Inhalte

Hersteller von Digitalen Gesundheitsanwendungen (DiGA) müssen zukünftig unterschiedlichen Verpflichtungen im Kontext der Telematikinfrastruktur (TI) nachkommen. Der vorliegende Leitfaden soll DiGA-Hersteller bei der Umsetzung der TI-Anwendungsfälle unterstützen, indem alle notwendigen Informationen gebündelt und übersichtlich bereitgestellt werden. Er soll insbesondere:

• die TI-Anwendungsfälle und deren Umsetzung durch DiGA-Hersteller detailliert beschreiben,
• über DiGA-relevante Spezifikationsdokumente der gematik,
• über die bestehenden Möglichkeiten der Einrichtung eines Zugangs zur Telematikinfrastruktur und
• über bestehende Möglichkeiten/Angebote, die TI-Anwendungsfälle zu testen aufklären.

Nach einem Überblick aller TI-Anwendungsfälle im DiGA-Kontext wird das Einstellen von DiGA-Daten in die elektronische Patientenakte durch den DiGA-Hersteller sowie die Integration der digitalen von den Kassen bereitgestellten digitalen Identitäten der Versicherten (GesundheitsID) als verpflichtende Anwendungsfälle fokussiert. 

Das TI-Ökosystem im Kontext Digitaler Gesundheitsanwendungen 

Durch die DiGA-Verordnung (DiGAV) sind Hersteller von Digitalen Gesundheitsanwendungen verpflichtet, Daten aus der DiGA auf Wunsch des Nutzenden in die elektronische Patientenakte (ePA) zu übertragen. Sofern der Nutzende den behandelnden Leistungserbringer zur Einsicht in die ePA berechtigt hat, kann der Leistungserbringer die versorgungsrelevanten DiGA-Daten aus seinem vertrauten Primärsystem einsehen, ohne eine DiGA-spezifische Schnittstelle bedienen zu müssen. Die Daten sollen in Form eines von der mio42 GmbH spezifiziertem DiGA-MIOs in die ePA eingestellt werden, können aber technisch auch in Form eines PDFs abgelegt werden. Da das Einstellen von Daten in die ePA aus dem DiGA-Backend heraus aktuell nur über einen Zugang zum geschlossenen Netz der TI, also über einen Konnektor in Verbindung mit einer sogenannten SMC-B DiGA (Smartcard, die einen Teilnehmer der TI eineindeutig identifiziert) möglich ist, müssen sich DiGA-Hersteller für die Umsetzung dieses Anwendungsfalls mit den entsprechenden Komponenten ausstatten. 

DiGA-Hersteller sind zudem verpflichtet die Anmeldung an der DiGA über die von den Kassen bereitgestellten digitalen Identitäten der Versicherten (GesundheitsID) zu ermöglichen. Die GesundheitsID soll ein zentraler Zugang zu Anwendungen im Gesundheitswesen werden, indem sogenannte Identity Provider der Kostenträger die sichere Authentifizierung der Nutzer für die Anwendung übernehmen.  DiGA-Hersteller müssen durch die DiGA-Verordnung jene hohen Sicherheitsanforderung in Bezug auf die Nutzerauthentifizierung erfüllen und dies zukünftig durch das Vorlegen eines Datensicherheitszertifikats nachweisen. Die Identity Provider der Kostenträger erfüllen die höchsten Sicherheitsanforderungen in Bezug auf die Identifizierung und Authentifizierung der Nutzenden und liefern DiGA-Herstellern gesichert die für das Schreiben in die ePA notwendige Krankenversiherungsnummer (KVNR). Das Anlegen einer GesundheitsID ist für Versicherte allerdings freiwillig, sodass DiGA-Hersteller zusätzlich eigene Authentifizierungsverfahren implementieren müssen (siehe hierzu Kapitel 3.4.4 "Identifizierung und Authentisierung" des DiPA-Leitfadens (Link).)

