Elektronische Gesundheitskarte und Telematikinfrastruktur

Systemspezifisches Konzept

E-Rezept

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
12.11.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSysL_eRp
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das vorliegende Dokument beschreibt die systemspezifische Lösung der Fachanwendung E-Rezept.

In diesem systemspezifischen Konzept werden insbesondere die Komponenten der Lösung von E-Rezept sowie ihre Schnittstellen untereinander und mit der Telematikinfrastruktur-Plattform beschrieben. Dieses Dokument bildet somit die Grundlage für die Spezifikationen, Produkttyp- und Anbietersteckbriefe der Komponenten der Fachanwendung E-Rezept.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter der 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.

Wichtiger Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass das Konzept 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 Abgrenzung des Dokuments

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zu den Themenbereichen:

• fachliche Inhalte des Informationsmodells für die Fachanwendung E-Rezept (siehe auch  )
• Prozesse für die Abrechnung von E-Rezepten der abgebenden Leistungserbringerinstitutionen gegenüber den Kostenträgern

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 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.2 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

2.1 Einführung

Die Fachanwendung E-Rezept ermöglicht eine Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel in elektronischer Form. Sie setzt sich aus den in ABB_SYSLERP_001 dargestellten Bestandteilen zusammen.

Abbildung 1: ABB_SYSLERP_001 Übersicht der Fachanwendung E-Rezept 

Der verordnende Leistungserbringer erstellt für einen Versicherten ein E-Rezept, welches auf dem zentralen E-Rezept-Fachdienst abgelegt wird. Der Standardfall sieht vor, dass der Versicherte seine E-Rezepte mit dem E-Rezept-Frontend des Versicherten auf seinem technischen Gerät verwaltet. Mit dem E-Rezept-Frontend des Versicherten kann der Versicherte einen E-Rezept-Token generieren, der eine Apotheke für den Zugriff auf ein konkretes E-Rezept im E-Rezept-Fachdienst berechtigt. Der Versicherte übermittelt den E-Rezept-Token elektronisch an eine Apotheke oder legt ihn in Form eines 2D-Codes in einer Apotheke vor. Die elektronische Übertragung des E-Rezept-Tokens an eine Apotheke erfolgt über den E-Rezept-Fachdienst.

Für Versicherte, welche kein E-Rezept-Frontend des Versicherten nutzen, erstellt der verordnende Leistungserbringer den E-Rezept-Token und übergibt ihn in Form eines 2D-Code auf einem Ausdruck dem Versicherten. Der Ausdruck kann in einer Apotheke vorgelegt werden. 

Durch die Übergabe eines E-Rezept-Token an eine andere Person kann diese als Vertreter das E-Rezept in einer Apotheke einlösen.

Der Versicherte hat die Hoheit über das E-Rezept, da jeglicher Zugriff auf ein konkretes Rezept im E-Rezept-Fachdienst entweder nur dem Versicherten, dem das E-Rezept verordnet wurde, oder einer Apotheke oder einem Vertreter nach Vorlage eines im E-Rezept-Token enthaltenen AccessCodes gestattet ist. Der E-Rezept-Token realisiert ein Besitzmodell, d.h. wer im Besitz des E-Rezept-Tokens und damit des AccessCodes ist, kann damit die Dispensierung in einer Apotheke veranlassen.

Mit der Übergabe bzw. dem Einlesen des E-Rezept-Tokens an einen/durch einen Apotheker erfolgt die Aufforderung zur Dispensierung. Der Apotheker lädt das E-Rezept vom zentralen E-Rezept-Fachdienst und verarbeitet es. Zugriffe auf den E-Rezept-Fachdienst werden im E-Rezept-Fachdienst protokolliert und sind durch den jeweils betroffenen Versicherten einsehbar.

Die dezentrale E-Rezept-Fachlogik wird im Primärsystem der verordnenden und abgebenden Leistungserbringerinstitutionen, sowie im E-Rezept-Frontend des Versicherten (E-Rezept-FdV) umgesetzt. Alle Client-Systeme nutzen Dienste der zentralen TI-Plattform, wobei die Primärsysteme der Leistungserbringer zusätzlich auf Funktionalitäten des Konnektors zurückgreifen.

In der TI gibt es genau einen Anbieter für den E-Rezept-Fachdienst und einen Anbieter für das E-Rezept-Frontend des Versicherten.

Das E-Rezept-Frontend des Versicherten muss diskriminierungsfrei, werbefrei und unabhängig sein.

Für den Zugang zur Telematikinfrastruktur nutzt der Versicherte seine eGK mit NFC-Schnittstelle, sodass eine Nutzung des E-Rezepts auch ohne weitere Hardware an den Geräten des Versicherten möglich ist.

2.2 Übergeordnete Ziele

2.2.1 Sicherheit und Datenschutz

Die Fachanwendung E-Rezept muss sicherstellen, dass nur berechtigte Akteure auf medizinische personenbezogene Daten vom E-Rezept zugreifen dürfen. Sie muss sicherstellen, dass die Daten der Fachanwendung E-Rezept beim Anbieter und Betreiber beteiligter Komponenten nicht für Zwecke der Profilbildung verarbeitet werden können. Die Fachanwendung E-Rezept muss ferner sicherstellen, dass die Sicherheit der TI durch die Nutzung der Fachanwendung E-Rezept nicht beeinträchtigt wird.

Eine Identifikation von Akteuren soll nur da erfolgen, wo sie notwendig ist. Beispielsweise ist es heute mit dem Papier-Rezept nicht notwendig, dass sich die einlösende Person in der Apotheke ausweist.

2.2.2 Datenhoheit und Flexibilität

Die Fachanwendung E-Rezept soll die Flexibilität des Papier-Rezepts bewahren. Der Versicherte muss die Apotheke, in der das E-Rezept eingelöst wird, frei wählen können. Das Einlösen durch Dritte ist explizit erlaubt. Das Delegieren an Vertreter soll leicht und flexibel erfolgen können.

In der Fachanwendung E-Rezept erfolgt eine Trennung zwischen medizinischen Daten (E-Rezept) und der Berechtigung auf den Zugriff auf die medizinischen Daten (E-Rezept-Token). Der Besitz des E-Rezept-Tokens soll einzige Voraussetzung für die Autorisierung zum Einlösen des E-Rezepts sein.

Versicherte müssen das E-Rezept auch ohne eigene technische Geräte und Softwarekomponenten einlösen können. Ein zusätzliches durch den Versicherten genutztes Frontend des Versicherten kann jedoch den Komfort der Anwendung heben.

2.2.3 Erweiterbarkeit

Die Fachanwendung E-Rezept soll um weitere Rezepttypen (bspw. Heilmittel, Hilfsmittel, T-Rezepte oder BtM-Rezepte) erweiterbar sein. Diese Erweiterungen erfolgen in Folgestufen.

2.2.4 Betrieb

Die Fachanwendung E-Rezept muss für Nutzer eine ihrem Bedarf entsprechende angemessene Funktionalität, Verfügbarkeit, Stabilität und Zuverlässigkeit, Performanz, Kontinuität und Vorhersehbarkeit der Anwendungsfälle des E-Rezepts sicherstellen. Die Produkttypen E-Rezept-Fachdienst und Identity Provider (IDP) und die damit zusammenfallenden technischen Systeme und Komponenten müssen entsprechende Schnittstellen zur Prüfung dieser Aspekte vorsehen. Die Betreiber bzw. Anbieter der operativen Betriebsleistungen dieser Produkttypen sind für die Überwachung, Prüfung, Analyse und Aufrechterhaltung der genannten Aspekte verantwortlich.

2.3 Akteure und Rollen

Im folgenden Abschnitt werden die am E-Rezept beteiligten Akteure/Rollen betrachtet. Ein Akteur ist eine Person oder ein technisches System, die/das mit der Fachanwendung E-Rezept interagiert. Diese Interaktion wird durch einen Anwendungsfall ausgelöst.

Akteure innerhalb der Fachanwendung E-Rezept sind jedoch keine konkreten beteiligten Personen oder Systeme, sondern Rollen, die jene im Rahmen des Anwendungsfalles einnehmen. Insofern kann eine Person oder ein technisches System in mehreren Rollen mit dem E-Rezept-System interagieren.

2.3.1 Fachliche Rollen

Die folgende Abbildung stellt die im Kontext der Fachanwendung E-Rezept beteiligten Rollen dar.

Abbildung 2: ABB_SYSLERP_002 Fachliches Rollenmodell

Tabelle 1 : TAB_SYSLERP_048 Fachliche Rollen

Die folgende Tabelle listet die für die Fachanwendung E-Rezept verwendeten kryptografischen Identitäten auf und ordnet sie den verschiedenen Akteuren mit ihrer jeweiligen Rolle zu.

Tabelle 2: TAB_SYSLERP_001 Kryptografische Identitäten der Akteure und ihre jeweilige Rolle

2.3.2 Technische Rollen

Neben den fachlichen Rollen existieren technische Rollen. Diese technischen Rollen kommen zum Tragen, wenn nicht eine Person mit dem System interagiert, sondern eine technische Komponente, ein Produkttyp der Fachanwendung E-Rezept oder das Primärsystem der Leistungserbringerumgebung. Die entsprechenden Produkttypen und Komponenten der Fachanwendung werden im Kapitel  dargestellt.

2.4 Funktionale Zerlegung

Die folgende Abbildung zeigt die funktionale Zerlegung.

Abbildung 3: ABB_SYSLERP_003 Funktionale Zerlegung E-Rezept 

2.4.1 Konzept Identifikation und Zugang zum E-Rezept

Der Zugang zur Fachanwendung E-Rezept erfolgt für die LEI mittels Konnektor in seiner Funktion als VPN-Router. Dieser enthält keine E-Rezept-spezifische Funktionalität, d.h. die Verbindung zu zentralen Diensten in der Provider-Zone und der TI-Plattform wird direkt durch die Client-Systeme aufgebaut. Der Versicherte greift auf die Schnittstellen der Dienste für das E-Rezept mittels des Frontends über das Internet zu.

Die Schnittstellen sind für den Nutzer ausschließlich nach einer erfolgreichen Authentifizierung durch einen Identity Provider (IDP) nutzbar, der die Identität des Versicherten bzw. der LEI über ein AuthN-Token als Identitätsbestätigung zusichert. Arzt-, Zahnarztpraxen, Krankenhäuser und Apotheken werden dabei über ihre Institutsidentität der jeweiligen SMC-B authentifiziert. Der Versicherte weist sich mit seiner eGK-Identität aus. Zukünftig werden neben der Authentisierung mit einer Smartcard auch alternative Verfahren zur Authentisierung ermöglicht.

Der IDP als TIP-Nutzerdienst übernimmt im zentralen Bereich die Authentifizierung des Nutzers. Ergänzt wird dieser durch ein Authentisierungsmodul, welches bei der LEI das Primärsystem bzw. beim Versicherten das E-Rezept-Frontend des Versicherten ergänzt. Das Authentisierungsmodul greift in der Consumer Zone bzw. Personal Zone auf die SMC-B bzw. eGK als Authentisierungsmittel (AUT-Identität) zu. Das Authentisierungsmodul steuert die Interaktion mit dem Nutzer, falls dies für die Authentisierung erforderlich ist oder eine Zustimmung (Consent) zur Freigabe von Identitätsmerkmalen an die Anwendung benötigt wird.

Nach erfolgreicher Authentifizierung durch den IDP erhält das Primärsystem bzw. das FdV ein AuthN-Token, welches als Bearer-Token verwendet wird, um auf die Dienste des E-Rezeptes zuzugreifen. Das AuthN-Token enthält die bestätigten Identitätsmerkmale, die der aufgerufene Dienst benötigt, um daraus die Berechtigung des Nutzers abzuleiten. Des Weiteren können dem Token erforderlichenfalls Identitätsattribute entnommen werden, die für die Fachlogik benötigt werden, z.B. zur Protokollierung.

Die folgende Abbildung zeigt eine Übersicht der an der Authentifizierung des Nutzers beteiligten Komponenten.

Abbildung 4: ABB_SYSLERP_009 Übersicht Identity Provider im Kontext E-Rezept

Der Authentifizierungsdienst (IDP) stellt der Fachlogik eines E-Rezept-Frontends eine Schnittstelle für den Bezug von Authentifizierungsbestätigungen bereit. Die Fachlogik nutzt dafür einen AuthN-Code, den sie über ein Authentisierungsmodul bezieht. Das Authentisierungsmodul steuert die konkrete Benutzerauthentifizierung gegenüber dem IDP unter Nutzung festgelegter bzw. durch den IDP prüfbare Identitätsmerkmale z.B. SmartCard + PIN.

