§ 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 version 1.0.0-rc2 is the release candidate version with results of the commenting process on the former version 0.1.0-ballot. For information on changes, see release notes.
In addition to the specification of the domain Diabetes Self-Management, which was part of the 0.1.0-ballot version, the current version contains FHIR profiling of the domains Lung Function Testing and Blood Pressure Monitoring (for information about included domains, see also roadmap). The pairing mechanism between DiGA and medical aid or implant for authorization and logging remains steady across domains. Comments with focus on the new domains Lung Function Testing and Blood Pressure Monitoring can be transmitted until 01.04.2026 via our request portal (see Contact and feedback).
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 given 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 section 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 portal.
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
This material includes SNOMED Clinical Terms® (SNOMED CT®) which is used by permission of the International Health Terminology Standards Development Organisation (IHTSDO). All rights reserved. SNOMED CT®, was originally created by The College of American Pathologists. “SNOMED” and “SNOMED CT” are registered trademarks of the IHTSDO.
The HDDT Implementation Guide makes reference to codes from the ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Nomenclature standard. Codes and display texts are adapted and reprinted with permission from IEEE for the sole purpose of producing this specification. Copyright IEEE 2020. All rights reserved.
