...

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 bestehende 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 (ePA) durch den DiGA-Hersteller sowie die Integration der von den Kassen bereitgestellten digitalen Identitäten der Versicherten (GesundheitsID) als verpflichtende Anwendungsfälle fokussiert. 

...

Durch die DiGA-Verordnung (DiGAV) sind DiGA-Hersteller von Digitalen Gesundheitsanwendungen verpflichtet, Daten aus der DiGA auf Wunsch des Nutzers in die elektronische Patientenakte ( ePA) zu  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 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 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).)

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 Nutzer 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 wurden 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. 

...

Schreiben eines DiGA-MIOs/PDF in die ePA des Nutzers

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 Nutzer schreiben.  Die Herausforderung für DiGA-Hersteller besteht darin, die TI-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. 

Image Removed

Berechtigung der Datenübertragung durch den Nutzer

Bevor DiGA-Hersteller überhaupt Daten in die ePA des Nutzers stellen können 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 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 Umsetzungsoptionen des TI-Zugangs) 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 Fachmodule, 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 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)

(3) Dokument einstellen

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.

(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. Diese muss vom DiGA-Hersteller persistiert werden, da aktuell kein lesender Zugriff möglich ist (vgl. A_23131 in gemILF_PS_ePA Kapitel 6.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.

...

Gemäß der Verordnung über Digitale Gesundheitsanwendungen (DiGAV; §6 Absatz 1) sind Hersteller von DiGAs dazu verpflichtet, Daten aus der DiGA auf Anforderung des Nutzers in die ePA zu übertragen. Wenn der Nutzer seine Zustimmung gibt, können behandelnde Gesundheitsdienstleister die relevanten DiGA-Daten aus ihrem gewohnten Primärsystem einsehen, ohne eine zusätzliche, DiGA-spezifische Schnittstelle bedienen zu müssen. Die Daten sollten idealerweise in Form eines DiGA-MIO, wie von der mio42 GmbH spezifiziert, in die ePA eingegeben werden, obwohl sie technisch auch als PDF gespeichert 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 Nutzer schreiben.  Die Herausforderung für DiGA-Hersteller besteht darin, die TI-Komponenten in ihre IT-Infrastruktur zu integrieren. Dieses Kapitel soll bei der Umsetzung des Anwendungsfalls unterstützen. 

Über die ePA

Die ePA stellt einen von allen gesetzlichen Krankenversicherungen in Deutschland bereitgestellten Dienst dar. Dieser kostenfreie Service steht den Versicherten frei zur Verfügung, die eigenständig entscheiden können, ob sie ihn in Anspruch nehmen möchten oder nicht. Er ermöglicht den Zugang zu medizinischen Dokumenten und Daten sowohl für Patienten als auch für die an der Behandlung beteiligten Gesundheitsfachkräfte. Dadurch wird eine umfassendere Wissensgrundlage für alle Beteiligten geschaffen, die die Diagnostik verbessert und eine gezieltere Planung von Behandlungen und medizinischen Eingriffen ermöglicht. Zudem verfolgt die ePA das Ziel, die Autonomie der Patienten zu stärken, indem diese verstärkt in Entscheidungsprozesse einbezogen werden und sich aktiv an die vereinbarten Behandlungspläne halten. Da der ePA-Dienst auf den Spezifikationen der gematik basiert und sämtliche ePA-Produkte von dieser geprüft und zugelassen werden, gewährleisten standardisierte APIs und Funktionalitäten die Interoperabilität. Der Dienst ermöglicht eine bundesweite, sektorenübergreifende Nutzung und unterstützt eine institutionsübergreifende, asynchrone und nicht-direktive Kommunikation. Die Architektur der ePA wird in der nachfolgenden Illustration vereinfacht dargestellt. Die derzeit aktive Version der ePA ist 2.6.

Image Added

Nach derzeitiger Rechtslage wird die ePA im Opt-in-Verfahren angeboten, was bedeutet, dass Versicherte  aktiv ihre Krankenversicherung kontaktieren müssen, um eine ePA zu beantragen UND ihr Smartphone für die Nutzung der ePA registrieren ODER einen Leistungserbringer aufsuchen müssen, um das Akten-System nach Eingabe der PIN ihrer elektronischen Gesundheitskarte (eGK) aktivieren zu lassen. Zudem ist es erforderlich, dass Versicherte einem Leistungserbringer dokumentenspezifischen Zugriff auf ihre ePA gewähren, um das Lesen und Schreiben von Dokumenten zu ermöglichen. Mit dem Gesetz zur Beschleunigung der Digitalisierung im Gesundheitswesen (Digital-Gesetz, DigiG) wird das Bereitstellungsmodell auf ein Opt-out-Verfahren umgestellt, das am 15. Januar 2025 in Kraft tritt. Dieses Modell sieht vor, dass Versicherte automatisch eine ePA erhalten, Leistungserbringer ohne Eingabe einer PIN mit der ePA interagieren können, sobald der Patient seine eGK vorlegt, und dass eine ausgewählte Anzahl gesetzlich vorgeschriebener Dokumente vom Leistungserbringenden in die ePA eingestellt werden muss - es sei denn, der Versicherte dies widerspricht. Die kommende Version der ePA wird die Version 3.0 sein, die wesentliche architektonische Änderungen mit sich bringt.

Im Laufe des Jahres 2024 wird dieser Leitfaden aktualisiert, um die Änderungen und die daraus resultierenden Implikationen aus der Sicht eines DiGA-Anbieters zu reflektieren. Für weitere Informationen und Updates bezüglich ePA 3.0 besuchen Sie bitte unsere Ressourcen auf GitHub unter: Link.

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. 

Image Added

Berechtigung der Datenübertragung durch den Nutzer

Bevor DiGA-Hersteller überhaupt Daten in die ePA des Nutzers stellen können 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 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 Umsetzungsoptionen des TI-Zugangs)  den DiGA-Hersteller in den Verzeichnisdienst der Telematikinfrastruktur eingetragen hat. Dies passiert unmittelbar nach Ausgabe der SMC-B DiGA und Aktivierung der Karte durch 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 Fachmodule, 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 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)

