gemILF_PS_eRp_V1.2.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Implementierungsleitfaden Primärsysteme – E-Rezept

    

     

      
Version
      
1.2.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
19.02.2021
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS_eRp
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das Dokument beschreibt die für die Implementierung des E-Rezepts erforderlichen Vorgaben.

1.2 Zielgruppe

Das Dokument richtet sich maßgeblich an Hersteller von Primärsystemen (Praxisverwaltungssysteme, Krankenhausinformationssysteme und Apothekenverwaltungssysteme) von Leistungserbringerinstitutionen (LEI).

1.3 Geltungsbereich

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

Die Anforderungen können für Implementierungsleitfäden bzw. Konformitätsprofile der Sektoren verwendet werden.

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

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zu den genutzten FHIR-Ressourcen und den E-Rezept-Token. Anforderungen hierzu befinden sich in [gemSpec_DM_eRp].

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zu Implementation des Authentisierungsmoduls. Anforderungen hierzu befinden sich in [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend].

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

1.5.1 Hinweis auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Beispiel für einen offenen Punkt.

2 Systemüberblick

Die folgende Abbildung zeigt einen Systemüberblick für die Primärsysteme verordnende LEI und abgebende LEI.

Abbildung 1 : ABB_ILFERP_001 – Systemzerlegung

Die von den Primärsystemen direkt erreichbaren Produkttypen der TI sind

• Identity Provider
• E-Rezept-Fachdienst

Identity Provider

Der Identity Provider (IDP) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen bereitstellt. Der IDP bietet außerdem die Möglichkeit, bereits erfolgte Authentifizierungen eines Nutzers im Sinne eines Single Sign-on nachzunutzen.

Der IDP besteht aus dem zentralen Nutzerdienst und einer dezentralen Komponente, dem Authentisierungsmodul des IDP.

Authentisierungsmodul des IDP

Das Authentisierungsmodul ergänzt den IDP, um auf dem Gerät des Nutzers die fachliche Logik für die Authentisierung entsprechend dem OpenID Connect-Standard sowie das Challenge Response Verfahren mit der SMC-B umzusetzen. Der Zugriff auf die Smart Card des Nutzers erfolgt über die Außenschnittstellen des Konnektors.

Das Authentisierungsmodul wird durch das Primärsystem implementiert.

Konnektor

Der Konnektor bildet das Gateway zum zentralen Netz der TI, d.h. es routet die Anfragen an den IDP und den E-Rezept-Fachdienst.

Für die Signatur des E-Rezepts bzw. des Dispensierdatensatzes wird die CMS-Signatur (CAdES) des Konnektors genutzt.

Der Konnektor kapselt die Zugriffe auf die SMC-B für die Authentisierung.

E-Rezept-Fachdienst

Der E-Rezept-Fachdienst ist ein offener fachanwendungsspezifischer Dienst in der TI, welcher Workflow zu den E-Rezepten umsetzt.

3 Systemkontext

3.1 E-Rezept Status

Ein E-Rezept durchläuft vom Erstellen bis zum Einlösen verschiedene Status. Abhängig vom Status sind in den Primärsystemen verschiedene Anwendungsfälle möglich.

Der Status wird im E-Rezept-Fachdienst verwaltet. Ist ein Anwendungsfall aufgrund des Status nicht zulässig, antwortet der E-Rezept-Fachdienst mit einer Fehlermeldung.

TAB_ILFERP_001 listet die möglichen Status.

Tabelle 1 : TAB_ILFERP_001 – E-Rezept-Status

Die Abbildung ABB_ILFERP_002 zeigt die Anwendungsfälle, welche zu Statusübergängen führen.

Abbildung 2 : ABB_ILFERP_002 – Statusübergänge

Für weitere Details zu Statusübergängen siehe [gemKPT_SysD_TI] und [gemSysL_eRp].

3.2 FHIR-Ressourcen

Für die Spezifikation der Schnittstellen in dieser Anwendung wird der Standard FHIR (Fast Healthcare Interoperability Resources) verwendet. In FHIR werden Datenstrukturen und Elemente in "Ressourcen" beschrieben, welche über standardisierte Schnittstellen zwischen verschiedenen Komponenten übertragen werden können. Die Daten werden dabei in XML oder in JSON repräsentiert.

Durch die Primärsysteme werden folgende FHIR-Ressourcen in den Schnittstellen zum E-Rezept-Fachdienst verwendet:

• Bundle (durch die KBV profilierte Ressource für Verordnungen von Arzneimitteln)
• MedicationDispense
• Communication
• Task
• Bundle (für die Darstellung der zu signierenden signierten Quittung)
• Organization

Für eine Beschreibung der Ressourcen siehe [gemSpec_DM_eRp].

Der FHIR Standard erlaubt eine Darstellung von FHIR-Ressourcen im JSON als auch XML Format. Für die FHIR-Ressourcen wird ausschließlich die XML Darstellung genutzt.