Darüber hinaus spezifiziert die gematik in Zusammenarbeit mit dem GKV-Spitzenverband und DiGA-Herstellerverbänden die digitale DiGA-Verordnung. Aktuell müssen die analogen DiGA-Rezepte durch den Nutzenden bei seiner/ihrer Krankenkasse eingereicht werden, um von dieser einen Freischaltcode zu bekommen, der dann in der DiGA eingegeben werden muss. Nach Daten des GKV-Spitzenverbandes von 2022 im Zeitraum September 2020 bis 30. September 2022  knapp 80% der Verordnungen eingelöst. Die digitale DiGA-Verordnung verfolgt das Ziel, den Verordnungs- und Einlöseprozess medienbruchfrei und schnell zu gestalten. Aktuell befindet sich die Verordnung noch in Konzeption und ist daher nicht Teil dieses Leitfadens. 

Da sich DiGA-Hersteller wie beschrieben für das Schreiben von Daten in die ePA mit den entsprechenden Komponenten an die TI anschließen müssen, ist zumindest technisch auch die Voraussetzung für die Nutzung eines TI-Messengers als auch des sicheren Kommunikationsverfahrens KIM gegeben. Hierzu existiert aus Basis der DiGAV aktuell keine Verpflichtung, sodass diese Anwendungsfälle aktuell nicht Teil dieses Leitfadens sind. 

Schreiben eines DiGA-MIOs/PDF in die ePA der nutzenden Person

Die DiGAV verpflichtet die DiGA-Hersteller in §6 Absatz 1, ihr Systeme derart anzupassen, dass die von der digitalen Gesundheitsanwendung verarbeiteten Daten mit Einwilligung des Versicherten in die elektronische Patientenakte des Versicherten  übermittelt werden können. Die von Anbietern der gesetzlichen Krankenkassen und zukünftig auch privaten Krankenversicherungen bereitgestellten ePA-Aktensysteme liegen im geschlossenen Netz der TI. Um auf dieses Netz zuzugreifen, benötigen DiGA-Hersteller eine Institutionskarte (SMC-B DiGA), die den DiGA-Hersteller gegenüber der Telematikinfrastruktur eineindeutig identifiziert und diesen zunächst gemäß § 341 Abs. 2 Nr. 9 SGB V ein reines Schreibrecht gewährt. Diese SMC-B muss über ein Kartenterminal mit einem Konnektor verbunden werden, erst dann kann der DiGA-Hersteller über definierte Schnittstellen des Konnektors Daten in die ePA der Nutzenden schreiben.  Die Herausforderung für DiGA-Hersteller besteht darin, die Komponenten in ihre IT-Infrastruktur zu integrieren. Dieses Kapitel soll bei der Umsetzung des Anwendungsfalls unterstützen. 

Umsetzung des Anwendungsfalls

Für die Umsetzung des Anwendungsfalls sind grundsätzlich zwei Teilschritte notwendig: 

1. Der Nutzer muss zunächst die DiGA in seinem ePA-Frontend zur Datenübertragung berechtigen. Für diesen Teilschritt sind keine Anpassungen der Systeme der DiGA-Hersteller notwendig. 
2. Der DiGA-Hersteller stellt anschließend zyklisch oder anlassbezogen die versorgungsrelevanten DiGA-Daten in Form eines MIOs oder PDFs in die ePA des Nutzers ein. Für diesen Teilschritt sind Anpassungen der Systeme der DiGA-Hersteller notwendig. 

Berechtigung der Datenübertragung durch den Nutzer

Bevor DiGA-Hersteller überhaupt Daten in die ePA des Nutzers stellen kann ist es zwingend notwendig, dass der Nutzer die DiGA zum Schreiben in seine ePA berechtigt. Ohne vorher erteilte Berechtigung durch den Nutzer ist kein Datenupload möglich und die entsprechende Anfrage läuft auf einen Fehler. Die Berechtigung kann durch den Nutzer DiGA-spezifisch im ePA-Frontend oder auch adhoc für DiGA allgemein an einem Kartenterminal in der Leistungserbringerinstitution erteilt werden (Dokumentenkategorie "DiGA" in der ePA, siehe hierzu gemSpec_Dokumentenverwaltung Kap. 5.4 Zugriffsregeln). 

