Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

E-Rezept-Frontend des Versicherten

    

     

      
Version
      
2.2.0
     
     

      
Revision
      
989834
     
     

      
Stand
      
13.09.2024
     
     

      
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 an den Hersteller 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. Die konkrete Ausgestaltung wird nicht normativ vorgegeben.

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.

1.6 Fachliche und technische Konzepte

Die den in diesem Dokument beschriebenen Anwendungsfälle liegen folgende fachliche und technische Konzepte für ärztliche und zahnärztliche Verordnungen für apothekenpflichtige Arzneimittel zugrunde:

Tabelle 1 : TAB_FdVERP_018 – Fachliche und technische Konzepte

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, Huawei EMUI 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 2 : TAB_FdVERP_028 – Akteure und Rollen

3.2 Nachbarsysteme

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

• Identity Provider (IDP-Dienst)
• E-Rezept-Fachdienst
• Verzeichnisdienst
• falls nicht im E-Rezept-FdV integriert: Authenticator-Modul
• falls Authenticator-Modul im E-Rezept-FdV integriert und Authentisierung mittels eGK unterstützt: eGK

Abbildung 1 : ABB_FDVERP_001 Systemüberblick E-Rezept-FdV

Identity Provider

Der Identity Provider (IDP-Dienst) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen anbietet. Der IDP-Dienst agiert als Authorization-Server, im Sinne von OAuth2 (rfc6749), für den E-Rezept-Fachdienst. Er kann sowohl selbst Authentisierungen, basierend auf der eGK oder eines mit der eGK verknüpften Geräteschlüssels, durchführen als auch den Nutzer zur Authentisierung an einen sektoralen Identity Provider weiterleiten, welcher gegenüber dem IDP-Dienst sicher die Identitätsmerkmale des Nutzers bestätigt.

Authenticator-Modul

Das Authenticator-Modul ist eine logische Komponente im E-Rezept-FdV oder in einer separaten App. Das Authenticator-Modul kapselt funktionale Anteile des Authentifizierungsprozesses gegenüber dem IDP-Dienst und ggf. die Kommunikation mit der Smartcard des Nutzers.

Für die Authentisierung mittels eGK greift das Authenticator-Modul 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 für die Nutzung dieser Funktionalität 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

Für das E-Rezept-FdV ist die Prüfvorschrift für den Produktgutachter des „ePA-Frontend des Versicherten“ und des „E-Rezept-Frontend des Versicherten“ des BSI [BSI PVePAeRp] einzuhalten.

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

4.1.1 Allgemeine Anforderungen

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.

4.1.2 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.3 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.4 Tracking

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

Im Folgenden wird unter Tracking Usability-Tracking sowie Crash-Reporting verstanden.

4.1.4.1 Allgemeine Anforderungen zum Tracking

Hinweis: Sicherheitsmerkmale sind z.B. die Gerätekennung (DeviceID) und Session-Daten, geheime oder private Schlüssel, Authentifizierungs- oder Autorisierungsbestätigungen.

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

4.1.4.2 Anforderungen zur Einwilligung zum Session-übergreifenden Tracking

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

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 Session-übergreifenden-Tracking. Leicht zugängliche Form bedeutet direkt im FdV.

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

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

Für das Deaktivieren von gerätespezifischen Funktionalitäten kann der Nutzer die Funktionalitäten des Betriebssystems nutzen.

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 5.2.5 Fehlerbehandlung.

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

5 Funktionsmerkmale

5.1 Allgemein

5.1.1 Session-Verwaltung

Eine Nutzer-Session bezeichnet die Nutzung des E-Rezept-FdV vom Start der App bis zum Beenden der App. Eine Authentisierung des Nutzers gegenüber der TI nach dem Start der Nutzer-Session erfolgt nicht automatisch, sondern nach Bedarf.

Das E-Rezept-FdV muss den Zugriffsschutz der App aktivieren, wenn diese nicht mehr im Fokus ist und sich im Hintergrund befindet. Das Aktivieren des Zugriffsschutz beendet die Nutzer-Session nicht.

Die Inaktivität bezieht sich hierbei auf die Nutzeraktivität in der gesamten App.

