Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

E-Rezept-Frontend des Versicherten

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
07.10.2021
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_eRp_FdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps E-Rezept-Frontend des Versicherten.

1.2 Zielgruppe

Das Dokument richtet sich den Hersteller (gematik) von Produkten des Produkttypen E-Rezept Frontend des Versicherten, sowie an Hersteller und Anbieter von weiteren Produkttypen der Fachanwendung E-Rezept.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps E-Rezept-Frontend des Versicherten verzeichnet.

Diese Spezifikation beschreibt Anforderungen zu den Aspekten Sicherheit, Interoperabilität, Funktionalität und Barrierefreiheit. Die konkrete Ausgestaltung der Benutzeroberfläche (GUI) und der Benutzerführung (UX) werden im Rahmen des agilen Herstellungsprozesses des E-Rezept-FdV erarbeitet.

1.5 Methodik

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

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

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

1.5.1 Hinweis auf offene Punkte

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

Beispiel für einen offenen Punkt.

2 Systemüberblick

Das E-Rezept-Frontend des Versicherten (E-Rezept-FdV) ist eine App für den Versicherten, welche die für die Nutzung der Fachanwendung E-Rezept notwendigen Funktionalitäten bündelt und dezentrale Fachlogik der Fachanwendung E-Rezept ausführt.

Ausführungsumgebung des E-Rezept-FdV ist ein mobiles Gerät des Versicherten (GdV), welches das Betriebssystem Google Android oder Apple iOS verwendet. Es steht unter alleiniger Kontrolle des Versicherten. Dem Versicherten obliegt es, durch geeignete Maßnahmen die Sicherheit der Daten zu stärken.

3 Systemkontext

3.1 Akteure und Rollen

Im Systemkontext des FdV interagieren verschiedene Akteure (aktive Komponenten) in unterschiedlichen Rollen mit dem FdV.

Tabelle 1: TAB_FdVERP_001 – Akteure und Rollen

3.2 Nachbarsysteme

Die vom E-Rezept-FdV direkt erreichbaren Produkttypen der TI sind

• Identity Provider (IDP)
• E-Rezept-Fachdienst
• Verzeichnisdienst 
• eGK

Abbildung 1: ABB_FDVERP_001 Systemüberblick FdV

Identity Provider

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

Authenticator-Modul

Das Authenticator-Modul ist eine logische Komponente im E-Rezept-FdV. Das Authenticator-Modul kapselt funktionale Anteile des Authentifizierungsprozesses und die Kommunikation mit der Smartcard des Nutzers.

Für die Authentisierung mittels eGK greift das E-Rezept-FdV mittels des Funkstandards Near Field Communication (NFC) zur drahtlosen Datenübertragung auf die kontaktlose Schnittstelle auf die eGK zu. Das bedeutet für den Nutzer, dass er sowohl eine NFC-fähige eGK als auch ein NFC-fähiges Endgerät benötigt.

E-Rezept-Fachdienst

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

Verzeichnisdienst

Der Produkttyp Verzeichnisdienst der TI stellt ein Verzeichnis von Apotheken bereit, bei denen der Versicherte E-Rezepte einlösen kann. Der Versicherte kann für die Suche nach Apotheken bspw. folgende Parameter verwenden: Institutionsname, Straße, Postleitzahl, Ort, Geodaten.

4 Übergreifende Festlegungen

4.1 Datenschutz und Sicherheit

In diesem Kapitel werden übergreifende Anforderungen beschrieben, die sich aus den Themenfeldern Datenschutz und Sicherheit ergeben.

Hinweis: Die Annahmen und Anforderungen sollen insbesondere Hinweise enthalten, mit welchen Maßnahmen der Nutzer sein Gerät sicher gestalten kann.

Hinweis: Dies betrifft bspw. die folgenden Aspekte:

• Verwendung von Plattform Sicherheit Best Practice
• Secure Data Storage
• Schutz gegen code tampering
• Extraneous functionality

Für mobile Anwendungen sind OWASP Top Ten Mobile Controls [OWASP TTMC] zu beachten.

