Implementation Guide
Health Device Data Transfer
Version 0.1.0 - ballot

Specification of health data transfer from devices to DiGA (§ 374a SGB V)

Endpoint Device

This document describes the syntax and semantics of querying FHIR Device resources via the standard FHIR RESTful API. A Device resources represent individual Personal Health Devices (medical aids and implants) of a patient, such as glucometers, CGM sensors, and pace makers.

To be compliant with § 374a SGB V, a Device Data Recorder MUST implement interactions for reading and searching Device resources:

Returned resources MUST conform to the HDDT Personal Health Device Device profile.

Endpoints

Device - READ

   
Endpoint [base]/Device/<id>
HTTP Method GET
Interaction READ
Description Retrieve a single Device resource by its logical id. The returned Device MUST conform to the HDDT Personal Health Device profile. All constraints and obligations of the standard FHIR read interaction apply.
Request Parameters id - logical ID of the Device.
Authorization OAuth2 Bearer token REQUIRED. The resource server MUST only return a Device resource that is linked to the patient who is associated with the token. Provided Device resources MUST match the requestor’s granted scopes (see Smart Scopes for the compartment semantics that MUST be used for validating the authorization of the requestor).
Returned Objects HDDT Personal Health Device resource. If no matching resource exists or if the matching resource cannot be returend, an error response MUST be sent (see below).
Specifications The only ways for a DiGA to obtain the logical id of a Device resource are an Observation.device reference, a DeviceMetric.source reference or a search interaction for Personal Health Devices of the given patient.
A DIGA MAY read a Device resource in order to validate the status of a Personal Health Device. E.g. a status value unknown indicates that the Device Data Recorder has no connection to the device hardware, e.g. due to interrupted communication.
A Device Data Recorder MUST NOT disclose information to a DiGA that allows the DiGA to identify the patient as a natural person. Respective guidance on the use of the Device.patient element is given in the Security and Privacy chaper of this specification.
Error codes 400 Bad Request OperationOutcome (Invalid query parameters / Invalid search parameters)
401 Unauthorized plaintext (Invalid or expired JWT)
403 Forbidden OperationOutcome (Empty Authorization header, or client has no permission for this resource.)
404 Not Found OperationOutcome (No resource exists or is accessible with this ID.)
500 (Internal Server Error—MAY be either an OperationOutcome or plain text)

Device - VREAD

Remark: A Device Data Recorder MAY omit the version specific read interaction if it does not support versioning of Device resources (see Retrieving Data for a discussion on how to express changes of device properties).

   
Endpoint [base]/Device/<id>/_history/<versionId>
HTTP Method GET
Interaction VREAD
Description Retrieve a single Device resource by its logical id and versionId. The returned Device resource MUST conform to the HDDT Personal Health Device profile. All constraints and obligations of the standard FHIR vread interaction apply.
Request Parameters id - logical ID of the Device resource
versionId - version identifier of the Device resource
Authorization OAuth2 Bearer token REQUIRED. The resource server MUST only return versions of Device resources that can be linked to the patient who is associated with the token. Provided Device resources MUST match the requestor’s granted scopes (see Smart Scopes for the compartment semantics that MUST be used for validating the authorization of the requestor).
Returned Objects HDDT Personal Health Device resource. If no matching resource or version exists or if the matching resource or version cannot be returned, an error response MUST be sent (see below).
Specifications The only ways for a DiGA to obtain the logical id and the versionId of a Device resource are an Observation.device reference, a DeviceMetric.source reference, or a ‘search’ interaction for Device resources of the given patient.
Error codes 400 Bad Request OperationOutcome (Invalid query parameters / Invalid search parameters)
401 Unauthorized plaintext (Invalid or expired JWT)
403 Forbidden OperationOutcome (Empty Authorization header, or client has no permission for this resource.)
404 Not Found OperationOutcome (No resource exists or is accessible with this ID.)
500 (Internal Server Error—MAY be either an OperationOutcome or plain text)

   
Endpoint /Device
HTTP Method GET / POST
Interaction SEARCH
Description Search for Device resources.
Authorization OAuth2 Bearer token REQUIRED. The resource server MUST only return Device resources that are linked to the patient who is associated with the token. Provided Device resources MUST match the requestor’s granted scopes (see Smart Scopes for the compartment semantics that MUST be used for validating the authorization of the requestor).
Search Parameters The resource server MUST be able to discover the patient identifier from the Access Token. This identifier MUST implicitly be considered as the patient argument with every search request for Device resources. If a DiGA explicitly provides a patient argument with a query, the resource server MUST ignore this argument and SHOULD respond with an 400 Bad Request error.
The resource server MAY support any standard FHIR Device search parameters.
Returned Objects Bundle containing Device entries that match the query.
If no matching Device resources are found, an empty Bundle MUST be returned.
Specifications After successful pairing with a Device Data Recorder a DiGA SHOULD discover the Personal Health Devices of the patient by searching for Device resources. The DiGA MAY use search parameters to filter the results, e.g. by device-name or type. The DiGA SHOULD present the discovered Device.serialNumber to the patient to allow him to verify the result of the pairing process.
The resource server MAY support the _include:definition parameter to allow including referenced DeviceDefinition resources in the response bundle.
All constraints and obligations of the standard FHIR search interaction apply.
   