2.4.2 Konzept Zugriffsberechtigung auf E-Rezepte

Alle Zugriffe auf Komponenten/Dienste und Schnittstellen für das E-Rezept setzen eine Identifikation der zugreifenden Nutzer voraus.

Um einen unberechtigten Zugriffe von E-Rezepten zu unterbinden und das Einlösen in einer ausgewählten Apotheke zu steuern, übermittelt der Versicherte eine Zugriffsberechtigung in Form eines AccessCodes an die Apotheke seiner Wahl (Vor-Ort-Apotheke, Versandapotheke). Nur durch Übergabe dieses AccessCodes beim Abruf eines E-Rezeptes erlangt diese Apotheke Zugriff auf genau dieses E-Rezept im E-Rezept-Fachdienst. Diesen AccessCode kann der Versicherte aus dem E-Rezept-Datensatz herunterladen und in einen E-Rezept-Token einbringen. Mit der Weitergabe dieses E-Rezept-Tokens an einen Vertreter kann der Versicherte das Einlösen eines E-Rezepts an einen Dritten delegieren.

Das Einlösen in einer Apotheke setzt voraus, dass die Apotheke diesen AccessCode an den E-Rezept-Fachdienst beim Zugriff auf ein E-Rezept übermittelt. Der Versicherte oder Vertreter übergibt den AccessCode an die Apotheke durch Vorzeigen des E-Rezept-Tokens in der Apotheke oder mittels elektronischer Übermittlung in der TI (siehe  ).

2.4.3 Konzept der E-Rezept-Ressourcenverwaltung

Die Verwaltung der E-Rezepte in der Telematikinfrastruktur setzt auf einen zentralen Ressourcenserver als E-Rezept-Fachdienst. Dieser soll alle E-Rezepte auf Basis des FHIR-Standards als MedicationReqests [FHIR] in strukturierter Form verwalten. Die Rezepte werden dabei über eine eindeutige Ressourcen-ID (Rezept-ID) adressiert. Zusätzlich protokolliert der E-Rezept-Fachdienst alle Zugriffe auf ein E-Rezept für den Versicherten und verwaltet die Statusübergänge eines E-Rezepts.

Mit der Verwaltung der E-Rezepte in strukturierter Form setzt der E-Rezept-Fachdienst die Einhaltung medizinischer Workflows durch. In der ersten Stufe der Umsetzung der Arzneimittelverordnung ("Muster 16") ist der Workflow relativ einfach. Mit der Umsetzung weiterer Verordnungstypen (Betäubungsmittel, Heil- und Hilfsmittel) kommen zusätzliche Beteiligte ins Spiel, die insbesondere bei Verordnungen mit Freigabezyklen (bspw. bei Hilfsmitteln durch Kostenträger und Gegenzeichnung einer absolvierten Maßnahme durch den Versicherten bei Heilmittelverordnungen) in den Verordnungsprozess eingebunden werden müssen. Hier lässt sich mit der Digitalisierung der fachlichen Workflows eine Zeitersparnis realisieren.

Mit der Erweiterung der E-Rezept-Ressourcen um MedicationStatements in einer zukünftigen Ausbaustufe wäre es Patienten zusätzlich möglich, auf eigenen Wunsch die Einnahme von Medikamenten über sein Frontend des Versicherten zu dokumentieren. Die konkrete Ausgestaltung der UserExperience mit der Definition entsprechender Schnittstellen und Ressourcen ergibt sich aus dem zu definierenden Zusammenspiel des E-Rezept-Fachdiensts für den Verordnungs-Prozess und der elektronischen Patientenakte für die Langzeitdokumentation medizinischer Daten.

Zur Sicherstellung der Integrität des verwalteten, QES-signierten E-Rezepts als strukturierter Datensatz erfolgt beim Einstellen eines E-Rezepts eine Signatur der E-Rezept-Ressource durch den E-Rezept-Fachdienst, sofern die Daten der E-Rezept-Ressource schematisch und anhand der QES des E-Rezept-Datensatzes valide sind. Mit der serverseitigen QES-Prüfung wird sichergestellt, dass ausschließlich schematisch korrekte Daten, durch QES des Verordnenden bestätigt, in der Steuerung der fachlichen Workflows verwendet werden. Zusätzlich stellt die serverseitige QES-Prüfung sicher, dass ausschließlich signierte Rezepte der Apotheke zugewiesen werden, wodurch sich die Qualität der eingereichten Rezepte gegenüber einer ungeprüften Überbringung in die Apotheke steigert. Hier sind in der Folge weniger Korrekturschleifen zwischen Verordnendem Arzt/Zahnarzt und Apotheker zu erwarten.

Der E-Rezept-Fachdienst prüft die Autorisierung des Zugriffs auf E-Rezepte und Protokolleinträge anhand der Identitätsbestätigungen der zugreifenden Nutzer. Dabei wird die Rechtmäßigkeit eines Aufrufs durch Leistungserbringer auf Rollenbasis geprüft. Beim Aufruf durch den Versicherten zum Abruf "seiner" E-Rezepte und Protokollinformationen erfolgt die Autorisierung anhand der Versicherten-ID (10-stelliger unveränderlicher Teil der Krankenversichertennummer (KVNR)) des Versicherten.

Das Einstellen von E-Rezepten ist verordnenden Leistungserbringern (Ärzte, Zahnärzte, etc.) und ihren Mitarbeitern gestattet. Hier genügt eine einfache Rollenprüfung anhand der Identität der Leistungserbringerinstitution. E-Rezepte abrufen und die Abgabe vollziehen dürfen ausschließlich Apotheken, deren Rolle ebenfalls anhand der Identität der Apotheke als Leistungserbringerinstitution geprüft wird. Zusätzlich erfordert das Abrufen eines E-Rezepts durch eine Apotheke die Vorlage des vom Versicherten an den Apotheker übergebenen AccessCode, der beim Abruf des E-Rezepts mit dem am E-Rezept-Datensatz gespeicherten AccessCode übereinstimmen muss.

Ist eine Apotheke für den Abruf eines E-Rezepts autorisiert, generiert der E-Rezept-Fachdienst beim Abruf ein Geheimnis, das der Apotheke zusammen mit dem E-Rezept-Datensatz übergeben wird. Der Zugriff auf genau dieses E-Rezept durch andere Apotheken ist gesperrt, da die Apotheke das Geheimnis beim Zurückgeben des E-Rezepts oder Abfragen der Quittung an den E-Rezept-Fachdienst übermitteln muss.

2.4.4 Konzept der Verschlüsselung des E-Rezepts

Der E-Rezept-Fachdienst verarbeitet die gespeicherten E-Rezepte im Klartext. Zum Schutz der in den E-Rezepten enthaltenen personenbezogenen medizinischen Daten muss eine unberechtigte Einsichtnahme durch Dritte verhindert werden. Hierfür wird das für die elektronische Patientenakte (ePA) entwickelte Konzept der "Vertrauenswürdigen Ausführungsumgebung" (VAU) aufgegriffen. Die VAU stellt technisch sicher, dass während des Betriebs keine Daten für den Betreiber des E-Rezept-Fachdienstes einsehbar sind. Zusätzlich erfolgt die Speicherung der Daten außerhalb der VAU derart verschlüsselt, dass der Betreiber die Daten nicht entschlüsseln kann, da der notwendige kryptographische Schlüssel nicht im Zugriff des Betreibers liegt. Gegenüber dem Nutzer authentisiert sich die VAU beim Verbindungsaufbau mit einer kryptografischen Identität, die dem Nutzer die Integrität der ausgeführten Fachlogik im E-Rezept-Fachdienst zusichert.

Der Transport der personenbezogenen medizinischen Informationen zwischen der Clientlogik des Nutzers und der Vertrauenswürdigen Ausführungsumgebung erfolgt transportverschlüsselt mittels TLS.

Anmerkung:

Die Schutzziele der Vertrauenswürdigen Ausführungsumgebung im E-Rezept-Fachdienst entsprechen denen der Vertrauenswürdigen Ausführungsumgebung der elektronischen Patientenakte, mit einer Ausnahme. Das Schutzziel der Kontextseparierung in der ePA ist im E-Rezept-Fachdienst nicht notwendig, da Versicherte keinen schreibenden Zugriff über ihre Clientsysteme auf die E-Rezepte im E-Rezept-Fachdienst haben. Somit entfällt gegenüber der VAU der ePA die Notwendigkeit eines versichertenindividuellen Kontextschlüssels und ebenso ist ein Sandboxing der verarbeiteten Daten verschiedener Versicherter während des Betriebs nicht erforderlich.

2.4.5 Konzept der Übermittlung eines E-Rezept-Tokens

Um ein E-Rezept einzusehen und beliefern zu können benötigt eine Apotheke einen AccessCode, den sie vom Versicherten bzw. Vertreter übermittelt bekommt (Nachricht innerhalb des E-Rezept-Fachdienstes an die Apotheke) bzw. von einem vorgelegten Medium einscannt. Dieser AccessCode plus weitere Metainformationen (Rezept-ID etc.) formen den E-Rezept-Token.

Im Standardfall lädt der Versicherte die für das E-Rezept-Token benötigten Informationen aus dem E-Rezept-Fachdienst und generiert den E-Rezept-Token in seinem Frontend, welcher dann als 2D-Code dargestellt werden kann. Nutzt der Versicherte kein Frontend auf einem eigenen Gerät, erhält er den E-Rezept-Token von der verordnenden Leistungserbringerinstitution als ausgedruckten 2D-Code.

Der 2D-Code kann in der einlösenden Apotheke vom Frontend abgescannt werden. Die Darstellung des Tokens als 2D-Code ist ein optisches Übertragungsverfahren.

Für den digitalen Versand des E-Rezept-Tokens an eine Apotheke und die weitere Kommunikation rund um den Einlösevorgang mit der Apotheke (Verfügbarkeit, Terminabsprache zum Abholen, ...) sowie die Weitergabe des E-Rezept-Tokens an einen Vertreter benötigt der Versicherte ein Übermittlungsverfahren. In einer ersten Umsetzungsstufe erfolgt das über den E-Rezept-Fachdienst. Hierbei erzeugt das Frontend des Versicherten bzw. Vertreters eine strukturierte Nachricht (E-Rezept-Token und Freitext). Die Apotheke bzw. der Vertreter rufen die an sie adressierte Nachricht vom E-Rezept-Fachdienst ab. Eine eventuelle Antwort der Apotheke wird vom AVS bzw. beim Vertreter durch das Frontend ebenfalls als strukturierte Nachricht in den E-Rezept-Fachdienst eingestellt.

Für Versorgungsprozesse in folgenden Ausbaustufen sind weitere Kommunikationsbeziehungen naheliegend:

• Versicherter/Vertreter ==> Verordnender, bspw. für die Bestellung von Folgeverordnungen
• Verordnender ==> Versicherter/Vertreter, bspw. für Textnachrichten bezüglich der Bestellung von Folgeverordnungen
• Verordnender ==> Abgebender, bspw. für Tokenversand für Zytostatika-Verordnungen (§11 ApoG)

Diese Kommunikationsbeziehungen werden mit dem E-Rezept-Fachdienst nicht adressiert. Hier setzt die Anwendung E-Rezept auf die Weiterentwicklung der Anwendung KIM (ehemals KOM-LE), über welche dann auch die Kommunikationsbeziehungen Versicherter/Vertreter ==> Abgebender und Versicherter ==> Vertreter in einem einheitlichen Kommunikationsverfahren umgesetzt werden können.

2.4.6 Konzept Status E-Rezept

Ein E-Rezept durchläuft während seines Lebenszyklus verschiedene Status.

Abbildung 5: ABB_SYSLERP_004 Statusübergänge E-Rezept

Da ein E-Rezept-Token vervielfältigt werden kann, besteht die Möglichkeit, dass ein E-Rezept-Token an mehrere Apotheken übermittelt wird. Um sicherzustellen, dass die Statusübergänge "in Abgabe (gesperrt)" zu "quittiert", "gelöscht" oder "offen" nur durch die Apotheke ausgelöst wird, welche das E-Rezept zuvor abgerufen hat, wird der Apotheke beim Abruf eines E-Rezepts vom E-Rezept-Fachdienst ein Geheimnis übermittelt. Dieses Geheimnis zur Statusänderung "in Abgabe (gesperrt)" wird beim Aufruf zum Statuswechsel zurück an den E-Rezept-Fachdienst übermittelt. Der E-Rezept-Fachdienst kann anhand des Geheimnisses sicherstellen, ob der Statusübergang zulässig ist.

