Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

Abruf der E-Rezepte in der Apotheke nach Autorisierung

    

     

      
Version
      
1.1.1
     
     

      
Revision
      
949257
     
     

      
Stand
      
15.02.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_eRp_Autorisierung_Apo
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt das Feature zum Abruf der E-Rezepte eines Versicherten in der Apotheke nach Autorisierung mit der eGK des Versicherten. Das Feature umfasst die Darstellung der Use Cases für die abgebende Leistungserbringerinstitution und Versicherte sowie die Ergänzungen bei den funktionalen Anforderungen an die Schnittstellen des E-Rezept-Fachdienstes und dem Primärsystem der abgebenden Leistungserbringerinstitution.

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, E-Rezept Frontend des Versicherten sowie Hersteller von Apothekenverwaltungssystemen.

1.3 Abgrenzungen

Für die Einführung des Features des Abrufs der E-Rezepte in der Apotheke nach Autorisierung wird ausschließlich die elektronische Gesundheitskarte (eGK) als Autorisierungsmittel betrachtet. 

Beim Lösungsansatz mittels PoPP wird eine Erweiterung des Anwendungsfall betrachtet, sobald das Plattform Feature beispielsweise um die eID erweitert wird. Siehe auch [gemF_PoPP#3 Einordnung in die Telematikinfrastruktur].

Beim Lösungsansatz mittels strukturiertem Prüfungsnachweis ist, da es sich um eine Übergangslösung handelt, eine Erweiterung des Anwendungsfalls um die eID nicht vorgesehen.

Der Lösungsansatz Anwesenheitsbeleg mit PoPP-Dienst (gesamte Kapitel 3) befindet sich noch in Abstimmung mit den Gesellschaftern und ist daher nicht normativ.

1.4 Methodik

Anforderungen und Anwendungsfälle

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

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Afo / Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

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

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

User Stories

Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten 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.

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

In diesem Abschnitt wird das Feature fachlich motiviert und der Mehrwert für Nutzer vorgestellt. Aus diesen Epics und User Stories wird anschließend ein technisches Konzept abgeleitet.

2.1 Epic

Elektronische Rezepte sollen flexibel und ohne Medienbrüche von Versicherten in ihrer Wunsch-Apotheke eingelöst werden können. Neben den bestehenden Optionen zu Einlösung eines E-Rezepts, soll der Versicherte gemäß § 312, Abs. 1, Nr. 6 SGB V einzig durch die Vorlage seiner elektronischen Gesundheitskarte eine Apotheke (bzw. einen berechtigten Leistungserbringer) dazu berechtigen können, seine einlösbaren E-Rezepte aus dem E-Rezept-Fachdienst abrufen zu können. Dies führt zu einem erhöhten Komfort, falls Versicherte bspw. sehr viele Verordnungen einlösen möchten, die E-Rezept-App nicht nutzen möchten oder der 2D-Code der Verordnung auf dem Ausdruck nicht mehr lesbar ist. Um den Komfort und die Praxistauglichkeit dieser Einlöse-Option sicherzustellen, soll die Autorisierung der Apotheke ohne PIN-Eingabe und auch für Vertreter möglich sein.

Als Vertreter wird eine vertrauenswürdige Person bezeichnet, die für den Versicherten dessen Rezepte einlösen soll. Für diesen Zweck übergibt der Versicherte seine eGK an diese Person, um die Apotheke zu autorisieren, die offenen Rezepte abzurufen. Der Versicherte teilt dem Vertreter nicht seine PIN für die eGK mit.

2.2 User Stories

Die User Stories beschreiben die Erwartungen der Nutzer.

2.2.1 User Stories für Versicherte

Als Patient möchte ich im Vorfeld der Rezepteinlösung oder vor Ort in der Apotheke verstehen, dass ich mein Rezept in der Apotheke auch allein mit der elektronischen Gesundheitskarte (eGK) einlösen kann, so dass ich informiert entscheiden kann, welchen Weg ich gehen möchte.

Als Patient möchte ich im Vorfeld der Rezepteinlösung oder vor Ort in der Apotheke verstehen, dass mein Apotheker in dem Fall, dass ich die eGK übergebe, alle meine offenen Rezepte lesen kann, so dass ich eine informierte Entscheidung treffen kann, ob das für mich passt.
Erläuterung: wenn ich zwei Rezepte offen habe und nicht alle eingelöst werden sollen, muss mich der Apotheker fragen, um welches Rezept es geht. Sollte eins der Medikamente für mich unangenehm oder sogar als stigmatisierend empfunden werden, kann mich das in eine ungewollte Situation bringen, wenn mich der Apotheke bspw. fragt, ob er auch das Psychopharmakon abgeben soll.

Als Patient möchte ich im Vorfeld der Rezepteinlösung oder vor Ort in der Apotheke verstehen, welche Vor- und Nachteile die E-Rezept-App gegenüber der Übergabe meiner eGK in der Apotheke bringt, so dass ich besser einschätzen kann, welche Methode für mich die bessere ist.

Als Patient möchte ich verstehen, dass der Vertreter ALLE verfügbaren offenen Rezepte einlösen kann, wenn ich ihm meine eGK übergebe.

Als Patient möchte ich jederzeit die Wahl haben, welches der Verfahren ich wählen möchte, so dass ich volle Flexibilität habe.

Als Patient möchte ich bei immer die Möglichkeit haben, die Apotheke mit der eGK zu berechtigen, egal ob ich einen Ausdruck erhalten habe oder die App verwende. 

Als Patient möchte ich in der Apotheke meine eGK stecken, an den Kartenleser halten oder übergeben können, so dass mein Apotheker mein Rezept bekommen kann und ich nicht auf dem Papierausdruck oder die E-Rezept-App angewiesen bin.

Als Patient möchte ich keine weiteren Absicherungen in Form einer PIN oder eines vergleichbaren Mechanismus in der Apotheke einsetzen müssen, so dass das Einlösen einfach bleibt und ich nicht noch die PIN bei meiner Krankenkasse  beantragen und mir merken muss.

Als Patient möchte ich, dass das Einlösen von Rezepten in der Apotheke für einen Vertreter mittels Übergabe meiner eGK genauso einfach ist wie das Einlösen mit seiner eigenen eGK ist, so dass es mir leichter fällt, jemandem zu bitten, für mich in die Apotheke zu gehen.

Als Patient möchte ich, dass sich die Statusanzeige für die Rezepte in meiner App auch dann aktualisieren, wenn ich die eGK zum Einlösen verwendet habe, so dass ich immer auf dem neuesten Stand bleibe. 

Als Patient möchte ich meine eGK über meine Krankenkasse sperren lassen, wenn ich sie verloren habe, sodass kein Fremder meine Rezepte einlösen kann.

Als Patient möchte ich, dass immer nur meine gültige eGK (aktuelle Karte und Folgekarte) den Apotheker berechtigen kann, auf meine Rezepte zuzugreifen.

Als Patient möchte ich, dass ein Apotheker meine E-Rezepte nicht abrufen kann, ohne dass ich (oder mein Vertreter) ihn vorher dazu durch die Übergabe meiner eGK (oder des Rezeptcodes per Ausdruck oder App) autorisiert habe (hat).

Als Patient möchte ich in der E-Rezept-App oder den E-Rezept-AdV nachvollziehen können, wann welche Apotheke E-Rezepte mit der eGK abgerufen hat, falls ich nicht selbst mit meiner eGK in der Apotheke war (sondern z.B. ein Stellvertreter) und bei Bedarf die Apotheke kontaktieren kann. 

2.2.2 User Story für Vertreter

Als Vertreter möchte ich, dass das Einlösen von Rezepten in der Apotheke mittels Übergabe der eGK der zu vertretenden Person genauso einfach ist wie das Einlösen mittels meiner eigenen eGK, so dass ich nicht noch weitere Hürden nehmen muss und der Prozess für mich handhabbar bleibt.

2.2.3 User Story für Apotheke

Als Apotheker möchte ich, dass meine Patienten mir mithilfe der eGK Zugang zu ihren Rezepten geben können, so dass ich neben der Zuweisung eines E-Rezept-Tokens, der E-Rezept-App oder dem Papierausdruck noch eine weitere Möglichkeit habe, meine Kunden gut zu bedienen.

Als Apotheker möchte ich, dass der Abruf der Rezepte nach Übergabe der eGK genauso einfach und schnell geht, wie wenn der Patient mir den Rezeptcode per App oder Ausdruck vorzeigt, so dass ich weiterhin wirtschaftlich arbeiten kann und meine Patienten nicht lange warten müssen.

Als Apotheker möchte ich alle verfügbaren offenen Rezepte meines Kunden sehen und dann entscheiden, welche ich davon beliefern kann.

Als Apotheker möchte ich, dass die neuen Zugangsmöglichkeiten keine Mehrkosten für mich bedeutet, damit ich keine zusätzlichen finanziellen Aufwände habe.

Als Apotheker möchte ich die eGK meines Patienten nur einmal in das Kartenterminal stecken und dann nicht nur das E-Rezept bearbeiten, sondern auch die Anwendung elektronische Patientenakte (ePA) und elektronischer Medikationsplan (eMP) nutzen. Wenn ePA oder eMP eine PIN-Eingabe erfordert, soll der Patient diese jeweils eingeben.

Als Apotheker möchte ich Rezepte wieder zurückgeben können, wenn der Patient nicht alle Rezepte in meiner Apotheke einlösen möchte.

In diesem Dokument werden zwei Lösungsansätze beschrieben:

• Anwesenheitsbeleg mittels PoPP-Dienst
• Anwesenheitsbeleg mittels strukturiertem VSDM Prüfungsnachweis

Sie werden ggf. stufenweise eingeführt werden.

3 Anwesenheitsbeleg mittels PoPP-Dienst

Der Lösungsansatz Anwesenheitsbeleg mit PoPP-Dienst (gesamtes Kapitel 3) befindet sich noch in Abstimmung mit den Gesellschaftern und ist daher nicht normativ.

3.1 Einordnung in die Telematikinfrastruktur

Das Feature zum Abruf der E-Rezepte in der Apotheke nach Autorisierung nutzt die bestehende Infrastruktur der Anwendungen E-Rezept und einen neu einzuführenden Service zum Anwesenheitsnachweis (Proof of Patient Presence, PoPP-Dienst). Der Konnektor wird um das Modul PoPP für diesen Service erweitert.

Abbildung 1: Übersicht E-Rezept-Komponenten

Der PoPP-Dienst ist ein Dienst im zentralen Netz der TI, welcher einen kryptographisch gesicherten Nachweis ausstellt, dass eine eGK in einer LEI gesteckt wurde. Eine PIN-Eingabe des Versicherten ist hierzu nicht notwendig. Die Kommunikation vom Primärsystem zum PoPP-Dienst erfolgt über ein Modul im Konnektor.

3.2 Technisches Konzept

3.2.1 Autorisierung mittels eGK

Beim Abruf der E-Rezepte in einer Apotheke nach Autorisierung wird die eGK des Versicherten als Mittel für die Autorisierung verwendet. Andere Mittel für die Autorisierung als die eGK werden nicht unterstützt.

Das Primärsystem (PS) ruft die Operation für den Anwesenheitsnachweis am Konnektor auf. Das Modul PoPP des Konnektors liefert einen durch den PoPP-Dienst signierten Token, welcher belegt, dass die eGK im eHealth-Kartenterminal der LEI gesteckt ist. Im Rahmen dieser Operation wird geprüft, ob die eGK nicht gesperrt und das Authentisierungszertifikat auf der eGK gültig ist.

Der Versicherte ist angehalten, bei Verlust seiner eGK dieses bei seiner Krankenkasse anzuzeigen, damit die Krankenkasse die eGK sperren kann. Die Prozesse zum Sperren der eGK liegen in der Verantwortung der Krankenkassen. Für Anforderungen an den Sperrprozess siehe  .

3.2.2 Anwesenheitsnachweis

Das Primärsystem (PS) ruft die Operation für den Anwesenheitsnachweis am Konnektor auf. Das Modul PoPP des Konnektors liefert einen durch den PoPP-Dienst signierten Token, welcher belegt, dass die eGK im eHealth-Kartenterminal der LEI gesteckt ist.

Der Token beinhaltet u.a. die Information der KVNR der eGK, die Telematik-ID der Leistungserbringerinstitution und den Zeitpunkt der Erstellung des Token. Der Token ist durch den PoPP-Dienst signiert.

Der E-Rezept-Fachdienst prüft beim Abruf der E-Rezepte den Token. Es wird geprüft, dass die Signatur gültig ist, dass der Token innerhalb eines bestimmten Zeitfensters vor dem Aufruf der Operation erstellt wurde und dass die Telematik-ID im Token mit der Telematik-ID der aufrufenden Apotheke übereinstimmt. Wenn diese Prüfungen positiv ausfallen, dann werden im Response für den Aufruf die E-Rezepte zur KVNR aus dem Token zurückgeliefert.

3.2.3 Use Case im Rahmen der Belieferung in der Apotheke

Die Prozesse der abgebenden Leistungserbringerinstitution für das Abrufen, das Zurückweisen, das Löschen des E-Rezeptes, das Abrufen der Quittung und die Kommunikation mit dem Versicherten bleiben unverändert. Es wird für die Apotheke ein Prozess ergänzt, mit dem die Informationen für das Abrufen von E-Rezepten eines Versicherten (ein Liste von Task-IDs und zugehöriger AccessCodes) vom E-Rezept-Fachdienst ermittelt werden können, wenn der Versicherter seine eGK präsentiert. 

Für Krankenhausapotheken ist der Prozess nicht vorgesehen. 

3.2.3.1 E-Rezepte von Versicherten durch Abgebenden abrufen

AF_10078-01 - E-Rezepte eines Versicherten durch Abgebende abrufen

Alle am Anwendungsfall "E-Rezepte eines Versicherten durch Abgebende abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Name	E-Rezepte eines Versicherten durch Abgebenden abrufen
Vorbedingungen	Der Versicherte oder ein Vertreter befindet sich vor Ort in der Apotheke. Der Versicherte hat seine eGK bzw. der Vertreter die eGK des zu Vertretenden dabei.
Kurzbeschreibung (Außenansicht)	Der Versicherte oder ein Vertreter steckt die eGK in das eHealth-Kartenterminal. Das PS ruft für diese eGK den Anwendungsfall "Anwesenheitsnachweis" am Konnektor auf. Im Ergebnis erhält das PS, sofern die eGK nicht gesperrt und das Authentifizierungszertifikat gültig ist, einen Token. Das PS ruft mit dem Token alle E-Rezepte des Versicherten mit dem Status "offen" vom E-Rezept-Fachdienst ab. Der E-Rezept-Fachdienst übermittelt die Zugriffsinformationen (Task-ID und AccessCode) zu jedem E-Rezept mit dem Status "offen".
Nachbedingungen	Im PS stehen die Zugriffsinformationen (Task-ID und AccessCode) für alle einlösbaren E-Rezepte zur Verfügung. Im PS kann zu den einzelnen E-Rezepten der Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" ausführen, um die E-Rezepte im PS anzuzeigen. Der Zugriff der Apotheke auf die E-Rezepte ist für den Versicherten auf dem E-Rezept-Fachdienst protokolliert.

Abbildung 2 : E-Rezepte eines Versicherten durch Abgebenden abrufen

[<=]

3.3 Datenschutz und Informationssicherheit

Mit der Übergabe der eGK autorisiert der Versicherte den abgebenden Leistungserbringer zum Abruf aller seiner noch nicht eingelösten E-Rezepte. Sofern es mehrere E-Rezepte betrifft, klärt der abgebende LE im Gespräch mit dem Versicherten,  welche E-Rezepte eingelöst werden sollen. Im Vertreterfall übergibt der Versicherte seine eGK dem Vertreter (Autorisierung des Vertreters), damit dieser in einer Apotheke diese eGK einem abgebenden Leistungserbringer zum Abruf der E-Rezepte des Versicherten geben kann.

Der E-Rezept-Fachdienst liefert im Falle des Abrufs von E-Rezepten bei Stecken der eGK in einer abgebenden LEI nur E-Rezepte aus, wenn ihm ein gültiger PoPP-Token vorliegt. Der PoPP-Token resultiert aus der Durchführung des Anwendungsfalls "Anwesenheitsnachweis" am Konnektor und wird dem E-Rezept-Fachdienst vom Primärsystem geliefert. Das Primärsystem der abgebenden LEI muss die E-Rezept-Abfrage abbrechen, wenn der Anwendungsfall "Anwesenheitsnachweis" einen Fehler liefert.

Aufgrund der Beschaffenheit des PoPP-Token ist dieser nicht fälschbar und stellt für den E-Rezept-Fachdienst eine verlässliche Information über eine in einer LEI gesteckte eGK dar. Der PoPP-Token beinhaltet einen Zeitstempel des Ausstellungszeitpunkts anhand dessen der E-Rezept-Fachdienst entscheiden kann, ob der Token für ihn aktuell genug ist. Somit kann der Token nicht zu einem beliebigen Zeitpunkt von der LEI (wieder-)verwendet werden.

Der E-Rezept-Fachdienst protokolliert für den Versicherten, dass ein Abruf von E-Rezepten durch Vorliegen eines gültigen PoPP-Token durch eine abgebende LEI erfolgte. Um Problemfälle bzw. Missbrauchsversuche erkennbar zu machen, werden dabei auch fehlgeschlagene Abrufversuche protokolliert (z.B. Abrufversuche mit ungültigen PoPP-Token). Beim PoPP-Aufruf erfolgt keine Protokollierung im eGK-Protokoll.

Anmerkungen:

Wenn das AVS den Anwendungsfall abbricht, weil der Anwendungsfall "Anwesenheitsnachweis" am Konnektor einen Fehler liefert (z.B. wegen einer gesperrten eGK ), wird der E-Rezept-Fachdienst vom AVS nicht angefragt. Somit kann der E-Rezept-Fachdienst diese Situation nicht protokollieren.

Das Risiko, dass eine entwendete oder verlorene eGK dazu genutzt wird, unberechtigt E-Rezepte einzulösen, wird zugunsten einer barrierearmen Lösung (PIN-Eingabe ist nicht erforderlich) in Kauf genommen. Falls ein Versicherter seine eGK verliert, muss er dies bei seiner Krankenkasse melden, die daraufhin eine Sperrung der Karte vornimmt bzw. veranlasst. Bei der Durchführung des Anwendungsfalls "Anwesenheitsnachweis" am Konnektor wird die Gültigkeit der eGK geprüft und ein Abruf von E-Rezepten ist nur bei einer gültigen eGK möglich.

Wäre eine PIN-Eingabe erforderlich, würde zudem der Vertretungsfall (Versicherter übergibt Person seines Vertrauens seine eGK mit der Bitte, die E-Rezepte in der Apotheke einzulösen) in dieser Situation ausgeschlossen werden, da der Versicherte dem Vertreter unzulässigerweise seine PIN mitteilen müsste.

Das Verfahren erlaubt nicht, dass dem Apotheker nur eine Auswahl der einlösbaren E-Rezepten zur Kenntnis gelangt. Auch hierfür ist der Grund, die Lösung barrierearm zu gestalten.

Der PoPP-Token beinhaltet keine Aussage darüber, in welchem fachlichen Kontext der Token erzeugt wurde. Eine Verwendung eines PoPP-Token in mehreren fachlichen Anwendungsfällen (z.B. in verschiedenen Anwendungen) ist technisch nicht ausgeschlossen. Für die Anwendung E-Rezept entsteht hierdurch derzeit kein Risiko, da das Abrufen von E-Rezepten in abrufenden LEI der einzig mögliche E-Rezept-Anwendungsfall für die Übergabe der eGK vom Versicherten an einen Leistungserbringer darstellt.

Der PoPP-Dienst protokolliert nicht, wenn er aufgerufen wird. Dies verhindert eine Profilbildung im PoPP-Dienst über die aufrufenden Leistungserbringerinstitutionen. Damit ist aber auch keine Nachvollziehbarkeit von Aufrufen gegeben, d.h. LEI können sich nicht an den Dienst wenden, um für ihre Telematik-ID Informationen über erfolgte Aufrufe des PoPP-Dienstes zu erhalten. Das Anlegen einer Aufrufhistorie muss bei Bedarf durch das PS der abgebenden LEI erfolgen.

3.4 Spezifikation

Dieses Kapitel beschreibt die technische Umsetzung der beschriebenen Konzepte an die verschiedenen Produkt- und Anbietertypen. In den jeweiligen Produkt- und Anbietertypsteckbriefen sind zu den Anforderungen ("Blattanforderungen") die jeweiligen Prüfverfahren angegeben.

Dargestellt sind die zusätzlichen Anforderungen an die Produkttypen des E-Rezepts, die bestehende Anforderungslage für bereits eingeführte Anwendungsfälle bleibt hiervon unberührt.

3.4.1 Anforderungen an den E-Rezept-Fachdienst

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_FD_eRp] übernommen.

