Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

Anbindung des E-Rezeptes an die Gesundheits-ID

    

     

      
Version
      
0.5.0
     
     

      
Revision
      
634747
     
     

      
Stand
      
24.03.2023
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemF_eRp_Fed
     
    

Dokumentinformationen

Ä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

Nutzer, welche an sektorale Identity Providern der Föderation angebunden sind, sollen vollkommen analog zu anderen Anwendungen das E-Rezept nutzen können. Dazu benötigt dieses einen innerhalb der Föderation registrierten Authorization-Server welcher den dafür definierten Vorgaben und Abläufen entspricht. Diese Rolle übernimmt weiterhin der IDP-Dienst, welcher im Rahmen der bisherigen Integration von sektoralen Identity Providern bereits alle Kernfunktionen implementiert hat (siehe 5.5 Third-Party Authorization Endpoint#gemSpec_IDP_Dienst). Diese müssen nun für einen Parallelbetrieb der beiden Vorgehensweisen sowie für die Integration des IDP-Dienstes als Authorization-Server in der Föderation erweitert werden.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von E-Rezept -Fachdienst, E-Rezept Frontend des Versicherten und des IDP-Dienstes in seiner Rolle als Authorization-Server für das E-Rezept. Es beschreibt die Änderungen, welche sich an Komponenten ergeben, um die Integration vom sektoralen IDP der Föderation zu ermöglichen.

1.3 Abgrenzungen

Das Dokument umfasst in Kapitel 3 Änderungen an bestehenden Spezifikationen bzw. Steckbriefen der gematik und ist daher als Ergänzung zur entsprechenden Spezifikation der gematik zu verstehen und zu lesen. Die neuen Dokumente für die Produkttypen sowie die entsprechenden Steckbriefe werden nach finaler Freigabe ergänzend zur Feature-Spezifikation veröffentlicht.

1.4 Methodik

1.4.1 Anforderungen und Anwendungsfälle

Anforderungen und Anwendungsfälle als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie 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 und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Afo / Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier.
• bei einer Anforderung besteht der Identifier aus der Zeichenfolge 'A_' gefolgt von einer Zahl,
• bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
• Titel der Anforderung / Anwendungsfalles: ein Titel, welcher zusammenfassend den Inhalt beschreibt
• Text / Beschreibung: ausführliche Beschreibung des Inhalts, kann neben Text Tabellen, Abbildungen und Modelle enthalten

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

2 Einordnung in die Telematikinfrastruktur

Der IDP-Dienst agiert weiterhin als alleiniger Authorization-Server für den E-Rezept-Fachdienst. Zusätzlich wird er weiterhin für andere Anwendungen als Identity Provider fungieren, welcher für WANDAs und andere TI-Anwendungen die Smartcard Identitäten von HBA und SMC-B in ID_TOKEN umwandelt, um von diesen Anwendungen die Kommunikation mit Konnektor, Kartenterminals und Smartcards zu kapseln und bereits einen Standard zu nutzen, welcher zukünftig um weitere Identifikationsmethoden im Rahmen sektoraler Identity Provider erweitert werden kann.

3 Spezifikation

3.1 Änderungen an gemSpec_IDP_Dienst

- siehe entsprechendes Dokument

Die für die Funktion des IDP-Dienst innerhalb der Föderation notwendigen Anforderungen aus gemSpec_IDP_FD finden sich in seinem Produkt- bzw. Anbietertypsteckbrief.

Es handelt sich dabei um die folgenden Anforderungen:

3.2 Änderungen an gemSpec_IDP_Frontend

- siehe entsprechendes Dokument

Hier richten sich verschiedene Vorgaben auch an das E-Rezept Frontend des Versicherten in seiner Funktion als Anwendungsfrontend gegenüber dem IDP-Dienst und werden in dessen Produkt- und Anbietertypsteckbrief referenziert.

Geändert haben sich die folgenden Anforderungen:

3.3 Änderungen an gemSpec_FD_eRp

3.3.1 Kapitel 3.1 Nachbarsysteme

...

Als Fachdienst der Telematikinfrastruktur bedient sich der E-Rezept-Fachdienst der weiteren Infrastrukturdienste wie TSPs für die Gültigkeitsabfrage für Signaturzertifikate, des HBA (für QES-Prüfung) und des IdentityManagements, bei dem der IDP-Dienst in seiner Rolle als Authorization-Server auf verschiedenen Wegen die Identitätsfeststellung für Nutzer übernimmt und deren Zugriffsberechtigungen dann in Form von ACCESS_TOKEN für den Zugriff auf den E-Rezept-Fachdienst bestätigt.

3.3.2 Kapitel 3.2 Akteure und Rollen

Leistungserbringerinstitutionen und Versicherte weisen sich gegenüber dem E-Rezept-Fachdienst mit einer Identitätsbestätigung (ACCESS_TOKEN) aus, die sie vom IDP-Dienst in seiner Rolle als Authorization-Server für den E-Rezept-Fachdienst, beziehen. In diesen ACCESS_TOKEN ist ihre Rollen-OID (Arzt, Apotheke, Versicherter) sowie ihr Identitätskennzeichen in Form der Versicherten-ID (10-stelliger unveränderlicher Anteil der KVNR) bzw. Telematik-ID enthalten. Anhand der jeweiligen Rolle wird die Zulässigkeit einer aufgerufenen Operation geprüft. Das Identitätskennzeichen wird für die Protokollierung von Zugriffen sowie die Zuordnung von Datensätzen, insbesondere bei E-Rezepten zu Versicherten, genutzt.

3.3.3 Kapitel 5.2 Authentifizierung von Nutzern

Die Identifikation von Nutzern erfolgt nach den Standards OAuth2 bzw. OpenID-Connect, hierfür stellt der IDP-Dienst in seiner Rolle als Authorization-Server für den E-Rezept-Fachdienst ACCESS_TOKEN für Nutzer aus, die er anhand ihrer identifizierenden Merkmale (z.B. eGK, SMC-B) selbst authentifiziert oder welche für ihn durch einen sektoralen Identity Provider authentifiziert wurden.

3.3.4 Kapitel 5.2.1 Registrierung beim Identity Provider

Der E-Rezept-Fachdienst delegiert die Authentifizierung von Nutzern an den IDP-Dienst in seiner Rolle als Authorization-Server. Für diesen Zweck muss er sich bei diesem als Relying Party registrieren und die für die Fachlogik notwendigen Attribute in den Identitätsbestätigungen (ACCESS_TOKEN) festlegen. Die Umsetzung des IdentityManagements über eine Föderation von Identity Providern wird durch den Authorization-Server vom E-Rezept-Fachdienst abstrahiert. Dieser integriert die sektoralen Identity Provider, welche die Identitäten von Nutzern der Telematikinfrastruktur verwalten und bestätigt die Attribute der Nutzer als vertrauenswürdig für die Umsetzung von Use Cases unter Nutzung der Schnittstellen des E-Rezept-Fachdienstes. Zuvor obliegt es dem E-Rezept-Fachdienst, sich beim IDP-Dienst als Relying Party zu registrieren.

Alt

Neu

Alt

Neu

Alt

Neu

Hinweis: Diese Art der langfristigen Session wird nur für das E-Rezept-FdV verwendet, welches eine begutachtete Speicherung der Zugangstoken gewährleisten kann. Alle anderen E-Rezept-Clients benötigen nach Ablauf der 5-minütigen Gültigkeit der ACCESS_TOKEN eine erneute Authentisierung des Nutzers. (siehe gemSpec_IDP_Dienst#A_21472, A_20946-01, A_20693-01).

Alt

Neu

Alt

Neu

3.3.5 Kapitel 5.2.2 Claims der Identitätsbestätigung

Entfällt da durch A_19993-01 in Verbindung mit den Anforderungen aus gemSpec_IDP_FD#Kapitel 5.3 redundant.

Alt

Neu

Alt

Neu

Alt

Neu

Alt

Neu

3.3.6 Kapitel 5.2.3 Verwaltung der Nutzersession

Der Identity Provider-Dienst übernimmt für den E-Rezept-Fachdienst als Relying Party die Verwaltung von Nutzersessions und stellt dem Client während der Gültigkeit der Nutzersession ACCESS_TOKEN für den Zugriff auf den E-Rezept-Fachdienst aus. Der E-Rezept-Fachdienst prüft diese ACCESS_TOKEN auf Gültigkeit gemäß der Festlegungen in [gemSpec_IDP_FD].

...

Das Signaturzertifikat C.FD.SIG des IDP kann über das Discovery Document des IDP unter https://<FQDN des IDP>/auth/realms/idp/.well-known/openid-configuration automatisch bezogen werden. Das Discovery Document ist als [JWT] aufgebaut und stellt im Claim "uri_puk_idp_sig" den Downloadpunkt auf ein JWK bereit. Darin ist das Signaturzertifikat über den key "kid"="puk_idp_sig" zu lokalisieren und liegt im Parameter "x5c" in Base64-DER-Codierung vor.

3.3.7 Kapitel 6.5.2.1 POST /Communication/

Alt

Neu

Alt

Neu

3.4 Änderungen an gemSpec_eRp_FdV

3.4.1 Kapitel 3.2 Nachbarsysteme

Die vom E-Rezept-FdV direkt erreichbaren Produkttypen der TI sind:

• Identity Provider (IDP-Dienst)
• E-Rezept-Fachdienst
• Verzeichnisdienst 
• eGK

Identity Provider

Der Identity Provider (IDP-Dienst) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen anbietet. Der IDP-Dienst agiert als Authorization-Server, im Sinne von OAuth2 (rfc6749), für den E-Rezept-Fachdienst. Er kann sowohl selbst Authentisierungen, basierend auf der eGK oder eines mit der eGK verknüpften Geräteschlüssels, durchführen als auch den Nutzer zur Authentisierung an einen sektoralen Identity Provider weiterleiten, welcher gegenüber dem IDP-Dienst sicher die Identitätsmerkmale des Nutzers bestätigt.

Authenticator-Modul

Das Authenticator-Modul ist eine logische Komponente im E-Rezept-FdV. Das Authenticator-Modul kapselt funktionale Anteile des Authentifizierungsprozesses gegenüber dem IDP-Dienst und die Kommunikation mit der Smartcard des Nutzers.

Für die Authentisierung mittels eGK greift das E-Rezept-FdV mittels des Funkstandards Near Field Communication (NFC) zur drahtlosen Datenübertragung auf die kontaktlose Schnittstelle auf die eGK zu. Das bedeutet für den Nutzer, dass er sowohl eine NFC-fähige eGK als auch ein NFC-fähiges Endgerät benötigt.

Darüber hinaus kann das Authenticator-Modul einen mit der eGK verknüpften Geräteschlüssels sicher auf dem Mobilgerät ablegen, beim IDP-Dienst registrieren und zukünftig für eine kartenlose Authentisierung nach Freischaltung mittels PIN, Passwort oder biometrischer Sensoren verwenden.

3.4.2 Kapitel 4.1 Datenschutz und Sicherheit

Alt:

Neu

3.4.3 Kapitel 5.1.2 Kommunikation mit Diensten der TI

Das E-Rezept-FdV nutzt TLS-Verbindungen für die Kommunikation zu den Diensten der TI. Es verbindet sich mit dem E-Rezept-Fachdienst, dem IDP-Dienst in seiner Rolle als Authorization-Server und dem Verzeichnisdienst.

...

Die Informationen zu den Endpunkten des IDP-Dienstes ermittelt das E-Rezept-FdV aus dem Discovery Document. Siehe auch [ gemSpec_IDP_Frontend#A_20512 - Regelmäßiges Einlesen des Discovery Document ]. Das Discovery Document ist vom IDP-Dienst unter der URL/.well-known/openid-configuration abrufbar. 

3.4.4 Kapitel 5.1.3 Authentisierung des Nutzers für Dienste der TI

Alt

Neu

3.4.5 Kapitel 5.1.6 Zertifikatsprüfung

Das E-Rezept-FdV verwendet bei den in TAB_FdVERP_017 dargestellten Aktivitäten Zertifikate.

Tabelle 1 TAB_FdVERP_017 – Zertifikatsnutzung

3.4.6 Kapitel 5.1.4 Authentisierung des Nutzers für Zugriff auf das E-Rezept-FdV

Alt

Neu

3.4.7 Kapitel 6 Informationsmodell

Dienste der TI:

Session-Daten (TI-Session) 

3.5 Änderungen an gemSpec_Perf

3.5.1 Kapitel 3.1 IDP-Dienste

A_22013-03 + Hinweis - Tabelle geändert - Neuer UseCase IDP-Dienst

Tab_gemSpec_Perf_Berichtsformat_IDP

Hinweis: Die Duration für IDP.UC_13 beginnt mit der Annahme  der Authorisierungsanfrage des E-Rezept Fachdienst und endet mit der Übermittlung der "URI-PAR" als Antwort auf die Authorisierungsanfrage. Zeiten zwischen dem Absetzen des Pushed Authorization Requst an den sektoralen IDP und dessen Antwort sind in der Berechnung enthalten.

A_22227-01 - Tabelle geändert - Neuer UseCase IDP-Dienst

Tab_gemSpec_Perf_IDP-Dienst: Bearbeitungszeitvorgaben

A_22012-01 - Kein Änderungsbedarf
A_22015-01 - Kein Änderungsbedarf

A_22230  - Kein Änderungsbedarf

A_22016-01  - Kein Änderungsbedarf

A_22504  - Kein Änderungsbedarf

A_21340-01  - Kein Änderungsbedarf

4 Dokumentenhaushalt

4.1 Neue Dokumente

Keine - die Inhalte aus gemF_eRp_Fed fließen nach Freigabe in die entsprechenden Zieldokumente ein.

4.2 Übersicht betroffener Dokumente

gemSpec_IDP_Dienst - Änderungen direkt im Dokument ersichtlich

gemSpec_IDP_Frontend - Änderungen direkt im Dokument ersichtlich

gemSpec_eRp_FdV - Anpassung der Vorgaben zur Weitergabe von Authorization Request und Authorization Code

gemSpec_FD_eRp - Veränderte Tokeninhalte

gemSpec_Perf - Veränderte UseCase Bezeichnungen

4.3 Übersicht Produkt- und Anbietertypen

gemAnbT_IDP-Dienst und gemProdT_IDP-Dienst

gemAnbT_eRp_FD und gemProdT_eRp_FD

gemAnbT_eRp_FdV und gemProdT_eRp_FdV

5 Anhang A – Verzeichnisse

5.1 Abkürzungen

5.2 Referenzierte Dokumente

5.2.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.

5.2.2 Weitere Dokumente

6 Anhang B – Anmerkungen aus der Industrie

< Hier können Anmerkungen beispielsweise als nummerierte Liste aufgezählt werden. >

7 Anhang C – Offene Punkte, Fragen

7.1 <offener Punkt oder Frage>