HDDT wird häufig als Schnittstellenprojekt verstanden. Tatsächlich entsteht mit HDDT jedoch eine dauerhaft zu betreibende Interoperabilitätsinfrastruktur. Die eigentliche Herausforderung liegt nicht in den FHIR-Profilen selbst, sondern im Zusammenspiel von Identitätsmanagement, Berechtigungen, Pairing, Onboarding und Betrieb. Wer heute mit der Umsetzung beginnt, sollte deshalb nicht nur die Anforderungen der Spezifikation erfüllen, sondern auch von Beginn an Fragen des Deployments und des Betriebs mitdenken.

Die Health Device Data Transfer Specification (HDDT) bildet den konkreten technischen Rahmen für den Datenaustausch zwischen Hilfsmitteln beziehungsweise Implantaten und digitalen Gesundheitsanwendungen (DiGA). Im Zentrum stehen die FHIR-REST-Schnittstellen. Die gematik definiert derzeit vier Mandatory Interoperable Values (MIVs), die jeweils gemäß § 374a SGB V verpflichtend bereitzustellende Gruppen von Hilfsmitteldaten repräsentieren: Blutzuckermessung, kontinuierliches Glukosemonitoring, Lungenfunktion und Blutdruck. Die zu jedem MIV zugehörigen FHIR-Profile und -schnittstellen legen fest, wie und unter welcher Bedingung die von einem Hilfmittel erfassten Messungen strukturiert sind und von DiGA abgerufen werden können.

Wer HDDT technisch betrachtet, könnte deshalb zunächst zu dem Schluss kommen: Hersteller müssen im Wesentlichen ihre vorhandenen Daten nach FHIR übersetzen und einen entsprechenden Endpunkt bereitstellen. Das greift jedoch zu kurz.

Nicht der Datenstandard ist das eigentliche Problem

Ein Hilfsmittelhersteller hat seine Gerätedaten in der Regel bereits in einer eigenen Cloud, einem Backendsystem, einer App-Infrastruktur oder bei einem Plattformanbieter gespeichert, von wo aus sie durch eigene Apps des Herstellers abrufbar sind. Die technische Herausforderung besteht deshalb nicht primär darin, Daten überhaupt digital verfügbar zu machen.

Neu ist, unter welchen Bedingungen Dritte auf diese Daten zugreifen können sollen:

• Eine gelistete DiGA muss beim BfArM beantragen, welche Art von Messdaten sie benötigt. Diese Daten müssen zu ihrer Indikation beziehungsweise ihrem bestimmungsgemäßen Gebrauch passen. Der Hilfsmittelhersteller darf nur diese Daten an die DIGA weitergeben.
• Der Hilfsmittelhersteller muss sicherstellen, dass nur im DiGA-Verzeichnis des BfArM gelistete DiGA Daten abrufen können. Er muss dazu die Identität und Authentizität der DiGA – bzw. ihres Backendsystems – prüfen.
• Die versicherte Person kann den Zugriff nur auf zulässige Arten von Daten autorisieren. Ihre Einwilligung allein macht einen fachlich beziehungsweise regulatorisch nicht vorgesehenen Datentyp noch nicht zulässig.
• Gleichzeitig soll die Identität des Patienten zwischen DiGA und Hersteller nicht offengelegt werden, d. h. beide müssen ein Pairing auf ihren jeweiligen Nutzer-Accounts durchführen, bei dem für den Patienten ein Pseudonym vereinbart wird.

Aus einer klassischen API-Frage wird damit eine Frage des datenschutzkonformen Identitätsmanagements und der Berechtigungssteuerung.

Genau deshalb umfasst HDDT deutlich mehr als FHIR-Schnittstellen. Die Spezifikation regelt unter anderem die patienteninitiierte Autorisierung, den Umgang mit Berechtigungen, die sichere Übertragung über Pseudonyme sowie den Nachweis der Authentizität der beteiligten Systeme.

Pairing verbindet zwei Welten, ohne den Patienten offenzulegen