4 Übergreifende Festlegungen

4.1 Logging und Meldungen

4.2 Namensauflösung

Der E-Rezept-Fachdienst ist für Primärsysteme gemäß der Festlegungen in [gemSpec_FD_eRp] über die Adresse erp.zentral.erp.splitdns.ti-dienste.de lokalisierbar. Das Redundanzkonzept sieht mehrere Instanzen vor, die über verschiedene IP-Adressen angesprochen werden. Folglich liefert die DNS-Namensauflösung verschiedene IP-Adressen zum FQDN zurück. Diese Adressen werden vom DNS-Server in zufälliger Reihenfolge geschickt, sodass es legitim ist, immer den ersten Eintrag für den folgenden Operationsaufruf zu verwenden. Üblicherweise wird die DNS-Auflösung vom Betriebsystem gekapselt, eine Lastverteilung am E-Rezept-Fachdienst ergibt sich aus der zufälligen Reihenfolge der IP-Adressen der DNS-Abfrage.

Unspezifiziert ist das Verhalten, wenn die erste Zieladresse nicht erreichbar ist. Empfehlenswert ist die Nutzung der anderen/weiteren IP-Adressen der DNS-Abfrage. Es muss aber angenommen werden, dass bestimmte Betriebssysteme bzw. Laufzeitumgebungen des Primärsystems diese mit der Nutzung der ersten Adresse bereits verworfen haben. Bei Nicht-Erreichbarkeit des Zielhosts der ersten IP-Adresse wird daher empfohlen, weitere Verbindungsversuche auf Basis einer neuen DNS-Abfrage zu tätigen, mit dem Ziel, eine andere IP-Adresse an erster Stelle der DNS-Antwort zu erhalten, als die des nicht erreichbaren Zielhosts.

5 Funktionsmerkmale

5.1 Allgemein

5.1.1 Kommunikation zu den Diensten der TI

Das PS einer verordnenden bzw. abgebenden LEI nutzt TLS-Verbindungen für die Kommunikation zu den Diensten der TI. Es verbindet sich mit dem E-Rezept-Fachdienst und einem Identity Provider.

Die Abfrage beim Namensdienst der TI erfolgt über eine DNS-Abfrage beim Konnektor. Der Konnektor bietet hierzu eine Operation GetIPAddress für das PS an. Siehe  in [gemSpec_KON]. Liefert die DNS-Abfrage mehrere Ziel-IP-Adressen, so ist es hilfreich, eine zufällig auszuwählen, um Lastspitzen in den einzelnen Zielsystemen zu reduzieren.