Da ein vom E-Rezept-Fachdienst heruntergeladenes E-Rezept elektronisch vervielfältigt werden kann, besteht die Möglichkeit, dass ein E-Rezept außerhalb der TI zu einer Apotheke übermittelt wird und der Status zur Abgabe des E-Rezepts im E-Rezept-Fachdienst nicht korrekt nachgehalten wird. Der E-Rezept-Fachdienst übermittelt der Apotheke beim Statuswechsel eines E-Rezepts von "in Abgabe (gesperrt)" zu "quittiert" eine Quittung. Der Besitz der Quittung belegt, dass die Apotheke die Abgabe des E-Rezepts entsprechend dem in der Fachanwendung vorgesehenen Ablauf durchgeführt hat. Die Quittung kann beispielsweise in der Abrechnung genutzt werden, um eine ungewollte mehrfache Abrechnung der Abgabe eines E-Rezepts zu vermeiden.

Die Verwaltung des Status im E-Rezept-Fachdienst erfolgt im Feld "status" der FHIR-Ressource Task (https://www.hl7.org/fhir/task.html ). Die Zuordnung der Status des E-Rezepts zum FHIR-Code-System findet sich in Tabelle TAB_SYSLERP_006. Die Umsetzung des Statusmodells für ein einzelnes E-Rezept wird über die Zustände der FHIR-Ressource Task gemäß des Workflow-Modells [FHIR_MED_WORKFLOW] realisiert. Der E-Rezept-Fachdienst prüft vor jedem Statuswechsel, ob ein von einem Akteur initiierter Statuswechsel zulässig ist.

Tabelle 3 : TAB_SYSLERP_006 Beschreibung Status Task

2.4.7 Unterstützung betrieblicher Prozesse

Die DVOs verordnender und abgebender LEIs benötigen eine einfache und schnell anwendbare Möglichkeit, nach Inbetriebnahme von Client-Systemen in der Produktivumgebung deren Funktionsfähigkeit zu überprüfen. Dies ist etwa nach Neuinstallation und Update oder auch regelmäßig im laufenden Betrieb hilfreich. Die Prüfung sollte einerseits keine explizite Anwendungslogik erfordern und andererseits ist die Abgabe von Arzneimitteln sowie eine gegenüber Kostenträgern abrechenbare Leistung auszuschließen.

Unter diesen Voraussetzungen sieht das Konzept eine durch die DVOs selbstbestimmte Prüfung der Konnektivität zwischen Client-Systemen und E-Rezept-Fachdienst wie folgt vor:

• Verordnende LEI: Mit "E-Rezept erzeugen" (UC 2.1) wird eine gültige E-Rezept-ID vom E-Rezept-Fachdienst abgerufen. Diese kann (muss aber nicht) nachher für das Einstellen eines vom LEI signierten E-Rezepts verwendet werden. Ist der Abruf einer E-Rezept-ID erfolgreich, gilt die Konnektivität zur Fachanwendung als gegeben.
• Abgebende LEI: Hierbei handelt es sich um einen Negativtestfall, der eine Fehlermeldung durch den E-Rezept-Fachdienst provoziert: Der DVO ruft ein E-Rezept (UC 4.1) mit zufälligen (und dadurch nicht validen) Werten für AccessCode und E-Rezept-ID ab. Der E-Rezept-Fachdienst antwortet mit einer entsprechenden Fehlermeldung.

In beiden Testfällen wird die Erstellung eines AuthN-Token gemäß UC 5.2 und die Verbindung zum E-Rezept-Fachdienst sowie die korrekte Verarbeitung der Anfragen inkl. Fehlermeldungen geprüft. Eine DVO-Prüfkarte wird hierzu nicht benötigt. Die Prüfungen können auch regelmäßig automatisiert durchgeführt werden (z.B. durch das TI-Service Monitoring).

Generell sollte für die Konnektivitätsprüfung auf die Erstellung eines signierten Prüf-E-Rezeptes (Rezept wird auf die KVNR einer DVO-Prüfkarte ausgestellt) verzichtet werden. Zwar kann mit einem solchen Rezept keine Verordnung eingelöst oder in Abrechnung gebracht werden, allerdings ist ggf. der Signierungsvorgang durch den  verordnenden LE u.U. nicht immer trennscharf von dem eines Echt-Rezeptes zu unterscheiden. Auf ein Verbot der Erstellung eines Prüf-E-Rezeptes wird allerdings verzichtet.

Weitere betriebliche Aufgaben sind bspw.

• die Bereitstellung von Probes zur Messung der Verfügbarkeit auf Anwendungsebene,
• die Verifikation von Änderungen in der PU auf Anwendungsebene.

Betriebliche Anforderungen

Der E-Rezept Betriebszustand wird durch die Betriebszustände der Produkttypen E-Rezept-Fachdienst, Identity Provider und Verzeichnisdienst repräsentiert.

3 Anwendungsfälle

3.1 Übersicht der Anwendungsfälle

Die folgende Abbildung zeigt eine Übersicht über die Anwendungsfälle der Fachanwendung E-Rezept.

Abbildung 6: ABB_SYSLERP_005 Anwendungsfälle E-Rezept

3.2 Übergreifende Vorbedingungen

Die nachfolgenden Vorbedingungen müssen für alle Anwendungsfälle erfüllt sein, damit sie erfolgreich ausgeführt werden können. Wenn diese Vorbedingungen nicht erfüllt sind, so muss die Operation mit einer Fehlermeldung abbrechen.

3.3 Übergreifende Nachbedingungen

Der folgende Abschnitt beschreibt übergreifende Nachbedingungen, die für den erfolgreichen Abschluss fachlicher Anwendungsfälle gelten.

3.4 E-Rezept ausstellen

3.4.1 E-Rezepte durch Verordnenden erzeugen

Mit diesem Anwendungsfall signiert ein verordnender Leistungserbringer ein oder mehrere Verordnungsdatensätze. Vor dem Signieren wird im Verordnungsdatensatz eine über die TI bezogene Rezept-ID ergänzt. Dieser Anwendungsfall kann, da er eine qualifizierte elektronische Signatur beinhaltet, nur durch den Leistungserbringer, nicht jedoch durch einen Mitarbeiter der medizinischen Institution durchgeführt werden.

A_18502 - Anwendungsfall "E-Rezepte erzeugen"

Alle am Anwendungsfall "E-Rezepte erzeugen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 4: TAB_SYSLERP_005 Anwendungsfall E-Rezepte erzeugen 

Name	UC 2.1 - E-Rezepte erzeugen
Vorbedingung	Der oder die Versicherten sind der LEI bekannt. Ein oder mehrere Verordnungsdatensätze wurden für den bzw. die Versicherten im Primärsystem erstellt. Der HBA ist für die QES gesteckt und freigeschaltet.
Kurzbeschreibung (Außenansicht)	Der verordnende Leistungserbringer wählt im Primärsystem einen oder mehrere Verordnungsdatensätze zum Signieren aus. Der Leistungserbringer wählt das Signaturverfahren aus. Das Primärsystem ruft für jedes E-Rezept vom E-Rezept-Fachdienst eine Rezept-ID ab und ergänzt diese im Verordnungsdatensatz. Anschließend werden die E-Rezepte mittels Konnektor mit einer QES signiert. Es kann die Einzel-, Stapel- oder Komfortsignatur genutzt werden.
Nachbedingung	Die erzeugten E-Rezepte beinhalten eine eineindeutige Rezept-ID und haben eine QES. Der AccessCode für jedes E-Rezept ist im Primärsystem gespeichert. Die E-Rezepte sind im E-Rezept-Fachdienst angelegt und haben den Status "initialisiert".

[<=]

3.4.2 E-Rezept einstellen

Mit diesem Anwendungsfall stellt eine verordnende Leistungserbringerinstitution ein E-Rezept auf den E-Rezept-Fachdienst ein und erzeugt den zugehörigen E-Rezept-Token.

A_18503 - Anwendungsfall "E-Rezept einstellen"

Alle am Anwendungsfall "E-Rezept einstellen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 5: TAB_SYSLERP_006 Anwendungsfall E-Rezept einstellen

Name	UC 2.3 - E-Rezept einstellen
Vorbedingung	Der verordnende Leistungserbringer hat den Anwendungsfall "UC 2.1 - E-Rezepte erzeugen" ausgeführt. Ein E-Rezept und die zugehörige Signatur liegen im Primärsystem vor. Die Rezept-ID und der AccessCode sind im Primärsystem bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "initialisiert".
Kurzbeschreibung (Außenansicht)	Der verordnende Leistungserbringer oder ein Mitarbeiter der medizinischen Institution wählt im Primärsystem ein E-Rezept zum Einstellen aus. Das Primärsystem aktualisiert das E-Rezept im E-Rezept-Fachdienst. Das Primärsystem erstellt einen E-Rezept-Token und speichert diesen..
Nachbedingung	Das E-Rezept ist im E-Rezept-Fachdienst gespeichert und hat den Status "offen". Das Einstellen ist im E-Rezept-Fachdienst protokolliert.

[<=]

3.4.3 E-Rezept-Token durch Verordnenden an Versicherten oder Apotheker übermitteln

Nachdem ein Mitarbeiter der verordnenden LEI den Anwendungsfall "UC 2.3 - E-Rezept einstellen" ausgeführt hat, kann der Versicherte sich das E-Rezept mit dem Anwendungsfall "UC 3.1 - E-Rezepte durch Versicherten abrufen" auf sein FdV herunterladen und einen E-Rezept-Token erstellen.

Nur wenn der Versicherte kein FdV nutzt, wird der E-Rezept-Token im Primärsystem erzeugt und als 2D-Code ausgedruckt. Der Ausdruck wird dem Versicherten übergeben. Ergänzend zum Ausdruck können zusätzliche technische Möglichkeiten bestehen, den 2D-Code für den Versicherten zum Abfotografieren anzuzeigen. Die Inhalte und das Format des papierbasierten Token der Fachanwendung E-Rezept werden durch die  Bundesmantelvertragspartner in Absprache mit dem Deutschen Apothekerverband (DAV) festgelegt. 

Für Verordnungen von Sprechstundenbedarfen und von parenteralen Zubereitungen nach §11 ApoG (Zytostatika) kann die verordnende LEI den E-Rezept-Token an eine Apotheke übertragen und hierfür KOM-LE nutzen. Im Kontext eines Krankenhauses sind weitere Übertragungswege möglich.

3.4.4 E-Rezept durch Verordnenden löschen

Mit diesem Anwendungsfall kann ein Mitarbeiter einer verordnenden Leistungserbringerinstitution, den Status für ein zuvor durch die LEI für den Versicherten eingestelltes E-Rezept auf "gelöscht" setzen. Die Nutzer können auf ein E-Rezept mit dem Status  "gelöscht" nicht mehr zugreifen.

A_18505 - Anwendungsfall "E-Rezept durch Verordnenden löschen"

Alle am Anwendungsfall "E-Rezept durch Verordnenden löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 6: TAB_SYSLERP_008 Anwendungsfall E-Rezept durch Verordnenden löschen

Name	UC 2.5 - E-Rezept durch Verordnenden löschen
Vorbedingung	Ein Mitarbeiter der verordnenden LEI hat den Anwendungsfall "UC 2.3 - E-Rezept einstellen" ausgeführt. Die Rezept-ID und der AccessCode sind im Primärsystem bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "offen".
Kurzbeschreibung (Außenansicht)	Ein Mitarbeiter der verordnenden LEI markiert über das PS ein durch die LEI verordnetes E-Rezept zum Löschen und bestätigt den Vorgang. Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert. Die personenbezogenen und medizinischen Daten im E-Rezept werden gelöscht. Der AccessCode wird im Primärsystem gelöscht.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "gelöscht". Es beinhaltet keine personenbezogenen oder medizinischen Daten.  Der Statuswechsel des E-Rezepts zum Status "gelöscht" ist im E-Rezept-Fachdienst protokolliert.

[<=]

3.5 E-Rezept durch Versicherten verwalten

3.5.1 E-Rezepte durch Versicherten abrufen

Mit diesem Anwendungsfall kann ein Versicherter alle seine im E-Rezept-Fachdienst eingestellten E-Rezepte herunterladen, um Einsicht in die Daten dieser E-Rezepte zu nehmen. Die E-Rezepte werden ohne QES des verordnenden LE bereitgestellt, dafür erhält der dem Versicherten bereitgestellte Datensatz eine Serversignatur zum Nachweis der Integrität und Authentizität, dass die bereitgestellten Daten mit den Daten der QES-Signatur übereinstimmen.

Beim Abruf der E-Rezepte im E-Rezept-FdV übermittelt der E-Rezept-Fachdienst auch den AccessCode der E-Rezepte. Dies ermöglicht das Erstellen von E-Rezept-Token.

A_18506 - Anwendungsfall "E-Rezepte durch Versicherten abrufen"

Alle am Anwendungsfall "E-Rezepte durch Versicherten abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 7: TAB_SYSLERP_009 Anwendungsfall E-Rezepte durch Versicherten abrufen

Name	UC 3.1 - E-Rezepte durch Versicherten abrufen
Vorbedingung	keine
Kurzbeschreibung (Außenansicht)	Ein Versicherter ruft über ein FdV (E-Rezept-FdV) alle seine im E-Rezept-Fachdienst eingestellten Rezepte ab. Der E-Rezept-Fachdienst identifiziert die E-Rezepte auf Basis der Versicherten-ID des Versicherten und liefert die E-Rezepte, Status und die Zeitpunkte, an denen die Status gesetzt wurden. Die AccessCodes werden nur übermittelt, wenn der Abruf über ein E-Rezept-FdV erfolgt.
Nachbedingung	Im FdV stehen die E-Rezepte zur Anzeige sowie die Daten für das Erstellen eines E-Rezept-Tokens bereit. Der Abruf ist im E-Rezept-Fachdienst protokolliert.

[<=]

3.5.2 E-Rezept durch Vertreter abrufen

Mit diesem Anwendungsfall kann ein Vertreter ein im E-Rezept-Fachdienst eingestelltes E-Rezept herunterladen, um Einsicht in die Daten des E-Rezepts zu nehmen.

A_18781 - Anwendungsfall "E-Rezept durch Vertreter abrufen"

Alle am Anwendungsfall "E-Rezept durch Vertreter abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 8: TAB_SYSLERP_041 Anwendungsfall E-Rezept durch Vertreter abrufen

Name	UC 3.6 - E-Rezept durch Vertreter abrufen
Vorbedingung	Der Vertreter hat den E-Rezept-Token vom Versicherten/Vertreter oder der verordnenden LEI empfangen. Der E-Rezept-Token ist im Frontend des Versicherten gespeichert.
Kurzbeschreibung (Außenansicht)	Ein Vertreter ruft über das Frontend des Versicherten ein im E-Rezept-Fachdienst eingestelltes Rezept ab. Der E-Rezept-Fachdienst liefert das E-Rezept, den Status und den Zeitpunkt, an dem der Status gesetzt wurde.
Nachbedingung	Im FdV steht das E-Rezept zur Anzeige bereit. Der Abruf ist im E-Rezept-Fachdienst protokolliert.

[<=]

3.5.3 E-Rezept durch Versicherten löschen

Mit diesem Anwendungsfall kann der Versicherte den Status für ein für ihn eingestelltes E-Rezept auf "gelöscht" setzen. Die Nutzer können auf ein E-Rezept mit dem Status "gelöscht" nicht zugreifen.

Der Anwendungsfall kann nicht durch einen Vertreter ausgeführt werden.

A_18507 - Anwendungsfall "E-Rezept durch Versicherten löschen"

Alle am Anwendungsfall "E-Rezept durch Versicherten löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 9: TAB_SYSLERP_010 Anwendungsfall E-Rezept durch Versicherten löschen

Name	UC 3.2 - E-Rezept durch Versicherten löschen
Vorbedingung	Der Versicherte hat den Anwendungsfall "UC 3.1 - E-Rezepte durch Versicherten abrufen" ausgeführt. Das E-Rezept hat einen Status ungleich "in Abgabe (gesperrt)"
Kurzbeschreibung (Außenansicht)	Ein Versicherter wählt am FdV (E-Rezept-FdV) ein für ihn ausgestelltes E-Rezept aus, das gelöscht werden soll. Der Versicherte bestätigt das Löschen. Das FdV überträgt die Anforderung an den E-Rezept-Fachdienst.  Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert. Die personenbezogenen und medizinischen Daten im E-Rezept werden auf dem E-Rezept-Fachdienst gelöscht. Abschließend wird der E-Rezept-Token im E-Rezept-FdV gelöscht.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "gelöscht". Es beinhaltet keine personenbezogenen oder medizinischen Daten.  Der Statuswechsel des E-Rezepts zum Status "gelöscht" ist im E-Rezept-Fachdienst protokolliert.

[<=]

3.5.4 Nachricht durch Versicherten an Abgebenden oder einen Vertreter übermitteln

Mit diesem Anwendungsfall kann ein Versicherter oder Vertreter einen E-Rezept-Token oder eine Mitteilung an eine Apotheke oder einen Vertreter seiner Wahl übermitteln, um das Rezept einzulösen oder eine Anfrage zur Belieferung des Rezepts durch die Apotheke zu stellen. Als Alternative steht die optische Übermittlung des E-Rezept-Tokens als 2D-Code zur Verfügung. 

A_18508 - Anwendungsfall "Nachricht durch Versicherten übermitteln"

Alle am Anwendungsfall "Nachricht durch Versicherten übermitteln" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 10: TAB_SYSLERP_011 Anwendungsfall Nachricht durch Versicherten übermitteln

Name	UC 3.3 - Nachricht durch Versicherten übermitteln
Vorbedingung	Der Versicherte hat den Anwendungsfall "UC 3.1 - E-Rezepte durch Versicherten abrufen" ausgeführt. Das FdV hat einen E-Rezept-Token erstellt. alternativ: Der Vertreter hat von einem Versicherten einen E-Rezept-Token erhalten. Ein E-Rezept-Token liegt im FdV vor.
Kurzbeschreibung (Außenansicht)	Ein Versicherter/Vertreter wählt im FdV einen E-Rezept-Token aus und trifft dann die Entscheidung, ob der Versand über die TI oder alternativ optisch per 2D-Code stattfinden soll. Der sichere Versand über die TI erfolgt mithilfe des E-Rezept-Fachdienstes. Versand an Apotheke: Der Versicherte wählt im Verzeichnisdienst die Apotheke aus, an die die Nachricht übermittelt werden soll. Versand an einen Versicherten: Der Versicherte gibt die KVNR des Empfängers (KVNR2) in das FdV ein, diese hat ihm der Empfänger mitgeteilt oder ist dem FdV aus einer vorherigen Nachricht bekannt. Anschließend stellt das FdV die Nachricht im E-Rezept-Fachdienst für den Empfänger ein. Die Nachricht enthält einen E-Rezept-Token und/oder eine Textnachricht. Im Falle der Alternative wird der E-Rezept-Token in einen 2D-Code umgewandelt und dem Abgebenden oder Vertreter entweder zum Scannen an einem Bildschirm gezeigt oder als Ausdruck übergeben.
Nachbedingung	Die Nachricht mit dem E-Rezept-Token liegt im E-Rezept-Fachdienst und kann vom Empfänger asynchron empfangen werden. Im Falle der Alternative kann der Empfänger den 2D-Code abscannen.

[<=]

3.5.5 E-Rezept-Token durch Versicherten an Vertreter übermitteln

Die Benennung eines Vertreters mit Mitteln der Telematikinfrastruktur erfolgt über den UseCase "UC 3.3 - Nachricht durch Versicherten übermitteln". Eine Übergabe des Tokens außerhalb der TI kann mittels Schnittstellen des E-Rezept-FdV erfolgen, welche in einer Rechtsverordnung zu § 360 Abs. 5 PDSG definiert werden.

3.5.6 Nachrichten durch Versicherten empfangen

Mit diesem Anwendungsfall kann ein Versicherter oder Vertreter eine oder mehrere Nachrichten von abgebenden LEI zu E-Rezepten mittels der sicheren Übertragung über die TI empfangen.

A_18618 - Anwendungsfall "Nachrichten durch Versicherten empfangen"

Alle am Anwendungsfall "Nachrichten durch Versicherten empfangen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 11: TAB_SYSLERP_037 Anwendungsfall Nachrichten durch Versicherten empfangen

Name	UC 3.4 - Nachrichten durch Versicherten empfangen
Vorbedingung	Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.7 - Nachricht durch Abgebenden übermitteln" ausgeführt. Ein Versicherter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt.
Kurzbeschreibung (Außenansicht)	Das FdV fragt beim E-Rezept-Fachdienst an, ob neue Nachrichten für den Nutzer des FdV vorliegen und lädt diese herunter.
Nachbedingung	Die Nachrichten liegen im FdV zur Anzeige bereit.

[<=]

3.5.7 Nachricht durch Versicherten löschen

Mit diesem Anwendungsfall kann der Versicherte von ihm übermittelte Nachrichten an Apotheken oder Versicherte löschen. Im Ergebnis der Löschanforderung wird dem Versicherten mitgeteilt, ob die Nachricht bereits vom Empfänger abgerufen wurde.

A_20260 - Anwendungsfall "Nachricht durch Versicherten löschen"

Alle am Anwendungsfall "Nachricht durch Versicherten löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 12: TAB_SYSLERP_061 Anwendungsfall Nachricht durch Versicherten löschen

Name	UC 3.8 - Nachricht durch Versicherten löschen
Vorbedingung	Ein Versicherter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt.
Kurzbeschreibung (Außenansicht)	Der Versicherte wählt eine oder mehrere zuvor von ihm übermittelte Nachrichten zum Löschen aus. Der Versicherte bestätigt das Löschen. Das FdV überträgt für jede zu löschende Nachricht die Löschanforderung an den E-Rezept-Fachdienst.  Die zu löschenden Nachrichten werden im E-Rezept-Fachdienst gelöscht. Der E-Rezept-Fachdienst übermittelt dem FdV eine Warning, wenn die Nachricht bereits durch den Empfänger abgerufen wurde. Abschließend werden die zu löschenden Nachrichten im FdV gelöscht.
Nachbedingung	Die Nachrichten sind auf dem E-Rezept-Fachdienst und im FdV gelöscht.

[<=]

3.5.8 Protokolldaten durch Versicherten einsehen

Mit diesem Anwendungsfall nimmt der Versicherte Einsicht in das Zugriffsprotokoll. Darin ersichtlich sind das Einstellen von E-Rezepten für den Versicherten, alle folgenden Statuswechsel zu diesen E-Rezepten sowie das Löschen von E-Rezepten.

A_18510 - Anwendungsfall "Protokolldaten abrufen"

Alle am Anwendungsfall "Protokolldaten abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 13: TAB_SYSLERP_013 Anwendungsfall Protokolldaten abrufen

Name	UC 3.5 - Protokolldaten abrufen
Vorbedingung	keine
Kurzbeschreibung (Außenansicht)	Ein Versicherter ruft über das FdV (E-Rezept-FdV) alle Protokolleinträge zur Anzeige ab. Für die Abfrage können Filterkriterien, wie bspw. ein Zeitraum angegeben werden.
Nachbedingung	Die Protokolleinträge stehen zur Anzeige bereit.

[<=]

3.6 E-Rezept in Apotheke einlösen

3.6.1 Nachrichten durch Abgebenden empfangen

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution Nachrichten vom E-Rezept-Fachdienst abrufen. Alternativ können E-Rezept-Token als 2D-Code im AVS eingescannt werden.

A_18617 - Anwendungsfall "Nachrichten durch Abgebenden empfangen"

Alle am Anwendungsfall "Nachrichten durch Abgebenden empfangen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 14: TAB_SYSLERP_036 Anwendungsfall Nachrichten durch Abgebenden empfangen

Name	UC 4.6 - Nachrichten durch Abgebenden empfangen
Vorbedingung	Ein Versicherter oder Vertreter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt Alternativ kann ein Versicherter oder Vertreter persönlich in der Apotheke den  2D-Code des E-Rezept-Tokens ausgedruckt oder als Anzeige in einem mobilen Gerät dem Abgebenden präsentieren.
Kurzbeschreibung (Außenansicht)	Der Mitarbeiter der abgebenden LEI wählt im PS aus, ob er einen E-Rezept-Token über die TI empfangen möchte oder der E-Rezept-Token als 2D-Code vorliegt. Das Empfangen über die TI erfolgt mithilfe des E-Rezept-Fachdienstes. Das PS fragt beim E-Rezept-Fachdienstes an, ob für die Telematik-ID der LEI neue Nachrichten vorliegen und lädt diese herunter. Im Falle der Alternative über den 2D-Code wandelt das PS die optische Repräsentation in die Textform um.
Nachbedingung	Der E-Rezept-Token liegt im PS der abgebenden LEI vor.

[<=]

3.6.2 Nachricht durch Abgebenden an Versicherten übermitteln

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution auf ein mittels dem E-Rezept-Fachdienst übermittelten E-Rezept-Token reagieren und dem Absender eine Nachricht, bspw. über die Verfügbarkeit,  übermitteln.

A_19013 - Anwendungsfall "Nachricht durch Abgebenden übermitteln"

Alle am Anwendungsfall "Nachricht durch Abgebenden übermitteln" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 15: TAB_SYSLERP_055 Anwendungsfall Nachricht durch Abgebenden übermitteln

Name	UC 4.7 - Nachricht durch Abgebenden übermitteln
Vorbedingung	Ein Versicherter oder Vertreter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt. Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.6 - Nachrichten durch Abgebenden empfangen" durchgeführt.
Kurzbeschreibung (Außenansicht)	Der Mitarbeiter der abgebenden LEI wählt im PS die Nachricht eines Versicherten bzw. Vertreters zu einem E-Rezept aus und erstellt eine Antwortnachricht. Der sichere Versand über die TI erfolgt mithilfe des E-Rezept-Fachdienstes. Als Empfänger wird der Absender der ursprünglichen Nachricht gesetzt. Das PS stellt die Nachricht in den E-Rezept-Fachdienst ein.
Nachbedingung	Der Nachricht liegt im E-Rezept-Fachdienst und kann vom Versicherten bzw. Vertreter asynchron empfangen werden.

[<=]

3.6.3 Nachricht durch Abgebenden löschen

Mit diesem Anwendungsfall kann der abgebende Leistungserbringer von ihm übermittelte Nachrichten an Versicherte löschen. Im Ergebnis der Löschanforderung wird dem Primärsystem des abgebenden Leistungserbringers mitgeteilt, ob die Nachricht bereits vom Empfänger abgerufen wurde.

A_20776 - Anwendungsfall "Nachricht durch Abgebenden löschen"

Alle am Anwendungsfall "Nachricht durch Abgebenden löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 16: TAB_SYSLERP_062 Anwendungsfall Nachricht durch Abgebenden löschen

Name	UC 4.9 - Nachricht durch Abgebenden löschen
Vorbedingung	Ein abgebender Leistungserbringer hat den Anwendungsfall "UC 4.7 - Nachricht durch Abgebenden übermitteln" ausgeführt.
Kurzbeschreibung (Außenansicht)	Der Abgebende wählt eine oder mehrere zuvor von ihm übermittelte Nachrichten zum Löschen aus. Der Abgebende bestätigt das Löschen. Das Primärsystem des Abgebenden überträgt für jede zu löschende Nachricht die Löschanforderung an den E-Rezept-Fachdienst.  Die zu löschenden Nachrichten werden im E-Rezept-Fachdienst gelöscht. Der E-Rezept-Fachdienst übermittelt dem Primärsystem eine Warnung, wenn die Nachricht bereits durch den Empfänger abgerufen wurde. Abschließend werden die zu löschenden Nachrichten im Primärsystem gelöscht.
Nachbedingung	Die Nachrichten sind auf dem E-Rezept-Fachdienst und im FdV gelöscht.

[<=]

3.6.4 E-Rezept durch Abgebenden abrufen

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution ein E-Rezept auf Basis eines durch den Versicherten, einen Vertreter oder die verordnende LEI übermittelten E-Rezept-Tokens aus dem E-Rezept-Fachdienst abrufen.

A_18511 - Anwendungsfall "E-Rezept durch Abgebenden abrufen"

Alle am Anwendungsfall "E-Rezept durch Abgebenden abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 17: TAB_SYSLERP_014 Anwendungsfall E-Rezept durch Abgebenden abrufen

Name	UC 4.1 - E-Rezept durch Abgebenden abrufen
Vorbedingung	Ein Versicherter, ein Vertreter oder eine verordnende LEI haben der abgebenden LEI einen E-Rezept-Token übermittelt. Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.6 - Nachrichten durch Abgebenden empfangen" durchgeführt. Der E-Rezept-Token liegt im Primärsystem vor. Das E-Rezept im E-Rezept-Fachdienst hat den Status "offen".
Kurzbeschreibung (Außenansicht)	Ein Mitarbeiter der abgebenden LEI wählt einen E-Rezept-Token zum Abruf im PS aus. Das PS ermittelt die Rezept-ID und den AccessCode aus dem E-Rezept-Token. Das PS ruft mit der Rezept-ID und dem AccessCode das E-Rezept vom E-Rezept-Fachdienst ab. Der Status des E-Rezepts im E-Rezept-Fachdienst wird auf "in Abgabe (gesperrt)" geändert. Der E-Rezept-Fachdienst erzeugt ein Geheimnis zur Statusänderung "in Abgabe (gesperrt)", welches im E-Rezept-Fachdienst gespeichert und dem PS zusammen mit dem E-Rezept übermittelt wird. Das PS prüft die Gültigkeit der QES des E-Rezepts mittels Konnektor.
Nachbedingung	Das E-Rezept hat im E-Rezept-Fachdienst den Status "in Abgabe (gesperrt)". Der Statuswechsel ist im E-Rezept-Fachdienst protokolliert. Das E-Rezept steht zur Anzeige im AVS bereit. Das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" ist im PS gespeichert.

[<=]

3.6.5 E-Rezept durch Abgebenden zurückgeben

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution, ein zuvor aus dem E-Rezept-Fachdienst abgerufenes E-Rezept zurückgeben, wenn die Abgabe des E-Rezepts nicht vollzogen werden kann oder soll. 

A_18512 - Anwendungsfall "E-Rezept durch Abgebenden zurückgeben"

Alle am Anwendungsfall "E-Rezept durch Abgebenden zurückgeben" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 18: TAB_SYSLERP_015 Anwendungsfall E-Rezept durch Abgebenden zurückgeben

Name	UC 4.2 - E-Rezept durch Abgebenden zurückgeben
Vorbedingung	Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" durchgeführt. Die Rezept-ID, der AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" sind im PS bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "in Abgabe (gesperrt)".
Kurzbeschreibung (Außenansicht)	Ein Mitarbeiter der abgebenden LEI markiert über das PS ein E-Rezept zum Zurückgeben und bestätigt es. Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID, den AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)". Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "offen".  Der Statuswechsel des E-Rezepts zum Status "offen" ist im E-Rezept-Fachdienst protokolliert. Das E-Rezept, der E-Rezept-Token und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" sind im PS gelöscht.

