DiGA in der Telematikinfrastruktur
Patienten haben Anspruch auf die Versorgung mit Digitalen Gesundheitsanwendungen (DiGA), die von der Kassenkasse im Rahmen der Regelversorgung der Gesetzlichen Krankenversicherung erstattet werden. Voraussetzung für die Erstattung ist die Listung im DiGA-Verzeichnis des BfArM, für die seitens des Herstellers verschiedene Nachweise zu Datenschutz, Sicherheit, Interoperabilität und Qualität der DiGA zu führen sind.
Hinsichtlich der technischen Anforderungen an DiGA steht in nächster Zeit ein ganzer Blumenstrauß an gesetzlichen Fristen ins Haus. Neben den neuen Zertifikatspflichten dürfte insbesondere die Anbindung von DiGA an die sich entwickelnde E-Health-Infrastruktur in Deutschland ins Gewicht fallen: ab Mai 2024 müssen DiGA-Hersteller sowohl den Zugang ihrer Systeme zur Telematikinfrastruktur sicherstellen (TI-Anbindung), als auch die sichere Authentisierung des Nutzenden über die von den Krankenkassen bereitgestellten digitalen Identitäten der Versicherten nachweisen (GesundheitsID).
Als Implementierungsnachweis müssen gelistete DiGA-Hersteller ein Bestätigungsverfahren der gematik erfolgreich durchlaufen und einen entsprechenden Nachweis beim BfArM einreichen.
Herausforderung GesundheitsID
Die in § 291 Absatz 8 SGB V geregelte GesundheitsID wird von den gesetzlichen Krankenkassen für deren Versicherte ausgegeben. Hierzu wird üblicherweise ein Identifizierungsverfahren – z. B. mit der eGK oder dem Personalausweis – durchgeführt. Jede gesetzliche Krankenkasse muss seit Anfang 2024 einen Identity Provider und eine Authenticator-App bereitstellen, über die regulierte Anwendungen wie insbesondere der ePA-Client, die eRezept-App und DiGA eine sichere 2-Faktor-Authentifizierung des Versicherten durchführen können. Die Identity Provider der verschiedenen Kassen bilden zusammen mit den zur Nutzung zugelassenen Anwendungen den Vertrauensraum einer sog. Identity Federation.
Die Implementierung der Anbindung einer DiGA an die Dienste zur Authentifizierung mittels GesundheitsID birgt verschiedene Herausforderungen für die Hersteller: über die Kernspezifikation von OpenID Connect werden Mechanismen wie PKCE, PAR und OIDC Federation verwendet, was das Protokoll zur Interaktion der DiGA mit verschiedenen Diensten recht komplex macht. Zur Teilnahme an der Identity Federation der gematik muss jede DiGA neben einem die Schnittstellen der DiGA beschreibenden Entity Statement auch ein JSON Web Key Set mit verschiedenen Schlüsselinformationen erzeugen und bereitstellen.
GesundheitsID als „Black Box“ – Der _fbeta eID-Service
_fbeta bietet für DiGA-Hersteller ein kompaktes Unterstützungspaket zur Implementierung der GesundheitsID per Entwicklerlizenz an, um die erforderlichen Tests in der Referenzumgebung der gematik durchführen und den vom BfArM geforderten Nachweis für die erfolgreiche Authentifizierung mit der GesundheitsID zu erlangen.
Die _fbeta eID-Service wird als lauffähiges Image in einem Docker Container bereitgestellt und kann sowohl in einer Cloud als auch in einem Rechenzentrum per Docker Compose installiert werden. Die Lösung platziert sich zwischen die DiGA, den Federation Master der gematik und die Identity Provider der Kassen. Alle Interaktionen mit dem Federation Master und den Identity-Provider-Diensten der Kassen werden gegenüber der DiGA gekapselt; diese kommuniziert lediglich über das Standard OpenID-Connect-Protokoll mit dem _fbeta eID-Service. Der in der einfachsten Umsetzungsoption (siehe Grafik) als Schnittstelle zur DiGA genutzte Keycloak IAM Server kann in Ergänzung kostenfrei bezogen werden bzw. per Docker Compose gleich mitinstalliert werden. Alternativ kann der DiGA-Hersteller anstelle des vorkonfigurierten Keycloak auch seine bestehende Autorisierungskomponente über ein dokumentiertes RESTful-API an die von _fbeta bereitgestellte Software anbinden. Damit ist es dann z. B. möglich, die Authentifizierung per GesundheitsID auch für bestehende Nutzer-Accounts der DiGA zu nutzen.
Die Containerlösung als Puzzlestück gibt es inklusive Integrations-Workshop, 12-monatiger Wartung, Erstellung des Entity-Statement und weiteren flexibel abrufbaren Unterstützungsleistungen zum Einmalpreis von 10.000 € im Paket. Dieser Preis gilt pro DiGA für eine unbeschränkte Zahl von Nutzern und erlaubt die Einbettung des eID-Service in das DiGA-Backend sowohl für die Test- als auch die Produktivumgebung. Der flexibel an jede beliebige DiGA anbindbare _fbeta eID-Service bietet für Hersteller eine Chance, die neuen Interoperabilitätsanforderungen an DiGA fristgerecht und mit Hinblick auf die weiteren Anforderungen der TI flexibel und zugleich nachhaltig umzusetzen. Eine auf dem _fbeta eID-Service aufsetzende Plug&Play-Library zum Schreiben des DiGA-Exports in die ePA ist in Arbeit und wird durch _fbeta zeitnah bereitgestellt. Auch hier wird es ein Kompaktpaket geben, das neben der Software auch Unterstützungsleistungen bei der Anbindung an die Telematikinfrastruktur über Konnektor bzw. TI-as-a-Service, die Integration der Library in die DiGA und das Durchlaufen der Nachweisverfahren bei der gematik umfasst.
Ansprechpartner:
Dr. Jörg Caumanns
joerg.caumanns@fbeta.de
