Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation

E-Rezept-Frontend des Versicherten

 

 

 

   

   

Version	1.01.0
Revision	548770
Stand	30.0612.11.2020
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_eRp_FdV

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des DokumentesAnpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

 

Inhaltsverzeichnis

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

1.5.1 Hinweis auf offene Punkte

2 Systemüberblick

3 Systemkontext

3.1 Akteure und Rollen

3.2 Nachbarsysteme

4 Übergreifende Festlegungen

4.1 Datenschutz und Sicherheit

4.1.1 Anforderungen zum Herstellungsprozess

4.1.2 Unterstützung von Audits

4.1.3 Tracking

4.1.3.1 Anforderungen zum Tracking an das E-Rezept-FdV

4.1.3.2 Anforderungen zum Tracking an den Hersteller

4.2 Benutzeroberfläche

4.2.1 Visuelle Darstellung

4.2.2 Benutzerführung/Benutzerfreundlichkeit (Usability)

4.2.2.1 Technische Normen und Verordnungen zur Beachtung

4.2.2.2 Usability-Tests

4.3 Konfiguration des E-Rezept-FdV

4.4 Logging

5 Funktionsmerkmale

5.1 Allgemein

5.1.1 Session-Verwaltung

5.1.2 Kommunikation mit Diensten der TI

5.1.3 Authentisierung des Nutzers für Dienste der TI

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

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

5.1.6 Zertifikatsprüfung

5.1.6.1 Vertrauensanker des TI-Vertrauensraum

5.1.6.2 TSL-Behandlung

5.1.6.3 Zertifikatsprüfung von Zertifikaten der TI

5.1.6.4 Zertifikatsprüfung von Internet-Zertifikaten

5.1.7 Notification ServiceSchnittstellen zu Drittanwendungen

5.1.8 Schnittstellen zu Drittanwendungen5.2 E-Rezept-Anwendungsfälle im FdV

5.2 E-Rezept-Anwendungsfälle im FdV5.2.1 Übersicht der Anwendungsfälle

5.2.1 Übersicht der Anwendungsfälle5.2.2 Übergreifende Festlegungen

5.2.2 Übergreifende Festlegungen5.2.3 Anwendungsfälle

5.2.3 Anwendungsfälle5.2.3.1 App-Session starten

5.2.3.1 App-Session starten5.2.3.2 TI-Session starten

5.2.3.2 TI-Session starten5.2.3.3 App-Session beenden

5.2.3.3 App-Session beenden5.2.3.4 TI-Session beenden

5.2.3.4 TI-Session beenden5.2.3.5 E-Rezepte empfangen

5.2.3.5 E-Rezepte empfangen5.2.3.6 E-Rezept anzeigen

5.2.3.6 E-Rezept anzeigen5.2.3.7 2D-Code einscannen

5.2.3.7 2D-Code einscannen5.2.3.8 E-Rezepte in E-Rezept-Fachdienst löschen

5.2.3.8 E-Rezepte in E-Rezept-Fachdienst löschen5.2.3.9 E-Rezepte lokal im E-Rezept-FdV löschen

5.2.3.9 E-Rezepte lokal im E-Rezept-FdV löschen5.2.3.10 Anfrage zur Belieferung von E-Rezepten bei einer Apotheke

5.2.3.10 Verfügbarkeit von per E-Rezept verordneter Medikamente bei einer Apotheke anfragen5.2.3.11 E-Rezept einer Apotheke über die TI zuweisen

5.2.3.11 E-Rezept einer Apotheke über die TI zuweisen5.2.3.12 Vertreterkommunikation

5.2.3.12 Vertreterkommunikation5.2.3.13 E-Rezept-Token als 2D-Code anzeigen

5.2.3.13 E-Rezept-Token als 2D-Code anzeigen5.2.3.14 Apotheke suchen

5.2.3.14 Apotheke suchen5.2.3.15 Nachrichten von Apotheke anzeigen

5.2.3.15 Nachrichten von Apotheke anzeigen5.2.3.16 Abgabeinformationen anzeigen

5.2.3.16 Abgabeinformationen anzeigen5.2.3.17 Protokolldaten anzeigen

5.2.3.17 Protokolldaten anzeigen5.2.4 Fehlerbehandlung

5.2.4 Fehlerbehandlung6 Informationsmodell

6 Informationsmodell7 Verteilungssicht

7 Verteilungssicht8 Anhang A – Verzeichnisse

8 Anhang A – Verzeichnisse8.1 Abkürzungen

8.1 Abkürzungen8.2 Glossar

8.2 Glossar8.3 Abbildungsverzeichnis

8.3 Abbildungsverzeichnis8.4 Tabellenverzeichnis

8.4 Tabellenverzeichnis8.5 Referenzierte Dokumente

8.5 Referenzierte Dokumente8.5.1 Dokumente der gematik

8.5.1 Dokumente der gematik8.5.2 Weitere Dokumente

8.5.2 Weitere Dokumente

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

Akteur	Rolle	Beschreibung
Nutzer des E-Rezept-FdV	Versicherter oder  Vertreter eines Versicherten	Primärer Anwender, Ausführen von fachlichen Anwendungsfällen mit Zugriff auf den E-Rezept-Fachdienst
Ausführungsumgebung	Gerät des Versicherten	Betriebs-/Ablaufumgebung des E-Rezept-FdV
Hersteller E-Rezept-FdV	Organisatorisch, kein Akteur in der Ausführung von E-Rezept-Anwendungsfällen	Der Hersteller E-Rezept-FdV stellt im Handbuch Informationen bereit bezüglich Anforderungen an die Ausführungsumgebung Der Hersteller E-Rezept-FdV erfüllt sicherheitstechnische Anforderungen zum Herstellungsprozess.

 

3.2 Nachbarsysteme

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

• Identity Provider (IdPIDP)

•   Authentisierungsmodul des IdP

• E-Rezept-Fachdienst
• Verzeichnisdienst 
• eGK

Abbildung 1 : ABB_FDVERP_001 Systemüberblick FdV

Identity Provider

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

Authentisierungsmodul des IdPAuthenticator-Modul

Das AuthentisierungsmodulAuthenticator-Modul ist eine separatelogische Komponente auf dem Gerät des Versicherten.

Das Authentisierungsmodul ergänzt den IdP, um auf dem Gerät des Nutzers den Zugriff auf die Smart Card des Nutzers über NFC umzusetzen. Dem IdP stellt das Authentisierungsmodul die für die Authentifizierung des Nutzers erforderlichen Daten bereit. 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 Workflow zu den 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.

A_20202 - E-Rezept-FdV - App-Berechtigungen

Das E-Rezept-FdV MUSS die Nutzung und den Zugriff auf Geräte-Ressourcen und Sensorik auf das für den Betrieb des E-Rezept-FdV notwendige Maß einschränken (z.Bbeispielsweise ggf. Standortabfrage für Apothekensuche, Kamerazugriff für das Abscannen eines 2D-Codes, Kalenderzugriff für Erinnerungen, Audio- und Mikro-Zugriff für barrierearmen Zugriff). [<=]

A_20203 - E-Rezept-FdV - Verbot Screenshot

Das E-Rezept-FdV MUSS das Erstellen eines Screenshots über die Inhalte der App verhindern. [<=]

A_19176 - E-Rezept-FdV – Nutzungshinweise

Der Hersteller bzw. der Anbieter des E-Rezept-FdV MUSS den Nutzer über die Annahmen und Anforderungen seines Produktes an das Gerät, auf dem das E-Rezept-FdV läuft, sowie über den Bezug des Produkts aus vertrauenswürdigen App Stores informieren. [<=]

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

A_19177 - E-Rezept-FdV – Anzeige von Protokolldaten

Das E-Rezept-FdV MUSS es den Versicherten ermöglichen, die für die Fachanwendung für ihn erzeugten Protokolleinträge anzeigen zu können. [<=]

A_19178 - E-Rezept-FdV – Schutzmaßnahmen gegen die OWASP-Mobile-Top-10-Risiken

Das E-Rezept-FdV MUSS Maßnahmen zum Schutz vor den in der jeweils aktuellen Version genannten OWASP-Mobile-Top-10-Risiken [OWASPMobileTop10] umsetzen.  [<=]

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.

A_19480 - E-Rezept-FdV – Schutz der Session-Daten

Das E-Rezept-FdV DARF Session-Daten (IDbspw. ACCESS_TOKEN, REFRESH und ID_TOKEN) NICHT an Dritte, außer im Rahmen der in den Anwendungsfällen spezifizierten Kommunikation, weitergeben. [<=]

A_20184 - E-Rezept-FdV - Speicherung der Session-Daten

