GesundheitsID in eine DiGA integrieren: Anforderungen, OIDC-Föderation und der BfArM-Nachweis
Seit Januar 2024 ist es für DiGA-Hersteller verpflichtend, die Authentifizierung ihrer Nutzerinnen und Nutzer über die GesundheitsID zu ermöglichen. Was nach einem überschaubaren „noch-ein-Login-Verfahren" klingt, entpuppt sich in der Praxis als eines der komplexeren Integrationsprojekte auf dem Weg ins DiGA-Verzeichnis – weil dahinter nicht nur ein OAuth-Flow steckt, sondern die gesamte sektorale Identity-Föderation der Telematikinfrastruktur (TI 2.0).
Dieser Artikel erklärt, was die GesundheitsID ist, warum sie Pflicht ist, wie die Integration technisch funktioniert, wo die echten Hürden liegen und wie du den vom BfArM geforderten Nachweis erbringst.
Warum die GesundheitsID für DiGAs Pflicht ist
Die rechtliche Grundlage liegt in § 291 Abs. 8 SGB V in Verbindung mit der DiGA-Verordnung (DiGAV). Demnach müssen DiGA-Hersteller ihre Anwendung so anpassen, dass sich GKV-Versicherte mit einer digitalen Identität – der GesundheitsID – authentisieren können.
Der Hintergrund: Die GesundheitsID ist die digitale Identität der Versicherten in der Telematikinfrastruktur. Sie ersetzt schwächere Verfahren wie SMS-TAN oder reine Passwort-Logins und ermöglicht einen kartenlosen, app-basierten Zugang auf höchstem Sicherheitsniveau. Für DiGAs ist sie außerdem die Voraussetzung, um Daten rechtskonform in die elektronische Patientenakte (ePA) zu schreiben: Über die GesundheitsID lässt sich die Krankenversichertennummer (KVNR) des Patienten anfragen, und ohne diese ist ein ePA-Export nicht möglich.
Kurz: Ohne GesundheitsID-Anbindung gibt es keine Listung im DiGA-Verzeichnis des BfArM – und damit keine Erstattung durch die gesetzlichen Krankenkassen.
Wie die GesundheitsID technisch funktioniert
Die GesundheitsID basiert auf OpenID Connect (OIDC), dem etablierten Industriestandard für Authentifizierung. So weit, so vertraut. Der entscheidende Unterschied zu einem klassischen „Login mit Google" ist die Föderation:
- Die gematik betreibt den zentralen Föderationsmaster, der festlegt, welche Teilnehmer der Föderation vertrauenswürdig sind.
- Die Krankenkassen betreiben jeweils ihre eigenen sektoralen Identity Provider (IDPs), bei denen sich ihre Versicherten authentisieren.
- Deine DiGA ist die Relying Party (der Fachdienst), die einen Login anfragt und am Ende verifizierte Identitätsattribute erhält.
Das bedeutet: Deine App spricht nicht mit einem IDP, sondern muss dynamisch mit vielen IDPs unterschiedlicher Kassen umgehen können – und dem Föderationsmaster gegenüber kryptografisch nachweisen, dass sie ein legitimer Teilnehmer ist.
Die echten Hürden bei der Integration
Hier wird aus „OIDC kennen wir doch" schnell ein mehrwöchiges Spezialprojekt. Die größten Stolpersteine:
Entity Statement und JSON Web Key Set (JWKS)
Jeder Teilnehmer der Föderation muss ein Entity Statement bereitstellen – ein signiertes Dokument, das die eigenen Schnittstellen, Endpunkte und unterstützten Verfahren beschreibt. Dazu kommt ein JSON Web Key Set (JWKS) mit den öffentlichen Schlüsseln, über die deine Signaturen verifiziert werden. Beides muss korrekt erzeugt, gehostet, signiert und aktuell gehalten werden.
Erweiterte OIDC-Mechanismen
Die Föderation nutzt über die OIDC-Kernspezifikation hinaus Mechanismen wie PKCE (Schutz des Authorization Codes), PAR (Pushed Authorization Requests) und OIDC Federation. Genau dieses Zusammenspiel macht das Protokoll deutlich anspruchsvoller als ein Standard-OAuth-Flow – und ist die häufigste Fehlerquelle bei Eigenentwicklungen.
Zertifikats- und Schlüsselmanagement
Vertrauen in der Föderation läuft über kryptografische Zertifikate und Schlüssel, die regelmäßig rotiert und erneuert werden müssen. Ein abgelaufenes Zertifikat bedeutet im Zweifel: Nutzer kommen nicht mehr rein.
Tests in der gematik-Referenzumgebung (RU)
Bevor es produktiv geht, müssen die Authentifizierungs-Flows in der Referenzumgebung (RU) der gematik getestet und nachgewiesen werden. Dafür braucht es einen Zugang zur RU sowie eine App-Version, die gegen die RU-GesundheitsID läuft.
Sich bewegende Spezifikationen
Die gematik-Spezifikationen entwickeln sich kontinuierlich weiter (Stichwort TI 2.0). Wer selbst integriert, muss diese Änderungen dauerhaft nachziehen – Wartungsaufwand, der nach dem Go-Live nicht verschwindet, sondern bleibt.
Der Weg zum BfArM-Nachweis
Für die Aufnahme ins DiGA-Verzeichnis musst du gegenüber dem BfArM nachweisen, dass die GesundheitsID-Authentifizierung funktioniert. Das Prüfverfahren wurde zuletzt auf eine Selbstauskunft umgestellt – der Nachweis wird also stärker in die Verantwortung des Herstellers gelegt, was sauber dokumentierte und reproduzierbare Tests umso wichtiger macht.
Für den produktiven Betrieb und das Schreiben in die ePA kommt zusätzlich die SMC-B DiGA ins Spiel – die Institutionskarte, die nach der Listung im DiGA-Verzeichnis über das d-trust-Portal beantragt werden kann.
Make or Buy: Eigenentwicklung vs. GesundheitsID as a Service
An diesem Punkt steht jedes Produktteam vor derselben Entscheidung: alles selbst bauen oder einen spezialisierten Dienst einbinden?
Eine Eigenentwicklung bedeutet, OIDC-Föderation, Entity-Statement-Erzeugung, JWKS-Hosting, Zertifikatsmanagement und RU-Tests selbst aufzubauen – und anschließend dauerhaft mit jeder gematik-Spec-Änderung mitzupflegen. Das bindet Entwicklerkapazität, die meist besser in die eigentlichen Kernfeatures der DiGA fließt.
Die Alternative ist GesundheitsID as a Service: Ein Dienst kapselt die Komplexität der Föderation hinter einer einfachen OIDC-Schnittstelle. Genau dafür ist azuma mimoto gebaut – die Entity Statements werden automatisch über das Developer-Portal generiert, das Zertifikatsmanagement läuft im Hintergrund, und Spec-Updates der gematik werden nachgezogen, ohne dass du eine Code-Zeile ändern musst. Statt Monate in die Föderation zu investieren, integrierst du einen Standard-OIDC-Flow.
Wer früh testen will, kann das im Simulationsmodus ohne Kosten und ohne RU-Zugang tun und später per Konfigurationswechsel in die Produktion gehen. Die technischen Details findest du im Integration Guide für mimoto.
Schritt für Schritt: So integrierst du die GesundheitsID
Als grobe Orientierung – unabhängig davon, ob ihr selbst baut oder einen Service nutzt:
- Anwendungsfall klären – Reicht reine Authentifizierung, oder soll auch in die ePA geschrieben werden (KVNR-Abruf, SMC-B DiGA)?
- OIDC-Flow integrieren – Authorization-Code-Flow mit PKCE und PAR, abgesichert nach BSI-Vorgaben.
- Entity Statement & JWKS bereitstellen – signiert, korrekt gehostet, mit Rotationsstrategie.
- In der Referenzumgebung testen – Flows gegen die RU-GesundheitsID validieren und dokumentieren.
- BfArM-Nachweis vorbereiten – Selbstauskunft und Testnachweise zusammenstellen.
- Produktiv gehen – SMC-B DiGA beantragen, in den Produktivmodus wechseln, Monitoring aufsetzen.
- Spec-Updates dauerhaft mitführen – oder an einen Dienst auslagern, der das übernimmt.
Häufige Fragen
Ist die GesundheitsID für jede DiGA verpflichtend?
Ja. Seit Januar 2024 müssen DiGA-Hersteller die Authentisierung ihrer Nutzer über die GesundheitsID ermöglichen. Sie ist Voraussetzung für die Listung im DiGA-Verzeichnis und für das Schreiben in die ePA.
Wie lange dauert eine GesundheitsID-Integration?
Bei einer Eigenentwicklung sind mehrere Wochen bis Monate realistisch, weil Föderation, Zertifikatsmanagement und RU-Tests aufgebaut werden müssen. Über einen spezialisierten Dienst mit Standard-OIDC-Schnittstelle ist eine Integration in der Regel in wenigen Tagen machbar.
Was kostet die Integration der GesundheitsID?
Die Kosten variieren stark zwischen Eigenentwicklung und SaaS. Managed-Lösungen für DiGA-Startups starten im niedrigen dreistelligen Bereich pro Monat – deutlich unter dem sechsstelligen Initialaufwand und dem laufenden Wartungsaufwand einer Eigenentwicklung.
Brauche ich für die GesundheitsID auch die ePA-Anbindung?
Nicht zwingend für die reine Authentifizierung – aber wenn deine DiGA Daten in die ePA schreiben soll, brauchst du die über die GesundheitsID abgerufene KVNR sowie eine SMC-B DiGA.
Du baust gerade eine DiGA und willst die GesundheitsID-Integration nicht selbst aufbauen? Hol dir einen kostenlosen Developer-Zugang und teste die Anbindung im Simulationsmodus – oder bespreche deinen konkreten Anwendungsfall mit unserem Team.