Für Festlegungen zur Schlüsselerzeugung siehe [gemSpec_Krypt#GS-A_4368].

Um die geforderte Entropie zu erreichen, können Informationen von zusätzlichen Quellen (Internet, Sensoren des Geräts) zusammengeführt werden.

Hinweis: Dienste Dritter, an die andere Daten als personenbezogene medizinische Daten weitergeleitet werden können, sind z.B. Kartendienste oder der Arzneimitteldatenbanken. Näheres hierzu regelt die Rechtsverordnung nach § 360 (5) PDSG.

Hinweis: Nach dem Widerruf darf das E-Rezept-FdV keine Daten mehr an Dienste von Dritten weitergeben. 

Hinweis: Beispielmaßnahmen sind in [OWASP Proactive Control#C2] zu finden. Das gewählte Verfahren muss die gleiche Wirksamkeit aufweisen wie die Kapselung gemäß [OWASP Proactive Control#C2 Punkt 4].

Hinweis: Die in A_19183 geforderte Zustimmung kann einmalig durch den Versicherten erteilt werden und bis auf Widerruf des Versicherten für alle Datenweiterleitungen, die von dem Versicherten veranlasst werden, gelten. Das E-Rezept-FdV kann dabei die Möglichkeit einer expliziten Opt-in-Lösung mit Widerrufsrecht oder ein anlassbezogenes Zustimmungsverfahren oder eine Wahlmöglichkeit beider Verfahren vorsehen.

Hinweis: Zu diesen Daten gehören Session-Daten, Cashes, Schlüssel, E-Rezept-Token, E-Rezept-Inhaltsdaten, Nachrichten.

4.1.1 Anforderungen zum Herstellungsprozess

Der Hersteller des E-Rezept-FdV muss die Anforderungen aus dem Abschnitt "Sicherer Softwareentwicklungsprozess" des Dokuments [gemSpec_DS_Hersteller] erfüllen.

4.1.2 Unterstützung von Audits

Der Hersteller des E-Rezept-FdV muss die Anforderungen aus dem Abschnitt "Unterstützung von Audits" des Dokuments [gemSpec_DS_Hersteller] erfüllen.

4.1.3 Tracking

Für die Analyse des Nutzerverhaltens (Tracking) bei der Verwendung des Frontends durch den Versicherten gelten die nachfolgend aufgeführten Anforderungen.

4.1.3.1 Anforderungen zum Tracking an das E-Rezept-FdV

Hinweis: Die folgenden Anforderungen gelten nur, falls das E-Rezept-FdV ein Usability-Tracking sowie Crash-Reporting vorsieht.

Hinweis: Diese Anforderung ist nicht durch einen alleinigen Verweis auf die AGB oder Nutzungsbedingungen des FdVs erfüllbar. Verständliche Form bedeutet eine kurze, nicht juristische Erklärung zum Zweck des Usability-Tracking sowie Crash-Reporting. Leicht zugängliche Form bedeutet direkt im FdV.

Hinweis: Wenn der Benutzer seine Einwilligung in das Usability-Tracking sowie Crash-Reporting nicht erteilt, darf das E-Rezept-FdV den Nutzer nicht solange nach seiner Einwilligung fragen, bis der Nutzer diese erteilt.

Hinweis: Das E-Rezept-FdV muss auch ohne aktiviertes Usability-Tracking sowie Crash-Reporting vollständig funktional nutzbar sein.

Hinweis: Personenbezogene Daten mit direktem Personenbezug sind bspw. Namen von natürlichen Personen, Geräte-IDs, Nutzerkennungen oder ein „Fingerabdruck“ auf Basis von Geräteeigenschaften und Einstellungen.

Hinweis: Sicherheitsmerkmale sind z.B. geheime oder private Schlüssel, Authentifizierungs- oder Autorisierungsbestätigungen.

Hinweis: Für die Güte des Zufalls gilt die entsprechende Anforderung aus [gemSpec_Krypt].

4.1.3.2 Anforderungen zum Tracking an den Hersteller

4.2 Benutzeroberfläche

Die Benutzeroberfläche, welche durch den Versicherten genutzt wird, um E-Rezept-Anwendungsfälle auszuführen, ist Teil des E-Rezept-FdVs.

Die folgenden Ausführungen zu Anforderungen an die visuelle Darstellung und Benutzerführung / Benutzerfreundlichkeit sind normativ.

4.2.1 Visuelle Darstellung

Für die visuelle Darstellung der Inhalte ist eine grafische Benutzeroberfläche erforderlich, welche die E-Rezept-Daten des Versicherten strukturiert und übersichtlich darstellt.

Das E-Rezept-FdV soll eine einheitlich gestaltete Oberfläche zur Benutzerführung besitzen, um die Übersichtlichkeit in allen Anwendungsfällen für den Nutzer zu gewährleisten. Es soll Menüfunktionen, Texte und andere Anzeigen eindeutig, verständlich und widerspruchsfrei benennen bzw. darstellen.

Das E-Rezept-FdV soll es dem Nutzer ermöglichen, zu jeder Zeit zu erkennen, in welchem E-Rezept-Anwendungsfall sich die Applikation gerade befindet.

4.2.2 Benutzerführung/Benutzerfreundlichkeit (Usability)

Eine hohe Akzeptanz der Benutzerfreundlichkeit oder Usability wird durch eine einfache, selbsterklärende Bedienung der Oberfläche erreicht, die sich an gängigen Mustern des App-Designs orientiert.

Hierfür ist es auch erforderlich, die Erwartungshaltung der Zielgruppe zu kennen und zu berücksichtigen (z.B. auch Menschen mit körperlichen oder geistigen Einschränkungen).

Die Akzeptanz des Frontends für den Versicherten hängt in großem Maße von folgenden Faktoren ab:

• Anwendbarkeit auf verschiedenen Bildschirmgrößen und Auflösungen
• Intuitive und unkomplizierte Handhabung
• Anwendbarkeit auch im Offline-Modus
• Zielgruppenorientierung
• Leichte und verständliche Bereitstellung von Informationen
• Einhaltung ergonomischer Aspekte (z.B. kurze Touchwege)
• Konsistente Gestaltung der Links, Buttons, etc.

4.2.2.1 Technische Normen und Verordnungen zur Beachtung

Zusätzlich zu den in diesem Kapitel aufgeführten Anforderungen zur Benutzerführung sollen auch die in der ISO 9241 aufgeführten Qualitätsrichtlinien zur Sicherstellung der Ergonomie interaktiver Systeme und Anforderungen aus der Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung – BITV 2.0) beachtet werden.

DIN EN ISO 9241 – Teile mit Bezug zur Software-Ergonomie

Insbesondere sollen die nachfolgend aufgeführten Teile der ISO 9241 berücksichtigt werden:

• Teil 8:       Anforderungen an Farbdarstellungen
• Teil 9:       Anforderungen an Eingabegeräte – außer Tastaturen
• Teil 110:   Grundsätze der Dialoggestaltung (ersetzt den bisherigen Teil 10)
• Teil 11:     Anforderungen an die Gebrauchstauglichkeit – Leitsätze
• Teil 12:     Informationsdarstellung
• Teil 13:     Benutzerführung
• Teil 14:     Dialogführung mittels Menüs
• Teil 15:     Dialogführung mittels Kommandosprachen
• Teil 16:     Dialogführung mittels direkter Manipulation
• Teil 17:     Dialogführung mittels Bildschirmformularen
• Teil 171:   Leitlinien für die Zugänglichkeit von Software BITV 2.0

Für die Entwicklung eines barrierefreien E-Rezept-FdVs ist insbesondere die Verordnung zur barrierefreien Gestaltung von Informationstechnik zu beachten.

BITV 2.0 - Barrierefreie Informationstechnik-Verordnung

Hinweis: Die Versionsnummern der aufgeführten Normen und Richtlinien spiegeln den Stand zum Zeitpunkt der Erstellung dieses Dokumentes wider.

Die seit 2018 bestehende umfassende Forderung nach Umsetzung von Barrierefreiheit in der Informationstechnik erwächst aus der EU Richtlinie 2016/2102 zur „Barrierefreiheit von Webseiten und mobiler Anwendungen öffentlicher Stellen“. Diese Richtlinie musste im Jahr 2018 in Bundes- und Landesrecht übertragen werden. – Diese Gesetze verweisen jeweils auf die Barrierefreie Informationstechnik-Verordnung mit Ausgabe vom 21. Mai 2019 (BITV 2.0).

Zur Erfüllung der BITV 2.0 § 3 Abs. 2 ist die durch die Veröffentlichung im europäischen Amtsblatt harmonisierte EN 301549 „Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen“ (V 2.1.2 von 2018-08) anzuwenden. Diese liegt in der Fassung von 2020-02 als DIN EN 301549 als deutsche Übersetzung vor. Die DIN EN 301549 ist eine Beschaffungsnorm. Die darin aufgeführten und für den Anwendungsfall des FdV des E-Rezepts anzuwendenden Erfolgskriterien sind in Kapitel 9 (Web mit 50 Erfolgskriterien), Kapitel 10 (Dokumente mit 46 Erfolgskriterien) und Kapitel 11 (Nicht webbasierte Software mit 44 Erfolgskriterien) aufgeführt. Sie entsprechen den Erfolgskriterien von Level AA der 2.1. WCAG 2.1 (Web Content Accessibility Guidelines).

Der sachliche Geltungsbereich der BITV 2.0 umfasst folgende relevanten Anwendungsbereiche für diese Spezifikation:

• Webseiten,
• nicht webbasierte Software mit mobilen Anwendungen.

Folgende Gestaltungsmerkmale der Anwendungen stellen die Barrierefreiheit sicher: 

• wahrnehmbar,
• bedienbar,
• verständlich und
• robust.    

In den genannten Normen und Standards werden nebeneinander die Belange von in der Handmotorik eingeschränkter, blinder, sehbehinderter, gehörloser, schwerhöriger, geistig und lernbehinderter Menschen berücksichtigt.

Nach BITV 2.0 müssen Dokumente, die über dem FdV angezeigt werden, die gleichen Anforderungen an die Barrierefreiheit erfüllen, wie sie an die Anwendung gestellt werden. Sämtliche bereitgestellten Dokumente müssen als barrierefreie Formate angeboten werden, die mit dem Screenreader lesbar und navigierbar sind. Hierbei müssen die behinderungsspezifischen Standardsoftwares zur Herstellung von Zugänglichkeit berücksichtigt werden.

Allgemeine Anforderungen an die Benutzerfreundlichkeit

Zusätzliche Sprachen können unterstützt werden.

Bezeichnungen sollen nach Möglichkeit vollständig ausgeschrieben sein, Abkürzungen sind zu vermeiden.

Im Hinweistext können die einzelnen Schritte des Anwendungsfalls sowie die Auswirkungen auf die Nutzung der Anwendung im Rahmen der Versorgung beschrieben sein.

Ist ein Anwendungsfall durchgeführt worden, muss das E-Rezept-FdV das Ergebnis für den Versicherten klar verständlich anzeigen, z.B. "Das ausgewählte E-Rezept wurde gelöscht.".

Ist ein Anwendungsfall durch den Versicherten abgebrochen worden oder technisch nicht durchführbar, muss der Versicherte ebenfalls einen für ihn verständlichen Hinweis erhalten. In jedem Fall muss das Ergebnis für den Versicherten klar erkennbar sein.

Für die Anzeige in Fehlerfällen siehe Kapitel .

Zur Sicherstellung, dass keine Daten versehentlich gelöscht werden, soll der Nutzer nach der Auswahl der Löschen-Funktion darauf hingewiesen werden, dass es sich hierbei um eine unwiderrufliche Aktion handelt.

4.2.2.2 Usability-Tests

Um die Usability und somit die Akzeptanz des E-Rezept-FdV durch den Nutzer zu gewährleisten bzw. zu erhöhen, soll das E-Rezept-FdV während des Entwicklungsprozesses iterativ von Nutzern qualitativ getestet werden.

Hierbei sollten sowohl die verschiedenen Nutzergruppen als auch die unterschiedlichen Umgebungen berücksichtigt werden (z.B. mobiler Einsatz).

4.3 Konfiguration des E-Rezept-FdV

Im Folgenden sind Konfigurationsparameter beschrieben, deren Werte für die Nutzung der Schnittstellen benötigt werden. Darüber hinaus kann der Hersteller des E-Rezept-FdV zusätzliche Konfigurationsparameter definieren.

4.4 Logging

Das E-Rezept-FdV kann Protokolldateien schreiben, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten.

Ein Logging des E-Rezept-FdV auf Geräten des Versicherten ist im Betrieb nicht vorgesehen, da die Protokolldaten zur Auswertung nicht erreichbar sind. Die Protokollierung auf einem externen Dienst ermöglicht eine Auswertung und kann die Fehlersuche unterstützen (siehe Usability Tracking und CrashReporting). Für Testzwecke soll ein Logging zur Fehleranalyse möglich sein. 

5 Funktionsmerkmale

5.1 Allgemein

5.1.1 Session-Verwaltung

Eine App-Session bezeichnet die Nutzung des E-Rezept-FdV vom Start der App bis zum Beenden der App. Eine Authentisierung gegenüber der TI nach dem Start der App-Session erfolgt nicht zwangsläufig.

Eine TI-Session bezeichnet den Zeitraum von der Authentisierung gegenüber der TI bis zum Ablauf der Authentisierung.

Die Authentisierung gegenüber der TI erfolgt über das Authentisierungsmodul, welche als eigenständige Komponente ebenfalls auf dem GdV installiert ist. Das Authentisierungsmodul unterstützt in der ersten Stufe eine Authentisierung des Versicherten mit der eGK , wobei der Versicherte die PIN eingeben muss. In den weiteren Ausbaustufen werden alternative Authentisierungsverfahren ermöglicht.

Der Versicherte weist sich gegenüber der TI mit der Identität der eGK mittels NFC (Near Field Communication) aus. Für die Authentisierung wird sowohl eine NFC-fähige eGK als auch ein NFC-fähiges Endgerät benötigt.

Die Authentisierung des Nutzers erfolgt mittels eGK und MRPIN.home. Für den Zugriff auf die kontaktlose Schnittstelle der eGK muss zusätzlich die CAN eingegeben werden, sofern der Nutzer die CAN nicht zuvor im FdV gespeichert hat.

Alternativ kann der Nutzer das E-Rezept-FdV auch offline ohne Authentisierung gegenüber der TI mit Einschränkungen nutzen. Dies kann z.B. der Fall sein, wenn der Nutzer dies nicht wünscht oder keine NFC-fähige eGK vorliegt oder das verwendete Endgerät nicht NFC-kompatibel ist.

Die Authentisierungsdauer einer TI-Session beträgt maximal 12 Stunden ab dem Zeitpunkt der Erstellung des Authentisierungstokens. Wird die App durch den Nutzer aktiv beendet, werden die Session-Daten gelöscht und eine erneute Authentisierung wird erforderlich (siehe Abschnitt "TI-Session beenden")

5.1.2 Kommunikation mit Diensten der TI

Das E-Rezept-FdV nutzt TLS-Verbindungen für die Kommunikation zu den Diensten der TI. Es verbindet sich mit dem E-Rezept-Fachdienst, einem Identity Provider und dem Verzeichnisdienst.

Die Informationen zu den Endpunkten des Identity Providers ermittelt das E-Rezept-FdV aus dem Discovery Document. Siehe auch [ gemSpec_IDP_Frontend#A_20512 - Regelmäßiges Einlesen des Discovery Document ]. Das Discovery Document ist vom IDP-Dienst unter der URL /.well-known/openid-configuration abrufbar. 

Für Informationen zur Produktidentifikation siehe [gemSpec_OM].

Der Wechsel des API-KEY erfolgt mit einer neuen Version des E-Rezept-FdV.

Der HTTP-Header X-api-key wird im äußeren HTTP-Request, d.h. außerhalb der Verschlüsselung des VAU-Transports, gesendet.

Tabelle 3 : TAB_FdVERP_019 - HTTP-Header "X-erp-resource"

5.1.3 Authentisierung des Nutzers für Dienste der TI

Der Nutzer authentisiert sich für Zugriffe auf Dienste der TI gegenüber der TI. Das E-Rezept-FdV erhält bei erfolgreicher Authentisierung einen Authentisierungstoken (ACCESS_TOKEN), welcher für die Authentisierung bei den Diensten der TI weitergeleitet wird.

Für Informationen zum Ablauf der Authentisierung siehe [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend].

5.1.4 Authentisierung des Nutzers für Zugriff auf das E-Rezept-FdV

Der Nutzer kann einen Schutz für den Zugriff konfigurieren. Hierbei sind verschiedene Authentisierungsarten zulässig. Für die Authentisierungsart Online-Authentisierung

Bei erfolgreicher Authentisierung erhält das E-Rezept-FdV einen verschlüsselten ACCESS_TOKEN. Das E-Rezept-FdV kann diesen ACCESS_TOKEN nicht entschlüsseln und somit nicht auswerten. Daher wird der HTTP-Response 200 als Ergebnis einer erfolgreichen Authentisierung gewertet.

Bei erfolgreicher Authentisierung werden  folgende Funktionen ermöglicht:

• Ein aktiver Zugriffsschutz wird deaktiviert. Der Nutzer kann auf die Funktionen des E-Rezept-FdV zugreifen
• Eine Konfiguration mit einem Authentisierungstypen mit niedrigerem Sicherheitsniveau bzw. das Abschalten des Zugriffsschutzes wird gespeichert.

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

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

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

5.1.6 Zertifikatsprüfung

Das E-Rezept-FdV verwendet bei den in TAB_FdVERP_017 dargestellten Aktivitäten Zertifikate.

Tabelle 4 TAB_FdVERP_017 – Zertifikatsnutzung

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

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

Der E-Rezept-Fachdienst stellt neben der TSL eine zweite Lösung bereit, im E-Rezept-FdV einen Vertrauensraum auf Basis eines Root-CA-Zertifikats aufzubauen. Diese Lösung besteht in einer JSON-Struktur, die eine Zertifikatskette (CA-Zertifikate, Cross-Zertifikate) hin zur dem E-Rezept-FdV bekannten Root-CA enthält. Die JSON-Struktur ist einfacher zu verarbeiten. Die Anforderungen und Schritte zum Aufbau dieser vertrauenswürdigen Zertifikatskette finden sich in der Spezifikation [gemSpec_Krypt] in Abschnitt 7.2.2 "Client-seitige Prüfung der E-Rezept-VAU-Identität".

5.1.6.1 Zertifikatsprüfung von Zertifikaten der TI

In der folgenden Anforderung sind die Schritte zum Prüfen eines Zertifikates der TI beschrieben. In den Schritten werden TUC_PKI_* referenziert. Sie dienen als Rahmen für den Ablauf der Prüfschritte. Die TUC_PKI_* sind in dieser Afo nicht normativ umzusetzen.

Für die Prüfung des Online-Status von Zertifikaten der TI wird die Schnittstelle I_OCSP_Status_Information genutzt. Siehe [gemSpec_PKI#9]. Die Schnittstelle wird durch den E-Rezept-Fachdienst angeboten. Siehe auch [gemSpec_FD_eRp#A_20024 - E-Rezept-Fachdienst - Bereitstellung OCSP-Forwarder].

5.1.6.2 Zertifikatsprüfung von Internet-Zertifikaten

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

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

5.1.7 Schnittstellen zu Drittanwendungen

Um dem Versicherten die Möglichkeit zu geben, ein E-Rezept-Token an Vertreter ohne Zugang zum E-Rezept-Fachdienst weitergeben zu können, ist es hilfreich, das E-Rezept-Token über Drittanwendungen mit einem Vertreter zu teilen. Dies setzt auf die etablierten Kommunikationskanäle zwischen Versichertem und seinem Vertreter auf (z.B. Messenger, E-Mail).

Der Export kann bspw. durch das Weiterleiten mittels eines Messenger-Dienstes oder E-Mail erfolgen. Beim Export sind datenschutzrechtliche Anforderungen zu beachten. Näheres hierzu regelt die Rechtsverordnung nach § 360 Abs. 5 PDSG.

5.2 E-Rezept-Anwendungsfälle im FdV

In diesem Kapitel wird die Umsetzung der im systemspezifischen Konzept [gemSysL_eRp] spezifizierten Anwendungsfälle im E-Rezept-FdV beschrieben.

5.2.1 Übersicht der Anwendungsfälle

Tabelle 5 : TAB_FdVERP_003 – Übersicht Anwendungsfälle E-Rezept-FdV

5.2.2 Übergreifende Festlegungen

Das E-Rezept-FdV kann ohne Verbindung zur TI (App-Session ohne TI-Session) oder mit Verbindung zur TI (App-Session mit TI-Session) benutzt werden. Um mit den Diensten der TI zu kommunizieren, muss sich der Versicherte gegenüber der TI authentifizieren.

5.2.3 Anwendungsfälle

5.2.3.1 App-Session starten

User Stories:

• Als Patient möchte ich meine Rezepte-App so absichern können, dass man auch nicht zugreifen kann, wenn das Smartphone entsperrt ist, so dass ich sicher sein kann, dass niemand meine Rezepte lesen oder einlösen kann.
• Als Patient möchte ich festlegen können, mit welchem Verfahren ich meine App absichere, so dass ich die Variante wählen kann, die für mich die beste darstellt. 
• Als Patient möchte ich verstehen, welche Methoden es zur Absicherung gibt und welche Vor- und Nachteile sie haben, so dass ich eine informierte Entscheidung treffen kann.
• Als Patient möchte ich festlegen können, wann die Absicherung greift, so dass ich den Schutz meiner Rezepte meinen individuellen Bedürfnissen anpassen kann.
• Als Patient möchte ich jederzeit die Absicherung meiner App an- und abschalten können, so dass ich frei in meiner Entscheidung bin.
• Als Patient möchte ich entscheiden können, ob ich die App mit oder ohne Anmeldung verwenden möchte, so dass ich selbstbestimmt über die Datenübertragung entscheiden kann.  

Mit diesem Anwendungsfall wird die App-Session im E-Rezept-FdV durch den Nutzer gestartet.

Der Nutzer kann festlegen, ob er das E-Rezept-FdV gegen unbefugten Zugriff sichert oder nicht. Für den Schutz kann er zwischen folgenden Authentisierungsarten wählen:

• mit TI-Authentisierung (, d.h. gegenüber einem Identity Provider der TI)

oder mit geringerem Sicherheitsniveau

• mit individuell festgelegter PIN
• mit hinterlegtem Fingerabdruck
• mit hinterlegter Face-ID

Zur Festlegung einer Authentisierung mit niedrigerem Sicherheitsniveau oder dem Abschalten der Authentisierung für den Zugriffsschutz wird - außer bei der ersten Nutzung des E-Rezept-FdV - eine TI-Authentisierung benötigt. In E-Rezept Stufe 1 erfolgt diese Authentisierung mittels eGK und MRPIN.home.

Die Authentisierung erfolgt gemäß der Aktivität "Authentisierung des Nutzers für Zugriff auf das E-Rezept-FdV".

5.2.3.2 TI-Session starten

User Stories: 

• Als Patient möchte ich, dass mich die App zum richtigen Zeitpunkt dazu auffordert, meine NFC-fähige eGK an das Telefon zu halten, so dass ich den Login-Prozess durchführen kann.
• Als Patient möchte ich, dass mich die App zum richtigen Zeitpunkt dazu auffordert, meine CAN einzugeben, so dass ich den Login-Prozess durchführen kann.
• Als Patient möchte ich, dass die App die Kombination aus Karte und CAN prüft, so dass ich mich einloggen und die App nutzen kann.
• Als Patient möchte ich, dass ich die CAN noch einmal eingeben kann, wenn ich mich vertippt habe, so dass ich die App nutzen kann.
• Als Patient möchte ich, dass mich die App zum richtigen Zeitpunkt dazu auffordert, meine PIN einzugeben, so dass ich den Login-Prozess durchführen kann.
• Als Patient möchte ich, dass die App die Kombination aus Karte und PIN prüft, so dass ich mich einloggen und die App nutzen kann.
• Als Patient möchte ich, dass ich die PIN noch einmal eingeben kann, wenn ich mich vertippt habe, so dass ich die App nutzen kann.

Der Start der TI-Session erfolgt mit der Authentisierung gegenüber der TI. 

Die Authentisierung gegenüber der TI erfolgt

• nach dem Start der App-Session, falls das automatische TI-Login in den Konfigurationseinstellungen aktiviert ist,
• falls für den Aufruf einer Operation an einem Dienst der TI (E-Rezept-Fachdienst ) kein gültiger ACCESS_TOKEN für den Dienst im E-Rezept-FdV vorliegt und
• wenn für die Deaktivierung des Zugriffsschutzes, die TI-Authentisierung genutzt werden soll..

5.2.3.3 App-Session beenden

Mit diesem Anwendungsfall kann der Nutzer die App-Session aktiv beenden. 

Wird die App-Session beendet, wird auch die TI-Session beendet, da der Authentisierungs-Token gelöscht wird.

Die App-Session wird beendet, indem der Nutzer das E-Rezept-FdV aktiv beendet, d.h. die App läuft nicht mehr im Hintergrund weiter. Verliert die App den Fokus und läuft im Hintergrund weiter, wird der vom Nutzer eingestellte Zugriffsschutz aktiviert.

5.2.3.4 TI-Session beenden

User Story:

• Als Nutzer möchte ich, dass ich die Kommunikation zu den Diensten der TI jederzeit selbst beenden kann.

Mit diesem Anwendungsfall kann der Nutzer die TI-Session beenden.

Wird die TI-Session beendet, besteht keine Verbindung mehr zu den Diensten der TI und es können keine Anwendungsfälle durchgeführt werden, für die eine Authentisierung des Nutzers erforderlich ist.

5.2.3.5 E-Rezepte empfangen

User Stories:

• Als Patient möchte ich ein "E-Rezept" auswählen können, das ich herunterladen möchte, so dass ich es später einlösen oder zuweisen kann. 
• Als Patient möchte ich, dass alle für mich verfügbaren "E-Rezepte" automatisch auf mein Gerät heruntergeladen werden, wenn sie dort noch nicht gespeichert sind, so dass ich nicht selbst meine Rezepte herunterladen muss. (eRP_159)
• Als Patient möchte ich, dass meine E-Rezept-App für einen konsistenten Zustand zwischen dem Fachdienst und der App sorgt, so dass ich keine Rezepte doppelt auf meinem Gerät habe oder andere Inkonsistenzen entstehen, so dass ich nicht  verwirrt werde. (eRP_160)
• Als Patient möchte ich, dass der Status meiner Rezepte automatisch von der App aktualisiert wird, wenn er sich im Fachdienst geändert hat, so dass ich immer auf dem neuesten Stand bin und nicht Rezepte einlösen will, die bereits eingelöst sind. (eRP_161)

Mit diesem Anwendungsfall kann sich der Nutzer (Versicherter) die Informationen zu allen seinen auf dem E-Rezept-Fachdienst hinterlegten E-Rezepten in sein E-Rezept-FdV herunterladen und speichern, um sie sich anschließend anzeigen zu lassen.

Standardablauf: E-Rezept herunterladen

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

Falls E-Rezepte auf dem E-Rezept-Fachdienst für den Versicherten abgelegt sind, dann liefert der Response ein Set von Task Ressourcen. Für die Spezifikation der Task Ressource siehe [gemSpec_DM_eRp]. Jeder Task enthält die folgenden fachlichen Informationen:

• Task-ID (Task.id), mit dem der Task bei Aufrufen des E-Rezept-Fachdienstes referenziert wird
• AccessCode (Task.Identifier mit "https://gematik.de/fhir/Namingsystem/accessCode"), welcher für den Zugriff auf das E-Rezept im Fachdienst berechtigt
  
• E-Rezept-Bundle mit den Detailinformationen zum E-Rezept
• signature mit der durch den E-Rezept-Fachdienst erzeugten FHIR-Signatur des E-Rezept-Bundles

Das E-Rezept-FdV kann die FHIR-Signatur des E-Rezept-Bundles prüfen. Hierzu wird das base64-kodierte data Element aus  signature dekodiert. Es enthält eine JSON Web Signature mit Information zum Algorithmus, eine Referenz zum Zertifikat und die signierten Daten. 

Der Ablauf der Prüfung erfolgt in den folgenden Schritten:

1. JSON als String einlesen, Header.Payload.Signatur sind Punktgetrennt, ohne Zeilenumbruch
2. Header Base64 decodieren
3. Header JSON-Syntax prüfen, passen „{„ etc nach JSON-RFC
4. Header prüfen, keine Dubletten-Attribute im Header
5. Header „Schema“ validieren (Implementierung muss Header-Inhalt verstehen)
6. Payload Base64 decodieren
7. Signatur Base64 decodieren
8. Signaturinput = „ASCII(BASE64URL(UTF8(JWS Protected Header))+'.'+BASE64URL(JWS Payload))“ für Prüfung gemäß Signaturverfahren wie im Header angegeben
9. 4-8 ggfs. wiederholen, falls mehrere Signaturen drin sind
10. Feststellung gültig/ungültig

Alternativer Ablauf 1: Ein spezifisches E-Rezept durch Nutzer abrufen

Die Alternative 1 wird genutzt, wenn nur die Informationen zu einem E-Rezept vom E-Rezept-Fachdienst heruntergeladen werden sollen, bspw. um zu prüfen, ob sich der Status geändert hat. Dafür muss die Task-ID dieses Rezepts im E-Rezept-FdV bekannt sein.

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

Der Response beinhaltet die Task Ressource des E-Rezepts.

Alternativer Ablauf 2: Ein spezifisches E-Rezept mit AccessCode abrufen

Die Alternative 2 wird genutzt, wenn der Nutzer als Vertreter eines Versicherten ein E-Rezept vom E-Rezept-Fachdienst herunterladen möchte. Dafür müssen die Task-ID und der AccessCode dieses Rezepts im E-Rezept-FdV bekannt sein. Die Informationen Task-ID und AccessCode werden im E-Rezept-Token übermittelt.

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

Der Response beinhaltet die Task Ressource des E-Rezepts.

5.2.3.6 E-Rezept anzeigen

User Stories:

• Als Patient möchte ich alle E-Rezepte, die für mich verfügbar sind, sehen können, so dass ich entscheiden kann, was ich mit diesen E-Rezepten machen will.
• Als Patient möchte ich sehen können, welchen Status ein E-Rezept hat, so dass ich in der Lage bin, den nächsten Schritt entscheiden zu können.
• Als Patient möchte ich die relevanten Informationen aus einem E-Rezept lesen können, so dass ich weiß, was mir verschrieben wurde.

Mit diesem Anwendungsfall kann sich der Nutzer alle im E-Rezept-FdV gespeicherten E-Rezepte anzeigen lassen.

5.2.3.7 2D-Code einscannen

User Story:

• Als Versicherter (Vertreter) möchte ich einen erhaltenen 2D-Code eines E-Rezepts einscannen können, um das E-Rezept in einer Apotheke einlösen zu können. 
• Als Patient möchte ich, dass das Einscannen von 2D-Codes funktioniert, wenn es ausgedruckt vorliegt und wenn es am Bildschirm dargestellt wird, so dass der Prozess für mich einfach ist und immer funktioniert." (eRP_44)
• Als Patient möchte ich in der Lage sein, einen 2D-Code einscannen zu können, ohne dass ich mich mit eGK und PIN anmelden muss (anonymer Modus), so dass ich volle Kontrolle über meine Daten habe. (eRP_103)

Mit diesem Anwendungsfall kann der Vertreter einen 2D-Code, der ihm vom Versicherten zur Verfügung gestellt wurde, einscannen und die Daten zum E-Rezept in seinem E-Rezept-FdV speichern.

Der 2D-Code ist im Dokument [gemSpec_DM_eRp] spezifiziert.

5.2.3.8 E-Rezepte in E-Rezept-Fachdienst löschen

User Stories:

• Als Patient möchte ich ein E-Rezept auswählen können, das ich löschen will, so dass ich mein Recht auf informationelle Selbstbestimmung ausüben kann.
• Als Patient möchte ich die ausgewählten E-Rezepte löschen können, so dass ich mein Recht auf informationelle Selbstbestimmung ausüben kann.
• Als Patient möchte ich Rückmeldung darüber erhalten, wenn die ausgewählten E-Rezepte gelöscht worden sind, so dass ich sicher sein kann, dass die Daten auch wirklich nicht mehr vorliegen.
• Als Patient möchte ich Rückmeldung darüber erhalten, wenn das Löschen fehlgeschlagen ist, so dass ich auf anderem Wege ein Löschen einleiten kann.

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) einzelne ausgewählte oder alle E-Rezepte, die auf dem E-Rezept-Fachdienst gespeichert sind, löschen.

Das E-Rezept-FdV kann es dem Nutzer ermöglichen, den Anwendungsfall zum lokalen Löschen für die zu löschenden E-Rezepte zusammen mit dem Löschen auf dem E-Rezept-Fachdienst auszuführen.

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

5.2.3.9 E-Rezepte lokal im E-Rezept-FdV löschen

User Stories:

• Als Patient möchte ich eigenständig E-Rezepte aus meinem E-Rezept-FdV löschen können, um die Übersichtlichkeit in der Ansicht zu erhöhen.
• Als Patient möchte ich nicht mehr benötigte E-Rezepte mit zugehörigen Informationen oder Nachrichten aus der Ansicht meines E-Rezept-FdV löschen können.

Mit diesem Anwendungsfall kann der Nutzer die lokal in seinem E-Rezept-FdV gespeicherten E-Rezepte mit allen dazugehörigen Informationen löschen.

Hinweis: Lokal gelöschte E-Rezepte werden nach einem erneuten Abruf von E-Rezepten vom E-Rezept-Fachdienst wieder im E-Rezept-FdV angezeigt.

5.2.3.10 Anfrage zur Belieferung von E-Rezepten bei einer Apotheke

User Stories:

• Als Patient möchte ich bei einer Apotheke anfragen können, ob alle Medikamente, die auf den E-Rezepten stehen, die ich einlösen will, vorrätig sind, bevor ich die Rezepte einlösen gehe oder sie der Apotheke zuweise, so dass ich keine unnötigen Wege gehen muss.
• Als Patient möchte ich in der Lage sein, die E-Rezepte auszuwählen, für die ich eine Anfrage zur Belieferung durch eine Apotheke bei einer Apotheke stelle, so dass ich selbst kontrollieren kann, was an welche Apotheke geht, und ich meine Wege optimieren kann.
• Als Patient möchte ich, dass die App mich bei der Formulierung einer Anfrage zur Belieferung durch eine Apotheke weitgehend unterstützt und mir die Anfrage quasi vorformuliert, so dass ich nicht viel tippen muss, wenn ich diese Anfrage stelle.
• Als Patient möchte ich in der Lage sein, in die Anfrage zur Belieferung durch eine Apotheke zusätzliche Informationen in Form von Freitext aufzunehmen, so dass ich bspw. zusätzlich zu den verschriebenen Medikamenten auch rezeptfreie Medikamente oder Hilfsmittel (Bsp. Teststreifen) anfragen kann und alles in einem Aufwasch erledigen kann.
• Als Patient möchte ich meine fertige Anfrage zur Belieferung durch eine Apotheke verschicken können, so dass die von mir ausgewählte Apotheke reagieren kann.
• Als Patient möchte ich Rückmeldung darüber erhalten, ob meine Anfrage zur Belieferung durch eine Apotheke verschickt worden ist, so dass ich weiß, was als nächstes passieren wird.
• Als Patient möchte ich auf Nachrichten Antworten formulieren können, so dass ich Rückfragen stellen kann.
• Als Patient möchte ich Antworten, die ich bereits formuliert habe, an den Apotheker tatsächlich versenden können, so dass meine Rückfragen auch ankommen.  

Mit diesem Anwendungsfall kann der Nutzer Nachrichten an eine ausgewählte Apotheke senden, um

• die Verfügbarkeit des im E-Rezept verordneten Mittels anzufragen
• auf eine Nachricht der Apotheke zum E-Rezept zu antworten, um z.B. Rückfragen zu stellen.

Der Nutzer wählt hierbei, ob die Auswahl mit dem Anwendungsfall "Apotheke suchen" erfolgen soll oder ob eine zuvor in der Konfiguration als Stammapotheke hinterlegte Apotheke verwendet werden soll.

Hinweis: Die Textnachricht ist optional. Die Informationen zum E-Rezept werden automatisch erzeugt.

Innerhalb der Textnachricht sind keine Internet-Links und keine Non-Printable-Characters zulässig.

Die Information zum verordneten Mittel wird aus dem heruntergeladenen und gespeicherten E-Rezept ermittelt. Der abgebenden LEI wird das Medication-Objekt aus dem E-Rezept-Bundle übermittelt.

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

Für weitere Informationen siehe Operation "Nachricht als Versicherter an eine Apotheke schicken" aus der API-Schnittstelle [E-Rezept API Dokumentation].

5.2.3.11 E-Rezept einer Apotheke über die TI zuweisen

User Stories:

• Als Patient möchte ich in der Lage sein, die E-Rezepte auszuwählen, die ich einer Apotheke zuweisen möchte, so dass diese mich beliefern kann oder ich die Medikamente dort abholen kann.
• Als Patient möchte ich in der Lage sein, "E-Rezepte" Apotheken zuweisen zu können, so dass diese Apotheke mich beliefern kann oder ich meine Medikamente dort abholen kann.
• Als Patient möchte ich Rückmeldung darüber erhalten, ob meine Zuweisung erfolgreich war, so dass ich weiß, was als nächstes passieren wird.
• Als Patient möchte ich mein "E-Rezept" an eine von mir ausgewählte Apotheke elektronisch übermitteln können, so dass ich dort meine Medikamente abholen kann.

Mit diesem Anwendungsfall kann der Nutzer (Versicherter oder Vertreter) über sein E-Rezept-Frontend einer vorher ausgewählten Apotheke ein E-Rezept zur Einlösung zuweisen.

Der Nutzer wählt hierbei, ob die Auswahl mit dem Anwendungsfall "Apotheke suchen" erfolgen soll oder ob eine zuvor in der Konfiguration als Stammapotheke hinterlegte Apotheke verwendet werden soll.

Hinweis: Die Textnachricht ist optional.

Innerhalb der Textnachricht sind keine Internet-Links und keine  Non-Printable-Characters zulässig.

Für das Zuweisen eines E-Rezepts an eine Apotheke wird der zum E-Rezept zugehörige E-Rezept-Token an die Apotheke übermittelt. Für die Spezifikation des E-Rezept-Token siehe [gemSpec_DM_eRp].

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

Für weitere Informationen siehe Operation "Anwendungsfall Ein E-Rezept verbindlich einer Apotheke zuweisen" aus der API-Schnittstelle [E-Rezept API Dokumentation].

Empfängt das E-Rezept-FdV eine Antwort einer Apotheke auf einen verbindlichen Einlöseauftrag, kann die Apotheke einen Warenkorb in ihrer Bestellplattform bereits vorbefüllt haben. Zur Nutzung und Weiterbearbeitung des Warenkorbs (Versandadresse, ggfs. Zuzahlung) kann die Apotheke eine externe URL auf ihre Bestellplattform in einer Nachricht an den Versicherten dem E-Rezept-FdV übergeben. 

5.2.3.12 Vertreterkommunikation

User Stories:

• Als Patient möchte ich in der Lage sein, ein E-Rezept auszuwählen, um einen Vertreter zu berechtigen, so dass dieser das E-Rezept für mich einlösen kann.
• Als Patient möchte ich mein E-Rezept an einen Versicherten versenden, so dass dieser das E-Rezept als mein Vertreter einlösen kann.
• Als Vertreter eines Patienten möchte ich auf eine Nachricht im Zusammenhang mit einem einzulösenden E-Rezept antworten können.

Mit diesem Anwendungsfall kann der Nutzer (Versicherter oder Vertreter) über sein E-Rezept-Frontend Nachrichten zur Vertretung beim Einlösen eines E-Rezepts mit einem anderen Versicherten austauschen.

Die Adressierung der Nachricht erfolgt auf Basis der KVNR des Empfängers.

Das Erfassen der KVNR eines Vertreters kann über eine Texterkennung durch Abscannen dessen eGK, manuelle Eingabe, durch Übernahme aus einer lokalen Vertreterliste oder auch durch die Übernahme aus einer vorherigen Kommunikation erfolgen.

Hinweis: Die Textnachricht ist optional.

Innerhalb der Textnachricht sind keine Internet-Links und keine  Non-Printable-Characters zulässig, siehe auch A_20011.  

In der Vertreterkommunikation wird der zum E-Rezept zugehörige E-Rezept-Token an den Vertreter übermittelt. Für die Spezifikation des E-Rezept-Token siehe [gemSpec_DM_eRp].

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

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

5.2.3.13 E-Rezept-Token als 2D-Code anzeigen

User Stories:

• Als Patient möchte ich in der Lage sein, mit meiner App E-Rezepte spontan in einer Apotheke einlösen zu können, ohne diese vorher dieser Apotheke über die TI zuweisen zu müssen, so dass ich ganz flexibel sein und meine Medikamente immer erhalten kann.
• Als Patient möchte ich ohne Verbindung zur TI mithilfe eines gespeicherten Tokens ein E-Rezept in der Apotheke einlösen können, so dass ich meine Medikamente erhalten kann.
• Als Patient möchte ich ein E-Rezept in meiner App haben, das ich einer dritten Person geben kann, so dass diese Person für mich das Rezept in der Apotheke einlösen kann.

Mit diesem Anwendungsfall kann der Nutzer seine Rezeptinformationen als 2D-Code auf dem Bildschirm seines E-Rezept-FdVs anzeigen lassen, um das E-Rezept direkt in der Apotheke einlösen oder die Informationen an einen Vertreter weitergeben zu können.

Für die Beschreibung der Struktur des E-Rezept-Token siehe [gemSpec_DM_eRp].

Ein 2D-Code kann bis zu 3 E-Rezept-Token beinhalten. Sollen mehr E-Rezept-Token übermittelt werden, können bspw. mehrere 2D-Codes erzeugt und angezeigt werden.

Für die Beschreibung des 2D-Codes siehe [gemSpec_DM_eRp].

5.2.3.14 Apotheke suchen

User Stories:

• Als Patient möchte ich Vorort-Apotheken und Versandapotheken in der Apothekensuche finden können, so dass ich die Wahl habe, ob ich mich beliefern lassen will oder selbst die Medikamente abhole.
• Als Patient möchte ich in einem Verzeichnis aller Apotheken eine Apotheke auswählen können, der ich E-Rezepte zuweisen kann, so dass ich dieser Apotheke diese E-Rezepte übermitteln kann. 
• Als Patient möchte ich die Ortungsfunktion meines Geräts nutzen können, um nahe gelegene Apotheken finden zu können, so dass ich spontan die für mich bestgelegene Apotheke finden kann.
• Als Patient möchte ich nach Apotheken suchen können, denen ich die Anfrage zur Belieferung meiner Verordnung schicken will, so dass ich überhaupt in die Kommunikation mit einer Apotheke eintreten kann.
• Als Patient möchte ich aus den Suchergebnissen Apotheken auswählen können, an die ich eine Anfrage zur Belieferung durch eine Apotheke stellen möchte, so dass meine Anfrage dort auch landen kann. 

Mit diesem Anwendungsfall kann sich der Nutzer (Versicherter und Vertreter) aus einem Verzeichnis aller Apotheken seine bevorzugte Einlöse-Apotheke heraussuchen und zur Übermittlung des E-Rezeptes auswählen. Er kann häufig verwendete Apotheken zur Einlösung als Stamm-Apotheke (Favorit) festlegen.

Für weitere Informationen siehe "Eine Apotheke aus dem Apotheken-Verzeichnis auswählen" in der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response liefert ein Bundle von Organisation Ressourcen. Für eine Beschreibung der FHIR-Ressource Organisation siehe [gemSpec_DM_eRp].

Das E-Rezept-FdV unterstützt das Festlegen von mindestens fünf Apotheken als Stammapotheke.

5.2.3.15 Nachrichten von Apotheke anzeigen

User Stories:

• Als Patient möchte ich, dass ich Nachrichten meiner Apotheke lesen kann.

Mit diesem Anwendungsfall kann der Nutzer (Versicherter und Vertreter) Nachrichten von der Apotheke empfangen und anzeigen lassen. 

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

Der Response liefert ein Bundle mit Communication Ressourcen.

Eine Communication Ressource beinhaltet die fachlichen Informationen:

• Absender-ID (Versicherten-ID)
• Mitteilung

5.2.3.16 Nachrichten löschen

User Stories:

• Als Patient möchte ich die Möglichkeit haben, Nachrichten, welche ich zuvor an eine Apotheke oder an einen anderen Versicherten gesandt habe, zu löschen..

Mit diesem Anwendungsfall kann der Nutzer von ihm zuvor versandte Nachrichten auf dem E-Rezept-Fachdienst löschen. 

Wenn die Nachricht bereits vom Empfänger abgerufen wurde, dann wird im Response des E-Rezept-Fachdienstes im HTTP-Header eine Warnung mit dem Zeitpunkt des Abrufes übermittelt.

5.2.3.17 Abgabeinformationen anzeigen

User Story:

• Als Patient möchte ich sehen können, welche Informationen zur Abgabe an mich übermittelt wurden, so dass ich besser über meine Therapie informiert bin.
• Als Patient möchte ich, dass alle Informationen zur Abgabe auch verfügbar sind, wenn ich gerade kein Internet habe, so dass ich jedrzeit darauf zugreifen kann, auch wenn ich beim Arzt gerade kein Internet habe.

Wenn die abgebende LEI ein E-Rezept beliefert, dann kann sie dem Versicherten Informationen zur Abgabe auf dem E-Rezept-Fachdienst einstellen. Das ist bspw. relevant, wenn ein Arzneimittel substituiert wird.

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) Informationen zur Abgabe auf sein E-Rezept-FdV herunterladen und anzeigen lassen.

Für weitere Informationen siehe "Abgabeinformationen abrufen" in der API-Schnittstelle [E-Rezept API Dokumentation].

Falls auf dem E-Rezept-Fachdienst Informationen zur Abgabe durch die abgebende LEI hinterlegt wurden, liefert der Response ein MedicationDispense Ressource. Zur Spezifikation der MedicationDispense Ressource siehe [gemSpec_DM_eRp]. Diese beinhaltet u.a. die folgenden fachlichen Informationen zum abgegebenen Arzneimittel:

• Pharmazentralnummer
• Beschreibung des Arzneimittels

5.2.3.18 Protokolldaten anzeigen

User Story:

• Als Versicherter möchte ich alle Datenzugriffe auf meine Daten einsehen können, um Änderungen und Zugriffe nachvollziehen zu können.
• Als Versicherter möchte ich, dass Protokolle so dargestellt werden, dass ich mit den Informationen auch was anfangen kann, so dass die Protokolleinträge für mich nicht nutzlos oder sogar verwirrend sind.

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) Einsicht in alle protokollierten Zugriffe in Verbindung mit seinen E-Rezepten nehmen.

Für weitere Informationen siehe "Eingriff in das Zugriffsprotokoll" in der API-Schnittstelle [E-Rezept API Dokumentation].

Der Response beinhaltet ein Bundle mit einem searchset von AuditEvent Ressourcen. Eine AuditEvent Ressource beinhaltet die folgenden Informationen (Siehe auch [ ]):

• ID des Datenobjektes, auf das zugegriffen wurde (AuditEvent.entity.what) Das entspricht der Task-ID oder MedicationDispense-ID
• Rezept-ID (AuditEvent.entity.description)
• lesbarer Beschreibung in einfacher Sprache (AuditEvent.text)
• Name des Zugreifenden (AuditEvent.agent.who)
• Zeitpunkt des Zugriffs (AuditEvent.recorded)
• Ergebnis der aufgerufenen Operation (AuditEvent.outcome)

Das E-Rezept-FdV kann es dem Nutzer über einen Link in der Anzeige ermöglichen, die Details zum referenzierten E-Rezept anzuzeigen.

Die Protokolldaten sollen für den Nutzer sortierbar und filterbar über die Angabe von Filterkriterien wie z.B. Zeitraum, dargestellt werden.

5.2.4 Fehlerbehandlung

Tritt ein Fehler bei der Verarbeitung von Operationsaufrufen des E-Rezept-Fachdienstes auf, dann antwortet der E-Rezept-Fachdienst mit einer Fehlermeldung. Das Format und die verwendeten Fehlercodes sind in den Spezifikationen der Interfaces beschrieben. Weiterhin können Fehler in der lokalen Verarbeitung auftreten.

Das E-Rezept-FdV soll dem Nutzer nach einem Abbruch eine verständliche Fehlermeldung anzeigen.

Wenn die Möglichkeit besteht, dass der Nutzer das fehlerverursachende Problem selbst beheben kann, kann das E-Rezept-FdV den Nutzer auf die Lösung hinweisen.

6 Informationsmodell

Dienste der TI:

Session-Daten (TI-Session) 

E-Rezept:

Weitere detaillierte Daten zum Informationsmodell der Verordnung sind im Datenmodell der KBV https://simplifier.net/erezept/kbvprerpbundle enthalten. Siehe [gemSpec_DM_eRp].

MedicationDispense

Protokolleintrag

Apotheke

Anfrage Belieferung durch eine Apotheke:

Einlöseauftrag:

Vertreterkommunikation:

7 Verteilungssicht

Eine Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

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

8.5.2 Weitere Dokumente