Specification of health data transfer from devices to DiGA (§ 374a SGB V)
Seiteninhalt:
The legal requirements specify that a medical aid or implant must be able to provide the following types of data to DiGA:
For the first implementation stage of HDDT, only
This section describes the fundamental mechanisms for exchanging measurement data and metrics. For measurement data, both single measurements and continuously collected time series are considered.
In general, data can be measured in two different scenarios by personal health devices:
In addition, there are also devices and scenarios, which combine both paradigms, e.g.
The HDDT FHIR API handles dedicated and continuous measurements in different ways. Which flavor of the API is to be used, is part of the FHIR implementation guide of a MIV. For combined scenarios usually the API flavor for continuous measurements is used, because it is much more efficient in transferring sampled data.
The specification of the technical interfaces for retrieving device data considers the following determinations and requirements:
Device.patient and the Observation.subject elements is given in the Security and Privacy chapter of this specification.A DiGA requests device data from a Device Data Recorder using a standard FHIR search interaction on the Observation resource type. The Device Data Recorder MUST respond to a search request with a collection of Observation resources or with an appropriate error.
The request MUST include an OAuth 2.0 access token in the Authorization header (as defined in the HDDT OAuth2 profile). This access token is issued by the Authorization Server of the Device Data Recorder.
The Device Data Recorder MUST be able to derive the internal patient identifier corresponding to the Pairing ID contained in the access token. This identifier MUST implicitly be used as the subject parameter in every query to the Device Data Recorder’s FHIR API. If a DiGA explicitly provides a subject parameter, the Device Data Recorder MUST ignore it and SHOULD return a 400 Bad Request error.
The Device Data Recorder MUST be able to retrieve the SMART scopes from the access token, which were consented to during pairing with the requesting DiGA (see Pairing). The SMART scope (with the resource type Observation) and it’s query parameters MUST implicitly be applied as a code search parameter in every FHIR search query. ValueSets used in scopes MUST be expanded since they MAY consist of multiple LOINC codes. All of these codes MUST be considered in the search (logical OR semantics). A DiGA MAY further narrow the result by explicitly providing a code parameter.
With every FHIR search interaction, the DiGA SHOULD provide a date parameter to limit the time period of data retrieval. If no date is specified, the Device Data Recorder MUST return all matching data according to the implicit and explicit query parameters.
Example:
GET [base]/Observation?date=gt20250912
The HTTP header holds an Access Token, from which the Device Data Recorder can obtain its internal patient identifier 123 and a SMART scope that resolves to the ValueSet https://gematik.de/fhir/hddt/ValueSet/hddt-miv-continuous-glucose-measurement which contains the LOINC codes 105272-9 and 99504-3. The “real” query processed by the Device Data Recorder’s FHIR Resource Server in this example is
GET [base]/Observation?date=gt20250912&subject=Patient/123&code:in=https://gematik.de/fhir/hddt/ValueSet/hddt-miv-continuous-glucose-measurement
Remark: The MIV ValueSets will be published on the ZTS (https://terminologien.bfarm.de) after the final approval of this specification. By now the ValueSets can only be found in the ValueSet section of this specifications’s artifact summary.
A DiGA MAY further constrain the kind of requested values by providing one or more code arguments with the search request. In this case only Observation resources are returned, where the contained data exactly matches the given codes.
Example: If no code argument is given, the data recorder of a blood glucose meter will respond to a query for blood glucose data with all glucose values regardless of the unit (e.g. mg/dl and mmol/l). If the LOINC code 2339-0 (Glucose [Mass/volume] in Blood) is given as a code argument, the device recorder will only respond with values that were measured in blood and which are available as mg/dl.
All code values provided as explicit query arguments MUST be part of the ValueSet that is referenced in the SMART scope that is linked with the Access Token. If a DiGA requests for a code which is not contained with this value set, the Device Data Recorder MUST respond with an ‘Invalid Request` error.
date and code are the only search parameters that each DiGA and Device Data Recorder MUST support for all MIVs. A MIV-specific implementation guide MAY request for supporting further search arguments and MAY constrain the use and semantics of these arguments. A Device Data Recorder MAY support even more search parameters in accordance to the FHIR Observation resource definition. In this case these arguments MUST be published through the Device Data Recorders CapabilityStatement.
Per HL7 FHIR a resource is a a definable, identifiable, addressable collection of data elements that represents a concept or entity in health care. By this each Observation resource a Device Data Recorder transmits to a DiGA MUST be identifiable and addressable through an id. Device Data Recorder MUST allow a DiGA to request a known Observation by using a FHIR read interaction:
GET [base]/Observation/[id]
Remark: As stated in General Considerations, device data recordes MAY limit access to historical data to 30 days, unless the MIV-specific specification requests for a longer period. In case a DiGA requests such a historic resource by its id after the availability period ended, the Device Data Recorder MUST respond with a _404 Not Found error (see https://hl7.org/fhir/R4/http.html#read for details on handling deleted resources).
In accordance with the HL7 FHIR specification, supporting paging is recommended but optional for Device Data Recorders (SHOULD). DiGA manufacturers MUST consider, that a specific Device Data Recorder may only be able to respond with a limited number of Observation resources in response to a query.
Each Observation resource returned by a Device Data Recorder MUST contain a device element that either refers to a DeviceMetric or a Device resource.
A Device Data Recorder MUST provide a device reference to a DeviceMetric with the Observation resources, if the sensor needs to be calibrated before or during use or if the calibration status of the sensor may change over time. The DeviceMetric resource MUST reflect the status of the sensor that was used to measure the observation. It MUST at least
calibration.state of the sensor andsource reference to the Device resource that represents the configuration of the personal health device at the time the measurement was performed.If the Device Data Recorder does not provide a device reference to a DeviceMetric resource, it MUST provide a device reference to a Device resource.
A DiGA MAY store the id of a Device resource, it received through a Observation.device or DeviceMetric.source reference or from a search interaction. The DiGA MAY use this id to request the Device resource - and by this the device’s current status - through a FHIR read interaction. This information can be helpful for detecting missing data (see section Missing Data below).
The Device resource MUST contain a definition reference to the device’s product definition as registered with the BfArM HIIS-VZ (Device Registry). The reference MUST be given as the canonical url of the DeviceDefinition resource that can be obtained from the BfArM HIIS-VZ. The reference MAY contain a version value.
Every Device Data Recorder holds information about its static attributes as part of its definition. These attributes can be obtained as key-value-pairs from the BfArM HIIS-VZ. The table below lists the keys defined so far.
| key | value | obligation | comments |
|---|---|---|---|
| Historic-Data-Period | minimum number of days historic data is available at the Device Data Recorder | MUST | If a DiGA queries for data that is older than Historic-Data-Period, the Device Data Recorder MAY respond with an error. Historic-Data-Period MUST NOT be shorter than the minimum historic data period defined for the affected MIV. |
| Delay-From-Real-Time | maximum delay in seconds of the end-to-end synchronization from the Personal Health Device to the Health Record under normal operational conditions. | MUST | if a DiGA polls for new device data in fixed intervals, the `Delay-From-Real-Time’ denotes the overlap of two consecutive intervals in order to catch all measured data. |
| Grace-Period | Time span a DiGA must wait between two requests for data that affect the same MIV and patient | MUST | A Device Data Recorder MAY reject a new request for the same MIV and patioen that is issued before the end of this time span. |
| Chunk-Time-Span | size of a chunk for sharing sampled data (see below) | MUST if applicable | This property is only applicable for Device Data Recorders that provide Observation values as sampled data |
The HDDT specification does not mandate a specific versioning strategy for Device and DeviceMetric resources. A Device Data Recorder MAY use the FHIR versionId mechanism or MAY use its own versioning strategy (e.g. by creating new resources whenever a relevant element changes).
A Device Data Recorder MUST track the Medical Health Devices used by a patient. If a patient exchanges a Personal Health Device (e.g. gets a new insulin pump), the Device Data Recorder MUST create a new Device resource with a new id that reflects the new Personal Health Device.
Unless stated otherwise in the MIV-specific implementation guide, a Device Data Recorder MAY not perform any versioning on any of the elements of the Device resource or MAY not expose such changes to the DiGA (see [https://hl7.org/fhir/R4/resource.html#versions(https://hl7.org/fhir/R4/resource.html#versions)]). In this case the Device Data Recorder MUST NOT change the id and the ‘meta.versionID’ of the Device resource as long as the Personal Health Device does not change. Nevertheless, a read interaction on the Device resource MUST always return the current status of the Personal Health Device (e.g. active, inactive, unknown), but it is up to the manufacturer, if this leads to a new, persistent, addressable version of the resource.
If a manufacturer implements versioning by creating a new record version of a Device resource whenever a relevant element changes, the manufacturer MUST implement the FHIR vread interaction to allow a DiGA to request a specific record version of a Device resource. See vread interaction for Personal Health Device resources for details.
Device resources MAY overlap in time. This is e.g. the case if a patient exchanges a Personal Health Device with a new one of the same type but keeps the old device for some time (e.g. when changing a rtCGM sensor the patient may take on the new sensor while still wearing the old one until the new sensor is fully calibrated). In this case it is up to the Device Data Recorder on how to handle the overlapping devices. Depending on the concrete kind of device and its typical usage patterns, the Device Data Recorder MAY either
effectiveDateTime or effectivePeriod, but the DiGA can distinguish the source of the data by the device reference of the Observation resources.A change of the Personal Health Device MUST always lead to a new DeviceMetric resource with a new id.
For sensors that need to be calibrated or change their calibration status over time, the Device Data Recorder MUST at least track the changes in calibration.state of the DeviceMetric resource. If the calibration.state changes, the Device Data Recorder MUST either create a new DeviceMetric resource with a new id or MUST create a new record version of the existing DeviceMetric resource by using the FHIR versionId mechanism.
Unless stated otherwise in the MIV-specific implementation guide, a Device Data Recorder MAY not perform any versioning on any elements of the Device resource other than calibration.state or MAY not expose such changes to the DiGA (see https://hl7.org/fhir/R4/resource.html#versions). In this case the Device Data Recorder MUST NOT change the id and the ‘meta.versionID’ of the Device resource as long as the calibration.state does not change.
If a manufacturer implements versioning by creating a new record version of a DeviceMetric resource whenever calibration.state or any other relevant element changes, the manufacturer MUST implement the FHIR vread interaction to allow a DiGA to request a specific version of a DeviceMetric resource. See vread interaction for Device Configuration and Calibration Status resources for details.
The Device Data Recorder must respond a search request with a Bundle of type searchset that contains all Observation resources that match the request. A DiGA MAY add the search parameter _include=Observation:device with the request. In this case the Device Data Recorder MUST include the DeviceMetric or Device resource that is referenced by the device element of the Observation in the same Bundle (see https://hl7.org/fhir/R4/search.html#revinclude for details).
Example:
GET [base]/Observation?date=gt20250912&_include=Observation:device
will return a Bundle of type searchset that contains all Observation resources that match the request and for each Observation the referenced DeviceMetric or Device resource.
Example:
GET [base]/Observation?date=gt20250912&_include=Observation:device&_include:iterate=DeviceMetric:source
will return a Bundle of type searchset that contains all Observation resources that match the request and for each Observation the referenced DeviceMetric or Device resource. If a DeviceMetric resource is referenced, the Bundle will also contain the Device resource that is referenced by the source element of the DeviceMetric.
In general, HDDT only requests a minimum of data elements to be mandatory with an Observation resource that reflects a single measurement. The example below is based on the HDDT FHIR implementation guideline for the MIV Blood Glucose Measurement.
{
"resourceType" : "Observation",
"id" : "example-blood-glucose-measurement-1",
"meta" : {
"profile" : [
🔗 "https://gematik.de/fhir/hddt/StructureDefinition/hddt-blood-glucose-measurement"
]
},
"status" : "final",
"code" : {
"coding" : [
{
"system" : "http://loinc.org",
"code" : "2339-0",
"display" : "Glucose [Mass/volume] in Blood"
}
]
},
"effectiveDateTime" : "2025-09-26T12:00:00+02:00",
"valueQuantity" : {
"value" : 120,
"unit" : "mg/dl",
"system" : "http://unitsofmeasure.org",
"code" : "mg/dL"
},
"device" : {
🔗 "reference" : "DeviceMetric/example-glucometer-metric"
}
}As the information on the time and result of the measurement is a rather straight-forward adoption of the FHIR standard, some HDDT-specific conventions have to be considered with the device reference (see above). The figure below shows a simple interplay of measured data (Observation), sensor status (DeviceMetric), and device configuration (Device), e.g. in response for a query for all blood glucose data that was measured for a given patient on May 7th.
This gets more complex if the status of the sensor changes. The figure below is based on the previous example, but now data is requested for a longer period (May 7th and 8th) with the patient calibrating the device within this period.
As shown with the example, a calibration of a sensor leads to an update to the sensor’s DeviceMetric resource. The Device Data Recorder MUST make changes to the calibration status of a sensor make visible to the device data consumer.
A response of the Device Data Recorder to a query for dedicated measurements MAY be incomplete in a way that there MAY be more data measured for the requested period, but the Device Data Recorder does not provide this data to the DiGA. The Device Data Recorder MUST respond with all data that is available at the time of the request, but there MAY be more data available that was measured a short time before the request, but not yet transmitted to the Device Data Recorder. Therefore a DiGA SHOULD always obtain the static property Delay-From-Real-Time from the Defvice Data Recorder’s DeviceDefinition (see above) and use this value to overlap two consecutive requests for data.
Missing data MAY even occur if the connection between the Personal Health Device and the Personal Health Gateway or between the Personal Health Gateway and the Health Record was broken during the requested period and the missing data may be transmitted to the Health Record after the connection is re-established. A DiGA can detect this situation by reading the Device resource and checking the status element. If the status of the device is unknown, the DiGA SHOULD assume that data is missing and may be available later.
Remark: FHIR R4 does provide information about a Personal Health Device being offline through the statusReason element of the Device resource. This element is missing in FHIR R5 and therefore not used in the HDDT specification. Due to this incompatibility across FHIR versions, a status value of _unknown MUST be used by the Device Data Recorder to indicate that the connection to the Personal Health Device is temporarily broken (which is semantically correct as the status of the device is unknown to the Health Record if it does not receive any information from the device).
The easiest way for a DiGA to deal with these kinds of missing data is to set the date argument of a new request to one second after the effectiveDateTime of the last Observation it received with the last request.
Values from continuous measurements MUST be provided as chunks of sampledData, where each chunk of data is represented as an Observation resource. As with single data points, the Observation holding the sampled Data MUST contain a device element that either refers to a DeviceMetric or a Device resource.
The owner of the Device Data Recorder MUST define the chunk-time-span of measurements that can be covered by a single chunk. E.g. if the owner of the Device Data Recorder defines a chunk-time-span of 24 hours for a chunk, each chunk can hold up to 1440 data points for a Personal Health Device that measures data every minute. A chunk MAY cover a shorter period of time than the chunk-time-span (e.g. when the calibration status of the device changed during measurements), but it MUST NOT exceed that value. The chunk-time-span is part of the device definition and can be requested by DiGA trough a defined property of the Device Data Recorder Definition resource.
If a query for continuously measured data results in multiple chunks (Observations), each chunk’s Observation.effectivePeriod MUST have the length of the chunk-time-span. The only exceptions are changes to the calibration.state or a change of the personal health device (see below). In these cases a chunk’s Observation.effectivePeriod can be shorter than the chunk-time-span.
A chunk MAY be in a preliminary state. This is the case if the chunk is not filled with values up to the chunk-time-span and the Device Data Recorder expects more data to come until the end of the time period covered by the chunk. The figure below shows an example of a preliminary chunk for a Device Data Recorder with a chunk-time-span of 24 hours and a Personal Health Device with a sample rate of one data point per minute. The search query stated by an authorized DiGA requests for all data from May 4th until now. The newest data available to the Device Data Recorder is from May, 6th 10:00 am.
If the DiGA states the same search query again one hour later, the newest data being available at the Device Data Recorder is now from May, 6th 11:00 am. Therefore now the preliminary chunk contains 60 additional values.
Remark: In the given example the DiGA could as well have used a read interaction to just obtain an updated version of the preliminary chunk:
GET [base]/Observation/3
Some sensors for continuous measurements require initial or regular calibration. If this leads to a changed value for calibration.state in the DeviceMetric observation that is bound to a chunk, the Device Data Recorder MUST finish the current chunk and start a new chunk. The same holds for any other change in calibration.state, e.g. a sensor that switches from a calibrated to an unknown state after a certain time (see figure below.)
As can be seen with the example, the last chunk before calibration is set to a final status and the effectivePeriod is adapted to the end time the calibration state changed. The new chunk is initialized with a preliminary status and the fixed chunk-time-span.
It is up to the Device Data Recorder if a change of calibration.state leads to a new DeviceMetric resource or if a new version of the existing resource is created. See Versioning of Device and DeviceMetric Resources above for possible options related to the manufacturer’s overall versioning strategy.
Personal Health Devices MAY require a Personal Health Device of another type to perform the calibration (e.g. a blood glucose meter for calibrating a rtCGM). Values measured with another Personal Health Device for calibration purposes MUST NOT be part of a chunk of continuously measured data.
Pairing a DiGA with a Device Data Recorder is always done for a specific patient and a specific type of Personal Health Device. If the patient exchanges the Personal Health Device (e.g. gets a new insulin pump or changes the rtCGM sensor) for a new one of the same type, the DiGA does not need to re-pair with the Device Data Recorder. In this case the Device Data Recorder MUST handle the change of the instance of the Personal Health Device internally. Nevertheless, the DiGA MUST be able to detect that a change of the Personal Health Device took place. This is done by the Device Data Recorder by finishing the current chunk and starting a new chunk with a new device reference to a Device resource that reflects the new Personal Health Device (see figure below).
In contrast to a change of calibration.state, a change of the Personal Health Device MUST always result in a new Device resource with a new id.
A response of the Device Data Recorder to a query for continuously measured data MAY be incomplete in a way that there MAY be more data measured for the requested period, but the Device Data Recorder does not provide this data to the DiGA. The most common case is that a DiGA requests for data that was measured very recently (e.g. within the last hour). The Device Data Recorder MAY respond with all data that is available at the time of the request, but there MAY be more data being in transmission from the Personal Health Device to the Health Record. Therefore a DiGA SHOULD always obtain the static property Delay-From-Real-Time from the Device Data Recorder’s DeviceDefinition (see above) and use this value to overlap two consecutive requests for data.
Missing data MAY even occur if the connection between the Personal Health Device and the Personal Health Gateway or between the Personal Health Gateway and the Health Record was broken during the requested period and the missing data may be transmitted to the Health Record after the connection is re-established. A Device Data Recorder MUST signal this kind of missing data by setting the status of the Observation resource that holds the chunk to preliminary with the effectivePeriod covering the full chunk-time-span.
Another reason for missing data is a change of the Personal Health Device (e.g. a rtCGM is replaced by a new sensor). A DiGA MAY detect missing data due to device changes by analyzing the sequence of (Observations) it received from a Device Data Recorder. If the effectivePeriod.end of a chunk is before the effectivePeriod.start of the next chunk, there is a gap in the data. The DiGA MAY use the id of the Device resource that is referenced in the device element of the chunks to check if the Personal Health Device changed (see above).
A DiGA MAY poll a Device Data Recorder in regular intervals for new data. For the current chunk data updates can be polled by read interactions. A status switch from preliminary to final signals that the chunk is full or that the status of the Personal Health Device changed (e.g. the sensor changed its calibration status or the patient put on a new sensor). In this case the DiGA MUST use the effectivePeriod.end of the last chunk as a starting point for a new search interaction to obtain the next chunk.
The pseudo code below shows an example of a DiGA polling for new data in regular intervals.
chunk = read [base]/Observation?date= [now]
loop
while chunk.status == preliminary
wait some time
chunk = read [base]/Observation/[chunk.id]
end
wait some time
chunk = read [base]/Observation?date=gt[chunk.effectivePeriod.end + 1 second]
end
The legal requirements of § 374a SGB V specify that a medical aid or implant must be able to provide aggregated data to DiGA. In the present specification, this is limited to data calculated from the MIVs provided by the medical aid or implant. For example, for a connected rtCGM a Device Data Recorder must only be able to provide key metrics that can be calculated exclusively on the continuously collected glucose values which represent the MIV “Continuous Glucose Measurement”. In order to minimise computational efforts at the manufacturer of the Device Data Recorder, DiGA can only request for aggregated or summarised data in the form of standardised reports. A DiGA cannot, for example, query the number of hypoglycemias within a given period of time as a single value from the Device Data Recorder of an rtCGM, but only the complete set of relevant key metrics, e.g. such as those contained in the ambulatory glucose profile (AGP).
As far as available and usable, these reports represent existing specifications. For rtCGM data, for example, the specification of a CGM Summary Observation from HL7 International is adopted unchanged. In order to be as flexible as possible for future MIVs, the specification does not limit the reports to a certain FHIR resource definition. This allows for adopting standard FHIR IGs for standardized reports regardless if they are provided as FHIR Observations, DiagnosticReports or any other kind of DomainResource.
As a dynamically derived artefact a report only becomes a “true” FHIR resource if it is persisted by a DiGA. The Device Data Recorder MAY decide to NOT persist dynamically assembled reports as addressable FHIR resources. In order to reflect this behaviour and to preserve maximum flexibility with respect to the type of FHIR resource used for a report, the HDDT specification defines dedicated FHIR operations for querying reports from a Device Data Recorder.
Each report is bound to the MIV that is used to calculate the report. A Device Data Recorder MUST provide a list of available reports for each MIV it supports. This list MUST be published by listing the respective FHIR operations in the Device Data Recorder’s CapabilityStatement which MUST be obtainable by a DiGA through the /metadata endpoint of the Device Data Recorder’s FHIR resource server.