Das E-Rezept-FdV DARF NICHT Session-Daten (IDbspw. ACCESS_TOKEN, REFRESH und ID_TOKEN) unverschlüsselt auf permanenten Speichermedien ablegen. [<=]

A_20185 - E-Rezept-FdV - Session-Timeout

Das E-Rezept-FdV MUSS die Session nach einem angemessenen Session-Timeout, gemäß aktuellen Best-Practice-Empfehlungen, aktiv beenden. [<=]

A_20186 - E-Rezept-FdV - Session-Daten löschen

Das E-Rezept-FdV MUSS beim Beenden einer Session die Session-Daten (IDbspw. ACCESS_TOKEN, REFRESH und ID_TOKEN) sicher löschen.  [<=]

A_19179 - E-Rezept-FdV – Qualität verwendeter Schlüssel

Das E-Rezept-FdV MUSS sicherstellen, dass die von ihm erzeugten Schlüssel eine ausreichende Qualität besitzen. [<=]

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.

A_19979 - E-Rezept-FdV – Kein Zugriff von Diensten Dritter auf personenbezogene medizinische Daten

Das E-Rezept-FdV DARF Diensten Dritter NICHT Zugriff auf personenbezogene medizinische Daten geben. [<=]

A_19980 - E-Rezept-FdV – Information über Datenweitergabe an Dienste Dritter

Das E-Rezept-FdV MUSS den Versicherten darauf hinweisen, dass durch die Nutzung von Diensten Dritter Daten an diese abfließen und welche Daten dies sind. [<=]

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.

 

A_19981 - E-Rezept-FdV – Zustimmung über Datenweitergabe an Dienste Dritter

Das E-Rezept-FdV MUSS vor einer Weitergabe von Daten an Dienste von Dritten einmalig das Einverständnis des Versicherten einholen (OPT-IN). [<=]

A_19982 - E-Rezept-FdV – Rücknahme der Zustimmung über Datenweitergabe an Dienste Dritter

Das E-Rezept-FdV MUSS es dem Versicherten ermöglichen das Einverständnis zur Weitergabe von Daten an Dienste von Dritten zu widerrufen und ihn dabei über eventuelle Einschränkungen in der Funktionalität informieren. [<=]

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

A_19983 - E-Rezept-FdV – Keine Nutzung von Diensten Dritter mit bekannten Schwachstellen

Das E-Rezept-FdV DARF NICHT Dienste von Dritten nutzen, wenn diese bekannte Schwachstellen besitzen. [<=]

A_19984 - E-Rezept-FdV – Validierung eingehender Daten von Diensten Dritter

Das E-Rezept-FdV SOLL eingehende Daten von Diensten Dritter validieren. [<=]

A_19181 - E-Rezept-FdV – Privacy bei default

Das E-Rezept-FdV MUSS bei Konfigurationsmöglichkeiten die sicherste, datenschutzfreundlichste Option vorauswählen.  [<=]

A_19182 - E-Rezept-FdV – Sicherheitsrisiken von Software-Bibliotheken minimieren

Das E-Rezept-FdV MUSS Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren.  [<=]

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

A_19183 - E-Rezept-FdV – Zustimmung zur Weiterleitung von Daten

Das E-Rezept-FdV MUSS sicherstellen, dass Daten, die vom E-Rezept-Fachdienst in das E-Rezept-FdV geladen werden, nur mit Zustimmung des Versicherten unter Nutzung von expliziten Opt-in-Lösungen weitergeleitet werden können, wobei sich das Opt-In nur genau auf die Weiterleitung beziehen und nicht mit anderen Zustimmungen kombiniert werden darf. [<=]

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.

A_19184 - E-Rezept-FdV – Information über weitergeleitete Daten

Das E-Rezept-FdV MUSS sicherstellen, dass der Versicherte vor der Zustimmung zur Weiterleitung von Daten aus dem E-Rezept-FdV in verständlicher Weise darüber informiert wird, welche Daten weitergeleitet werden. [<=]

A_19185 - E-Rezept-FdV – Nachvollziehbarkeit der Weiterleitung von Daten

Das E-Rezept-FdV MUSS sicherstellen, dass der Versicherte eine Weiterleitung der Daten im Nachhinein nachvollziehen kann (z.B. durch Protokollierung).  [<=]

A_19186 - E-Rezept-FdV – Sichere Speicherung lokaler Daten

Das E-Rezept-FdV MUSS Daten lokal sicher speichern, so dass keine andere App auf demselben Gerät unbefugt Zugriff auf die Daten hat. Insbesondere MUSS das E-Rezept-FdV Zugriffsschlüssel verschlüsselt ablegen. Außerdem MUSS das E-Rezept-FdV sicherstellen, dass vertrauliche Daten nicht vom Betriebssystem an anderen Ablageorten zwischengespeichert werden. [<=]

A_19187 - E-Rezept-FdV – Authentisierung vor Zugang zum Dienst

Das E-Rezept-FdV DARF NICHT eine Verbindung zum E-Rezept-Fachdienst aufbauen, wenn es keinen AuthN-TokenACCESS_TOKEN vom IdPIDP erhalten hat. [<=]

A_20182 - E-Rezept-FdV - Makelverbot

Das E-Rezept-FdV DARF NICHT zusätzliche Funktionalitäten enthalten, die die berufs- oder gewerbsmäßige Zuweisung und das Makeln von E-Rezepten unterstützen oder den Nutzer in in seiner Entscheidung beeinflussen, welche elektronischen Verordnungen in welcher Apotheke eingelöst werden. [<=]

A_20285 - E-Rezept-FdV: Wettbewerbsneutralität für Darstellung Apotheken

Das E-Rezept-FdV MUSS Apotheken wettbewerbsneutral darstellen (bspw. Sortierung nach Alphabet oder Entfernung vom aktuellen Standort des Nutzers). [<=]

A_19188 - E-Rezept-FdV - Sichere Deinstallation

Das E-Rezept-FdV MUSS die von ihm verarbeiteten Daten so speichern, dass die Daten bei einer Deinstallation des E-Rezept-FdV mit gelöscht werden. [<=]

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

A_19086 - E-Rezept-FdV: Verbot von Werbe-Tracking

Das E-Rezept-FdV DARF ein Werbe-Tracking NICHT verwenden.  [<=]

A_19087 - E-Rezept-FdV: Erlaubnis von Usability-Tracking sowie Crash-Reporting

Das E-Rezept-FdV KANN ein Usability-Tracking sowie Crash-Reporting verwenden.  [<=]

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

A_19088 - E-Rezept-FdV: Informierte Einwilligung

Das E-Rezept-FdV DARF ein Usability-Tracking sowie Crash-Reporting NICHT verwenden, ohne dass der Nutzer vorher über die Funktionen informiert wurde und über ein Opt-in-Verfahren eingewilligt hat. [<=]

A_20187 - E-Rezept-FdV: Einwilligung Tracking widerrufen

Das E-Rezept-FdV MUSS es dem Versicherten ermöglichen, die Einwilligung in die Aktivierung eines Usability-Tracking sowie Crash-Reporting zu widerrufen und ihn dabei über die Folgen des Widerrufs informieren. [<=]

A_19089 - E-Rezept-FdV: Informationen zur Einwilligung

Das E-Rezept-FdV MUSS den Versicherten vor der Einwilligung in die Aktivierung Usability-Tracking sowie Crash-Reporting in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache folgende Einwilligungsinformationen anzeigen:

• welche Daten durch die Tracking-Funktionen erhoben werden,
• zu welchen Zwecken die Daten erhoben werden,
• welche Informationen durch die Auswertung der erhobenen Daten gewonnen werden und ob Rückschlüsse auf den Gesundheitszustand des Nutzers möglich wären,
• wer die Empfänger der Daten sind,
• wie lange die Daten gespeichert werden,
• wie die Tracking-Funktionen deaktiviert werden können.

[<=]

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.

A_19090 - E-Rezept-FdV: Aktivierung erst nach Lesebestätigung der Einwilligungsinformationen

Das E-Rezept-FdV MUSS sicherstellen, dass die Einwilligung des Nutzers in die Aktivierung von Usability-Tracking sowie Crash-Reporting erst erfolgt, wenn der Nutzer bestätigt, die angezeigten Einwilligungsinformationen gelesen zu haben. [<=]

A_19091 - E-Rezept-FdV: Verbot von mehrmaligen Einwilligungsabfragen

Das E-Rezept-FdV MUSS technisch sicherstellen, dass der Benutzer der App maximal einmal eine Abfrage zur Einwilligung in das Usability-Tracking sowie Crash-Reporting angezeigt bekommt. [<=]

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.

A_19092 - E-Rezept-FdV: Kopplungsverbot

Das E-Rezept-FdV DARF die Nutzung E-Rezept-FdV NICHT an die Aktivierung des Usability-Tracking sowie Crash-Reporting koppeln. [<=]

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

