gemF_eRp_EU_V1.0.0_CC
Prereleases:
Elektronische Gesundheitskarte und Telematikinfrastruktur
Feature:
EU Zugriff E-Rezept
| Version | 1.0.0_CC |
| Revision | 1078886 |
| Stand | 20.12.2024 |
| Status | zur Abstimmung freigegeben |
| Klassifizierung | öffentlich_Entwurf |
| Referenzierung | gemF_eRp_EU |
Dokumentinformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokuments im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
| Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
|---|---|---|---|---|
| 1.0.0_CC | 19.12.2024 | initiale Erstellung | gematik | |
ML-161756 - E-Rezept Feature: EU Zugriff E-Rezept
[<=]
Inhaltsverzeichnis
1 Einordnung des Dokuments
Dieses Dokument beschreibt das Feature zur Übermittlung von Verordnungen für Einlösen im europäischen Ausland für die Komponenten der Anwendung E-Rezept. Das Feature umfasst die Definition der Prozessparameter und Ergänzungen der workflowspezifischen Anforderungen an die Schnittstellen des E-Rezept-Fachdienstes sowie die Darstellung der Use Cases für Versicherte für das Management der Einwilligung und Zugriffsberechtigung zum Einlösen von E-Rezepten im europäischen Ausland.
1.1 Zielsetzung
Die Beschreibung des Funktionsumfangs als Feature erleichtert das Verständnis und die Nachvollziehbarkeit der Lösung, ausgehend von der Darstellung der Nutzersicht auf Epic-Ebene, über das technische Konzept bis zur Spezifikation der technischen Details. Mit den hier aufgestellten Anforderungen sollen Hersteller in der Lage sein, den zusätzlichen Funktionsumfang ihrer verantworteten Komponente bzw. Produkttyp bewerten und umsetzen zu können.
1.2 Zielgruppe
Das Dokument richtet sich an den Hersteller und Anbieter des Produkttyps E-Rezept-Fachdienst sowie Hersteller von Clientsystemen für den Zugriff auf den E-Rezept-Fachdienst.
1.3 Abgrenzungen
Die Festlegungen zum E-Rezept der bisher spezifizierten Workflows für apothekenpflichtige Arzneimittel sind nicht Gegenstand dieses Dokuments. Auch sollen die Ausführungen dieses Dokuments nicht im Widerspruch zu den bisherigen Festlegungen verstanden werden.
Folgende Aspekte sind nicht Gegenstand dieses Feature Dokuments:
- Anbindung der Telematikinfrastruktur (TI) an die eHealth Digital Service Infrastructure (eHDSI)
- Mapping der Informationen zwischen dem für die Verordnung in Deutschland und der Übermittlung im Rahmen des Einlösens im europäischen Ausland genutzten Datenmodell
- Abrechnung von im europäischen Ausland eingelösten E-Rezepten
1.4 Methodik
User Stories
Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurzgehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. [Wikipedia: User Story]
Aus diesem Grund kann in den User Stories eine abweichende Terminologie genutzt werden, welche für den Leser nachvollziehbar (bspw. Patient = Versicherter) ist.
Anforderungen / 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.
Anforderungen und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Anforderung / Titel des Anwendungsfalles>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung/der Anwendungsfall sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.
Hinweise 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 Epic und User Story
Das fachliche Konzept zum Einlösen von E-Rezepten im europäischen Ausland wurde im Rahmen von "Feature: ePrescription/eDispensation Land A" [gemF_ePres-eDisp] abgestimmt.
3 Einordnung in die Telematikinfrastruktur
Die Unterstützung des Einlösens von E-Rezepten im europäischen Ausland setzt auf die bestehende Infrastruktur der Anwendung E-Rezept auf.
Die Kommunikation mit den abgebenden Leistungserbringern im europäischen Ausland (LE-EU) wird durch den National Contact Point eHealth (NCPeH) in Deutschland gebündelt. Der NCPeH-Fachdienst (Deutschland) verbindet die TI mit der eHDSI. Der NCPeH-FD (Deutschland) ist ein neues Client System des E-Rezept-Fachdienst.
Der Versicherte nutzt für die Verwaltung von Einwilligung und Zugriffberechtigung ein E-Rezept-FdV, welches direkt mit dem E-Rezept-Fachdienst kommuniziert.
Abbildung 1 : Übersicht Architektur
4 Fachliches Konzept
4.1 Einlösbare Rezepte
Für das europäische Nutzungsszenario ePrescription/eDispensation dürfen folgende E-Rezepte nicht verarbeitet werden:
- Betäubungsmittel,
- Arzneimittel, die nach ärztlicher Verschreibung oder nach den Vorschriften eines Arzneibuchs für den Versicherten zubereitet werden (bezeichnet als "formula magistralis" oder "extemporale Zubereitungen"),
- Arzneimittel, die nicht durch ein industrielles Verfahren hergestellt oder bei deren Herstellung ein industrielles Verfahren angewandt wurde,
- Arzneimittel, die nicht als Humanarzneimittel eingestuft sind,
- noch nicht gültige oder abgelaufene E-Rezepte.
Zusätzlich bestehen Einschränkungen, wenn das Mapping aus den Verordnungsdaten in das geforderte europäische Datenformat nicht möglich ist.
Der E-Rezept-Fachdienst prüft bei Operationsaufrufen, ob die E-Rezepte die folgenden Kriterien erfüllen:
- Workflow 160 oder 200 (Verordnung für apothekenpflichtige Arzneimittel, keine Workflowsteuerung durch den Leistungserbringer)
- PZN-Verordnung (KBV_PR_ERP_Medication_PZN) mit strukturierter Angabe der Stückzahl sowie der Packungsgröße, getrennt nach Einheit und numerischem Wert
- Gültigkeitszeitraum ist erreicht
- Gültigkeitszeitraum ist nicht überschritten
- der Workflow zum E-Rezept hat den Status "offen"
Ein E-Rezept, welches die obigen Kriterien erfüllt, wird im Kontext dieses Features als einlösbares E-Rezept bezeichnet.
Ein Versicherter kann sich im E-Rezept-FdV anzeigen lassen, welche seiner E-Rezepte im europäischen Ausland einlösbar sind.
4.2 Autorisierung
4.2.1 Autorisierung des LE-EU für Zugriff auf die Anwendung E-Rezept
Die Authentisierung des LE-EU erfolgt im Land B (Ausland). Hierbei wird dem LE-EU eine Rolle zugeordnet. Bei der Übermittlung des Requests aus dem Land B zum NCPeH-FD (Deutschland) wird die Rollen-Information und ggf. eine Permission-Information übermittelt. Der NCPeH-FD (Deutschland) prüft die Permission für den Zugriff auf die Anwendung E-Rezept. Falls keine Permission übermittelt wurde, führt der NCPeH-FD (Deutschland) eine Rollenprüfung durch.
Der E-Rezept-Fachdienst führt keine Permission- oder Rollenprüfung durch.
4.2.2 Autorisierung des LE-EU für Zugriff auf Daten eines Versicherten
Ein Versicherter muss den Zugriff eines LE-EU auf seine E-Rezepte autorisieren. Dafür verwendet der Versicherte einen länderspezifischen zufälligen 6-stelligen alpha-nummerischen Zugriffscode (a-z, A-Z, 0-9) und übermittelt diesen zusammen mit seiner Versicherten-ID an den LE-EU.
Versicherten-ID und Zugriffscode bilden zusammen die Information zur Zugriffberechtigung und dienen der Autorisierung des LE-EU beim Operationsaufruf am E-Rezept-Fachdienst.
Der Zugriffscode wird dezentral im E-Rezept-Frontend des Versicherten erzeugt. Das E-Rezept-FdV registriert den Zugriffscode am E-Rezept-Fachdienst.
Ein Zugriffscode kann nur am E-Rezept-Fachdienst registriert werden, wenn eine "Einwilligung zum Einlösen im EU-Ausland" des Versicherten vorliegt.
Bei der Registrierung des Zugriffscodes am E-Rezept-Fachdienst wird geprüft, ob einlösbare Rezepte im E-Rezept-Fachdienst für die KVNR des Versicherten vorliegen. Falls keine einlösbaren E-Rezepte vorliegen, wird der Zugriffscode nicht registriert und der Versicherte erhält eine entsprechende Meldung in seinem E-Rezept-FdV.
Ein Zugriffscode ist eine Stunde gültig.
Der Versicherte kann einen Zugriffscode vor dem Ende des Gültigkeitszeitraumes löschen und somit die Zugriffsberechtigung widerrufen.
Wenn der Versicherte einen neuen Zugriffscode erstellt, dann wird ein zuvor bestehender Zugriffscode überschrieben und somit nicht mehr für die Autorisierung akzeptiert.
Der registrierte Zugriffscode wird dem Nutzer im E-Rezept-FdV zusammen mit dem Gültigkeitszeitraum angezeigt, damit der Nutzer den Zugriffscode der LEI-EU übermitteln kann.
Nach Ablauf der Gültigkeit löscht der E-Rezept-Fachdienst den Zugriffscode.
5 Technisches Konzept
5.1 Statusmodel des Workflows
Für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel in Deutschland wird das folgende Statusmodell umgesetzt.
Abbildung 2 : ABB_SYSLERP_001 Übersicht der Fachanwendung E-Rezept
Für die im Rahmen des Einlösens im europäischen Ausland vorgegebenen Prozessschritten kann das Statusmodell nicht unverändert angewandt werden, da kein Prozessschritt vorgesehen ist, ein zur Abgabe vorgesehenes E-Rezept an den Versicherten zurückzugeben, wenn die Abgabe nicht erfolgen kann.
Um die Möglichkeiten des Versicherten für den Zugriff auf seine E-Rezepte nicht einzuschränken, wird der Status wie folgt gesetzt.
Tabelle 1 : Statusübergänge
| Anwendungsfall | Status des E-Rezepts vor Operation |
Status des E-Rezepts nach Operation |
|---|---|---|
| UC Demographische Daten eines Versicherten abrufen | offen (ready) | offen (ready) |
| UC Auflistung von verfügbaren E-Rezepten des Versicherten | offen (ready) | offen (ready) |
| UC Abruf der abzugebenden E-Rezepten des Versicherten | offen (ready) | offen (ready) |
| UC Abgabe von Arzneimitteln an Versicherte im Abgabeland | offen (ready) | quittiert (completed) |
5.2 Use Cases zur Verwaltung der Einwilligung durch den Versicherten
Es werden die im Rahmen des Features "E-Rezepte für PKV-Versicherte: apothekenpflichtige Arzneimittel" eingeführten Anwendungsfälle zum Verwalten der "Einwilligung zum Speichern der Abrechnungsinformationen" verallgemeinert.
5.2.1 Einwilligung durch den Versicherten erteilen
Mit diesem Anwendungsfall kann der Versicherte seine "Einwilligung zum Einlösen im EU-Ausland" erteilen.
Die Einwilligung wird unbefristet erteilt.
AF_10084-01 - E-Rezept - Einwilligung durch Versicherten erteilen
Alle am Anwendungsfall "Einwilligung durch Versicherten erteilen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
Tabelle 2 : Einwilligung durch Versicherten erteilen
| Name | Einwilligung durch Versicherten erteilen |
|---|---|
| Vorbedingungen | Ein Versicherter hat eine Datenverarbeitung ausgewählt, für die er eine Einwilligung erteilen möchte. |
| Kurzbeschreibung (Außenansicht) |
Ein Versicherter wählt im E-Rezept-FdV die Operation zum Erteilen der Einwilligung auf. Der E-Rezept-Fachdienst speichert die Einwilligung. |
| Nachbedingungen | Die Einwilligung ist im E-Rezept-Fachdienst gespeichert. Das Erteilen der Einwilligung ist im E-Rezept-Fachdienst protokolliert. |
Abbildung 3 : SD Einwilligung durch Versicherten erteilen
[<=]5.2.2 Einwilligung durch den Versicherten widerrufen
Mit diesem Anwendungsfall kann der Versicherte seine zuvor erteilte Einwilligung auf dem E-Rezept-Fachdienst widerrufen.
AF_10085-01 - E-Rezept - Einwilligung durch Versicherten widerrufen
Alle am Anwendungsfall "Einwilligung durch Versicherten widerrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
Tabelle 3 : Einwilligung durch Versicherten widerrufen
| Name | Einwilligung durch Versicherten widerrufen |
|---|---|
| Vorbedingungen | Ein Versicherter hat eine Datenverarbeitung ausgewählt, für die er eine Einwilligung widerrufen möchte. Im E-Rezept-FdV liegt die Information vor, dass die Einwilligung für diese Datenverarbeitung erteilt wurde. |
| Kurzbeschreibung (Außenansicht) |
Ein Versicherter wählt über ein E-Rezept-FdV die Operation zum Widerrufen der Einwilligung auf. Der E-Rezept-Fachdienst prüft, ob zuvor die Einwilligung erteilt wurde und löscht diese. Der E-Rezept-Fachdienst löscht für die Einwilligung relevante Daten unwiederbringlich. |
| Nachbedingungen | Das Widerrufen der Einwilligung ist im E-Rezept-Fachdienst protokolliert. |
Abbildung 4 : SD Einwilligung durch Versicherten widerrufen
[<=]Hinweis zu relevanten Daten: Mit dem Widerruf der "Einwilligung zum Einlösen im EU-Ausland" wird ein ggf. zuvor registrierter Zugriffscode gelöscht.
5.2.3 Einwilligungen durch den Versicherten einsehen
Mit diesem Anwendungsfall kann der Versicherte einsehen, welche Einwilligungen auf dem E-Rezept-Fachdienst für seine KVNR hinterlegt sind.
AF_10086-01 - E-Rezept - Einwilligungen durch Versicherten einsehen
Alle am Anwendungsfall "Einwilligungen durch Versicherten einsehen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
Tabelle 4 : Einwilligungen durch Versicherten einsehen
| Name | Einwilligungen durch Versicherten einsehen |
|---|---|
| Vorbedingungen | keine |
| Kurzbeschreibung (Außenansicht) |
Das E-Rezept-FdV führt die Operation zum Abfrage der Einwilligungen aus. Der E-Rezept-Fachdienst gibt die Information an das E-Rezept-FdV. |
| Nachbedingungen | Die Information steht zur Anzeige im E-Rezept-FdV bereit. |
Abbildung 5 : SD Einwilligungen durch Versicherten einsehen
[<=]5.3 Use Cases zur Verwaltung der Zugriffsberechtigung durch den Versicherten
5.3.1 Zugriffberechtigung durch Versicherten erstellen
AF_10395 - E-Rezept - Zugriffsberechtigung durch Versicherten erstellen
Alle am Anwendungsfall "Zugriffsberechtigung durch Versicherten erstellen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
Tabelle 5 : Zugriffsberechtigung durch Versicherten erstellen
| Name | Zugriffsberechtigung durch Versicherten erstellen |
|---|---|
| Vorbedingungen | Der Versicherte hat seine "Einwilligung zum Einlösen im EU-Ausland" erteilt. Im E-Rezept-FdV liegt die Information vor, welche europäischen Länder das Einlösen von in Deutschland verordneten E-Rezepten unterstützen. |
| Kurzbeschreibung (Außenansicht) |
Der Nutzer wählt im E-Rezept-FdV das Land aus, in dem er sein Rezepte einlesen möchte und fordert einen Zugriffscode an. Das E-Rezept-FdV erstellt einen zufälligen Zugriffscode. Das E-Rezept-FdV übermittelt den Zugriffscode und die Länderinformation an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst prüft die Einwilligung, löscht einen ggf. bestehenden Zugriffscode, hinterlegt den übermittelten Zugriffscode und liefert die Gültigkeitsdauer des Zugriffscodes an das E-Rezept-FdV. |
| Nachbedingungen | Der Zugriffscode ist im E-Rezept-Fachdienst hinterlegt und kann zur Autorisierung des Zugriffs eines LE-EU genutzt werden. Der Zugriffscode und die Gültigkeitsdauer können im E-Rezept-FdV angezeigt werden. |
Abbildung 6 : SD Zugriffsberechtigung durch Versicherten erstellen
[<=]
5.3.2 Zugriffberechtigung durch Versicherten löschen
Mit diesem Anwendungsfall kann der Versicherte eine zuvor erstellte Zugriffsberechtigung löschen.
AF_10405 - E-Rezept - Zugriffsberechtigung durch Versicherten löschen
Alle am Anwendungsfall "Zugriffsberechtigung durch Versicherten löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
Tabelle 6 : Zugriffsberechtigung durch Versicherten löschen
| Name | Zugriffsberechtigung durch Versicherten löschen |
|---|---|
| Vorbedingungen | keine |
| Kurzbeschreibung (Außenansicht) |
Der Nutzer wählt im E-Rezept-FdV aus, dass er eine bestehende Zugriffsberechtigung löschen möchte. Das E-Rezept-FdV übermittelt den Löschwunsch an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst löscht eine ggf. bestehende Zugriffsberechtigung. Das E-Rezept-FdV löscht die Zugriffsberechtigung. |
| Nachbedingungen | Es ist keine Zugriffsberechtigung für den Versicherten im E-Rezept-Fachdienst registriert. Die Zugriffsberechtigung wird im E-Rezept-FdV nicht mehr angezeigt. |
Abbildung 7 : SD Zugriffsberechtigung durch Versicherten löschen
[<=]5.3.3 Zugriffberechtigung durch Versicherten einsehen
Mit diesem Anwendungsfall kann der Versicherte sich einen eine Zugriffsberechtigung im E-Rezept-FdV anzeigen lassen, wenn die Informationen zur Zugriffsberechtigung nicht lokal im E-Rezept-FdV gespeichert sind.
AF_10406 - E-Rezept - Zugriffsberechtigung durch Versicherten einsehen
Alle am Anwendungsfall "Zugriffsberechtigung durch Versicherten einsehen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
Tabelle 7 : Zugriffsberechtigung durch Versicherten einsehen
| Name | Zugriffsberechtigung durch Versicherten einsehen |
|---|---|
| Vorbedingungen | keine |
| Kurzbeschreibung (Außenansicht) |
Das E-Rezept-FdV führt die Operation zum Abfrage der Zugriffsberechtigung aus. Der E-Rezept-Fachdienst gibt die Information an das E-Rezept-FdV. |
| Nachbedingungen | Die Daten zur Zugriffsberechtigung stehen im E-Rezept-FdV zur Anzeige bereit. |
Abbildung 8 : SD Zugriffsberechtigung durch Versicherten einsehen
[<=]5.4 Use Cases im Rahmen der Belieferung durch eine Apotheke im europäischen Ausland
5.4.1 Demographische Daten eines Versicherten abrufen
AF_10396 - E-Rezept - Demographische Daten eines Versicherten abrufen
Die am Anwendungsfall "Demographische Daten eines Versicherten abrufen" beteiligten Produkttypen und Komponenten der Anwendung E-Rezept MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | Demographische Daten eines Versicherten abrufen |
|---|---|
| Vorbedingungen | Der Versicherte hat seine Einwilligung zum Einlösen im EU-Ausland erteilen (Anwendungsfall "Einwilligung durch Versicherten erteilen"). Der Versicherte hat eine Zugriffsberechtigung für Land B erteilt (Anwendungsfall "Zugriffsberechtigung durch Versicherten erstellen"). |
| Kurzbeschreibung (Außenansicht) |
Der Versicherte übermittelt die Informationen zur Zugriffsberechtigung an den LE-EU. Der LE-EU informiert den Versicherten über die Datenschutzrechte. Der Versicherte willigt gegenüber dem LE-EU in die Verarbeitung der Daten ein. Der LE-EU sendet einen Request über den eHDSI an das Land A (Deutschland). Der NCPeH-FD (Deutschland) prüft die Permission aus der Anfrage und falls nicht vorhanden die Rolle des anfragenden LE-EU. Der NCPeH-FD (Deutschland) sendet einen Request für die Liste einlösbarer E-Rezepte des Versicherten an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst übermittelt das aktuellste einlösbaren E-Rezept an den NCPeH-FD (Deutschland). Der NCPeH-FD (Deutschland) extrahiert die notwendigen Informationen und erstellt den Response für den LE-EU. |
| Nachbedingungen | Der Status der einlösbaren E-Rezepte des Versicherten ist unverändert. Die Abfrage ist im E-Rezept-Fachdienst protokolliert. Der LE-EU stehen die demographischen Daten des Versicherten zur Verfügung. |
Abbildung 9 : SD Demographische Daten eines Versicherten abrufen
[<=]5.4.2 Liste der einlösbaren E-Rezepte eines Versicherten abrufen
AF_10397 - E-Rezept - Liste der einlösbaren E-Rezepte eines Versicherten abrufen
Die am Anwendungsfall "Liste der einlösbaren E-Rezepte eines Versicherten abrufen" beteiligten Produkttypen und Komponenten der Anwendung E-Rezept MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | Liste der einlösbaren E-Rezepte eines Versicherten abrufen |
|---|---|
| Vorbedingungen | Der Versicherte hat eine Zugriffsberechtigung für Land B erteilt. Der Versicherte hat die Informationen zur Zugriffsberechtigung an den LE-EU übermittelt. (Anwendungsfall "Demographische Daten eines Versicherten abrufen") |
| Kurzbeschreibung (Außenansicht) |
Der LE-EU sendet einen Request über den eHDSI an das Land A (Deutschland). Der NCPeH-FD (Deutschland) prüft das Vorliegen einer Behandlungsbeziehung zwischen LE-EU und Versicherten. Der NCPeH-FD (Deutschland) prüft die Permission aus der Anfrage und falls nicht vorhanden die Rolle des anfragenden LE-EU. Der NCPeH-FD (Deutschland) sendet einen Request für die Liste einlösbarer E-Rezepte des Versicherten an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst übermittelt die Liste der einlösbaren E-Rezepte an den NCPeH-FD (Deutschland). Der NCPeH-FD (Deutschland) extrahiert die notwendigen Informationen, transkodiert die Informationen und erstellt den Response für den LE-EU. |
| Nachbedingungen | Der Status der einlösbaren E-Rezepte des Versicherten ist unverändert. Die Abfrage ist im E-Rezept-Fachdienst protokolliert. Der LE-EU stehen die Liste der einlösbaren E-Rezepte des Versicherten zur Verfügung. |
Abbildung 10 : SD Liste der einlösbaren E-Rezepte eines Versicherten abrufen
[<=]5.4.3 Liste ausgewählter E-Rezepte eines Versicherten abrufen
AF_10398 - E-Rezept - Liste ausgewählter E-Rezepte eines Versicherten abrufen
Die am Anwendungsfall "Liste ausgewählter E-Rezepte eines Versicherten abrufen" beteiligten Produkttypen und Komponenten der Anwendung E-Rezept MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | Liste ausgewählter E-Rezepte eines Versicherten abrufen |
|---|---|
| Vorbedingungen | Der Versicherte hat eine Zugriffsberechtigung für Land B erteilt. Der Versicherte hat die Informationen zur Zugriffsberechtigung an den LE-EU übermittelt. (Anwendungsfall "Demographische Daten eines Versicherten abrufen") Der LE-EU hat die Liste der einlösbaren E-Rezepte für den Versicherten abgerufen. |
| Kurzbeschreibung (Außenansicht) |
Der LE-EU sendet einen Request mit einer Liste von Rezept-IDs ,über den eHDSI an das Land A (Deutschland). Der NCPeH-FD (Deutschland) prüft das Vorliegen einer Behandlungsbeziehung zwischen LE-EU und Versicherten. Der NCPeH-FD (Deutschland) prüft die Permission aus der Anfrage und falls nicht vorhanden die Rolle des anfragenden LE-EU. Der NCPeH-FD (Deutschland) sendet einen Request mit der Liste von Rezept-IDs des Versicherten an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst übermittelt die Liste der E-Rezepte an den NCPeH-FD (Deutschland). Der NCPeH-FD (Deutschland transformiert und transkodiert die E-Rezepte in das entsprechende eHDSI-Dokumentenformat und erstellt den Response für den LE-EU. |
| Nachbedingungen | Der Status der einlösbaren E-Rezepte des Versicherten ist unverändert. Die Abfrage ist im E-Rezept-Fachdienst protokolliert. Der LE-EU stehen die Liste der E-Rezepte des Versicherten zur Verfügung. |
Abbildung 11 : SD Liste ausgewählter E-Rezepte eines Versicherten abrufen
[<=]5.4.4 Abgabe von E-Rezepten im europäischen Ausland
Offener Punkt: Für den Anwendungsfall "Abgabe von E-Rezepten im europäischen Ausland" wird angenommen, dass die vollständigen Dispensierinformationen zu einer ePrescription (E-Rezept) in genau einem eDispensation Dokument (CDA) vom LE-EU übermittelt werden.
AF_10399 - E-Rezept - Abgabe von E-Rezepten im europäischen Ausland
Die am Anwendungsfall "Abgabe von E-Rezepten im europäischen Ausland" beteiligten Produkttypen und Komponenten der Anwendung E-Rezept MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | Abgabe von E-Rezepten im europäischen Ausland |
|---|---|
| Vorbedingungen | Der Versicherte hat eine Zugriffsberechtigung für Land B erteilt. Der Versicherte hat die Informationen zur Zugriffsberechtigung an den LE-EU übermittelt. (Anwendungsfall "Demographische Daten eines Versicherten abrufen") Der LE-EU hat ausgewählte E-Rezepte des Versicherten abgerufen. |
| Kurzbeschreibung (Außenansicht) |
Der Versicherte übermittelt, falls der zuvor übermittelte Zugriffscode zeitlich nicht mehr gültig ist, einen neuen Zugriffscode an den LE-EU. Der LE-EU sendet einen eDispensation Request für ein E-Rezept über den eHDSI an Land A (Deutschland). Der NCPeH-FD (Deutschland) prüft das Vorliegen einer Behandlungsbeziehung zwischen LE-EU und Versicherten. Der NCPeH-FD (Deutschland) prüft die Permission und falls nicht vorhanden die Rolle des anfragenden LE-EU. Der NCPeH-FD (Deutschland) transformiert und transkodiert die Information zu jedem eDispensation Document in einen Dispensierinformationsdatensatz für das E-Rezept. Der NCPeH-FD (Deutschland) sendet für jedes übermittelte eDispensation Document (CDA) einen Request mit den Dispensierinformationsdatensatz für das E-Rezept an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst speichert die Dispensierinformationen und ändert den Status des Task zu "completed". Der E-Rezept-Fachdienst übermittelt den Status der Operation an den NCPeH-FD (Deutschland). Der NCPeH-FD (Deutschland) übermittelt den Status an den LE-EU. |
| Nachbedingungen | Der Status der eingelösten E-Rezepte ist "completed". Der Datenzugriff ist im E-Rezept-Fachdienst für jedes E-Rezept protokolliert. |
Abbildung 12 : SD Abgabe von E-Rezepten im europäischen Ausland
[<=]
Nach der Bereitstellung der Dispensierinformationen im E-Rezept-Fachdienst kann der Versicherte diese mit seinem E-Rezept-FdV herunterladen und anzeigen lassen. Eine Übermittlung der Dispensierinformationen an den ePA Medication Service ist aktuell nicht vorgesehen.
6 Datenschutz und Informationssicherheit
Die gesetzlichen Grundlagen zu diesem Feature sind insbesondere in § 361 Abs. 5 SGB V festgelegt. Danach muss der Versicherte vor einem Zugriff von Leistungserbringern aus dem EU-Ausland über den NCPeH in Deutschland grundsätzlich in die Übermittlung eingewilligt haben. Zudem muss der Versicherte jeden konkreten Zugriff durch einen Leistungserbringer aus dem EU-Ausland (LE-EU) in diesem Rahmen technisch freigeben. Die Einwilligung wird durch den Versicherten mittels eines FdV mit E-Rezept-Funktionalität gegeben (bzw. widerrufen) und im E-Rezept-Fachdienst gespeichert (bzw. gelöscht). Sie ist länderunspezifisch, d.h. sie gilt für alle teilnehmenden Länder in der EU. In der Umsetzung kann die Einwilligung in das Verfahren in Verbindung mit der ersten Freigabe eines Zugriffs für einen LE-EU erfolgen.
Die technische Freigabe für einen Leistungserbringer im EU-Ausland erteilt der Versicherte durch einen sechsstelligen alphanumerischen Zugriffscode, den er im FdV angezeigt bekommt und die er dem Leistungserbringer mitteilt (z.B. durch Vorzeigen des im FdV angezeigten Zugriffscodes). Der Zugriffscode ist nach der Erzeugung einen begrenzten Zeitraum (höchstens eine Stunde) gültig. Nach Ablauf dieses Zeitraums muss ein neuer Zugriffscode erzeugt werden. Der Versicherte kann auch vor Ablauf des Zeitraums einen neuen Zugriffscode erzeugen, wobei der vorherige Zugriffscode damit ungültig wird. Der E-Rezept-Fachdienst erhält den jeweils gültigen Zugriffscode vom FdV und lehnt Anfragen mit einem ungültigen Zugriffscode ab. Neben dem Zugriffscode erhält der E-Rezept-Fachdienst vom FdV die Information, in welchem Land der aktuelle Zugriffscode Verwendung finden soll. Die Information, in welchem Land sich der LE-EU befindet, das den Zugriffscode bei einer Abfrage präsentiert, erhält der E-Rezept-Fachdienst vom deutschen NCPeH. Stimmen die beiden Informationen nicht überein, lehnt der E-Rezept-Fachdienst die Anfrage ebenfalls ab.
Anwendungsfälle
Aus diesem Feature ergeben sich für den E-Rezept-Fachdienst ein neuer direkter Akteur, der NCPeH in Deutschland, der zur Ausführung folgender Anwendungsfälle mit seiner eigenen kryptografischen Identität auf den E-Rezept-Fachdienst zugreift:
- Demographische Daten eines Versicherten abrufen
Damit berechtigte LE-EU die E-Rezepte des Versicherten abrufen können, ist es notwendig, die demografischen Daten des Versicherten zuvor in Deutschland ermitteln zu lassen. Ein LE-EU kann die ermittelten demografischen Versichertendaten mit den auf der eGK abgebildeten Daten vergleichen und so auf Richtigkeit prüfen. Die Ermittlung dieser Daten erfolgt aus einem E-Rezept des Versicherten im E-Rezept-Fachdienst – sofern mindestens eines vorhanden ist.
- Liste der einlösbaren E-Rezepte eines Versicherten abrufen
Mittels KVNR und Zugriffscode ruft der LE-EU die Liste aller einlösbaren E-Rezepte vom E-Rezept-Fachdienst ab. Dabei liefert der E-Rezept-Fachdienst alle Informationen aus den E-Rezepten an den NCPeH, der zur Erstellung der Liste nur bestimmte Informationen verwendet (mindestens die obligatorischen Angaben gemäß den europäischen Vorgaben). Der E-Rezept-Fachdienst liefert keine Informationen zu E-Rezepten, die in den europäischen Vorgaben definiert sind: z.B. Betäubungsmittel und Arzneimittel, die nach ärztlicher Verschreibung oder nach den Vorschriften eines Arzneibuchs für den Versicherten zubereitet werden.
- Liste ausgewählter E-Rezepte eines Versicherten abrufen
Ausgehend von der Liste der einlösbaren E-Rezepte für einen Versicherten, kann der LE-EU eine Liste der zur Einlösung ausgewählten E-Rezepte abrufen (transkodiert und im Original).
- Abgabe von E-Rezepten im europäischen Ausland
Beim Einlösen von E-Rezepten erfolgt die Übermittlung der Datensätze über die an den Versicherten abgegebenen Arzneimittel mittels des NCPeH an den E-Rezept-Fachdienst.
Daneben gibt es die Anwendungsfälle für die Versicherten zur Erteilung, zur Einsicht und zum Widerruf der Einwilligung.
Aufgrund der starken Abhängigkeit von Systemen außerhalb der TI werden keine Aussagen zur Verfügbarkeit dieser Anwendungsfälle getroffen. Die Verfügbarkeit der Komponenten bzw. Dienste der TI ist hierfür in jedem Fall ausreichend.
Informationsobjekte
Durch dieses Feature werden die folgenden wesentlichen Informationsobjekte eingeführt:
| Informations-objekt | Beschreibung | Personen-bezug | Vertraulichkeit | Integrität |
|---|---|---|---|---|
| Zugriffscode | Sechsstelliger alphanumerischer Zugriffscode zur Autorisierung eines LE-EU zum Abruf und Einlösung von E-Rezepten eines Versicherten. | nein | hoch Der Schutzbedarf für die Vertraulichkeit des Freischaltcodes wird mit „hoch“ bewertet, da der Zugriffscode zwar für den Zugriff auf E-Rezepte bzw. deren Einlösung erforderlich ist, die Kenntnis des Zugriffscodes alleine aber nicht für das Einlösen eines E-Rezepts ausreicht. |
hoch Eine Verletzung der Integrität verhindert den Zugriff auf E-Rezepte. |
Authentifizierung und Autorisierung
Der NCPeH in Deutschland ist ein neuer (VAU-) Client und neuer Produkttyp im E-Rezept-System. Die Authentifizierung des NCPeH in Deutschland findet durch den Authorization Server des E-Rezept-Fachdienstes statt, der einen AccessToken ausstellt, der im E-Rezept-Fachdienst validiert wird. Dabei findet ein länderspezifisches Zertifikat Verwendung – also nicht das Zertifikat des NCPeH in Deutschland, sondern ein Zertifikat, dass den NCPeH im jeweilig anfragenden EU-Ausland repräsentiert.
Indirekt wirkende Akteure sind Leistungserbringer im EU-Ausland, die über den NCPeH in ihrem Land und den NCPeH in Deutschland Daten aus dem E-Rezept-Fachdienst abrufen können. Die Authentisierung der Leistungserbringer im EU-Ausland erfolgt durch den NCPeH in ihrem Land (vgl. unten Grenzen der Sicherheitsleistung).
Die Kommunikation zwischen dem NCPeH und dem E-Rezept-Fachdienst erfolgt zum einen über TLS mit server-seitiger Authentifizierung des E-Rezept-Fachdienstes und zum anderen mittels VAU-Verschlüsselung zwischen der VAU im NCPeH und VAU im E-Rezept-Fachdienst. Hierbei prüft der E-Rezept-Fachdienst das VAU-Zertifikat der VAU im NCPeH. Hierdurch wird eine beidseitige Authentifizierung der Systeme erreicht.
Der Zugriffscode dient – in Kombination mit der KVNR - der Autorisierung eines LE-EU zum Abruf der E-Rezepte eines Versicherten.
Protokollierung
Die Protokollierung im E-Rezept-Fachdienst erfolgt für alle o.g. Anwendungsfälle und umfasst jeweils folgende Informationen:
- das Land, aus dem der Zugriff erfolgte,
- die Leistungserbringerinstitution, aus der der Zugriff erfolgte,
- der Leistungserbringer-EU, der zugegriffen hat,
- der ausgeführte Anwendungsfall,
- falls ein E-Rezept eingelöst wurde: die Rezept-ID,
- der Zeitpunkt des Zugriffs,
- ob der Zugriff erfolgreich war bzw. (in für den Versicherten verständlicher Sprache) bzw. warum ein Zugriff abgelehnt wurde.
Abgelehnte Zugriffsversuche werden nur protokolliert, wenn die KVNR in Verbindung mit dem Zugriffscode passen, damit der Versicherte erkennen kann, ob er alle Voraussetzungen geschaffen hat, um es dem LE-EU zu ermöglichen, seine E-Rezepte abzurufen. Gründe für eine Ablehnung können sein:
- Die Einwilligung wurde zwischenzeitlich entzogen.
- Es liegen keine einlösbaren E-Rezept vor, aus denen die Daten extrahierbar wären.
Falls die Kombination von KVNR und Zugriffscode nicht korrekt war, wird kein Protokolleintrag erzeugt, da eine Ablehnung auch an einer falschen KVNR liegen kann. In diesem Fall würde der Versicherte mit der übertragenden KVNR einen Protokolleintrag über einen abgelehnten Zugriff sehen, obwohl er keine Einlösung im Ausland ausgelöst hat. Da es sich aber nicht um einen Angriff handelt, könnte der Versicherte aus einem Protokolleintrag keine sinnvolle Handlung ableiten.
Angriffe durch massenweises Durchprobieren von KVNR- und Zugriffscode-Kombinationen müssen durch die NCPeH und den E-Rezept-Fachdienst mitigiert werden. In Verdachtsfällen müssen die Protokolle in den NCPeH ausgewertet werden.
Robustheit
Der NCPeH in Deutschland prüft bei Anfragen an den E-Rezept-Fachdienst, ob die mitgegebene KVNR syntaktisch korrekt ist und dass der Zugriffscode sechsstellig ist. Damit werden syntaktisch unkorrekte Anfragen bereits im NCPeH abgeblockt. Generell muss der Anbieter des NCPeH-Fachdienstes Maßnahmen zur Erkennung und Verhinderung von dem Erraten eines Zugriffscodes umsetzen.
Grenzen der Sicherheitsleistung
Der E-Rezept-Fachdienst muss von integren und korrekt arbeitenden NCPeHs ausgehen.
In der Realisierung der o.g. Anwendungsfälle übernehmen die NCPeH im EU-Ausland die Authentisierung der Leistungserbringer im jeweiligen Land. Anfragen von nichtauthentisierten Leistungserbringern werden nicht an den NCPeH in Deutschland weitergeleitet und damit auch nicht an den E-Rezept-Fachdienst. Dies gilt auch für Anfragen aus EU-Ländern, die nicht in der Liste der teilnehmenden Länder stehen.
Der NCPeH in Deutschland protokolliert jegliche Transaktion, in der er involviert ist. Wie ein Betroffener diese Protokolldaten einsehen kann, wird durch den Betreiber des NCPeH geregelt.
Der NCPeH in Deutschland muss grundlegende Denial-of-Service-Abwehrmechanismen implementieren. Diese sind nicht näher spezifiziert und deshalb kann hier auch keine Annahme über deren Wirksamkeit getroffen werden. Zumindest werden nur Anfragen mit syntaktisch korrekten KVNRs und ausschließlich sechsstelligen Zugriffscodes weitergereicht.
Über die Sicherheit der Systeme der LE-EU kann keine Aussage getroffen werden. Ggf. ist die Situation in den verschiedenen EU-Ländern unterschiedlich.
Aufgrund der Vorgaben der EU können Situationen entstehen, in denen eine Mehrfacheinlösung von E-Rezepten durch den E-Rezept-Fachdienst nicht verhindert werden kann. Dies betrifft insbesondere Situationen in grenznahen Gebieten, in denen ein Versicherter erst eine Einlösung im Ausland initiiert, aber das Medikament noch nicht erhält, er dann das E-Rezept in Deutschland regulär einlöst, um dann zurück in der EU-Apotheke das Medikament nochmals zu erhalten – sofern die EU-Apotheke das Medikament ausgibt, obwohl der E-Rezept-Fachdienst einen Fehler meldet (z.B. um den Umsatz dennoch zu machen). Ein finanzieller Schaden für Apotheken im Ausland würde hierbei nicht entstehen, da Versicherte die im Ausland erhaltenen Medikamente zunächst selbst bezahlen. Kostenträger können einen finanziellen Schaden abwenden, wenn sie durch geeignete Prüfungen eine oben geschilderte mehrfache Einlösung eines E-Rezepts feststellen. Für Apotheker in Deutschland könnte ein finanzieller Schaden entstehen, falls der Kostenträger einem Versicherten die Rechnung für ein im Ausland erhaltenes Medikament erstattet, bevor die Abrechnung des E-Rezepts durch die Apotheke in Deutschland erfolgt – unter der Annahme, dass der Kostenträger in diesem Fall das E-Rezept nicht noch einmal abrechnen wird. Solche Schadensszenarien können nicht durch die Komponenten und Dienste der TI abgewendet werden.
7 Spezifikation
7.1 Anforderungen an den E-Rezept-Fachdienst
Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_FD_eRp] übernommen.
7.1.1 Änderung in 5.2.3 Verwaltung der Nutzersession
alt:
A_19992 - E-Rezept-Fachdienst - Blocklisting zu häufig verwendeter ACCESS_TOKEN
Der E-Rezept-Fachdienst MUSS ein während einer konfigurierbaren Dauer vielfach vorgelegtes ACCESS_TOKEN (z.B. mehr als 10 mal innerhalb einer Sekunde) für den Rest der angegebenen Gültigkeitsdauer auf einer Blocklist führen und eingehende HTTP-Requests mit diesem ACCESS_TOKEN mit dem HTTP-Status-Code 429 ablehnen, damit ein Überlastungsangriff (DOS-Attacke) auf den E-Rezept-Fachdienst unterbunden werden kann. [<=]
neu:
A_19992-01 - E-Rezept-Fachdienst - Blocklisting zu häufig verwendeter ACCESS_TOKEN
Der E-Rezept-Fachdienst MUSS ein während einer konfigurierbaren Dauer vielfach vorgelegtes ACCESS_TOKEN (z.B. mehr als 10 mal innerhalb einer Sekunde) für den Rest der angegebenen Gültigkeitsdauer auf einer Blocklist führen und eingehende HTTP-Requests mit diesem ACCESS_TOKEN mit dem HTTP-Status-Code 429 ablehnen, damit ein Überlastungsangriff (DOS-Attacke) auf den E-Rezept-Fachdienst unterbunden werden kann.
Der E-Rezept-Fachdienst MUSS bei diese Prüfung die ACCESS_TOKEN des NCPeH-FD (Rolle "professionOID" = oid_ncpeh) ausnehmen. [<=]
7.1.2 Änderungen in 5.3 Routing von Requests
alt:
A_21572 - E-Rezept-Fachdienst - Routing-Informationen X-erp-user
Der Eingangspunkt des E-Rezept-Fachdienstes KANN eine Routingentscheidung zu einem nutzergruppenspezifischen Verarbeitungskontext anhand des Headers "X-erp-user" mit Wertebereich [l, v, k, s] im äußeren http-Request treffen. [<=]
Die Werte sollen von Clients des E-Rezepts wie folgt verwendet werden:
- l (kleines L) - Leistungserbringer
- v - Versicherte
- k - Kostenträger
- s - Sonstige (aktuell nicht verwendet)
neu:
A_21572-01 - E-Rezept-Fachdienst - Routing-Informationen X-erp-user
Der E-Rezept-Fachdienstes KANN am Eingangspunkt eine Routingentscheidung zu einem nutzergruppenspezifischen Verarbeitungskontext anhand des Headers "X-erp-user" im äußeren http-Request treffen. [<=]
Die Werte sollen von Clients des E-Rezepts wie folgt verwendet werden:
- l (kleines L) - Leistungserbringer
- v - Versicherte
- k - Kostenträger
- n - NCPeH
7.1.3 Änderungen in 5.4 Fehlercodes
Änderung in TAB_eRPFD_003 Übersicht Http-Statuscodes
| Http-Status-Code | Bedeutung | in welchen Operationen als Statuscode möglich | Bedingung |
|---|---|---|---|
| 200 | Operation erfolgreich beendet, in der Rückgabe ist ggfs. das Ergebnis der Operation enthalten | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission GET /$read-eu-access-permission |
Die Operation wurde erfolgreich bearbeitet. In der Rückgabe sind die erzeugten bzw. gelesenen Daten enthalten. |
| 204 | Die Operation liefert keinen Rückgabewert | ... DELETE /$revoke-eu-access-permission |
|
| 400 | Bad Request, der Operationsaufruf enthält ungültige Daten. | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission DELETE /$revoke-eu-access-permission GET /$read-eu-access-permission |
In der aufgerufenen Operation werden vom Client Daten für die Verarbeitung erwartet. Entsprechen sie nicht dem erwarteten FHIR-Profil oder sind sie ungültig (bspw. Signatur), werden sie vom E-Rezept-Fachdienst zurückgewiesen. |
| 401 | Der Nutzer konnte nicht authentifiziert werden | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission DELETE /$revoke-eu-access-permission GET /$read-eu-access-permission |
Der Aufruf enthält keine oder abgelaufene oder ungültige Authentifizierungsinformationen im HTTP-Request-Header "Authorization" |
| 403 | Der Nutzer ist nicht berechtigt, die aufgerufene Operation anzufordern | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission DELETE /$revoke-eu-access-permission GET /$read-eu-access-permission |
Gemäß Rollenprüfung in jedem Operationsaufruf sind nur bestimmte Operationen je aufrufendem Nutzer zulässig. |
| 404 | Die adressierte Ressource wurde nicht gefunden. | ... POST /Task/<id>/$eu-close |
Die über die <id> adressierte Ressource existiert nicht, d.h. wurde auch nicht zwischenzeitlich gelöscht (siehe Code 410). |
| 405 | Die Anfrage ist gültig, jedoch in Kombination mit anderen Aufrufparametern nicht gültig | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission DELETE /$revoke-eu-access-permission GET /$read-eu-access-permission |
In der Operation wird eine unzulässige Kombination aus Http-Operation auf eine bestimmte Ressource ggfs. in Verbindung mit einer FHIR-Operation aufgerufen ... |
| 408 | Request Timeout. Die Anfrage konnte innerhalb der erwarteten Zeit nicht beantwortet werden | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission DELETE /$revoke-eu-access-permission GET /$read-eu-access-permission |
Der E-Rezept-Fachdienst ist überlastet und kann die Anfrage innerhalb der Wartezeit des Clientsystems nicht beantworten. |
| 429 | Der Client hat zu viele Aufrufe innerhalb einer festgelegten Zeitspanne getätigt | ... POST /Task/<id>/$eu-close POST /$get-eu-prescriptions POST /$grant-eu-access-permission |
Das Clientsystem hat innerhalb des konfigurierten Zeitabschnitts zu viele Requests geschickt |
7.1.4 Änderungen in 5.5 Protokollierungen
Alt:
A_19284-10 - E-Rezept-Fachdienst - Versichertenprotokoll zu Operationen
Der E-Rezept-Fachdienst MUSS jeden Aufruf der folgenden Operationen protokollieren:
Tabelle 8: TAB_eRPFD_004 Versichertenprotokoll
| Operation | Rolle des zugreifenden Nutzers |
Beschreibung (ggfs. als Vorschlag für einen lesbaren Protokolleintrag in einfacher Sprache) |
|---|---|---|
| http GET /Task/<id> | ||
| - | Versicherter, Vertreter |
Patient/Versicherter/Vertreter hat das E-Rezept heruntergeladen |
| Apotheker | Apotheke hat die E-Rezept-Quittung heruntergeladen | |
| http GET /Task | ||
| Apotheker | im Erfolgsfall beim passenden AcceptPN3VSDMxx=false: Apotheke hat mit Ihrer eGK die Liste der offenen E-Rezepte abgerufen. im Erfolgsfall bei PN3 und passende AcceptPN3VSDMxx=true: Apotheke hat mit Ihrer eGK die Liste der offenen E-Rezepte abgerufen. (Offline-Check wurde akzeptiert) im Fehlerfall PN3 und passende AcceptPN3VSDMxx=false: Apotheke konnte aufgrund eines Fehlerfalls nicht die Liste der offenen E-Rezepte mit Ihrer eGK abgerufen. (Offline-Check wurde nicht akzeptiert) im sonstigen Fehlerfall: Apotheke konnte aufgrund eines Fehlerfalls nicht die Liste der offenen E-Rezepte mit Ihrer eGK abgerufen. |
|
| Kostenträger | Krankenkasse hat die Liste der offenen E-Rezepte (DiGA-Verordnungen) abgerufen. | |
| http POST /Task | ||
| $activate | Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut | Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut hat das E-Rezept bereitgestellt |
| $accept | Apotheke | Apotheke hat das E-Rezept heruntergeladen |
| Kostenträger | Krankenkasse hat das E-Rezept heruntergeladen | |
| $reject | Apotheke | Apotheke hat das E-Rezept zurückgegeben |
| Kostenträger | Krankenkasse hat das E-Rezept zurückgegeben | |
| $dispense | Apotheke | Apotheke hat das E-Rezept beliefert |
| $close | Apotheke | Apotheke hat das E-Rezept abgeschlossen |
| Kostenträger | Krankenkasse hat das E-Rezept abgeschlossen | |
| $abort | Versicherter, Vertreter |
Patient/Versicherter/Vertreter hat das E-Rezept gelöscht |
| Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut | Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut hat das E-Rezept gelöscht | |
| Apotheke | Apotheke hat das E-Rezept gelöscht | |
| GET /MedicationDispense?<parameter>=... | ||
| Versicherter, Vertreter |
Patient/Versicherter hat Medikament-Informationen heruntergeladen | |
| http DELETE /ChargeItem/<id> | Versicherter | Versicherter hat Abrechnungsinformation gelöscht |
| http GET /ChargeItem/<id> | Versicherter | Versicherter hat Abrechnungsinformation gelesen |
| Apotheke | Apotheke hat Abrechnungsinformation gelesen | |
| http POST /ChargeItem | Apotheke | Apotheke hat Abrechnungsinformation bereitgestellt |
| http PATCH /ChargeItem/<id> | Versicherter | Versicherter hat Markierung zu Abrechnungsinformation gespeichert |
| http PUT /ChargeItem/<id> | Apotheke | Apotheke hat PKV-Abgabedatensatz gespeichert |
| http POST /Consent | Versicherter | Versicherter hat Einwilligung erteilt |
| http DELETE /Consent | Versicherter | Versicherter hat Einwilligung widerrufen |
| Automatisches Löschen durch den Fachdienst | ||
| Ressource Task | E-Rezept-Fachdienst | Veraltete E-Rezepte vom Fachdienst automatisch gelöscht |
| Ressource MedicationDispense | Veraltete Medikament-Informationen vom Fachdienst automatisch gelöscht | |
| Ressource Communication | Veraltete Nachrichten vom Fachdienst automatisch gelöscht | |
| Ressource ChargeItem | Veraltete Abrechnungsinformation vom E-Rezept-Fachdienst automatisch gelöscht | |
und die gelesene bzw. geschriebene Ressource im Protokolleintrag AuditEvent.entity.what als Referenz hinzufügen sowie die KVNR des betroffenen Versicherten in AuditEvent.entity.name speichern.
Mit diesen Informationen kann der Versicherte die Zugriffe auf seine Daten nachvollziehen und bei einem unberechtigten Zugriff ggfs. intervenieren. [<=]
Neu:
A_19284-11 - E-Rezept-Fachdienst - Versichertenprotokoll zu Operationen
Der E-Rezept-Fachdienst MUSS jeden Aufruf der folgenden Operationen protokollieren:
Tabelle 9: TAB_eRPFD_004 Versichertenprotokoll
| Operation | Rolle des zugreifenden Nutzers |
Beschreibung (ggfs. als Vorschlag für einen lesbaren Protokolleintrag in einfacher Sprache) |
|---|---|---|
| http GET /Task/<id> | ||
| - | Versicherter, Vertreter |
Patient/Versicherter/Vertreter hat das E-Rezept heruntergeladen |
| Apotheker | Apotheke hat die E-Rezept-Quittung heruntergeladen | |
| http GET /Task | ||
| Apotheker | im Erfolgsfall beim passenden AcceptPN3VSDMxx=false: Apotheke hat mit Ihrer eGK die Liste der offenen E-Rezepte abgerufen. im Erfolgsfall bei PN3 und passende AcceptPN3VSDMxx=true: Apotheke hat mit Ihrer eGK die Liste der offenen E-Rezepte abgerufen. (Offline-Check wurde akzeptiert) im Fehlerfall PN3 und passende AcceptPN3VSDMxx=false: Apotheke konnte aufgrund eines Fehlerfalls nicht die Liste der offenen E-Rezepte mit Ihrer eGK abgerufen. (Offline-Check wurde nicht akzeptiert) im sonstigen Fehlerfall: Apotheke konnte aufgrund eines Fehlerfalls nicht die Liste der offenen E-Rezepte mit Ihrer eGK abgerufen. |
|
| Kostenträger | Krankenkasse hat die Liste der offenen E-Rezepte (DiGA-Verordnungen) abgerufen. | |
| http POST /Task | ||
| $activate | Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut | Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut hat das E-Rezept bereitgestellt |
| $accept | Apotheke | Apotheke hat das E-Rezept heruntergeladen |
| Kostenträger | Krankenkasse hat das E-Rezept heruntergeladen | |
| $reject | Apotheke | Apotheke hat das E-Rezept zurückgegeben |
| Kostenträger | Krankenkasse hat das E-Rezept zurückgegeben | |
| $dispense | Apotheke | Apotheke hat das E-Rezept beliefert |
| $close | Apotheke | Apotheke hat das E-Rezept abgeschlossen |
| Kostenträger | Krankenkasse hat das E-Rezept abgeschlossen | |
| $eu-close | NCPeH-FD | Der [Parameters.parameter:requestData.part:practitionerRole] [Parameters.parameter:requestData.part:practitionerName] hat in [Parameters.parameter:requestData.part:healthcare-facility-type] [Parameters.parameter:requestData.part:pointOfCare] in [Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode)] Ihr E-Rezept eingelöst. |
| $abort | Versicherter, Vertreter |
Patient/Versicherter/Vertreter hat das E-Rezept gelöscht |
| Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut | Arzt-/Zahnarztpraxis/Krankenhaus/Psychotherapeut hat das E-Rezept gelöscht | |
| Apotheke | Apotheke hat das E-Rezept gelöscht | |
| GET /MedicationDispense?<parameter>=... | ||
| Versicherter, Vertreter |
Patient/Versicherter hat Medikament-Informationen heruntergeladen | |
| http DELETE /ChargeItem/<id> | Versicherter | Versicherter hat Abrechnungsinformation gelöscht |
| http GET /ChargeItem/<id> | Versicherter | Versicherter hat Abrechnungsinformation gelesen |
| Apotheke | Apotheke hat Abrechnungsinformation gelesen | |
| http POST /ChargeItem | Apotheke | Apotheke hat Abrechnungsinformation bereitgestellt |
| http PATCH /ChargeItem/<id> | Versicherter | Versicherter hat Markierung zu Abrechnungsinformation gespeichert |
| http PUT /ChargeItem/<id> | Apotheke | Apotheke hat PKV-Abgabedatensatz gespeichert |
| http POST /Consent | Versicherter | Versicherter hat Einwilligung für [Beschreibung für Consent.category.coding.code] erteilt. |
| http DELETE /Consent | Versicherter | Versicherter hat Einwilligung für [Beschreibung für Consent.category.coding.code] widerrufen. |
| http POST /$grant-eu-access-permission | Versicherter | Sie haben eine Zugriffsberechtigung zum Einlösen von E-Rezepten für das Land [Land B] erteilt. |
| http DELETE /$revoke-eu-access-permission | Versicherter | Sie haben die Zugriffsberechtigung zum Einlösen von E-Rezepten für das Land [Land B] gelöscht. |
| POST /$get-eu-prescriptions | ||
| Parameters.parameter:requestData.part:requesttype = demographics | NCPeH-FD | Der [Parameters.parameter:requestData.part:practitionerRole] [Parameters.parameter:requestData.part:practitionerName] hat in [Parameters.parameter:requestData.part:healthcare-facility-type] [Parameters.parameter:requestData.part:pointOfCare] in [Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode)] Ihre Patientendaten abgerufen. |
| Parameters.parameter:requestData.part:requesttype = e-prescriptions-list | NCPeH-FD | Der [Parameters.parameter:requestData.part:practitionerRole] [Parameters.parameter:requestData.part:practitionerName] hat in [Parameters.parameter:requestData.part:healthcare-facility-type] [Parameters.parameter:requestData.part:pointOfCare] in [Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode)] Ihre offenen E-Rezepte abgerufen. |
| Parameters.parameter:requestData.part:requesttype = e-prescriptions-retrieval | NCPeH-FD | Der [Parameters.parameter:requestData.part:practitionerRole] [Parameters.parameter:requestData.part:practitionerName] hat in [Parameters.parameter:requestData.part:healthcare-facility-type] [Parameters.parameter:requestData.part:pointOfCare] in [Land B (Klartext aus: Parameters.parameter:requestData.part:countryCode)] Ihre einzulösenden E-Rezepte abgerufen. |
| Automatisches Löschen durch den Fachdienst | ||
| Ressource Task | E-Rezept-Fachdienst | Veraltete E-Rezepte vom Fachdienst automatisch gelöscht |
| Ressource MedicationDispense | Veraltete Medikament-Informationen vom Fachdienst automatisch gelöscht | |
| Ressource Communication | Veraltete Nachrichten vom Fachdienst automatisch gelöscht | |
| Ressource ChargeItem | Veraltete Abrechnungsinformation vom E-Rezept-Fachdienst automatisch gelöscht | |
und die gelesene bzw. geschriebene Ressource im Protokolleintrag AuditEvent.entity.what als Referenz hinzufügen sowie die KVNR des betroffenen Versicherten in AuditEvent.entity.name speichern.
Mit diesen Informationen kann der Versicherte die Zugriffe auf seine Daten nachvollziehen und bei einem unberechtigten Zugriff ggfs. intervenieren. [<=]
7.1.5 Neues Kapitel in 6.11 Verordnungen für Einlösen im europäischen Ausland
7.1.5.1 Neues Kapitel 6.11.1 Http-Operation POST get-eu-prescriptions
Der abgebenden Apotheke im europäischen Ausland werden Ressourcen des MedicationRequest sowie die darin verknüpften Ressourcen mit Informationen über im europäischen Ausland einlösbare Verordnungen bereitgestellt. Der Zugriff auf diese Ressourcen erfolgt ausschließlich lesend durch den deutschen NCPeH-FD, der die Informationen entsprechend aufbereitet und weiterleitet.
A_27059 - E-Rezept-Fachdienst - eu-prescription abfragen - Rollenprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions sicherstellen, dass ausschließlich Nutzer in der Rolle
- oid_ncpeh
A_27060 - E-Rezept-Fachdienst - eu-prescription abfragen - Schemaprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD das im http-Body des Requests enthaltene Parameter-Objekt gegen
das Profil https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PAR_EU_GET_Prescription_EU_Input prüfen und im Fehlerfall die Operation mit Http-Fehlercode 400 abbrechen. [<=]
A_27061 - E-Rezept-Fachdienst - eu-prescription abfragen - Prüfung Einwilligung für KVNR
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD sicherstellen, dass für die in Parameters.parameter:requestData.part:kvnr übermittelte KVNR ein Consent-Datensatz mit Consent.patient.identifier = KVNR und Consent.category.coding.code = EUDISPCONS existiert und bei fehlgeschlagener Prüfung die Operation mit dem Http-Fehlercode 403 abbrechen, damit nur Verordnungsdaten für Versicherte übermittelt werden, die eine Einwilligung erteilt haben. [<=]
A_27062 - E-Rezept-Fachdienst - eu-prescription abfragen - Prüfung Zugriffsberechtigung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD sicherstellen, dass zu dem in Parameters.parameter:requestData.part:kvnr, Parameters.parameter:requestData.part:accessCode und Parameters.parameter:requestData.part:countryCode übermittelte Tripple von KVNR, Zugriffs- und Ländercode eine zeitliche gültige Zugriffsberechtigung im E-Rezept-Fachdienst existiert und bei fehlgeschlagener Prüfung die Operation mit dem Http-Fehlercode 403 abbrechen, damit nur Verordnungsdaten für Versicherte übermittelt werden, wenn eine gültige Zugriffsberechtigung vorliegt. [<=]
Offener Punkt: In die folgende Anforderung sind Filterkriterien zu ergänzen, welche Verordnungen ausschließen, bei denen das Mapping aus den Verordnungsdaten in das geforderte europäische Datenformat nicht möglich ist.
Nach aktuellen Stand betrifft das PZN Verordnungen ohne strukturierter Angabe der Stückzahl sowie der Packungsgröße, getrennt nach Einheit und numerischem Wert.
A_27063 - E-Rezept-Fachdienst - eu-prescription abfragen - Filter einlösbarer E-Rezepte
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD sicherstellen, dass nur Ressourcen eines Tasks bereitgestellt werden, die folgende Kriterien erfüllen:
- Task.extension:flowType = 160 oder 200
- MedicationRequests.medication vom Typ KBV_PR_ERP_Medication_PZN
- Task.for = KVNR für die KVNR aus Parameters.parameter:requestData.part:kvnr
- Task.ExpiryDate nicht vor dem aktuellen Datum
- Falls MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true, dann MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start nicht nach dem aktuellen Datum
- Task.status = "ready"
A_27064 - E-Rezept-Fachdienst - eu-prescription abfragen - Schema des Response
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD sicherstellen, dass die FHIR-Ressourcen zu einlösbaren Verordnungen in einem übergreifenden FHIR-Bundle gruppiert werden, absteigend sortiert nach dem medicationrequest.authored-on Datum, wobei das Bundle pro Verordnung ein FHIR-Bundle vom Typ https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundle enthält, mit der unter https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_PrescriptionId abgelegten Task-ID sowie den im MedicationRequest referenzierten Ressourcen MedicationRequest, Medication, Patient, Practitioner und Coverage. [<=]
A_27065 - E-Rezept-Fachdienst - eu-prescription abfragen - Abfrage der aktuellsten Verordnungsinformationen
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions?_count=1 durch den NCPeH-FD sicherstellen, dass die Ressourcen der zuletzt ausgestellten einlösbaren Verordnung zurückgegeben werden und falls keine Verordnung vorliegt, mit dem Http-Statuscode 404 antworten. [<=]
A_27066 - E-Rezept-Fachdienst - eu-prescription abfragen - Abfrage aller einlösbaren Verordnungsinformationen
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD sicherstellen, dass wenn Parameters.parameter:requestData.part:prescription-id leer ist, die Ressourcen aller einlösbaren Verordnung zurückgegeben werden und falls keine Verordnung vorliegt, mit dem Http-Statuscode 404 antworten. [<=]
A_27067 - E-Rezept-Fachdienst - eu-prescription abfragen - Abfrage nach Liste Rezept-Ids
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /$get-eu-prescriptions durch den NCPeH-FD sicherstellen, dass wenn Parameters.parameter:requestData.part:prescription-id nicht leer ist, die Ressourcen aller einlösbaren Verordnung zurückgegeben werden, deren Task-IDs in Parameters.parameter:requestData.part:prescription-id enthalten sind, und falls keine Verordnung vorliegt, mit dem Http-Statuscode 404 antworten. [<=]
7.1.6 Neues Kapitel 6.1.2.8 POST /Task/<id>/$eu-close
Die FHIR-Operation $eu-close beendet den E-Rezept-Workflow des unter der <id> geführten Tasks und speichert die von der europäischen Apotheke übermittelten Dispensierinformationen für den Versicherten. Diese Operation steht ausschließlich dem deutschen NCPeH zur Verfügung.
A_27068 - E-Rezept-Fachdienst - Task schließen - EU - Rollenprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close sicherstellen, dass ausschließlich Nutzer in der Rolle
- oid_ncpeh
[<=]
A_27069 - E-Rezept-Fachdienst - Task schließen - EU - Schemaprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close durch den NCPeH-FD das im http-Body des Requests enthaltene Parameter-Objekt gegen
das Profil https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PAR_EU_CloseOperation_Input prüfen und im Fehlerfall die Operation mit Http-Fehlercode 400 abbrechen. [<=]
A_27070 - E-Rezept-Fachdienst - Task schließen - EU - Prüfung Einwilligung für KVNR
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close durch den NCPeH-FD sicherstellen, dass für die in Parameters.parameter:requestData.part:kvnr übermittelte KVNR ein Consent-Datensatz mit Consent.patient.identifier = KVNR und Consent.category.coding.code = EUDISPCONS existiert und bei fehlgeschlagener Prüfung die Operation mit dem Http-Fehlercode 403 abbrechen, damit nur Dispensierinformationen für Versicherte übermittelt werden, die eine Einwilligung erteilt haben. [<=]
A_27071 - E-Rezept-Fachdienst - Task schließen - EU - Prüfung Zugriffsberechtigung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close durch den NCPeH-FD sicherstellen, dass zu dem in Parameters.parameter:requestData.part:kvnr, Parameters.parameter:requestData.part:accessCode und Parameters.parameter:requestData.part:countryCode übermittelte Tripple von KVNR, Zugriffs- und Ländercode eine zeitliche gültige Zugriffsberechtigung im E-Rezept-Fachdienst existiert und bei fehlgeschlagener Prüfung die Operation mit dem Http-Fehlercode 403 abbrechen, damit nur Dispensierinformationen übermittelt werden, wenn eine gültige Zugriffsberechtigung vorliegt. [<=]
A_27072 - E-Rezept-Fachdienst - Task schließen - EU - Statusprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close durch den NCPeH-FD sicherstellen, dass Task.status = ready ist und bei Ungleichheit mit dem HTTP-Fehlercode 403 abbrechen. [<=]
A_27074 - E-Rezept-Fachdienst - Task schließen - EU - Zeitstempel MedicationDispense
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close durch den NCPeH-FD sicherstellen, dass der Zeitpunkt des Aufrufes in Task.extension:lastMedicationDispense im Format "YYYY-MM-DDThh:mm:ss+zz:zz" (FHIR-instant) angelegt und gespeichert wird. [<=]
A_27075 - E-Rezept-Fachdienst - Task schließen - EU - Status beenden
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation des Endpunkts /Task/<id>/$eu-close durch den NCPeH-FD sicherstellen, dass die zulässige Beendigung eines übermittelten Tasks im Status Task.status = completed vollzogen wird, damit der Workflow für den Versicherten als beendet und das E-Rezept somit als eingelöst dargestellt wird. [<=]
7.1.7 Änderung in 6.1.1 HTTP-Operation GET
neu:
A_27273 - E-Rezept-Fachdienst - Task abrufen - Versicherter - Verordnung in Europa einlösbar
Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf einen einzelnen /Task/<id> durch einen Versicherten in Task.extension:eu-eprescription.valueBoolean zurückgeben, ob die Verordnung den Kriterien zum Einlösen im europäischen Ausland entspricht, damit dem Versicherten dargestellt werden kann, ob das E-Rezept im europäischen Ausland einlösbar ist. [<=]
Die Kriterien, ob eine Verordnung im europäischen Ausland einlösbar ist, sind in A_27063-* beschrieben.
7.1.8 Änderung in 6.4 Ressource Consent
7.1.8.1 Änderung in HTTP-Operation DELETE
neu:
A_27131 - E-Rezept-Fachdienst - Consent löschen - EUDISPCONS - Löschen Zugriffsberechtigung
Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-Operation DELETE auf den Endpunkt /Consent mit ?category=EUDISPCONS alle dem Versicherten zugeordneten Zugriffsberechtigungen anhand der KVNR des Versicherten im ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests identifizieren und löschen.
[<=]
7.1.8.2 Änderung in HTTP-Operation POST
alt:
A_22162 - E-Rezept-Fachdienst - Consent schreiben – nur eine Einwilligung CHARGCONS pro KVNR
Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den Endpunkt /Consent sicherstellen, dass noch keine Consent Ressource für die KVNR im ACCESS_TOKEN und Consent.category.coding.code = CHARGCONS gespeichert ist, um maximal eine Einwilligung für den Versicherten zu speichern. Im Fehlerfall muss der Http-Request mit dem Http-Fehlercode 409 abgewiesen werden. [<=]
neu:
A_22162-01 - E-Rezept-Fachdienst - Consent schreiben – nur eine Einwilligung pro KVNR und Einwilligungstyp
Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-POST-Operation auf den Endpunkt /Consent sicherstellen, dass noch keine Consent Ressource für die KVNR im ACCESS_TOKEN und Consent.category.coding.code = <Einwilligungstyp> aus URL-Parameter category gespeichert ist, um maximal eine Einwilligung für den Versicherten für jeden Einwilligungstypen zu speichern. Im Fehlerfall muss der Http-Request mit dem Http-Fehlercode 409 abgewiesen werden. [<=]
7.1.9 Neues Kapitel in 6.12 Zugriffsberechtigung für Einlösen im europäischen Ausland
Einen Zugriffsberechtigung eines Versicherten für das Einlösen von E-Rezepten im europäischen Ausland beinhaltet die folgenden Informationen:
- KVNR des Versicherten
- Ländercode des Landes, für welches die Zugriffsberechtigung durch den Versicherten erteilt wurde
- Zugriffscode
- gültig bis (1h ab Einstellen), wird durch den E-Rezept-Fachdienst beim Einstellen der Zugriffsberechtigung gesetzt.
A_27083 - E-Rezept-Fachdienst - Zugriffsberechtigung - periodische Bereinigung
Der E-Rezept-Fachdienst MUSS periodisch prüfen, dass keine zeitlich ungültigen Zugriffsberechtigungen gespeichert sind. [<=]
7.1.9.1 Neues Kapitel 6.12.1 Http-Operation DELETE
Die Operation führt zum Löschen der für den Versicherten gespeicherten Zugriffsberechtigung. Diese Operation steht dem Versicherten, der die Zugriffsberechtigung erteilt hat, zur Verfügung.
A_27084 - E-Rezept-Fachdienst - Zugriffsberechtigung löschen - Rollenprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-DELETE-Operation auf den Endpunkt /$revoke-eu-access-permission die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im Http-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle oid_versicherter die Operation am E-Rezept-Fachdienst aufrufen dürfen, damit die Information zur Zugriffsberechtigung nicht durch Unberechtigte gelöscht werden kann. [<=]
A_27085 - E-Rezept-Fachdienst - Zugriffsberechtigung löschen - Löschen
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-DELETE-Operation auf den Endpunkt /$revoke-eu-access-permission die KVNR des Versicherten im ACCESS_TOKEN im Http-RequestHeader "Authorization" feststellen und, falls vorhanden, zu dieser KVNR gespeicherte Zugriffsberechtigungen löschen. [<=]
7.1.9.2 Neues Kapitel 6.12.2 Http-Operation GET
Mit der FHIR-Operation kann die Zugriffsberechtigung für die im ACCESS_TOKEN angegebene KVNR abgerufen werden. Diese Operation steht Versicherten zur Verfügung.
A_27086 - E-Rezept-Fachdienst - Zugriffsberechtigung lesen - Rollenprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-GET-Operation auf den Endpunkt /$read-eu-access-permission die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im Http-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle oid_versicherter die Operation am E-Rezept-Fachdienst aufrufen dürfen, damit die Information zur Einwilligung nicht durch Unberechtigte ausgelesen werden kann. [<=]
A_27087 - E-Rezept-Fachdienst - Zugriffsberechtigung lesen - Response
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-GET-Operation auf den Endpunkt /$read-eu-access-permission die KVNR des Versicherten im ACCESS_TOKEN im Http-RequestHeader "Authorization" feststellen und im Response falls vorhanden eine Ressource des Profils https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PAR_EU_Access_Authorization_Response mit zur KVNR gespeicherte zeitlich gültige Zugriffsberechtigung übermitteln. [<=]
7.1.9.3 Neues Kapitel 6.12.3 Http-Operation POST
Die FHIR-Operation führt zum Schreiben einer neuen Zugriffsberechtigung. Diese Operation steht Versicherten zur Verfügung.
A_27088 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Rollenprüfung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im Http-RequestHeader "Authorization" feststellen und sicherstellen, dass ausschließlich Versicherte in der Rolle oid_versicherter die Operation am E-Rezept-Fachdienst aufrufen dürfen, damit eine Zugriffsberechtigte nicht durch Unberechtigte erteilt werden kann. [<=]
A_27089 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Prüfung Einwillung für KVNR
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission die KVNR des Versicherten im ACCESS_TOKEN im Http-RequestHeader "Authorization" feststellen und sicherstellen, dass ein Consent-Datensatz mit Consent.patient.identifier = KVNR und Consent.category.coding.code = EUDISPCONS existiert und bei fehlgeschlagener Prüfung die Operation mit dem Http-Fehlercode 403 und dem OperationOutcome "Das Erstellen einer Zugriffsberechtigung ist erst zulässig, wenn eine Einwilligung durch den Nutzer zum Einlösen von E-Rezepten im europäischen Ausland erteilt wurde." abbrechen, damit nur Versicherte eine Zugriffsberechtigung schreiben, die eine Einwilligung erteilt haben. [<=]
A_27090 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Prüfung Ländercode
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission prüfen, dass der im Request übermittelte Ländercode (Parameters.parameter:countryCode) einem Land entspricht, welches die Anwendung ePrescription/eDispensation Szenario Land A unterstützt und bei fehlschlagender Prüfung die Operation mit dem Http-Fehlercode 409 und dem OperationOutcome "Für das angefragte Land ist Einlösen von E-Rezepten nicht möglich." abbrechen, damit der Versicherte nur für zulässige europäische Länder eine Zugriffsberechtigung erteilt. [<=]
A_27091 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Prüfung Zugriffscode
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission prüfen, dass der im Request übermittelte Zugriffscode (Parameters.parameter:accessCode) das korrekte Format hat und bei fehlschlagender Prüfung die Operation mit dem Http-Fehlercode 400 und dem OperationOutcome "Der übermittelte Zugriffscode ist nicht zulässig." abbrechen. [<=]
Die Formatvorgaben für den Zugriffscode sind in [gemSpec_DM_eRp#A_27097-*] spezifiziert.
A_27092 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Löschen bestehender Zugriffsberechtigung
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission prüfen, ob für die im Request übermittelte KVNR Zugriffsberechtigungen gespeichert sind und falls ja, diese löschen. [<=]
A_27093 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Neue Zugriffsberechtigung speichern
Der E-Rezept-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission mit dem im Request übermittelten KVNR, Zugriffscode und Ländercode eine neue Zugriffsberechtigung speichern und den Wert valid_until auf aktuellen Zeitpunkt + 1h setzen. [<=]
A_27094 - E-Rezept-Fachdienst - Zugriffsberechtigung schreiben - Response
Der E-Rezept-Fachdienst MUSS im Response zu einem Aufruf der Http-POST-Operation auf den Endpunkt /$grant-eu-access-permission eine Ressource des Profils https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PAR_EU_Access_Authorization_Response mit den Daten des gespeicherten Datensatz zur Zugriffsberechtigung übermitteln. [<=]
7.1.9.4 Neues Kapitel 6.12.4 Zulässige europäische Länder
Um zu bestimmen, welche europäischen Länder das die Anwendung ePrescription/eDispensation Szenario Land A unterstützen, lädt der E-Rezept-Fachdienst die Liste dieser Länder aus dem FHIR-VZD. Die Liste kann für 96h gecacht werden.
Der Ablauf der Authentisierung und Suche ist in [gemSpec_VZD_FHIR_Directory#AF_10403 Fachdienst sucht Einträge im FHIR-Directory] beschrieben. Der Betreiber des E-Rezept-Fachdienst muss beim FHIR-VZD Anbieter für den Zugriff auf den FHIR-VZD nach [gemSpec_VZD_FHIR_Directory#Nutzer und Rollen] registrieren.
A_27095 - E-Rezept-Fachdienst - Zugriffsberechtigung - Liste zulässiger Länder
Der E-Rezept-Fachdienst MUSS die Liste aller zulässigen Länder aus dem Verzeichnisdienst ermitteln, indem an den Verzeichnisdienst folgende Abfrage gestellt wird:
- Abfrage der Ressource "HealthcareService"
- HealthcareServices, deren Speciality "57833-6" aus https://loinc.org enthalten
- HealthcareServices, deren Organisation aktiv sind
- HealthcareServices, deren Organisation den OrganizationProfessionOIDType "1.2.276.0.76.4.292" entspricht
- Einbeziehen der Organisation in das Rückgabeergebnis
Prüfverfahren: funktionale Herstellererklärung
A_27096 - E-Rezept-Fachdienst - Zugriffsberechtigung - Caching Liste zulässiger Länder
Der E-Rezept-Fachdienst DARF NICHT Informationen zur Liste zulässiger Länder verwenden, welche länger als 96h lokal durch den E-Rezept-Fachdienst gecacht wurden. [<=]
Prüfverfahren: funktionale Herstellererklärung
7.2 Anforderungen an das E-Rezept-FdV
Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_eRp_FdV] übernommen.
Das E-Rezept-FdV der gematik wird die Anwendungsfälle umsetzen. Für die E-Rezept-FdV der Krankenkassen ist die Umsetzung optional.
7.2.1.1 Änderungen in 5.2.1 Übersicht Anwendungsfälle
Tabelle 10 : TAB_FdVERP_003 – Übersicht Anwendungsfälle E-Rezept-FdV
| Anwendungsfall | Workflow | Umsetzung | |
|---|---|---|---|
| ... | |||
| Einwilligung | verpflichtend, wenn einer der folgenden Funktionalitäten im E-Rezept-FdV umgesetzt wird:
|
||
| Einwilligung erteilen | |||
| Einwilligungen einsehen | |||
| Einwilligung widerrufen | |||
| ... | |||
| Zugriffsberechtigung für Einlösen im EU-Ausland | optional | ||
| Zugriffsberechtigung erteilen | verpflichtend, wenn die Zugriffsberechtigung für Einlösen im EU-Ausland umgesetzt wird | ||
| Zugriffsberechtigung anzeigen | |||
| Zugriffsberechtigung abrufen | |||
| Zugriffsberechtigung löschen |
7.2.1.2 Änderungen in 5.2.3 Anwendungsfälle
7.2.1.3 Änderungen in Kapitel 5.2.3.19 Einwilligungen
Die bestehenden Anwendungsfälle zur Verwaltung von Einwilligungen werden verallgemeinert.
A_27105 - E-Rezept-FdV: Einwilligung zum Speichern von Abrechnungsinformation
Das E-Rezept-FdV KANN es dem Nutzer, welcher sich als PKV-Versicherte identifiziert hat, ermöglichen, die "Einwilligung zum Speichern von Abrechnungsinformationen" zu verwalten. [<=]
A_27106 - E-Rezept-FdV: Einwilligung zum Einlösen im EU-Ausland
Das E-Rezept-FdV KANN es dem Nutzer ermöglichen, die "Einwilligung zum Einlösen im EU-Ausland" zu verwalten. [<=]
7.2.1.3.1 Änderung in 5.2.3.19.1 Einwilligung zum Speichern der Abrechnungsinformationen erteilen
Das Kapitel wird in "Einwilligung erteilen" umbenannt.
Mit diesem Anwendungsfall kann der Nutzer (Versicherter) eine Einwilligung erteilen und die Information auf dem E-Rezept-Fachdienst speichern.
A_24565-01 - E-Rezept-FdV: optional: Einwilligung erteilen
Das E-Rezept-FdV KANN den Anwendungsfall "Einwilligung erteilen" umsetzen. [<=]
A_22709-02 - E-Rezept-FdV: Einwilligung erteilen - Einwilligungstext
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung erteilen" den Text für die Einwilligung derart gestalten, dass dem Nutzer eine informierte Einwilligung möglich ist. Insbesondere MÜSSEN enthalten sein: der Verwendungszweck, die konkreten Informationen über die Art der erhobenen Daten, die Speicherdauer, Hinweis auf Freiwilligkeit, auf Widerrufsrecht, Hinweis auf die Folgen bei Verweigerung oder Widerruf. [<=]
A_22163-02 - E-Rezept-FdV: Einwilligung erteilen - Einwilligung eingeben
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung erteilen" es dem Nutzer ermöglichen, die Einwilligung einzugeben. [<=]
A_22164-02 - E-Rezept-FdV: Einwilligung erteilen
Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall umsetzt, den Anwendungsfall "Einwilligung durch Versicherten erteilen" gemäß TAB_FdVERP_020 umsetzen.
Tabelle 11 : TAB_FdVERP_020 – Einwilligung erteilen
| Name | Einwilligung erteilen |
| Auslöser |
|
| Akteur | Versicherter |
| Vorbedingung |
|
| Nachbedingung |
|
| Standardablauf |
|
A_22165-01 - E-Rezept-FdV: Einwilligung erteilen - Consent Ressource erstellen
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung erteilen" eine Consent Ressource mit
- Versicherten-ID in Consent.patient.identifier
- Einwilligungstyp in Consent.category.coding.code
Der Einwilligungstyp ist gemäß einem der folgenden Codesysteme zu wählen: https://gematik.de/fhir/erpchrg/CodeSystem/GEM_ERPCHRG_CS_ConsentType , https://gematik.de/fhir/erp-eu/CodeSystem/GEM_ERPEU_CS_ConsentType .
A_22166-01 - E-Rezept-FdV: Einwilligung erteilen - Speicherrequest
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung erteilen" zum Speichern der Information im E-Rezept-Fachdienst die HTTP-Operation POST /Consent mit
- ACCESS_TOKEN im Authorization-Header
7.2.1.3.2 Änderung in 5.2.3.19.2 Einwilligungsinformation abrufen
Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Information, welche Einwilligungen erteilt wurden, vom E-Rezept-Fachdienst abrufen.
A_24566-01 - E-Rezept-FdV: optional: Einwilligungsinformation abrufen
Das E-Rezept-FdV KANN den Anwendungsfall "Einwilligungen durch Versicherten einsehen" umsetzen. [<=]
A_22167-02 - E-Rezept-FdV: Einwilligungsinformation abrufen
Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall umsetzt, den Anwendungsfall "Einwilligungen durch Versicherten einsehen" gemäß TAB_FdVERP_021 umsetzen.
Tabelle 12 : TAB_FdVERP_021 – Einwilligungsinformation abrufen
| Name | Einwilligungsinformation abrufen |
| Auslöser |
|
| Akteur | Versicherter |
| Vorbedingung |
|
| Nachbedingung |
|
| Standardablauf |
|
A_22168-02 - E-Rezept-FdV: Einwilligungsinformation abrufen - Abfragerequest
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligungsinformation abrufen" zum Abrufen der Information vom E-Rezept-Fachdienst die HTTP-Operation GET /Consent mit
- ACCESS_TOKEN im Authorization-Header
Im Response können mehrere Consent Ressourcen enthalten sein. Der Einwilligungstyp des Consent ist in Consent.category.coding.code angegeben. Die Werte können sich auf folgende Codesysteme beziehen: https://gematik.de/fhir/erpchrg/CodeSystem/GEM_ERPCHRG_CS_ConsentType ,
https://gematik.de/fhir/erp-eu/CodeSystem/GEM_ERPEU_CS_ConsentType .
7.2.1.3.3 Änderung in 5.2.3.19.3 Einwilligung zum Speichern der Abrechnungsinformationen widerrufen
Das Kapitel wird in "Einwilligung widerrufen" umbenannt.
Mit diesem Anwendungsfall kann der Nutzer (Versicherter) eine Einwilligung widerrufen und die Information zur Einwilligung vom E-Rezept-Fachdienst zu löschen.
Mit dem Widerruf der "Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst" werden alle Abrechnungsinformationen des Versicherten gelöscht. Das Löschen erfolgt unwiederbringlich.
Mit dem Widerruf der "Einwilligung zum Einlösen im EU-Ausland" wird eine gegebenenfalls erteilte Zugriffsberechtigung gelöscht.
Mit dem Anwendungsfall "Einwilligungsinformation abfragen" können die bestehenden Einwilligungen bestimmt werden.
A_24567-01 - E-Rezept-FdV: optional: Einwilligung widerrufen
Das E-Rezept-FdV KANN den Anwendungsfall "Einwilligung widerrufen" umsetzen. [<=]
A_22169-02 - E-Rezept-FdV: Einwilligung widerrufen - Widerruf eingeben
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung widerrufen" es dem Nutzer ermöglichen, den Widerruf zu erfassen. [<=]
A_22330-02 - E-Rezept-FdV: Einwilligung widerrufen - Bestätigung
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung widerrufen" vom Nutzer eine Bestätigung einholen, dass die Einwilligung widerrufen werden soll, somit ggf. korrespondierende Daten gelöscht werden und die Möglichkeit geben, das Widerrufen abzubrechen. [<=]
A_22170-02 - E-Rezept-FdV: Einwilligung widerrufen
Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall umsetzt, den Anwendungsfall "Einwilligung durch Versicherten widerrufen" gemäß TAB_FdVERP_022 umsetzen.
Tabelle 13 : TAB_FdVERP_022 – Einwilligung widerrufen
| Name | Einwilligung widerrufen |
| Auslöser |
|
| Akteur | Versicherter |
| Vorbedingung |
|
| Nachbedingung |
|
| Standardablauf |
|
A_22171-01 - E-Rezept-FdV: Einwilligung widerrufen - Löschrequest
Das E-Rezept-FdV MUSS im Anwendungsfall "Einwilligung widerrufen" zum Löschen der Information im E-Rezept-Fachdienst die HTTP-Operation DELETE /Consent/?category=<Einwilligungstyp> mit
- ACCESS_TOKEN im Authorization-Header
- Einwilligungstyp in ?category
Der Einwilligungstyp ist entsprechend dem Codesystem https://gematik.de/fhir/erpchrg/CodeSystem/GEM_ERPCHRG_CS_ConsentType bzw. https://gematik.de/fhir/erp-eu/CodeSystem/GEM_ERPEU_CS_ConsentType anzugeben.
7.2.1.4 Neues Kapitel 5.2.3.x Zugriffsberechtigung für Einlösen im europäischen Ausland
7.2.1.4.1 Neues Kapitel 5.2.3.x.y Zugriffsberechtigung erteilen
Mit diesem Anwendungsfall kann der Nutzer (Versicherter) eine Zugriffsberechtigung für Leistungserbringer in einem europäischen Land erteilen und die Information auf dem E-Rezept-Fachdienst speichern.
A_27107 - E-Rezept-FdV: optional: Zugriffsberechtigung erteilen
Das E-Rezept-FdV KANN den Anwendungsfall "Zugriffsberechtigung erteilen" umsetzen. [<=]
A_27108 - E-Rezept-FdV: Anzeige der E-Rezepte für EU-Zugriff
Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, sich die E-Rezepte anzeigen zu lassen, auf die die Berechtigung für EU-Zugriff wirkt. [<=]
Um zu bestimmen, welche europäischen Länder die Anwendung ePrescription/eDispensation Szenario Land A unterstützen, lädt der E-Rezept-FdV die Liste dieser Länder aus dem FHIR-VZD. Die Liste kann für 96h gecacht werden.
A_27109 - E-Rezept-FdV: Zugriffsberechtigung - Liste zulässiger Länder
Das E-Rezept-FdV MUSS Anwendungsfall "Zugriffsberechtigung erteilen" die Liste aller zulässigen Länder aus dem Verzeichnisdienst ermitteln, indem an den Verzeichnisdienst folgende Abfrage gestellt wird:
- Abfrage der Ressource "HealthcareService"
- HealthcareServices, deren Speciality "57833-6" aus https://loinc.org enthalten
- HealthcareServices, deren Organisation aktiv sind
- HealthcareServices, deren Organisation den OrganizationProfessionOIDType "1.2.276.0.76.4.292" entspricht
- Einbeziehen der Organisation in das Rückgabeergebnis
A_27110 - E-Rezept-FdV: Zugriffsberechtigung - Caching Liste zulässiger Länder
Das E-Rezept-FdV DARF NICHT Informationen zur Liste zulässiger Länder verwenden, welche länger als 96h lokal durch das E-Rezept-FdV gecacht wurden. [<=]
A_27111 - E-Rezept-FdV: Zugriffsberechtigung erteilen - Land auswählen
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung erteilen" es dem Nutzer ermöglichen, ein Land aus der Liste der zulässigen Länder auszuwählen, für das der Nutzer die Zugriffberechtigung erteilen möchte. [<=]
A_27112 - E-Rezept-FdV: Zugriffsberechtigung erteilen
Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall umsetzt, den Anwendungsfall "Zugriffsberechtigung erteilen" gemäß TAB_FdVERP_xxx umsetzen.
Tabelle 14 : TAB_FdVERP_xxx – Zugriffsberechtigung erteilen
| Name | Zugriffsberechtigung erteilen |
| Auslöser |
|
| Akteur | Versicherter |
| Vorbedingung |
|
| Nachbedingung |
|
| Standardablauf |
|
A_27113 - E-Rezept-FdV: Zugriffsberechtigung erteilen - Zugriffscode erzeugen
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung" einen eigens generierten Zugriffscode als Zufallswert erzeugen. [<=]
Das Format für den Zugriffscode ist in [gemSpec_DM_eRp#A_27097-*] beschrieben.
Für jede weitere Erteilung einer Zugriffsberechtigung für ePrescription/eDispensation Szenario Land A muss ein neuer Zugriffscode erzeugt werden.
A_27114 - E-Rezept-FdV: Zugriffsberechtigung erteilen - Zugriffsberechtigung am E-Rezept-Fachdienst speichern
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung erteilen" zum Speichern der Information am E-Rezept-Fachdienst die Http-Operation POST /$grant-eu-access-permission mit
- ACCESS_TOKEN im Authorization-Header
- Organization.extension:ncpehCountryEx.valueCodeableConcept.coding.code des vom Nutzer ausgewählten Landes in Parameters.parameter:countryCode
- erzeugter Zugriffscode in Parameters.parameter:accessCode
Im Response übermittelt der E-Rezept-Fachdienst in Parameters.parameter:validUntil die Gültigkeitsdauer der Zugriffsberechtigung.
7.2.1.4.2 Neues Kapitel 5.2.3.x.y Zugriffsberechtigung anzeigen
Mit diesem Anwendungsfall kann ein Nutzer eine bestehende Zugriffsberechtigung im Display anzeigen, um die Information an einen Leistungserbringer zu übermitteln.
Die Information kann nach dem Erteilen der Zugriffsberechtigung lokal gespeichert worden sein oder vom E-Rezept-Fachdienst ermittelt werden.
A_27115 - E-Rezept-FdV: optional: Zugriffsberechtigung anzeigen
Das E-Rezept-FdV KANN den Anwendungsfall "Zugriffsberechtigung anzeigen" umsetzen. [<=]
A_27116 - E-Rezept-FdV: Zugriffsberechtigung anzeigen
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung anzeigen" folgende Informationen auf dem Display anzeigen:
- Name des Landes
- Gültigkeitsende
- Zugriffscode
- KVNR des Versicherte
Für die Anzeige der Gültigkeitsdauer ist die Zeitzone zu beachten, in der der Nutzer sich befindet.
A_27117 - E-Rezept-FdV: Zugriffsberechtigung anzeigen - Gültigkeit Restdauer hervorheben
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung anzeigen" die Gültigkeitsdauer der Zugriffsberechtigung auf dem Display hervorheben, wenn die Gültigkeitsdauer 10 Minuten unterschreitet. [<=]
A_27118 - E-Rezept-FdV: Zugriffsberechtigung anzeigen - Gültigkeit Ablauf anzeigen
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung anzeigen", wenn die Gültigkeit der Zugriffsberechtigung zeitlich abgelaufen ist, den Versicherten informieren. [<=]
Hinweis: Es reicht aus, dass die Information über den Ablauf der Zugriffsberechtigung nur angezeigt wird, während der Nutzer auf dem Gerät aktiv ist.
Der zeitliche Ablauf der Zugriffsberechtigung wird nicht durch den E-Rezept-Fachdienst signalisiert.
7.2.1.4.3 Neues Kapitel 5.2.3.x.y Zugriffsberechtigung abrufen
Mit diesem Anwendungsfall kann eine am E-Rezept-Fachdienst registrierte Zugriffsberechtigung ermittelt werden.
A_27119 - E-Rezept-FdV: optional: Zugriffsberechtigung abrufen
Das E-Rezept-FdV KANN den Anwendungsfall "Zugriffsberechtigung abrufen" umsetzen. [<=]
A_27120 - E-Rezept-FdV: Zugriffsberechtigung abrufen
Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall umsetzt, den Anwendungsfall "Zugriffsberechtigung abrufen" gemäß TAB_FdVERP_xxx umsetzen.
Tabelle 15 : TAB_FdVERP_xxx – Zugriffsberechtigung abrufen
| Name | Zugriffsberechtigung abrufen |
| Auslöser |
|
| Akteur | Versicherter |
| Vorbedingung |
|
| Nachbedingung |
|
| Standardablauf |
|
A_27121 - E-Rezept-FdV: Zugriffsberechtigung abrufen - Abfragerequest
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung abrufen" zum Abrufen der Information vom E-Rezept-Fachdienst die Http-Operation GET /$read-eu-access-permission mit
- ACCESS_TOKEN im Authorization-Header
Im Response kann ein Zugriffberechtigungsdatensatz (https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PAR_EU_Access_Authorization_Response ) enthalten sein.
7.2.1.4.4 Neues Kapitel 5.2.3.x.y Zugriffsberechtigung löschen
Mit diesem Anwendungsfall kann der Nutzer (Versicherter) eine zuvor erteilte Zugriffsberechtigung am E-Rezept-Fachdienst löschen.
A_27122 - E-Rezept-FdV: optional: Zugriffsberechtigung löschen
Das E-Rezept-FdV KANN den Anwendungsfall "Zugriffsberechtigung löschen" umsetzen. [<=]
A_27123 - E-Rezept-FdV: Zugriffsberechtigung löschen - Löschwunsch eingeben
Das E-Rezept-FdV MUSS es dem Nutzer im Anwendungsfall "Zugriffsberechtigung löschen" ermöglichen den Löschwunsch einzugeben. [<=]
A_27124 - E-Rezept-FdV: Zugriffsberechtigung löschen
Das E-Rezept-FdV MUSS, wenn es den Anwendungsfall umsetzt, den Anwendungsfall "Zugriffsberechtigung löschen" gemäß TAB_FdVERP_xxx umsetzen.
Tabelle 16 : TAB_FdVERP_xxx – Zugriffsberechtigung löschen
| Name | Zugriffsberechtigung löschen |
| Auslöser |
|
| Akteur | Versicherter |
| Vorbedingung |
|
| Nachbedingung |
|
| Standardablauf |
|
A_27125 - E-Rezept-FdV: Zugriffsberechtigung löschen - Abfragerequest
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung löschen" zum Löschen der Information auf dem E-Rezept-Fachdienst die Http-Operation DELETE /$revoke-eu-access-permission mit
- ACCESS_TOKEN im Authorization-Header
A_27126 - E-Rezept-FdV: Zugriffsberechtigung löschen - lokale Zugriffsberechtigung löschen
Das E-Rezept-FdV MUSS im Anwendungsfall "Zugriffsberechtigung löschen" die lokal gespeicherten Informationen zur Zugriffsberechtigung löschen. [<=]
7.3 Daten- und Informationsmodell
7.3.1 Neues FHIR Package de.gematik.erezept-workflow-eu
Link zum ReleaseCandidate: https://simplifier.net/packages/de.gematik.erezept.eu/1.0.0-rc1
7.3.1.1 Profile
OperationDefinitions:
- EUClose: https://simplifier.net/erezept-workflow-eu/eucloseoperation
- GET-Prescription-EU: https://simplifier.net/erezept-workflow-eu/get-prescription-eu
- Grant-EU-Access-Permission: https://simplifier.net/erezept-workflow-eu/grant-eu-access-permission
- Read-EU-Access-Permission: https://simplifier.net/erezept-workflow-eu/read-eu-access-permission
- Revoke-EU-Access-Permission: https://simplifier.net/erezept-workflow-eu/revoke-eu-access-permission
Parameters Profile für die Operationen:
- GEM_ERPEU_PR_PAR_Access_Authorization_Request: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_par_access_authorization_request
- GEM_ERPEU_PR_PAR_Access_Authorization_Response: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_par_access_authorization_response
- GEM_ERPEU_PR_PAR_CloseOperation_Input: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_par_closeoperation_input
- GEM_ERPEU_PR_PAR_GET_Prescription_Input: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_par_get_prescription_input
Profile:
- GEM_ERPEU_PR_Access_Code: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_access_code
- GEM_ERPEU_PR_MedicationDispense: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_medicationdispense
- GEM_ERPEU_PR_Organization: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_organization
- GEM_ERPEU_PR_Practitioner: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_practitioner
- GEM_ERPEU_PR_PractitionerRole: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_practitionerrole
- GEM_ERPEU_PR_Consent: https://simplifier.net/erezept-workflow-eu/gem_erpeu_pr_consent
7.3.1.2 Terminologien
Code Systeme:
- GEM_ERPEU_CS_ConsentType: https://simplifier.net/erezept-workflow-eu/gem-erpeu-cs-consenttype
beinhaltet für die Einwilligung zum Einlösen im EU-Ausland den Code:
EUDISPCONS - Consent for redeeming e-prescriptions in EU countries - GEM_ERPEU_CS_RequestType: https://simplifier.net/erezept-workflow-eu/gem-erpeu-cs-requesttype
ValueSets:
- GEM_ERPEU_VS_ConsentType: https://simplifier.net/erezept-workflow-eu/gem-erpeu-vs-consenttype
- GEM_ERPEU_VS_Consent_PolicyRule: https://simplifier.net/erezept-workflow-eu/gem-erpeu-vs-consent-policyrule
- GEM_ERPEU_VS_RequestType: https://simplifier.net/erezept-workflow-eu/gem-erpeu-vs-requesttype
- GEM_ERPEU_VS_PractitionerRole: https://simplifier.net/erezept-workflow-eu/gem-erpeu-vs-practitionerrole
- GEM_ERPEU_VS_HealthCareFacilityType: https://simplifier.net/erezept-workflow-eu/gem-erpeu-vs-healthcarefacilitytype
Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_DM_eRp] übernommen.
7.3.2 Änderung in Kapitel 2.1 FHIR-Ressourcen
neu:
A_27189 - Version FHIR-Package de.gematik.erezept.eu
Die Produkttypen der Anwendung E-Rezept und Clientsysteme des E-Rezept-Fachdienstes MÜSSEN das FHIR-Package de.gematik.erezept.eu in der Version gemäß [FHIR Version] unterstützen. [<=]
7.3.3 Neues Kapitel 2.x Zugriffsberechtigung für Einlösen im europäischen Ausland
A_27097 - Format Zugriffscode
Produkttypen der Anwendung E-Rezept MÜSSEN, wenn sie einen Zugriffscode für das Einlösen im europäischen Ausland verarbeiten, folgende Formatvorgaben für den Zugriffscode einhalten:
- String mit Gesamtlänge von 6 Zeichen
- erlaubte Zeichen: a-z, A-Z, 0-9
7.3.4 Änderung in Kapitel 2.5 Zugriffsprotokoll
alt:
A_19296-03 - E-Rezept-Fachdienst - Inhalt Protokolleintrag
Der E-Rezept-Fachdienst MUSS einen Protokolleintrag mit den folgenden Werten befüllen:
- AuditEvent.text: Generierung eines HTML-<div>-Elements mit lesbarer Beschreibung in einfacher Sprache
- AuditEvent.type: Fester Wert "rest" gemäß http://terminology.hl7.org/CodeSystem/audit-event-type
- AuditEvent.subtype: aus dem ValueSet https://www.hl7.org/fhir/valueset-audit-event-sub-type.html gemäß http://hl7.org/fhir/restful-interaction
-
- "create" beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Ausnahme von AuditEvent- und Communication-Ressource)
- "read" beim lesenden Zugriff auf ein Datenobjekt mit Versichertenbezug
- "update", wenn das Datenobjekt mit Versichertenbezug geändert/aktualisiert wird
- "delete", wenn das Datenobjekt mit Versichertenbezug manuell oder automatisch gelöscht wird
- "create" beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Ausnahme von AuditEvent- und Communication-Ressource)
- AuditEvent.action: analog AuditEvent.subType (C, R, U, D) gemäß https://www.hl7.org/fhir/valueset-audit-event-action.html
- AuditEvent.recorded: aktuelle Systemzeit des E-Rezept-Fachdienstes
- AuditEvent.outcome: Ergebnis der aufgerufenen Operation gemäß https://www.hl7.org/fhir/valueset-audit-event-outcome.html (0 = Erfolg, 4 = Fehler auf Clientseite, 8 = Serverfehler)
- AuditEvent.agent.type: Fester Wert "humanuser" bzw. bei Übermittlung an ePA "dataprocessor" aus http://terminology.hl7.org/CodeSystem/extra-security-role-type
- AuditEvent.agent.name: Lesbarer Name aus Identity-Token des Zugreifenden, der die zu protokollierende Aktion getriggert hat, z.B. "Praxis Dr. Müller, Bahnhofstr. 78" oder Versicherter z.B. "Max Mustermann" bzw. bei Übermittlung an ePA "E-Rezept-Fachdienst"
- AuditEvent.agent.who: KVNR bzw. Telematik-ID des zugreifenden Nutzers aus Identity-Token, der diesen Protokolleintrag ausgelöst hat
- AuditEvent.agent.requestor: Fester Wert "false", da keine Protokolleinträge von außen erzeugt werden
- AuditEvent.soure.site: Fester Wert "E-Rezept-Fachdienst"
- AuditEvent.soure.observer: Device-Informationen des E-Rezept-Fachdienstes (status, serialnumber=gemäß Release)
- AuditEvent.entity.what: Referenz auf das betroffene Datenobjekt Task, ChargeItem, MedicationDispense oder Consent zum Abruf
- AuditEvent.entity.name: Eintrag der KVNR des betroffenen Versicherten aus dem Identifier des protokollierten Datenobjekts (String)
- AuditEvent.entity.description: Rezept-ID als Identifier, wird übernommen aus MedicationDispense, ChargeItem oder Task bzw. Consent.category.coding.code bei Anlegen oder Löschen eines Consent
neu:
A_19296-04 - E-Rezept-Fachdienst - Inhalt Protokolleintrag
Der E-Rezept-Fachdienst MUSS einen Protokolleintrag mit den folgenden Werten befüllen:
- AuditEvent.text: Generierung eines HTML-<div>-Elements mit lesbarer Beschreibung in einfacher Sprache
- AuditEvent.type: Fester Wert "rest" gemäß http://terminology.hl7.org/CodeSystem/audit-event-type
- AuditEvent.subtype: aus dem ValueSet https://www.hl7.org/fhir/valueset-audit-event-sub-type.html gemäß http://hl7.org/fhir/restful-interaction
-
- "create" beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Ausnahme von AuditEvent- und Communication-Ressource)
- "read" beim lesenden Zugriff auf ein Datenobjekt mit Versichertenbezug
- "update", wenn das Datenobjekt mit Versichertenbezug geändert/aktualisiert wird
- "delete", wenn das Datenobjekt mit Versichertenbezug manuell oder automatisch gelöscht wird
- "create" beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Ausnahme von AuditEvent- und Communication-Ressource)
- AuditEvent.action: analog AuditEvent.subType (C, R, U, D) gemäß https://www.hl7.org/fhir/valueset-audit-event-action.html
- AuditEvent.recorded: aktuelle Systemzeit des E-Rezept-Fachdienstes
- AuditEvent.outcome: Ergebnis der aufgerufenen Operation gemäß https://www.hl7.org/fhir/valueset-audit-event-outcome.html (0 = Erfolg, 4 = Fehler auf Clientseite, 8 = Serverfehler)
- AuditEvent.agent.type: Fester Wert "humanuser" bzw. bei Übermittlung an ePA oder NCPeH "dataprocessor" aus http://terminology.hl7.org/CodeSystem/extra-security-role-type
- AuditEvent.agent.name: Lesbarer Name aus Identity-Token des Zugreifenden, der die zu protokollierende Aktion getriggert hat, z.B. "Praxis Dr. Müller, Bahnhofstr. 78" oder Versicherter z.B. "Max Mustermann" bzw. bei Übermittlung an ePA "E-Rezept-Fachdienst"
- AuditEvent.agent.who: KVNR bzw. Telematik-ID des zugreifenden Nutzers aus Identity-Token, der diesen Protokolleintrag ausgelöst hat
- AuditEvent.agent.requestor: Fester Wert "false", da keine Protokolleinträge von außen erzeugt werden
- AuditEvent.soure.site: Fester Wert "E-Rezept-Fachdienst"
- AuditEvent.soure.observer: Device-Informationen des E-Rezept-Fachdienstes (status, serialnumber=gemäß Release)
- AuditEvent.entity.what: Referenz auf das durch den Abruf betroffene Datenobjekt Task, ChargeItem, MedicationDispense, Consent oder Objekt der Zugriffsberechtigung
- AuditEvent.entity.name: Eintrag der KVNR des betroffenen Versicherten aus dem Identifier des protokollierten Datenobjekts (String)
- AuditEvent.entity.description: Rezept-ID als Identifier, wird übernommen aus MedicationDispense, ChargeItem oder Task bzw. Consent.category.coding.code bei Anlegen oder Löschen eines Consent bzw. countryCode bei Anlegen oder Löschen einer Zugriffsberechtigung
7.4 Anforderungen an den NCPeH-FD
Folgende Anforderungen gelten für Clientsysteme des E-Rezept-Fachdienst und werden somit auch dem NCPeH-FD zugeordnet. Wenn Anforderungen zu diesem Zweck verallgemeinert werden, sind diese Verallgemeinerungen hier dargestellt.
Die nachfolgenden Anforderungen werden in die jeweiligen Dokumente übernommen.
7.4.1 Änderungen in gemILF_PS_eRp 5.1.1 Kommunikation zu den Diensten der TI
alt:
A_19451-01 - PS: Lokalisierung E-Rezept-Fachdienst
Das Primärsystem MUSS für die zur Kommunikation mit dem E-Rezept-Fachdienst die FQDNs als Lokalisierungsinformationen in einer DNS-Abfrage gemäß [gemSpec_FD_eRP#5.1 Servicelokalisierung] nutzen. [<=]
neu:
A_19451-02 - CS: Lokalisierung E-Rezept-Fachdienst
Das Clientsystem des E-Rezept-Fachdienstes MUSS für die Kommunikation mit dem E-Rezept-Fachdienst die Endpunkte der Schnittstellen gemäß [gemSpec_FD_eRP#5.1 Servicelokalisierung] nutzen. [<=]
alt:
A_19744 - PS: Endpunkt Schnittstelle E-Rezept-Fachdienst
Das Primärsystem MUSS die URL für die Kommunikation mit dem E-Rezept-Fachdienst gemäß https://<FQDN aus DNS Lookup>:443/ bilden. [<=]
neu:
A_19744-01 - CS: Endpunkt Schnittstelle E-Rezept-Fachdienst
Das Clientsystem des E-Rezept-Fachdienstes MUSS für die Kommunikation mit dem E-Rezept-Fachdienst die URL mit dem Port 443 bilden. [<=]
alt:
A_19234 - PS: Kommunikation über TLS-Verbindung
Das Primärsystem MUSS für die Anwendungsfälle der Anwendung E-Rezept mit den Diensten der TI ausschließlich über TLS kommunizieren. [<=]
neu:
A_19234-01 - CS: Kommunikation über TLS-Verbindung
Das Clientsystem des E-Rezept-Fachdienstes MUSS für die Anwendungsfälle der Anwendung E-Rezept mit den Diensten der TI ausschließlich über TLS kommunizieren. [<=]
alt:
A_19235 - PS: Unzulässige TLS-Verbindungen ablehnen
Das Primärsystem MUSS bei jedem Verbindungsaufbau den Dienst der TI anhand seines TLS-Zertifikats authentifizieren und MUSS die Verbindungen ablehnen, falls die Authentifizierung fehlschlägt. [<=]
neu:
A_19235-01 - CS: Unzulässige TLS-Verbindungen ablehnen
Das Clientsystem des E-Rezept-Fachdienst MUSS sich bei jedem Verbindungsaufbau zum E-Rezept-Fachdienst oder IDP-Dienst anhand seines TLS-Zertifikats authentifizieren und MUSS die Verbindungen ablehnen, falls die Authentifizierung fehlschlägt. [<=]
alt:
A_20015-01 - PS: HTTP-Header user-agent
Das Primärsystem MUSS in alle HTTP-Requests an Dienste der TI im äußeren HTTP-Request den HTTP-Header user-agent gemäß [RFC7231] mit <Produktname>/<Produktversion> <Herstellername>/<client_id> mit
- <Produktname> gemäß eigener Definition, Länge 1-20 Zeichen, Zeichenvorrat [0-9a-zA-Z\-\.]
- <Produktversion> gemäß Produktidentifikation
- <Herstellername> gemäß eigener Definition, Länge 1-20 Zeichen, Zeichenvorrat [0-9a-zA-Z\-\.]
- <client_id> gemäß Registrierung bei der gematik
neu:
A_20015-02 - CS: HTTP-Header user-agent
Das Clientsystem des E-Rezept-Fachdienstes MUSS in alle HTTP-Requests an den E-Rezept-Fachdienst und IDP-Dienst im äußeren HTTP-Request den HTTP-Header user-agent gemäß [RFC7231] mit <Produktname>/<Produktversion> <Herstellername>/<client_id> mit
- <Produktname> gemäß eigener Definition, Länge 1-20 Zeichen, Zeichenvorrat [0-9a-zA-Z\-\.]
- <Produktversion> gemäß Produktidentifikation
- <Herstellername> gemäß eigener Definition, Länge 1-20 Zeichen, Zeichenvorrat [0-9a-zA-Z\-\.]
- <client_id> gemäß Registrierung bei der gematik
alt:
A_21568-01 - PS: HTTP-Header X-erp-user
Das Primärsystem MUSS in alle Anfragen an den E-Rezept-Fachdienst im äußeren HTTP-Request den HTTP-Header "X-erp-user" mit dem Wert
- "l" (kleines L) als PS eines Leistungserbringers
- oder "k" als CS eines Kostenträgers
neu:
A_21568-02 - CS: HTTP-Header X-erp-user
Das Clientsystem des E-Rezept-Fachdienstes MUSS in alle Anfragen an den E-Rezept-Fachdienst im äußeren HTTP-Request den HTTP-Header "X-erp-user" mit dem Wert
- "l" (kleines L) als PS eines Leistungserbringers
- "k" als CS eines Kostenträgers
- "v" als E-Rezept Frontend des Versicherten
- oder "n" als NCPeH-FD
A_21568-02 ersetzt zusätzlich "A_21567 - E-Rezept-FdV: HTTP-Header X-erp-user". A_21567 wird storniert.
alt:
A_21569 - PS: HTTP-Header X-erp-resource
Das Primärsystem MUSS in alle Anfragen an den E-Rezept-Fachdienst im äußeren HTTP-Request den HTTP-Header "X-erp-resource" mit dem Wert gemäß der angefragten Ressource im FHIR-Request einfügen. [<=]
neu:
A_21569-01 - CS: HTTP-Header X-erp-resource
Das Clientsystem des E-Rezept-Fachdienstes MUSS in alle Anfragen an den E-Rezept-Fachdienst im äußeren HTTP-Request den HTTP-Header "X-erp-resource" mit dem Wert gemäß der angefragten Ressource im FHIR-Request einfügen. [<=]
Die Tabelle TAB_ILFERP_014 wird um folgende Einträge erweitert:
Tabelle 17 : TAB_ILFERP_014 - HTTP-Header "X-erp-resource"
| Operation | X-erp-resource |
|---|---|
| POST /Task/<id>/$eu-close | Task |
| POST /$get-eu-prescriptions | Prescription |
| GET /$read-eu-access-permission | access-permission |
| POST /$grant-eu-access-permission | access-permission |
| DELETE /$revoke-eu-access-permission | access-permission |
7.4.2 Änderungen in gemILF_PS_eRp 5.1.2 Verschlüsselte Kommunikation zur VAU des E-Rezept-Fachdienstes
alt:
A_19741 - PS: Umsetzung sicherer Kanal zur VAU des E-Rezept-Fachdienstes
Das Primärsystem MUSS für alle Anfragen an den E-Rezept-Fachdienst für
- die Abfrage des capability statement
- den Zugriff auf Task oder Communication Ressourcen
neu:
A_19741-01 - CS: Umsetzung sicherer Kanal zur VAU des E-Rezept-Fachdienstes
Das Clientsystem des E-Rezept-Fachdienstes MUSS für alle Anfragen an den E-Rezept-Fachdienst für
- die Abfrage des capability statement
- den Zugriff auf Task, Communication, Consent, Prescription oder access-permission Ressourcen
7.4.3 Änderungen in gemILF_PS_eRp 5.1.3 Zertifikatsprüfung
alt:
A_20769 - PS: verpflichtende Zertifikatsprüfung
Das Primärsystem MUSS alle Zertifikate, die es aktiv verwendet (bspw. TLS-Verbindungsaufbau), auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Das Primärsystem MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]
neu:
A_20769-01 - CS: verpflichtende Zertifikatsprüfung
Das Clientsystem des E-Rezept-Fachdienst MUSS alle Zertifikate, die es aktiv verwendet (bspw. TLS-Verbindungsaufbau), auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Das Clientsystem des E-Rezept-Fachdienst MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]
7.4.3.1 Änderungen in gemILF_PS_eRp 5.1.3.1 Zertifikatsprüfung von Zertifikaten der TI
ToDo neue Afos für Clientsystem die TUC_PKI_018 umsetzen
7.4.3.2 Änderungen in gemILF_PS_eRp 5.1.3.2 Zertifikatsprüfung von Internet-Zertifikaten
alt:
A_20091 - PS: Prüfung der Zertifikate für TLS-Verbindung zu E-Rezept-Fachdienst und Identity Provider
Das Primärsystem MUSS für die Prüfung eines Zertifikats für den TLS-Verbindungsaufbau zum E-Rezept-Fachdienst und IDP das Zertifikat auf ein CA-Zertifikat einer CA, die die "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (https://cabforum.org/baseline-requirements-documents/) erfüllt, kryptographisch (Signaturprüfung) zurückführen können. Ansonsten MUSS es das Zertifikat als "ungültig" bewerten.
Das PS MUSS die zeitliche Gültigkeit des Zertifikats prüfen. Falls diese Prüfung negativ ausfällt, muss es das Zertifikat als "ungültig" bewerten. [<=]
neu:
A_20091-01 - CS: Prüfung der Zertifikate für TLS-Verbindung zu E-Rezept-Fachdienst und IDP-Dienst
Das Clientsystem des E-Rezept-Fachdienst MUSS für die Prüfung eines Zertifikats für den TLS-Verbindungsaufbau zum E-Rezept-Fachdienst und IDP das Zertifikat auf ein CA-Zertifikat einer CA, die die "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (https://cabforum.org/baseline-requirements-documents/) erfüllt, kryptographisch (Signaturprüfung) zurückführen können. Ansonsten MUSS es das Zertifikat als "ungültig" bewerten.
Das Clientsystem des E-Rezept-Fachdienst MUSS die zeitliche Gültigkeit des Zertifikats prüfen. Falls diese Prüfung negativ ausfällt, muss es das Zertifikat als "ungültig" bewerten. [<=]
7.4.3.3 Änderungen in gemILF_PS_eRp 5.1.4.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes
alt:
A_20654 - Registrierung des Primärsystems
Der Hersteller des Primärsystems MUSS sich über einen organisatorischen Prozess beim Anbieter des IDP-Dienstes für die Dienste, für welche Token abgerufen werden sollen, registrieren. Der IDP-Dienst vergibt dabei eine "client_id". Diese "client_id" MUSS vom Primärsystem bei Nutzung des IDP-Dienstes übertragen werden. [<=]
neu:
A_20654-01 - CS: Registrierung des Clientsystems des E-Rezept-Fachdienstes
Der Hersteller des Clientsystem des E-Rezept-Fachdienstes MUSS sich über einen organisatorischen Prozess beim Anbieter des IDP-Dienstes für die Dienste, für welche Token abgerufen werden sollen, registrieren. Der IDP-Dienst vergibt dabei eine "client_id". Diese "client_id" MUSS vom Clientsystem bei Nutzung des IDP-Dienstes übertragen werden. [<=]
alt:
A_20655 - Regelmäßiges Einlesen des Discovery Document
Das Primärsystem MUSS das Discovery Document (DD) [RFC8414] regelmäßig alle 24 Stunden einlesen und auswerten, und danach die darin aufgeführten URI zu den benötigten öffentlichen Schlüsseln (PUKs) und Diensten verwenden.
Der Downloadpunkt wird als Teil der organisatorischen Registrierung des Primärsystems beim IDP-Dienst übergeben.
Das Primärsystem MUSS den Downloadpunkt des Discovery Document als konfigurierbaren Parameter speichern. [<=]
neu:
A_20655-01 - CS: Regelmäßiges Einlesen des Discovery Document
Das Clientsystem MUSS das Discovery Document (DD) [RFC8414] regelmäßig alle 24 Stunden einlesen und auswerten, und danach die darin aufgeführten URI zu den benötigten öffentlichen Schlüsseln (PUKs) und Diensten verwenden.
Der Downloadpunkt wird als Teil der organisatorischen Registrierung des Clientsystems beim IDP-Dienst übergeben.
Das Clientsystem MUSS den Downloadpunkt des Discovery Document als konfigurierbaren Parameter speichern. [<=]
alt:
A_20656-01 - Prüfung der Signatur des Discovery Document
Das Primärsystem MUSS die JWS (JSON Web Signature) [RFC7515 # section-3 - Compact Serialization] Signatur des Discovery Document auf mathematische Korrektheit sowie über die Funktion "VerifyCertificate" des Konnektors gemäß [gemSpec_Kon#4.1.9.5.3] bzw. [gemILF_PS#4.4.4.3] auf Gültigkeit des ausstellenden Zertifikates innerhalb der TI prüfen.
[<=]
neu:
A_20656-02 - CS: Prüfung der Signatur des Discovery Document
Das Clientsystem MUSS die JWS (JSON Web Signature) [RFC7515 # section-3 - Compact Serialization] Signatur des Discovery Document auf mathematische Korrektheit sowie auf Gültigkeit des ausstellenden Zertifikates innerhalb der TI prüfen.
Das Clientsystem MUSS, wenn es den Konnektor oder den Basis-Consumer nutzt, die Gültigkeit des Zertifikates mit der Operation "VerifyCertificate" prüfen.
[<=]
Für die Prüfung des ausstellenden Zertifikats mittels Konnektor siehe [gemSpec_Kon#4.1.9.5.3] bzw. [gemILF_PS#4.4.4.3].
Für die Prüfung des ausstellenden Zertifikats mittels Basis-Consumer siehe [gemSpec_Basis_KTR_Consumer#A_17429].
alt:
A_20657 - Prüfung der Signatur des Discovery Document
Das Primärsystem MUSS die Signatur des Discovery Document auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID "oid_idpd" zurückführen können. [<=]
neu:
A_20657-01 - CS: Prüfung Typ und Rolle des Signaturzertifikats des Discovery Document
Das Clientsystem MUSS die Signatur des Discovery Document auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID "oid_idpd" zurückführen können. [<=]
alt:
A_20658 - Sicheres Löschen der Token
Das Primärsystem MUSS, wenn es absichtlich gestoppt oder deaktiviert wird, vorhandene "ACCESS_TOKEN", "ID_TOKEN" und "AUTHORIZATION_CODE"-Objekte sicher aus dem RAM löschen. [<=]
neu:
A_20658-01 - CS: Sicheres Löschen der Token
Das Clientsystem MUSS, wenn es kontrolliert beendet wird, vorhandene "ACCESS_TOKEN", "ID_TOKEN" und "AUTHORIZATION_CODE"-Objekte sicher löschen. [<=]
alt:
A_21337 - Löschung von TOKEN bei zeitlichem Ablauf
Das Primärsystem MUSS vorhandene "ACCESS_TOKEN", "ID_TOKEN" und "AUTHORIZATION_CODE"-Objekte nach Ablauf ihrer Gültigkeit sicher löschen. [<=]
neu:
A_21337-01 - CS: Löschung von TOKEN bei zeitlichem Ablauf
Das Clientsystem MUSS vorhandene "ACCESS_TOKEN", "ID_TOKEN" und "AUTHORIZATION_CODE"-Objekte nach Ablauf ihrer Gültigkeit sicher löschen. [<=]
alt:
A_21338 - Sichere Speicherung der Token
Das Primärsystem MUSS empfangene "ACCESS_TOKEN", "ID_TOKEN" und "AUTHORIZATION_CODE"-Objekte gegen unberechtigten Zugriff schützen. [<=]
neu:
A_21338-01 - CS: Sichere Speicherung der Token
Das Clientsystem MUSS empfangene "ACCESS_TOKEN", "ID_TOKEN" und "AUTHORIZATION_CODE"-Objekte gegen unberechtigten Zugriff schützen. [<=]
7.4.3.4 Änderungen in gemILF_PS_eRp 5.1.4.2 Abruf von Token beim IDP-Dienst
alt:
A_20659 - Erzeugen des CODE_VERIFIER
Das Primärsystem MUSS zur Laufzeit einen "CODE_VERIFIER" (Zufallswert) gemäß [RFC7636 # section-4.1] bilden. Der "CODE_VERIFIER" MUSS eine Länge von mindestens 43 und maximal 128 Zeichen enthalten. Dabei sind die folgenden Zeichen zulässig: [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~". [<=]
neu:
A_20659-01 - CS: Erzeugen des CODE_VERIFIER
Das Clientsystem MUSS zur Laufzeit einen "CODE_VERIFIER" (Zufallswert) gemäß [RFC7636 # section-4.1] bilden. Der "CODE_VERIFIER" MUSS eine Länge von mindestens 43 und maximal 128 Zeichen enthalten. Dabei sind die folgenden Zeichen zulässig: [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~". [<=]
alt:
A_20660 - Erzeugen des Hash-Werts des CODE_VERIFIER
Das Primärsystem MUSS über den "CODE_VERIFIER" einen SHA256-HASH-Wert, die sogenannte "CODE_CHALLENGE", gemäß [RFC7636 # section-4.2] bilden.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) [<=]
neu:
A_20660-01 - Erzeugen des Hash-Werts des CODE_VERIFIER
Das Clientsystem MUSS über den "CODE_VERIFIER" einen SHA256-HASH-Wert, die sogenannte "CODE_CHALLENGE", gemäß [RFC7636 # section-4.2] bilden.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) [<=]
alt:
A_20661 - Anfrage des "AUTHORIZATION_CODE" für ein "ACCESS_TOKEN"
Das Primärsystem MUSS den Antrag zum "AUTHORIZATION_CODE" für ein "ACCESS_TOKEN" beim Authorization-Endpunkt (URI_AUTH) in Form eines HTTP/1.1 GET Request stellen und dabei die folgenden Attribute anführen:
• "response_type"
• "scope"
• "client_id"
• "redirect_uri"
• "code_challenge" (Hashwert des "code_verifier") [RFC7636 # section-4.2]
• "code_challenge_method" HASH-Algorithmus (S256) [RFC7636 # section-4.3] [<=]
neu:
A_20661-01 - CS: Anfrage des "AUTHORIZATION_CODE" für ein "ACCESS_TOKEN"
Das Clientsystem MUSS den Antrag zum "AUTHORIZATION_CODE" für ein "ACCESS_TOKEN" beim Authorization-Endpunkt (URI_AUTH) in Form eines HTTP/1.1 GET Request stellen und dabei die folgenden Attribute anführen:
• "response_type"
• "scope"
• "client_id"
• "redirect_uri"
• "code_challenge" (Hashwert des "code_verifier") [RFC7636 # section-4.2]
• "code_challenge_method" HASH-Algorithmus (S256) [RFC7636 # section-4.3] [<=]
alt:
A_20662 - Annahme des "user_consent" und des "CHALLENGE_TOKEN"
Das Primärsystem MUSS den "user_consent" und den "CHALLENGE_TOKEN" vom Authorization-Endpunkt des IDP-Dienstes annehmen. Der Authorization-Endpunkt liefert diese als Antwort auf den Authorization-Request des Primärsystems. [<=]
neu:
A_20662-01 - CS: Annahme des "user_consent" und des "CHALLENGE_TOKEN"
Das Clientsystem MUSS den "user_consent" und den "CHALLENGE_TOKEN" vom Authorization-Endpunkt des IDP-Dienstes annehmen. Der Authorization-Endpunkt liefert diese als Antwort auf den Authorization-Request des Clientsystems. [<=]
alt:
A_20663-01 - Prüfung der Signatur des CHALLENGE_TOKEN
Das Primärsystem MUSS die Signatur des "CHALLENGE_TOKEN" gegen den aktuellen öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_SIG" prüfen. Liegt dem Primärsystem der öffentliche Schlüssel des Authorization-Endpunktes noch nicht vor, MUSS es diesen gemäß dem "kid"-Parameter "puk_idp_sig" aus dem Discovery Document abrufen. [<=]
neu:
A_20663-02 - CS: Prüfung der Signatur des CHALLENGE_TOKEN
Das Clientsystem MUSS die Signatur des "CHALLENGE_TOKEN" gegen den aktuellen öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_SIG" prüfen. Liegt dem Clientsystem der öffentliche Schlüssel des Authorization-Endpunktes noch nicht vor, MUSS es diesen gemäß dem "kid"-Parameter "puk_idp_sig" aus dem Discovery Document abrufen. [<=]
alt:
A_20665-01 - Signatur der Challenge des IdP-Dienstes
Das Primärsystem MUSS für das Signieren des CHALLENGE_TOKEN des IdP-Dienstes mit der Identität ID.HCI.AUT der SM-B die Operation ExternalAuthenticate des Konnektors gemäß [gemSpec_Kon#4.1.13.4] bzw. [gemILF_PS#4.4.6.1] verwenden und als zu signierende Daten BinaryString den SHA-256-Hashwert des CHALLENGE_TOKEN in Base64-Codierung übergeben.
[<=]
neu:
A_20665-02 - Signatur der Challenge des IdP-Dienstes
Das Clientsystem MUSS, wenn es sich mit seiner SM-B authentisiert, den CHALLENGE_TOKEN des IdP-Dienstes mit der Identität ID.HCI.AUT der SM-B signieren.
Das Clientsystem MUSS, wenn es den Konnektor oder den Basis-Consumer nutzt, für das Signieren die Operation ExternalAuthenticate verwenden und als zu signierende Daten BinaryString den SHA-256-Hashwert des CHALLENGE_TOKEN in Base64-Codierung übergeben. [<=]
Für das Signieren mittels Konnektor siehe [gemSpec_Kon#4.1.13.4] bzw. [gemILF_PS#4.4.6.1].
Die referenzierte Anforderung A_20266-02 wird aus [gemILF_PS_eRp] entfernt und durch die folgende Hinweise ersetzt:
Das Auslesen des Zertifikat C.HCI.AUT der SM-B mittels Konnektor erfolgt über über die Operation ReadCardCertificate. Siehe [gemILF_PS_ePA#A_20266-* Auslesen des Authentisierungszertifikates].
Das Auslesen des Zertifikat C.HCI.AUT der SM-B mittels Basis-Consumer erfolgt über über die Operation ReadCertificate. Siehe [gemILF_PS_ePA#A_25720-* Auslesen des Authentisierungszertifikates aus einem HSM].
alt:
A_20667-01 - Response auf die Challenge des Authorization-Endpunktes
Das Primärsystem MUSS das eingereichte "CHALLENGE_TOKEN" zusammen mit der von der Smartcard signierten Challenge-Signatur "signed_challenge" (siehe A_20665-*) und dem Authentifizierungszertifikat der Smartcard (siehe A_20666-*), mit dem öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_ENC" verschlüsselt, in Form eines HTTP-POST-Requests senden. [<=]
neu:
A_20667-03 - CS: Response auf die Challenge des Authorization-Endpunktes
Das Clientsystem MUSS das eingereichte "CHALLENGE_TOKEN" zusammen mit der von der Smartcard signierten Challenge-Signatur "signed_challenge" und dem Authentifizierungszertifikat der Smartcard, mit dem öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_ENC" verschlüsselt, in Form eines HTTP-POST-Requests senden. [<=]
alt:
A_20668 - Annahme des "AUTHORIZATION_CODE"
Das Primärsystem MUSS den vom Authorization-Endpunkt als Antwort auf die signierte Challenge gesendeten "AUTHORIZATION_CODE" verarbeiten. Das Primärsystem MUSS das "AUTHORIZATION_CODE" ablehnen, wenn dieser außerhalb der mit dem Authorization-Endpunkt etablierten TLS-Verbindung übertragen wird. [<=]
neu:
A_20668-01 - CS: Annahme des "AUTHORIZATION_CODE"
Das Clientsystem MUSS den vom Authorization-Endpunkt als Antwort auf die signierte Challenge gesendeten "AUTHORIZATION_CODE" verarbeiten. Das Clientsystem MUSS das "AUTHORIZATION_CODE" ablehnen, wenn dieser außerhalb der mit dem Authorization-Endpunkt etablierten TLS-Verbindung übertragen wird. [<=]
alt:
A_21333 - Erzeugung des "Token-Key"
Das Primärsystem MUSS vor dem Abrufen von ID_Token und ACCESS_Token einen zufälligen 256bit-AES-Schlüssel ("Token-Key") erzeugen. [<=]
neu:
A_21333-01 - CS: Erzeugung des "Token-Key"
Das Clientsystem MUSS vor dem Abrufen von ID_Token und ACCESS_Token einen zufälligen 256bit-AES-Schlüssel ("Token-Key") erzeugen. [<=]
alt:
A_21334 - Erzeugung des "KEY_VERIFIER"
Das Primärsystem MUSS den "KEY_VERIFIER" bilden, indem "Token-Key" und "CODE_VERIFIER" in einem JSON-Objekt kodiert werden. [<=]
neu:
A_21334-01 - CS: Erzeugung des "KEY_VERIFIER"
Das Clientsystem MUSS den "KEY_VERIFIER" bilden, indem "Token-Key" und "CODE_VERIFIER" in einem JSON-Objekt kodiert werden. [<=]
alt:
A_20671-01 - Einreichen des AUTHORIZATION_CODE beim Token-Endpunkt
Das Primärsystem MUSS den "Key_Verifier" mittels JWE und PUK_IDP_ENC verschlüsseln und zusammen mit dem "AUTHORIZATION_CODE“ TLS-gesichert und als HTTP/1.1 POST Request an den Token-Endpunkt senden.
[<=]
neu:
A_20671-02 - CS: Einreichen des AUTHORIZATION_CODE beim Token-Endpunkt
Das Clientsystem MUSS den "Key_Verifier" mittels JWE und PUK_IDP_ENC verschlüsseln und zusammen mit dem "AUTHORIZATION_CODE“ TLS-gesichert und als HTTP/1.1 POST Request an den Token-Endpunkt senden.
[<=]
alt:
A_20672-01 - Annahme des ID_TOKEN
Das Primärsystem MUSS das vom Token-Endpunkt ausgegebene "ID_TOKEN" als HTTP/1.1 Statusmeldung 200 verarbeiten und mittels "Token-Key" entschlüsseln. Das Primärsystem MUSS das "ID_TOKEN" ablehnen, wenn dieses außerhalb der mit dem Token-Endpunkt etablierten TLS-Verbindung übertragen wird oder nicht mit dem vorher übermittelten "Token-Key" verschlüsselt war. [<=]
neu:
A_20672-02 - CS: Annahme des ID_TOKEN
Das Clientsystem MUSS das vom Token-Endpunkt ausgegebene "ID_TOKEN" als HTTP/1.1 Statusmeldung 200 verarbeiten und mittels "Token-Key" entschlüsseln. Das Clientsystem MUSS das "ID_TOKEN" ablehnen, wenn dieses außerhalb der mit dem Token-Endpunkt etablierten TLS-Verbindung übertragen wird oder nicht mit dem vorher übermittelten "Token-Key" verschlüsselt war. [<=]
alt:
A_20673-01 - Annahme des "ACCESS_TOKEN"
Das Primärsystem MUSS das vom Token-Endpunkt ausgegebene "ACCESS_TOKEN" in der HTTP/1.1 Statusmeldung 200 verarbeiten und mittels "Token-Key" entschlüsseln. Das Primärsystem MUSS das "ACCESS_TOKEN" ablehnen, wenn dieses außerhalb der mit dem Token-Endpunkt etablierten TLS-Verbindung übertragen wird oder nicht mit dem vorher übermittelten "Token-Key" verschlüsselt war.
[<=]
neu:
A_20673-02 - CS: Annahme des "ACCESS_TOKEN"
Das Clientsystem MUSS das vom Token-Endpunkt ausgegebene "ACCESS_TOKEN" in der HTTP/1.1 Statusmeldung 200 verarbeiten und mittels "Token-Key" entschlüsseln. Das Clientsystem MUSS das "ACCESS_TOKEN" ablehnen, wenn dieses außerhalb der mit dem Token-Endpunkt etablierten TLS-Verbindung übertragen wird oder nicht mit dem vorher übermittelten "Token-Key" verschlüsselt war.
[<=]
alt:
A_20674 - Formale Prüfung der Signatur des ID_TOKEN
Das Primärsystem MUSS die Signatur des ID_TOKEN mathematisch prüfen und auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID "oid_idpd" zurückführen können. [<=]
neu:
A_20674-01 - CS: Formale Prüfung der Signatur des ACCESS_TOKEN
Das Clientsystem MUSS die Signatur des ACCESS_TOKEN mathematisch prüfen und auf ein C.FD.SIG-Zertifikat mit der Rollen-OID "oid_idpd" zurückführen.
[<=]
alt:
A_20675 - Gültigkeitsprüfung der Signatur des ID_TOKEN innerhalb der TI
Das Primärsystem MUSS das zur Signatur des ID_TOKEN verwendete Zertifikat über die Funktion „VerifyCertificate“ des Konnektors gemäß [gemSpec_Kon#4.1.9.5.3] bzw. [gemILF_PS#4.4.4.3] auf Gültigkeit innerhalb der TI prüfen. [<=]
neu:
A_20675-01 - CS: Gültigkeitsprüfung des Signaturzertifikats des ACCESS_TOKEN innerhalb der TI
Das Clientsystem MUSS das zur Signatur des ACCESS_TOKEN verwendete Zertifikat auf Gültigkeit innerhalb der TI prüfen.
Das Clientsystem MUSS, wenn es den Konnektor oder den Basis-Consumer nutzt, mit der Operation "VerifyCertificate" prüfen. [<=]
Für die Prüfung mittels Konnektor siehe [gemSpec_Kon#4.1.9.5.3] bzw. [gemILF_PS#4.4.4.3].
Für die Prüfung mittels Basis-Consumer siehe [gemSpec_Basis_KTR_Consumer#A_17429].
7.4.4 Zuweisungen von Anforderungen aus gemSpec_Krypt
Die folgenden Anforderungen aus gemSpec_Krypt werden dem Produkttypen NCPeH-FD zugewiesen:
A_20161-01 - E-Rezept-Client, Request-Erstellung, Prüfverfahren: Produktgutachten
A_20174 - E-Rezept-Client, Response-Auswertung, Prüfverfahren: Produktgutachten
A_20175 - E-Rezept-Client, Speicherung Nutzerpseudonym, Prüfverfahren: Produktgutachten
A_21216 - E-Rezept-Client, Zertifikatsprüfung auf TSL-Basis, Prüfverfahren: Produktgutachten
A_21222 - E-Rezept-Client, allgemein Zertifikatsprüfung, Prüfverfahren: Produktgutachten
A_21275-01 - TLS-Verbindungen, zulässige Hashfunktionen bei Signaturen im TLS-Handshake, Prüfverfahren: Produktgutachten (bereits zugeordnet)
A_21332-02 - E-Rezept: TLS-Vorgaben, Prüfverfahren: Produktgutachten
7.4.5 Änderung in gemSpec_DM_eRp 2.1 FHIR-Ressourcen
alt:
A_22483 - Version FHIR-Package de.gematik.erezept-workflow
Die Produkttypen der Anwendung E-Rezept und das PS der verordnenden und abgebenden LEI MÜSSEN das FHIR-Package de.gematik.erezept-workflow in der Version gemäß [FHIR Version] unterstützen. [<=]
neu:
A_22483-01 - Version FHIR-Package de.gematik.erezept-workflow
Die Produkttypen der Anwendung E-Rezept und Clientsystem des E-Rezept-Fachdienstes MÜSSEN das FHIR-Package de.gematik.erezept-workflow in der Version gemäß [FHIR Version] unterstützen. [<=]
alt:
A_22216 - FHIR-Ressourcen Versionsangabe
Die Produkttypen der Anwendung E-Rezept und das PS der verordnenden und abgebenden LEI MÜSSEN alle generierten FHIR-Ressourcen mit der Versionsnummer gemäß https://www.hl7.org/fhir/datatypes.html#canonical im Feld Ressource.meta.profile kennzeichnen, zu dessen aktuell gültiger Profilversion sie mutmaßlich validieren. [<=]
neu:
A_22216-01 - FHIR-Ressourcen Versionsangabe
Die Produkttypen der Anwendung E-Rezept und Clientsystem des E-Rezept-Fachdienstes MÜSSEN alle generierten FHIR-Ressourcen mit der Versionsnummer gemäß https://www.hl7.org/fhir/datatypes.html#canonical im Feld Ressource.meta.profile kennzeichnen, zu dessen aktuell gültiger Profilversion sie mutmaßlich validieren. [<=]
Die folgenden Anforderungen aus gemSpec_DM_eRp werden dem Produkttypen NCPeH-FD zugewiesen:
A_26237 - FHIR-Ressourcen - Ressource-ID in fullUrl, Prüfverfahren: funktionaler Test
A_26238 - FHIR-Ressourcen - Format fullUrl, Prüfverfahren: funktionaler Test
7.5 Betrieb
7.5.1 Änderungen in der gemKPT_Betr
7.5.1.1 Änderung in 5.3.2.9 Anwendung E-Rezept (PDT50, PDT59)
Hinzufügen des neuen UseCases zur Tabelle Tab_gemKPT_Betr_eRP_S::O/A
| Produkttyp / Anwendungstyp | S/A-ID |
Schnittstellen::Operation / Anwendungsfall |
Beschreibung | Berichtsformat-Alias (sofern von Schnittstellen::Operation bzw. Anwendungsfall abweichend) |
|---|---|---|---|---|
| E-Rezept-Fachdienst - PDT50 | ||||
| ... | ||||
| PDT50 | A59 | ERP.UC_3_16 | Zugriffsberechtigung durch Versicherten erstellen | |
| PDT50 | A60 | ERP.UC_3_17 | Zugriffsberechtigung durch Versicherten löschen | |
| PDT50 | A61 | ERP.UC_3_18 | Zugriffsberechtigung durch Versicherten einsehen | |
| PDT50 | A62 | ERP.UC_4_19 | Demographische Daten eines Versicherten abrufen | |
| PDT50 | A63 | ERP.UC_4_20 | Liste der einlösbaren E-Rezepte eines Versicherten abrufen | |
| PDT50 | A64 | ERP.UC_4_21 | Liste ausgewählter E-Rezepte eines Versicherten abrufen | |
| PDT50 | A65 | ERP.UC_4_22 | Abgabe eines E-Rezeptes im europäischen Ausland | |
7.5.2 Änderungen in der gemSpec_Perf
7.5.2.1 Änderung in 3.2.2.2 Format
Erweiterung der Tabelle 16: Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst um den neuen UseCase
| $FD-operation |
Operation |
Schnittstelle zu |
|---|---|---|
| ... | ||
| ERP.UC_3_16 | POST /$grant-eu-access-permission | FdV |
| ERP.UC_3_17 |
DELETE /$revoke-eu-access-permission |
FdV |
| ERP.UC_3_18 |
GET /$read-eu-access-permission |
FdV |
| ERP.UC_4_19 | POST /$get-eu-prescriptions mit Requesttype demographics | NCPeH |
| ERP.UC_4_20 | POST /$get-eu-prescriptions mit Requesttype e-prescriptions-list | NCPeH |
| ERP.UC_4_21 | POST /$get-eu-prescriptions mit Requesttype e-prescriptions-retrieval | NCPeH |
| ERP.UC_4_22 | POST /Task/<id>/$eu-close | NCPeH |
7.6 Test
7.6.1 Testunterstützung für den PET
Das [eHDSI Test Framework] definiert eine Durchführung von Tests in der Produktivumgebung nach Erteilung der Betriebserlaubnis (Product Environment Test - PET). Diese Tests MÜSSEN im Rahmen der Inbetriebnahme bzw. des Upgrades auf eine neue eHDSI Release Version (Wave) erfolgen. Dementsprechend muss produktübergreifend eine Möglichkeit geschaffen werden, diese Tests mit der Produktivumgebung der TI durchzuführen.
In Vorbereitung des PET MUSS sich die DVKA eine oder mehrere Versichertenidentitäten zu Prüfzwecken beschaffen. Dazu können eGK Prüfkarten für die Rolle und Identität eines Prüfversicherten über den gematik WEB-Shop [gemWebShop] bestellt werden.
Die DVKA MUSS sich um LE-DE (Ärzte oder Zahnärzte) kümmern, um für den PET realitätsnahe E-Rezepte in den E-Rezept-Fachdienst einstellen zu können. Das Einstellen der E-Rezepte erfolgt dabei in der Umgebung des jeweiligen LE-DE.
Die Erteilung der Zugriffsberechtigung für die Prüfidentität kann mittels gematik E-Rezept-App erfolgen.
Die Testdurchführung ist mit dem Betrieb der gematik abzustimmen. Insbesondere die Sicherstellung der Verfügbarkeit der TI Produkte und passenden Produktversionen ist hier relevant.
8 Beispiele und Referenzimplementierungen
API-Beschreibung: https://github.com/gematik/api-erp/blob/feature/eu-eprescription/docs/erp_eprescription.adoc
9 Anhang A – Verzeichnisse
9.1 Abkürzungen
| Kürzel | Erläuterung |
|---|---|
| API | Application Programming Interface |
| CS | Clientsystem |
| DVKA | Deutsche Verbindungsstelle Krankenversicherung – Ausland |
| eHDSI | eHealth Digital Service Infrastructure |
| FD | Fachdienst |
| FdV | Frontend des Versicherten |
| LE-EU | Leistungserbringer im europäischen Ausland |
| LEI-EU | Leistungserbringerinstitution im europäischen Ausland |
| NCPeH | National Contact Point eHealth |
| PS | Primärsystem |
| TI | Telematikinfrastruktur |
| UC | Use Case, Anwendungsfall |
9.2 Abbildungsverzeichnis
- Abbildung 1 : Übersicht Architektur
- Abbildung 2 : ABB_SYSLERP_001 Übersicht der Fachanwendung E-Rezept
- Abbildung 3 : SD Einwilligung durch Versicherten erteilen
- Abbildung 4 : SD Einwilligung durch Versicherten widerrufen
- Abbildung 5 : SD Einwilligungen durch Versicherten einsehen
- Abbildung 6 : SD Zugriffsberechtigung durch Versicherten erstellen
- Abbildung 7 : SD Zugriffsberechtigung durch Versicherten löschen
- Abbildung 8 : SD Zugriffsberechtigung durch Versicherten einsehen
- Abbildung 9 : SD Demographische Daten eines Versicherten abrufen
- Abbildung 10 : SD Liste der einlösbaren E-Rezepte eines Versicherten abrufen
- Abbildung 11 : SD Liste ausgewählter E-Rezepte eines Versicherten abrufen
- Abbildung 12 : SD Abgabe von E-Rezepten im europäischen Ausland
9.3 Tabellenverzeichnis
- Tabelle 1 : Statusübergänge
- Tabelle 2 : Einwilligung durch Versicherten erteilen
- Tabelle 3 : Einwilligung durch Versicherten widerrufen
- Tabelle 4 : Einwilligungen durch Versicherten einsehen
- Tabelle 5 : Zugriffsberechtigung durch Versicherten erstellen
- Tabelle 6 : Zugriffsberechtigung durch Versicherten löschen
- Tabelle 7 : Zugriffsberechtigung durch Versicherten einsehen
- Tabelle 8: TAB_eRPFD_004 Versichertenprotokoll
- Tabelle 9: TAB_eRPFD_004 Versichertenprotokoll
- Tabelle 10 : TAB_FdVERP_003 – Übersicht Anwendungsfälle E-Rezept-FdV
- Tabelle 11 : TAB_FdVERP_020 – Einwilligung erteilen
- Tabelle 12 : TAB_FdVERP_021 – Einwilligungsinformation abrufen
- Tabelle 13 : TAB_FdVERP_022 – Einwilligung widerrufen
- Tabelle 14 : TAB_FdVERP_xxx – Zugriffsberechtigung erteilen
- Tabelle 15 : TAB_FdVERP_xxx – Zugriffsberechtigung abrufen
- Tabelle 16 : TAB_FdVERP_xxx – Zugriffsberechtigung löschen
- Tabelle 17 : TAB_ILFERP_014 - HTTP-Header "X-erp-resource"
9.4 Referenzierte Dokumente
9.4.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.
| [Quelle] |
Herausgeber: Titel |
| [gemGlossar] |
gematik: Glossar der Telematikinfrastruktur |
| [gemILF_PS] | gematik: Implementierungsleitfaden Primärsysteme – Telematikinfrastruktur (TI) |
| [gemILF_PS_ePA] | gematik: Implementierungsleitfaden Primärsysteme ePA für alle |
| [gemILF_PS_eRp] | gematik: Spezifikation Implementierungsleitfaden Primärsysteme – E-Rezept |
| [gemSpec_Basis_KTR_Consumer] | gematik: Spezifikation Basis- und KTR-Consumer |
| [gemSpec_DM_eRp] | gematik: Spezifikation Datenmodell E-Rezept |
| [gemSpec_FD_eRp] | gematik: Spezifikation E-Rezept-Fachdienst |
| [gemSpec_eRp_FdV] | gematik: Spezifikation E-Rezept-Frontend des Versicherten |
| [gemSpec_Kon] | gematik: Spezifikation Konnektor |
| [gemSpec_Krypt] | gematik: Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur |
| [gemSpec_VZD_FHIR_Directory] | gematik: Spezifikation Verzeichnisdienst FHIR-Directory |
| [FHIR Version] | https://github.com/gematik/api-erp/blob/master/docs/erp_fhirversion.adoc#e-rezept-fhir-package-versionsmanagement |
9.4.2 Weitere Dokumente
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
| [gematik-workflow-projekt] | https://simplifier.net/erezept-workflow |
| [gemWebShop] | https://fachportal.gematik.de/toolkit/pruefkarte-egk-fuer-dvo |