Elektronische Gesundheitskarte und Telematikinfrastruktur




Feature:

Abruf der E-Rezepte in der Apotheke nach Autorisierung




Version2.0.0_CC
Revision1450380
Stand05.12.2025
Statuszur Abstimmung freigegeben
Klassifizierungöffentlich_Entwurf
ReferenzierunggemF_eRp_Autorisierung_Apo


Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes 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 29.08.2022 freigegeben gematik
1.0.1 01.09.2022 Korrektur in A_22431: Task.status="ready"
A_23182 für URL-Kodierung des Prüfungsnachweises hinzugefügt		 gematik
1.1.0 14.02.2022 Erweiterung um
- Proof of Patient Presence (Arbeitsstand)
- Anwesenheitsbeleg mittels strukturiertem VSDM
  Prüfungsnachweis (Arbeitstitel VSDM++) (freigegeben)		 gematik
1.1.1 15.02.2023 Korrektur in A_23449: Kleinschreibung URL-Parameter pnw,
Korrektur Beispiel unterhalb A_23449		 gematik
2.0.0_CC 05.12.2025 Überarbeitung der Nutzung "Nachweis Versorgungskontexts mittels PoPP"
Rückbau der Spezifikation zu "Anwesenheitsbeleg mittels strukturiertem VSDM-Prüfungsnachweis"		 gematik

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

In der Version 1.1.1 dieses Dokumentes wurden zwei Lösungsansätze beschrieben:

Mit dieser Version wird die Konzeption und Spezifikation für den Lösungsansatz unter Nutzung der PoPP-Lösung überarbeitet. 

Die Umsetzung des Lösungsansatzes "Anwesenheitsbeleg mittels strukturiertem VSDM Prüfungsnachweis" wird abgekündigt.

Die Einführung der PoPP-Lösung erfolgt stufenweise. Das Dokument beschreibt die Nutzungsszenarien der Stufe 1 (PoPP-Token bei physischer Anwesenheit in und ausserhalb der LEI - eGK). Es wird um die PoPP Anwendungsfälle der Stufe 2 (u.a. PoPP-Token ohne physische Anwesenheit in der LEI - eGK (mobil) als Ersatz für die "Cardlink" Lösung) erweitert, wenn die Spezifikation zur PoPP-Lösung Stufe 2 veröffentlicht wurde.

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:

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.

Vertreter

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 den Leistungserbringer zu autorisieren, die offenen Rezepte abzurufen. Der Versicherte teilt dem Vertreter nicht seine PIN für die eGK mit. 

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 bei ihrer Wunsch-Apotheke eingelöst werden können. Neben dem Patientenausdruck und dem Frontend des Versicherten soll auch langfristig die Gesundheitskarte in verschiedenen Versorgungsszenarien für die Einlösung - komfortabel und ohne PIN Eingabe - genutzt werden können (§ 312, Abs. 1, Nr. 6 SGB V). Die Nutzung der eGK zur Autorisierung einer Apotheke auf Basis von VSDM++ wird durch die Abschaltung der Dienste von VSDM 1.0 nicht mehr möglich sein. Mit diesem Feature auf Basis der PoPP-Lösung soll sichergestellt werden, dass dieser beliebte Einlöseweg (ca. 90% Nutzungsquote) auch weiterhin ermöglicht wird.

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 verstehen, dass meine Apotheke in dem Fall, dass ich die eGK übergebe, alle meine einlösbaren Rezepte lesen kann, so dass ich eine informierte Entscheidung treffen kann, ob das für mich passt. 

Als Patient möchte ich jederzeit die Wahl haben, welches Verfahren zur Einlösung (eGK, Patientenausdruck, E-Rezept-FdV) ich nutzen möchte, so dass ich volle Flexibilität habe.

Als Patient möchte ich, dass das Einlösen mittels eGK für einen Vertreter mittels Übergabe meiner eGK genauso einfach ist wie das Einlösen von eigenen Rezepten ist, so dass es mir leichter fällt, jemandem zu bitten, für mich meine Rezepte einzulösen. 

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, dass immer nur meine gültige eGK (aktuelle Karte und Folgekarte) die Apotheke berechtigen kann, auf meine Rezepte zuzugreifen. 

Als Patient möchte ich in meinem FdV nachvollziehen können, wann welche Apotheke E-Rezepte nach Berechtigung mittels eGK abgerufen hat.

Als Patient möchte ich in der Apotheke meine eGK in den Kartenleser stecken, so dass meine Apotheke meine einlösbaren Rezept einsehen kann und ich nicht auf den Papierausdruck oder das FdV angewiesen bin.

Als Patient möchte ich außerhalb der Leistungserbringerinstitution (z.B. im Pflegeheim) meine eGK an das mobile Lesegerät der Apotheke halten können, so dass sie meine einlösbaren Rezept einsehen 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 wie das Einlösen eigener Rezepte ist, 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 Apotheken

