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 clinical 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 in the form of a standard FHIR Bundle, or with an appropriate error. In case a search interaction finds no matches, an empty Bundle MUST be returned.
Certain endpoints or certain MIVs may specify additional situations, where an empty Bundle is returned. In such cases, an OperationOutcome MAY be included in the Bundle, in order to explain the reason why no matches were found.
The search 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 1: 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 it supports, potentially including measurements with different LOINC codes representing different units (e.g. LOINC code 2339-0 for Glucose [Mass/volume] in Blood measured in mg/dl and LOINC code 15074-8 for Glucose [Moles/volume] in Blood measured in mmol/l). If a specific LOINC code such as 2339-0 is given as a code argument, the device recorder will only respond with observations that match that specific code, limiting results to measurements in the corresponding unit (mg/dl in this case).
Example 2: If no code argument is given, the data recorder of a peak flow meter will respond to a query with all lung function values that the data recorder supports (e.g raw measurement, reference value, and ratio of measured value to predicted value, each for Peak Expiratory Flow (PEF) and Forced Expiratory Volume in One Second (FEV1)). However, if a code argument is provided (e.g. 20150-9 FEV1), the device data recorder will respond only with observations that match that specific code. (Example queries and responses can be seen in MIV Lung Function Testing.)
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 return an empty Bundle, as if no matches are found. An OperationOutcome MAY be included in the Bundle, in order to explain why no search results were returned.
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]
Device Data Recorders MAY limit access to historical data to a MIV-specific Historic Data Period, e.g. 30 days (see Properties of Device Data Recorders for details). If a DiGA requests data that is older than the declared Historic Data Period, the Device Data Recorder MUST respond with a 404 Not Found error and an appropriate OperationOutcome indicating that the requested data lies outside the supported historic data period. Error handling follows the rules defined in Resource Server Errors.
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 MAY contain a definition reference to the device’s product definition as registered with the BfArM HIIS-VZ (Device Registry). If present, the reference MUST point to the matching DeviceDefinition resource in the BfArM HIIS-VZ.
Every Device Data Recorder holds information about its static attributes as part of its definition, which are in particular useful for DiGA to optimize the continuous retrieval of sampled data (see Properties of Device Data Recorders for details).
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. The Device Data Recorder MUST follow the definitions for FHIR LogicalIDs when creating a new id.
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). 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.calibration.state of the DeviceMetric resource that is referenced by the device element of the Observation resources to determine if the device was calibrated at the time of measurement.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 Device Data Recorder’s DeviceDefinition (see Properties of Device Data Recorders for details) 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. Note: In the context of HDDT, a status with a value of unknown is conventionally interpreted to indicate that the Device Data Recorder currently has no active connection to the Personal Health Device, and thus the completeness of data for recent time periods cannot be guaranteed. This is a specific interpretation beyond the base FHIR definition. 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 previous 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 internally define a 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 Personal Health Device that measures data every minute, each chunk can hold up to 1440 data points. A chunk MAY cover a shorter period of time than the chunk time span in exceptional situations (e.g. when the calibration status of the device changed during measurements), but it MUST NOT exceed that value.
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 MUST be set to a preliminary state 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 as defined by the vendor.
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 Properties of Device Data Recorders for details) 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 clinical 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 clinical 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.