3.4.1.1 Protokollierung

3.4.1.2 Ressource Task

3.4.1.2.1 HTTP-Operation GET

Die Anforderungen zum Prüfen des PoPP-Token sind im Kapitel "HTTP-Operation GET - Prüfung PoPP-Token" beschrieben.

Diese Operation führt nicht zu einer Statusänderung bei den zurück gelieferten Task Ressourcen.

3.4.1.2.2 HTTP-Operation GET - Prüfung PoPP-Token

Wenn die Operation GET /Task durch eine Apotheke aufgerufen wird, um alle offenen E-Rezepte zu einer KVNR abzurufen, dann wird ein PoPP-Token und der zugehörige Pseudonymisierungsschlüssel übermittelt.

Die Struktur des PoPP-Token (JWS Compact Serialization [RFC-7515]) ist in A_23308-* (siehe [gemF_PoPP]) beschrieben.

Die im Token verwendeten Elemente sind in A_23372-* (siehe [gemF_PoPP]) beschrieben.

Der payload hat folgende Struktur:

{

"iat": 1666545075.211588,

"tid": "4:1:2234314343",

"used_challenge" : "1666552275:Wm1GR8T7wWRhc2jma54itA==",

"enc_egk_data": "...base64-kodiertes-Chiffrat ...",

"iss": "..."

}