[<=]

3.6.6 E-Rezept durch Abgebenden löschen

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution den Status für ein zuvor aus dem E-Rezept-Fachdienst abgerufenes E-Rezept auf "gelöscht" setzen. Die Nutzer können auf ein E-Rezept mit dem Status "gelöscht" nicht zugreifen.

A_18513 - Anwendungsfall "E-Rezept durch Abgebenden löschen"

Alle am Anwendungsfall "E-Rezept durch Abgebenden löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 19: TAB_SYSLERP_016 Anwendungsfall E-Rezept durch Abgebenden löschen

Name	UC 4.3 - E-Rezept durch Abgebenden löschen
Vorbedingung	Ein Versicherter, ein Vertreter oder eine verordnende LEI hat der abgebenden LEI einen E-Rezept-Token übermittelt. Der Versicherte hat der abgebenden LEI seinen Wunsch zum Löschen des E-Rezepts mitgeteilt Ein Mitarbeiter der abgebenden LEI hat die Anwendungsfälle "UC 4.6 - Nachrichten durch Abgebenden empfangen" und "UC 4.1 - E-Rezept durch Abgebenden abrufen" durchgeführt. Die Rezept-ID, der AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" sind im PS bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "in Abgabe (gesperrt)".
Kurzbeschreibung (Außenansicht)	Ein Mitarbeiter der abgebenden LEI markiert über das PS ein Rezept zum Löschen und bestätigt es. Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID, den AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)". Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert. Die personenbezogenen und medizinischen Daten im E-Rezept werden gelöscht.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "gelöscht". Es beinhaltet keine personenbezogenen oder medizinischen Daten. Der Statuswechsel des E-Rezepts zum Status "gelöscht" ist im E-Rezept-Fachdienst protokolliert. Das E-Rezept, der E-Rezept-Token und das Geheimnis sind im PS gelöscht.

