§ 374a SGB V requests vendors of medical aids and implants (see Glossary) to provide medical device data for Digitale Gesundheitsanwendungen (DiGA: authorized digital health applications) through a standardized backend API. This API is specified by the Health Device Data Transfer (HDDT) implementation guide, which provides normative definitions for the data transfer itself as well as for accomplishing security services.
Content
The HDDT implementation guide includes requirements for:
Ensuring data interoperability between DiGA and medical aids/implants through interfaces and profiles based on HL7 FHIR
Patient-initiated authorisation of the DiGA to retrieve health data from the utilised medical aid/implant
Management of authorisation by the patient
Retrieval of information necessary for a DiGA to use the interfaces
Retrieval of information necessary for a medical aid/implant to provide the interfaces
Confidential transmission of health data from the medical aid/implant to a DiGA based on a user’s pseudonym
Verifiability of the authenticity of DiGA and medical aid/implants
Evidence and traceability of the operational functionality of the interface
Out-of-Scope for the HDDT implementation guide are:
Identification and authentication of the patient vis-à-vis a DiGA or a medical aid/implant (manufacturer-specific)
Definition of a DiGA/medical aid/implant API for front-ends (manufacturer-specific)
Protection of health data storage or health data processing within a DiGA or a medical device/implant (manufacturer-specific)
About the current version
The current ballot version aims to gather feedback about the technical concept and specificatory aspects from affected medical aid, implant and DiGA manufacturers as well as other stakeholders. The parts describing the pairing mechanism between DiGA and medical aid or implant for authorization and logging are general requirements across all product groups and domains. The interoperable values to be provisioned, however, will be defined per domain. For this ballot version, the domain of Diabetes Self-Management was defined as a first domain to specify data interoperability (see section Methodology). For further information on the status and roadmap for the specification, see Release notes and Roadmap.
The primary audience for this implementation guide are product managers, developers, and architects of manufacturers of medical aids, implants and DiGA.
For developers and architects the following sections of this specification are of particular interest:
The Logical Viewpoints provide a high-level overview of the system architecture and main components.
Section Security and Privacy sketches the security services and mechanisms to be implemented. Further details on specific aspects are give in the sections Pairing and Smart Scopes while the technical specifications are provided in section Authorization Server.
The sections Information Model and Retrieving Data provide logical descriptions of the FHIR-based data model and the RESTful interactions. Technical specifications for these interactions are provided in the section FHIR Resource Server.
The implementation of the data model is through dedicated FHIR profiles and value sets per Mandatory Interoperable Values. The section MIVs lists the Mandatory Interoperable Values defined so far and provides links to the respective FHIR profiles and value sets. An overview of all FHIR profiles and value sets defined in this implementation guide is given in section FHIR Artifacts Summary, where you find examples, too.
Readers who are responsible for project management, product management, or regulatory affairs may find the following sections useful:
The Roadmap describes how the technical specifications will be extended in the future to cover further domains. In addition this sections gives first hints on the regulatory approval process and procedures for product registration.
Certification Relevant Systems describes which products and components are affected by § 374a SGB V and MUST implement the services as defined in this specification.
Section Security and Privacy defines trust anchors and security objects that MUST be provided by the manufacturers of medical aids, implants, and DiGA.
Operational Requirements describe the operational procedures and service levels that MUST be provided by manufacturers of certification relevant systems.
Contact and feedback
Please submit questions and comments about this implementation guide via our request portaluntil 30.11.2025.
If you do not have access to the request portal and would like to use it, please send us a message to hddt [at] gematik.de with the subject “Portal access”.
Copyrights
This IG is created and maintained by gematik GmbH.
It includes IP covered under the following statements:
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
The HDDT Implementation Guide makes reference to codes from the ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Nomenclature standard. These codes are included under the terms of HL7 International’s licensing agreement with the IEEE. Users of this specification may reference individual codes as part of HL7 FHIR-based implementations. However, the full ISO/IEEE 11073 code system and its contents remain copyrighted by ISO and IEEE.