Das Chiffrat enc_egk_data ist gemäß A_23313-* (siehe [gemF_PoPP])  verschlüsselt.

Der Pseudonymisierungsschlüssel pkey ist base64 kodiert. Nach dem Decodieren kann enc_egk_data mit dem Pseudonymisierungsschlüssel entschlüsselt werden.

Der Plaintext zu enc_egk_data hat folgende Struktur:

{

"egk_aut": "<eGK AUT>",

"egk_aut_status": "CERT_GOOD",

"egk_signature": "<Base64-kodierte Signatur>",

"egk_cvc": "<Base64-kodiertes CVC EE>",

"egk_cvc_ca": "<Base64-kodiertes CVC CA>"

}

Die Vorgaben zum Prüfen des Signaturzertifikates sind in A_23325-* und A_23257-* beschrieben.

Der E-Rezept-Fachdienst muss die eGK-Informationen enc_egk_data aus dem PoPP-Token extrahieren und mit dem AES/GCM Schlüssel pkey entschlüsseln. Der E-Rezept-Fachdienst erhält damit die obige JSON-Datenstruktur mit u.a. dem eGK-AUT-Zertifikat und dem eGK-AUT-Zertifikat-Sperrstatus.

Der Konnektor prüft bei der Erstellung des PoPP-Token die Gültigkeit des AUT-Zertifikats. Fällt die Prüfung negativ aus, weil bspw. das Zertifikat den Status REVOKED hat, dann wird kein PoPP-Token durch den Konnektor am PoPP-Dienst getriggert. Falls die Prüfung der Gültigkeit des AUT-Zertifikats aus technischen Gründen nicht möglich ist, wird dies im Token übermittelt. In dem Fall prüft der E-Rezept-Fachdienst den Onlinestatus.

