Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

E-Rezept-Frontend des Versicherten im KTR-AdV-Terminal

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
05.06.2020
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSpec_eRp_FdV_AdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

<<kurze Beschreibung der inhaltlichen Änderungen (max. ½ Seite)>>

Dokumentenhistorie

<<Genereller Hinweis:

Hidden Text wird blau dargestellt

In doppelten spitzen Klammen gefasste Mustertexte der Vorlage sind Hidden Text und sind für die Druckaufbereitung normalerweise ausgeblendet.

In einfachen spitzen Klammern gesetzte Begriffe sind Platzhalter und sinngemäß auszutauschen bzw. zu entfernen.

Alle Anforderungen und Abbildungen sind Muster und zu entfernen.

Fachliche Formulierungen und Abbildungen aus dem Kontext der TI sind beispielhaft und müssen entfernt werden

Weitere Hinweise – insbesondere zum Umgang mit Anforderungen – siehe Kap. 2.>>

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

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

1.2 Zielgruppe

Das Dokument richtet sich den Hersteller von Produkten des Produkttypen E-Rezept Frontend des Versicherten,im KTR-AdV-Terminal 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 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-Frontend des Versicherten im KTR-AdV-Terminal 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 imKTR-AdV-Terminal (E-Rezept-FdV-AdV) 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-AdV ist dasKTR-AdV-Terminal. 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_xxx – Akteure und Rollen

3.2 Nachbarsysteme

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

• Identity Provider (IdP)
• Authentisierungsmodul des IdP
• E-Rezept-Fachdienst
• Verzeichnisdienst 
• eGK

4 Zerlegung des Produkttyps

<<Optional: Falls eine weitere Zerlegung des Produkttyps in Teilsysteme nötig ist, erfolgen alle Festlegungen hierzu in diesem Kapitel. Im weitern Verlauf des Dokuments kann auf die hier festgelegte Teilsysteme zurückgegriffen werden. Speziell können übergreifende Anforderungen für die Teilsysteme gestellt werden (Kapitel 6) und die Funktionsmerkmale die Teilsysteme konkretisieren (Kapitel 7). Das Kapitel muss auch dann erhalten bleiben, wenn keine weitere Zerlegung stattfindet.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

Eine weiter Untergliederung der Aufbaustruktur des Produkttyps ist nicht erforderlich.>>

5 Übergreifende Festlegungen

<<Sofern es Festlegungen für den Produkttyp und seine Teilsysteme aus Kap. 5 gibt, die sich nicht  einem Funktionsmerkmal zuordnen lassen, werden diese hier erhoben.>>

5.1 Datenschutz und Sicherheit

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

...

5.1.1 Anforderungen zum Herstellungsprozess

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

5.2 Benutzeroberfläche

Anforderungen siehe gemSpecKTR-AdV-Terminal

6 Funktionsmerkmale

<<Vollständig funktionale Zerlegung der Funktionen des Produkttyps in Funktionsmerkmale. I.d.R. ergeben sich die Funktionsmerkmale 1:1 aus den systemspezifischen Konzepten der TI-Plattform. Für die Architektur sind dies die in gemKPT_Arch_TIP definierten Basis-, Infrastruktur- und Netzwerkdienste mit Relevanz für den Produkttyp.>>

<<Ggf. Übersicht aller Funktionsmerkmale und Schnittstellstellen in geeigneter Form>>

<<Hinweis zur Struktur: Sollte nur genau ein Funktionsmerkmal zu beschreiben sein, sollte die überflüssige Gliederungsebene ausgelassen werden und alle untergeordneten Kapitel rücken dementsprechend eine Ebene höher – die Kapitelüberschrift der Eben 1 „7 Funktionsmerkmale“ wird dann ersetzt durch den Titel des Funktionsmerkmals – dann z. B. „7 Basisdienst Kartenverwaltung“, die Unterkapitel zu den einzelnen Schnittstellen rücken auf Ebene 2 etc.>>

6.1 <Funktionsmerkmal_ABC>

<<Folgende Reihenfolge ist bei der Dokumentation der Schnittstellen einzuhalten: 1: technische Schnittstellen mit einen direkten funktionalen Bezug zu Funktionsmerkmal; 2: technische Schnittstellen mit einem betrieblichen bzw. organisatorischen Bezug; 3: organisatorische Schnittstellen>>

