Der technische Leitfaden für DiGA-Hersteller: Von der Krankenkassen-Abrechnung bis zur ePA-Integration
Autorin: Alexandra Heuel Project Manager bei BAYOOMED
Du hast eine App entwickelt, die bereits ein Medizinprodukt ist – oder planst, eine DiGA von Grund auf neu zu bauen? Dann beginnt jetzt der anspruchsvollste Teil: die Umsetzung.
Denn eine DiGA ist kein klassisches Softwareprodukt. Neben der eigentlichen Anwendung brauchst Du eine belastbare Backend-Architektur, sichere Authentifizierung, saubere Datenprozesse, Schnittstellen zu Krankenkassen und – perspektivisch – die Anbindung an die Telematikinfrastruktur.
Dieser Leitfaden zeigt Dir, welche technischen Bausteine relevant sind, wie sie zusammenhängen und worauf Du in der Praxis achten solltest.
Warum eine DiGA entwickeln?
Wird eine DiGA von einem Arzt verordnet, übernehmen gesetzliche Krankenkassen die Kosten und vergüten diese direkt an den Hersteller. Bei privaten Krankenversicherungen erfolgt die Erstattung auf Basis individueller Verträge. Voraussetzung dafür ist jedoch immer: Die DiGA muss zuvor erfolgreich geprüft und in das offizielle Verzeichnis des BfArM aufgenommen worden sein.
Das DiGA-Verfahren gilt als eines der fortgeschrittensten Erstattungsverfahren für digitale Gesundheitsanwendungen in Europa. Für Hersteller eröffnet es die Chance, Versorgung zu verbessern und zugleich einen klar definierten kommerziellen Zugangsweg in das Gesundheitssystem zu nutzen.
Rechtliche Grundlagen für DiGA
Die rechtliche Grundlage für DiGA findet sich in § 33a SGB V. Weitere Anforderungen sind in der DiGAV geregelt. Ergänzend sind die BfArM-Prüfkriterien sowie die öffentlichen Informationen des BfArM relevant.
Eine wichtige Orientierung bietet außerdem der DiGA-Leitfaden des BfArM.
Das BfArM prüft eine DiGA und nimmt sie in das Verzeichnis auf, wenn die festgelegten Voraussetzungen erfüllt sind.
Anforderungen an Hersteller
Neben den Anforderungen an die Anwendung selbst müssen auch Hersteller bestimmte formale Voraussetzungen erfüllen. Dazu gehört insbesondere ein Qualitätsmanagementsystem nach ISO 13485. Außerdem muss der Hersteller ein Informationssicherheitsmanagementsystem mit Zertifizierung nach ISO 27001 oder nach ISO 27001 auf Basis von IT-Grundschutz nachweisen. Das BfArM verlangt für DiGA seit dem 1. April 2022 ein entsprechendes ISMS-Zertifikat des Herstellers; für den Nachweis der Datensicherheit der Anwendung ist seit dem 1. Januar 2025 zudem ein Zertifikat auf Basis der TR-03161 erforderlich.
Informationssicherheit: Warum die TR-03161 für DiGA wichtig ist
Ein zentraler Bestandteil jeder DiGA ist die Informationssicherheit. Die BSI TR-03161 definiert Anforderungen an den Schutz sensibler Gesundheitsdaten – etwa in Bezug auf Authentifizierung, Verschlüsselung und sichere Datenverarbeitung.
Für die Aufnahme in das DiGA-Verzeichnis muss der Hersteller mittels eines Zertifikats des BSI nachweisen, dass die relevanten Sicherheitsanforderungen umgesetzt wurden. Ziel dieser Anforderungen ist es, Patientendaten wirksam zu schützen und die vertrauenswürdige Nutzung digitaler Gesundheitsanwendungen sicherzustellen.
Wie die Prüfung typischerweise abläuft
Die Prüfung erfolgt über anerkannte Prüfstellen wie PwC, TÜV Informationstechnik oder Secuvera.
Für die Planung wichtig:
- Vorlaufzeit für Prüfstellen: erfahrungsgemäß mehrere Monate
- Prüfung selbst: strukturierter Prozess mit Prüfbericht und ggf. Nachbesserungen
Nach erfolgreicher Prüfung wird das Ergebnis an das BSI übermittelt und das Zertifikat ausgestellt.
👉 Wichtig für Dich: Die Sicherheitsanforderungen betreffen nicht nur einzelne Funktionen, sondern die gesamte Architektur – insbesondere Authentifizierung, Logging und Datenverarbeitung.
Womit solltest Du anfangen?
Bevor Du in einzelne Komponenten gehst, ist eine Frage entscheidend:
👉 Welche Systeme musst Du von Anfang an mitdenken?
In der Praxis zeigt sich:
- Backend & Auth sind immer notwendig
- Abrechnung ist zwingend für den Betrieb
- Einwilligungsmanagement ist regulatorisch kritisch
- TI/ePA/GID sind abhängig vom Use Case, aber früh mitzudenken
👉 Der größte Fehler: zu spät mit Backend, Sicherheit und Prozessen anfangen.
Die technische Zielarchitektur einer DiGA
Eine DiGA besteht in der Praxis aus mehreren spezialisierten Systemen:
- Backend (Daten, Logik, APIs)
- Authentifizierungsservice
- Einwilligungs- und Protokollsystem
- Abrechnungssystem
- optional: TI-/ePA-/GID-Integration
- Monitoring & Sicherheitsinfrastruktur
Die folgenden Bausteine bilden die Grundlage.
Backend-Architektur und Core-Services
Krankenkassen-Abrechnung
Für die Abrechnung stellt die gesetzliche Krankenversicherung eine API-Definition bereit.
Der typische Ablauf:
- Krankenkasse erstellt Freischaltcode
- Nutzer gibt Code in der DiGA ein
- Validierung über Kassen-API
- Zugriff wird freigeschaltet
- Abrechnungsdatensatz wird erzeugt
Wichtig ist dabei:
- Abrechnungsdaten müssen getrennt gespeichert werden
- Freischaltcodes dürfen nicht mit Nutzerkonten vermischt werden
- Der Hersteller definiert die Nutzungslogik der Codes
👉 Praktische Konsequenz: Du brauchst ein Backend mit sauber getrennten Datenbereichen und stabiler API-Anbindung an die Krankenkassen. Weitere Infos zur Abrechnung von DiGA findest du hier.
Authentifizierung und Benutzerverwaltung
Eine DiGA benötigt Benutzerkonten mit sicherer Authentifizierung. Dazu gehören:
- pseudonyme Nutzung
- Zwei-Faktor-Authentifizierung (Welche 2FA Methoden möglich und ausreichend sicher sind, listet das BSI hier)
- zentrale Authentifizierungslogik
- vollständige Protokollierung sicherheitsrelevanter Ereignisse
Vor dem Login dürfen keine personenbezogenen Daten preisgegeben werden – insbesondere bei Registrierung oder Passwort-Reset.
👉 Praktische Konsequenz: Ein zentraler Auth-Service (z. B. auf Basis von OAuth 2.0 / OpenID Connect) ist essenziell.
Einwilligungsmanagement
Der Hersteller muss jederzeit nachweisen können, welche Benutzereinwilligungen vorliegen. Änderungen an personenbezogenen Daten müssen protokolliert werden. Nutzer sollen dieses Protokoll in der DiGA einsehen und Einwilligungen direkt in der Anwendung widerrufen können.
- Änderungen an AGB oder Datenschutzerklärung müssen mindestens 14 Tage vorher angekündigt werden und erfordern eine erneute Einwilligung.
- Nutzer müssen 14 Tage vor Ablauf der DiGA-Verordnung informiert werden, damit sie sich auf Löschung und Export ihrer Daten vorbereiten können.
Praktische Konsequenz: Du brauchst einen Service für die Speicherung und Verwaltung von Einwilligungen, eine revisionssichere Protokollierung sowie eine Erinnerungs- oder Benachrichtigungsfunktion.
Integration in das Gesundheitswesen
Für den Export in die elektronische Patientenakte werden Daten als MIO im XML-Format (FHIR-basiert) übertragen.
Für die Anbindung an die Telematikinfrastruktur ist Zugriff auf entsprechende Komponenten erforderlich, etwa Konnektor, Kartenterminal und eine DiGA-spezifische SMC-B-Karte. Die Kommunikation erfolgt über definierte Schnittstellen, die durch ein sogenanntes Primärsystem angebunden werden.
Beim Export gelten klare Rahmenbedingungen:
- nur Schreibzugriff auf die ePA
- regelmäßige Exporte
- Dokumenten-ID für Updates erforderlich
- Zugriff erst nach Freigabe durch den Nutzer
- KVNr notwendig (über GID)
👉 Praktische Konsequenz: Du brauchst MIO-Konvertierung, TI-Anbindung und ein valides Test-Setup.
Krankenkassen stellen ihren Versicherten alternativ zur Gesundheitskarte eine sichere digitale Identität zur Verfügung: die GesundheitsID (GID). DiGA müssen eine Anmeldung über diese Identität ermöglichen.
Die technische Umsetzung wird durch die Gematik spezifiziert. Nutzeridentifikation und Authentifizierung basieren auf OAuth 2.0 und OpenID Connect. Das zugrunde liegende Identitätsmanagement erfolgt über OpenID Federation und wird im Kontext der Telematikinfrastruktur als TI-Föderation bezeichnet.
Jede Krankenkasse betreibt einen eigenen Identity Provider zur Authentifizierung ihrer Versicherten. Anwendungen, die diese Authentifizierung nutzen möchten, müssen als sogenannter Fachdienst auftreten, der im Sinne von OpenID Connect als Relying Party fungiert.
Die Krankenversichertennummer (KVNR) darf ausschließlich über die GesundheitsID bezogen werden und ist zweckgebunden, etwa für den Export in die elektronische Patientenakte. Die dafür benötigten Claims müssen bereits bei der Registrierung des Fachdienstes hinterlegt werden.
Für die Umsetzung bedeutet das, dass ein eigener Web-Service als Fachdienst innerhalb der TI-Föderation betrieben werden muss. Der GID-Login wird in die DiGA integriert und mit dem bestehenden Authentifizierungssystem verzahnt.
👉 Praktische Konsequenz: Du brauchst einen eigenen Fachdienst und musst den GID-Login sauber in Deine bestehende Authentifizierung integrieren.
Betrieb und Sicherheit
Updates und Wartung
Die DiGA muss beim Start prüfen, ob sicherheitskritische Updates vorliegen. Ist dies der Fall, darf die Anwendung bis zur Installation des Updates keine sensiblen Daten mehr verarbeiten. Dafür ist ein Mechanismus erforderlich, der Updates erkennt und die Nutzung der Anwendung bei Bedarf einschränkt.
Datenmanagement und Grace-Periode
Nach Ablauf der Verordnungsdauer dürfen Nutzerdaten für maximal drei Monate in einer sogenannten Grace-Periode gespeichert bleiben, um eine mögliche Folgeverordnung zu ermöglichen.
Die Speicherung über diesen Zeitraum hinaus setzt eine ausdrückliche Einwilligung des Nutzers voraus. Liegt diese nicht vor, müssen die Daten mit Ablauf der Verordnung gelöscht werden. Nutzer müssen zudem entscheiden können, ob bei einer Folgeverordnung der bestehende Account weiterverwendet oder ein neuer Account angelegt wird. Im Fall eines neuen Accounts ist der bestehende zu löschen.
Darüber hinaus muss die DiGA Funktionen bereitstellen, um Accounts zu sperren, etwa bei Verlust eines Endgeräts, sowie Prozesse zur Wiederherstellung oder Ausgabe neuer Zugangsdaten. Dabei ist sicherzustellen, dass nur der rechtmäßige Nutzer Zugriff erhält.
Monitoring, Protokollierung und Backup
Das Backend einer DiGA benötigt ein zentrales Protokollierungs- und Monitoring-System. Alle relevanten Systemkomponenten müssen Ereignisse erfassen und zentral auswertbar machen. Verdächtige Aktivitäten sollten automatisiert erkannt und entsprechende Alarme ausgelöst werden.
Zugriffe auf diese Systeme müssen durch ein Rollen- und Rechtemanagement abgesichert sein.
Zusätzlich ist ein belastbares Backup- und Wiederherstellungskonzept erforderlich. Dabei müssen insbesondere Szenarien wie ein Ransomware-Angriff berücksichtigt werden. Backups, die personenbezogene Daten enthalten, sind verschlüsselt zu speichern.
Cybersecurity-Anforderungen
Der Umgang mit kryptografischen Verfahren richtet sich nach den Vorgaben der BSI-TR-02102-1 und BSI-TR-02102-2. Zusätzlich sollte die DiGA Zertifikats-Pinning einsetzen, um die Sicherheit der Kommunikationsverbindungen zu erhöhen.
Cybersecurity ist dabei kein isolierter Aspekt, sondern muss durchgängig in Architektur, Betrieb und technische Schutzmaßnahmen integriert werden.
Fazit: Eine DiGA ist ein Gesamtprojekt, keine einzelne App
Die Entwicklung einer DiGA geht weit über die reine Umsetzung einer mobilen oder webbasierten Anwendung hinaus. In der Praxis entsteht eine komplexe Systemlandschaft mit spezialisierten Komponenten für Abrechnung, Authentifizierung, Einwilligungsmanagement, Protokollierung, Integration in die Telematikinfrastruktur, ePA-Anbindung sowie Update- und Sicherheitsmanagement.
Hinzu kommen organisatorische und infrastrukturelle Anforderungen, etwa der sichere Betrieb von Backend-Systemen, der Umgang mit sensiblen Gesundheitsdaten, die Anbindung an Krankenkassen sowie die Vorbereitung auf regulatorische Prüfungen wie die TR-03161.
Wer eine DiGA entwickelt, sollte deshalb frühzeitig ganzheitlich planen – nicht nur Produkt und Nutzererlebnis, sondern auch Architektur, Sicherheit, Compliance, Betrieb und externe Abhängigkeiten.