Ein zentraler Baustein ist deshalb das sogenannte Pairing-Verfahren. Dabei wird für einen bestimmten Patienten eine eindeutige Zuordnung zwischen einer DiGA und dem Backendsystem des Hilfsmittelherstellers  hergestellt. Dabei entsteht eine pseudonyme Pairing-ID, über die beide Systeme den Datenbezug herstellen können, ohne die Patientenidentität systemübergreifend offenzulegen.

Gleichzeitig wird im Pairing festgelegt, auf welche Daten die DiGA zugreifen darf. Die Berechtigungen werden technisch über OAuth2 beziehungsweise SMART Scopes abgebildet.

Auch die DiGA muss vertrauenswürdig identifiziert werden

Hinzu kommt eine zweite Ebene: Bevor überhaupt entschieden werden kann, auf welche Daten eine DiGA zugreifen darf, muss geklärt sein, wer auf die Schnittstelle zugreift.

HDDT sieht dafür gegenseitig authentisierte TLS-Verbindungen (mTLS) vor. Die DiGA authentifiziert sich gegenüber dem Backendsystem, das die Messdaten bereitstellt. Umgekehrt muss sich auch dieser gegenüber der DiGA ausweisen. Dieses gilt übrigens auch, wenn das Backendsystem von einem Dritten, d. h. nicht dem Hersteller eines betroffenen Hilfsmittels selbst, bereitgestellt wird. Dafür werden unter anderem X.509-Zertifikate und die beim BfArM hinterlegten Vertrauensinformationen genutzt. Zusätzlich muss geprüft werden, welche Typen von Messdaten die jeweilige DiGA für ihren bestimmungsgemäßen Gebrauch verarbeiten darf. Diese Informationen werden im Rahmen des DiGA-Zulassungsverfahrens im DiGA-Verzeichnis hinterlegt und bilden die Grundlage für den zulässigen Umfang des Datenzugriffs. Eine DiGA darf daher nur die für sie freigegebenen Typen von Messungen anfragen und die Hilfsmitteldaten vorhaltenden Backendsysteme dürfen nur diesen Umfang bereitstellen.

Damit entstehen zwei getrennte Kontrollfragen:

1. Ist dies tatsächlich eine berechtigte DiGA?
2. Auf welche Daten dieses Patienten darf diese DiGA zugreifen?

Erst das Zusammenspiel aus mTLS und Pairing beantwortet beide.

Der FHIR-Server wird damit zur kontrollierten Datendrehscheibe

Erst dahinter kommt der Teil, der häufig zuerst mit HDDT verbunden wird: der eigentliche Austausch der Gerätedaten.

HDDT basiert auf HL7 FHIR R4. Für die einzelnen MIVs – d. h. Gruppen von Hilfsmitteldaten – legt die Spezifikation Profile, Suchparameter und Interaktionen fest. Hersteller müssen ihre Gerätedaten entsprechend strukturiert bereitstellen.

Die wenigsten Hersteller werden ihre komplette bestehende Datenplattform dafür auf FHIR umstellen wollen. Technisch sinnvoll ist deshalb eine Übersetzungsschicht zwischen vorhandener Infrastruktur und HDDT: Daten aus bestehenden Datenbanken oder proprietären Formaten werden in die benötigten FHIR-Ressourcen überführt, in einer DMZ sicher abgelegt und von dort über die HDDT-Schnittstellen für DiGA bereitgestellt.

Genau diese Aufgabe übernimmt das _fbeta HDDT Gateway. Dieses stellt in einer DMZ einen FHIR-Server und einen Autorisierungsserver bereit, die alle von HDDT geforderten Endpunkte für das Pairing und den Datenabruf implementieren. Zusätzlich übernimmt das _fbeta HDDT Gateway die FHIR-native Speicherung und Transformation der mit den bestehenden Backendsystemen synchronisierten Daten.

HDDT wird so als zusätzliche Interoperabilitätsschicht eingebaut, nicht als Ersatz der vorhandenen Geräteplattform.

Die eigentliche Skalierungsfrage beginnt bei der zweiten DiGA