A_19093 - E-Rezept-FdV: Keine direkt identifizierenden personenbezogenen Daten

Das E-Rezept-FdV MUSS sicherstellen, dass die Informationen zu Usability-Tracking sowie Crash-Reporting keine Daten enthalten, die natürliche Personen direkt identifizieren. [<=]

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.

A_19094 - E-Rezept-FdV: Keine Weitergabe von Sicherheitsmerkmalen

Das E-Rezept-FdV MUSS sicherstellen, dass in den übermittelten Informationen zu Usability-Tracking sowie Crash-Reporting keine Sicherheitsmerkmale enthalten sind. [<=]

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

A_19095 - E-Rezept-FdV: Generierung von Nutzersession-basierten Merkmalen

Das E-Rezept-FdV MUSS beim Start einer Nutzersession die Nutzersession-ID zufällig neu generieren. [<=]

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

A_19096 - E-Rezept-FdV: Neue Generierung der Pseudonyme

Falls das E-Rezept-FdV ein Session-übergreifendes Tracking umsetzt, MUSS das E-Rezept-FdV technisch sicherstellen, dass pseudonyme Identifier neu generiert werden können. [<=]

A_19097 - E-Rezept-FdV: Deaktivierung zu jeder Zeit

Das E-Rezept-FdV MUSS technisch sicherstellen, dass aktiviertes Usability-Tracking sowie Crash-Reporting jederzeit durch den Nutzer des FdVs deaktiviert werden können. [<=]

4.1.3.2 Anforderungen zum Tracking an den Hersteller

A_19098 - E-Rezept-FdV: Verarbeitung und Auswertung der Tracking-Daten

Der Hersteller bzw. der Anbieter des E-Rezept-FdV MUSS die Verarbeitung und Auswertung der gesammelten Informationen zu Usability-Tracking sowie Crash-Reporting selbst durchführen und darf diese nicht von einem Drittanbieter durchführen lassen. [<=]

A_19099 - E-Rezept-FdV: Verbot der Profilbildung

Der Hersteller bzw. der Anbieter des E-Rezept-FdV DARF die gesammelten Informationen zu Usability-Tracking sowie Crash-Reporting NICHT für eine Profilbildung verwenden. [<=]

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

Die Entwicklung einer barrierearmen Anwendung unterliegt einem sich fortlaufend weiterentwickelnden Prozess. Die Umsetzung aller Anforderungen kann nicht mit der Ersteinführung der Anwendung sichergestellt werden.

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

A_19074 - E-Rezept-FdV: Intuitive Bedienung

Die Bedienung des E-Rezept-FdV SOLL für den Nutzer intuitiv gestaltet werden.  [<=]

A_19075 - E-Rezept-FdV: Bereitstellung Sprachen

Das E-Rezept-FdV SOLL dem Nutzer alle anzeigbaren Texte in den Sprachen Deutsch, Türkisch, Russisch, Polnisch, Arabisch und Englisch bereitstellen. [<=]

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

A_19077 - E-Rezept-FdV: Abbruch Anwendungsfälle

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, Anwendungsfälle auch vor dem Ende der Verarbeitung jederzeit abzubrechen. [<=]

A_19085 - E-Rezept-FdV: Arten der Verwaltung

Die E-Rezept-FdV SOLL dem Nutzer anzeigen, welche Arten von Dokumentenzugriffen und Verwaltungsfunktionen ausgeführt werden können. [<=]

A_19084 - E-Rezept-FdV: Bezeichnung der Anwendungsfälle

Das E-Rezept-FdV MUSS für die Inhalte und Anwendungsfälle eindeutige und verständliche Bezeichnungen verwenden. [<=]

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

A_19078 - E-Rezept-FdV: Navigierbarkeit bereitgestellter Inhalte

Das E-Rezept-FdV SOLL sicherstellen, dass bereitgestellte Inhalte maschinenlesbar und navigierbar sind, um dem Nutzer eine barrierefreie Bedienung zu ermöglichen. [<=]

A_20193 - E-Rezept-FdV: Anwendungsspezifische Nutzung Gerätefunktionalitäten

Das E-Rezept-FdV DARF NICHT gerätespezifische Funktionalitäten (z.B. Lagebestimmung, Kamerafunktion, Multi-Touch-Gesten) nutzen, wenn sie nicht für die Anwendung erforderlich sind. [<=]

A_19079 - E-Rezept-FdV: Nutzung Gerätefunktionalitäten

Das E-Rezept-FdV SOLL gerätespezifische Funktionalitäten (z.B. Lagebestimmung, Kamerafunktion, Multi-Touch-Gesten) sinnvoll nutzen und unterstützen. [<=]

A_20194 - E-Rezept-FdV: Information zur Verwendung von Gerätefunktionalitäten

Das E-Rezept-FdV MUSS den Nutzer über die Verwendung der gerätespezifischen Funktionalitäten (z.B. Lagebestimmung, Kamerafunktion, Multi-Touch-Gesten) informieren. [<=]

A_20205 - E-Rezept-FdV: Deaktivierung gerätespezifischer Funktionalitäten

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die Verwendung von gerätespezifischen Funktionalitäten (z.B. Lagebestimmung, Kamerafunktion, Multi-Touch-Gesten) jederzeit deaktivieren zu können. [<=]

A_19080 - E-Rezept-FdV: Nutzung Schnittstellen Bedienungsmöglichkeiten des Betriebssystems

Das E-Rezept-FdV SOLL die Schnittstellen für die Unterstützung der barrierefreien Bedienungsmöglichkeit, welche vom Betriebssystem zur Verfügung gestellt werden, nutzen. [<=]

A_19081 - E-Rezept-FdV: Nutzung Bedienhilfen des Betriebssystems

Das E-Rezept-FdV SOLL die Bedienhilfen der verwendeten Betriebssysteme zur barrierefreien Nutzung verwenden. [<=]

A_19082 - E-Rezept-FdV: Kontrastverhältnis

Das E-Rezept-FdV SOLL für das GUI ein Kontrastverhältnis verwenden, welches unter verschiedenen Bedingungen eine optimale Ablesbarkeit gewährleistet. [<=]

A_19083 - E-Rezept-FdV: Hinweise

Das E-Rezept-FdV SOLL dem Nutzer Hinweise anzeigen, die den Zweck sowie den inhaltlichen Ablauf eines Anwendungsfalls betreffen, um dem Nutzer die Bedienung zu vereinfachen. [<=]

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.

A_19574 -01 AFO - E-Rezept-FdV: Parameter speichern und laden

Das E-Rezept-FdV MUSS die Parameter aus TAB_FdVERP_002 persistent speichern und bei der Initialisierung laden.

Tabelle 2 : TAB_FdVERP_002 – Konfigurationsparameter

[<=]

A_20051 - E-Rezept-FdV: Konfigurationsparameter verwalten

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die Parameter aus TAB_FdVERP_002 zu verwalten (anzeigen, ändern, löschen). [<=]

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.   

A_19682 - E-Rezept-FdV - Kein Logging auf Geräten des Versicherten

Das E-Rezept-FdV MUSS als Standardkonfigurationfür den Betrieb auf dem Gerät des Versicherten das Logging deaktiviert haben. [<=]

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 SeesionSession-Daten gelöscht und eine erneute Authentisierung wird erforderlich (siehe Abschnitt "TI-Session beenden")

A_19540 - E-Rezept-FdV: Start Anwendungsfall "TI-Session starten"

Das E-Rezept-FdV SOLL beim erstmaligen Start nach der Installation der App den Anwendungsfall "TI-Session starten" starten. [<=]

A_19725 - E-Rezept-FdV: Aktivieren des Zugriffsschutzes bei Verlust des Fokus

Das E-Rezept-FdV MUSS den in den Konfigurationseinstellungen eingestellten Zugriffsschutz der App aktivieren, wenn diese nicht mehr im Fokus ist und sich im Hintergrund befindet. [<=]

A_19541 - E-Rezept-FdV: Aktivieren des Zugriffsschutzes bei Inaktivität

Das E-Rezept-FdV MUSS den eingestellten Zugriffsschutz der App aktivieren, wenn der Nutzer für die in den Konfigurationseinstellungen festgelegten Zeitdauer inaktiv war.  [<=]

A_19572 - E-Rezept-FdV: automatischer Start "TI-Session starten"

Das E-Rezept-FdV MUSS den Anwendungsfall "TI-Session starten" automatisch nach dem Anwendungsfall "App-Session starten" ausführen, wenn das automatische TI-Login in den Konfigurationseinstellungen aktiviert ist.  [<=]

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.

A_19438 - E-Rezept-FdV: Lokalisierung E-Rezept-Fachdienst