Die Informationen zu den Endpunkten des Identity Providers ermittelt das Primärsystem aus dem Discovery Document. Siehe auch [gemSpec_IDP_Dienst#Registrierung von Endgerät und Anwendungsfrontend]. Das Discovery Document ist vom IDP-Dienst unter der URL /.well-known/openid-configuration abrufbar. 

Es gelten die Vorgaben aus [gemSpec_Krypt] für TLS.

5.1.2 Verschlüsselte Kommunikation zur VAU des E-Rezept-Fachdienstes

Die Kommunikation zum E-Rezept-Fachdienst wird zusätzlich zu TLS über einen sicheren Kanal (Verschlüsselung auf Http-Ebene) zwischen dem PS und der Vertrauenswürdigen Ausführungsumgebung (VAU) im E-Rezept-Fachdienst gesichert.

Für Informationen zum Kommunikationsprotokoll zwischen E-Rezept-FdV und der VAU des E-Rezept-Fachdienstes siehe  und  .

5.1.3 Zertifikatsprüfung

Das Primärsystem der verordnenden und abgebenden LEI verwendet bei den in TAB_ILFERP_012 dargestellten Aktivitäten Zertifikate.

Tabelle 2 TAB_ILFERP_012 – Zertifikatsnutzung

Es gelten folgende übergreifende Festlegungen für die Prüfung aktiv durch das E-Rezept-FdV genutzter Zertifikate.

"Ein Zertifikat aktiv verwenden" bedeutet im Sinne von A_20769, dass ein Primärsystem einen dort aufgeführten öffentlichen Schlüssel innerhalb einer kryptografischen Operation (Signaturprüfung, Verschlüsselung, Signaturprüfung von öffentlichen (EC)DH-Schlüsseln etc.) nutzt. Erhält ein Primärsystem bspw. einen Access-Token, in dem Signaturen und Zertifikate enthalten sind, und behandelt es diesen Token als opakes Datenobjekt, ohne die Zertifikate darin gesondert zu betrachten, dann verwendet das Primärsystem diese Zertifikate im Sinne von A_20769 passiv.

5.1.3.1 Zertifikatsprüfung von Zertifikaten der TI

5.1.3.2 Zertifikatsprüfung von Internet-Zertifikaten

Folgende Vorgaben gelten für die Prüfung von Internet-Zertifikaten.

Hinweis: Der erste Teil von A_20091 ist gleichbedeutend damit, dass das CA-Zertifikat im Zertifikats-Truststore eines aktuellen Webbrowsers ist.

5.1.4 Authentifizierung der LEI

Die LEI authentisiert sich für Zugriffe auf Dienste der TI im Rahmen der Anwendung E-Rezept gegenüber dem IDP-Dienst. 

Das Primärsystem übernimmt hierbei, wenn kein gültiger "ACCESS_TOKEN" vorliegt, neben der Rolle der Anwendungsfrontend-Applikation auch die Aufgabe des Authenticator-Moduls (der in [RFC6749 # section-4.1] beschriebene User-Agent), um das zum Zugriff auf Fachdienste benötigte "ACCESS_TOKEN" zu beantragen. Hierfür wird am Authorization-Endpunkt des IDP-Dienstes ein "AUTHORIZATION_CODE" beantragt, der nach erfolgreicher Verifikation am Token-Endpunkt des IDP-Dienstes gegen ein "ID_TOKEN" und ein "ACCESS_TOKEN" getauscht wird.

Die für die Beantragung des "AUTHORIZATION_CODE" im Challenge-Response-Verfahren notwendige elektronische Signatur mit der AUT-Identität einer SMC-B der LEI lässt das Primärsystem über die Schnittstellen des Konnektors generieren. Im Fall einer bereits freigeschalteten Smartcard passiert diese Aktion ohne Interaktion mit dem Nutzer im Hintergrund. 

Der IDP-Dienst führt die Identifikation der LEI durch, und stattet diese anschließend mit "ID_TOKEN" gemäß [openid-connect-core 1.0 # IDToken] und "ACCESS_TOKEN" gemäß [RFC6749 # section-1.4 & RFC6749 # section-5] aus. Dabei wurde aus Sicherheitsaspekten der "Authorization Code Grant" gemäß [RFC6749 # section-4.1] gewählt, welcher in identischem Ablauf auch für mobile Endgeräte mit getrennten Komponenten für Authenticator-Modul und Anwendungsfrontend anwendbar ist. Um dem erforderlichen Sicherheitsniveau gerecht zu werden, wird zudem die Verwendung von PKCE (Proof Key for Code Exchange by OAuth Public Clients) gemäß [RFC7636] vorgesehen.

Der IDP-Dienst selbst teilt sich in mehrere statisch adressierte Teildienste auf. Diese umfassen:

• Discovery-Endpunkt ("OAuth 2.0 Authorization Server Metadata" [RFC8414])
• Authorization-Endpunkt (Teil des "The OAuth 2.0 Authorization Framework" [RFC6749])
• Token-Endpunkt [RFC6749 # section-3.2]

Für weitere Informationen zum IDP-Dienst und zum Ablauf der Authentisierung siehe [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend].

5.1.4.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes

Zur Nutzung des IDP-Dienstes gelten einige grundlegende Voraussetzungen, welche das PS erfüllen muss.

Als SignatureType ist urn:ietf:rfc:5652 für eine CMS-Signatur zu verwenden. Weitere optionale Parameter kommen nicht zur Anwendung.

Bei Aufruf der Funktion "VerifyDocument" an der Außenschnittstelle des Konnektors ist es nicht möglich, direkt auch eine Prüfung des Zertifikatstyps und der Rollen-OID durchzuführen.

Hinweis: Zur Durchführung der Prüfungen gemäß A_20657 und ähnlicher Anforderungen ist zu verifizieren, ob im Feld certificatePolicies (2.5.29.32) des Zertifikates der richtige Zertifikatstyp FD.SIG (1.2.276.0.76.4.203) gemäß [gemSpec_OID#Tabelle Tab_PKI_405] eingetragen ist und sich in der Admission (1.3.36.8.3.3) des Zertifikats die richtige "oid_idpd" (1.2.276.0.76.4.260) findet.

Darüber hinaus gelten für die Kommunikation mit dem IDP-Dienst die Vorgaben aus .

5.1.4.2 Abruf von Token beim IDP-Dienst

Im Folgenden wird der Ablauf der Token-Beantragung und Ausstellung detaillierter beschrieben und – wo für das Primärsystem notwendig – mit entsprechenden Anforderungen hinterlegt. 
Im ersten Schritt erzeugt sich das Primärsystem einen zufälligen "CODE_VERFIER" und bildet darüber den Hash "CODE_CHALLENGE". Mit dessen Hilfe kann es sich im späteren Verlauf als valider Empfänger des Tokens ausweisen.

Anschließend werden der gehashte Zufallswert und die notwendigen Angaben als "CODE_CHALLENGE" beim Authorization-Endpunkt des IDP-Dienstes eingereicht.

Hinweis: Der folgende Aufruf skizziert einen beispielhaften HTTP-GET-Request an den IDP-Dienst, welcher vom Authenticator-Modul initiiert wird:

GET /auth?response_type=code&scope=openid%20erezept&state=af0ifjsldkj&client_id=ZXJlemVwdC1hcHA&redirect_uri=https%3A%2F%2Fapp.erezept.com%2Fauthnres&code_challenge_method=S256&code_challenge=S41HgHxhXL1CIpfGvivWYpbO9b_QKzva-9ImuZbt0Is

HTTP/1.1
Host: idp.com
X-Authenticator-App: 1.0
Accept: application/json
User-Agent: Authenticator-App/1.0

Der Authorization-Endpunkt legt nun eine "session_id" an, stellt alle nötigen Informationen zusammen und erzeugt die verschlüsselte "challenge".
Darüber hinaus stellt der Authorization-Endpunkt den im Claim des entsprechenden Fachdienstes vereinbarten "Consent" zusammen, welcher die für dessen Funktion notwendigen Attribute beinhaltet.

Der Authorization-Endpunkt liefert als Response zur Anfrage des "AUTHORIZATION_CODE" einen "CHALLENGE_TOKEN", um die Identität der LEI zu bestätigen, sowie den "consent" des im "scope" angefragten Fachdienstes.

Hinweis: Nachfolgend wird beispielhaft ein "CHALLENGE_TOKEN" in Form eines JSON Web Token (JWT) dargestellt:
Challenge JWT:
challenge_headers = {
    "typ":"JOSE+JSON",
    "iat":1591714252326,
    "exp":1591714552326,
    "jti":"c3a8f9c8-aa62-11ea-ac15-6b7a3355d0f6",
    "snc":"sLlxlkskAyuzdDOwe8nZeeQVFBWgscNkRcpgHmKidFc"
}
challenge_payload = {
    "response_type":"code",
    "scope":"openid erezept",
    "client_id":"ZXJlemVwdC1hcHA",
"state":"af0ifjsldkj", 
    "redirect_uri":"https://app.erezept.com/authnres",
    "code_challenge_method":"S256",
    "code_challenge":"S41HgHxhXL1CIpfGvivWYpbO9b_QKzva-9ImuZbt0Is"
}

Der Authorization-Endpunkt hat den "CHALLENGE_TOKEN" mit seinem privaten Schlüssel "PRK_AUTH" signiert. Der folgende Aufruf skizziert beispielhaft die Antwort des Authorization-Endpunktes, welche vom Primärsystem angenommen wird. Der "CHALLENGE_TOKEN" wird dabei nur angedeutet:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
 
{
  "challenge": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpPU0UrSlNPTiIsImlhdCI6MTU5MTcxNDI1MjMy......",
  "user_consent": {
    "client_name": "eRezept App",
    "url": "https://erezept.com/",
    "requested_scope": {
      "openid": "Der Zugriff auf den ID Token" 
      "erezept": "Zugriff auf die eRezept Funktionalität."
    },
"show_once": true,
"amr": ["JWT-Challenge-Response"]
    // ggf. mehr Informationen, welche dem Nutzer angezeigt werden sollen, wie die Auflistung der mit der Zustimmung weitergegebenen Daten
  }
}

Das Primärsystem verwendet nun die AUT-Identität der SM-B der LEI und deren Konnektor, um die 256-Bit "challenge" des IDP-Dienstes zu signieren. Wenn es sich um eine erstmalige Anmeldung des Benutzers bei diesem Fachdienst handelt, werden diesem darüber hinaus die für den Zugriff übermittelten Daten der LEI angezeigt.

Hinweis: Die erfolgte Zustimmung des Nutzers darf gespeichert werden und weitere Abfragen können entfallen.

Für weitere Informationen siehe Kapitel "Als Nutzer gegenüber der Telematikinfrastruktur authentisieren" in der API-Schnittstelle [E-Rezept API Dokumentation].

Hinweis: Im Rahmen der Signatur wird auf privates Schlüsselmaterial zugegriffen. Die verwendeten Karten müssen sich daher in einem erhöhten Sicherheitszustand befinden, der ggf. erst durch eine PIN-Eingabe hergestellt werden muss. Das Primärsystem muss den Kartenzustand abfragen und die Karte ggf. durch den Nutzer freischalten lassen. Mit dem (optionalen) Einblenden eines Hinweises der Form "Bitte beachten Sie die Anzeige an Ihrem Kartenterminal" muss das Primärsystem dafür sorgen, dass die Abfrage einer PIN-Eingabe am Kartenterminal vom Benutzer nicht übersehen wird.

Anschließend werden die signierte "challenge" und das verwendete Authentisierungszertifikat der Smartcard an den IDP-Dienst übermittelt.

Hinweis: Der folgende beispielhafte Aufruf skizziert den HTTP-POST-Request, welcher vom Authenticator-Modul an den Authorization-Endpunkt des IDP-Dienstes übertragen wird. Dabei wird das signierte und verschlüsselte "CHALLENGE_TOKEN" nur angedeutet:

POST /sign_response HTTP/1.1
Host: idp.com
Content-Type: application/x-www-form-urlencoded

signed_challenge=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpPU0UrSlNPTiIsIng.....

Der Authorization-Endpunkt validiert nun die "session" sowie die "signed_challenge" und prüft das Zertifikat der LEI. Anschließend verknüpft er die "session" mit der Identität aus dem Authentisierungszertifikat und erstellt einen "AUTHORIZATION_CODE", welchen er als Antwort zurücksendet

Das Primärsystem empfängt nun diesen "AUTHORIZATION_CODE" von IDP-Dienst und prüft ihn.

Hinweis: Der Authorization-Endpunkt liefert den "AUTHORIZATION_CODE" innerhalb einer HTTP-Redirection (HTTP-Status Code 302) an das Primärsystem zurück. Der Wert des Attributs "location" der HTTP 302 Response ist nicht relevant.
Nachfolgend wird ein beispielhafter Response des Authorization-Endpunkt skizziert, dabei wird der "AUTHORIZATION_CODE", nur angedeutet:

HTTP/1.1 302 Found
Location: https://app.erezept.com/authnres?code=eyJhbGciOiJkaXIiL... 
&state=af0ifjsldkj

Zur Prüfung von Zertifikatstyp-OID und Rollen-OID siehe Hinweis zu A_20657.

Anschließend werden der zu Beginn des Prozesses erzeugte "CODE_VERFIER" und der "AUTHORIZATION_CODE" zum Token-Endpunkt des IDP-Dienstes gesendet, um dort gegen "ID_TOKEN" und "ACCESS_TOKEN" eingetauscht zu werden

Hinweis: Der folgende Aufruf skizziert beispielhaft den HTTP-POST-Request an den Token-Endpunkt. Der mitgegebene "AUTHORIZATION_CODE" wird dabei nur angedeutet:
POST /token HTTP/1.1
Host: idp.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiZXhwIjoxNTkx.....
&redirect_uri=https%3A%2F%2Fapp.erezept.com%2Fauthnres
&code_verifier=MApN61C4itdm4-58dCjMkoucuu00jipPlNibsAxjyJk

Der Token-Endpunkt validiert den "CODE_VERFIER" und gleicht diesen mit der "code_challenge" ab. Dann erzeugt er die erforderlichen Token und verschlüsselt das "ACCESS_TOKEN" für den empfangenden Fachdienst.

Das Primärsystem erhält nun den signierten "ID_TOKEN" und den für es nicht lesbaren "ACCESS_TOKEN" vom Token-Endpunkt und prüft die Signatur des "ID_TOKEN".

Hinweis: Das Primärsystem nimmt sowohl den "ID_TOKEN" als auch den "ACCESS_TOKEN" aus der Antwort des Token-Endpunktes des IDP-Dienstes. Der Token-Endpunkt antwortet mit den Token auf die erfolgreiche Übergabe und Validierung des "AUTHORIZATION_CODES" durch das Anwendungsfrontend. Nachfolgend wird beispielhaft die Antwort des Token-Endpunktes skizziert. Der "ID_TOKEN" und der "ACCESS_TOKEN" werden dabei nur angedeutet:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
 
{"token_type": "Bearer",
 "expires_in": 300,
 "id_token": "...",
 "access_token": "...",
}

Zur Prüfung von Zertifikatstyp- und Rollen-OID siehe Hinweis zu A_20657.

Im weiteren Verlauf kann der "ACCESS_TOKEN" innerhalb seiner Gültigkeitsdauer bei verschiedenen Aufrufen des Fachdienstes eingereicht werden. Der Fachdienst entschlüsselt das "ACCESS_TOKEN" mit seinem privaten Schlüssel, validiert es, zieht die notwendigen Informationen entsprechend seinem Claim heraus und verwendet diese für seine fachlichen Operationen.

5.2 Anwendungsfälle verordnende LEI

Folgende Anwendungsfälle werden im Primärsystem einer verordnenden LEI umgesetzt.

5.2.1 E-Rezept erstellen

Mit diesem Anwendungsfall werden die Aufbewahrungspflichten der verordnenden LEI unterstützt. Das PS der verordnenden LEI fragt für das Erstellen eines E-Rezepts beim E-Rezept-Fachdienst eine über 11 Jahre eindeutige Rezept-ID ab, die für das E-Rezept verwendet wird. 

Für weitere Informationen siehe Operation "E-Rezept erstellen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Value-Katalog für FlowType ist in [gemSpec_DM_eRp] beschrieben.

Der Response des Fachdienstes liefert

• die Rezept-ID (Task.Identifier mit "https://gematik.de/fhir/NamingSystem/PrescriptionID "), mit der das E-Rezept-Bundle vervollständigt wird,
• die Task-ID (Task.id), mit dem der Task bei Aufrufen des E-Rezept-Fachdienstes referenziert wird,
• und den AccessCode (Task.Identifier mit "https://gematik.de/fhir/Namingsystem/accessCode"), welcher für den Zugriff auf das E-Rezept im Fachdienst berechtigt

Dieses Bundle wird in diesem Dokument als E-Rezept-Bundle bezeichnet. Ein E-Rezept-Bundle enthält genau eine Verordnungszeile.

Für die qualifizierte elektronische Signatur des E-Rezept Bundels wird der Konnektor verwendet. Es wird eine CMS-Signatur (CAdES) erstellt. Die Operation für die QES muss durch den Leistungserbringer durchgeführt werden.

Für weitere Informationen siehe Operation "E-Rezept qualifiziert signieren" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Für die Nutzung der Komfortsignatur siehe [gemILF_PS].

Falls keine Komfortsignatur zur Verfügung steht oder die Komfortsignatur deaktiviert ist, soll das PS der verordnenden LEI die Stapelsignatur verwenden ist, falls mehrere E-Rezepte signiert werden sollen. 

5.2.2 E-Rezept einstellen

Mit diesem Anwendungsfall wird das von der verordnenden LEI erstellte E-Rezept auf dem Fachdienst eingestellt, damit es für den Versicherten verfügbar ist.

Das erstellte E-Rezept-Bundle wird innerhalb einer PKCS#7-Datei (enveloping) für die QES an den Task in der $activate-Operation übergeben.

Für weitere Informationen siehe Operation "E-Rezept vervollständigen und Task aktivieren" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Es gelten vorrangig die Regelungen zum Ausdruck eines E-Rezepts aus den Bundesmantelverträgen [BMV] und [BMV-Z].

Für die Spezifikation des E-Rezept-Token siehe [gemSpec_DM_eRp#2.3].

Für die Spezifikation des Datamatrix-Code für E-Rezept-Token siehe [gemSpec_DM_eRp#2.3]. 

Für Regelungen zum Inhalt des Ausdrucks siehe auch Bundesmantelverträge [BMV] und [BMV-Z]

5.2.3 E-Rezept löschen

Mit diesem Anwendungsfall kann die verordnende LEI ein E-Rezept löschen, welches sie zuvor auf den E-Rezept-Fachdienst eingestellt hat.

Für weitere Informationen siehe Operation "Ein E-Rezept löschen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3 Anwendungsfälle abgebende LEI

Folgende Anwendungsfälle werden im Primärsystem einer abgebenden LEI umgesetzt.

5.3.1 E-Rezept abrufen

Mit diesem Anwendungsfall kann die abgebende LEI Daten zum E-Rezept inklusive QES zu einem vom Versicherten empfangenen E-Rezept-Token vom E-Rezept-Fachdienst abrufen, um das E-Rezept einzulösen.
Darüber hinaus wird durch die Gültigkeit der QES sichergestellt, dass es sich um ein gegenüber der Krankenkasse abrechenbares gültiges E-Rezept handelt.

Für weitere Informationen siehe Operation "E-Rezepte abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response liefert eine Task Ressource. Für die Spezifikation der Task Ressource siehe [gemSpec_DM_eRp]. Jeder Task enthält die folgenden fachlichen Informationen:

• Secret - Dieser Code wurde vom E-Rezept-Fachdienst spezifisch für diesen Abruf des E-Rezepts erstellt. Er berechtigt, die weiteren Statusänderungen auf dem E-Rezept-Fachdienst vorzunehmen.
• signature - base64 kodierter PKCS#7-Datei mit dem E-Rezept-Bundle und der Signatur, wie sie vom Konnektor der verordnenden LEI generiert wurde.

Für die QES-Prüfung wird die PKCS#7-Datei verwendet. Die Verordnungsdaten des E-Rezepts sind innerhalb der PKCS#7-Datei enthalten und müssen für die Weiterverarbeitung extrahiert werden.

Für weitere Informationen siehe Operation "Qualifizierte Signatur des E-Rezepts prüfen" aus der API-Schnittstelle [E-Rezept API Dokumentation]. Implementierungshinweise zur Signaturprüfung für Primärsysteme sind in [gemILF_PS#4.4.2] beschrieben. Die Außenschnittstelle des Konnektors ist in [gemSpec_Kon#TIP1-A_5034-x Operation VerifyDocument (nonQES und QES)] beschrieben. 

Als Response liefert der Konnektor einen standardisierten Prüfbericht in einer VerificationReport-Struktur gemäß [OASIS-VR].

Für die weitere Verarbeitung wird das E-Rezept-Bundle aus der PKCS#7-Datei verwendet.

5.3.2 Quittung abrufen

Mit diesem Anwendungsfall kennzeichnet das PS der abgebenden LEI das E-Rezept nach der Belieferung im E-Rezept-Fachdienst als abgegeben und lädt die Quittung herunter, die für die weiteren Abrechnungsprozesse genutzt wird.
Darüber hinaus werden dem E-Rezept-Fachdienst Informationen über das abgegebene Medikament bereitgestellt, die dann vom Versicherten auf seinem FdV heruntergeladen werden können. 

Für die Spezifikation der Ressource MedicationDispense siehe [gemSpec_DM_eRp]. Die Befüllung des Medication-Objekts der MedicationDispense kann in Abhängigkeit eines Austauschs aus der Übernahme der wesentlichen Attribute (PZN, Wirkstoff, Darreichungsform, Dosierinformationen) aus dem Verordnungsdatensatz und den Daten aus dem Securpharm-Scan in die MedicationDispense und Medication kopiert werden. Weitere Informationen, die sich aus dem Scan des Securpharm-Codes für Fertigarzneimittel ergeben (z.B. Charge, Haltbarkeitsdatum) und im Primärsystem vorliegen, können ebenfalls übernommen werden.

Für weitere Informationen siehe Operation "E-Rezept-Abgabe vollziehen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response enthält ein signiertes Quittungs-Bundle, welches im Abrechnungsprozess genutzt wird.

Der E-Rezept-Fachdienst prüft regelmäßig den Status seines Signaturzertifikats, die mandatorische Signaturprüfung der Quittung obliegt dem Quittungsempfänger, kann aber vom AVS vor der Weitergabe in die Abrechnungsprozesse ebenfalls geprüft werden.

Die Quittung wird als PKCS#7-Datei erstellt. Die quittierten Daten sind innerhalb der PKCS#7-Datei enthalten.

Implementierungshinweise zur Signaturprüfung für Primärsysteme sind in [gemILF_PS#4.4.2] beschrieben. Die Außenschnittstelle des Konnektors ist in [gemSpec_Kon#TIP1-A_5034-x Operation VerifyDocument (nonQES und QES)] beschrieben. 

Als Response liefert der Konnektor einen standardisierten Prüfbericht in einer VerificationReport-Struktur gemäß [OASIS-VR].

5.3.3 Quittung erneut abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die Quittung erneut abrufen, falls bei der Übermittlung vom E-Rezept-Fachdienst ein Fehler aufgetreten ist.

Der Anwendungsfall kann bei Bedarf wiederholt werden.

Für weitere Informationen siehe Operation "Quittung erneut abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response enthält ein signiertes Quittungs-Bundle, welches im Abrechnungsprozess genutzt wird.

5.3.4 E-Rezept zurückgeben

Mit diesem Anwendungsfall kann die abgebende LEI ein E-Rezept, welches vom E-Rezept-Fachdienst abgerufen wurde, wieder zurückgeben, z.B. weil das E-Rezept nicht beliefert werden kann oder weil der Versicherte darum gebeten hat. Nachfolgend kann es durch den Versicherten einer anderen abgebenden LEI zugewiesen werden.

Für weitere Informationen siehe Operation "Ein E-Rezept zurückweisen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.5 E-Rezept löschen

Mit diesem Anwendungsfall kann die abgebende LEI ein E-Rezept, welches auf dem E-Rezept-Fachdienst gespeichert ist, löschen, z.B. wenn ein Fehler an der Verordnung gefunden wurde, der sich nur durch das Ausstellen eines neuen E-Rezepts durch die verordnende LEI beheben lässt.

Für weitere Informationen siehe Operation "Ein E-Rezept löschen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.6 Nachrichten von Versicherten empfangen

Mit diesem Anwendungsfall kann die abgebende LEI den Token eines E-Rezepts empfangen, um es zu beliefern. Darüber hinaus kann es Nachrichten des Versicherten, wie z.B. Anfragen zur Belieferung durch eine Apotheke, empfangen.  

Für weitere Informationen siehe Operationen "Anwendungsfall auf neue Nachrichten prüfen" und  "Anwendungsfall Alle Nachrichten vom E-Rezept-Fachdienst abrufen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Falls eine oder mehrere E-Rezept-Nachrichten für die abgebende LEI auf dem Fachdienst bereitstehen, übermittelt der Fachdienst ein Bundle von Communication Ressourcen. 

Eine Communication Ressource kann unterschiedlichen Typs sein und beinhaltet typabhängige, fachliche Informationen:

• Absender-ID (Versicherten-ID) für die Korrespondenz möglicher Antwortnachrichten
• Nachrichten-ID, um auf eine konkrete Nachricht zu antworten
• unverbindliche Anfrage zur Belieferung durch eine Apotheke
  
• • Informationen zum verordneten bzw. angefragten Medikament als Medication-Ressource
  • Anzahl der Packungen des verordneten bzw. angefragten Medikamentes
    
  • IK-Nummer des begünstigten Versicherten (unabhängig von der Versicherten-ID, da auch Vertreter Anfragen zur Belieferung durch eine Apotheke stellen können) 
  • Aut-Idem-Feld entsprechend der Festlegung im E-Rezept-Datensatz
  • Rezepttyp als Wert des Flowtypes im Task des E-Rezept-Workflows
  • optional: bevorzugte Belieferungsoptionen ["Apotheke", "Bote", "Versand"] des Versicherten 
  • optional: Mitteilung/Text
• verbindlicher Einlöseauftrag
• • Referenz auf den aktiven E-Rezept-Task inkl. Zugriffsberechtigung (E-Rezept-Token), über den sämtliche einlöserelevanten Informationen beziehbar sind
  • optional: Mitteilung/Text

Wenn die Nachricht einen E-Rezept-Token enthält, dann hat der Versicherte das E-Rezept der Apotheke zugewiesen. Mit den Informationen aus dem E-Rezept-Token kann das E-Rezept vom Fachdienst abgerufen (Anwendungsfall "E-Rezept abrufen") und beliefert werden.

Wenn die Nachricht Informationen zum verordneten Mittel und keinen E-Rezept-Token enthält, dann kann die Information entsprechend der Mitteilung des Versicherten (bspw. Anfrage zur Belieferung durch eine Apotheke) verarbeitet werden. 

5.3.7 Nachricht an Versicherten versenden

Mit diesem Anwendungsfall kann die abgebende LEI auf Nachrichten eines Versicherten antworten, z.B. um mitzuteilen, ob das E-Rezept durch die Apotheke beliefert werden kann oder wann die Arzneimittel zur Abholung bereitstehen.

Innerhalb der Textnachricht sind keine Internet-Links zulässig.

Als ID des Empfängers wird die Versicherten-ID des Absenders aus der empfangenen E-Rezept-Nachricht verwendet.

Für die Spezifikation der Communication Ressource siehe [gemSpec_DM_eRp].

Für weitere Informationen siehe Operationen "Anwendungsfall Nachricht als Apotheke an einen Versicherten schicken" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.3.8 Dispensierdatensatz signieren

Nach der Belieferung eines E-Rezepts erstellt das PS der abgebenden LEI einen Dispensierdatensatz, welcher zusammen mit dem E-Rezept-Bundle und der Quittung für die Abrechnung des E-Rezepts verwendet wird.

Die Inhalte und die Struktur des Dispensierdatensatzes werden durch DAV und GKV-SV vorgegeben.

Der Dispensierdatensatz dient der Abrechnung. Demgegenüber stehen die Dispensierinformationen der MedicationDispense-Ressource für den Versicherten (vgl. Abschnitt 5.3.2). 

Für die Signatur des Dispensierdatensatzes wird der Konnektor verwendet.

5.3.9 2D-Code einscannen

Eine Alternative zur Übermittlung eines E-Rezept-Token vom Versicherten mittels E-Rezept-Nachricht ist die persönliche Übergabe in der Apotheke vor Ort. Hierzu übergibt der Kunde (Versicherter oder Vertreter) dem Mitarbeiter der abgebenden LEI einen Papierausdruck mit 2D-Code oder präsentiert einen 2D-Code auf dem Display seines mobilen Gerätes. Ebenso besteht die Möglichkeit, dass ein Versicherter den Papierausdruck eines E-Rezept-Tokens an eine Versandapotheke sendet. Der 2D-Code wird eingescannt.

Der 2D-Code auf einem durch eine verordnende LEI erstellten Ausdruck enthält genau den E-Rezept-Token für ein E-Rezept. Der Versicherte kann in seinem E-Rezept-FdV bis zu 3 E-Rezept-Token in einem 2D-Code zusammenfassen. Dies dient einer besseren Usability.

Für den Aufbau des 2D-Codes und Struktur des E-Rezept-Token siehe [gemSpec_DM_eRp].

Mit den Informationen aus einem E-Rezept-Token kann das E-Rezept vom E-Rezept-Fachdienst heruntergeladen werden.

5.4 Fehlerbehandlung

Tritt ein Fehler bei der Verarbeitung von Operationsaufrufen an einem Dienst der TI (bspw. E-Rezept-Fachdienst) auf, dann antwortet der Dienst mit einer Fehlermeldung. Das Format und die verwendeten Fehlercodes sind in den Spezifikationen der Interfaces (bspw. [gemSpec_FD_eRp]) beschrieben. Weiterhin können Fehler in der lokalen Verarbeitung auftreten.

6 Informationsmodell

Dienste der TI:

Authentisierung

Session-Daten

für PS verordnende LEI

E-Rezept:

für PS abgebende LEI:

E-Rezept:

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

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

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

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

7.5.2 Weitere Dokumente