Der Nutzer kann die DiGA erst berechtigen, wenn die gematik als Herausgeber der SMC-B DiGA (siehe Kapitel...) den DiGA-Hersteller in den Verzeichnisdienst der Telematikinfrastruktur eingetragen hat. Dies passiert unmittelbar nach Ausgabe der SMC-B DiGA an den Hersteller. Erst dann kann der Nutzer die entsprechende DiGA in seinem ePA-Frontend finden und die entsprechende Berechtigung erteilen. 

Bei der Berechtigungsvergabe durch den Nutzer wird eine DiGA-spezifischer Ordner im ePA-Aktensystem des Nutzers angelegt, in den die versorgungsrelevanten DiGA-Daten anschließend abgelegt werden können. 

Die beschriebenen Funktionalitäten/Mechanismen sind durch die Aktensystemanbieter und Kostenträger bereits umgesetzt, sodass für diesen Teilschritt keine technischen Anpassungen seitens der DiGA-Hersteller notwendig sind. 

Datenupload

Sofern der Nutzer die DiGA zum Schreiben in seine ePA berechtigt hat und damit der DiGA-spezifische ORdner im ePA-Aktensystem angelegt wurde, kann der DiGA-Hersteller versorgungsrelevante DiGA-Daten in die ePA des Nutzers stellen und/oder ersetzen. Hierzu sind 3 bzw. 4 Schritte erforderlich: 

(1) Aufruf des ePA-Fachmoduls im Konnektor

Konnektoren haben für verschiedene Produkte der Telematikinfrastruktur sogenannte Fachmoudle, die spezifische Funktionalitäten dieser TI-Produkte kapseln. Der erste Schritt, um ein Dokument in die ePA zu stellen ist also der Aufruf des ePA-Fachmoduls im Konnektor. Dazu muss der entsprechende Endpunkt ermittelt werden (vgl. ePA-Implementierungsleitfaden für Primärsysteme  (gemILF_PS_ePA) Kapitel 4.2 Dienstverzeichnisdienst).

(2) Akte des Nutzers finden

Anschließend muss ermittelt werden, bei welchen Aktenanbieter die Akte des Nutzers liegt. Dafür wird eine Anfrage mit der KVNr des Nutzers an den Konnektor gestellt, die den Aktenanbieter (HomeCommunityID) als Antwort zurückliefert. Die HomeCommunityID sollte – solange der Nutzer Daten in die ePA schreiben möchte - mit der KVNR gespeichert werden, um sich die zeitaufwändige Ermittlung der HomeCommunityID bei erneutem Datenupload zu sparen. (vgl. Implementierungsleitfaden Primärsysteme ePA (gemILF_PS_ePA) Kapitel 5.1.1 Aktenanbieter ermitteln,
Referenz-Request auf GitHub: Link)

(3) Dokument einstellen

Mit der Akten-ID (KVNR) und der HomeCommunity sowie der erfolgten Berechtigung durch den Nutzer können nun Dokumente in die ePA gestellt werden. Um ein DiGA-MIO oder ein PDF-Dokument in die identifizierte ePA des Nutzers zu stellen, muss ein Request nach IHE-Standard gem. Kapitel 5.2.1 des Implementierungsleitfaden Primärsysteme ePA an den Konnektor gestellt werden.

Allgemeine Metadaten-Vorgaben lassen sich dem ePA-Datenmodell (gemSpec_DM_ePA) Kapitel 2.1.4 Nutzungsvorgaben für IHE ITI XDS-Metadaten entnehmen. Für DiGA gelten hier die gleichen allgemeinen Vorgaben wie Primärsysteme.

Metadaten-Vorgaben um ein DiGA-MIO auszuweisen befindet sich als Referenz auf GitHub: Link

Referenz-Request für das Einstellen eines MIOs befindet sich ebensfalls auf GitHub: Link

Zeitnah – spätestens sobald die ersten Konnektathons mit DiGA-Herstellern durchgeführt worden sind - werden Referenz-Requests für das Einstellen eines DiGA-MIOs/PDFs auf GitHub veröffentlicht

(4) Dokument aktualisieren/ersetzen

