Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden

Nachbarsysteme für eHealth-CardLink

    

     

      
Version
      
1.1.1
     
     

      
Revision
      
1115897
     
     

      
Stand
      
29.01.2025
     
     

      
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 Telematikinfrastruktur (TI)-Konnektor eines Leistungserbringers (LE) interagieren. Im Ergebnis kann dem an den eH-CL angeschlossenen Leistungserbringer ein Versichertenstammdatenmanagement (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 eH-CL 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 Herstellern/Anbietern der in diesem Implementierungsleitfaden (ILF) 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 LE.
Aus Sicht der gematik werden in diesem ILF 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 Krankenversicherungsnummer (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.

Mit der Anpassung des VSDM-Prüfungsnachweis bzw. der VSDM-Prüfziffer (PZ) ist der Abgleich der KVNR für das Primärsystem mit der neuen PZ Version 2 nicht mehr möglich, da diese verschlüsselt ist. Die notwendige Sicherheitsleistung wird bei Verwendung der PZ Version 2 durch den prüfenden Fachdienst übernommen (Sperrinformation innerhalb der PZ). Das Primärsystem, welches einen eHealth-CardLink verwendet, muss somit unterscheiden, ob eine PZ Version 1 oder 2 vorliegt und unterschiedlich reagieren.

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.

4.5.2 Weitere Dokumente