Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

E-Rezept-Anwendung des Versicherten

    

     

      
Version
      
1.1.1
     
     

      
Revision
      
784618
     
     

      
Stand
      
28.04.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_eRp_AdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

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

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von Produkten des Produkttypen E-Rezept-Anwendung des Versicherten (gematik) 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. Produkttypsteckbrief, Leistungsbeschreibung, ...) festgelegt und bekanntgegeben.

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-Anwendung des Versicherten verzeichnet.

Diese Spezifikation beschreibt Anforderungen zu den Aspekten Sicherheit, Interoperabilität und Funktionalität. Die konkrete Ausgestaltung der Benutzeroberfläche (GUI) und der Benutzerführung (UX) wird während der Entwicklung festgelegt und ist nicht Teil dieser Spezifikation.

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.

User Stories

Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. [Wikepedia:User Storie]
Aus diesem Grund kann in den User Stories eine abweichende Terminologie genutzt werden, welche für den Leser nachvollziehbar (bspw. Patient = Versicherter) ist.

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:

2 Systemüberblick

Die E-Rezept-Anwendung des Versicherten (E-Rezept-AdV) ist eine Anwendung für den Versicherten, welche die für die Wahrnehmung der Rechte der informationelle Selbstbestimmung in der Fachanwendung E-Rezept notwendigen Funktionalitäten bündelt und dezentrale Fachlogik der Fachanwendung E-Rezept ausführt.

Ausführungsumgebung der E-Rezept-AdV ist ein stationäres Gerät des Versicherten (GdV). Es steht unter alleiniger Kontrolle des Versicherten. Dem Versicherten obliegt es, durch geeignete Maßnahmen die Sicherheit der Daten zu stärken.

Unterschiede zum E-Rezept-FdV bestehen in der Ausführungsumgebung und im reduzierten Umfang der für den Nutzer ausführbaren Anwendungsfälle.

3 Systemkontext

3.1 Akteure und Rollen

Im Systemkontext der E-Rezept-AdV interagieren verschiedene Akteure (aktive Komponenten) in unterschiedlichen Rollen mit der E-Rezept-AdV.

Tabelle 1 : TAB_AdVERP_001 – Akteure und Rollen

3.2 Nachbarsysteme

Die von der E-Rezept-AdV direkt erreichbaren Produkttypen der TI sind

• Identity Provider (IDP)
• E-Rezept-Fachdienst
• elektronische Gesundheitskarte (eGK)

Abbildung 1 : Systemüberblick E-Rezept-AdV

Identity Provider

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

E-Rezept-Fachdienst

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

Authenticator-Modul

Das Authenticator-Modul ist eine logische Komponente in der E-Rezept-AdV. Das Authenticator-Modul kapselt funktionale Anteile des Authentifizierungsprozesses und die Kommunikation mit der Smart Card des Nutzers. Im Authentisierungsprozess übernimmt das Authenticator-Modul die Rolle Authenticator-Modul und das E-Rezept-AdV die Rolle Anwendungsfrontend. Siehe [gemSpec_IDP_FD].
Für die Authentisierung mittels eGK greift die E-Rezept-AdV über die kontaktbehaftete Schnittstelle oder 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 einen Kartenleser benötigt.

4 Übergreifende Festlegungen

4.1 Datenschutz und Sicherheit

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

Hinweis: Beim Erstbezug der E-Rezept-AdV kann die Prüfung der Authentizität der Quelle noch nicht durch die E-Rezept-AdV selbst erfolgen. Dies kann z.B. über eine TLS-Serverauthentifizierung der Bezugsquelle oder das Einstellen der E-Rezept-AdV in einen vertrauenswürdigen Store erreicht werden.

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 (bspw. Internet, Sensoren des Geräts) zusammengeführt werden.

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

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

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

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

4.1.1 Anforderungen zum Herstellungsprozess

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

4.1.2 Unterstützung von Audits

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

4.2 Benutzeroberfläche

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

Ausführungen zur visuellen Darstellung, Usability und zu geltenden technischen Normen werden im Dokument [gemSpec_eRp_FdV] beschrieben.

Die konkrete Ausgestaltung der GUI und der Benutzerführung wird während der Entwicklung festgelegt und in diesem Dokument nicht weiter behandelt.

4.3 Konfiguration der E-Rezept-AdV

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

4.4 Logging

Die E-Rezept-AdV 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 der E-Rezept-AdV 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 Crash Reporting). Für Testzwecke soll ein Logging zur Fehleranalyse möglich sein. 

5 Funktionsmerkmale

5.1 Allgemein

5.1.1 Session-Verwaltung