Error codes 400 Bad Request OperationOutcome (Invalid query parameters / Invalid search parameters)
401 Unauthorized plaintext (Invalid or expired JWT)
403 Forbidden OperationOutcome (Empty Authorization header, or client has no permission for this resource.)
404 Not Found OperationOutcome (No resource exists or is accessible with this ID.)
500 (Internal Server Error—MAY be either an OperationOutcome or plain text)

Profile - HDDT Personal Health Device

Profile: Device – Personal Health Device

This structure is derived from Device

NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
.. Device 0..* Device Personal Health Device
... implicitRules ?!Σ 0..1 uri A set of rules under which this content was created
... modifierExtension ?! 0..* Extension Extensions that cannot be ignored
... definition 1..1 Reference(DeviceDefinition) Definition of the Personal health device
... expirationDate S 0..1 dateTime Date and time of expiry of this Personal health device (if applicable)
... serialNumber S 0..1 string Serial number of the Personal health device
... deviceName S 0..* BackboneElement Name of the Personal health device
.... modifierExtension ?!Σ 0..* Extension Extensions that cannot be ignored even if unrecognized
.... name 1..1 string The name of the device
.... type 1..1 code udi-label-name | user-friendly-name | patient-reported-name | manufacturer-name | model-name | other
Binding: DeviceNameType (required): The type of name the device is referred by.
... type 0..1 CodeableConcept The machine-readable type of the Personal health device
Binding: Device Type of personal health devices (required)

doco Documentation for this format

Detailed description of differential elements

Guidance on how to interpret the contents of this table can be foundhere

0. Device
Definition

A type of a manufactured device that is used in the provision of healthcare without being substantially changed through that activity. The device MUST be a medical aid or implant.

ShortPersonal Health Device
2. Device.definition
Definition

Reference to a DeviceDefinition resource that describes the technical and functional details of the Personal health device.

ShortDefinition of the Personal health device
Control1..?
4. Device.status
Comments

The status values active and inactive refer to the ability of the Personal Health Device to record and share measured data. E.g. a real-time Continuous Glucose Monitoring device usually stops recording and sharing glucose values after 14 days of wear, even though the sensor is still alive for a longer time. After these 14 days, the status switches from active to inactive.

If a resource server has not synchronized with the connected Personal Health Device for a time span longer than stated in the static attribute Delay-From-Real-Time(e.g. due to temporarely lost Bluetooth or internet connectivity), the status of the Device resource that represents the Personal Health Device MUST be set to unknown. The device specific value of the static attribute Delay-From-Real-Time can be obtained through the device's DeviceDefinition resource.

Must Supporttrue
Requirements

allow a requesting party to detect missing data (e.g. due to connection issues)

6. Device.expirationDate
Definition

The date and time beyond which this Personal Health Device is no longer valid or should not be used (if applicable).

ShortDate and time of expiry of this Personal health device (if applicable)
Comments

The expiration date signals the end of communication (which is latest the devices end of life). E.g. a real-time Continuous Glucose Monitoring device usually stops recording and sharing glucose values after 14 days of wear, even though the sensor is still alive for a longer time. The expirationDate in this case is 14 days after the patient started the sensor.

Must Supporttrue
8. Device.serialNumber
Definition

The serial number that uniquely identifies the Personal Health Device instance.

ShortSerial number of the Personal health device
Comments

The serial number MAY only be omitted if neither the Personal Health Device nor its manual and packaging hold the printed serial number and if the Personal Health Device does not provide an API for reading a unique number from the device hardware.

Must Supporttrue
10. Device.deviceName
Definition

The name of the Personal health device as given by the manufacturer and listed in the HIIS-VZ (BfARM Device Registry).