6.1.1 Schnittstelle <I_XYZ>

<<Vollständige Definition (WAS) und Umsetzung (WIE)  der Schnittstelle I_XYZ.
Beispiel: Die Schnittstelle <I_XYZ> setzt die in gemKPT_XXX_TIP definierte Schnittstelle <I_AAA> technisch um>>

6.1.1.1 Schnittstellendefinition

<<Definition der Schnittstelle mit allen ihren Anteilen (z.B. Operationen) auf technischer Ebene im Sinne einer Schnittstellenspezifikation (Syntax und Semantik). Die Schnittstellendefinition ist von nutzenden Systemen zu beachten.

Die Schnittstellendefinition erfolgt beispielsweise durch

• Definition aller technischen Operationen mit Parametern
• Vollständige Semantik der Schnittstelle
• Nichtfunktionale Anteile
• Ablaufdiagramme im Kontext der Schnittstelle, falls nötig (für nicht-triviale Abläufe)

Die Definition der Schnittstelle muss in Umsetzung einer Konzeption erfolgen (durch Umsetzungsanforderungen)

In der Schnittstellendefinition darf nicht auf die Umsetzung im Produkttyp eingegangen werden.>>

6.1.1.2 Umsetzung

<<Wie wird die Schnittstelle im Produkttyp umgesetzt, z.B. durch Beteiligung mit anderen Produkttypen (Nutzung der dort bereitgestellten Schnittstellen). Der Fokus liegt hierbei auf einer Black-Box-Betrachtung der Umsetzung für den Produkttyp. Die Umsetzungsanteile sind irrelevant für den Nutzer und können daher geändert werden, ohne dass der Nutzer davon betroffen ist. Falls andere Produkttypen in der Umsetzung der Schnittstelle beteiligt sind, muss dies in geeigneter Form auf technischer Ebene beschrieben werden (z.B. durch Verwendung von Sequenzdiagrammen und Referenzierung der nötigen Schnittstellen). Betrachtet werden sollen hierbei aber nur die direkt verwendeten Schnittstellen und die bereitstellenden Produkttypen. Es soll hier keine E2E-Sicht erfolgen. Die E2E-Sicht in der TI-Plattform ist bereits auf Konzeptebene vollständig dargestellt.

Die Umsetzung der Schnittstelle im bereitstellen Produkttyp muss in Umsetzung einer Konzeption erfolgen (durch Umsetzungsanforderungen)>

6.1.1.3 Nutzung <<optional – ggf. komplett zu streichen>>

<<Optional falls bereits einheitliche Festlegungen zur Nutzung definiert werden sollen. Ansonsten können spezifische Festlegungen auch in den Spezifikationen der nutzenden Produkttypen erfolgen. Anforderung in diesem Kapitel sind ausschließlich  relevant für den Nutzer der Schnittstelle>>

6.1.2 Schnittstelle <P_XYZ>

<<Vollständige Definition (WAS) und Umsetzung (WIE)  der organisatorischen Schnittstelle P_XYZ. Hierzu zählen insbesondere auch produkttypspezifische organisatorische betriebliche Anteile. Technische Schnittstellen die für im Rahmen der organisatorischen Schnittstelle benötigt werden, müssen in einem Kapitel für technische Schnittstellen definiert werden.>>

6.1.2.1 Schnittstellendefinition

6.1.2.2 Umsetzung

6.1.2.3 Nutzung <<optional – ggf. komplett zu streichen>>

<< Optional falls bereits einheitliche Festlegungen zur Nutzung definiert werden sollen Ansonsten sollen spezifische Festlegungen auch in den Spezifikationen der nutzenden Produkttypen erfolgen >>

6.2 E-Rezept Anwnedungsfälle im FdV

6.2.1 TI-Session starten (Authentisierung des Nutzers)

User Stories:

• Als Patient möchte ich mich am AdV Terminal mit der eGK authentisieren können, so dass ich die damit verbundenen Services nutzen kann ohne dabei auf ein eigenes Gerät zurückgreifen zu müssen.
• Als Patient möchte ich, dass mir das AdV-Terminal den Authentisierungsprozess erklärt, so dass ich weiß, was ich machen muss, wenn der Prozess beginnt.
• Als Patient möchte ich, dass mich das AdV-Terminal zum richtigen Zeitpunkt dazu auffordert, meine eGK in den Kartenleser zu stecken oder auf die NFC-Schnittstelle aufzulegen, so dass ich mich authentisieren kann.
• Als Patient möchte ich, dass mich das AdV-Terminal zum richtigen Zeitpunkt auffordert, meine CAN einzugeben, wenn ich NFC verwende, so dass ich mich authentisieren kann.
• Als Patient möchte ich, dass mich das AdV-Terminal zum richtigen Zeitpunkt auffordert, meine PIN einzugeben, so dass ich mich authentisieren kann.
• Als Patient möchte ich meine CAN wiederholt eintippen können, wenn ich mich vertippt habe, so dass ich mich authentisieren kann.
• Als Patient möchte ich meine PIN wiederholt eintippen können, wenn ich mich vertippt habe, so dass ich mich authentisieren kann.

Mit diesem Anwendungsfall authentisiert sich der Nutzer für den Nutzerzugang am E-Rezept-Fachdienst mittels TI-Authentisierung (, d.h. gegenüber einem Identity Provider der TI)

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

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

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

6.2.2 E-Rezepte einsehen

User Stories:

• Als Patient möchte ich nach Authentisierung am AdV-Terminal alle meine Verordnungen einsehen können, so dass ich einen Überblick über meine Verordnungen behalte.
• Als Patient möchte ich den kompletten Inhalt von "E-Rezepten" lesen können, so dass ich sicher sein kann, die richtigen "E-Rezepte" ausgewählt zu haben, wenn ich mich zu nächsten Schritten entscheide
• Als Patient möchte ich verstehen, was der Status eines "E-Rezepts" bedeutet, so dass ich die nächsten Schritte sinnvoll entscheiden kann.

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.

AFO: E-Rezept-FdV-AdV: E-Rezepte herunterladen

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

AFO: E-Rezept-FdV-AdV: E-Rezept herunterladen

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

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

AFO: E-Rezept-FdV-AdV: FHIR-Signatur prüfen

Das E-Rezept-FdV-AdV 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:

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

AFO: E-Rezept-FdV-AdV: Kein E-Rezept im E-Rezept-FdV-AdV speichern

Das E-Rezept-FdV-AdV DARF vom E-Rezept-Fachdienst heruntergeladenen E-Rezepte NICHT im lokalen Speicher ablegen.

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.

AFO: E-Rezept-FdV-AdV: Spezifisches E-Rezept herunterladen

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

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

AFO: E-Rezept-FdV-AdV: E-Rezept mit AccessCode herunterladen

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

• ID_TOKEN im http-Header
• Rezept-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.

AFO: E-Rezept-FdV-AdV: E-Rezept im Frontend anzeigen

Das E-Rezept-FdV-FdV-AdV MUSS es dem Nutzer ermöglichen, die heruntergeladenen E-Rezepte in geeigneter Weise anzuzeigen.

6.2.3 E-Rezepte löschen

User Stories:

• Als Patient möchte ich nach Authentisierung am AdV-Terminal 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 das AdV-Terminal 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öschung 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.

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

Das E-Rezept-FdV-AdV 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.

AFO: E-Rezept-FdV-AdV: E-Rezept löschen - Bestätigung

Das E-Rezept-FdV-AdV 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.

AFO: E-Rezept-FdV-AdV: E-Rezepte löschen

Das E-Rezept-FdV-AdV MUSS den Anwendungsfall "UC xx - E-Rezepte löschen" aus [gemSysL_eRp] gemäß TAB_FdVERP_xxx umsetzen. 

AFO: E-Rezept-FdV-AdV: E-Rezept löschen - Löschrequest

Das E-Rezept-FdV-AdV 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

• ID_TOKEN im Authorization-Header
• Rezept-ID in URL <id>
• 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].

AFO: E-Rezept-FdV-AdV: E-Rezept löschen - E-Rezept-Token löschen

Das E-Rezept-FdV-AdV 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.

6.2.4 Zugriffsprotokolle einsehen

User Stories:

• Als Patient möchte ich nach Authentisierung am AdV-Terminal die Protokolle 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.

AFO: E-Rezept-FdV-AdV: Protokolldaten anzeigen

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

AFO: E-Rezept-FdV-AdV: Protokolldaten anzeigen - Protokolleinträge abrufen

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

• ID_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:

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

AfO: E-Rezept-FdV-AdV: Protokolldaten anzeigen - Anzeigen

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

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