[<=]

3.6.7 Quittung abrufen

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution ein zuvor aus dem E-Rezept-Fachdienst abgerufenes E-Rezept nach der Abgabe des Mittels als "quittiert" kennzeichnen und erhält eine Quittung.

A_18514 - Anwendungsfall "Quittung abrufen"

Alle am Anwendungsfall "Quittung abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 20: TAB_SYSLERP_017 Anwendungsfall Quittung abrufen

Name	UC 4.4 - Quittung abrufen
Vorbedingung	Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" durchgeführt. Das Primärsystem hat die QES des E-Rezepts erfolgreich geprüft. Die QES des E-Rezepts ist gültig. Die Rezept-ID, der AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" des E-Rezepts sind im PS bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "in Abgabe (gesperrt)".
Kurzbeschreibung (Außenansicht)	Ein Mitarbeiter der abgebenden LEI hat ein E-Rezept dispensiert. Er markiert das E-Rezept über das PS als abgegeben und bestätigt es. Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID, den AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" und die Informationen zur Abgabe. Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert. Der E-Rezept-Fachdienst erstellt eine Quittung und übermittelt diese an das PS.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "quittiert".  Die Information zur Abgabe liegen im E-Rezept-Fachdienst. Der Statuswechsel des E-Rezepts zum Status "quittiert" ist im E-Rezept-Fachdienst protokolliert. Im PS liegt eine Quittung vor, welche bspw. für die Abrechnung des E-Rezepts genutzt werden kann.

[<=]

3.6.8 Quittung erneut abrufen

Falls beim Aufruf der Operation "UC 4.4 - Quittung abrufen" ein Fehler bei der Übertragung der Quittung an das AVS auftrat, hat die abgebende LEI die Möglichkeit, die zuvor erstellte Quittung noch einmal abzurufen.

Der Anwendungsfall führt zu keiner Änderung am Status des E-Rezepts.

A_19117 - Anwendungsfall "Quittung erneut abrufen"

Alle am Anwendungsfall "Quittung erneut abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 21: TAB_SYSLERP_057 Anwendungsfall Quittung erneut abrufen

Name	UC 4.8 - Quittung erneut abrufen
Vorbedingung	Ein Mitarbeiter der abgebenden LEI hat den Anwendungsfall "UC 4.4 - Quittung abrufen" durchgeführt. Im PS liegt keine  Quittung vor. Das E-Rezept im E-Rezept-Fachdienst hat den Status "quittiert".
Kurzbeschreibung (Außenansicht)	Ein Mitarbeiter der abgebenden LEI wählt das E-Rezept über das PS aus, um erneut die Quittung abzurufen. Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" . Der E-Rezept-Fachdienst übermittelt die im Anwendungsfall "UC 4.4 - Quittung abrufen" erstellte Quittung an das PS.
Nachbedingung	Im PS liegt eine Quittung vor, welche bspw. für die Abrechnung des E-Rezepts genutzt werden kann.

[<=]

3.6.9 Dispensierdatensatz durch Abgebenden signieren

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution einen Dispensierdatensatz signieren. In Abhängigkeit der arzneimittelrechtlichen Vorschriften und der Verträge nach § 129 SGB V wird dieser Datensatz qualifiziert (QES) bzw. fortgeschritten (nonQES) signiert. 

A_18515 - Anwendungsfall "Dispensierdatensatz durch Abgebenden signieren"

Alle am Anwendungsfall "Dispensierdatensatz durch Abgebenden signieren" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 22: TAB_SYSLERP_018 Anwendungsfall Dispensierdatensatz durch Abgebenden signieren

Name	UC 4.5 - Dispensierdatensatz durch Abgebenden signieren
Vorbedingung	Ein E-Rezept wurde dispensiert. Der Dispensierdatensatz steht zum Signieren im PS bereit. Der HBA bzw. eine SMC-B ist für das Signieren gesteckt und freigeschaltet.
Kurzbeschreibung (Außenansicht)	Falls die Abgabe ohne Änderung erfolgte, signiert ein Mitarbeiter der abgebenden LEI den Dispensierdatensatz mit einer fortgeschrittenen Signatur. Falls die Abgabe mit Änderung der Verschreibung nach § 17 (5) ApoBetrO erfolgte, signiert der abgebende Leistungserbringer den Dispensierdatensatz mit einer QES.
Nachbedingung	Der Dispensierdatensatz ist durch den Abgebenden signiert.

[<=]

3.7 Anfordern von Identitätsbestätigungen

3.7.1 Identitätsbestätigung durch den Versicherten anfordern