Als Apotheke möchte ich innerhalb meiner Institution von meinen Patienten mithilfe der eGK Zugang zu ihren einlösbaren Rezepten erhalten können, so dass ich meine Kunden in allen Versorgungsszenarien gut versorgen kann.

Als Apotheke möchte ich außerhalb meiner Räumlichkeiten z.B. bei Heimbesuchen von meinen Patienten mithilfe der eGK Zugang zu ihren einlösbaren Rezepten erhalten können, so dass ich meine Kunden in allen Versorgungsszenarien gut versorgen kann.

Als Apotheke möchte ich die eGK meines Patienten nur einmal stecken, um auf die einlösbaren E-Rezepte zuzugreifen und einen Zugang zur elektronische Patientenakte (ePA) zu erhalten (sofern vorhanden und ich berechtigt bin).

Als Apotheke 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 FdV oder Ausdruck vorzeigt, so dass meine Patienten und ich nicht lange warten müssen.

Als Apotheke möchte ich nach dem Stecken der eGK alle einlösbaren Rezepte meines Kunden sehen und dann entscheiden, welche ich davon beliefern kann.

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

3 Nachweis Versorgungskontexts mittels PoPP

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 sowie die Komponenten der PoPP-Lösung (Proof of Patient Presence).

Abbildung 1: Übersicht E-Rezept-Komponenten

Der PoPP-Service ist ein TI-Plattformdienst, welcher die Bestätigung eines Versorgungskontexts in Form eines kryptografisch gesicherten PoPP-Token erzeugt. Dieses Token bestätigt, dass ein bestimmter Versicherter mit einer bestimmten Leistungserbringerinstitution (LEI) zusammengekommen ist. Der PoPP-Service ist der Serveranteil der PoPP-Lösung.

Der PoPP-Client ist Teil des Primärsystems und übernimmt die Kommunikation mit dem PoPP-Service. Er ist verantwortlich für das Anfordern und Empfangen von PoPP-Token. Die Kommunikation zwischen PoPP-Client und PoPP-Service basiert auf dem Zero Trust Sicherheitskonzept.

3.2 Technisches Konzept

3.2.1 Proof of Patient Presence

Proof of Patient Presence (PoPP) ist ein Nachweis, der belegt, dass sich ein Versicherter zu einem bestimmten Zeitpunkt in einem Versorgungskontext mit einer bestimmten Leistungserbringerinstitution (LEI) befindet. Im kryptografisch gesicherten PoPP-Token sind somit Informationen über die LEI und über den Versicherten zusammengeführt. Dabei ist es die Aufgabe der PoPP-Lösung, die Authentifizierung der LEI durchzuführen und durch Authentifizierung des Versicherten per GesundheitsID oder Authentifizierung der elektronischen Gesundheitskarte (eGK) eines Versicherten den Versorgungskontext zu bestätigen. Das Ergebnis ist das PoPP-Token, welches der LEI zur Autorisierung für den Zugriff auf die Daten des Versicherten in Diensten der Telematikinfrastruktur (TI) dient. [gemSpec_PoPP_Service]

3.2.1.1 PoPP Anwendungsfälle

Für PoPP wurden verschiedene Anwendungsfälle spezifiziert. Bei den Anwendungsfällen wird seitens der Versicherten die Verwendung der eGK oder der GesundheitsID unterschieden. Seitens der LEI wird unterschieden, ob der Versorgungskontext entsteht während Versicherter und LEI physisch gemeinsam anwesend sind (Praxisbesuch, Hausbesuch), oder ob die LEI virtuell anwesend ist, wie bspw. bei einer Videosprechstunde.
Für eine Auflistung der Anwendungsfälle und deren Beschreibung siehe [gemF_PoPP_stat_QRCode].

Die Bereitstellung der PoPP-Lösung erfolgt stufenweise. [gemSpec_PoPP_Service]

Der PoPP-Service Stufe 1 beinhaltet die Erstellung von PoPP-Token mittels einer eGK in Versorgungsszenarien bei dem Leistungserbringer und Versicherte an einem Ort physisch zusammentreffen. Dies entspricht den Use Cases UC_PoPP_1a und UC_PoPP_2a.

Der PoPP-Service Stufe 2 beinhaltet zusätzlich die Erstellung von PoPP-Token in Versorgungsszenarien, bei denen von Versichertenseite die GesundheitsID verwendet wird sowie Versorgungsszenarien mit der eGK in der Fernversorgung (Ersatz für "Cardlink").

Dieses Konzept betrachtet die Anwendungsfälle der Stufe 1.

UC_PoPP_1a - PoPP-Token bei physischer Anwesenheit in der LEI - eGK

Ein Versicherter möchte eine Versorgung in einer LEI in Anspruch nehmen. Die LEI benötigt für den Zugriff auf die Daten des physisch anwesenden Versicherten einen Nachweis des Versorgungskontexts. Dazu wird die eGK des Versicherten an einem geeigneten Lesegerät der LEI präsentiert. Nachdem der Versicherte den Check-in-Prozess mit der eGK durchgeführt hat, ist dieser abgeschlossen und die LEI erhält im PS den notwendigen Nachweis des Versorgungskontexts. 

