...

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 Nutzers 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 Nutzer und liefern DiGA-Herstellern gesichert die für das Schreiben in die ePA notwendige Krankenversiherungsnummer Krankenversicherungsnummer (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).)

...

Anschließend muss ermittelt werden, bei welchen Aktenanbieter die Akte des Nutzers liegt. Dafür muss eine Anfrage mit der KVNR des Nutzers an den Konnektor gestellt werden, der den Aktenanbieter in Form der sogenannten HomeCommunityID als zurückliefert. Die HomeCommunityID sollte – solange der Nutzer Daten in die ePA schreiben möchte - zusammen mit der KVNR, die gleichzeitig die Akten-ID darstellt, 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)

...

Mit der KVNR (=Akten-ID) und der HomeCommunityID 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 ((gemILF_PS_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 befinden sich als Referenz auf GitHub (Link). Ebenso befindet sich ein Referenz-Request für das Einstellen eines U-Heft-MIOs auf GitHub (Link). Zeitnah werden zusätzlich Referenz-Requests für das Einstellen eines DiGA-MIOs/PDFs auf GitHub veröffentlicht.

...

Ein zuvor eingestelltes ePA-Dokument kann ersetzt werden, indem dem unter (3) erforderlichen Request die bestehende DocumentID (DocumentEntry.entryUUID) beigefügt wird. Diese muss vom DiGA-Hersteller persistiert werden, da aktuell kein lesender Zugriff möglich ist (vgl. A_23131 in gemILF_PS_ePA Kapitel6 Kapitel 6.4.4 Daten digitaler Gesundheitsanwendungen).

...

• SMC-B DiGA: Physische Institutionskarte, die den DiGA-HErsteller Hersteller gegenüber der TI identifiziert und dieses zum Schreiben in die ePA berechtigt
• Kartenterminal: Träger der SMC-B
• Konnektor: Physische Komponente, die im Zusammenspiel mit Kartenterminal und SMC-B Zugangs- und ePA-Funktionalitäten kapselt. 

Ansprache von Konnektorschnittsellen

Aktuell gibt es am Markt zwei Möglichkeiten einen TI-Zugang zu realisieren. Zum kann ein Hersteller in einer von Ihm verantworteten Umgebung ein Einbox-Konnektor betreiben, der mit einer SMC-B in einem Kartenterminal kommuniziert. Die andere - und für DiGA-Hersteller aufgrund Ihrer IT-Infrastruktur in der Regel komfortablere - Option ist, den TI-Anschluss über einen TI-as-a-Service Anbieter zu realisieren. 

...

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 Eigene Beschaffung der benötigten Komponenten und Dienste für den Zugang zur RU (Konnektor, Kartenterminal mit SMC-KT, Testkarten, VPN-Zugang zur RU)

...

Ab dem Januar 2024 müssen DiGA eine Anmeldung über die von den Kostenträgern bereitgestellten digitalen Identitäten (GesundheitsID) anbieten. In der Anlage 1 zur DiGAV ist dies in der Kategorie Datensicherheit als Punt 15a festgeschrieben. Ab Mitte 2023 wird sukzessive eine sogenannte Föderation aus sektoralen Identity Providern (IDP) nach dem Standard OpenID Connect Connect aufgebaut. Die sektoralen IDPs verwalten den gesamten Lebenszyklus der Identitäten der Versicherten und stellen nach erfolgreicher Authentisierung des Versicherten Identitätsbestätigungen gegenüber Anwendungen wie DiGA aus. DiGA-Hersteller können also den Nutzer zur Authentifizierung an die IDP-Föderation delegieren und erhalten nach erfolgreicher Authentifizierung ein DiGA- und nutzerspezifisches Pseudonym oder -ausschließlich für das Schreiben versorgungsrelevanter DiGA-Daten in die ePA des Nutzers - die KVNR. 

Die Nutzerverwaltung und -autorisierung ist kein Leistungsmerkmal der IDP-Föderation und bleibt in der Verantwortung des DiGA-Herstellers. 

Weitere Informationen zur IDP-Föderation sind in der IDP-Wissensdatenbank der gematik zu finden (Link).

Umsetzung des Anwendungsfalls

...