Dieser Anwendungsfall betrifft die Anforderung eine Identitätsbestätigung (AuthN-Token) für den aktuellen Nutzer durch das FdV. Er ist Bestandteil aller Anwendungsfälle, die für einen Zugriff auf einen Dienst der TI (Ausnahme: Zugriff auf IDP) ein solches Token benötigen, siehe die Ablaufbeschreibungen (Sequenzdiagramme) der oben aufgeführten Anwendungsfälle.

A_18822 - Anwendungsfall "AuthN-Token durch Versicherten anfordern"

Alle am Anwendungsfall "AuthN-Token durch Versicherten anfordern" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 23: TAB_SYSLERP_045 AuthN-Token durch Versicherten anfordern

Name	UC 5.1 - AuthN-Token durch Versicherten anfordern
Vorbedingung	Die eGK des Versicherten kann über Gerät des Nutzers gelesen werden Es liegt kein gültiger AuthN-Token vor (zeitlich nicht mehr gültig oder fehlende Identitätsattribute)
Kurzbeschreibung (Außensicht)	Das FdV übergibt die Authentifizierungs-Anforderung mit den angeforderten Identitätsmerkmalen an das Authentisierungsmodul. Dieses leitet die Anforderung an den IDP weiter. Falls beim IDP keine gültige Sitzung vorliegt: Authentifizierung des Versicherten per Challenge/Response-Verfahren (eGK). Das Authentisierungsmodul greift dazu auf die AUT-Identität der eGK zu. Falls beim IDP keine gültige Sitzung vorliegt oder erweiterte Identitätsattribute angefragt sind: Einholen einer Einwilligung des Versicherten zur Bereitstellung der Identitätsattribute über das Authentisierungsmodul. Der IDP erstellt AuthN-Token mit den angefragten und bestätigten Identitätsattributen und einen zugehörigen AuthN Code. Der IDP übergibt den AuthN Code an das Authentisierungsmodul. Das Authentisierungsmodul übergibt den AuthN Code an das FdV. Das FdV fragt mittels des erhaltenen AuthN Codes den AuthN-Token beim IDP ab. Der IDP stellt dem FdV den AuthN-Token bereit.
Nachbedingung	Ein AuthN-Token mit den angeforderten Identitätsmerkmalen liegt im FdV vor.

[<=]

In Ausbaustufen des IDP bzw. mit der Förderierung der IDPs zu einem umfassenden Identity Management sind weitere Authentifizierungssverfahren (ggfs. über alternative Identifikationsmittel) denkbar, sofern sie das jeweils aus dem Schutzniveau der Daten abgeleitete Sicherheitsniveau erfüllen (Sicherheitsniveau im E-Rezept: 'hoch').

3.7.2 Identitätsbestätigung durch LEI anfordern

Dieser Anwendungsfall betrifft die Anforderung eines AuthN-Tokens durch eine LEI über das Primärsystem. Er ist Bestandteil aller Anwendungsfälle, die für einen Zugriff auf einen Dienst der TI (Ausnahme: Zugriff auf IDP) ein solches Token benötigen, siehe die Ablaufbeschreibungen (Sequenzdiagramme) der oben aufgeführten Anwendungsfälle.

A_18827 - Anwendungsfall "AuthN-Token durch LEI anfordern"

Alle am Anwendungsfall "AuthN-Token durch LEI anfordern" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 24 TAB_SYSLERP_046 AuthN-Token durch LEI anfordern

Name	UC 5.2 - AuthN-Token durch LEI anfordern
Vorbedingung	SMC-B ist gesteckt und freigeschaltet Es liegt kein gültiger AuthN-Token vor (zeitlich nicht mehr gültig oder fehlende Identitätsattribute).
Kurzbeschreibung (Außensicht)	Das Client System (PS/AVS) übergibt die Authentifizierungs-Anforderung mit den angeforderten Identitätsmerkmalen an das Authentisierungsmodul. Dieses leitet die Anforderung an den IDP weiter. Falls beim IDP keine gültige Sitzung vorliegt: Authentifizierung der LEI per Challenge/Response-Verfahren (SMC-B). Das Authentisierungsmodul greift dazu über die Konnektorschnittstelle I_Sign_Operations::external_authenticate auf die AUT-Identität der SMC-B zu. Falls beim IDP keine gültige Sitzung vorliegt oder erweiterte Identitätsattribute angefragt sind: Einholen einer Einwilligung des LEI-Mitarbeiters zur Bereitstellung der Identitätsattribute über das Authentisierungsmodul. Der IDP erstellt AuthN-Token mit den angefragten und bestätigten Identitätsattributen und einen zugehörigen AuthN Code. Der IDP übergibt den AuthN Code an das Authentisierungsmodul. Das Authentisierungsmodul übergibt den Code an das Client System (PVS/AVS). Das Client System (PVS/AVS) fragt mittels des erhaltenen AuthN Codes den AuthN-Token beim IDP ab. Der IDP stellt dem Client System (PVS/AVS) den AuthN-Token bereit.
Nachbedingung	Ein AuthN-Token mit den angeforderten Identitätsmerkmalen liegt im Client System vor.

[<=]

4 Systemzerlegung (Deployment)

Die Fachanwendung E-Rezept realisiert die fachlichen Anwendungsfälle über das Zusammenspiel mehrerer Produkttypen in verschiedenen Zonen der TI. Die Systemzerlegung der Fachanwendung ist in der nachfolgenden Abbildung "Systemzerlegung E-Rezept" dargestellt. Sie ordnet die fachanwendungsspezifischen Produkttypen (blau dargestellt) und ihre Komponenten den Zonen gemäß Zonenmodell der TI-Plattform aus [gemKPT_Arch_TIP] zu.

Fachanwendungsübergreifende zentrale Produkttypen, für die sich mit der Einführung der Fachanwendung E-Rezept zusätzliche Anforderungen ergeben, sind grün dargestellt.

Abbildung 7: ABB_SYSLERP_006 Systemzerlegung E-Rezept

Der E-Rezept-Fachdienst verwaltet die durch die Verordnenden eingestellten E-Rezepte und stellt sicher, dass die Statusänderungen nur entsprechend dem Statusmodell durchgeführt werden. Der E-Rezept-Fachdienst erstellt und verwaltet die Zugriffsprotokolle für die E-Rezepte.

Der E-Rezept-Fachdienst ermöglicht die sichere Übertragung von E-Rezept-Token zwischen Versicherten, Vertretern und Abgebenden über die TI. Wenn der Empfänger eine Apotheke ist, kann diese im Verzeichnisdienst der TI ausgewählt werden. Die Übertragung erfolgt asynchron.

Folgende anwendungsübergreifenden Dienste der Provider Zone werden durch die fachanwendungsspezifischen Produkttypen und Komponenten genutzt.

Der Identity Provider authentifiziert Akteure und erstellt Identitätstoken, auf deren Basis die fachanwendungsspezifischen und fachanwendungsübergreifenden Dienste den Zugriff auf Ressourcen autorisieren.

Der Verzeichnisdienst der TI ermöglicht die Suche nach abgebenden LEIs für Versicherte, Vertreter und verordnende LEIs für die Übermittlung von E-Rezept-Token.

4.1 Produkttypen der Fachanwendung E-Rezept

Es besteht die Möglichkeit, dass E-Rezept-Token optisch übertragen werden. Dafür wird eine Darstellung von E-Rezept-Token als 2D-Code vorgesehen. Der bundeseinheitliche Medikationsplan (BMP) besitzt eine Darstellung als DataMatrix-Code,welcher durch die Primärsysteme der Leistungserbringer seit Oktober 2016 gedruckt und gescannt werden kann. Durch die weite Verbreitung bietet sich die Verwendung des gleichen Standards auch in der Fachanwendung E-Rezept an.

Neben dem E-Rezept-Fachdienst bieten auch der Verzeichnisdienst und der Identity Provider, welche für die Anwendung E-Rezept genutzt werden, ihre Dienste im Internet an.

Um ein Single Sign-On zu ermöglichen, werden die Nutzer von den Diensten mittels einer durch einen IDP ausgestellten Identitätsbestätigung authentifiziert.

4.1.1 Produkttyp E-Rezept-Fachdienst

Der E-Rezept-Fachdienst ist ein offener fachanwendungsspezifischer Dienst in der TI zum Speichern der E-Rezepte. Er ist im Zonenmodell der TI-Plattform der Provider Zone zugeordnet.

Es gibt genau einen Anbieter für den E-Rezept-Fachdienst, d.h. alle Akteure greifen auf denselben Dienst zu.

Die Rezept-ID ist Teil des fachlichen Informationsmodells des E-Rezepts. Sie identifiziert das E-Rezept über den gesamten Lebenszyklus, d.h. auch in den Abrechnungsprozessen. Die Rezept-ID kann eine fortlaufende Nummer sein.

Die Zugriffsautorisierung erfolgt u.a. auf Basis eines AccessCodes, welcher durch den E-Rezept-Fachdienst für jedes Rezept erstellt wird.

Für einen Überblick der Status und der Statusübergänge siehe .

Hinweis: Diese Quittung kann in Abrechnungsprozessen verwendet werden, um sicherzustellen, dass ein E-Rezept nur einmal abgerechnet wird.

Das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" wird genutzt, um den exklusiven Zugriff und die Zulässigkeit des folgenden Statusüberganges sicherzustellen.

Das Löschen eines E-Rezept-Datensatzes erfolgt automatisiert entsprechend einer Löschfrist durch den E-Rezept-Fachdienst.

Für die Identifikation des E-Rezepts im Protokolleintrag wird die Rezept-ID verwendet.

Um eine missbräuliche Verwendung von eGK-Prüfkarten auszuschließen, prüft der E-Rezept-Fachdienst die Verwendung der eGK-Prüfkarte in den Anwendungsfällen der Vertreterkommunikation und des Vertreterzugriffs auf E-Rezepte. 

4.1.1.1 Vertrauenswürdige Ausführungsumgebung

Der E-Rezept-Fachdienst wird in einer Vertrauenswürdigen Ausführungsumgebung betrieben und garantiert damit den Ausschluss des Anbieters des Dienstes vom Zugriff auf die verarbeiteten Nutzdaten der E-Rezepte.

Im Folgenden werden betrieblich-funktionalen Aspekte beschrieben, die bei der Umsetzung der VAU des E-Rezept-Fachdienstes zu berücksichtigen sind, um der Situation des Anbieterausschlusses Rechnung zu tragen. Die Sicherheitsmechanismen werden in Kapitel 5 behandelt.

4.1.1.2 Betriebliche Aspekte

Der Anbieter E-Rezept-Fachdienst liefert Rohdaten zu Performance-Kennzahlen für die Überwachung der TI an die gematik. Die notwendigen Tätigkeiten im Rahmen der Serviceerbringung (Mitwirkungspflichten, Service Level) sowie die Teilnahme an den TI-ITSM-Prozessen ist in [gemKPT_Betr] und [gemRL_Betr_TI] geregelt.

Die Verifikationskriterien werden im Rahmen des betrieblichen Change-Prozesses in Zusammenarbeit mit dem Anbieter von der gematik festgelegt. Sie können auch das Erfordernis umschließen, den Nachweis mittels einer Ende-zu-Ende Verifikation zu erbringen.

4.1.2 Produkttyp E-Rezept-Frontend des Versicherten

Das E-Rezept-Frontend des Versicherten wird in der Versichertenumgebung, d.h. auf einem Gerät des Versicherten, genutzt. Das E-Rezept-Frontend des Versicherten führt die dezentrale Fachlogik der Fachanwendung E-Rezept aus. Es ermöglicht dem Versicherten die Verwaltung seiner E-Rezepte.

Es gibt genau einen Anbieter für das E-Rezept-Frontend des Versicherten.

Das E-Rezept-Frontend des Versicherten wird durch die gematik bereitgestellt.

Eine zusätzliche Funktionalität ist beispielsweise die Anfrage zur Belieferung durch eine Apotheke oder Download digitaler Beipackzettel.

Ein DataMatrix-Code kann einen oder mehrere E-Rezept-Token beinhalten, um den Versicherten zu ermöglichen, mehrere E-Rezepte mit einem Abscann-Vorgang der Apotheke zuzuweisen.

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.

Wenn das FdV sich mit der TI verbindet, dann können alle Daten zu einem E-Rezept angezeigt werden. Wird das FdV ohne Verbindung zur TI genutzt und der E-Rezept-Token bspw. eingescannt, dann soll das FdV die beschreibenden Metadaten aus dem E-Rezept-Token anzeigen können.

Der Versicherte soll für die Suche im Verzeichnis Suchkriterien eingeben und über die Ergebnismenge filtern können. Filterkriterien können bspw. der Name, die Adresse oder Geoinformationen sein.