6.2.5 Zugriffsprotokolle löschen - in Klärung

User Stories:

• Als Patient möchte ich nach Authentisierung am AdV-Terminal die Protokolle einzelner oder aller Verordnungen löschen können, so dass ich die volle Kontrolle zu Informationen über mich und meinen Rezepten habe.
• 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öschung einleiten kann.

6.2.6 E-Rezept als 2D-Code anzeigen

User Story:

• Als Patient möchte ich nach einer Authentisierung am AdV-Terminal den 2D-Code einer Verordnung angezeigt bekommen können (z.B.: weil ich diesen mit einem separaten Gerät abfotografieren möchte).

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

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

Das E-Rezept-FdV-AdV MUSS es dem Nutzer ermöglichen, heruntergeladene E-Rezepte für die Anzeige in einem 2D-Code auszuwählen.

AFO: E-Rezept-FdV-AdV: 2D-Code anzeigen - E-Rezept-Token erstellen

Das E-Rezept-FdV-AdV 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].

AFO: E-Rezept-FdV-AdV: 2D-Code anzeigen

Das E-Rezept-FdV-AdV 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].

AFO: E-Rezept-FdV-AdV: 2D-Code anzeigen - personenbezogene Daten

Das E-Rezept-FdV-AdV DARF NICHT personenbezogene Daten zusammen mit der Anzeige des 2D-Codes anzeigen.

6.2.7 Artefakte

<<Optional: Hier Datenstrukturen und Wertebereiche, die spezifisch im Kontext des Funktionsmerkmal liegen– andernfalls Kap. 7 nutzen

Werden keine Festlegungen getroffen, sollte das Unterkapitel mit dem folgenden Standardsatz erhalten bleiben:

Zu Artefakten im Zusammenhang mit Funktionsmerkmal werden keine gesonderten Festlegungen getroffen.>

6.2.8 Testunterstützung

<< Optional wenn für dieses Funktionsmerkmal  eine spezielle Testunterstützung benötigt wird. Hier sind speziell nötige Umsetzungen für den Produkttyp aus der Testarchitektur durchzuführen. Hierbei kann es sich um spezifische Ausprägungen des Produkttypen für Testumgebungen handeln, aber auch um spezielle Testfunktion die im Wirkbetrieb aktivierbar bzw. nutzbar sein müssen.

Werden keine Festlegungen getroffen, sollte das Unterkapitel mit dem folgenden Standardsatz erhalten bleiben:

Zur Unterstützung von Tests im Zusammenhang mit dem Funktionsmerkmal werden keine gesonderten Festlegungen getroffen >>

6.2.9 Hardwaremerkmale

<< Optional: Hardwaremerkmale im Kontext des Funktionsmerkmals. Beispielsweise HW-Schnittstellen oder andere HW-Bestandteile mit Sichtbarkeit nach Außen (z.B. Bedienelemente).

Werden keine Festlegungen getroffen, sollte das Unterkapitel mit dem folgenden Standardsatz erhalten bleiben:

Das Funktionsmerkmal setzt keine besonderen Hardwaremerkmale voraus. >>

7 Informationsmodell

<<Optional: Enthält, sofern erforderlich, das technische Info-Modell – den Information View, z.B. auch Zertifkate, Schlüssel, eGK-Strukturen der TI-Plattform >>

<<Das Kapitel muss auch dann erhalten bleiben, wenn kein Informationsmodell angegeben wird.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

Eine gesondertes Informationsmodell der durch den Produkttypen verarbeiteten Daten wird  nicht benötigt.>>

8 Verteilungssicht

<< Optional: Darstellung der Verteilsicht des Produkttyps, also der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und die Einbettung in die physikalische Umgebung (z.B. Arztpraxis)>>

<<Das Kapitel muss auch dann erhalten bleiben, wenn kein Verteilungssicht dargestellt wird.

Werden keine Festlegungen getroffen, sollte das Kapitel mit dem folgenden Standardsatz erhalten bleiben:

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

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

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

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

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

9.5.2 Weitere Dokumente

9.6 Verzeichnis der verwendeten Operationen und Interfaces <<optional>>

9.7 Klärungsbedarf <<optional>>

9.8 Allgemeine Erläuterungen <<optional>>

<<hier können die Interfaces und Operationen mit Verweis auf die jeweilige Seite gelistet werden. Lesehilfe zur Auflösung von Querbezügen>>