Du hast eine App entwickelt, die bereits ein Medizinprodukt ist, oder planst eine DiGA von Grund auf neu zu entwickeln? Dann stehst Du vor einer Vielzahl technischer Herausforderungen, die weit über die reine App-Entwicklung hinausgehen. Von der komplexen Backend-Architektur für die Krankenkassen-Abrechnung über sichere Authentifizierungssysteme bis hin zur Integration in die Telematikinfrastruktur – die technischen Anforderungen für eine zertifizierte DiGA sind umfangreich und anspruchsvoll.

Dieser Leitfaden zeigt Dir systematisch auf, welche technischen Komponenten Du für eine erfolgreiche DiGA-Implementierung benötigst und welche regulatorischen Vorgaben dabei zu beachten sind.

Gesetzliche Krankenkassen bezahlen jede verordnete DiGA dem DiGA-Hersteller. Mit privaten Krankenkassen müssen individuelle Verträge ausgehandelt werden. Geprüfte DiGAs werden dann im öffentlichen Verzeichnis des BfArM eingetragen.

DiGAs sind definiert im SGB V § 33a. Anforderungen an DiGAs sind in der DiGAV festgelegt. Zusätzliche Anforderungen des BfArM stehen in den BfArM-DiGA-Prüfkriterien. BfArM prüft und gibt DiGAs frei.

Weitere Anforderungen des BSI nach BSI TR-03161 – DiGAs brauchen eine Zertifizierung nach den BSI Richtlinien.

GKV stellt Definition der API bereit, die von allen Krankenkassen umgesetzt wurde.

Der Ablauf der DiGA-Freischaltung und Abrechnung funktioniert folgendermaßen: Der Freischaltcode wird von Kassen erstellt und steht auf dem Rezept. Der Patient lädt die DiGA im Store runter und gibt in der DiGA den Code ein. Die DiGA lässt den Code über die Kassen API prüfen und gewährt Zugang zur Nutzung. Die API liefert dann den Abrechnungsdatensatz zurück.

Wichtig zu wissen ist, dass Abrechnungsdatensätze über die gleiche API kommen und in einer getrennten Datenbank gespeichert werden müssen. Der DiGA-Hersteller ist verantwortlich, wie oft derselbe Code benutzt werden darf. Ein Code muss separat vom Nutzer-Account gespeichert und nach Freischaltung der DiGA gelöscht werden. Ein Hash des Codes darf gespeichert werden. Das Mapping-Verzeichnis der Krankenkassen-Endpunkte muss regelmäßig quartalsweise aktualisiert werden.

Ergebnis: Du brauchst dafür ein Backend-System mit Datenbanken mit Anbindungen an App und den APIs.

Die DiGA muss einen Benutzeraccount mit Authentisierung haben. Der Account muss pseudonym nutzbar sein und es muss eine Zwei-Faktor-Authentisierung geben.

Die Umsetzung der Authentisierung erfolgt nur per verifizierbarer, zentraler Komponente. Es besteht Protokollpflicht für Ereignisse wie Identifizierung, Authentisierung und Autorisierung. Protokollzugriffe müssen durch Berechtigungsmanagement abgesichert werden. Die Protokolle sind automatisiert auszuwerten, um sicherheitsrelevante Ereignisse zu erkennen bzw. proaktiv zu verhindern. Eine Login-Methode muss ein angemessenes Vertrauensniveau nach BSI TR-03107-1 haben. Weitere Login-Methoden können mit Einwilligung des Nutzers ein niedrigeres Vertrauensniveau haben.

Wichtig zu wissen ist, dass die DiGA keine personenbezogenen Daten vor einem Login preisgeben darf. Das muss besonders bei Passwort-vergessen- oder Registrierungsprozessen beachtet werden.

Ergebnis: Es braucht einen Auth-Service, am besten nach OAuth 2.0 und OpenID Connect Standard.

Der Hersteller muss jederzeit die Benutzereinwilligungen nachweisen können und Änderungen an personenbezogenen Daten protokollieren. Nutzer können per DiGA das Protokoll einsehen und Einwilligungen direkt in der DiGA widerrufen.

Änderungen an AGB oder Datenschutzerklärung müssen mindestens 14 Tage vorher dem Nutzer angekündigt werden und erfordern immer eine erneute Benutzereinwilligung. Ebenso müssen Nutzer 14 Tage vor Ablauf der DiGA-Verordnung darüber informiert werden, dass dann ihre Daten gelöscht werden und sie einen Export machen können.