(3) Dokument einstellen

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 DiGA-MIOs (Link) sowie eines U-Heft-MIOs auf GitHub (Link). 

(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. Diese muss vom DiGA-Hersteller persistiert werden, da aktuell kein lesender Zugriff möglich ist (vgl. A_23131 in gemILF_PS_ePA Kapitel 6.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

Anchor
TI-Zugang TI-Zugang

Wie zuvor beschrieben ist es für den ePA-Anwendungsfall notwendig, dass sich DiGA-Hersteller mit TI-Zugangskomponenten ausstatten. Konkret müssen folgende Komponenten für den TI-Zugang zusammenspielen:

• SMC-B DiGA: Physische Institutionskarte, die den DiGA-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. 

Image Added

TI-as-a-Service Anbieter hosten Konnektor(en) und sichern den Betrieb für den DiGA-Hersteller. Dieser spricht die für die TI-Anwendungsfälle notwendigen Konnektorschnittstellen über eine sichere VPN-Verbindung an. Hersteller zahlen in diesem Modell meist eine einmalige Anschlussgebühr und eine monatliche Pauschale. Die Einbettung der SMC-B in diesem Modell sollte mit dem TI-as-a-Service Anbieter individuell in Abhängigkeit der individuellen IT-Infrastruktur des DiGA-Herstellers abgestimmt werden.

SMC-B-Herausgabe

Eine Beantragung der SMC-B DiGA ist erst möglich, nachdem die DiGA erfolgreich im DiGA-Verzeichnis gelistet wurde. Nach § 351 Abs. 3 SGB V ist die gematik Kartenherausgeber für SMC-B DiGA. DiGA-Hersteller können SMC-Bs über das Antragsportals der d-trust als Kartenanbieter der gematik beantragen (Link). Das BfArM wird gegenüber der gematik bestätigen, dass der Antragssteller berechtigt ist, eine SMC-B zu erhalten. 

Es ist wichtig zu beachten, dass für jede DiGA, die im Verzeichnis gelistet ist, eine separate SMC-B aus folgenden Gründen bestellt werden muss:

1. Der Nutzer muss in der Lage sein, die ePA-Schreibberechtigung (und perspektivisch auch die Leseberechtigung) für jede DiGA individuell zu vergeben.
2. Bei Bedarf, zum Beispiel wenn eine DiGA des Herstellers aus dem Verzeichnis entfernt wird, muss jede SMC-B einer DiGA separat gesperrt werden können.

 Für Testzwecke stellt die gematik jedoch spezielle Testkarten zur Verfügung, die über das Fachportal der gematik oder über Ihren Enabler bestellt werden können – auch vor einer offiziellen Listung als DiGA im Verzeichnis (Link).

...

Wie zuvor beschrieben ist es für den ePA-Anwendungsfall notwendig, dass sich DiGA-Hersteller mit TI-Zugangskomponenten ausstatten. Konkret müssen folgende Komponenten für den TI-Zugang zusammenspielen:

• SMC-B DiGA: Physische Institutionskarte, die den DiGA-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. 

Image Removed

TI-as-a-Service Anbieter hosten Konnektor(en) und sichern den Betrieb für den DiGA-Hersteller. Dieser spricht die für die TI-Anwendungsfälle notwendigen Konnektorschnittstellen über eine sichere VPN-Verbindung an. Hersteller zahlen in diesem Modell meist eine einmalige Anschlussgebühr und eine monatliche Pauschale. Die Einbettung der SMC-B in diesem Modell sollte mit dem TI-as-a-Service Anbieter individuell in Abhängigkeit der individuellen IT-Infrastruktur des DiGA-Herstellers abgestimmt werden.

Ab Herbst 2023 wird es eine neue Zugangsart in Form eines TI-Gateways geben, mit der DiGA-Hersteller analog zum TI-as-a-Service Angebot auf die Einbindung eines eigenen physischen Konnektors verzichten können (Link).

SMC-B-Herausgabe

Nach § 351 Abs. 3 SGB V ist die gematik Kartenherausgeber für SMC-B DiGA. DiGA-Hersteller können SMC-Bs über das Antragsportals der d-trust als Kartenanbieter der gematik beantragen (Link). Das BfArM wird gegenüber der gematik bestätigen, dass der Antragssteller berechtigt ist, eine SMC-B zu erhalten. Eine Beantragung der SMC-B DiGA ist erst nach erfolgreicher Listung im DiGA-Verzeichnis möglich. 

Anchor
testmoeglichkeiten testmoeglichkeiten

Testmöglichkeiten/-angebote 

...

Für die ePA-Tests in der RU wird unter anderem eine Test-Versichertenkarte (eGK) und eine Test-Institutionskarte (SMC-B) benötigt.  Beide Testkarten können über einen Enabler bezogen werden. 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

Die gematik bietet regelmäßig sogenannte Connectahons an, in denen DiGA-Hersteller in der Referenzumgebung Ende-zu-Ende Anwendungsfälle mit Aktensystemherstellern und Kassen testen können. Weitere Informationen und Anmeldemöglichkeiten sind hier zu finden.  für die Institutionskarte erteilen lassen. Weitere Informationen zu RU-as-a-Service(-Anbietern) finden Sie hier. 

Anchor
digamiotoolkit digamiotoolkit

DiGA MIO Toolkit

...

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  Seit Dezember 2023 wird wurde sukzessive eine sogenannte Föderation aus sektoralen Identity Providern (IDP) nach dem Standard OpenID 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 TI-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. 

...

Wie auf der verlinkten Seite dargestellt, ist es für einige Integrationstest notwendig, den Authorization-Server der DiGA in der TI-Föderation zu registrieren. Nur so wird der Fachdienst als Teilnehmer der Föderation von allen sektoralen IDPs in der Föderation erkannt.  Details zur Registrierung in der Test- bzw. Referenzumgebung sind ebenfalls in der IDP-Wissensdatenbank zu finden: Registrierung eines Fachdienstes in der TI-Föderation (für die Testumgebung (TU) und/oder Referenzumgebung (RU)).  

Wie ebenfalls auf Fachdienste Test-Umgebungen beschrieben befindet sich die Referenzimplementierung des gematik sektoralen IDP in einem eingeschränkt zugänglichen Netz der gematik. Aus dem Grund muss die Outbound-IP des DiGA-Herstellers auf der Allowlist der gematik stehen oder alternativ muss vom DiGA-Hersteller ein X-Auth-Header in seinem Request verwendet werden. Dieser wird von der gematik auf Anfrage an diga@gematik.de kommuniziert.

Kann ein von einem sektoralen IDP ausgestelltes ID-Token erfolgreich entschlüsselt werden, so wurde der Authentisierungsprozess in der Testumgebung auch erfolgreich durchlaufen.  Die Die finalen Tests sollten nicht gegen den gematik sektoralen IDP mit dessen GSIA-App sondern gegen einen von der gematik zugelassenen sektoralen IDP und dessen Authenticator-App in der Testumgebung ausgeführt werden. Da sich die sektoralen IDPs der Kassen noch in der Zulassung befinden, sind noch nicht alle sektoralen IDPs der Kassen in der Testumgebung registriert. Auch ist es aktuell werden. Aktuell ist es noch nicht möglich, Zugang zu den Authenticator-Apps der IDP-Anbieter zu bekommen. Weitere Informationen hierzu folgen. 

...

2. Bestätigung als DiGA in der TI-Föderation durch die gematik

Sobald DiGA-Hersteller die GesundheitsID erfolgreich getestet haben und einen ID-Token abgerufen haben, müssen

...

sie von der gematik als DiGA in der TI-Föderation bestätigt werden. Gemäß

...

§ 327 SGB V bedarf es einer Bestätigung durch die gematik, wenn Komponenten bzw. Produkte der Telematikinfrastruktur durch weitere Anwendungen genutzt werden. Ziel ist es, auf diese Weise sicherzustellen, dass die Hersteller die von der gematik spezifizierten Anforderungen erfüllen und während der Laufzeit der Bestätigung

...

aufrechterhalten. Der gesamte Bestätigungsprozess von der Antragstellung bis zum Ausstellen des Bestätigungsbescheids ist detailliert unter folgendem Link zu finden, unter "Digitale Gesundheitsanwendungen (DiGA) → Verfahrensbeschreibung Bestätigung Digitale Gesundheitsanwendungen".

Die Anforderungen, die ein DiGA-Hersteller erfüllen muss, werden gebündelt in einem Anwendungssteckbrief dargestellt. Dieser wartet aktuell noch auf Freigabe durch den Gesellschafterkreis der gematik und wird zeitnah mit allen weiteren Informationen zur Beantragung, zu anfallenden Gebühren und zum Ablauf des Bestätigungsverfahrens veröffentlichtbefindet sich unter dem folgenden Link, unter "Digitale Gesundheitsanwendungen (DiGA) → Anwendungssteckbrief Digitale Gesundheitsanwendungen". Die Nachweise über die erfüllten Anforderungen werden müssen die DiGA-Hersteller über Eigenerklärungen im Zuge des Bestätigungsverfahrens liefern müssen. Die gematik selbst wird keine Implementierungen der DiGA-Hersteller testen.   Informationen hierzu werden hier im Leitfaden ergänzt, sobald sie verfügbar sindAb sofort können Anträge auf Bestätigung über das digitale Antragsportal der gematik gestellt werden. Es wurde eine Gebühr von 500€ pro DiGA für das Bestätigungsverfahren festgelegt (siehe "Gebührenübersicht → Bestätigungsverfahren DiGA"). 

3. Nachweis der erfolgreichen Integration der GesundheitsID gegenüber dem BfArM

In Abstimmung mit dem BfArM soll die  Die von der gematik in Schritt 2  ausgestellte Bestätigung dem BfArM als Nachweis der Implementierung der GesundheitsID dienen. Das BfArM wird einen Übergangszeitraum in 2024 definieren, in dem der Nachweis beim BfArM eingereicht werden soll. Die gematik steht hier im engen Austausch mit dem BfArM, um den DiGA-Herstellern ausreichend Zeit für die Implementierung zu gewähren. Weitere Informationen hierzu wird das BfArM zeitnah veröffentlichen2 ausgestellte Bestätigung dient dem BfArM als Nachweis der Implementierung der GesundheitsID. Bis zum 30.04.2024 müssen DiGA-Hersteller das Bestätigungsverfahren der gematik für die Nutzung von Komponenten bzw. Produkten der Telematikinfrastruktur erfolgreich durchlaufen haben und die Bestätigung beim BfArM einreichen (siehe Link). Dies gilt ebenfalls für bereits gelistete DiGAs. 

4. Registrierung der DiGA in der in der produktiven TI-Föderation nach erfolgreicher Listung im DiGA-Verzeichnis

Nachdem (angehende) DiGA-Hersteller dem BfArM die erfolgreiche Integration der GesundheitsID über die von der gematik ausgestellte Bestätigung nachgewiesen haben, werden Sie sie im DiGA-Verzeichnis gelistet - vorausgesetzt, alle weiteren Anforderungen des BfArMs sind erfüllt. Nach erfolgreicher Listung kann der DiGA-Hersteller in der (produktiven) TI-Föderation registriert werden. Da die sektoralen IDPs der Kassen erst ab Januar ausgerollt werden, wird eine Registrierung von DiGA in der TI-Föderation auch erst ab Januar möglich sein. Dieses Vorgehen ist mit dem BfArM abgestimmt. Weitere Informationen zum Registrierungsantrag folgen zeitnahListung kann der DiGA-Hersteller in der produktiven TI-Föderation registriert werden. Der Hersteller muss das BfArM innerhalb von 6 Wochen nach Zustellung des Genehmigungsbescheids über die Aktivierung der SMC-B sowie die erfolgreiche IDP-Registrierung informieren. Falls die DiGA bereits gelistet ist, muss dies 6 Wochen nach Einreichung der gematik-Bestätigung erfolgen (siehe Link). Weitere Informationen zur Registrierung von DiGAs in der PU werden zeitnah bereitgestellt.