Eine Authentisierung gegenüber der TI nach dem Start der Anwendung erfolgt automatisch.

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 ein Authentisierungsmodul, welche Bestandteil der E-Rezept-AdV ist oder als eigenständige Komponente ebenfalls auf dem Gerät des Versicherten (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.

Der Versicherte weist sich gegenüber der TI mit der Identität der eGK aus.

Die Anbindung der eGK an das GdV kann mittels kontaktloser NFC-Schnittstelle oder der kontaktbehafteten Schnittstelle erfolgen.

Die Authentisierung des Nutzers erfolgt mittels eGK, MRPIN.home und, falls die NFC Schnittstelle genutzt wird, der CAN.

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

Für die Aktivität "Authentisierung des Nutzers gegenüber TI" siehe Kapitel 5.1.3 .

5.1.2 Kommunikation mit Diensten der TI

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

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

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

Für Informationen zur Nutzung der TLS siehe [gemSpec_Krypt].

Für Informationen zur Produktidentifikation siehe [gemSpec_OM].

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

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

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

5.1.3 Authentisierung des Nutzers für Dienste der TI

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

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

5.1.4 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 die E-Rezept-AdV und der Vertrauenswürdigen Ausführungsumgebung (VAU) im E-Rezept-Fachdienst gesichert.

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

5.1.5 Zertifikatsprüfung

Die E-Rezept-AdV verwendet bei den in TAB_FdVERP_017 dargestellten Aktivitäten Zertifikate.

Tabelle 4 : TAB_FdVERP_017 – Zertifikatsnutzung

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

"Ein Zertifikat aktiv verwenden" bedeutet im Sinne von A_19739, dass eine E-Rezept-AdV 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 die E-Rezept-AdV ein Datenobjekt, in dem Signaturen und Zertifikate enthalten sind und behandelt es dieses als opakes Datenobjekt, ohne die Zertifikate darin gesondert zu betrachten, dann verwendet die E-Rezept-AdV diese Zertifikate im Sinne von A_19739 passiv.

5.1.5.1 Zertifikatsprüfung von Zertifikaten der TI

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

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

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

5.1.5.2 Zertifikatsprüfung von Internet-Zertifikaten

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

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

5.2 E-Rezept Anwendungsfälle in der E-Rezept-AdV

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

5.2.1 Anwendungsfälle

5.2.1.1 E-Rezepte einsehen

User Stories:

• Als Patient möchte ich nach Authentisierung in der E-Rezept-AdV alle meine Verordnungen einsehen können, so dass ich einen Überblick über meine Verordnungen behalte.
• Als Patient möchte ich die relevanten Informationen aus einem E-Rezept lesen können, so dass ich weiß, was mir verschrieben wurde.
• 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.

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

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 u.a. die folgenden fachlichen Informationen:

• Task-ID (Task.id), mit dem der Task bei Aufrufen des E-Rezept-Fachdienstes referenziert wird
  
• 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 prüft die FHIR-Signatur des E-Rezept-Bundles. Hierzu wird das base64-kodierte data Element aus  signature dekodiert. Es enthält eine JSON Web Signature mit Information zum Algorithmus, eine Referenz zum Zertifikat und die signierten Daten. 

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

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

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:

• bei Fertigarzneimitteln: Pharmazentralnummer (sofern vorhanden)
• Beschreibung des Arzneimittels

Mittels der Task-ID können die Dispensierinformationen den E-Rezepten zugeordnet werden.

5.2.1.2 E-Rezepte löschen

User Stories:

• Als Patient möchte ich nach Authentisierung in der E-Rezept-AdV einzelne Verordnungen löschen können, so dass ich E-Rezepte, die ich nicht benötige, permanent entfernen kann und diese nicht mehr einsehbar sind und ich mein Recht auf informationelle Selbstbestimmung ausüben kann.
• Als Patient möchte ich verstehen können, welche Konsequenzen das Löschen von E-Rezepten hat, so dass ich mir der Tragweite meines Handelns bewusst sein kann.
• Als Patient möchte ich, dass mich die E-Rezept-AdV davor bewahrt, ein E-Rezept aus Versehen zu löschen, so dass ich keine Fehler mache und damit meine Therapie gefährde.
• 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 eine Rückmeldung darüber erhalten, wenn das Löschen fehlgeschlagen ist, so dass ich auf anderem Wege eine Löschen einleiten kann.

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

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

5.2.1.3 Protokolldaten anzeigen

User Stories:

• Als Patient möchte ich nach Authentisierung im E-Rezept-AdV die Zugriffsprotokolle einzelner oder aller Verordnungen einsehen können, um nachzuvollziehen wer darauf zugegriffen hat
• Als Patient möchte ich, dass mein Protokoll so dargestellt wird, dass ich mit den Informationen auch was anfangen kann, so dass die Protokolleinträge für mich nicht nutzlos oder sogar verwirrend sind.

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

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

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

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

Die E-Rezept-AdV 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.1.4 Nachrichten empfangen

User Stories:

·        Als Versicherter möchte ich, dass ich Nachrichten von meiner Apotheke empfangen kann.

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

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

Der Response liefert ein Bundle mit Communication Ressourcen.

Eine Communication Ressource beinhaltet u.a. die fachlichen Informationen:

• Absender-ID (Telematik-ID der Apotheke)
• Mitteilung
  Für die strukturierten Informationen in der Mitteilung siehe [gemILF_PS_eRp]

5.2.1.5 Nachrichten löschen

User Stories:

• Als Versicherter möchte ich auf dem Fachdienst gespeicherte Nachrichten löschen können.

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

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

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

Die E-Rezept-AdV 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 die E-Rezept-AdV den Nutzer auf die Lösung hinweisen.

6 Informationsmodell

Dienste der TI:

Session-Daten (TI-Session) 

E-Rezept:

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

MedicationDispense 

Protokolleintrag:

7 Verteilungssicht

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

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

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

8.5.2 Weitere Dokumente