Ein zuvor eingestelltes ePA-Dokument kann ersetzt werden, indem dem unter (3) erforderlichen Request die bestehende DocumentID (DocumentEntry.entryUUID) beigefügt wird. DiGA-Hersteller muss die DocumentID des von ihm eingestellten Dokuments persistieren, da aktuell kein lesender Zugriff  möglich ist.
(vgl. A_23131 in gemILF_PS_ePA Kapitel6.4.4 Daten digitaler Gesundheitsanwendungen). Sofern keine DocumentID mitgegeben wird, wird ein neues Dokument im DiGA-Ordner der ePA des Nutzers abgelegt und die Verantwortung das relevante oder aktuellste Dokument zu öffnen liegt im Primärsystem

Umsetzungsoptionen des TI-Zugangs

Wie zuvor beschrieben ist es für den ePA-Anwendungsfall notwendig, dass sich DiGA-Hersteller mit TI-Zugangskomponenten ausstatten. 

Ansprache von Konnektorschnittsellen

• ØTI-as-a-Service Anbieter hosten Konnektor(en) und sichern den Betrieb
• ØNeue Zugangsart „TI-Gateway“ ab Herbst 2023 im Feld und wird durch TI-as-a-Service Anbieter angeboten

SMC-B-Herausgabe

ØGematik ist Kartenherausgeber für SMC-B DiGA 

ØBestellbar ab Q4 über das Antragsportal der d-trust

ØBeteiligung des BfArM noch in Abstimmung (Authentizität des Antragsstellers etc.)

Testmöglichkeiten/-angebote 

DiGA-Hersteller haben bereits jetzt die Möglichkeit, in der sogenannten Referenzumgebung der TI (RU) den Datenupload in eine ePA zu testen. Es gibt grundsätzlich 2 verschiedene Möglichkeiten Zugang zur RU zu erhalten:

1. Beauftragung eines "Enablers", der Ihnen alle benötigten Komponenten und Dienste, sowie weitere (individuelle) Dienstleistungen für den Zugang zur RU "aus einer Hand" anbietet
2. eigene Beschaffung der benötigten Komponenten und Dienste für den Zugang zur RU (Konnektor, Kartenterminal mit SMC-KT, Testkarten, VPN-Zugang zur RU)

Es wird DiGA-Herstellern empfohlen, den RU-Zugang über einen "Enabler" as a Service zu beziehen, da die eigene Beschaffung und Integration der TI-Zugangskomponenten aufgrund der IT-Infrastruktur der DiGA-Hersteller wesentlich komplexer in der Umsetzung ist. 

RU-as-a-Service (Enabler)

Für die ePA Tests in der RU benötigen Sie unter anderem eine Test-Versichertenkarte (eGK) und eine Test-Institutionskarte (SMC-B).  Beide Testkarten können Sie über einen Enabler beziehen. Ebenso kann der Enabler ein Aktenkonto für die Versichertenkarte anlegen lassen bzw. die Berechtigung für die Institutionskarte erteilen lassen. Weiter Informationen zu RU-as-a-Service(-Anbietern) finden Sie hier. 

Connectathons

Angebot der gematik e2e mit Aktensystemherstellern und Kassen Anwendungsfälle in Referenzumgebung zu testen. Anmeldungen bereits möglich und erster Connectathon mit DiGA-Herstellern werden im April durchgeführt

DiGA MIO Toolkit

Coming Soon

Anmeldung an der DiGA mit der GesundheitsID

Gesetziche Grundlagen

Umsetzung des Anwendungsfalls

• ØAnfrage an IDP-Föderation muss korrekt vom DiGA-Backend gestellt werden (vgl. IDP Wissensdatenbank)
• ØID-Token müssen verarbeitet werden (vgl. IDP Wissensdatenbank)
• ØZur Identifikation der DiGA muss Schlüsselmaterial und weitere Informationen in der IDP bei initialen Registrierungsprozess hinterlegt werden (Entity Statement, vgl. IDP Wissensdatenbank)
• ØOrganisatorischer Registrierungsprozess inkl. Beteiligung des BfArM aktuell noch in finaler Abstimmung

Testmöglichkeiten/-angebote 

• ØTestmöglichkeiten, mit denen DiGA die Anfragen und das Handling des ID-Tokens testen können werden durch die gematik zeitnah bereitgestellt