You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

se

English Version: Coming soon

Der vorliegende Leitfaden wird iterativ weiterentwickelt Sollten relevante Aspekte und/oder Fragestellungen fehlen, bitten wir um Feedback über folgende Mailadresse: diga@gematik.de 


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 KArankenversiherungsnummer (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 XXX kommen aufgrund der Medienbrüche des aktuellen Prozesses nur XX% der verordneten DiGA auch wirklich via Freischaltcode in die Nutzung. Die digitale DiGA-Verordnung befindet sich aktuell noch in Konzeption und ist aktuell 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 des Nutzenden

Gesetzliche Grundlagen

ePA: DiGA must implement an ePA interface

§ 6a Abs. 1 DiGAV

Digitale Gesundheitsanwendungen sind ab dem 1. Januar 2024 so zu gestalten, dass die von der digitalen Gesundheitsanwendung verarbeiteten Daten mit Einwilligung des Versicherten in die elektronische Patientenakte des Versicherten nach § 341 des Fünften Buches Sozialgesetzbuch übermittelt werden können.

DiGA receives write permissions in ePA, attribute "data from digital health applications"

§ 341 Abs. 2 Nr. 9 SGB V

(2) Es besteht die Möglichkeit zur Einstellung folgender Daten in die elektronische Patientenakte:

9. Daten des Versicherten aus digitalen Gesundheitsanwendungen des Versicherten nach § 33a,

DiGA - ePA interface defined for data exchange

§ 354 Abs. 2 Nummer 6 SGB V

bis zum 1. Januar 2022 die Festlegungen dafür zu treffen, dass Daten der Versicherten aus digitalen Gesundheitsanwendungen nach § 33a vom Hersteller der Anwendungen über den Anbieter der elektronischen Patientenakte über eine Schnittstelle, die den Anforderungen des Zwölften Kapitels genügt, in die elektronische Patientenakte übermittelt und dort verarbeitet werden können, und

ePA: gematik issues components for authentication, BfArM confirms authorization

§ 351 Abs. 3 SGB V

Die Ausgabe der Komponenten zur Authentifizierung der Hersteller digitaler Gesundheitsanwendungen nach § 33a erfolgt durch die Gesellschaft für Telematik. Das Bundesinstitut für Arzneimittel und Medizinprodukte bestätigt, dass ein Hersteller digitaler Gesundheitsanwendungen nach § 33a berechtigt ist, eine Komponente nach Satz 1 zu erhalten.

  • Gesetzliche Verpflichtung, Daten in die ePA zu stellen
  • ePA-Aktensysteme liegen im geschlossenen Netz der TI
  • Dementsprechend werden Komponenten benötigt um auf das Netzt und die Aktensysteme zuzugreifen 

Umsetzung des Anwendungsfalls

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

Berechtigung der Datenübertragung durch den Nutzer

  • ØBerechtigung (Schreibrecht, kein Leserecht) wird durch den Nutzer im ePA-Frontend oder adhoc vergeben (vgl. A_A_19303-04 in gemSpec_Dokumentenverwaltung Kap. 5.4 Zugriffsregeln)
  • ØBerechtigung erfolgt auf Basis der Telematik-ID des DiGA-Herstellers
  • ØTelematik-ID erhält der DiGA-Hersteller mit der SMC-B DiGA, die durch die gematik herausgegeben wird.
  • ØSobald die SMC-B DiGA durch die gematik ausgegeben wurde, wird die DiGA im Verzeichnisdienst durch die gematik als Herausgeber gelistet und Berechtigungen können durch den Nutzer vergeben werden (adhoc Berechtigungen über KTs nur auf Dokumentenkategorie „DiGA“ – über ePA-FdV pro DiGA)
  • ØBerechtigungsfunktionalität durch die Aktensystemanbieter und Kassen bereits umgesetzt
  • ØBei Erteilung der Berechtigung wird ein DiGA-spezifischer Ordner im Aktensystem in der Dokumentenkategorie „DiGA“ erstellt (vgl. A_21512 in gemSpec_Dokumentenverwaltung Kap. 5.1 Dokumentenverwaltung
  • ØOhne vorher erteilte Berechtigung durch den Nutzer ist kein Datenupload möglich! (Anfrage durch das DiGA-Backend läuft auf Fehler)

Datenupload

(1) Aufruf des ePA-Fachmoduls im Konnektor

  • ØUm das ePA-Fachmodul des Konnektors aufzurufen, muss der entsprechende Endpunkt ermittelt werden
    (vgl. Implementierungsleitfaden Primärsysteme ePA (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

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 

RU-as-a-Service

  • ØRU-as-a-Service Anbieter (Enabler) bereits im Feld
  • ØMit Testkonnektoren-as-a-Service können Requests zur Dokumentenanlage in Referenzumgebung getestet werden
  • ØLink zur Übersichtsseite: https://wiki.gematik.de/x/CD3aGQ

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

Anmeldung an der DiGA mit der GesundheitsID

Gesetziche Grundlagen

Digital Identities

§ 291 Absatz 8 SGB V

Spätestens ab dem 1. Januar 2024 stellen die Krankenkassen den Versicherten ergänzend zur elektronischen Gesundheitskarte auf Verlangen eine sichere digitale Identität für das Gesundheitswesen barrierefrei zur Verfügung, die die Vorgaben nach Absatz 2 Nummer 1 und 2 erfüllt und die Bereitstellung von Daten nach § 291a Absatz 2 und 3 durch die Krankenkassen ermöglicht.

Digital Identities are mandatory for DiGA

DiGAV Annex 1
requirement #15a Data Security

Kann die digitale Gesundheitsanwendung bis spätestens zum 1. Januar 2024 eine Authentisierung von GKV-Versicherten als die die digitale Gesundheitsanwendung nutzenden Personen über die sichere digitale Identität nach § 291 Absatz 8 des Fünften Buches Sozialgesetzbuch unterstützen?

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







  • No labels