Die Default-Konfiguration ist, dass die Warnung OCSP_CHECK_REVOCATION_FAILED zu einem negativen Ergebnis der Prüfung führt.

3.4.2 Anforderungen an das Primärsystem der abgebenden LEI

Die nachfolgenden Anforderungen werden in das Dokument [gemILF_PS_eRp] übernommen.

3.4.2.1 Kommunikation zu Diensten der TI

Die Tabelle TAB_ILFERP_014 wird wie folgt ergänzt:

Tabelle 2 : TAB_FdVERP_014 - HTTP-Header "X-erp-resource"

3.4.2.2 E-Rezepte von einem Versicherten abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die E-Rezept-Token Information zu allen E-Rezepten mit dem Status "offen" von einem Versicherten, dessen eGK in ein mit dem Konnektor gepairten E-Health-Kartenterminal gesteckt wurde, vom E-Rezept-Fachdienst abrufen.

Für weitere Informationen zur Operation PerformPoPP siehe [gemF_PoPP].

Der Response der Operation PerformPoPP beinhaltet einen Token und einen Schlüssel. Der Token und der Schlüssel werden der Response entnommen und in den Aufruf des E-Rezept-Fachdienstes übernommen. Der Token und der Schlüssel werden durch das AVS nicht ausgewertet.

Bsp.-URL: GET /Task?popp=q94mhx93b8ch...&pkey=Z2ZoZGZ...

Im Response ist eine Liste von Tasks enthalten. Für jeden Task sind u.a. folgende Informationen enthalten:

• Task-ID und
• AccessCode.

Auf Basis dieser Informationen können mittels des Anwendungsfalls "E-Rezept abrufen" (siehe [gemILF_PS_eRp]) die Verordnungsdatensätze zu den E-Rezepten vom E-Rezept-Fachdienst abgerufen werden. Erst dann sind die Inhalte der Verordnungen im AVS bekannt und können mit dem Versicherten abgestimmt werden.