Das Frontend soll den Nutzer bei der intuitiven Nutzung der Fachanwendung E-Rezept unterstützen. Beispielsweise:

• Information über neu vorliegende Nachrichten durch Abgebende,
• automatische Information über Statusänderungen von E-Rezepten im E-Rezept-Fachdienst,
• Ausdruck des DataMatrix-Code für einen E-Rezept-Token,
• Filterfunktionen zur Auswahl abgebender LEI aus dem Verzeichnis,
• Filterfunktionen für die Anzeige der Protokolleinträge.

4.1.3 Primärsysteme

Die Primärsysteme stellen das Frontend für Leistungserbringer dar. Hiermit greift der Leistungserbringer auf die Fachanwendung E-Rezept zu.

Die Primärsysteme verwalten in einer lokalen Datenbasis die notwendigen Informationen zu den in der Fachanwendung E-Rezept eingesetzten SMC-Bs und HBAs. Praxisverwaltungssysteme verwalten zusätzlich die zur Verordnung notwendigen Versichertendaten (KVNR).

Für die Erzeugung einer fortgeschrittenen oder qualifizierten elektronischen Signatur sowie für die Prüfung einer qualifizierten elektronischen Signatur nutzt ein Primärsystem Schnittstellen der TI-Plattform, die die tatsächlichen kryptographischen Operationen durchführen.

Wenn das Primärsystem einer verordnenden oder abgebenden LEI eine Operation aufruft, mit der der Status eines E-Rezepts geändert werden soll, dann prüft der E-Rezept-Fachdienst die Zulässigkeit des Statuswechsels (vgl.  ).

Bei der Verordnung und der Abgabe eines E-Rezepts kann es Wechselwirkungen mit anderen Fachanwendungen der TI (bspw. eMP/AMTS oder ePA) geben. Der Leistungserbringer soll dabei unterstützt werden, die Daten in mehreren Anwendungen zu nutzen, bspw. die Bereitstellung der Daten des E-Rezepts für die Aktualisierung des eMP.

4.1.3.1 Primärsystem verordnender Leistungserbringer

Das Primärsystem verordnender Leistungserbringer ist ein ärztliches bzw. zahnärztliches Praxisverwaltungssystem (PVS) oder ein Krankenhausinformationssystem (KIS).

Rezept-ID und AccessCode sind die Informationen, welche für den Zugriff auf ein E-Rezept notwendig sind.

Der durch das PS erzeugte DataMatrix-Code beinhaltet die Informationen von einem E-Rezept-Token.

Neben der optischen Darstellung des E-Rezept-Tokens als DataMatrix-Code kann der Ausdruck weitere lesbare Informationen zum E-Rezept für den Empfänger enthalten. Die Ausgestaltung eines Formulars für den Ausdruck liegt nicht in der Regelungshoheit der gematik.

Ein Versand des E-Rezept-Token an den Versicherten ist nicht notwendig, da sich dieser die notwendigen Informationen mit seinem FdV vom E-Rezept-Fachdienst abrufen kann und den E-Rezept-Token im FdV erstellt.

Die Übermittlung eines E-Rezept-Token an eine abgebende LEI ist entsprechend der gesetzlichen Grundlagen gemäß §11 ApoG zulässig. Hierfür kann KOM-LE genutzt werden.

4.1.3.2 Primärsystem abgebender Leistungserbringer

Das Primärsystem abgebender Leistungserbringer ist ein Apothekenverwaltungssystem (AVS).

Ein DataMatrix-Code kann die Informationen von einem oder mehreren E-Rezept-Token enthalten.

Das Primärsystem der abgebenden Leistungserbringerinstitution darf nur E-Rezepte bearbeiten, zu deren Abgabe es gemäß Metadaten berechtigt ist.

Das E-Rezept wird auch bei nicht erfolgreicher Prüfung der Signatur im Primärsystem angezeigt.

4.2 Fachanwendungsübergreifende Produkttypen

4.2.1 Produkttyp Identity Provider

Der Identity Provider (IDP) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen bereitstellt. Die Bereitstellung von Authentifizierungsbestätigungen und Identitätsmerkmalen erfolgt in Form von Bearer Token (AuthN-Token). Der IDP bietet außerdem die Möglichkeit, bereits erfolgte Authentifizierungen eines Nutzers im Sinne eines Single Sign-on nachzunutzen. Als TIP-Nutzerdienst ist der Dienst der Provider Zone des TI-Zonenmodells zugeordnet. Der Dienst ist in der TI ggf. mehrfach vorhanden, wobei jeder einzelne IDP die Identitäten einer Gruppe von TI-Teilnehmern abdeckt.

Für die Fachanwendung E-Rezept werden IDPs für die nutzenden Leistungserbringerinstitutionen und die Versicherten genutzt. Deren Identitätsmerkmale bestimmen - zusammen mit den E-Rezept-Token - die Zugriffsberechtigungen auf Funktionen und Daten der Anwendung E-Rezept.

4.2.1.1 Funktionale Anforderungen

4.2.1.2 Betriebliche Aspekte

Der Anbieter des IDP liefert Rohdaten zu Performance-Kennzahlen für die Überwachung der TI an die gematik. Die notwendigen Tätigkeiten im Rahmen der Serviceerbringung (Mitwirkungspflichten, Service Level) sowie die Teilnahme an den TI-ITSM-Prozessen ist in [gemKPT_Betr]  und [gemRL_Betr_TI] geregelt.

Die Verifikationskriterien werden im Rahmen des betrieblichen Change-Prozesses in Zusammenarbeit mit dem Anbieter von der gematik festgelegt. Sie können auch das Erfordernis umschließen, den Nachweis mittels einer Ende-zu-Ende-Verifikation zu erbringen.

4.2.2 Authentisierungsmodul

Das Authentisierungsmodul ergänzt den IDP, um auf dem Gerät des Nutzers den Zugriff auf die Smart Card des Nutzers (z.B. über Kartenleser, NFC, Konnektor) umzusetzen. Es ermöglicht die Interaktion mit dem Nutzer zwecks Authentisierung und Einwilligung (Consent) in die Bereitstellung von Identitätsattributen. Dem IDP stellt das Authentisierungsmodul die Einwilligung des Nutzers und die für die Authentifizierung des Nutzers erforderlichen Daten bereit. Das Authentisierungsmodul alleine speichert den IDP-Sitzungsschlüssel (Subject Session ID) und ermöglicht einen Single Sign-On für alle den IDP nutzenden Anwendungen auf dem Gerät des Nutzers.

Für das Signieren mit einer SMC-B bzw. eGK siehe  bzw. . Für die Übergabe der signierten Challenge siehe 4.3.4

Die Anbindung der eGK kann mittels eines Kartenlesegerätes Klasse 1 oder mittels Near Field Communication (NFC) erfolgen.

4.2.3 Produkttyp Verzeichnisdienst der TI

Der durch die Fachanwendung E-Rezept genutzt Produkttyp Verzeichnisdienst der TI basiert auf dem Online-Produktivbetrieb Stufe 3 [OPB3] spezifizierten Produkttypen.

Folgende zusätzliche Anforderungen bestehen.

Der Versicherte kann für die Suche bspw. folgende Parameter verwenden: Institutionsname, Straße, Postleitzahl, Ort, Geodaten.

4.3 Schnittstelle der Fachanwendung E-Rezept

Der folgende Abschnitt beschreibt die interoperablen Schnittstellen der Fachanwendung E-Rezept, die zwischen Primärsystem verordnender LEI und E-Rezept-Fachdienst, zwischen Primärsystem abgebender LEI und E-Rezept-Fachdienst sowie zwischen Frontend des Versicherten und E-Rezept-Fachdienst genutzt werden.

Der folgende Abschnitt beschreibt die durch die Anwendung genutzten Ressourcen und zugehörigen Operationen, auf welche die Primärsysteme der verordnenden und abgebenden LEI und die FdV zugreifen können.

4.3.1 Schnittstelle für die Ressource E-Rezept

Die Ressource E-Rezept enthält alle Daten des fachlichen Informationsmodells und zusätzliche Informationen für die Verwaltung des E-Rezepts.

4.3.2 Schnittstelle für die Ressource E-Rezept-Nachricht

Die Ressource E-Rezept-Nachricht enthält alle Daten zur Übermittlung eines E-Rezept-Tokens.

4.3.3 Schnittstelle für die Ressource Zugriffsprotokolleintrag

Die Ressource Zugriffsprotokolleintrag enthält alle Daten zum Zugriff eines Akteurs auf die E-Rezept-Datensätze eines Versicherten. 

4.3.4 Schnittstelle für die Ressource signierte Challenge

Für die Authentifizierung bei Verwendung von Smart Cards der TI im Challenge-Response-Verfahren wird eine Schnittstelle zwischen Authentisierungsmodul und IDP benötigt. Dazu wird hier eine Ressource definiert.

4.3.5 Schnittstelle für die Ressource Einwilligung

Für das Einholen einer Einwilligung (Consent) des Nutzers in die Verwendung angefragter Identitätsattribute wird eine Schnittstelle zwischen Authentisierungsmodul und IDP benötigt. Dazu wird hier eine Ressource definiert.

5 Datenschutz- und Sicherheitsaspekte

Für die Akzeptanz der Fachanwendung E-Rezept durch die Nutzer ist die Gewährleistung des Datenschutzes und - damit verbunden - die Sicherheit der personenbezogenen medizinischen Daten ein unabdingbares Merkmal. Die Fachanwendung E-Rezept erreicht dies durch das Aufstellen von Anforderungen an den Datenschutz und die Informationssicherheit, das Prüfen der Einhaltung dieser Anforderungen in der Zulassung und die Überprüfung der Einhaltung der Anforderungen im laufenden Betrieb durch den Anbieter des E-Rezept-Fachdienstes selbst, aber auch durch Audits der gematik.

Die aufgestellten Anforderungen des Datenschutzes und der Informationssicherheit entsprechen dem Gebot der Angemessenheit dadurch, dass sie einerseits den Schutzbedarf der zu verarbeitenden Daten und andererseits die Umsetzungsfähigkeit durch den Hersteller des E-Rezept-Frontend des Versicherten und den Anbieter des E-Rezept-Fachdienstes berücksichtigen. Die Angemessenheit der Anforderungen hinsichtlich des Schutzbedarfs wird durch die Nutzung der Methoden zur Informationssicherheit und des Datenschutzes der TI unter Beachtung der Risiko-Policy der TI erreicht. Die Angemessenheit hinsichtlich der Umsetzbarkeit wird in den spezifizierten Technologien berücksichtigt.

Die Sicherheitsanforderungen an den E-Rezept-Fachdienst leiten sich zum einen vom Schutzbedarf der verarbeiteten Daten und zum anderen von der potenziellen negativen Beeinflussung der TI durch diesen Dienst ab.

Hinsichtlich des maßgeblichen Schutzbedarfs wurden folgende Informationsobjekte identifiziert:

Tabelle 50: TAB_SYSLERP_052 Schutzbedarf der maßgeblichen Informationsobjekte

Die für die Verfügbarkeit maßgeblichen Prozesse sind:

Tabelle 51: TAB_SYSLERP_053 Schutzbedarf der maßgeblichen Prozesse

Für die Aufrechterhaltung des Datenschutz- und Informationssicherheitsniveaus der TI ist es erforderlich, dass die TI durch die Nutzung der Fachanwendung E-Rezept nicht negativ beeinflusst wird. Eine Beeinträchtigung kann insbesondere über den Anschluss des E-Rezept-Fachdienstes erfolgen. Um dies zu verhindern, werden dem Anbieter des E-Rezept-Fachdienstes entsprechend dem Modularisierungskonzept in [gemSpec_DS_Anbieter] Module der Informationssicherheit und des Datenschutzes zugeordnet.

Über diese Module bzw. die zugehörigen Anforderungen wird der Anbieter auch verpflichtet, Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung einzurichten.

Aufgrund der Kritikalität des E-Rezept-Fachdienstes wird zudem eine Anforderung an die Vertrauenswürdigkeit des Anbieters des E-Rezept-Fachdienstes gestellt:

Beispiele für Kriterien des Nachweises der Vertrauenswürdigkeit sind, dass der Anbieter in den letzten fünf Jahren bereits Anwendungen betreibt, in denen besonders schützenswerte Daten nach Artikel 9 DSGVO (insbes. personenbezogene medizinische Daten) verarbeitet wurden, oder dass der Anbieter in den letzten drei Jahren keine meldepflichtigen Datenschutzvorfälle zu verzeichnen hatte. Eine weitere Möglichkeit wäre die Sicherstellung von Datenschutz und Sicherheit beim Anbieter durch externe Gutachter (z.B. im Rahmen von Zertifizierungen bzw. Prüfsiegeln) überprüfen und bestätigen zu lassen. 