Ergebnis: Es braucht eine Erinnerungsfunktion, oder Notifications in der App. Es braucht einen Service, um Benutzereinwilligungen im Backend zu speichern und Protokolle bereit zu stellen.

Der Datenexport wird nur in Form eines MIO (Medizinisches InformationsObject) akzeptiert. Die Daten müssen im XML Format sein. MIOs basieren auf dem FHIR-Standard. KBV stellt FHIR Ressourcen-Definition der MIOs bereit.

Die ePA ist nur über die Telematik Infrastruktur (TI) erreichbar. Die Gematik GmbH ist für Spezifikationen von ePA und TI verantwortlich.

Zugang zur TI ist nur mit spezieller Hardware möglich: Konnektor, Kartenterminal und DiGA spezifische SMC-B Karte. Jede DiGA bekommt eine eigene SMC-B ausgestellt, die dauerhaft in ein Kartenterminal eingesteckt werden muss. Der Konnektor bietet SOAP-Schnittstellen an und Software, die den Konnektor anspricht, wird Primärsystem (PS) genannt und muss entsprechende Gematik Anforderungen erfüllen.

Die DiGA muss Benutzern automatische, regelmäßige ePA-Exporte anbieten. Eine DiGA hat grundsätzlich nur Schreibrechte in der ePA. Zum Dokumente aktualisieren muss die Dokument-Id gespeichert werden. Der Benutzer muss in seiner ePA zuerst der DiGA den Zugriff erteilen über das Frontend-des-Versicherten (FdV) also z.B. die ePA-App seiner KK. Um in die ePA zu schreiben, braucht es die Krankenversichertennummer (KVNr), welche DiGAs nur über den GID-Login beziehen dürfen.

Ergebnis: Es braucht eine Implementierung, um Gesundheitsdaten in MIOs umzuwandeln. Es braucht Zugang zur TI-Hardware, kaufen oder als Service mieten. Es braucht eine Implementierung für die Konnektor Schnittstellen, das Primärsystem. Es braucht ein Test-Setup mit Testbenutzer und dessen FdV-App um Export in die ePA zu testen.

Krankenkassen müssen allen Versicherten alternativ zu Gesundheitskarte eine sichere digitale Identität, genannt GesundheitsID (GID) anbieten. DiGAs müssen eine Anmeldung mit der GID ermöglichen.

Die Umsetzung der GID wird von der Gematik betreut. Nutzer-Identifikation und Authentifizierung basiert auf OAuth2.0 + OpenID Connect. Das Identity Management basiert auf dem OpenID Federation Standard und heißt TI-Föderation. Jede Krankenkasse stellt einen Identity Provider Service (IDP) bereit zur Authentifizierung von Versicherten. Jede Anwendung die Versicherte authentisieren lassen will muss einen sog. Fachdienst, was nach OIDC Relying Party (RP) heißt, bereitstellen.

Wichtig zu wissen ist, dass DiGAs die KVNr nur über die GID beziehen dürfen und nur für den ePA-Export benutzen. Diese wird vom Fachdienst/RP bei Anmeldung beim IDP abgefragt, als sog. Claim. Claims müssen bereits im Registrierungsformular des RP eingetragen werden.

Ergebnis: Es braucht einen Web-Service, der als Fachdienst im Kontext der TI-Föderation und als Relying Party im Kontext der OpenID Federation fungiert. Der GID Login muss in der DiGA App umgesetzt werden. Der bestehende Auth-Service für den DiGA-Benutzerlogin muss weiterhin funktionieren und für den GID Login höchstwahrscheinlich angepasst werden.

Wir verfügen über praktische Erfahrung mit TR-03161-konformen Anwendungen und haben bereits ein DiGA-Projekt vollständig nach diesen Standards entwickelt. Diese Expertise ermöglicht es uns, Dich mit fundiertem Know-how zu unterstützen und typische Herausforderungen bereits im Vorfeld zu identifizieren.

Um die Konformität Deiner DiGA zu gewährleisten, unterstützen wir nach einer Einführung in die TR-03161 (falls erforderlich) im Bereich des Anforderungsmanagements, in der Erstellung einer Gap-Analyse, in der Projektplanung sowie in der Umsetzung und Schließung vorhandener Lücken zur TR-03161.