Abgerufene Rezepte, welche nicht durch die Apotheke beliefert werden, müssen durch die Apotheke zurückgegeben (Anwendungsfall "E-Rezept durch Abgebenden zurückgeben") werden.

3.4.3 Anforderungen an das E-Rezept-FdV

Für das E-Rezept-FdV ergeben sich keine neuen funktionalen Anforderungen.

Da durch das Feature die Statusübergänge eines E-Rezepts unverändert sind, kann der Versicherte diese im E-Rezept-FdV sich wie gewohnt anzeigen lassen.

Das E-Rezept-FdV bietet dem Nutzer die Möglichkeit das Zugriffsprotokoll vom E-Rezept-Fachdienst anzeigen zu lassen. So kann der Versicherte die Protokolleinträge des Anwendungsfalls einsehen.

3.4.4 Daten- und Informationsmodell

Für das Feature gibt es keine Anpassung am Daten- oder Informationsmodell.

3.4.5 Betrieb

Die nachfolgenden Anforderungen werden an definierten Stellen in [gemSpec_Perf] und [gemKPT_Betr] übernommen. 

3.4.5.1 Verfügbarkeit

Für die Hinzunahme der Funktionalität des Abrufs von E-Rezepten in der Apotheke mit der eGK des Versicherten existieren keine abweichenden Anforderungen an die Verfügbarkeit des E-Rezept-Fachdienstes. Es gelten weiterhin die bereits existierenden Anforderungen an den E-Rezept-Fachdienst.

3.4.5.2 Last und Antwortzeiten

Aktuelle Schätzungen gehen davon aus, dass kurzfristig ca. 40 % und langfristig ca. 70 % der ausgestellten E-Rezepte durch den direkten Abruf mit der eGK in der Apotheke dispensiert werden könnten. In 2018 durchgeführte Erhebungen kamen zu einem geschätzten Aufkommen von 3.501.000 ausgestellten Rezeptzeilen am Tag mit dem höchsten Aufkommen (Montag, 17.12.2018). Basierend auf dieser Grundannahme, wird im Kontext dieses Dokumentes ein Mengengerüst von 4 Millionen Rezeptzeilen angenommen. Zusätzlich wird mit einem Faktor von 1,7 dispensierten Rezeptzeilen pro Apothekenbesuch eines Versicherten gerechnet.

E-Rezept-Fachdienst

Für die Hinzunahme der Funktionalität des Abrufs von E-Rezepten in der Apotheke mit der eGK des Versicherten wird eine zusätzliche Last durch den notwendigen Abruf der Liste der E-Rezepte (GET /Task?popp=) erzeugt. Basierend auf der oben getroffenen 70 % Annahme der Nutzung des neuen Anwendungsfalles, ergibt sich die folgende zusätzliche Spitzenlast in der Anforderung A_20165-04 mit der Aufnahme einer weiteren Zeile.