Damit ist die technische Schnittstelle funktionsfähig. Jedoch ist HDDT keine Schnittstelle, die nach dem Deployment einfach „fertig“ ist. Sie ist vielmehr ein dauerhaft zu betreibender und weiterzuentwickelnder Service. Ein skalierbarer Betrieb muss z. B. sicherstellen, dass neue DiGA gegen die Schnittstellen testen und an der Produktivumgebung registriert werden können. Daher gehört auch eine Onboarding-Umgebung zur technischen HDDT-Architektur. Das _fbeta Onboarding Portal ergänzt das _fbeta HDDT Gateway um genau diese Funktionalitäten. Ziel ist es, die Anbindung neuer DiGA zu standardisieren und vom produktiven Betrieb zu entkoppeln. Dadurch lässt sich der Integrationsaufwand auch bei einer wachsenden Zahl von Anwendungen beherrschbar halten.

Die relevante Architekturentscheidung lautet deshalb nicht nur „Build or Buy?“

Mit HDDT entsteht damit nicht nur eine neue Schnittstelle, sondern eine dauerhaft zu betreibende Interoperabilitätsinfrastruktur.

Für Hersteller stellt sich deshalb eine grundsätzliche Architekturfrage: Welche dieser Funktionen sind für das eigene Produkt tatsächlich differenzierend – und welche sind standardisierte Infrastruktur, die nur Kosten und keine Wettbewerbsvorteile bringen?

Gerätedaten, medizinische Funktionen, Nutzererlebnis und das eigene Backend bleiben Kernbestandteile der Herstellerplattform. Die technische Vermittlung zwischen dieser Plattform und unterschiedlichen DiGA ist dagegen eine Interoperabilitätsaufgabe, die sich standardisieren lässt.

Genau hier setzt das HDDT Gateway von _fbeta an: Es ergänzt bestehende Geräteplattformen um die HDDT-spezifische Integrationsschicht, ohne die vorhandene Infrastruktur zu ersetzen. Das Onboarding Portal erweitert diese Schicht um einen standardisierten Prozess für Test und Anbindung neuer DiGA.

Fazit: Die technische Umsetzung sollte deshalb beim späteren Betrieb beginnen

HDDT wird häufig als Schnittstellenprojekt verstanden. Tatsächlich entsteht mit HDDT jedoch eine dauerhaft zu betreibende Interoperabilitätsinfrastruktur. Die eigentliche Herausforderung liegt nicht in den FHIR-Profilen selbst, sondern im Zusammenspiel von Identitätsmanagement, Berechtigungen, Pairing, Onboarding und Betrieb. Wer heute mit der Umsetzung beginnt, sollte deshalb nicht nur die Anforderungen der Spezifikation erfüllen, sondern auch von Beginn an Fragen des Deployments und des Betriebs mitdenken.

Welche Hersteller heute bereits von § 374a und HDDT betroffen sind, welche Fristen relevant sind und welche Schritte jetzt anstehen, zeigen wir im ersten Teil unserer Reihe: § 374a SGB V und HDDT: Welche Hilfsmittelhersteller jetzt handeln müssen

Unsere HDDT-Artikelreihe

Veranstaltung zu dem Thema: beta_meet am 11. November 2026

Viele der offenen Fragen rund um Betroffenheit, Umsetzung und Roadmap stehen auch im Mittelpunkt unseres nächsten beta_meet

Gemeinsam mit Vertreterinnen und Vertretern aus Bundesgesundheitsministerium, BfArM, Interoperabilitätsexpertise und technischer Umsetzung betrachten wir § 374a und HDDT entlang der gesamten Umsetzungskette: Regulatorischer Rahmen -> Registrierung -> technische Umsetzung -> HDDT-Roadmap -> Perspektiven für die Versorgung

Die Veranstaltung findet bei _fbeta in Berlin statt. Eine digitale Teilnahme ist ebenfalls möglich.

Weitere Informationen und Anmeldung zum beta_meet auf Eventbrite.

Ansprechpartner

 

Vielleicht interessiert Sie auch

• § 374a SGB V: Hilfsmitteldaten als Teil der digitalen Versorgung 
• _fbeta ePA-Client: Eine Open-Source-Lösung für die sichere und einfache Anbindung von DiGA an die ePA für alle
• Die Unangepassten – DiGAs als Chance und Herausforderung für das Gesundheitssystem
• TI-Integration
• Umsetzung regulierter Anwendungen – Das Beispiel „Zentraler Terminologieserver“