Eine E-Rezept-Fachdienst-Session bezeichnet den Zeitraum von der Authentisierung gegenüber dem E-Rezept-Fachdienst bis zum Ablauf der Authentisierung.

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, dem IDP-Dienst in seiner Rolle als Authorization-Server und dem Verzeichnisdienst.

Für die URLs der Schnittstellen siehe [gemSpec_FD_eRP#A_21782-*].

Die Informationen zu den Endpunkten des IDP-Dienstes 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 die Informationen zu den Endpunkten des FHIR-VZD TI siehe [gemSpec_VZD_FHIR_Directory#FHIR Schnittstelle für Versicherte FHIRDirectoryPatientSearchAPI].

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

5.1.3.1 Authentisierung des Nutzers für Zugriff auf den E-Rezept-Fachdienst

Der Nutzer des E-Rezept-FdV muss sich für Zugriffe auf den E-Rezept-Fachdienst gegenüber der TI authentifizieren.

Die Authentisierung kann gegenüber dem IDP-Dienst mittels eGK unter Kenntnis der PIN der eGK oder mit der GesundheitsID, d.h. Nutzerauthentisierung gegenüber dem sektoralen IDP, erfolgen.

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

Das E-Rezept-FdV erhält bei erfolgreicher Authentisierung einen Authentisierungstoken (ACCESS_TOKEN), welcher an den E-Rezept-Fachdienst weitergeleitet wird.

5.1.3.2 Authentisierung des Nutzers für Zugriff auf den FHIR-VZD

Der Ablauf der Authentisierung gegenüber dem FHIR-VZD TI ist in [gemSpec_VZD_FHIR_Directory#Versicherter sucht Einträge im FHIR-Directory] beschrieben.

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

Mit dieser Authentifizierung ist die lokale Authentifizierung am E-Rezept-FdV auf dem Gerät des Versicherten (und nicht die Anmeldung an Backendsystemen (z.B. E-Rezept-Fachdienst)) gemeint.

Bei erfolgreicher Authentisierung kann der Nutzer auf die Funktionen des E-Rezept-FdV zugreifen.

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 [gemSpec_Krypt#3.16 E-Rezept-spezifische Vorgaben (informativ)] und [gemSpec_Krypt#7 Kommunikationsprotokoll zwischen E-Rezept-VAU und E-Rezept-Clients] .

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 obigen Sinne, 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 obigen Sinne 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

Die Prüfung von Zertifikaten der TI erfolgt gemäß [gemSpec_Krypt#6.2.2 Client-seitige Prüfung der E-Rezept-VAU-Identität].

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

Alle Anwendungsfälle werden durch das E-Rezept-FdV der gematik implementiert.

5.2.2 Übergreifende Festlegungen

Das E-Rezept-FdV kann ohne Verbindung zur TI (Nutzer-Session ohne E-Rezept-Fachdienst-Session) oder mit Verbindung zur TI (Nutzer-Session mit E-Rezept-Fachdienst-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 Nutzer-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.

Der Nutzer muss sich beim Start des E-Rezept-FdV, ausser bei der Initialisierung des E-Rezept-FdV, gegenüber dem E-Rezept-FdV authentisieren. Siehe auch  5.1.4 Authentisierung des Nutzers für Zugriff auf das E-Rezept-FdV .

Verliert die App den Fokus und läuft im Hintergrund weiter, wird der vom Nutzer eingestellte Zugriffsschutz aktiviert.

5.2.3.2 E-Rezept-Fachdienst-Session starten

User Stories:

• Als Patient möchte ich verstehen, welche Methoden die App für das Login am E-Rezept-Fachdienst unterstützt.
• Als Patient möchte ich, falls eine eGK für die Authentifizierung genutzt wird, 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, falls eine eGK für die Authentifizierung genutzt wird, 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, falls eine eGK für die Authentifizierung genutzt wird, dass ich die CAN noch einmal eingeben kann, wenn ich mich vertippt habe, so dass ich die App nutzen kann.

Der Start der E-Rezept-Fachdienst-Session erfolgt mit der Authentisierung gegenüber dem E-Rezept-Fachdienst. 

Siehe 5.1.3 Authentisierung des Nutzers für Dienste der TI .

5.2.3.3 Nutzer-Session beenden

Wird die Nutzer-Session beendet, wird auch die E-Rezept-Fachdienst-Session beendet..

Die Nutzer-Session wird beendet, indem der Nutzer das E-Rezept-FdV aktiv beendet, d.h. die App läuft nicht mehr im Hintergrund weiter.

5.2.3.4 E-Rezept-Fachdienst-Session beenden

5.2.3.5 E-Rezepte abrufen

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)
• 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 (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: Liste von 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/erp/StructureDefinition/GEM_ERP_PR_AccessCode"), welcher für den Zugriff auf das E-Rezept im Fachdienst berechtigt
  
• E-Rezept-Bundle mit den Detailinformationen zum E-Rezept

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 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.7 E-Rezept 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.

Die Information soll insbesondere die Unterschiede bei nicht eingelösten und eingelösten E-Rezepten beinhalten.

Für das Löschen von E-Rezepten des Workflow-Typ "200" und "209" ist der Nutzer zu informieren, dass nach Löschen des E-Rezeptes nicht mehr die Möglichkeit besteht, dass die abgebende LEI (Apotheke) die Abrechnungsinformation zum E-Rezept für den PKV-Versicherten über das E-Rezept-FdV bereitstellt.

Das E-Rezept-FdV kann es dem Nutzer ermöglichen, den Anwendungsfall zum lokalen Löschen für das zu löschende E-Rezept 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.8 E-Rezept 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.

Zu den verknüpften Daten gehören beispielweise die Nachrichten und Protokolleinträge.

5.2.3.9 Anfrage zur Belieferung von E-Rezepten bei einer Apotheke

Dieser Anwendungsfall ist noch nicht im E-Rezept-FdV der gematik implementiert. Wenn die Absprachen mit den AVS-Hersteller hierzu finalisiert sind, ist geplant die UX Guideline für AVS in [gemILF_PS_eRp] für diesen Anwendungsfall zu erweitern.

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.

Die Auswahl kann bspw. mit dem Anwendungsfall "Apotheke suchen" erfolgen.

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.10 E-Rezept 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.

Die Auswahl kann mit dem Anwendungsfall "Apotheke suchen" erfolgen.

Hinweis: Die Textnachricht ist optional.

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

Die Auswahl kann mit dem Anwendungsfall "Kostenträger suchen" erfolgen.

Beim Zuweisen einer DiGA-Verordnung ist keine frei Textnachricht vorgesehen, um eine maschinelle Verarbeitung zur Bereitstellung des Freischaltcodes zu ermöglichen.

Für das Zuweisen eines E-Rezepts wird der zum E-Rezept zugehörige E-Rezept-Token ü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].

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

Das E-Rezept-FdV kann die Anzeige eines 2D-Codes auf dem Display des Geräts des Versicherten mit einem hohen Kontrast (dunkle Farbe auf hellem Hintergrund) darstellen, damit Lesegeräte den 2D-Code zuverlässig erkennen können.

Das E-Rezept-FdV kann die Anzeige eines 2D-Codes auf dem Display des Geräts des Versicherten mit einem Ruhebereich von weißer Farbe von mindestens doppelter Breite eines Punktes des 2D-Codes darstellen, damit Lesegeräte den 2D-Code zuverlässig von sonstigen Informationen auf dem Display unterscheiden können.

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

Die Anfrage zur Suche von Apotheken, richtet sich an den FHIR-Directory des Verzeichnisdienstes der TI (FHIR-VZD TI).

Der Ablauf der Authentisierung und Suche ist in [gemSpec_VZD_FHIR_Directory#Versicherter sucht Einträge im FHIR-Directory] beschrieben.

Für weitere Informationen siehe Anwendungsfall "Suche nach Apotheken im FHIR VZD" aus der API-Schnittstelle [E-Rezept API Dokumentation].

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

5.2.3.14 Kostenträger suchen

User Stories:

Als Patient möchte ich, ...

• ... dass ich meine mir ausgestellte DiGA Verordnung meinem Kostenträger/ meiner Krankenkasse zugewiesen werden kann, damit ich einen Freischaltcode erhalte.
• ... dass die richtige Zieladresse der Zuweisung automatisch gefunden wird.
• ... dass wenn die Zieladresse nicht automatisch ermittelt werden kann, ich meine Krankenkasse manuell auswählen kann.

Mit diesem Anwendungsfall soll ermöglicht werden, dass ein Nutzer eines E-Rezept-FdV möglich ist, eine DiGA Verordnung an den korrekten Kostenträger zuzuweisen. Soweit möglich, kann die Telematik-ID des Kostenträgers für den Versicherten im E-Rezept-FdV fest vorgegeben werden. In diesem Fall müssen die Anforderungen zu diesem Anwendungsfall nicht umgesetzt werden.

Wenn die Telematik-ID des KTR des Versicherten nicht im Programmcode hinterlegt wird, muss diese zur Laufzeit bestimmt werden. Hierfür nutzt das E-Rezept-FdV das IKNR des KTR, wodurch es dann in der Lage ist nach der Telematik-ID im FHIRVZD zu suchen.

Als Antwort erhält das E-Rezept-FdV ein Suchset mit mindestens 2 Ressourcen: eine oder mehrere HealthcareServices und genau eine Organization Ressource. Die Organization Ressource enthält dann einen identifier mit identifier.type == "PRN". Dieser identifier enthält die Telematik-ID unter identifier.value.

Falls das E-Rezept-FdV nicht in der Lage ist die IKNR oder die Telematik-ID des Kostenträgers des Nutzers zu ermitteln, soll der Nutzer die Möglichkeit haben den Kostenträger manuell zu bestimmen.

Der Nutzer soll eine Liste aller Kostenträger, denen eine DiGA zugewiesen werden kann, zur Auswahl angezeigt bekommen.

Als Antwort erhält das E-Rezept-FdV ein Suchset mit mehreren HealthcareServices und mehreren Organizations. Dem Nutzer ist dann eine Liste der Organizations anzuzeigen und zu verarbeiten:

• Organization.name enthält den Namen der Krankenkasse
• Organzation.identifier:Telematik-ID enthält die Telematik-ID an die die Communication gesendet werden muss

5.2.3.15 Nachrichten anzeigen

User Stories:

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

Mit diesem Anwendungsfall kann der Nutzer (Versicherter und Vertreter) Nachrichten 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

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

Das Löschen der Nachrichten kann alternativ zusammen mit dem Löschen des E-Rezepts umgesetzt werden.

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

Hinweis: Die Möglichkeit des Einstellens von Abgabeinformationen vor dem Abschluss des Workflows ist noch nicht umgesetzt. Insbesondere ist hierfür noch eine FHIR-Profilanpassung für das Einführen von Task.extension:lastMedicationDispense notwendig.

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 jederzeit darauf zugreifen kann, auch wenn ich beim Arzt gerade kein Internet habe.

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

Die abgebende LEI stellt die Abgabeinformationen entweder vor dem Abschluss oder beim Abschluss des Workflows zum E-Rezept ein.

Werden die Abgabeinformationen vor dem Abschluss der Workflows eingestellt, dann ändert sich der Status des Workflows nicht (Task.status=in-progress). Im Task ist der Zeitpunkt des Einstellens unter Task.extension:lastMedicationDispense gespeichert. Solange der Workflow nicht abgeschlossen ist, können die Abgabeinformationen gelöscht oder geändert werden. Hierbei wird der Zeitpunkt des Einstellens jeweils gelöscht bzw. neu gesetzt.

Mit dem Abschluss des Workflows ist Task.status=complete. Ein Ändern der Abgabeinformationen ist danach nicht mehr möglich.

Hinweis: Die Information, dass eine Abgabeinformation eingestellt wurde (Task.status = "in-progress" und Task.extension:lastMedicationDispense existiert) kann dafür genutzt werden den Status des E-Rezepts als Abgegeben darzustellen.

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

Der Abruf mehrerer MedicationDispense-Objekte über GET /MedicationDispense und die Suche auf Basis der MedicationDispense-Suchparameter (?identifier=https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_PrescriptionId|<PrescriptionID>) liefert ein FHIR-Bundle von MedicationDispense-Objekten. Wurde die Verordnung eines Medikaments mit mehreren Medikamenten beliefert (z.B. 2*50 Tabletten, weil 100er-Packung nicht verfügbar ist), so liefert die Abfrage GET /MedicationDispense/<id> (mit <id> ggfs. <prescriptionID>) die erste MedicationDispense und die Abfrage über Suchparameter ein Bundle mehrerer MedicationDispense-Objekten (sofern mehrere eingestellt wurden).  

Supportinformationen zu DiGA-Apps sind im BfArM-Verzeichnis verfügbar.

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 [gemSpec_DM_eRp#A_19296-* - E-Rezept-Fachdienst - Inhalt Protokolleintrag ]):

• 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.3.19 Einwilligungen

5.2.3.19.1 Einwilligung zum Speichern der Abrechnungsinformationen erteilen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilen und die Information auf dem E-Rezept-Fachdienst speichern.

5.2.3.19.2 Einwilligungsinformation abrufen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Information, ob eine Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst erteilt wurde, vom E-Rezept-Fachdienst abrufen.

Im Response können mehrere Consent Ressourcen enthalten sein. Die Einwilligung zum Speichern der Abrechnungsinformationen liegt vor, wenn eine Consent mit Consent.category.coding.code = CHARGCONS übermittelt wurde.

5.2.3.19.3 Einwilligung zum Speichern der Abrechnungsinformationen widerrufen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Einwilligung zum Speichern von Abrechnungsinformationen auf dem E-Rezept-Fachdienst widerrufen und die Information zur Einwilligung vom E-Rezept-Fachdienst zu löschen. 

Mit dem Widerruf der Einwilligung werden alle Abrechnungsinformationen des Versicherten gelöscht. Das Löschen erfolgt unwiederbringlich.

Mit dem Anwendungsfall "Einwilligungsinformation abfragen" werden die bestehenden Einwilligungen bestimmt. Das E-Rezept-FdV bestimmt die Consent-ID der Ressource mit Consent.category.coding.code = CHARGCONS.

5.2.3.20 Abrechnungsinformationen

5.2.3.20.1 Abrechnungsinformationen abrufen

Mit diesem Anwendungsfall kann der Nutzer eine Liste aller Abrechnungsinformationen vom E-Rezept-Fachdienst abrufen, welche für den Versicherten bereitgestellt wurden.

Im Response ist eine Liste von ChargeItem-Ressourcen enthalten. Für jede ChargeItem-Ressource ist die folgende Information enthalten:

• Prescription-ID

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Abrechnungsinformation zu einem E-Rezept vom E-Rezept-Fachdienst herunterladen.

Im Response ist die ChargeItem Ressource und die zugehörigen Detaildatensätze Verordnungsdatensatz, PKV-Abgabedatensatz, Quittung und der AccessCode zum Ändern des PKV-Abgabedatensatzes enthalten.

5.2.3.20.2 Abrechnungsinformation-Token als 2D-Code anzeigen

Mit diesem Anwendungsfall kann der Nutzer den AccessCode zum Ändern als 2D-Code auf dem Bildschirm seines E-Rezept-FdVs anzeigen lassen, um es direkt in der Apotheke vorzuzeigen und die Apotheke damit zu berechtigen, die Abrechnungsinformation vom E-Rezept-Fachdienst abzurufen und den PKV-Abgabedatensatz einmalig zu ändern.

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

5.2.3.20.3 Abrechnungsinformation-Token einer Apotheke übermitteln

Mit diesem Anwendungsfall kann der Nutzer den AccessCode zum Ändern mittels einer Nachricht einer Apotheke übermitteln und die Apotheke damit zu berechtigen, die Abrechnungsinformation vom E-Rezept-Fachdienst abzurufen und den PKV-Abgabedatensatz einmalig zu ändern.

Hinweis: Die Textnachricht ist optional.

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

Für die Spezifikation des Abrechnungsinformation-Token siehe [gemSpec_DM_eRp].

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

5.2.3.20.4 Abrechnungsinformation markieren

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) Markierungen zu seiner Abrechnungsinformation setzen. Diese werden auf dem E-Rezept-Fachdienst gespeichert.

5.2.3.20.5 Abrechnungsinformation löschen

Mit diesem Anwendungsfall kann der Nutzer (Versicherter) die Abrechnungsinformation zu einem E-Rezept, die auf dem E-Rezept-Fachdienst gespeichert ist, löschen.

Das E-Rezept-FdV muss im Rahmen der Bestätigung darauf hinweisen, dass mit dem Löschen der Abrechnungsinformation die Daten des Verordnungsdatensatzes, des PKV-Abgabedatensatzes und der Quittung gelöscht werden und somit ein Neueinstellen der Abrechnungsinformation durch die Apotheke ggf. nicht mehr möglich ist.

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

Der E-Rezept-Fachdienst bewahrt eine Abrechnungsinformation für 10 Jahre auf. Danach werden sie vom E-Rezept-Fachdienst automatisch  gelöscht.

5.2.3.20.6 Abrechnungsinformation exportieren

Mit diesem Anwendungsfall kann der Versicherte die Abrechnungsinformation aus dem E-Rezept-FdV exportieren, um es zur Abrechnung einzureichen oder zu archivieren.

Für die Visualisierung der Abrechnungsinformation für PKV-Versicherte ist die zwischen DAV und PKV-Verband vereinbarte Technische Anlage zu den PKV-Abgabedaten und dem dortigen Kapitel 6 Ausdruck für den Privatversicherten sowie dem Unterkapitel 6.2 Spezifikation des Ausdrucks für den Versicherten (Empfehlung) [http://www.abda.de/themen/e-health/datenauschtausch-pkv] zu beachten. Zur Umsetzungsunterstützung siehe auch [https://github.com/DAV-ABDA/eRezept-Beispiele/tree/main/PKV]. 

Das schließt das Versenden per E-Mail oder die Ablage im Dateisystem ein.

5.2.4 Einlösen ohne Anmelden am E-Rezept-Fachdienst

Für die Struktur der Nachricht siehe A_22784-* - E-Rezept - Einlösen ohne Anmelden - Datenstruktur Nachricht .

Das Profil des C.HCI.ENC Zertifikats wird in [gemSpec_PKI] beschrieben. Die Verwendung anderer Zertifikate zur Verschlüsselung von Nachrichten ist nicht zulässig.

Eine Apotheke kann mehrere SMC-Bs mit gleicher Telematik-ID im Einsatz haben, auf jeder SMC-B befinden sich aktuell Verschlüsselungsidentitäten für das kryptografische RSA und das ECC-Verfahren.

Für Vorgaben zur Verschlüsselung siehe GS-A_4389 - Symmetrischer Anteil der hybriden Verschlüsselung binärer Daten und GS-A_4390 - Asymmetrischer Anteil der hybriden Verschlüsselung binärer Daten .

Für Liste der Platzhalter siehe Tabelle "Platzhalter in URL".

Das folgende curl-Kommando zeigt, wie die Daten an die Schnittstelle des Apothekensystems übergeben werden:

5.2.5 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 (E-Rezept-Fachdienst-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 Test

7.1 Testtreiberschnittstelle für E-Rezept-Frontend des Versicherten

Hinweis: Die Einführung der Testtreiberschnittstelle wird verbunden mit dem Testvorgehen für ePA für Alle. Sie ist aktuell noch nicht verfügbar.

Für die automatisierten Tests der gematik im Kontext von Zulassungsverfahren des E-Rezept-Frontend des Versicherten muss der Hersteller entsprechend Zulassungsantrag für jedes Betriebssystem vorinstallierte Testobjekte mittels Testtreiberschnittstelle entsprechend [gemKPT_Test#Bereitstellung von Remote-Test-FdVs] bereitstellen . 

Die Spezifikation der Testtreiberschnittstelle wird als OpenAPI beschrieben und unter [gemTestTreiberFdV] als normativer Bestandteil der Spezifikation veröffentlicht.

7.2 Unterstützung des Herstellers bei den Zulassungstest des E-Rezept-Frontends des Versicherten

Der Hersteller des E-Rezept-FdV testet im Rahmen der eigenverantwortlichen Test integrativ mit dem E-Rezept-Fachdienst in der RU. Die gematik möchte diese integrativen Tests über eine Auswertung der Betriebsdaten nachvollziehen. Hierfür ist es notwendig, dass für diese Tests je Zulassungsobjekt ein eindeutiger User-Agent verwendet wird.

Hinweis:

Die Betriebsdatenerfassung des E-Rezept Fachdienstes protokolliert zu jeder Anfrage u.a. timestamp, User-Agent und Operation sowie den Status-Code des jeweiligen Responses der aufgerufenen Operation. Die gematik wird aus den erfassten Betriebsdaten Rückschlüsse ziehen, welche Operation erfolgreich aufgerufen werden konnten.

Hinweis:

Der Prozess der Bereitstellung eines User-Agents wird durch die gematik administriert.

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