Specification of health data transfer from devices to DiGA (§ 374a SGB V)
Seiteninhalt:
This specification is based on HL7 FHIR R4 (v4.0.1), which is the normative FHIR version for the German healthcare system.
Considering that existing implementations at affected manufactures of resource servers may use FHIR R5 or may even prepare for the upcoming release R6, serious efforts have been made to not rely on elements from FHIR R4 resource definitions that do not have corresponding elements in R5 and R6. This even is a prerequisite for a semantics-preserving possible future upgrade of the HDDT specifications to a higher FHIR version than R4.
The FHIR standard defines three different representation formats: XML, JSON, and RDF (Turtle). Within the scope of the HDDT specification, resource servers as HDDT device data providers MUST support both the XML and JSON formats.
DiGA as HDDT device data consumers may choose between XML and JSON representations but MUST indicate the chosen representation in the HTTP Accept and Content-Type headers.
If a HDDT device data consumer requests a format in the Accept header that is not supported by the HDDT device data provider, the HDDT device data provider MUST respond with the error code 406 Not Acceptable. If a HDDT device data consumer sends a format in the Content-Type header that is not supported by the HDDT device data provider, the HDDT device data provider MUST respond with the error code 415 Unsupported Media Type.
It should be noted that the Content-Type and Accept headers may include additional FHIR-specific and general parameters:
_format Parameter and MAY support the other parameters defined at https://www.hl7.org/fhir/R4/http.html#parameters.The elements defined within the HDDT FHIR profiles consist of Mandatory, Must Support and Optional elements. This section defines how resource servers as device data providers and DIGA as device data consumers MUST process Mandatory, Must Support and Optional elements. Basis for these definitions are the HL7-D Best Practices for Profiling FHIR.
Mandatory elements are elements with a minimum cardinality of 1 (min=1). A HDDT device data provider always MUST provide a valid value for such elements. A HDDT device data consumer MUST be able to process such elements according to the semantics as defined with the HDDT specifications or the core HL7 FHIR R4 specification.
Must Support elements are flagged with an “S” in the HDDT FHIR profile definitions. A HDDT device data provider SHOULD provide a valid value for each Must Support element. Omitting a Must Support element in response to a query is only allowed if
A HDDT device data consumer MUST be able to process all Must Support elements according to the semantics as defined with the HDDT specification or the core HL7 FHIR R4 specification.
Optional elements are elements with a minimum cardinality of 0 (min=0) which are not flagged as Must Support. A HDDT device data provider MAY omit optional elements from a response to a request. A HDDT device data consumer MAY ignore optional elements included with the response to a request.
Remark: Ignoring an element means that the element is not interpreted by the device data consumer and does not affect the device data consumer’s perception of the semantics of the resource. The only exception is when the element is a modifierExtension. In this case the device data consumer MUST throw an error if it is not able to interpret the modifierExtension (see Using Existing and Derived Profiles).
HDDT builds upon standard FHIR RESTful interactions on Observation resources for sharing measured device data. Aggregated reports are shared using dedicated FHIR operations. Access to observational device attributes (e.g. calibration status) is possible through standard FHIR RESTful interactions on Device and DeviceMetric resources.
For the specifications of the required interactions and operations see the respective HDDT specification parts:
A Device Data Recorder MUST publish the list of supported search parameters as part of its CapabilityStatement (see /metadata endpoint).
The DiGA MUST provide an OAuth2 Bearer Token in the HTTP Authorization header with each FHIR RESTful interaction or operation request, using the format Authorization: Bearer <access_token>. For details on how to obtain an Access Token see Pairing - Tokens and Token Response. For rules on how to validate the Access Token see Security Considerations.
For each FHIR endpoint that a Device Data Recorder MUST support, the respective HDDT specification part lists possible errors. For each error the expected HTTP error code, the type of error, and likely reasons for the occurrence of the error are given.
In case of an error, the Device Data Recorder MUST return the defined HTTP error code. It MUST return a FHIR-OperationOutcome resource if [OperationOutcome] is specified as the error type by the specification of the affected interaction or operation. The Device Data Recorder SHOULD provide a reason for the error. For this the Device Data Recorder SHOULD either use a coded value in OperationOutcome.issue.details, or use the free text input in ObservationOutcome.issue.diagnostics.
Manufacturers who implement the HDDT FHIR API MAY use any FHIR profile that is compliant with the mandatory and Must Support elements of the HDDT profiles. Such profiles MAY further constrain any optional elements from the HDDT profile.
Manufacturers who implement the HDDT FHIR API MAY use any FHIR profiles that further constrain the HDDT FHIR profiles as long as
When using derived or compliant profiles, the manufacturer MAY include a respective meta.profile reference with a resource instance. A DiGA MAY ignore such meta.profile references. A DiGA MUST always validate received resources against the HDDT profile regardless of value of the meta.profile element.
In addition, the implementor of a HDDT profile MUST be aware that a DiGA as the consumer of the HDDT FHIR resources
extension elements with the resource unless these extensions are defined by the HDDT specificationmodifierExtension that the DiGA is not able to interpret.Implementations that regularly trigger errors with a resource consuming DiGA MAY be considered as not compliant with the HDDT specifications. DiGA manufacturers who are affected by such errors MAY request gematik for a renewal of the conformance approval of the resource providing Health Record’s HDDT implementation.
While deriving FHIR profiles from the assessed use cases (see methodology), existing profiles from other countries and organizations have been considered in order to be as compliant as possible with existing solutions.
Baseline for many specifications in the area of health device data are the ISO/IEEE 11073 family of standards for medical device communication. These standards define a common framework for the exchange, management and interoperability of medical device data. The standards define device specific domain models on top of a common data model, communication protocols, and standardized attributes for device configurations. For years several organizations, in particular the Continua Health Alliance and the Bluetooth SIG, have worked on the definition of Health Device Profiles based on ISO/IEEE 11073 standards in order to allow interoperability between personal health devices and health IT systems. The focus of specific profiles is on the device side, i.e. communication between a Personal Health Device and a Personal Health Gateway device (e.g. a smartphone).
The HL7 Personal Health Device (PHD) Project of the HL7 Devices Workgroup builds upon the work of the Continua Health Alliance by defining FHIR profiles for the exchange of health device data based on the Domain Information Model as defined in the IEEE 11073-20601 standard. These profiles cover a wide range of personal health devices including blood pressure monitors, weight scales, glucose meters, pulse oximeters, and thermometers. The profiles are designed to be used in a variety of settings including home health care, remote patient monitoring, and telehealth. The focus of the HL7 PHD profiles is on data exchange between a Continua compliant Personal Health Gateway and a receiving health IT system (“Health Record” in the former Continua notion). Another initiative from HL7 - Point of Care Devices (PoCD) - focuses on the exchange of data between point of care devices and health IT systems in clinical settings. In contrast to PHD, PoCD builds upon the Domain Information Model as defined in the ISO/IEEE 11073-10201 standard for Point-of-care medical device communication.
The figure below shows how the HDDT profiles, the ISO/IEEE 11073 standards, and the HL7 PHD profiles focus on different parts of the overall communication chain from a Personal Health Device to consuming health IT application such as a DiGA.
The existing HL7 initiative which is best comparable with the goals of HDDT is the HL7 Vitals Signs Panel. This profile covers a wide range of vital signs - e.g. from a patient’s wearables and personal health devices - including blood pressure, body temperature, heart rate, respiratory rate, oxygen saturation, and body weight. The purpose is to allow a client to request a patient’s vital data from a resource server in a simple request and only profiling the defined observations to the minimum needed for interoperability. This is the same strategy as used with the HDDT profiles. Differences between the HL7 Vital Signs Panel and the HDDT Observation profiles are:
Observation.category element mandatory while HDDT does not. The reason for this is that for HL7 the category is the broadest filter for search interactions while HDDT’s broadest filter is the Mandatory Interoperable Value (MIV) for the Observation.code element.Observation.device element mandatory while HDDT does. The reason for this is that the use cases addressed by HDDT require a higher level of patient safety and data provenance than the use cases addressed by the HL7 Vital Signs Panel (see conclusion below).Observation.subject element to be mandatory while HDDT does not. The reason for this is that DiGA and medical aids’ backend systems do not securely identify the patient. They just match authenticated patient accounts. The relevant patient identifer therefore is the internal patient ID of the Device Data Recorder, which is associated with the Access Token and which is fully opaque to the requesting DiGA. In order to allow a Device Data Recorder to not disclose this identifier to the DiGA, HDDT does not make the Observation.subject element mandatory. DiGA and Device Data Recorder MAY use the Pairing-ID as a reference to the patient, but as this ID is as well known to both parties from the pairing process, there is no need to redundantly provide this ID with each Observation resource.The following table shows the compatibility of the defined HDDT FHIR Observation profiles and aggregated report profiles with existing international profiles.
| HDDT FHIR profile | international profile | HDDT compliance statement |
|---|---|---|
| blood glucose measurement (Observation) | UK Core Observation Blood Glucose | UK Core allows only SNOMED CT for the Observation.code element while HDDT only allows LOINC. Observation.device is optional for UK Core. |
| US Core R4 Observation | fully compliant except that Observation.device is mandatory with HDDT. |
|
| International Patient Summary: Observation Results | Observation.device is optional for IPS. Other derivations are minor issues that do not affect the compatibility with HDDT blood sugar measurements: IPS only allows for final as an observation’s status. IPS allows for explicitly missing effective[x] elements using an extension. |
|
| Clinivault Observation (India) | fully compliant except that Observation.device is mandatory with HDDT. |
|
| KBV MIO DiGA-Toolkit (Germany) and KBV Basisprofile (Germany) |
Observation.device is mandatory with HDDT. HDDT only allows for a single Observation.code while KBV requests two (LOINC and SCT). The KBV LOINC binding is a subset of the HDDT MIV ValueSet for Blood Glucose Measurement. |
|
| ISiK Vitalwerte und Körpermaße (Germany) | In contrast to ISiK Observation.device is mandatory with HDDT. ISiK makes serveral elements mandatory or Must Support due to the hospital context for which the ISiK profiles are designed: Observation.category for better filtering, Observation.subject for identification of the patient, and Observation.encounter for linkage with an encounter and internal access control. |
|
| Finnish PHR Blood Glucose Profile | Finnish PHR allows for LOINC Codes which are not part of the HDDT MIVs. Finnish PHR disallows Observation.device which is mandatory for HDDT. |
|
| CGM summary report (Bundle) | HL7 CGM IG | The HDDT cgm summary report capsuled with the FHIR bundle is fully compliant with the machine readable part of the HL7 CGM IG (CGMSummaryObservation profile). |
| Continuous Glucose Measurement (Observation) | Recently there seem to be no dedicated profiles available for capturing continuous glucose monitoring (CGM) raw data as FHIR SampledData. Available CGM profile either only cover key values (see HL7 CGM IG) or provide one Observation resource per data point. The later approach was discarded due to severe efficiency problems with modern CGM with sample rates of up to one value per minute. | |
| HL7 PHD real time sample area Observation Profile | The HL7 PHD profile is designed to capture real-time data from personal health devices. It uses the SampledData datatype to capture a series of measurements over time. The profile is fully compliant with the HDDT Continuous Glucose Measurement profile except that Observation.category is mandatory and Observation.device is optional for HL7 PHDrtsa. In addition HL7 PHDrtsa does not define conventions for sharing contiuously measured data where effectivePeriod does not have an end value in ‘real life’. |
As can bee seen in the assessment, the only major derivation of the information model and its derived Observation profiles from existing Observation profiles is that HDDT makes the Observation.device element mandatory. The reason for this is to address patient safety issues which arise from the specific HDDT use cases:
Device.serialNumber as provided with a Device resource is the only identifier that allows the patient to verify that data originated from his personal health device.