Specification of health data transfer from devices to DiGA (§ 374a SGB V)
Seiteninhalt:
The HDDT specification is based on several fundamental decisions intended to reduce complexity and ensure that its interfaces remain economically viable for manufacturers.
The HDDT solution enables a DiGA to retrieve standardised health data of the same patient of medical aids and after explicit consent of the patient - without establishing bilateral contractual relationships between the manufacturers. The system is based on a holistic 4-pillar architectural approach:
The key requirement for the Health Device Data Transfer (HDDT) specification is to build on existing international standards wherever possible. This applies not only to data formats and interfaces, but also to how medical aids and implants are broken down into abstract components, to the information model behind the exchanged data, to security services, and to the technical representation of meaningful artifacts.
| Standard | Use with HDDT |
|---|---|
| HL7 FHIR | The HDDT logical model is fully aligned with a FHIR-compliant information model. Device data is accessed through FHIR’s read and search interactions. All data exchanged through this API MUST conform to HL7 FHIR R4. HDDT places strong emphasis on compliance with the FHIR base specification and, where possible, with existing FHIR profiles for device data (see Use of HL7 FHIR). |
| ISO/IEEE 11073 | Properties and configuration settings of Personal Health Devices SHOULD be encoded using ISO/IEEE 11073 nomenclature. The HDDT information model considers the ISO/IEEE 11073 domain models of the devices evaluated during the HDDT MVP phase. |
| OAuth2 | The pairing flow for authorizing a DiGA to access device data is an implementation of the OAuth2 Code flow with PKCE. |
| SMART on FHIR | HDDT makes use of SMART 2.0 “Finer-grained resource constraints” and SMART 2.0 “patient-specific-scopes” for access permissions to FHIR resources (see SMART Scopes). |
| LOINC | HDDT Mandatory Interoperable Values (MIVs) are mapped onto sets of LOINC codes. |
| UCUM | Units of measures are consistently encoded in UCUM. |
The HDDT solution design imposes trust as well on the transport layer of communicating IT-systems as on the application level of a medical aid sharing data with a DiGA. The following principles apply:
All flows and interfaces for authorized access to HDDT FHIR resources have been validated for easy implementability using established open-source libraries and tools (HAPI FHIR as FHIR Resource Server and Keycloak for the OAuth2 Authorization Server).
Personal Health Devices store their collected data in a Health Record in the device backend. The Health Record collects measurement data for each patient and acts as a resource server for external parties. It provides interfaces that allow patients and their physicians to access data through mobile apps or other interactive front-end systems.
The HDDT specification is intended to allow manufacturers of backend systems for Personal Health Devices to extend their existing resource servers’ interfaces with HDDT-specific processes and data models in a straightforward way. Ideally, any required adjustments should be limited to the syntax of data exchange, without changes to the core architecture that connects the Personal Health Device, the Personal Health Gateway (e.g. the mobile app that controls the device), and the Health Record. To support this, the specification and its non-functional requirements are based on the following principles:
The HDDT specification follows the reference model of the Continua Health Alliance, which is also adopted by the HL7 Personal Health Device WG. This model defines that a Personal Health Device connects to an Personal Health Gateway (e.g. a mobile app) that serves as a gateway to the Health Record. In HDDT, the Personal Health Gateway and Health Record together are referred to as the Device Data Recorder (see Logical Building Blocks for details). The Device Data Recorder provides the FHIR resource server. A DiGA connects to this server to request and obtain data measured by a connected Personal Health Device.
The Device Data Recorder controls all data and communication flows between the patient’s Personal Health Device and the Health Record on the backend system. The HDDT specification MUST NOT affect this role. The specification also MUST NOT set requirements for:
The HDDT specifications apply to all types of Personal Health Devices and Device Data Recorders. Rules for pairing, authentication, authorization, and logging are the same for all devices and are therefore provided as one common technical specification.
The Mandatory Interoperable Values (MIVs) that a resource server exposes to a DiGA depend on the types of Personal Health Devices connected to it. Each MIV has its own defined data set and rules for exchange. To help manufacturers identify the relevant requirements, the data set for each MIV is defined individually and documented in dedicated sections of the HDDT specification. An overview of the defined MIVs by domain, along with their MIV-specific specification parts, can be found here.
In HDDT, slicing of FHIR attributes is only applied when all slices belong to the same type of data. Domain-specific types of data, such as blood glucose and peak expiratory flow, each always have their own definitions of the FHIR Observation resource type — even if they differ only by LOINC codes and units. This separation ensures that future changes affecting one data type do not impact manufacturers of devices for other domains.
§ 374a SGB V requires that aggregated data MUST also be made available through the HDDT interface. In HDDT, this requirement is limited to aggregated data that can be calculated from the MIVs provided by the medical aid. For example, an rtCGM only MUST provide aggregated values that can be computed from its continuous glucose measurements (MIV - Continuous Glucose Measurement). To reduce the workload for Health Record manufacturers, aggregated data MUST be provided as standardized reports whenever it is calculated over a period of time. A DiGA therefore SHALL NOT request a single metric, such as the number of hypoglycemias, but instead MUST retrieve the full report (e.g. the Ambulatory Glucose Profile (AGP)). Where possible, HDDT adopts existing specifications for such reports unchanged — for rtCGM data, this includes the CGM Summary Observation from HL7 International.
The HDDT specification requires that data be exchanged primarily as FHIR resources. Because FHIR clinical resources are designed for storage and versioning, each resource SHOULD be permanently retrievable under its identifier. In practice, most Health Records linked to Personal Health Devices store data only for a limited time. HDDT therefore states that manufacturers MUST NOT extend existing storage periods solely to comply with the specification. However, every Health Record is assumed to be able to store data for a defined number of days and keep it accessible under a fixed identifier during that period. This period, called the Historic-Data-Period, is defined per MIV based on typical DiGA use cases and is listed in the MIV-specific specification tables in the chapter Mandatory Interoperable Values (MIVS).