gemILF_PS_eRp_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Implementierungsleitfaden Primärsysteme – E-Rezept

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
30.06.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS_eRp
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

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

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

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

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

Folgende Vorgaben gelten für die Prüfung der Serverzertifikate für den TLS-Verbindungsaufbau.

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

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 Authentifizierung der LEI

Die LEI authentisiert sich für Zugriffe auf Dienste der TI gegenüber der TI. Das PS erhält bei erfolgreicher Authentisierung einen Authentisierungstoken (ID_TOKEN), welcher für die Authentisierung bei den Diensten der TI weitergeleitet wird.

Für Informationen zum Ablauf der Authentisierung siehe [gemSpec_IdP_Dienst] und [gemSpec_IdP_Frontend].

Der Authenticator führt für die Authentisierung Challenge Response mit der AUT-Identität einer SMC-B der LEI durch. Hierfür wird der Konnektor genutzt.

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

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 können dem E-Rezept-Fachdienst Informationen über das abgegebene Medikament bereitgestellt werden, die dann vom Versicherten auf seinem FdV heruntergeladen werden können.

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

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.

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. Verfügbarkeitsanfragen, 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 Verfügbarkeitsanfrage
• • Informationen zum verordneten bzw. angefragten Medikament als Medication-Ressource
  • IK-Nummer des begünstigten Versicherten (unabhängig von der Versicherten-ID, da auch Vertreter Verfügbarkeitsanfragen stellen können)
  • 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. Verfügbarkeitsanfrage) 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.

Wenn die Abgabe ohne Änderung vollzogen wurde, wird der Dispensierdatensatz nonQES signiert.

Wenn die Abgabe mit einer Änderung in Bezug auf die Verordnungsdaten des verordnenden Arztes vollzogen wurde, wird der Datensatz mit einer qualifizierten elektronischen Signatur versehen. 

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:

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