Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden

Nachbarsysteme für eHealth-CardLink

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
958752
     
     

      
Stand
      
19.03.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_eHealth-CardLink
     
    

gemILF_eHealth-CardLink

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Mit dem Produkttyp eHealth-CardLink (eH-CL) kann über ein Smartphone die elektronische Gesundheitskarte (eGK) eines Nutzers mit dem TI-Konnektor eines Leistungserbringers interagieren. Im Ergebnis kann dem an den eH-CL angeschlossenen Leistungserbringer ein VSDM-Prüfungsnachweis ausgestellt werden.
Ein gültiger Prüfungsnachweis kann einen Leistungserbringer zum Abruf von E-Rezepten vom TI-Fachdienst autorisieren.
Mit dem eH-CL ist es damit möglich, dass ein Versicherter einer an den eH-CL angebundenen Apotheke mobil den Abruf der E-Rezepte ermöglicht. Daraufhin kann die Apotheke bzw. der Apotheker dem Versicherten alle aus seiner Sicht zum Zweck der Beratung und Verkauf erforderlichen Informationen beispielsweise über eine Applikation zur Verfügung stellen.

Hinweise:

• Die beschriebenen Nutzungsszenarien können bereits jetzt in ähnlicher Form durch Versicherte mit digitaler Identität (GesundheitsID) abgebildet werden.

• Der eHealth-CardLink soll diese Szenarien darüber hinaus für alle Versicherten ermöglichen, die noch nicht über eine GesundheitsID bzw. über eine eGK-PIN verfügen. Es handelt sich um eine zeitlich begrenzte Brückentechnologie, die zum einen durch die Verbreitung der GesundheitsID und zum anderen von der Weiterentwicklung der Fachdienste der Kostenträger abgelöst und von der gematik abgekündigt wird.

• Den in diesem Implementierungsleitfaden adressierten Komponenten und Diensten (App-Provider; Primärsysteme) wird daher ebenfalls empfohlen, ihre weiterführenden Entwicklungstätigkeiten an der Nutzung der digitalen Identität für Versicherte auszurichten.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von Primärsystemen und an App-Provider, die im Kontext eHealth-CardLink agieren wollen.

1.3 Geltungsbereich

Die in diesem Dokument formulierten Anforderungen sind informativ für Primärsysteme, die am Produktivbetrieb der TI teilnehmen. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben. 

Alle Anforderungen zur Durchführung von Online-Prüfungen und -Aktualisierungen sowie zur Übernahme von Prüfungsnachweisen gelten für Primärsysteme gemäß den Vorgaben für vertrags(zahn)ärztliche Leistungserbringer. Dies kann Psychotherapeuten betreffen, die in ein Arztregister eingetragen sind, betrifft jedoch nicht den stationären Bereich.

Wichtiger Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Es ist keine Abgrenzung gegenüber anderen Spezifikationen erforderlich.

1.5 Methodik

Anwendungsfälle und Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID,
Anforderungen zusätzlich durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

2 Maßnahmen zur Verknüpfung von App-Aufrufen mit eGKs

Zur Umsetzung des in Kapitel 2 von [gemSpec_eHealth-CardLink]  beschriebenen Anwendungskontextes tragen auch Komponenten und Dienste des App-Providers sowie das Primärsystem (PS) bei. 
Die Verantwortung für die Sicherheit der Gesamtlösung liegt im Verantwortungsbereich des Leistungserbringers.
Aus Sicht der gematik werden in diesem Implementierungsleitfaden Maßnahmen formuliert, die zur Sicherheit der Gesamtlösung beitragen.
Es wird das Zusammenspiel der beteiligten Komponenten und Dienste beschrieben.

Der Inhalt des Hinweises muss für den durchschnittlichen Benutzer verständlich sein. Er kann auf den Anwendungskontext bezogen werden, er muss nicht den technischen Begriff „VSDM-Prüfungsnachweis“ enthalten.

3 Maßnahmen gegen Manipulation der Kartenkommunikation

Wie in [gemSpec_eHealth-CardLink] im Kapitel "Maßnahmen gegen Manipulation der Kartenkommunikation" erläutert werden im Falle der Remote-Anbindung einer eGK erweiterte Sicherheitsmaßnahmen empfohlen, um Angriffe zu unterbinden, bei denen die von der eGK zu lesenden Daten von einem Angreifer manipuliert werden können. Zu diesen Maßnahmen kann auch das PS ergänzend zu A_24929* und A_25193* beitragen.
Das Primärsystem prüft, ob die KVNR aus dem VSDM-Prüfnachweis und die KVNR aus dem verifizierten C.CH.AUT-Zertifikat der vorgelegten eGK identisch sind. Nur in dem Fall darf das Primärsystem den Prüfnachweis verwenden (beispielsweise zum Abruf von Rezeptdaten beim E-Rezept-Fachdienst).
Die KVNR des C.CH.AUT-Zertifikats der präsentierten eGK kann beispielsweise aus dem VSDM-Ereignis "VSDM/PROGRESS/READVSD" entnommen werden. Dort ist entsprechend [gemSpec_FM_VSDM#VSDM-A_2667] die KVNR (=$CARD.KVNR) aus C.CH.AUT enthalten, welches der Konnektor aus dem C.CH.AUT Zertifikat ermittelt (vgl. [gemSpec_Kon#TIP1-A_4565]). 
Hinweis: Wird dieser Weg gewählt, muss das Primärsystem das VSDM-Ereignis abonniert haben.

4 Anhang – Verzeichnisse

4.1 Abkürzungen

4.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

4.3 Abbildungsverzeichnis

4.4 Tabellenverzeichnis

4.5 Referenzierte Dokumente

4.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

4.5.2 Weitere Dokumente