Das E-Rezept-FdV MUSS die zur Kommunikation mit dem E-Rezept-Fachdienst notwendigen Lokalisierungsinformationen per DNS-Abfrage nach den in [gemSpec_FD_eRP#Tab_eRP_Service Discovery] und [gemSpec_FD_eRP#Tab_eRP_FQDN] dargestellten Parametern ermitteln. [<=]

A_19747 - E-Rezept-FdV: Endpunkt Schnittstelle E-Rezept-Fachdienst

Das E-Rezept-FdV MUSS die URL für die Kommunikation mit dem E-Rezept-Fachdienst gemäß https://<FQDN aus DNS Lookup>:443/<path> bilden. [<=]

A_20067 - E-Rezept-FdV: Endpunkt Schnittstelle Verzeichnisdienst

Das E-Rezept-FdV MUSS als Endpunkt für die Kommunikation mit dem Verzeichnisdienst die URL https://directory.vzd.ti-dienste.de:443/  nutzen. [<=]

Die Informationen zu den Endpunkten des Identity Providers ermittelt das E-Rezept-FdV aus dem Discovery Document. Siehe auch [gemSpec_IDP_Dienst#Registrierung von Endgerät und Anwendungsfrontend]. 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. 

A_19215 - E-Rezept-FdV: Kommunikation über TLS-Verbindung

Das E-Rezept-FdV MUSS mit den Diensten der TI ausschließlich über TLS kommunizieren. [<=]

A_20206 - E-Rezept-FdV: Kommunikation über TLS-Verbindung mit Diensten Dritter

Das E-Rezept-FdV SOLL mit den Diensten Dritter ausschließlich über TLS kommunizieren. [<=]

A_19216 - E-Rezept-FdV: Unzulässige TLS-Verbindungen ablehnen

Das E-Rezept-FdV MUSS bei jedem Verbindungsaufbau den Dienst der TI anhand seines TLS-Zertifikats authentifizieren und MUSS die Verbindungen ablehnen, falls die Authentifizierung fehlschlägt. [<=]

A_20014 - E-Rezept-FdV: HTTP-Header user-agent

Das E-Rezept-FdV MUSS in alle HTTP-Requests an Dienste der TI den HTTP-Header user-agent gemäß [RFC7231] mit <Hersteller-ID> <Produktkürzel>/<Produktversion> gemäß der Produktidentifikation des E-Rezept-FdV befüllen. [<=]

Für Informationen zur Produktidentifikation siehe [gemSpec_OM].

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 (IDACCESS_TOKEN), welcher für die Authentisierung bei den Diensten der TI weitergeleitet wird.

A_20167 - E-Rezept-FdV: Authentisierung - Rolle Authenticator-Modul und Anwendungsfrontend

Das E-Rezept-FdV MUSS für den Zugriff auf Dienste der TI, wenn kein gültiger IDACCESS_TOKEN vorliegt, sich gegenüber einem Identity Provider der TI in der Rolleden Rollen Authenticator-Modul und Anwendungsfrontend Applikation authentisieren. [<=]

Für Informationen zum Ablauf der Authentisierung siehe [gemSpec_IdPIDP_Dienst] und [gemSpec_IdPIDP_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

A_20172 - E-Rezept-FdV: Zugriffsschutz - Online-Authentisierung

Das E-Rezept-FdV MUSS für die Umsetzung der Online-Authentisierung für dueden Zugriffsschutz des E-Rezept-FdV eine Authentisierung gegenüber einen Identity Provider der TI durchführen. [<=]

Bei erfolgreicher Authentisierung erhält das E-Rezept-FdV einen verschlüsselten IDACCESS_TOKEN. Das E-Rezept-FdV kann diesen IDACCESS_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.

A_19740-01 - E-Rezept-FdV: Umsetzung sicherer Kanal zur VAU des E-Rezept-Fachdienstes

Das E-Rezept-FdV MUSS für alle Anfragen an den E-Rezept-Fachdienst für

• die Abfrage des capability statement
• den Zugriff auf Task, AuditeventMedicationDispense, AuditEvent oder Communication Ressourcen

das Kommunikationsprotokoll zwischen E-Rezept-VAU und E-Rezept-Clients in der Rolle E-Rezept-Client nutzen. [<=]

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 3 TAB_FdVERP_017 – Zertifikatsnutzung

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

A_19739 - E-Rezept FdV: verpflichtende Zertifikatsprüfung

Das E-Rezept-FdV MUSS alle Zertifikate, die es aktiv verwendet (bspw. TLS-Verbindungsaufbau), auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Das E-Rezept-FdV MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]

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

5.1.6.1 Vertrauensanker des TI-Vertrauensraum

Der Vertrauensraum der TI ist in [gemSpec_PKI#8.1] beschrieben. Für das E-Rezept-FdV gelten abweichende Vorgaben, da das E-Rezept-FdV nicht innerhalb der TI betrieben wird. Diese Abweichungen werden im Folgenden beschrieben.

Die Initialisierung des TI-Vertrauensraums und der Wechsel des TI-Vertrauensankers wird beim E-Rezept-FdV durch die Bereitstellung der FdV Applikation durchgeführt.

A_20027 - E-Rezept-FdV: Behandlung des Vertrauensankers

Das E-Rezept-FdV MUSS den aktuellen TI-Vertrauensanker (TSL-Signer-CA-Zertifikat) im Auslieferungszustand der Applikation integer und authentisch mit sich führen. 
Dabei MUSS der TI-Vertrauensanker fest mit dem Code des E-Rezept-FdV verbunden sein, d.h. eine Manipulation des TI-Vertrauensankers MUSS durch das E-Rezept-FdV erkannt werden.
Das E-Rezept-FdV MUSS bei einem angekündigten Wechsel des TI-Vertrauensankers den neuen TI-Vertrauensanker zusätzlich zum aktuell gültigen Vertrauensanker mit sich führen.
Das E-Rezept-FdV MUSS eindeutig identifizierte und während der Erstellung der Applikation mittels Fingerprint validierte TSL-Signer-CA-Zertifikate mit sich führen und ausschließlich diese als Vertrauensanker verwenden. [<=]

5.1.6.2 TSL-Behandlung

Folgende Vorgaben gelten für den Bezug und die Verarbeitung der TSL.

A_20028 - E-Rezept-FdV: Periodische Aktualisierung TI-Vertrauensraum

Das E-Rezept-FdV MUSS zur periodischen Aktualisierung des TI-Vertrauensraums den TUC_PKI_001 mit folgenden Anpassungen umsetzen:

• Der Offline-Modus ist nicht zu berücksichtigen
• Auslöser: keine TSL lokal gespeichert oder die gespeicherte TSL ist zu alt (die in der TSL selbst kodierte Gültigkeitsdauer NextUpdate ist abgelaufen).
• Wenn innerhalb der letzten 24 Stunden keine Prüfung erfolgte, dann muss das E-Rezept-FdV prüfen, ob eine neuere TSL zur Verfügung steht. Falls eine neuere TSL am Downloadpunkt bereitsteht, so muss das E-Rezept-FdV die neuere TSL herunterladen.

Das E-Rezept-FdV MUSS zum Prüfen der Aktualität und dem Herunterladen der TSL(ECC-RSA) die vom E-Rezept-Fachdienst angebotene Schnittstelle verwenden. [<=]

Für die Spezifikation der Schnittstelle siehe [gemSpec_FdVFD_eRp#A_20023 - E-Rezept-Fachdienst - Bereitstellung TSL]. Der Aufbau und der Inhalt der TSL sind durch [ETSI_TS_102_231_V3.1.2] gegeben und in [gemSpec_TSL#7] beschrieben.

A_20029 - E-Rezept-FdV: TSL - Prüfung Integrität und Authentizität

Das E-Rezept-FdV MUSS die Integrität und Authentizität der heruntergeladenen TSL prüfen. Falls die Prüfung kein positives Ergebnis liefert, so MUSS die gerade heruntergeladene TSL verworfen werden. [<=]

Die Bedingungen an den Vertrauensstatus der TSL sind in [gemSpec_TSL#8.2.2] beschrieben. Für das ePA-Modul E-Rezept-FdV gilt eine "TSL-Graceperiod" von 0 Tagen, d.h., die TSL-Informationen sind nicht mehr vertrauenswürdig, wenn das aktuelle Datum nach dem Datum nextUpdate der TSL liegt.

A_20030 - E-Rezept-FdV: TSL - Truststore für Zertifikatsprüfung

Das E-Rezept-FdV MUSS die TSL auswerten, um aus den Inhalten einen Truststore für die durchzuführenden Zertifikatsprüfungen zu bilden. [<=]

Hinweis: Eine Möglichkeit zur Umsetzung ist, im Rahmen der Aktualisierung der TSL (vgl. A_20028) nach positiver Prüfung der TSL-Signatur die CA-Zertifikate aus der TSL in verschiedene zugriffsgeschützte Verzeichnisse zu legen: bspw. einmal für HBA/SMC-B/eGK-CAs, einmal für SGD-Zertifikate und einmal für CAs der Komponenten-PKI der TI. Die Verzeichnisse dienen dann als Truststore für die Zertifikatsprüfung, womit sich die Umsetzungskomplexität der Vorgabe aus A_20032 Punkt 2 reduziert.

A_20031 - E-Rezept-FdV: TSL nicht verfügbar

Das E-Rezept-FdV MUSS, falls keine auf Integrität und Authentizität erfolgreich geprüfte TSL zur Verfügung steht oder das aktuelle Datum nach dem Datum nextUpdate der TSL liegt, den Vertrauensraum als ungültig betrachten und sicherstellen, dass alle Zertifikatsprüfungen für TI-Zertifikate mit "ungültig" bewertet werden. [<=]

Hinweis: Es ist in Bezug auf die Evaluierung hilfreich, wenn die TSL-Signaturprüfung mit einer speziell dafür geschriebenen (und gehärteten) Programmkomponente durchgeführt wird. Bei einer anschließenden XML-Auswertung der TSL mit einer Standard-XML-Bibliothek können die verarbeiteten XML-Daten dann als vertrauenswürdig angesehen werden.

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

A_20032 - E-Rezept-FdV: Prüfung TI-Zertifikate

Das E-Rezept-FdV MUSS bei der Prüfung von X.509-Zertifikaten der TI folgende Prüfschritte durchlaufen.

1. Prüfung der zeitlichen Gültigkeit des Zertifikats auf Basis der aktuellen Systemzeit (orientiert an gemSpec_PKI#TUC_PKI_002)
2. Ist das Zertifikat kryptographisch (Signaturprüfung) rückführbar auf ein CA-Zertifikat aus einer authentischen und integeren und zeitlich gültigen TSL (vgl. A_20028)? (orientiert an [gemSpec_PKI#TUC_PKI_003 und TUC_PKI_004])
3. Prüfung auf den für den Anwendungsfall korrekten Zertifikatstyp gemäß TAB_FdVERP_017. Die OID des Zertifikatstyps gemäß [gemSpec_OID] muss in der Extension CertificatePolicies enthalten sein.
4. Falls das Zertifikat für den Aufbau des sicheren Kanals zur VAU verwendet wird (VAU-Zertifikat innerhalb des VAU-Protokolls, vgl. [gemSpec_Krypt#Kommunikationsprotokoll zwischen VAU und ePA-Clients]), so MUSS die Rolle "oid_erp_vau" gemäß  im EE-Zertifikat aufgeführt sein (analog gemSpec_PKI#TUC_PKI_009). Falls nein, MUSS das Zertifikat für den Aufbau des sicheren Kanals zur VAU abgelehnt werden.
5. Falls das Zertifikat ein EE-Zertifikat ist: Ermittlung der OCSP-Statusinformation. Ist das Zertifikat nicht gesperrt (Status "good" [RFC-6960#2.2 Response]) (vgl. A_15869)? Eine OCSP-Antwort KANN lokal maximal 4 Stunden gecacht und als Prüfgrundlage verwendet werden.
   Die Prüfung ist analog gemSpec_PKI#TUC_PKI_006 mit den Parametern Referenzzeitpunkt=Systemzeit, OCSP-Graceperiod=4 Stunden.
6. Prüfung der Extensions KeyUsage und ExtendedKeyUsage auf die richtige Belegung gemäß dem Anwendungsfall (orientiert an gemSpec_PKI#TUC_PKI_018 Schritt 2).

Führt einer der Prüfschritte nicht zu einem positiven Prüfergebnis, so MUSS das Zertifikat abgelehnt werden und die weitere Verarbeitung des Zertifikats oder der Attribute darin abgelehnt werden. 

Das E-Rezept-FdV muss die referenzierten technischen Use Cases (TUC_PKI_*) aus [gemSpec_PKI] im Rahmen dieser Anforderung nicht normativ umsetzen. [<=]

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.4 Zertifikatsprüfung von Internet-Zertifikaten

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

A_20033 - E-Rezept-FdV: Prüfung Internet-Zertifikate

Das E-Rezept-FdV MUSS für die Prüfung des internetseitigen Zertifikats von Diensten der TI das Zertifikat auf ein CA-Zertifikat einer CA, die die "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (https://cabforum.org/baseline-requirements-documents/) erfüllt, kryptographisch (Signaturprüfung) zurückführen können. Ansonsten MUSS es das Zertifikat als "ungültig" bewerten.
Das E-Rezept-FdV MUSS die zeitliche Gültigkeit des Zertifikats prüfen. Falls diese Prüfung negativ ausfällt, muss es das Zertifikat als "ungültig" bewerten.  [<=]

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

5.1.7 Notification Service

Der E-Rezept-Fachdienst sendet Notifikationen an das E-Rezept-FdV, wenn ein neues E-Rezept durch eine verordnende LEI oder eine neue E-Rezept-Nachricht von einer abgebenden LEI für den Versicherten eingestellt wurde. Hierfür werden Services von Apple bzw. Google genutzt.

Hinweis: Die funktionalen Anforderungen für das E-Rezept-FdV für die Nutzung eines Notification Service werden in Folgerelease erarbeitet.

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

A_20239 - E-Rezept-FdV: Schnittstelle zu Drittanwendungen

Das E-Rezept-Frontend des Versicherten KANN einen E-Rezept-Token aus Drittanwendungen importieren und in Drittanwendungen exportieren. [<=]

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 4 : 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

  

Die in diesem Kapitel aufgeführten User Stories schildern die Absichten des Nutzers in Verbindung mit dem E-Rezept-FdV und dienen als Lesehilfe zu den fachlichen Anwendungsfällen. Die User Stories erheben keinen Anspruch auf Vollständigkeit.

A_19443 - E-Rezept-FdV: Ausführung der Anwendungsfälle

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die in "TAB_FdVERP_003 – Übersicht Anwendungsfälle E-Rezept-FdV" beschriebenen Anwendungsfälle auszuführen. [<=]

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.

A_20008 - E-Rezept-FdV - Hinweise zu Authentisierungsarten

Das E-Rezept-FdV SOLL dem Nutzer die verfügbaren Authentisierungsarten in verständlicher Form darstellen und erklärende Hinweise zur Verfügung stellen. [<=]

A_19485 - E-Rezept-FdV: Konfiguration Authentisierung gegenüber E-Rezept-FdV

Das E-Rezept-FdV MUSS dem Nutzer die Möglichkeit bieten, die Authentisierung gegenüber der E-Rezept-FdV in den Konfigurationseinstellungen ein- oder auszuschalten . [<=]

A_19484 - E-Rezept-FdV: TI-Authentisierung

Das E-Rezept-FdV MUSS dem Nutzer ermöglichen, sich mittels eines geeigneten technischen Verfahrens, das zur Authentifizierung einen hohen Sicherheitsstandard gewährleistet, für die Konfiguration einer Authentisierungsart mit geringerem Sicherheitsniveau zu authentisieren. [<=]

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

A_19563 - E-Rezept-FdV: alternative Authentisierungsarten

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die alternative Authentisierungsarten PIN, Fingerabdruck und Face-ID, soweit sie vom GdV unterstützt werden, zu nutzen. [<=]

A_19952 - E-Rezept-FdV: App-Session starten

Das E-Rezept-FdV MUSS den Anwendungsfall "App-Session starten" gemäß TAB_FdVERP_005 umsetzen. 

Tabelle 5 : TAB_FdVERP_005 – App-Session starten

[<=]

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 IDACCESS_TOKEN für den Dienst im E-Rezept-FdV vorliegt und
• wenn für die Deaktivierung des Zugriffsschutzes, die TI-Authentisierung genutzt werden soll..

A_19472 - E-Rezept-FdV: Expliziter Start TI-Session

Das E-Rezept-FdV MUSS, falls das automatische TI-Login in den Konfigurationseinstellungen aktiviert ist, nach Start der App-Session die TI-Session starten. [<=]

A_20117 - E-Rezept-FdV: Authentisierung wenn kein gültiger ACCESS_CODE

Das E-Rezept-FdV MUSS, falls für den Aufruf des E-Rezept-Fachdienstes kein gültiger IDACCESS_TOKEN  sowie kein gültiger ACCESS_CODE vorliegt, die TI-Session starten. [<=]

A_20035 - E-Rezept-FdV: TI-Session starten

Das E-Rezept-FdV MUSS zum Start der TI-Session die Aktivität "Authentisierung des Nutzers gegenüber TI"  ausführen. [<=]

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.

A_19481 - E-Rezept-FdV: Löschen der App-Session-Daten

Das E-Rezept-FdV MUSS zum Beenden der App-Session die IDACCESS_TOKEN und den ACCESS_CODE sicher löschen . [<=]

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.

A_19482 - E-Rezept-FdV: Beenden der TI-Session

Das E-Rezept-FdV MUSS zum Beenden der TI-Session

• bestehende TLS-Verbindungen zu den Diensten der TI abbauen,
• die Schlüssel für die sichere Verbindung zur VAU des E-Rezept-Fachdienstes löschen und
• alle IDACCESS_TOKEN und ACCESS_CODE löschen.

[<=]

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.

A_19346 - E-Rezept-FdV: E-Rezepte herunterladen

Das E-Rezept-FdV MUSS die  Anwendungsfälle "UC 3.1 - E-Rezepte durch Versicherten abrufen" und "UC 3.6 - E-Rezept durch Vertreter abrufen" aus [gemSysL_eRp] gemäß TAB_FdVERP_007 umsetzen. 

Tabelle 6 : TAB_FdVERP_007 – E-Rezepte abrufen 

[<=]

Standardablauf: E-Rezept herunterladen

A_19347 - E-Rezept-FdV: E-Rezept herunterladen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezepte empfangen" zum Herunterladen alle E-Rezepte des Nutzers die HTTP-Operation GET /Task mit

1.                      IDACCESS_TOKEN im Authorization-Header

ausführen. [<=]

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. 

A_20053 - E-Rezept-FdV: FHIR-Signatur prüfen

Das E-Rezept-FdV MUSS die FHIR-Signatur des E-Rezept-Bundles aus dem vom E-Rezept-Fachdienst heruntergeladenen E-Rezept gemäß [RFC7515#5.2] prüfen und bei negativer Prüfung die Verarbeitung abbrechen. [<=]

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

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

A_19348 - E-Rezept-FdV: E-Rezept im E-Rezept-FdV speichern

Das E-Rezept-FdV MUSS es dem Versicherten ermöglichen, die vom E-Rezept-Fachdienst heruntergeladenen E-Rezepte im lokalen Speicher persistent abzulegen. [<=]

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.

A_19350 - E-Rezept-FdV: Spezifisches E-Rezept herunterladen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezepte empfangen" zum Herunterladen eines spezifischen E-Rezepts des Nutzers die HTTP-Operation GET /Task/<id> mit

1.                      IDACCESS_TOKEN im Authorization-Header
2.                      Task-ID in URL <id>

ausführen. [<=]

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 E-RezeptTask-ID und der AccessCode dieses Rezepts im E-Rezept-FdV bekannt sein. Die Informationen E-RezeptTask-ID und AccessCode werden im E-Rezept-Token übermittelt.

A_19351 - E-Rezept-FdV: E-Rezept mit AccessCode herunterladen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezepte empfangen" zum Herunterladen eines E-Rezepts als Vertreter die HTTP-Operation GET /Task/<id> mit

• IDACCESS_TOKEN im http-Header
• RezeptTask-ID in URL <id>
• AccessCode im http-Header

ausführen. [<=]

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.

A_19349 - E-Rezept-FdV: E-Rezept im Frontend anzeigen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die lokal gespeicherten E-Rezepte in geeigneter Weise anzuzeigen. [<=]

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.

A_19579 - E-Rezept-FdV: Zugriff auf Geräte-Kamera

Das E-Rezept-FdV MUSS zum Einscannen eines 2D-Codes auf die Kamera des verwendeten Gerätes zugreifen. [<=]

A_19483 - E-Rezept-FdV: 2D-Code einscannen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, einen 2D-Code einzuscannen. [<=]

A_20005 - E-Rezept-FdV: 2D-Code

Das E-Rezept-FdV MUSS einen eingescannten 2D-Code decodieren und die darin enthaltenen Daten zu einem oder mehreren  E-Rezepten (Task-ID, AccessCode) im E-Rezept-FdV speichern. [<=]

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 und Vertreter) einzelne ausgewählte oder alle E-Rezepte, die auf dem E-Rezept-Fachdienst gespeichert sind, löschen.

A_19219 - E-Rezept-FdV: E-Rezepte löschen - E-Rezepte zum Löschen auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein oder mehrere E-Rezepte aus der Übersicht aller E-Rezepte zum Löschen auf dem Fachdienst zu markieren. [<=]

A_19220 - E-Rezept-FdV: E-Rezept löschen - Bestätigung

Das E-Rezept-FdV MUSS vom Nutzer eine Bestätigung einholen, dass die selektierten E-Rezepte gelöscht werden sollen und die Möglichkeit geben, das Löschen abzubrechen. [<=]

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.

A_19221 - E-Rezept-FdV: E-Rezepte löschen

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.2 - E-Rezept durch Versicherten löschen" aus [gemSysL_eRp] gemäß TAB_FdVERP_008 umsetzen. 

Tabelle 7 : TAB_FdVERP_008 – E-Rezepte löschen

[<=]

A_19222 - E-Rezept-FdV: E-Rezept löschen - Löschrequest

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezepte löschen" für jedes zu löschende E-Rezept die HTTP-Operation POST /Task/<id>/$abort des E-Rezept-Fachdienstes mit

1.                      IDACCESS_TOKEN im Authorization-Header
2.                      RezeptTask-ID in URL <id>
3.                      optional: AccessCode im x-AccessCode-Header

ausführen. [<=]

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

A_19223 - E-Rezept-FdV: E-Rezept löschen - E-Rezept-Token löschen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezepte löschen" für jedes zu löschende E-Rezept nach erfolgreichem Aufruf der Operation "Ein E-Rezept löschen" die Daten zum E-Rezept-Token lokal löschen. [<=]

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.

A_19227 - E-Rezept-FdV: E-Rezepte lokal löschen - E-Rezepte zum Löschen auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein oder mehrere E-Rezepte aus der Übersicht aller E-Rezepte zum Löschen im E-Rezept-FdV zu markieren. [<=]

A_19228 - E-Rezept-FdV: E-Rezepte lokal löschen - Bestätigung

Das E-Rezept-FdV MUSS vom Nutzer eine Bestätigung einholen, dass die selektierten E-Rezepte lokal gelöscht werden sollen und die Möglichkeit geben, das Löschen abzubrechen. [<=]

A_19229 - E-Rezept-FdV: E-Rezepte lokal löschen - Löschen

Das E-Rezept-FdV MUSS alle Daten, d.h. die E-Rezept Daten als auch alle damit verknüpften Daten, zu den lokal zu löschenden E-Rezepten im E-Rezept-FdV löschen. [<=]

5.2.3.10 Verfügbarkeit von per E-Rezept verordneter MedikamenteAnfrage zur Belieferung von E-Rezepten bei einer Apotheke anfragen

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 VerfügbarkeitsanfrageAnfrage 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 VerfügbarkeitsanfrageAnfrage 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 VerfügbarkeitsanfrageAnfrage 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 VerfügbarkeitsanfrageAnfrage 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 VerfügbarkeitsanfrageAnfrage 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.

A_19189 - E-Rezept-FdV: VerfügbarkeitsabfrageAnfrage Belieferung - Apotheke auswählen

Das E-Rezept-FdV MUSS es im Anwendungsfall "Verfügbarkeit eines E-Rezepts anfragen" dem Nutzer ermöglichen, eine Apotheke für die VerfügbarkeitsanfrageAnfrage zur Belieferung durch eine Apotheke auszuwählen.  [<=]

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.

A_19190 - E-Rezept-FdV: VerfügbarkeitsabfrageAnfrage Belieferung - E-Rezept auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein E-Rezept für eine VerfügbarkeitsanfrageAnfrage zur Belieferung durch eine Apotheke zu markieren. [<=]

A_19191 - E-Rezept-FdV: VerfügbarkeitsabfrageAnfrage Belieferung - freie Textnachricht

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, eine freie Textnachricht zu verfassen, welche der Nachricht an die Apotheke hinzugefügt wird. [<=]

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. 

A_20010 - E-Rezept-FdV: VerfügbarkeitsabfrageAnfrage Belieferung - Textnachricht ohne Link

Das E-Rezept-FdV MUSS prüfen, dass die durch den Nutzer erfasst Textnachricht keinen Internet-Link und keine  Non-Printable-Characters enthält und die Textnachricht nur bei erfolgreicher Prüfung weiterverarbeiten. [<=]

A_19192 - E-Rezept-FdV: Verfügbarkeit eines E-Rezepts anfragen

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.3 - Nachrichten durch Versicherten übermitteln" aus [gemSysL_eRp] für eine VerfügbarkeitsanfrageAnfrage zur Belieferung durch eine Apotheke gemäß TAB_FDVERP_009 umsetzen.  

Tabelle 8 : TAB_FdVERP_009 - Verfügbarkeit von per E-Rezept verordneter Medikamente bei einer Apotheke erfragen

[<=]

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.

A_19194 - E-Rezept-FdV: VerfügbarkeitsabfrageAnfrage Belieferung - Nachricht erstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Verfügbarkeit eines E-Rezepts anfragen" eine FHIR Ressource Communication des Profils https://gematik.de/fhir/StructureDefinition/erxCommunicationInfoReq  mit 

1.                      Telematik-ID der ausgewählten abgebenden LEI in recipient
2.                      Textnachricht in payload
3.                      Medication-Objekt aus dem E-Rezept-Bundle in about reference als contained Objekt
4.                      optional: IK-Nummer der Kasse des Versicherten aus dem E-Rezept-Bundle als Identifier-Referenz in payload 
5.                      erstellen. [<=] Aut-Idem-Feld entsprechend der Festlegung im E-Rezept-Bundle
6.                      Rezepttyp als Wert des Flowtypes im Task des E-Rezept-Workflows
7.                      optional: bevorzugte Belieferungsoptionen ["Apotheke", "Bote", "Versand"] 

erstellen. [<=]

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

A_19196 - E-Rezept-FdV: VerfügbarkeitsabfrageAnfrage Belieferung - Nachricht auf E-Rezept-Fachdienst einstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Verfügbarkeit eines E-Rezepts anfragen" zur Übergabe der Nachricht an die einlösende Apotheke die HTTP-Operation POST /Communication  mit

• IDACCESS_TOKEN im Authorization-Header
• Communication Ressource im HTTP-Request-Body

ausführen. [<=]

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.

A_19197 - E-Rezept-FdV: E-Rezept zuweisen - Apotheke auswählen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezept einer Apotheke zuweisen" es dem Nutzer ermöglichen, eine Apotheke zum Zuweisen des E-Rezepts auszuwählen. [<=]

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.

A_19198 - E-Rezept-FdV: E-Rezept zuweisen - E-Rezept auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein E-Rezept für das Zuweisen an eine Apotheke zu markieren. [<=]

A_19199 - E-Rezept-FdV: E-Rezept zuweisen - freie Textnachricht

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, eine freie Textnachricht zu erfassen, welche der Nachricht an die Apotheke hinzugefügt wird. [<=]

Hinweis: Die Textnachricht ist optional.

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

A_20011 - E-Rezept-FdV: Textnachricht ohne Link

Das E-Rezept-FdV MUSS prüfen, dass die durch den Nutzer erfasst Textnachricht keinen Internet-Link und keine  Non-Printable-Characters enthält und die Textnachricht nur bei erfolgreicher Prüfung weiterverarbeiten. [<=]

A_19200 - E-Rezept-FdV: E-Rezept einer Apotheke zuweisen

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" aus [gemSysL_eRp] für das Zuweisen eines E-Rezepts gemäß TAB_FdVERP_010 umsetzen.

Tabelle 9 : TAB_FdVERP_010 – E-Rezept einer Apotheke zuweisen

[<=]

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

A_19201 - E-Rezept-FdV: E-Rezept zuweisen - Nachricht erstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezept einer Apotheke zuweisen" eine FHIR Ressource Communication des Profils https://gematik.de/fhir/StructureDefinition/erxCommunicationDispReq  mit  

• Telematik-ID der ausgewählten abgebenden LEI in recipient
• Textnachricht in payload contentString
• E-Rezept-Token in basedOn reference auf Task inkl. AccessCode als "/Task/<id>/$accept?ac=..." 

erstellen. [<=]

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

A_19203 - E-Rezept-FdV: E-Rezept zuweisen - Nachricht auf E-Rezept-Fachdienst einstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezept einer Apotheke zuweisen" zur Übergabe des Tokens an die einlösende Apotheke die HTTP-Operation POST /Communication  mit

• IDACCESS_TOKEN im Authorization-Header
• Communication Ressource in HTTP-Request-Body

ausführen. [<=]

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

A_20232 - E-Rezept-FdV: Vertreterkommunikation - KVNR des Vertreters erfassen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die KVNR des Empfängers der Nachricht zu erfassen. [<=]

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.

A_20233 - E-Rezept-FdV: Vertreterkommunikation - E-Rezept auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, ein E-Rezept für die Kommunikation mit dem Vertreter auszuwählen. [<=]

A_20234 - E-Rezept-FdV: Vertreterkommunikation - freie Textnachricht

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, eine freie Textnachricht zu erfassen, welche der Nachricht an den Vertreter hinzugefügt wird. [<=]

Hinweis: Die Textnachricht ist optional.

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

A_20235 - E-Rezept-FdV: Vertreterkommunikation

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" aus [gemSysL_eRp] für die Vertreterkommunikation gemäß TAB_FdVERP_015 umsetzen.

Tabelle 10 : TAB_FdVERP_015 – Vertreterkommunikation

[<=]

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

A_20237 - E-Rezept-FdV: Vertreterkommunikation - Nachricht erstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "Vertreterkommunikation" eine FHIR Ressource Communication des Profils https://gematik.de/fhir/StructureDefinition/erxCommunicationRepresentative  mit 

1.                      KVNR des Vertreters in recipient
2.                      Textnachricht in payload contentString
3.                      E-Rezept-Token in basedOn reference auf Task inkl. AccessCode als "/Task/<id>?ac=..." 

erstellen. [<=]

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

A_20236 - E-Rezept-FdV: Vertreterkommunikation - Textnachricht

Das E-Rezept-FdV MUSS im Anwendungsfall "Vertreterkommunikation" in der Communication-Ressource der optionalen Text ein Präfix "<Absendername> schreibt: " voranstellen, sodass die Communication-Ressource immer mindestens den Absendernamen in der Textnachricht enthält. [<=]

A_20238 - E-Rezept-FdV: Vertreterkommunikation - Nachricht auf E-Rezept-Fachdienst einstellen

Das E-Rezept-FdV MUSS im Anwendungsfall "E-Rezept einer Apotheke zuweisen" zur Übergabe des Tokens an die einlösende Apotheke die HTTP-Operation POST /Communication  mit

• IDACCESS_TOKEN im Authorization-Header
• Communication Ressource in HTTP-Request-Body

ausführen. [<=]

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.

A_19668 - E-Rezept-FdV: 2D-Code anzeigen - E-Rezepte auswählen

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, lokal gespeicherte E-Rezepte für die Anzeige in einem 2D-Code auszuwählen. [<=]

A_19669 - E-Rezept-FdV: 2D-Code anzeigen - E-Rezept-Token erstellen

Das E-Rezept-FdV MUSS für die ausgewählten E-Rezepte die E-Rezept-Token erstellen. [<=]

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

A_19474 - E-Rezept-FdV: 2D-Code anzeigen

Das E-Rezept-FdV MUSS mit den erstellten E-Rezept-Token 2D-Codes erstellen und auf dem Display des Endgerätes anzeigen. [<=]

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

A_19671 - E-Rezept-FdV: 2D-Code anzeigen - Kontrast

Das E-Rezept-FdV MUSS 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. [<=]

A_19672 - E-Rezept-FdV: 2D-Code anzeigen - Ruhebereich

Das E-Rezept-FdV MUSS 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. [<=]

A_20181 - E-Rezept-FdV: 2D-Code anzeigen - personenbezogene Daten

Das E-Rezept-FdV DARF NICHT personenbezogene Daten zusammen mit der Anzeige des 2D-Codes anzeigen. [<=]

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 VerfügbarkeitsanfrageAnfrage 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 VerfügbarkeitsanfrageAnfrage 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.

A_19477 - E-Rezept-FdV: Apotheke suchen - Suchkriterien eingeben

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, Kriterien für die Suche nach Apotheken einzugeben. [<=]

A_19478 - E-Rezept-FdV: Apotheke suchen - Ortungsfunktion

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, über die Ortungsfunktion des verwendeten Gerätes den aktuellen Standort zu ermitteln, um diesen für eine Umkreissuche von Apotheken zu verwenden. [<=]

A_19731 - E-Rezept-FdV: Apotheke suchen

Das E-Rezept-FdV MUSS den Anwendungsfall "Apotheke suchen" gemäß TAB_FdVERP_011 umsetzen.

Tabelle 11 : TAB_FdVERP_011 – Apotheke suchen

[<=]

A_19953 - E-Rezept-FdV: Apotheke suchen - Suchkriterium Apotheke

Das E-Rezept-FdV MUSS im Anwendungsfall "Apotheke suchen" mindestens das Suchkriterium Apotheke ("type=urn:oid|1.2.276.0.76.4.32") angeben. [<=]

A_20208 - E-Rezept-FdV: Apotheke suchen - Nutzung Verzeichnisdienst

Das E-Rezept-FdV MUSS den Verzeichnisdienst ausschließlich zum Abruf von Apothekeninformationen nutzen und darf den Verzeichnisdienst nicht nach weiteren Einträgen durchsuchen. [<=]

A_19475 - E-Rezept-FdV: Apotheke suchen - Suchabfrage Verzeichnisdienst

Das E-Rezept-FdV MUSS im Anwendungsfall "Apotheke suchen" zur Suche einer Apotheke im Verzeichnisdienst die HTTP-Operation GET /Organization mit

1.                      IDACCESS_TOKEN im Authorization-Header
2.                      Suchoption "type=urn:oid|1.2.276.0.76.4.32"
3.                      weitere Suchoptionen gemäß https://www.hl7.org/fhir/organization/#searchhttps://www.hl7.org/fhir/organization.html#search 

ausführen. [<=]

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

A_20226 - E-Rezept-FdV: Apotheke suchen: Suchergebnis vollständig anzeigen

Das E-Rezept-FdV MUSS es dem Versicherten ermöglichen, sich alle Einträge aus einem Suchergebnis anzeigen zu lassen. [<=]

A_20183 - E-Rezept-FdV: Apotheke suchen: neutrale Darstellung Suchergebnisse

Das E-Rezept-FdV MUSS ein Suchergebniss so darstellen, dass einzelne Apotheken nicht hervorgehoben oder bevorzugt werden. [<=]

A_19479 - E-Rezept-FdV: Filterfunktion

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, die Suchergebnisse nach festgelegten Kriterien zu filtern.  [<=]

A_19476 - E-Rezept-FdV: Stammapotheke speichern

Das E-Rezept-FdV MUSS es dem Nutzer ermöglichen, mindestens fünf Apotheken als Stammapotheke in der Konfiguration zu speichern. [<=]

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 über den Eingang neuer Informationen zur Abgabe benachrichtigt werden, so dass ich weiß, dass ich sie jetzt ansehen und speichern kann. 

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

•   Als Patient möchte ich über den Eingang neuer Nachrichten von einer Apotheke benachrichtigt werden, so dass ich weiß, dass ich sie jetzt ansehen und gegebenenfalls reagieren kann.

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

A_19204-01 - E-Rezept-FdV: Nachrichten von Apotheken anzeigen

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.4 - Nachrichten durch Versicherten empfangen" aus [gemSysL_eRp] gemäß TAB_FdVERP_012 umsetzen.

Tabelle 12 : TAB_FdVERP_012 – Nachrichten durch Versicherten empfangen

[<=]

A_19205 - E-Rezept-FdV: Nachrichten anzeigen - Nachrichten herunterladen

Das E-Rezept-FdV MUSS im Anwendungsfall "Nachrichten von Apotheken anzeigen" zum Herunterladen von Nachrichten vom E-Rezept-Fachdienst die HTTP-Operation GET /Communication  mit

1.                      IDACCESS_TOKEN im Authorization-Header
2.                      optional: ?received=null für nur ungelesene Nachrichten
3.                      optional: ?received=gtYYYY-MM-DD_sort=sent für Nachrichten jünger als Datum DD.MM.YYY

ausführen. [<=]

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

A_19207 - E-Rezept-FdV: Nachrichten anzeigen - Nachricht speichern

Das E-Rezept-FdV MUSS die vom E-Rezept-Fachdienst heruntergeladenen Nachrichten im lokalen Speicher persistent ablegen. [<=]

A_19208 - E-Rezept-FdV: Nachrichten anzeigen - Anzeigen

Das E-Rezept-FdV MUSS die vom E-Rezept-Fachdienst heruntergeladenen Nachrichten in geeigneter Weise anzeigen. [<=]

A_19486 - E-Rezept-FdV: Benachrichtigung über eingegangene Nachrichten

Das E-Rezept-FdV MUSS den Nutzer über eingegangene Nachrichten benachrichtigen, wenn die Benachrichtigung in der Konfigurationseinstellung aktiviert ist. [<=]

A_19624 - E-Rezept-FdV: Nachrichten lokal verwalten

Das E-Rezept-FdV MUSS ein Löschen für die im lokalen Speicher persistent ablegten Nachrichten anbieten. [<=]

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

A_19344 - E-Rezept-FdV: Abgabeinformationen abrufen

Das E-Rezept-FdV MUSS den Anwendungsfall für das Abrufen der Abgabeinformationen gemäß TAB_FdVERP_013 umsetzen.

Tabelle 13 : TAB_FdVERP_013 – Abgabeinformation abrufen

[<=]

A_19345 - E-Rezept-FdV: Abgabeinformationen abfragen - MedicationDispense abrufen

Das E-Rezept-FdV MUSS im Anwendungsfall "Abgabeinformationen abfragen" die HTTP-Operation GET /MedicationDispense  mit

1.                      IDACCESS_TOKEN im Authorization-Header
2.                      optional: Suchparameter gemäß https://www.hl7.org/fhir/medicationdispense/#searchhttps://www.hl7.org/fhir/medicationdispense.html#search 

ausführen. [<=]

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

A_19647 - E-Rezept-FdV: Abgabeinformation abfragen - MedicationDispense im E-Rezept FdV speichern

Das E-Rezept-FdV MUSS die vom E-Rezept-Fachdienst heruntergeladenen Informationen zum abgegebenen Mittel im lokalen Speicher persistent speichern. [<=]

A_20036 - E-Rezept-FdV: Anzeige der Abgabeinformationen

Das E-Rezept-FdV MUSS dem Nutzer die AngabeinformationenAbgabeinformationen in geeigneter Weise anzeigen [<=]

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

A_19209 - E-Rezept-FdV: Protokolldaten anzeigen

Das E-Rezept-FdV MUSS den Anwendungsfall "UC 3.5 - Protokolldaten abrufen" aus [gemSysL_eRp] gemäß TAB_FdVERP_014 umsetzen.

Tabelle 14 : TAB_FdVERP_014 – Protokolldaten anzeigen

[<=]

A_19210 - E-Rezept-FdV: Protokolldaten anzeigen - Protokolleinträge abrufen

Das E-Rezept-FdV MUSS im Anwendungsfall "Protokolldaten anzeigen" zum Abrufen der Protokolleinträge vom E-Rezept-Fachdienst die HTTP-Operation GET /AuditEvent mit 

1.                      IDACCESS_TOKEN im Authorization-Header

ausführen. [<=]

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)

A_19211 - E-Rezept-FdV: Protokolldaten anzeigen - Anzeigen

Das E-Rezept-FdV MUSS eine Anzeige für die Protokolldaten umsetzten, in der die Protokolleinträge übersichtlich dargestellt werden. [<=]

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.

A_19560 - E-Rezept-FdV: Abbrechen des Anwendungsfalls

Das E-Rezept-FdV MUSS, wenn bei der Abarbeitung der Aktivitäten eines Anwendungsfalls ein Fehler auftritt und keine Fehlerbehandlung beschrieben ist, den Anwendungsfall abbrechen. [<=]

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.

A_19561 - E-Rezept-FdV: Anzeige von Handlungsmöglichkeiten im Fehlerfall

Das E-Rezept-FdV SOLL dem Nutzer im Fehlerfall einen Hinweis geben, wenn es für den Nutzer Handlungsmöglichkeiten dazu gibt. [<=]

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 

VerfügbarkeitsanfrageAnfrage 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

Abbildung 1 : ABB_FDVERP_001 Systemüberblick FdV

8.4 Tabellenverzeichnis

Tabelle 1 : TAB_FdVERP_001 – Akteure und Rollen

Tabelle 2 : TAB_FdVERP_002 – Konfigurationsparameter

Tabelle 3 TAB_FdVERP_017 – Zertifikatsnutzung

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

Tabelle 5 : TAB_FdVERP_005 – App-Session starten

Tabelle 6 : TAB_FdVERP_007 – E-Rezepte abrufen

Tabelle 7 : TAB_FdVERP_008 – E-Rezepte löschen

Tabelle 8 : TAB_FdVERP_009 - Verfügbarkeit von per E-Rezept verordneter Medikamente bei einer Apotheke erfragen

Tabelle 9 : TAB_FdVERP_010 – E-Rezept einer Apotheke zuweisen

Tabelle 10 : TAB_FdVERP_015 – Vertreterkommunikation

Tabelle 11 : TAB_FdVERP_011 – Apotheke suchen

Tabelle 12 : TAB_FdVERP_012 – Nachrichten durch Versicherten empfangen

Tabelle 13 : TAB_FdVERP_013 – Abgabeinformation abrufen

Tabelle 14 : TAB_FdVERP_014 – Protokolldaten anzeigen

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