Die folgenden Ergänzungen bzw. Änderungen werden an [gemSpec_Perf#Tab_gemSpec_Perf_eRp-Fachdienst: Last- und Bearbeitungszeitvorgaben] in der Anforderung A_20165-04 vorgenommen:

Die folgenden Ergänzungen werden an [gemSpec_Perf#Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall] vorgenommen:

3.4.5.3 Bereitstellung von Betriebsdaten

Die folgenden Ergänzungen werden an [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst] vorgenommen:

3.4.5.4 Performance-Kennzahlen

Die folgenden Ergänzungen werden an [gemKPT_Betr#Tab_gemKPT_Betr_UC_Anwendungsfallübersicht] vorgenommen.

4 Anwesenheitsbeleg mittels strukturiertem VSDM Prüfungsnachweis

4.1 Einordnung in die Telematikinfrastruktur

Das Feature zum Abruf der E-Rezepte in der Apotheke nach Autorisierung setzt auf die bestehende Infrastruktur der Anwendungen E-Rezept und Versichertenstammdatenmanagement (VSDM) sowie die bestehende Anbindung der Apotheken an die Telematikinfrastruktur (TI) auf.

Der Versicherte nutzt die eGK als personenbezogenem Identitätsnachweis. Dabei ist der Versicherte nicht notwendigerweise selbst mit seiner eGK in der Apotheke anwesend, sondern ggf. ein Vertreter, den er durch Übergabe der Karte  autorisiert hat, seine E-Rezepte einzulösen.

Abbildung 3 : Übersicht E-Rezept-Komponenten (VSDM)

4.2 Technisches Konzept

4.2.1 Autorisierung mittels eGK

Beim Abruf der E-Rezepte in einer Apotheke nach Autorisierung wird die eGK des Versicherten als Mittel für die Autorisierung verwendet. Andere Mittel für die Autorisierung als die eGK werden nicht unterstützt.

Das Primärsystem (PS) liest die Versichertenstammdaten (VSD) der eGK mittels der Operation ReadVSD des Konnektors. Im Rahmen dieser Operation wird geprüft, ob die eGK nicht gesperrt und das Authentisierungszertifikat auf der eGK gültig ist.

Der Versicherte ist angehalten, bei Verlust seiner eGK, dieses bei seiner Krankenkasse anzuzeigen, damit die Krankenkasse die eGK sperren kann. Die Prozesse zum Sperren der eGK liegen in der Verantwortung der Krankenkassen. Für Anforderungen an den Sperrprozess siehe  .

4.2.2 Standardablauf

Voraussetzung: Es existiert ein geteiltes Geheimnis (kryptographischer Schlüssel) zwischen Fachdienst VSDM und dem E-Rezept-Fachdienst, welches für ein Hashverfahren (SHA-256) genutzt wird. Dieses Geheimnis ist Fachdienst VSDM betreiberspezifisch.

1. Der Versicherte übergibt dem Apotheker seine eGK und autorisiert diesen damit für den Abruf der E-Rezepte des Versicherten.
2. Die eGK wird in der Apotheke in das eHealth-Kartenterminal gesteckt bzw. bei Nutzung der NFC Schnittstelle gehalten.
3. Das Apothekenverwaltungssystem (AVS) ruft die Operation ReadVSD am Konnektor mit den Parametern PerformOnlineCheck=true und ReadOnlineReceipt=true auf.
4. Das Fachmodul VSDM führt die Onlineprüfung und ggf. -aktualisierung durch.
5. Der Fachdienst VSDM (UFS oder VSDD) verwendet als fachliche Information für die Prüfziffer u.a. die KVNR und den aktuellen Zeitpunkt als Zeitstempel. Es wird mit dem betreiberspezifischen Geheimnis ein Hashwert über die fachlichen Informationen gebildet. Die fachliche Information bilden zusammen mit dem Hashwert die Prüfziffer.
6. Das Fachmodul VSDM erstellt den Prüfungsnachweis und fügt die vom Fachdienst VSDM erhaltene Prüfziffer ein.
7. Das Fachmodul VSDM liefert im Response die Versichertenstammdaten und den Prüfungsnachweis an das AVS.
8. Das AVS ruft den E-Rezept-Fachdienst auf und übermittelt den Prüfungsnachweis.
9. Der E-Rezept-Fachdienst verifiziert die Prüfziffer indem der Hashwert über die fachlichen Informationen der Prüfziffer mit dem bekannten Geheimnis gebildet und mit dem übermittelten Hashwert verglichen wird. Bei Übereinstimmung wird die Prüfziffer als authentisch betrachtet.
10. Der E-Rezept-Fachdienst verifiziert, ob der in der Prüfziffer enthaltene Zeitstempel in einem definierten Zeitfenster zum aktuellen Zeitpunkt liegt.
11. Der E-Rezept-Fachdienst übermittelt die einlösbaren E-Rezepte zur in der Prüfziffer übermittelten KVNR an das AVS.

4.2.3 Use Case im Rahmen der Belieferung in der Apotheke

Die Prozesse der abgebenden Leistungserbringerinstitution für das Abrufen, das Zurückweisen, das Löschen des E-Rezeptes, das Abrufen der Quittung und die Kommunikation mit dem Versicherten bleiben unverändert. Es wird für die Apotheke ein Prozess ergänzt, mit dem die Informationen für das Abrufen von E-Rezepten eines Versicherten (ein Liste von Task-IDs und zugehöriger AccessCodes) vom E-Rezept-Fachdienst ermittelt werden können, wenn die eGK eines Versicherten präsentiert wird. 

Für Krankenhausapotheken ist der Prozess nicht vorgesehen. 

4.2.3.1 E-Rezepte von Versicherten durch Abgebenden abrufen

AF_10129 - E-Rezepte eines Versicherten durch Abgebende abrufen (VSDM)

Alle am Anwendungsfall "E-Rezepte eines Versicherten durch Abgebende abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Name	E-Rezepte eines Versicherten durch Abgebenden abrufen (VSDM)
Vorbedingungen	Der Versicherte oder ein Vertreter befindet sich vor Ort in der Apotheke. Der Versicherte hat seine eGK bzw. der Vertreter die eGK des zu Vertretenden dabei.
Kurzbeschreibung (Außenansicht)	Der Versicherte oder ein Vertreter steckt die eGK in das eHealth-Kartenterminal. Das PS ruft für diese eGK den Anwendungsfall "VSD von der eGK lesen" mit den Optionen "Onlineprüfung durchführen" und "Prüfungsnachweis lesen" am Konnektor auf. Im Ergebnis erhält das PS, sofern die eGK nicht gesperrt und das Authentifizierungszertifikat gültig ist, den Versichertenstammdatensatz (PD, VD und GVD) und den Prüfungsnachweis. Das Fachmodul VSDM protokolliert das Lesen der GVD auf der eGK. Das PS ruft mit dem Prüfungsnachweis alle E-Rezepte des Versicherten mit dem Status "offen" vom E-Rezept-Fachdienst ab. Es werden die Zugriffsinformationen (Task-ID und AccessCode) zu jedem E-Rezept übermittelt.
Nachbedingungen	Im PS stehen die Zugriffsinformationen (Task-ID und AccessCode) für alle einlösbaren E-Rezepte zur Verfügung. Im PS kann zu den einzelnen E-Rezepten der Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" ausführen, um die E-Rezepte im PS anzuzeigen. Der Zugriff auf den E-Rezept-Fachdienst ist für den Versicherten protokolliert. Der Besuch in der Apotheke ist auf der eGK protokolliert.

Abbildung 4 : E-Rezepte eines Versicherten durch Abgebenden abrufen (VSDM)

[<=]

4.3 Datenschutz und Informationssicherheit

Die Interaktion zwischen Versicherten und Apotheker unterscheidet sich beim Lösungsansatz „Anwesenheitsbeleg mittels strukturiertem Prüfungsnachweis“ nicht vom Lösungsansatz „Anwesenheitsbeleg mittels PoPP-Dienst“:

Mit der Übergabe der eGK autorisiert der Versicherte den abgebenden Leistungserbringer zum Abruf aller seiner noch nicht eingelösten E-Rezepte. Sofern es mehrere E-Rezepte betrifft, klärt der abgebende LE im Gespräch mit dem Versicherten, welche E-Rezepte eingelöst werden sollen. Im Vertreterfall übergibt der Versicherte seine eGK dem Vertreter (Autorisierung des Vertreters), damit dieser in einer Apotheke diese eGK einem abgebenden Leistungserbringer zum Abruf der E-Rezepte des Versicherten geben kann.

Im Unterschied zum Lösungsansatz „Anwesenheitsbeleg mittels PoPP-Dienst“ erhält der E-Rezept-Fachdienst bei diesem Lösungsansatz als Nachweis, dass die eGK in der LEI gesteckt ist, keinen PoPP-Token, sondern einen Prüfungsnachweis, der aus der Durchführung des VSDM-Anwendungsfalls ReadVSD im Konnektor resultiert und der eine kryptografisch gesicherte Prüfziffer enthält. Dabei erfolgt die kryptographische Absicherung durch den jeweilig beteiligten Fachdienst VSDM. Dadurch ist die Prüfziffer nicht fälschbar und stellt für den E-Rezept-Fachdienst ebenfalls (wie auch ein PoPP-Token) eine verlässliche Information über eine gesteckte eGK dar.

Durch den in der Prüfziffer enthaltenen Zeitstempel ist es dem E-Rezept-Fachdienst möglich, die Verwendung des Prüfnachweises auf einen bestimmten Zeitraum einzugrenzen, so dass Replay-Angriffe außerhalb dieses Zeitraums nicht möglich sind. Der Zeitraum wird so gewählt, dass er die Dauer des Versorgungsvorgangs in der Apotheke plausibel abdeckt.

Der E-Rezept-Fachdienst protokolliert für den Versicherten, dass ein Abruf von E-Rezepten durch Vorliegen eines gültigen Prüfungsnachweises durch eine abgebende LEI erfolgte. Um Problemfälle bzw. Missbrauchsversuche erkennbar zu machen, werden dabei auch fehlgeschlagene Abrufversuche protokolliert (z.B. Abrufversuche mit ungültigen Prüfungsnachweis). Der Konnektor protokolliert den Zugriff auf die eGK im Kontext des ReadVSD-Aufrufs in der eGK.

Die kryptografische Absicherung der Integrität der Prüfziffer erfolgt durch einen Hash-Wert mit geeigneter Qualität. Dieser Hash-Wert wird von den jeweiligen Fachdienstbetreiber VSDM sicher erzeugt und verwaltet. Da er zur Prüfung der Integrität der Prüfziffer auch in der VAU des E-Rezept-Fachdienstes bekannt sein muss, wird der Hash-Wert mit dem öffentlichen Schlüssel der VAU-Verschlüsselungszertifikats verschlüsselt und in dieser Form an die gematik übergeben, die ihn wiederum dem E-Rezept-Fachdienstbetreiber (IBM) zur Verfügung stellt. Beim E-Rezept-Fachdienstbetreiber ist der Hash-Wert nur in der VAU im Klartet verfügbar, also der IBM nicht bekannt.

Anmerkungen:

Wenn das AVS den Anwendungsfall abbricht, weil ReadVSD einen Fehler liefert (z.B. wegen einer gesperrten eGK), wird der E-Rezept-Fachdienst vom AVS nicht angefragt. Somit kann der E-Rezept-Fachdienst diese Situation nicht protokollieren.

Das Risiko, dass eine entwendete oder verlorene eGK dazu genutzt wird, unberechtigt E-Rezepte einzulösen wird zugunsten einer barrierearmen Lösung (PIN-Eingabe ist nicht erforderlich) in Kauf genommen. Falls ein Versicherter seine eGK verliert, muss er dies bei seiner Krankenkasse melden, die daraufhin eine Sperrung der Karte vornimmt bzw. veranlasst. Bei der Durchführung von ReadVSD wird die Gültigkeit der eGK geprüft und ein Abruf von E-Rezepten ist nur bei einer gültigen eGK möglich.

Wäre eine PIN-Eingabe erforderlich, würde zudem der Vertretungsfall (Versicherter übergibt Person seines Vertrauens seine eGK mit der Bitte die E-Rezepte in der Apotheke einzulösen) in dieser Situation ausgeschlossen werden, da der Versicherte dem Vertreter unzulässiger Weise seine PIN mitteilen müsste.

Das Verfahren erlaubt nicht, dass dem Apotheker nur eine Auswahl der einlösbaren E-Rezepten zur Kenntnis gelangt. Auch hierfür ist der Grund, die Lösung barrierearm zu gestalten.

Der Prüfungsnachweis beinhaltet keine Aussage darüber, in welchem fachlichen Kontext der Aufruf von ReadVSD erfolgte. Eine Verwendung eines Prüfungsnachweises in mehreren fachlichen Anwendungsfällen (z.B. in verschiedenen Anwendungen) ist technisch nicht ausgeschlossen. Für die Anwendung E-Rezept entsteht hierdurch derzeit kein Risiko, da das Abrufen von E-Rezepten in abrufenden LEI der einzig mögliche E-Rezept-Anwendungsfall für die Übergabe der eGK vom Versicherten an einen Leistungserbringer darstellt.

Der Aufruf der Fachdienste VSDM durch den Konnektor erfolgt mittels eines zwischengeschalteten Intermediärs. Somit können die Fachdienste VSDM keinen Zusammenhang zwischen Aufruf und aufrufender LEI herstellen. Das damit einhergehende Risiko, dass die LEI in der die eGK steckt, nicht die LEI ist, die die Abfrage nach E-Rezepten anstößt, wird als akzeptabel angesehen. Im E-Rezept-Protokoll für den Versicherten wird die tatsächlich abfragende LEI vermerkt. Damit ist dieser Fall unter Nutzung des Protokolls für Versicherte erkennbar.

4.4 Spezifikation

Dieses Kapitel beschreibt die technische Umsetzung der beschriebenen Konzepte an die verschiedenen Produkt- und Anbietertypen. In den jeweiligen Produkt- und Anbietertypsteckbriefen sind zu den Anforderungen ("Blattanforderungen") die jeweiligen Prüfverfahren angegeben.

Dargestellt sind die zusätzlichen Anforderungen an die Produkttypen des E-Rezepts, die bestehende Anforderungslage für bereits eingeführte Anwendungsfälle bleibt hiervon unberührt.

4.4.1 Anforderungen an den E-Rezept-Fachdienst

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_FD_eRp] übernommen.

4.4.1.1 Protokollierung

A_19284-* gemäß 3.4.1.1 Protokollierung  

4.4.1.2 Ressource Task

4.4.1.2.1 HTTP-Operation GET

A_21558-01 gemäß 3.4.1.2.1 HTTP-Operation GET 

Eine mögliche Änderung der Konfiguration für den Zeitraum der Gültigkeit des Prüfungsnachweises erfolgt ausschließlich nach Anpassung von A_23451-* im Rahmen des Änderungsmanagement für Spezifikationen. 

Diese Operation führt nicht zu einer Statusänderung bei den zurück gelieferten Task Ressourcen.

4.4.1.2.2 HTTP-Operation GET - Prüfung VSDM Prüfungsnachweis

Der VSDM Prüfungsnachweis wird URL-codiert übertragen.

Das Informationsmodel des VSDM Prüfungsnachweises ist in [gemSysL_VSDM] beschrieben.

Die Struktur der VSDM Prüfziffer ist in A_23453-* (siehe Änderungseintrag C_11321) beschrieben.

Tabelle 4 : Struktur VSDM Prüfziffer

Der Vergleich für die Ermittlung des HMAC-Schlüssel (2.a.) erfolgt case-sensitive.

Der E-Rezept-Fachdienst verwaltet HMAC-Schlüssel, welche durch die Betreiber der Fachdienste VSDM bereitgestellt werden. Ein HMAC-Schlüssel wird durch die Kennung des Betreibers des Fachdienstes VSDM und der Version des Schlüssels identifiziert.

Die Ausgabelänge der SHA-256 Hashfunktion ist 32 Byte lang. Für die Prüfziffer werden die ersten 24 Byte verwendet. Die restlichen Bytes werden verworfen.

4.4.1.3 Management VSDM HMAC-Schlüssel

Der Anbieter des E-Rezept-Fachdienstes erhält das Exportpaket eines Betreiber eines Fachdienstes VSDM über das TI-ITSM-System. Zur Struktur des Export-Paket siehe A_23466-*.

Der Anbieter des E-Rezept-Fachdienstes darf das Exportpaket erst in die VAU einbringen, nachdem "empty_string_hmac" und die Betreiberkennung aus dem Export-Paket mit den Informationen, die die gematik vom Betreiber des Fachdienstes VSDM erhalten hat, abgeglichen wurden.

Die VAU des E-Rezept-Fachdienstes setzt die Gültigkeitszeiten nicht technisch durch. Stattdessen erfolgt das Entfernen von alten Schlüsseln (alten Version) manuell.

Aus Gründen der Dokumentation und der Nachvollziehbarkeit führt der Anbieter des E-Rezept-Fachdienstes eine Liste von importierten Schlüsseln.

Die Schnittstelle wird nicht im Internet oder im zentralen Netz der TI bereitgestellt.

4.4.2 Anforderungen an das Primärsystem der abgebenden LEI

4.4.2.1 Kommunikation zu Diensten der TI

gemäß 3.4.2.1 Kommunikation zu Diensten der TI 

4.4.2.2 E-Rezepte von einem Versicherten abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die E-Rezept-Token Information zu allen E-Rezepten mit dem Status "offen" von einem Versicherten, dessen eGK in ein mit dem Konnektor gepairten E-Health-Kartenterminal gesteckt wurde, vom E-Rezept-Fachdienst abrufen.

Der Parameter PerformOnlineCheck gibt an, dass eine Onlineprüfung und -aktualisierung durchgeführt werden soll. Der Parameter ReadOnlineReceipt gibt an, dass ein Prüfungsnachweis erstellt und an den aufrufenden Client übermittelt werden soll.

Der Response beinhaltet die Elemente PersoenlicheVersichertendaten, AllgemeineVersicherungsdaten, GeschuetzteVersichertendaten und Pruefungsnachweis. Deren Inhalte sind komprimiert sowie base64-kodiert und müssen vor dem Parsen entsprechend dekodiert werden.

Für weitere Informationen zur Operation ReadVSD siehe [gemILF_PS].

Der Prüfungsnachweis wird aus dem ReadVSD Response entnommen, URL-kodiert und in den Aufruf des E-Rezept-Fachdienstes übernommen.

Bsp.-URL: GET /Task?pnw=q94mhx93b8ch... 

Im Response ist eine Liste von Tasks enthalten. Für jeden Task sind u.a. folgende Informationen enthalten:

• Task-ID und
• AccessCode.

Auf Basis dieser Informationen können die Verordnungsdatensätze zu den E-Rezepten vom E-Rezept-Fachdienst abgerufen werden. Erst dann sind die Inhalte der Verordnungen im AVS bekannt und können mit dem Versicherten abgestimmt werden.

Abgerufene Rezepte, welche nicht durch die Apotheke beliefert werden, müssen durch die Apotheke zurückgegeben (Anwendungsfall "E-Rezept durch Abgebenden zurückgeben") werden.

A_23152 gemäß 3.4.2.2 E-Rezepte von einem Versicherten abrufen 

4.4.3 Anforderungen an das E-Rezept-FdV

Für das E-Rezept-FdV ergeben sich keine neuen funktionalen Anforderungen.

Da durch das Feature die Statusübergänge eines E-Rezepts unverändert sind, kann der Versicherte diese im E-Rezept-FdV sich wie gewohnt anzeigen lassen.

Das E-Rezept-FdV bietet dem Nutzer die Möglichkeit das Zugriffsprotokoll vom E-Rezept-Fachdienst anzeigen zu lassen. So kann der Versicherte die Protokolleinträge des Anwendungsfalls einsehen.

4.4.4 Daten- und Informationsmodell

Für das Feature gibt es keine Anpassung am Daten- oder Informationsmodell.

4.4.5 Betrieb

Die nachfolgenden Anforderungen werden an definierten Stellen in [gemSpec_Perf] und [gemKPT_Betr] übernommen. 

4.4.5.1 Verfügbarkeit

Für die Hinzunahme der Funktionalität des Abrufs von E-Rezepten in der Apotheke mit der eGK des Versicherten existieren keine abweichenden Anforderungen an die Verfügbarkeit des E-Rezept-Fachdienstes. Es gelten weiterhin die bereits existierenden Anforderungen an den E-Rezept-Fachdienst.

4.4.5.2 Last und Antwortzeiten

Aktuelle Schätzungen gehen davon aus, dass kurzfristig ca. 40 % und langfristig ca. 70 % der ausgestellten E-Rezepte durch den direkten Abruf mit der eGK in der Apotheke dispensiert werden. In 2018 durchgeführte Erhebungen kamen zu einem geschätzten Aufkommen von 3.501.000 ausgestellten Rezeptzeilen am Tag mit dem höchsten Aufkommen (Montag, 17.12.2018). Basierend auf dieser Grundannahme, wird im Kontext dieses Dokumentes ein Mengengerüst von 4 Millionen Rezeptzeilen angenommen. Zusätzlich wird mit einem Faktor von 1,7 dispensierten Rezeptzeilen pro Apothekenbesuch eines Versicherten gerechnet.

E-Rezept-Fachdienst

Für die Hinzunahme der Funktionalität des Abrufs von E-Rezepten in der Apotheke mit der eGK des Versicherten wird eine zusätzliche Last durch den notwendigen Abruf der Liste der E-Rezepte (GET /Task(PNW)) erzeugt. Basierend auf der oben getroffenen 90 % Annahme der Nutzung des neuen Anwendungsfalles, ergibt sich die folgende zusätzliche Spitzenlast in der Anforderung A_20165-04 mit der Aufnahme einer weiteren Zeile.

Die folgenden Ergänzungen bzw. Änderungen werden an [gemSpec_Perf#Tab_gemSpec_Perf_eRp-Fachdienst: Last- und Bearbeitungszeitvorgaben] in der Anforderung A_20165-05 vorgenommen:

Die folgenden Ergänzungen werden an [gemSpec_Perf#Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall] vorgenommen:

4.4.5.3 Bereitstellung von Betriebsdaten

Die folgenden Ergänzungen werden an [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst] vorgenommen:

5 Dokumentenhaushalt

In diesem Abschnitt werden die Auswirkungen auf den Dokumentenhaushalt des E-Rezepts dargestellt.

5.1 Übersicht betroffener Dokumente

Dieses Dokument beschreibt das Feature als geschlossene funktionale Einheit. Mit der Freigabe zur Umsetzung werden die hier getroffenen Festlegungen in einem nachgelagerten Wartungsrelease in die jeweiligen Produkt- und Anbietertypspezifikationen überführt.

5.2 Übersicht Produkt- und Anbietertypen

Die hier aufgelisteten Anforderungen richten sich an die Produkt- und Anbietertypen:

• E-Rezept-Fachdienst
• Primärsystem der abgebenden LEI

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Referenzierte Dokumente

6.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

6.2.2 Weitere Dokumente