UC_PoPP_2a - PoPP-Token bei physischer Anwesenheit außerhalb der LEI - eGK

Ein Versicherter möchte eine Versorgung außerhalb einer LEI in Anspruch nehmen. Dazu kommt das Personal der LEI zum Versicherten. Die LEI benötigt für den Zugriff auf die Daten des physisch anwesenden Versicherten einen Nachweis des Versorgungskontexts. Dazu wird die eGK des Versicherten an einem geeigneten mobilen Lesegerät der LEI präsentiert. Nachdem das LEI-Personal die eGK eingelesen hat, ist der Check-in-Vorgang abgeschlossen und die LEI erhält im PS den notwendigen Nachweis des Versorgungskontexts. 

Das Konzept wird um die PoPP Anwendungsfälle der Stufe 2 erweitert, wenn die Spezifikation zu Stufe 2 veröffentlicht wurde.

3.2.2 Anwesenheitsnachweis

Die eGK des Versicherten wird in ein eHealth-Kartenterminal oder Standard-Kartenleser gesteckt. Das Primärsystem initiiert über den PoPP-Client die Kommunikation mit dem PoPP-Service. Dafür authentisiert der ZETA Client das Primärsystem gegenüber dem PoPP-Service. Nach erfolgreicher Authentifizierung und Prüfung wird vom PoPP-Service ein PoPP-Token erstellt und an den PoPP-Client übermittelt. Der PoPP-Token wird vom PoPP-Client zur weiteren Verwendung innerhalb des Primärsystems übergeben. [spec-ilf-popp-client#Systemüberblick]

Der PoPP-Token belegt, dass sich die eGK zu diesem Zeitpunkt in einem Versorgungskontext mit der LEI befindet.

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

3.2.2.1 Validierung des PoPP-Tokens

Der E-Rezept-Fachdienst prüft beim Abruf der E-Rezepte den vom AVS übermittelten Token in der Rolle PoPP-Verifier (siehe [gemSpec_PoPP_Service]). Die Validierung des Schlüsselmaterials erfolgt gemäß dem OpenID-Connect-Standard.

Der PoPP-Service ist innerhalb der TI-Föderation beim Federation Master registriert und veröffentlicht sein Entity Statement über einen definierten Endpunkt. Der E-Rezept-Fachdienst ruft dieses Entity Statement ab. Darin ist eine Referenz auf den öffentlichen Schlüssel enthalten, mit dem sowohl das Entity Statement selbst als auch ein JWK-Set signiert sind.

Anschließend lädt der E-Rezept-Fachdienst über die im Entity Statement angegebene URL das JWK-Set, um die öffentlichen Schlüssel zur Verifizierung der PoPP-Token-Signatur zu beziehen. Dadurch kann der E-Rezept-Fachdienst sicherstellen, dass ein vorgelegter PoPP-Token tatsächlich vom PoPP-Service ausgestellt wurde.

Ein Clientsystem des E-Rezept-Fachdienstes übermittelt in seiner Anfrage den PoPP-Token, der daraufhin geprüft wird. Nach erfolgreicher Signaturprüfung wird kontrolliert, ob der Token innerhalb des vorgesehenen Zeitfensters erstellt wurde und ob die im Token enthaltene Telematik-ID mit der Telematik-ID der aufrufenden Apotheke übereinstimmt. Fallen alle Prüfungen positiv aus, liefert der E-Rezept-Fachdienst im Response die zur im Token enthaltenen KVNR gehörenden einlösbaren E-Rezepte zurück.

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. 

3.2.3.1 E-Rezepte von Versicherten durch Abgebenden abrufen

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

Tabelle 1 : Anwendungsfall "E-Rezepte eines Versicherten durch Abgebende abrufen"

Name E-Rezepte eines Versicherten durch Abgebenden abrufen
Vorbedingungen
  • Der Versicherte oder ein Vertreter befindet sich vor Ort im Kontakt  mit einem Mitarbeiter 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 oder ein mit dem Primärsystem verbundenen Standard-Kartenleser.
Das PS ruft für diese eGK den Anwendungsfall zum Erstellen eines PoPP-Token auf. Im Ergebnis erhält das PS, sofern die eGK nicht gesperrt und das Authentifizierungszertifikat gültig ist, einen PoPP-Token.
Das PS übermittelt dem PoPP-Token, um die einlösbaren E-Rezepte des Versicherten vom E-Rezept-Fachdienst abzurufen.
Der E-Rezept-Fachdienst prüft die Gültigkeit des PoPP-Tokens.
Der E-Rezept-Fachdienst übermittelt die Zugriffsinformationen (Task-ID und AccessCode) zu jedem einlösbaren E-Rezept.
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. Das Verfahren erlaubt nicht, dass dem Apotheker nur eine Auswahl der einlösbaren E-Rezepten zur Kenntnis gelangt. Sofern es mehrere einlösbare E-Rezepte gibt, 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.

Die Eingabe der eGK-PIN ist nicht erforderlich, um das Verfahren möglichst barrierearm zu gestalten. 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 eGK-PIN mitteilen müsste.

Falls ein Versicherter seine eGK verliert, muss er dies bei seiner Krankenkasse melden, die daraufhin eine Sperrung der Karte vornimmt bzw. veranlasst. Der PoPP-Service prüft den Sperrstatus einer eGK und liefert nur für gültige eGKs einen PoPP-Token zurück.

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 vom Primärsystem der abgebenden LEI übermittelt wurde. Das Primärsystem der abgebenden LEI erhält den PoPP-Token vom PoPP-Service über den im PS integrierten PoPP-Client.

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. Aus Sicht der Anwendung E-Rezept entsteht hierdurch kein Risiko für Versicherte, da das Abrufen von E-Rezepten in einer Apotheke der normale, vom Versicherten intendierte Anwendungsfall ist. In verordnenden LEIs spielen PoPP-Token für die Anwendung E-Rezept keine Rolle, da E-Rezepte auch ohne Anwesenheit des Versicherten für ihn ausgestellt werden können müssen.

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 abgebenden LEI gesteckte eGK dar.

Der PoPP-Token beinhaltet neben anderen Informationen 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. Eine Apotheke kann jedoch innerhalb des zulässigen Zeitraumes einen PoPP-Token mehrfach verwenden.

Der E-Rezept-Fachdienst protokolliert für den Versicherten, dass ein Abruf von E-Rezepten mittels Vorlegens eines gültigen PoPP-Tokens durch eine abgebende LEI erfolgte. Beim Aufruf des PoPP-Services erfolgt keine Protokollierung auf der eGK. Auch der PoPP-Service selbst protokolliert nicht, wenn er aufgerufen wird.

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

Anpassung A_19284-* E-Rezept-Fachdienst - Versichertenprotokoll zu Operationen

http GET /Task
Apotheke
(PoPP)		 Durch <PoPP-Anwendungsfall> hat Apotheke die Liste der einlösbaren E-Rezepte abgerufen.
3.4.1.2 Ressource Task
3.4.1.2.1 HTTP-Operation GET

A_21558-02 - E-Rezept-Fachdienst - Task abrufen - Rollenprüfung Versicherter oder Apotheke liest Rezepte

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task  sicherstellen, dass ausschließlich Versicherte und Leistungserbringer in der Rolle 

die Operation am E-Rezept-Fachdienst aufrufen dürfen und die Rolle "professionOID" des Aufrufers im ACCESS_TOKEN im HTTP-RequestHeader "Authorization" feststellen, damit E-Rezepte nicht durch Unberechtigte ausgelesen werden können. [<=]

A_22432-02 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - Prüfung PoPP-Token

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit HTTP-Header X-PoPP-Token durch eine abgebende LEI, den im HTTP-Header X-PoPP-Token übermittelten Token extrahieren, prüfen und bei Fehlen oder fehlerhafter Prüfung mit dem Fehler 403 abbrechen, damit die Autorisierung zum Zugriff auf die Daten nur erfolgt, wenn ein Anwesenheitsnachweis erfolgreich durchgeführt wurde.  [<=]

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

A_23399-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - PoPP - Zeitraum Akzeptanz PoPP-Token

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit HTTP-Header X-PoPP-Token durch eine abgebende LEI prüfen, dass die Differenz zwischen Zeitstempel iat im Token und dem aktuellen Zeitpunkt nicht größer als 30 Minuten (konfigurierbar) ist und bei fehlerhafter Prüfung mit dem Fehler 403 abbrechen. [<=]

A_22431-02 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - PoPP - Filter KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit HTTP-Header X-PoPP-Token durch eine abgebende LEI, die Tasks nach

filtern und in einem Bundle der gefundenen Tasks (ohne den signierte Anhang QES) zurückgeben, damit eine abgebende LEI alle zu einem Versicherten gehörenden einlösbaren E-Rezepte mit dem Status "offen" abrufen kann. [<=]

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 der E-Rezept-Fachdienst in einem Aufruf einen PoPP-Token empfängt muss geprüft werden, dass der Token vom PoPP-Service ausgestellt wurde. Hierzu wird die Signatur des PoPP-Tokens geprüft.

Der E-Rezept-Fachdienst setzt gemäß [gemSpec_PoPP_Service] in der Rolle PoPP-Verifier folgende Prüfschritte um (siehe [gemSpec_PoPP_Service#5.1.2 PoPP-Token Prüfung]):

Tabelle 2 : TAB_eRPFD_xxx Prüfschritte PoPP-Token

Prüfschritt Anforderung  Beschreibung
Beziehen der URL für den PoPP-Service A_27358 Die URL des PoPP-Service wird per Konfiguration im E-Rezept-Fachdienst hinterlegt. Deshalb kann auf die Abfrage der URL des PoPP-Service beim Federation Master verzichtet werden.
Beziehen der Schlüssel für die PoPP-Token Signaturprüfung A_26449 Der PoPP-Service veröffentlicht sein EntityStament nach OpenID-Connect Standard. Dort ist die URL hinterlegt, an dem das JWK-Set abgerufen werden kann.
Prüfung Signatur des JWK-Set A_26534 Der E-Rezept-Fachdienst bezieht aus dem Entity Statement des PoPP-Service den öffentlichen Schlüssel zur Prüfung der Signatur des JWK-Set und prüft dieses anschließend.
Durchführung der Signaturprüfung von PoPP-Token A_26450 Der E-Rezept-Fachdienst führt die Signaturprüfung der PoPP-Token durch.
Inhaltliche Prüfung des PoPP Tokens A_26452 Der E-Rezept-Fachdienst validiert, ob der PoPP-Token inhaltlich valide ist.
Prüfungen von Claims für den E-Rezept-Fachdienst sind im Kapitel "Ressource Task - HTTP-Operation GET - Prüfung PoPP-Token" beschrieben.

Anstelle zur nicht zugewiesnen Anforderung  A_27358 - Beziehen der URL für den PoPP-Service

A_28579 - E-Rezept-Fachdienst - Prüfung PoPP-Token - Apotheke - PoPP Prüfung - Konfiguration PoPP-Service URL

Der E-Rezept-Fachdienst MUSS einen Konfigurationsparameter PoPP_Service_Domain für die Domain des PoPP-Service verwalten. [<=]

Ergänzend zu A_26449 - Beziehen der Schlüssel für die PoPP-Token Signaturprüfung :

A_28580 - E-Rezept-Fachdienst - Prüfung PoPP-Token - Aktualisierung des PoPP-Service JWK-Sets

Der E-Rezept-Fachdienst MUSS stündlich die JWK-Set des PoPP-Service [RFC7517] über dem im Entity Statement metadata.oauth_resource.signed_jwks_uri angegeben URL abrufen und die öffentlichen Schlüssel zur Verifikation der PoPP-Token verwenden. [<=]

Ergänzend zu A_26452 - Inhaltliche Prüfung des PoPP Tokens :

A_23402-01 - E-Rezept-Fachdienst - Prüfung PoPP-Token - Telematik-ID prüfen

Der E-Rezept-Fachdienst MUSS bei der Prüfung des PoPP-Token prüfen, dass die Telematik-ID actor_id aus dem Token mit der Telematik-ID der Leistungserbringerinstitution (idNumber) im ACCESS_TOKEN im "Authorization"-Header des HTTP-Requests übereinstimmt und bei fehlerhafter Prüfung mit dem Fehler 403 abbrechen. [<=]

Folgende Anforderungen aus der anwendungsübergreifenden Spezifikation werden dem E-Rezept-Fachdienst zugewiesen:

Anforderung Prüfverfahren
A_26449 - PoPP-Verifier - Verwendung von PoPP-Service JWK-Sets funktionale Eignung: Anbietererklärung
A_26534 - PoPP-Verifier - PoPP-Service JWK-Set Signatur Prüfung Sicherheitsgutachten
A_26450 - PoPP-Verifier - PoPP-Token Signaturprüfung Produktgutachten
A_26452 - PoPP-Verifier - JWT Claims Validierung Produktgutachten

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 3 : TAB_FdVERP_014 - HTTP-Header "X-erp-resource"

Operation X-erp-resource
GET /Task Task

3.4.2.2 E-Rezepte von einem Versicherten abrufen

Mit diesem Anwendungsfall kann die abgebende LEI die E-Rezept-Token Information zu allen einlösbaren E-Rezepten von einem Versicherten, dessen eGK in ein mit dem Konnektor gepairten E-Health-Kartenterminal oder ein mit dem Primärsystem verbundenen Kartenleser gesteckt wurde, vom E-Rezept-Fachdienst abrufen.

A_22434-02 - PS abgebende LEI: E-Rezepte von Versicherten abrufen

Das PS der abgebenden LEI MUSS den Anwendungsfall "E-Rezepte eines Versicherten durch Abgebenden abrufen" gemäß TAB_ILFERP_019 umsetzen. 

Tabelle 4 : TAB_ILFERP_019 – E-Rezepte von Versicherten abrufen

Name E-Rezepte von Versicherten abrufen
Auslöser
  • Aufruf des Anwendungsfalls in der GUI
Akteur Leistungserbringer, Mitarbeiter der abgebenden LEI
Vorbedingung
  • Der eGK des Versicherten ist im eHealth-Kartenterminal oder einem Standard-Kartenleser gesteckt.
  • Die LEI hat sich gegenüber der TI authentisiert.
Nachbedingung
  • Es steht eine Liste von Informationen mit Task-ID und zugehörigen AccessCode zu einlösbaren E-Rezepten des Versicherten für die Weiterverarbeitung zu Verfügung.
Standardablauf
  1. PoPP-Token abrufen
  2. E-Rezepte abrufen
[<=]

A_22435-02 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - PoPP-Token abrufen

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" einen PoPP-Token vom PoPP-Service abrufen. [<=]

Für die Umsetzung siehe [spec-ilf-popp-client].

Hinweis: Im Response des PoPP-Service erhält das PS den PoPP-Token im JWT Compact Serialization Format (s. gemSpec_PoPP_Service#A_26432). Das PS gibt den PoPP-Token im gleichen Format an den E-Rezept-Fachdienst weiter.

A_22437-02 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - E-Rezepte abrufen

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" die HTTP-Operation GET /Task mit

ausführen. [<=]

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

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.

A_23152 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - nicht belieferte E-Rezepte zurückgeben

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" den Nutzer geeignet unterstützen, heruntergeladene und damit reservierte E-Rezepte, welche nicht beliefert werden, wieder zurückzugeben, um dem Versicherten zu ermöglichen, diese in einer anderen Apotheke einzulösen.  [<=]

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

E-Rezept-Fachdienst

Für die Hinzunahme der Funktionalität des Abrufs von E-Rezepten in der Apotheke mit der eGK des Versicherten wird keine zusätzliche Last durch den notwendigen Abruf der Liste der E-Rezepte (GET /Task(PoPP)) erzeugt. Es ist davon auszugehen, dass der Abruf GET /Task(PoPP) den Abruf GET /Task(PNW) ersetzt und die Abrufzahlen gleich bleiben. 

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

Auszug:

UseCase-Bezug Fachdienstoperation Mittelwert
[msec]		 99%-Erfüllungsquote
[msec]
ERP.UC_4_15 GET /Task(PoPP)
600 840

Komplette abgeänderte Anforderung:

A_20165-12 - Performance – E-Rezept-Fachdienst - Bearbeitungszeit unter Last

Der E-Rezept-Fachdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Bearbeitungszeitvorgaben" unter einer Spitzenlast von 1770 Aufrufen pro Sekunde an der TI Schnittstelle und 620 Aufrufen pro Sekunde an der Internet-Schnittstelle erfüllen.

Tabelle 5: Tab_gemSpec_Perf_eRP-Fachdienst: Bearbeitungszeitvorgaben

UseCase-Bezug Fachdienstoperation Mittlere Bearbeitungszeit
[msec]		 99%-Erfüllungsquote
[msec]
ERP.UC_1_1 GET /Device 120 200
ERP.UC_1_2 GET /metadata 120 200
ERP.UC_2_1 POST /Task/$create 250 400
ERP.UC_2_3* POST /Task/<id>/$activate 460 620
ERP.UC_2_5 POST /Task/<id>/$abort 330 470
ERP.UC_3_1 GET /Task 380 530
ERP.UC_3_2 POST /Task/<id>/$abort 330 470
ERP.UC_3_3 POST /Communication 430 590
ERP.UC_3_4 GET /Communication 540 720
ERP.UC_3_5 GET /AuditEvent 540 720
ERP.UC_3_6 GET /Task/<id> 380 530
ERP.UC_3_7 GET /ChargeItem/<id> 480 650
ERP.UC_3_8 DELETE /Communication/<id> 540 720
ERP.UC_3_9 GET /MedicationDispense?<parameter>= 540 720
ERP.UC_3_10 GET /ChargeItem 540 720
ERP.UC_3_11 DELETE /ChargeItem/<id> 430 590
ERP.UC_3_12 PATCH /ChargeItem/<id> 310 440
ERP.UC_3_13 GET /Consent 280 410
ERP.UC_3_14 POST /Consent 340 480
ERP.UC_3_15 DELETE /Consent 430 600
ERP.UC_3_16 POST /$grant-eu-access-permission  430 590
ERP.UC_3_17 DELETE /$revoke-eu-access-permission 430 590
ERP.UC_3_18 GET /$read-eu-access-permission 380 530
ERP.UC_3_20 POST /pushers/set
460 620
ERP.UC_3_21 GET /pushers
380 530
ERP.UC_3_22 GET /channels
380 530
ERP.UC_3_23 GET /channels/{pushkey}
380 530
ERP.UC_3_24 POST /channels/{pushkey}
460 620
ERP.UC_4_1 POST /Task/<id>/$accept 340 480
ERP.UC_4_2 POST /Task/<id>/$reject 300 430
ERP.UC_4_3 POST /Task/<id>/$abort 330 470
ERP.UC_4_4 POST /Task/<id>/$close 460 620
ERP.UC_4_6 GET /Communication 540 720
ERP.UC_4_7 POST /Communication 430 590
ERP.UC_4_8 GET /Task/<id>?secret 615 800
ERP.UC_4_9 DELETE /Communication/<id> 290 420
ERP.UC_4_10 GET /ChargeItem/<id> 480 650
ERP.UC_4_11 POST /ChargeItem 510 680
ERP.UC_4_12 GET /Task(PNW) 600 840
ERP.UC_4_13 PUT /ChargeItem/<id>  510 670
ERP.UC_4_14 POST /Subscription 230 350
ERP.UC_4_15 GET /Task(PoPP) 600 840
ERP.UC_4_16 POST /Task/<id>/$dispense 460 620
ERP.UC_4_17 GET /Task/<id>?accesscode 615 800
ERP.UC_4_19  POST /$get-eu-prescriptions mit Requesttype demographics 615 800
ERP.UC_4_20 POST /$get-eu-prescriptions mit Requesttype e-prescriptions-list 650 840
ERP.UC_4_21 POST /$get-eu-prescriptions mit Requesttype e-prescriptions-retrieval 650 840
ERP.UC_4_22 POST /Task/<id>/$eu-close  460 620
[<=]

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

ID Anwendungsfall Datenmenge
[KB]		 Mittelwert
[s]
ERP.UC_4_15 E-Rezepte vom Versicherten durch Abgebenden abrufen (PoPP) 10 4

3.4.5.3 Bereitstellung von Betriebsdaten

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

$FD-operation Operation  Schnittstelle zu 
ERP.UC_4_15 GET /Task(PoPP) abgebende LEI

3.4.5.4 Servicezerlegung

In Kapitel 3.5.2 der gemKPT_Betr werden die Mitwirkungspflichten für das TI-ITSM und deren Teilnehmer untereinander geregelt. Um den Support zwischen dem E-Rezept Fachdienst und dem PoPP Service aufzunehmen, wird der Unterstützungsservice für den Anbieter des E-Rezept Fachdienstes und seiner Service Komponente (das Produkt E-Rezept Fachdienst) gegenüber dem Anbieter des PoPP-Service und seiner Servicekomponente hinterlegt.

In der nachfolgenden Grafik sind das die gelbmarkierten U:

3.4.5.5 Technische Service Level und Performance-Kenngrößen

Die folgende Ergänzung wird in der gemKPT_Betr in Kapitel 5.3.1.9 an [gemKPT_Betr#Tab_gemKPT_Betr_eRP_S::O/A] vorgenommen.

Produkttyp ID Anwendungsfall Beschreibung
PDT50 A44 ERP.UC_4_15 E-Rezepte vom Versicherten durch Abgebenden abrufen (PoPP)

Die folgende Ergänzung wird in der gemKPT_Betr in Kapitel 5.3.1.9 an [gemKPT_Betr#Tab_gemKPT_Betr_eRP_Performance-Kenngroessen] vorgenommen.

Performance-
Kenngröße		 Beschreibung berechnet aus (Betriebsdaten, Probing) SL-Wert
(Soll-Wert)		 min / max Normative Referenz
E-Rezept-Fachdienst - PDT50 - (ERP.UC_4_15)
PDT50-A17-D2-G08 Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 650 max A_20165-*
PDT50-A17-D2-G30 Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] Betriebsdaten 840 max A_20165-*
PDT50-A17-D2-G31 Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] Betriebsdaten 99000 min A_20165-*

4 Anwesenheitsbeleg mittels strukturiertem VSDM Prüfungsnachweis

Nach einer Migrationsphase wird der Anwendungsfall "Anwesenheitsbeleg mittels strukturiertem VSDM Prüfungsnachweis" abgekündigt. Damit entfallen folgende Anforderungen. Sie werden storniert.

4.1 Technisches Konzept

4.1.1 Use Case im Rahmen der Belieferung in der Apotheke

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

4.2 Spezifikation

4.2.1 Anforderungen an den E-Rezept-Fachdienst

Stornierte Anforderungen
A_23450-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Prüfung Prüfungsnachweis
A_27287 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Vergleich KVNR
A_27347 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Vergleich hcv
A_23451-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Zeitraum Akzeptanz Prüfungsnachweis
A_23452-03 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Filter Status, KVNR und Workflowtype
A_25206 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - PN3
A_25208-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - URL kvnr
A_27346 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - URL hcv
A_25994 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - PN3 - Mappen von IKNR zu VSDM
A_25995 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - PN3 - keine E-Rezepte
A_25207 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - PN3 - AcceptPN3 false
A_25209-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - PN3 - AcceptPN3 true - Filter Status, KVNR und Workflowtype
A_23454 - E-Rezept-Fachdienst - Prüfung Prüfziffer
A_23456-01 - E-Rezept-Fachdienst - Prüfung Prüfziffer - Berechnung HMAC der Prüfziffer
A_27301 - E-Rezept-Fachdienst - Prüfung und Entschlüsselung Prüfziffer Version 2
A_23501 - E-Rezept-Fachdienst – VSDM HMAC-Schlüssel - Verarbeitung in VAU
A_23482 - Anbieter E-Rezept-Fachdienst - Bereitstellung Exportpaket VSDM HMAC-Schlüssel
A_23483 - Anbieter E-Rezept-Fachdienst - Prüfung Exportpaket VSDM HMAC-Schlüssel
A_23492 - E-Rezept-Fachdienst - VSDM HMAC-Schlüssel - Exportpaket einbringen
A_23493 - E-Rezept-Fachdienst - VSDM HMAC-Schlüssel - Prüfung
A_23484 - Anbieter E-Rezept-Fachdienst - Prüfung Exportpaket VSDM HMAC-Schlüssel - Information Fachdienstbetreiber VSDM
A_23485 - Anbieter E-Rezept-Fachdienst - Löschen VSDM HMAC-Schlüssel
A_23486 - E-Rezept-Fachdienst - VSDM HMAC-Schlüssel - Ausgabe
A_25200 - E-Rezept-Fachdienst - Status AcceptPN3
A_25201 - E-Rezept-Fachdienst - Status AcceptPN3Automatic
A_25202 - E-Rezept-Fachdienst - Konfigurationsparameter NumberApothekenPN3
A_25203 - E-Rezept-Fachdienst - Betrieblicher Prozess Änderung AcceptPN3, AcceptPN3Automatic, NumberApothekenPN3
A_25371 - E-Rezept-Fachdienst - Konfigurationsparameter AcceptPN3Interval
A_25372 - E-Rezept-Fachdienst - AcceptPN3 - Anzahl Apotheken mit PN3
A_25204 - E-Rezept-Fachdienst - AcceptPN3 - automatisch Aktivieren
A_25205 - E-Rezept-Fachdienst - AcceptPN3 - automatisch Deaktivieren

Gelöschte Zuordnung der Anforderung zum E-Rezept-Fachdienst
A_27299 - VSDM-Prüfziffer Version 2: prüfenden Systeme, Import der gemeinsamen Geheimnisse und AES/GCM-Schlüsselableitung
A_27342 - Konfigurationsvariable enforce_hcv_check
A_27279 - VSDM-Prüfziffer Version 2: Prüfung und Entschlüsselung

4.2.2 Anforderungen an das Primärsystem der abgebenden LEI

Stornierte Anforderungen
A_22435 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - VSD und PNW von eGK lesen
A_22436 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - Abbruch bei Fehler ReadVSD
A_23182 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - Prüfungsnachweis URL-kodieren
A_27354 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - Hashwert hcv erzeugen
A_27355 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - Hashwert hcv Base64URLSafe kodieren

Gelöschte Zuordnung der Anforderung zu Primärsystem der abgebenden LEI
A_27352 - VSDM-Prüfziffer Version 2: Erzeugung von hcv

4.2.3 Betrieb

Last und Antwortzeiten

Der folgende Eintrag in der Anforderung A_20165-* [gemSpec_Perf#Tab_gemSpec_Perf_eRp-Fachdienst: Last- und Bearbeitungszeitvorgaben] wird gelöscht:

UseCase-Bezug Fachdienstoperation Spitzenlast
[1/s]		 Mittelwert
[ms]		 99%-Quantil
[ms]
ERP.UC_4_12 GET /Task(PNW)
220 650 840

Der folgende Eintrag in [gemSpec_Perf#Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall] wird gelöscht:

ID Anwendungsfall Datenmenge
[KB]		 Mittelwert
[s]
ERP.UC_4_12 E-Rezepte vom Versicherten durch Abgebenden abrufen (VSDM++) 10 5,7

Bereitstellung von Betriebsdaten

Der folgende Eintrag in [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst] wird gelöscht:

$FD-operation Produkttyp Operation
ERP.UC_4_12 E-Rezept-Fachdienst GET /Task(PNW)

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.

Dokument
Titel
[gemILF_PS_eRp] gematik: Implementierungsleitfaden Primärsysteme – E-Rezept
[gemSpec_FD_eRp] gematik: Spezifikation E-Rezept-Fachdienst
[gemSpec_Perf] gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform
[gemKPT_Betr] gematik: Betriebskonzept Online-Produktivbetrieb

5.2 Übersicht Produkt- und Anbietertypen

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

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Kürzel Erläuterung
AdV Anwendungen des Versicherten
AVS Apothekenverwaltungssystem
eGK elektronische Gesundheitskarte
FdV Frontend des Versicherten
G-ID GesundheitsID
JWT Json Web Token
KVNR Krankenversichertennummer
LE Leistungserbringer
LEI Leistungserbringerinstitution
PNW VSDM Prüfungsnachweis
PoPP Proof of Patient Presence

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.

[Quelle]
Herausgeber: Titel
[gemGlossar]
gematik: Glossar der Telematikinfrastruktur
[gemILF_PS_eRp] gematik: Implementierungsleitfaden Primärsysteme – E-Rezept
[gemKPT_Betr] gematik: Betriebskonzept Online-Produktivbetrieb
[gemSpec_FD_eRp] gematik: Spezifikation E-Rezept-Fachdienst
[gemSpec_Perf] gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform
[gemSpec_PoPP_Service] gematik: Spezifikation Proof of Patient Presence (PoPP)-Service
[spec-ilf-popp-client] gematik: Implementierungsleitfaden PoPP für Primärsysteme
https://github.com/gematik/spec-ilf-popp-client/tree/main 

6.2.2 Weitere Dokumente

[Quelle]
Herausgeber (Erscheinungsdatum): Titel