ShortName of the Personal health device
Must Supporttrue
12. Device.type
ShortThe machine-readable type of the Personal health device
BindingThe codes SHALL be taken from Device Type of personal health devices
(required to https://terminologien.bfarm.de/fhir/ValueSet/hddt-device-type)

Example: Glucometer

In this example the patient uses a glucometer that is connected to the Device Data Recorder via Bluetooth. The glucometer is used to perform blood glucose measurements that are stored as Observation resources in the Device Data Recorder. Each Observation references the Device resource that represents the glucometer (either directly or through a DeviceMetric resource).

The glucometer used in this example is the product GlukkCheck plus mg/dl from Glukko Inc.. The glucometer performs “bloody” measurements from capillary blood. The vendor-defined model number of this type of devices is CGPA987654 and the serial number of the patient’s individual device is SN123456. Both identifiers are printed on the back of the device and allow the patient to validate the authenticity of this Personal Health Device resource.

Remarks:

  • As glucometers do not expire (that is just the case for the test stripes), the expirationDate is not set, even though this element is set to Must Support in the profile.
  • The text element is omitted in this example to keep the example small. Nevertheless, as all HDDT resources are intended for sole machine processing, the text element MAY be omitted.

Device - READ

Request: GET /Device/example-glucometer

Response:

{
  "resourceType" : "Device",
  "id" : "example-glucometer",
  "meta" : {
    "profile" : [
      🔗 "https://gematik.de/fhir/hddt/StructureDefinition/hddt-personal-health-device"
    ]
  },
  "definition" : {
    🔗 "reference" : "DeviceDefinition/example-glucometer-def"
  },
  "status" : "active",
  "manufacturer" : "Glukko Inc.",
  "serialNumber" : "SN123456",
  "deviceName" : [
    {
      "name" : "GlukkoCheck plus mg/dL",
      "type" : "user-friendly-name"
    }
  ],
  "modelNumber" : "CGPA987654",
  "type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "version" : "20250520",
        "code" : "528401",
        "display" : "Glucose Monitor"
      }
    ]
  }
}

Device - SEARCH

Request: GET /Device

Response:

{
    "resourceType": "Bundle",
    "type": "searchset",
    "entry": [
        {
            "fullUrl": "https://example.com/fhir/Device/example-glucometer",
            "resource": {
                "resourceType": "Device",
                "id": "example-glucometer",
                "meta": {
                    "profile": [
                        "https://gematik.de/fhir/hddt/StructureDefinition/hddt-personal-health-device"
                    ]
                },
                "type": {
                    "coding": [
                        {
                            "code": "528401",
                            "system": "urn:iso:std:iso:11073:10101",
                            "version": "20250520",
                            "display": "Glucose Monitor"
                        }
                    ]
                },
                "status": "active",
                "deviceName": [
                    {
                        "name": "GlukkoCheck plus mg/dL",
                        "type": "user-friendly-name"
                    }
                ],
                "manufacturer": "Glukko Inc.",
                "serialNumber": "SN123456",
                "modelNumber": "CGPA987654",
                "definition": {
                    "reference": "DeviceDefinition/example-glucometer-def"
                }
            },
            "search": {
                "mode": "match"
            }
        }
    ]
}

Example: rtCGM Sensor

This example describes a real-time Continuous Glucose Monitoring sensor (rtCGM) as a personal health device.

The example sensor is the product GlukkoCGM 18 from Glukko Inc. that performs continuous glucose measurements from interstitial fluid. The sensor in the example will stop transmitting data on September 10, 2025, and MUST be replaced by the patient at that date. The vendor-defined model number of this type of devices is GCGMA98765 and the serial number of the patient’s individual device is CGM1234567890. Both identifiers are printed on the package of the device and allow the patient to validate the authenticity of this Personal Health Device resource.

Remarks:

  • The text element is omitted in this example to keep the example small. Nevertheless, as all HDDT resources are intended for sole machine processing, the text element MAY be omitted.

Instance of the HDDT Personal Health Device profile

{
  "resourceType" : "Device",
  "id" : "example-device-cgm",
  "definition" : {
    🔗 "reference" : "DeviceDefinition/device-definition-cgm-001"
  },
  "status" : "active",
  "manufacturer" : "Glukko Inc.",
  "expirationDate" : "2025-09-10",
  "serialNumber" : "CGM1234567890",
  "deviceName" : [
    {
      "name" : "GlukkoCGM 18",
      "type" : "user-friendly-name"
    }
  ],
  "modelNumber" : "GCGMA98765",
  "type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "version" : "20250520",
        "code" : "528409",
        "display" : "MDC_DEV_SPEC_PROFILE_CGM"
      }
    ]
  }
}