5.1 Anforderungen an den E-Rezept-Fachdienst

Folgende Anforderungen müssen durch den E-Rezept-Fachdienst zudem umgesetzt werden:

5.1.1 Anforderungen an die Vertrauenswürdige Ausführungsumgebung

In diesem Abschnitt werden die Anforderungen an den E-Rezept-Fachdienst zur Umsetzung einer Vertrauenswürdigen Ausführungsumgebung (VAU) gestellt. Die VAU dient der datenschutzrechtlich zulässigen und sicheren Verarbeitung von schützenswerten unverschlüsselten Daten innerhalb des E-Rezept-Fachdienstes. Die VAU stellt dazu einen Verarbeitungskontext bereit, in dem die Verarbeitung sensibler Daten unverschlüsselt erfolgen kann. Dieser Verarbeitungskontext ist entsprechend zu schützen.

5.1.2 Verarbeitungskontext

Die Gesamtheit aus der für eine Verarbeitung der unverschlüsselten Daten erforderlichen Software, dem für diese Verarbeitung genutzten physikalischen System sowie den für die Integrität dieser Verarbeitung erforderlichen organisatorischen und physischen Rahmenbedingungen bildet den Verarbeitungskontext der Vertrauenswürdigen Ausführungsumgebung.

Der Verarbeitungskontext grenzt sich von allen weiteren, im betrieblichen Kontext beim Anbieter des E-Rezept-Fachdienstes vorhandenen Systemen und Prozessen dadurch ab, dass die unverschlüsselten Daten von Komponenten innerhalb des Verarbeitungskontextes aus erreichbar sind oder sein können, während sie dies von außerhalb des Verarbeitungskontextes nicht sind. Die schützenswerten Daten verlassen den Verarbeitungskontext ausschließlich gemäß wohldefinierten (Zugriffs-)Regeln und in verschlüsselter Form.

Zur Vertrauenswürdigen Ausführungsumgebung gehören neben den Verarbeitungskontexten alle für ihre Erreichbarkeit und betriebliche Steuerung erforderlichen Komponenten. Sie dürfen nur soweit unbedingt erforderlich als Teil des Verarbeitungskontextes implementiert sein.

Hinweis: für die Qualität der Transportverschlüsselung gelten die Anforderungen aus [gemSpec_Krypt].

Als Persistenz-Schlüssel wird ein kryptographischer, symmetrischer Schlüssel verstanden, der folgende Eigenschaften aufweist:

• Er schützt durch Ver- und Entschlüsselung sämtliche schützenswerten E-Rezept-bezogenen Daten.
• Er wird an die Verarbeitungskontexte, die auf die verschlüsselte Datenspeicherung zugreifen müssen, für die Nutzung zur Ver- und Entschlüsselung gespeicherter Daten im Rahmen der Initialisierung der Verarbeitungskontexte sicher übermittelt.
• Er ist vor jedem Zugriff durch den Anbieter des E-Rezept-Fachdienstes geschützt gespeichert.

Eine ggf. erforderliche Umschlüsselung der durch einen Persistenz-Schlüssel geschützten Daten ist nur innerhalb des Verarbeitungskontextes der VAU oder innerhalb eines HSM und nach Autorisierung im "Mehr-Augen-Prinzip" zulässig.

5.1.3 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld

Der Schutzbedarf der in der VAU verarbeiteten unverschlüsselten Daten erfordert den technischen Ausschluss von Zugriffen des Anbieters. Dies umfasst insbesondere Zugriffe durch Personen aus dem betrieblichen Umfeld des Anbieters.

Die VAU des E-Rezept-Fachdienstes benötigt symmetrisches Schlüsselmaterial für die Speicherung der E-Rezept-Daten außerhalb der VAU, um für persistierte Daten den Anbieter vom Zugriff auszuschließen. Die Funktionen der Vorhaltung und Bereitstellung des Persistenz-Schlüssels wird von einem HSM ausgefüllt. Das HSM muss die Integrität der Verarbeitungskontexte feststellen können, bevor es einen Persistenz-Schlüssel an einen Verarbeitungskontext übermittelt.

Die VAU des E-Rezept-Fachdienstes muss sich gegenüber Nutzern mittels eines Dienstzertifikats ausweisen, welches die Vertrauenswürdigkeit des Dienstes repräsentiert. Die Nutzung des privaten Schlüssels dieses Dienstzertifikats muss an die Integritätsprüfung der Verarbeitungskontexte gebunden sein und darf ausschließlich innerhalb eines HSM erfolgen.

5.1.4 Trennung von Session- und Request-Kontexten

In jedem Verarbeitungskontext der VAU des E-Rezept-Fachdienstes werden Daten unverschlüsselt verarbeitet, die zu genau einem Akteur gehören und dementsprechend einer authentifizierten Client-Verbindung zuzuordnen sind. Innerhalb einer Client-Session kann z. B. der verordnende Arzt ein mehrzeiliges Rezept (in Form eines E-Rezepts pro Zeile) im E-Rezept-Fachdienst ablegen.

Aus Gründen der Skalierbarkeit des Fachdienstes können Verarbeitungskontexte in verschiedenen Komponenten des Dienstes auf Basis verschiedener Methoden bzw. Technologien separiert werden.

Ein grundlegender Faktor für die Bewertung der Qualität der Kontextseparation ist die Komplexität der in jeder Komponente umgesetzten Verarbeitung und damit die Möglichkeit zur belastbaren Feststellung der Zuverlässigkeit der Kontextseparation in der Komponente.

Aus Sicherheitsgründen und aus Gründen der betrieblichen Stabilität müssen Verarbeitungsvorgänge und in ihnen möglicherweise auftretende Fehlerzustände voneinander isoliert werden. Ein konsistenter Systemzustand des E-Rezept-Fachdienstes muss auch nach einem schwerwiegenden Fehler in der Datenverarbeitung (z. B. aufgrund eines Hardware-Fehlers) wiederhergestellt werden können, ohne dass die Verfügbarkeit des Dienstes wesentlich eingeschränkt wird.

5.2 Anforderungen an das E-Rezept-Frontend des Versicherten

Für das E-Rezept-Frontend des Versicherten gelten die Anforderungen aus [gemSpec_DS_Hersteller].

Folgende Anforderungen müssen durch das E-Rezept-Frontend des Versicherten umgesetzt werden:

Hinweis: Die Best-Practice-Sicherheitsmaßnahmen sind abhängig von der Technologie, mit der das E-Rezept FdV vom Hersteller umgesetzt wird.

5.3 Anforderungen an den Identity Provider

Dem Anbieter des IDP werden entsprechend dem Modularisierungskonzept in [gemSpec_DS_Anbieter] Module der Informationssicherheit und des Datenschutzes zugeordnet.

Folgende Anforderungen müssen durch den IDP zudem umgesetzt werden:

Durch einen Missbrauch des IDP (z.B. durch einen Innentäter bei einem Authentifizierungsdienst) kann ein missbräuchlicher Zugriff auf die in Fachdiensten der TI gespeicherten personenbezogenen medizinischen Daten erfolgen, sofern der Fachdienst nicht weitere eigene Sicherheitsmaßnahmen einsetzt.  Es sind daher durch den IDP geeignete Maßnahmen umzusetzen, die das Risiko eines solchen Missbrauchs verhindern.

Hinweis: für die Qualität der Transportverschlüsselung gelten die Anforderungen aus [gemSpec_Krypt].

Für die durch den IDP genutzten kryptographische Verfahren, sind die Anforderungen aus [gemSpec_Krypt] einzuhalten.

5.4 Grenzen der Sicherheitsleistung der Fachanwendung E-Rezept

Nicht alle Sicherheitsleistungen, die von der Fachanwendung E-Rezept benötigt werden, werden von Produkttypen der Fachanwendung umgesetzt. Zum Teil werden solche Leistungen von der TI-Plattform bereitgestellt, zum Teil müssen Systeme außerhalb der TI diese Leistungen übernehmen.

Leistungen, die durch die TI-Plattform erbracht werden:

• die Identifikation von TI-Teilnehmern,
• das Erstellen einer fortgeschrittenen und einer qualifizierten elektronischen Signatur und die Prüfung einer qualifizierten elektronischen Signatur.

Leistungen, die nicht durch die TI erbracht werden:

• E-Rezept-Token, die außerhalb der TI transportiert werden, können durch die TI nicht geschützt werden. Der Schutz dieser E-Rezept-Token liegt in der Verantwortung derjenigen, die diese Übermittlungsverfahren anwenden.
• Die Verhinderung von Mehrfachabrechnungen eines E-Rezepts muss durch die Prozesse und Systeme bei den abgebenden Leistungserbringern und Kostenträgern erfolgen. Nur für E-Rezepte, die über den E-Rezept-Fachdienst transportiert werden, stellt der E-Rezept-Fachdienst eine Quittung aus. Sollten E-Rezept-Dateien über andere Wege, als die TI transportiert werden, so kann die TI eine Mehrfacheinlösung nicht verhindern, sondern die Prozesse und Systeme bei den abgebenden Leistungserbringern und Kostenträgern müssen auf eine korrekte Quittung achten.
• Die TI kann eine missbräuchlichen Ausstellung von E-Rezepten in der Umgebung des verordnenden Leistungserbringers durch eine Übernahme der Kontrolle über alle dafür notwendigen Komponenten (inkl. ausgespähter PIN für eine QES-Erstellung mittels entwendeten HBAs) nicht verhindern.

6 Informationsmodell

6.1 Technisches Informationsmodell

Der E-Rezept-Fachdienst erzeugt eine eindeutige Rezept-ID, welche das E-Rezept, den zugehörige Dispensierdatensatz und die Quittung identifiziert, sowie einen AccessCode.

Das E-Rezept wird durch den verordnenden Leistungserbringer auf den E-Rezept-Fachdienst hochgeladen. Zusammen mit dem E-Rezept werden folgende Metadaten im E-Rezept-Fachdienst im E-Rezept-Datensatz verwaltet:

• Versicherten-ID des Versicherten, dem das E-Rezept verordnet wurde,
• der Status des E-Rezepts,
• das Datum der letzten Statusänderung,
• AccessCode,
• der Leistungserbringer-Typ, welcher zur Abgabe berechtigt ist,
• gültig bis (einlösbar),
• das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" für die Prüfung von Statusübergängen und
• Quittung.

Der E-Rezept-Token beinhaltet die Task-ID als Referenz für den zum E-Rezept zugehörigen Task im E-Rezept-Fachdienst und den AccessCode.

Der E-Rezept-Token besitzt für die optische Übermittlung eine Darstellung als 2D-Code und für die elektronische Übermittlung und Verarbeitung eine textuelle Codierung. Auf dem Ausdruck eines E-Rezept-Tokens wird der 2D-Code sowie weitere Metadaten abgebildet.

Die beim Statuswechsel von "in Abgabe (gesperrt)" zu "quittiert" erstellte Quittung beinhaltet das Datum des Statuswechsels und die Rezept-ID. Mittels Rezept-ID kann eine Quittung dem E-Rezept im Abrechnungsprozess zugeordnet werden.

Die E-Rezept-Nachricht beinhaltet eine Text-Mitteilung und alternativ den E-Rezept-Token oder Informationen für eine Anfrage zur Belieferung der Verordnung durch eine Apotheke. 

Die folgende Abbildung ABB_SYSLERP_008 gibt einen informativen Überblick der relationalen Zusammenhänge der in der Fachananwendung verarbeiteten Informationsobjekte. 

Abbildung 8: ABB_SYSLERP_008 Informationsmodell E-Rezept 

6.2 Fachliches Informationsmodell

Die fachlichen Inhalte des Informationsmodells für die Fachanwendung E-Rezept, d.h. den Daten, die durch den Verordnenden bereitgestellt werden, werden durch die Bundesmantelvertragspartner im Benehmen mit dem Deutschen Apothekerverband (DAV) festgelegt.

Die fachlichen Inhalte des Informationsmodells zu den Dispensier- und Abrechnungsdaten werden über den Rahmenvertrag § 129 Abs. 2 SGB V sowie über die Vereinbarung nach § 300 Abs. 3 SGB V festgelegt.

Diese fachlichen Inhalte sind nicht Teil des Scopes dieses Konzeptes.

7 Anhang – Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

Allgemeine Begriffe finden sich in [gemGlossar].

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

7.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 Versionsnummer entnehmen Sie bitte der aktuellen, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

7.5.2 Weitere Dokumente