Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Systemspezifisches Konzept

E-Rezept

 

 

   

   

Version	1.01.0
Revision	548770
Stand	30.0612.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

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzung des Dokuments

1.5 Methodik

1.5.1 Anforderungen

1.5.2 Hinweis auf offene Punkte

2 Systemüberblick

2.1 Einführung

2.2 Übergeordnete Ziele

2.2.1 Sicherheit und Datenschutz

2.2.2 Datenhoheit und Flexibilität

2.2.3 Erweiterbarkeit

2.2.4 Betrieb

2.3 Akteure und Rollen

2.3.1 Fachliche Rollen

2.3.2 Technische Rollen

2.4 Funktionale Zerlegung

2.4.1 Konzept Identifikation und Zugang zum E-Rezept

2.4.2 Konzept Zugriffsberechtigung auf E-Rezepte

2.4.3 Konzept der E-Rezept-Ressourcenverwaltung

2.4.4 Konzept der Verschlüsselung des E-Rezepts

2.4.5 Konzept der Übermittlung eines E-Rezept-Tokens

2.4.6 Konzept Status E-Rezept

2.4.7 Unterstützung betrieblicher Prozesse

3 Anwendungsfälle

3.1 Übersicht der Anwendungsfälle

3.2 Übergreifende Vorbedingungen

3.3 Übergreifende Nachbedingungen

3.4 E-Rezept ausstellen

3.4.1 E-Rezepte durch Verordnenden erzeugen

3.4.2 E-Rezept einstellen

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

3.4.4 E-Rezept durch Verordnenden löschen

3.5 E-Rezept durch Versicherten verwalten

3.5.1 E-Rezepte durch Versicherten abrufen

3.5.2 E-Rezept durch Vertreter abrufen

3.5.3 E-Rezept durch Versicherten löschen

3.5.4 Nachricht durch Versicherten an Abgebenden oder einen Vertreter übermitteln

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

3.5.6 Nachrichten durch Versicherten empfangen

3.5.7 ProtokolldatenNachricht durch Versicherten einsehenlöschen

3.6 E-Rezept in Apotheke einlösen3.5.8 Protokolldaten durch Versicherten einsehen

3.6.1 Nachrichten durch Abgebenden empfangen3.6 E-Rezept in Apotheke einlösen

3.6.2 Nachricht durch Abgebenden an Versicherten übermitteln3.6.1 Nachrichten durch Abgebenden empfangen

3.6.3 E-Rezept durch Abgebenden abrufen3.6.2 Nachricht durch Abgebenden an Versicherten übermitteln

3.6.4 E-Rezept durch Abgebenden zurückgeben3.6.3 Nachricht durch Abgebenden löschen

3.6.5 E-Rezept durch Abgebenden löschen3.6.4 E-Rezept durch Abgebenden abrufen

3.6.6 Quittung abrufen3.6.5 E-Rezept durch Abgebenden zurückgeben

3.6.7 Quittung erneut abrufen3.6.6 E-Rezept durch Abgebenden löschen

3.6.8 Dispensierdatensatz durch Abgebenden signieren3.6.7 Quittung abrufen

3.7 Anfordern von Identitätsbestätigungen3.6.8 Quittung erneut abrufen

3.7.1 Identitätsbestätigung durch den Versicherten anfordern3.6.9 Dispensierdatensatz durch Abgebenden signieren

3.7.2 Identitätsbestätigung durch LEI anfordern3.7 Anfordern von Identitätsbestätigungen

4 Systemzerlegung (Deployment)3.7.1 Identitätsbestätigung durch den Versicherten anfordern

4.1 Produkttypen der Fachanwendung E-Rezept3.7.2 Identitätsbestätigung durch LEI anfordern

4.1.1 Produkttyp E-Rezept-Fachdienst4 Systemzerlegung (Deployment)

4.1.1.1 Vertrauenswürdige Ausführungsumgebung4.1 Produkttypen der Fachanwendung E-Rezept

4.1.1.2 Betriebliche Aspekte4.1.1 Produkttyp E-Rezept-Fachdienst

4.1.2 Produkttyp E-Rezept-Frontend des Versicherten4.1.1.1 Vertrauenswürdige Ausführungsumgebung

4.1.3 Primärsysteme4.1.1.2 Betriebliche Aspekte

4.1.3.1 Primärsystem verordnender Leistungserbringer4.1.2 Produkttyp E-Rezept-Frontend des Versicherten

4.1.3.2 Primärsystem abgebender Leistungserbringer4.1.3 Primärsysteme

4.2 Fachanwendungsübergreifende Produkttypen4.1.3.1 Primärsystem verordnender Leistungserbringer

4.2.1 Produkttyp Identity Provider4.1.3.2 Primärsystem abgebender Leistungserbringer

4.2.1.1 Funktionale Anforderungen4.2 Fachanwendungsübergreifende Produkttypen

4.2.1.2 Betriebliche Aspekte4.2.1 Produkttyp Identity Provider

4.2.2 Authentisierungsmodul4.2.1.1 Funktionale Anforderungen

4.2.3 Produkttyp Verzeichnisdienst der TI4.2.1.2 Betriebliche Aspekte

4.3 Schnittstelle der Fachanwendung E-Rezept4.2.2 Authentisierungsmodul

4.3.1 Schnittstelle für die Ressource E-Rezept4.2.3 Produkttyp Verzeichnisdienst der TI

4.3.2 Schnittstelle für die Ressource E-Rezept-Nachricht4.3 Schnittstelle der Fachanwendung E-Rezept

4.3.3 Schnittstelle für die Ressource Zugriffsprotokolleintrag4.3.1 Schnittstelle für die Ressource E-Rezept

4.3.4 Schnittstelle für die Ressource signierte Challenge4.3.2 Schnittstelle für die Ressource E-Rezept-Nachricht

4.3.5 Schnittstelle für die Ressource Einwilligung4.3.3 Schnittstelle für die Ressource Zugriffsprotokolleintrag

5 Datenschutz- und Sicherheitsaspekte4.3.4 Schnittstelle für die Ressource signierte Challenge

5.1 Anforderungen an den E-Rezept-Fachdienst4.3.5 Schnittstelle für die Ressource Einwilligung

5.1.1 Anforderungen an die Vertrauenswürdige Ausführungsumgebung5 Datenschutz- und Sicherheitsaspekte

5.1.2 Verarbeitungskontext5.1 Anforderungen an den E-Rezept-Fachdienst

5.1.3 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld5.1.1 Anforderungen an die Vertrauenswürdige Ausführungsumgebung

5.1.4 Trennung von Session- und Request-Kontexten5.1.2 Verarbeitungskontext

5.2 Anforderungen an das E-Rezept-Frontend des Versicherten5.1.3 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld

5.3 Anforderungen an den Identity Provider5.1.4 Trennung von Session- und Request-Kontexten

5.4 Grenzen der Sicherheitsleistung der Fachanwendung E-Rezept5.2 Anforderungen an das E-Rezept-Frontend des Versicherten

6 Informationsmodell5.3 Anforderungen an den Identity Provider

6.1 Technisches Informationsmodell5.4 Grenzen der Sicherheitsleistung der Fachanwendung E-Rezept

6.2 Fachliches Informationsmodell6 Informationsmodell

7 Anhang – Verzeichnisse6.1 Technisches Informationsmodell

7.1 Abkürzungen6.2 Fachliches Informationsmodell

7.2 Glossar7 Anhang – Verzeichnisse

7.3 Abbildungsverzeichnis7.1 Abkürzungen

7.4 Tabellenverzeichnis7.2 Glossar

7.5 Referenzierte Dokumente7.3 Abbildungsverzeichnis

7.5.1 Dokumente der gematik7.4 Tabellenverzeichnis

7.5.2 Weitere Dokumente7.5 Referenzierte Dokumente

7.5.1 Dokumente der gematik

7.5.2 Weitere Dokumente

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 ApothekenApotheke 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 Leistungserbringer undLeistungserbringerinstitutionen, 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 (IdPIDP) 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 (IdPIDP) 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 IdPIDP 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 IdPIDP 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 (IdPIDP) 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 IdPIDP unter Nutzung festgelegter bzw. durch den IdPIDP 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 VetreterVertreter 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

A_18966 - Überwachung von Verfügbarkeit und Zuverlässigkeit der Fachanwendung

Die an der Fachanwendung E-Rezept beteiligten Produkttypen E-Rezept-Fachdienst und Identity Provider (IdP) MÜSSEN sämtliche technischen, funktionalen, interoperablen und organisatorischen Voraussetzungen zur Überwachung von Verfügbarkeit und Zuverlässigkeit des jeweiligen Produkttyps umsetzen und auf Schnittstellen-Aufrufe durch Probes des TI-Service Monitorings innerhalb der TI mit aussagekräftigen Meldungen antworten. [<=]

A_18967 - Erhebung und Speicherung von Performance-Messdaten

Die an der Fachanwendung E-Rezept beteiligten Produkttypen E-Rezept-Fachdienst und Identity Provider (IdP) MÜSSEN fortlaufend Last- und Performance-Messdaten erheben, sammeln, ggfs. zusammenführen sowie speichern, und diese - zur eindeutigen Lokalisierung der betroffenen technischen Produktinstanz und/oder Komponente - mit Metadaten anreichern (z.B. Produktversion), um sie einer weiterführenden betrieblichen Analyse und Auswertung durch die gematik zuführen zu können. Dies gilt auch für zusammengehörig definierte Operationen (im Sinne eines Bearbeitungsprozesses oder des Ablaufs eines Anwendungsfalls), sofern eine entsprechende Relevanz im Rahmen der Überwachung von Verfügbarkeit und Performance durch die gematik festgestellt wird. [<=]

A_18992 - Lieferung von Performance-Messdaten

Die Anbieter der Produkttypen E-Rezept-Fachdienst und Identity Provider (IdP) MÜSSEN Performance-Messdaten an die vom Gesamtverantwortlichen TI definierte Schnittstelle liefern. [<=]

A_18991 - E-Rezept-Fachdienst - Erhebung von Performance-Messdaten

Der E-Rezept-Fachdienst MUSS mindestens für die Operationen "E-Rezept-ID abrufen", "E-Rezept einstellen", "E-Rezept durch Abgebenden abrufen", "Quittung abrufen", "E-Rezept-Nachricht einstellen" und "E-Rezept-Nachricht abrufen" Performance-Messdaten erheben. [<=]

A_18993 - Identity Provider - Erhebung von Performance-Messdaten

Der Produkttyp Identity Provider MUSS mindestens für die Operation(en) zur Anforderung bis zur Übergabe von Identitätsbestätigungen (AuthN-Token) Performance-Messdaten erheben, inkl. der Durchführung des Challenge-Response-Verfahrens. Beim Challenge-Response-Verfahren ist dabei auch die Dauer der Antwortzeit des Authentisierungsmoduls (Einwilligung in die Nutzung von Identitätsattributen) zu messen und separat auszuweisen. Die Ausstellung von Versicherten-Identitätsbestätigungen bzw. die über die Internet-Schnittstelle angeforderten und übergebenden Identitätsbestätigungen sind separat auszuweisen. [<=]

A_18969 - Unterstützung des TI-ITSM-Anbieter- und des Endanwender-Supports durch aussagekräftige Fehlermeldungen

Die an den Anwendungsfällen der Fachanwendung E-Rezept beteiligten Produkttypen E-Rezept-Fachdienst, Identity Provider und deren Komponenten sowie die jeweiligen Frontend-Komponenten der Nutzer MÜSSEN zur Unterstützung des Endanwender-Supports bei einer entstehenden Störung oder einem Abbruch, gleich aus welchem Grunde, eine eindeutige, aussagekräftige und interoperable Fehlermeldung bereitstellen, die es den Supporteinheiten ermöglichen, die Störungsursache und den oder die Lösungsverantwortlichen der Störung zu identifizieren und mögliche eigene Gegenmaßnahmen zu ergreifen. [<=]

A_18999 - Anzeige des E-Rezept-Betriebszustandes

Das TI-Service Monitoring MUSS den Anbietern der Produkttypen E-Rezept-Fachdienst, Identity Provider, Verzeichnisdienst, VPN-Zugangsdienst und dem Anbieter des E-Rezept-Frontends des Versicherten den E-Rezept-Betriebszustand anzeigen. Störungen oder Service-Einschränkungen der Fachanwendung E-Rezept werden allen vorgenannten Anbietern gemeldet. Die Anzeige und die Meldungen enthalten Angaben zum verursachenden Dienst und unabhängig davon, durch welchen Produkttyp oder durch welchen Anbieter die Störung verursacht wird. [<=]

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

A_18997 - Anbieter E-Rezept-Fachdienst - Supportverantwortung im TI-ITSM-Teilnehmersupport

Der Anbieter des E-Rezept-Fachdienstes MUSS zur Unterstützung der Hochverfügbarkeit der Fachanwendung E-Rezept für die im TI-ITSM-Teilnehmersupport gemeldeten Störungen mit E-Rezept-Kontext die Supportverantwortung übernehmen und diese koordinieren.  [<=]

A_18998 - Anbieter E-Rezept-Fachdienst - 24/7 TI-ITSM-Teilnehmersupport

Der Anbieter E-Rezept-Fachdienst MUSS seinen TI-ITSM-Teilnehmersupport 24/7 anbieten. [<=]

A_18970 - Versichertensupport durch Anbieter Frontend des Versicherten

Anbieter operativer Betriebsleistungen des E-Rezept-Frontend des Versicherten MÜSSEN einen Versichertensupport anbieten. [<=]

A_18996 - TI-ITSM-Teilnahme von Anbietern Frontend des Versicherten

Anbieter operativer Betriebsleistungen des E-Rezept-Frontend des Versicherten KÖNNEN am TI-ITSM teilnehmen. [<=]

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.

A_18496 - Übergreifende Vorbedingung: Aufrufparameter gültig

Die Produkttypen der Fachanwendung E-Rezept MÜSSEN bei allen Operationen mit einer qualifizierten Fehlermeldung abbrechen, wenn notwendige Aufrufparameter unvollständig, ungültig oder inkonsistent sind. [<=]

A_18839 - Übergreifende Vorbedingung: Validierung von AuthN-Token

Jeder Produkttyp, der AuthN-Token als Aufrufparameter bei Operationen entgegennimmt und verarbeitet, MUSS den AuthN-Token (ID Token) gemäß [OIDC] validieren. Er MUSS die Operation mit einer qualifizierten Fehlermeldung abbrechen, falls die Validierung fehlschlägt. [<=]

3.3 Übergreifende Nachbedingungen

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

A_18497 - Protokollierung der Zugriffe auf medizinische Daten

Die Fachanwendung E-Rezept MUSS für jeden Aufruf einer Operation zum Einstellen, zur Statusänderung, zum Lesen oder Löschen eines E-Rezepts einen Protokolleintrag für den Versicherten erstellen. Der Eintrag MUSS dabei das aktuelle Datum, die aktuelle Uhrzeit und die Art des Zugriffs, einen lesbaren Namen des Zugreifenden, einen Identifier des Zugreifenden sowie einen Bezeichner des zugegriffenen Datenobjekts enthalten. [<=]

A_18498 - Für Nutzer verständliche Fehlermeldungen

Alle an den Anwendungsfällen der Fachanwendung E-Rezept beteiligten Produkttypen und Komponenten MÜSSEN interoperable Fehlermeldungen bereitstellen, die es den Versicherten bzw. den Mitarbeitern der Leistungserbringerinstitution ermöglichen, die Ursache des Fehlers über ihr jeweiliges Frontend zu identifizieren und mögliche Gegenmaßnahmen zu ergreifen. [<=]

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 

 

[<=]

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 

 

[<=]

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

 

[<=]

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 oder einen E-Rezept-Token zu erstellen. Die E-Rezepte werden ohne QES des verordnenden LE bereitgestellt, dafür erhält der dem Versicherten bereitestelltebereitgestellte 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

 

[<=]

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

 

[<=]

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 

 

[<=]

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 Verfügbarkeitsanfrage zu dem RezeptAnfrage 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 

 

[<=]

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

[<=]

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

 [<=]

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 1213: TAB_SYSLERP_013 Anwendungsfall Protokolldaten abrufen 

 

[<=]

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 1314: TAB_SYSLERP_036 Anwendungsfall Nachrichten durch Abgebenden empfangen

[<=]

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 1415: TAB_SYSLERP_055 Anwendungsfall Nachricht durch Abgebenden übermitteln

[<=]

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

 [<=]

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 1517: TAB_SYSLERP_014 Anwendungsfall E-Rezept durch Abgebenden abrufen

 

[<=]

3.6.45 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 1618: TAB_SYSLERP_015 Anwendungsfall E-Rezept durch Abgebenden zurückgeben

 

[<=]

3.6.56 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 1719: TAB_SYSLERP_016 Anwendungsfall E-Rezept durch Abgebenden löschen

 

[<=]

3.6.67 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 1820: TAB_SYSLERP_017 Anwendungsfall Quittung abrufen

 

[<=]

3.6.78 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 1921: TAB_SYSLERP_057 Anwendungsfall Quittung erneut abrufen

 

[<=]

3.6.89 Dispensierdatensatz durch Abgebenden signieren

Mit diesem Anwendungsfall kann ein Mitarbeiter einer abgebenden Leistungserbringerinstitution einen Dispensierdatensatz signieren. Erfolgt bei der Belieferung des E-Rezepts eine Änderung der Verschreibung nach § 17 (5) ApoBetrO, dann wird ein QES aufgebracht, anderenfalls wird fortgeschritten signiert.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 2022: TAB_SYSLERP_018 Anwendungsfall Dispensierdatensatz durch Abgebenden signieren

 

[<=]

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 IdPIDP) 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 2123: TAB_SYSLERP_045 AuthN-Token durch Versicherten anfordern

 

[<=]

In Ausbaustufend es IdPAusbaustufen des IDP bzw. mit der Förderierung der IdPsIDPs zu einem umfassenden IdentityManagementIdentity 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 IdPIDP) 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 2224 TAB_SYSLERP_046 AuthN-Token durch LEI anfordern 

 

[<=]

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.

A_18516 - E-Rezept-Token als DataMatrix-Code unterstützen

Das Primärsystem und das E-Rezept-Frontend des Versicherten MÜSSEN den E-Rezept-Token in seiner Kodierung als DataMatrix-Code gemäß ISO/IEC 16022 unterstützen. [<=]

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.

A_18792 - Sicherung der TI

Die durch die Fachanwendung E-Rezept genutzten Dienste, welche ihren Dienst im Internet anbieten, MÜSSEN die TI gegenüber dem Internet absichern. [<=]

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

A_18793 - Authentifizierung mittels AuthN-Token

Die durch die Fachanwendung E-Rezept genutzten Dienste, außer dem Identity Provider, MÜSSEN Leistungserbringerinstitutionen und Versicherte über einen durch einen Identity Provider der TI erstellte Identitätsbestätigung (AuthN-Token) authentifizieren. [<=]

A_18794 - Zugang zu Diensten nur nach Authentifizierung

Die Dienste der Fachanwendung E-Rezept MÜSSEN sicherstellen, dass nur nach erfolgreicher Authentifizierung der Zugang zum Dienst gewährt wird. [<=]

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.

A_18517 - E-Rezept-Fachdienst – Ressource E-Rezept

Der E-Rezept-Fachdienst MUSS die Ressourcen E-Rezept und Zugriffsprotokolleintrag verwalten und für die Ressourcen die Operationen gemäß TAB_SYSLERP_019 anbieten. 

Tabelle 2325: TAB_SYSLERP_019 Schnittstellen E-Rezept-Fachdienst

[<=]

A_18519 - E-Rezept-Fachdienst – Rezept-ID erzeugen

Der E-Rezept-Fachdienst MUSS Rezept-IDs erzeugen, welche mindestens über einen Zeitraum von 1011 Jahren eindeutig sind. [<=]

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.

A_18764 - E-Rezept-Fachdienst – Rezept-ID als Ressourcen-Identifier

Der E-Rezept-Fachdienst MUSS die Rezept-ID als Ressourcen-Identifier für die Ressource E-Rezept verwenden. [<=]

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

A_18520 - E-Rezept-Fachdienst – Eineindeutiger AccessCode des E-Rezepts

Der E-Rezept-Fachdienst MUSS einen AccessCode mit ausreichend hoher Entropie erzeugen. Der E-Rezept-Fachdienst MUSS sicherstellen, dass jedes im E-Rezept-Fachdienst verwaltete E-Rezept einen eineindeutigen AccessCode besitzt. [<=]

A_18522 - E-Rezept-Fachdienst – E-Rezept-Statuswechsel

Der E-Rezept-Fachdienst MUSS sicherstellen, dass ein mit einer Operation verbundener Statuswechsel eines E-Rezepts zulässig ist und anderenfalls die Operation mit einem Fehler abbrechen. Die Fehlermeldung an das aufrufende System muss eine Information über den aktuellen Status des E-Rezepts beinhalten. [<=]

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

A_18523 - E-Rezept-Fachdienst – Quittung beim Statusübergang zu "quittiert"

Der E-Rezept-Fachdienst MUSS beim Übergang des Status eines E-Rezepts von "in Abgabe (gesperrt)" zu "quittiert" eine E-Rezept-spezifische Quittung erstellen, mit seiner PKI-Identität (ID.FD.SIG) signieren und dem abgebenden Leistungserbringer übergeben. Die Quittung muss die Rezept-ID und das Datum des Statuswechsels beinhalten. [<=]

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

A_18524 - E-Rezept-Fachdienst – Geheimnis zur Statusänderung "in Abgabe (gesperrt)"

Der E-Rezept-Fachdienst MUSS bei jedem Übergang des Status eines E-Rezepts von "offen" zu "in Abgabe (gesperrt)" ein E-Rezept-spezifisches und übergangsspezifisches Geheimnis mit ausreichend hoher Entropie erzeugen und dem abgebenden Leistungserbringer übermitteln, sowie dem E-Rezept zuordnen. [<=]

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

A_18820 - E-Rezept-Fachdienst – Inhalte löschen beim Statusübergang "gelöscht"

Der E-Rezept-Fachdienst MUSS bei jedem Übergang des Status eines E-Rezepts zu "gelöscht" alle personenbezogenen und medizinischen Inhalte aus dem E-Rezept-Datensatz löschen. [<=]

A_18952 - E-Rezept-Fachdienst – Abfrage E-Rezept mit Status "gelöscht"

Der E-Rezept-Fachdienst MUSS die Abfrage eines E-Rezepts, welches den Status "gelöscht" hat, mit einem Fehler abbrechen, welcher dem Client den Status anzeigt. Wenn ein Versicherter alle seine E-Rezepte abruft, dann werden Rezepte mit dem Status "gelöscht" nicht zurückgegeben. [<=]

A_20055 - E-Rezept-Fachdienst – Prüfung Leistungserbringer-Typ

Der E-Rezept-Fachdienst MUSS bei der Abfrage eines E-Rezepts durch eine abgebende LEI den Leistungserbringer-Typ prüfen, ob die LEI für die Abgabe des Rezept-Typen berechtigt ist. [<=]

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

A_18525 - E-Rezept-Fachdienst – E-Rezept-Datensatz löschen (Löschfristen)

Der E-Rezept-Fachdienst MUSS einen E-Rezept-Datensatz in Abhängigkeit von Gültigkeitszeitraum und Status löschen.

Tabelle 2426: TAB_SYSLERP_021 Bedingungen zum Löschen von E-Rezepten

[<=]

A_18788 - E-Rezept-Fachdienst – E-Rezept-Nachricht löschen (Löschfrist)

Der E-Rezept-Fachdienst MUSS eine E-Rezept-Nachricht 100 Tage nach dem Einstellen löschen.

[<=]

A_18526 - E-Rezept-Fachdienst – Einträge für Zugriffsprotokoll erstellen

Der E-Rezept-Fachdienst MUSS sämtliche Zugriffe auf sowie Statuswechsel und das Löschen von E-Rezepten für den Versicherten nachvollziehbar protokollieren. [<=]

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

A_18937 - E-Rezept-Fachdienst – Protokolleinträge für E-Rezept löschen (Löschfrist)

Der E-Rezept-Fachdienst MUSS sicherstellen, dass Protokolleinträge 3 Jahre nach ihrer Generierung gelöscht werden. [<=]

A_18889 - E-Rezept-Fachdienst - Authentifizierung auf Basis Identitätsbestätigung des IdPIDP

Der E-Rezept-Fachdienst MUSS den aufrufenden Nutzer anhand einer durch einen Identity Provider ausgestellten Identitätsbestätigung authentifizieren. [<=]

A_18739 - E-Rezept-Fachdienst - Zugangsberechtigungen

Der E-Rezept-Fachdienst MUSS Zugangsberechtigungen für die Operationen auf Basis der Identitätsattribute der Identitätsbestätigung des Nutzers gemäß TAB_SYSLERP_040 umsetzen.

Tabelle 2527: TAB_SYSLERP_040 Zugangsberechtigungen Operationen E-Rezept-Fachdienst

Die Ausführung von Operationen durch Unberechtigte sowie hier nicht genannte Operationen MUSS vom E-Rezept-Fachdienst unterbunden werden.  [<=]

A_18936 - E-Rezept-Fachdienst - Transaktionssicherheit

Der E-Rezept-Fachdienst MUSS alle Aktivitäten zu einem Aufruf durch einen Client transaktionssicher durchführen. [<=]

A_18795 - E-Rezept-Fachdienst - Erreichbarkeit im Internet

Der E-Rezept-Fachdienst MUSS im Internet erreichbar sein. Der E-Rezept-Fachdienst MUSS sicherstellen, dass ausschließlich Versicherte aus dem Internet zugreifen können. [<=]

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. 

A_20755 - E-Rezept-Fachdienst - Prüfkarte eGK in der Vertreterkommunikation

Der E-Rezept-Fachdienst MUSS eine Kommunikationen von Versicherten einer Krankenkasse zu Nutzern einer Prüfkarte eGK verhindern. Der umgekehrte Kommunikationsweg MUSS vom E-Rezept-Fachdienst ebenfalls verhindert werden. [<=]

A_20756 - E-Rezept-Fachdienst - Prüfkarte eGK im Vertreterzugriff auf E-Rezepte

Der E-Rezept-Fachdienst MUSS einen Zugriff auf E-Rezepte von Versicherten einer Krankenkasse durch Nutzer einer Prüfkarte eGK verhindern. Ebenso MUSS der E-Rezept-Fachdienst verhindern, dass Versicherte einer Krankenkasse auf E-Rezepte zugreifen können, die für Nutzer einer Prüfkarte eGK ausgestellt wurden. [<=]

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.

A_18823 - Umsetzung des E-Rezept-Fachdienstes in einer Vertrauenswürdigen Ausführungsumgebung (VAU)

Der E-Rezept-Fachdienst MUSS alle Komponenten, die an der Verarbeitung von E-Rezept-Daten im Klartext beteiligt sind, in einer Vertrauenswürdigen Ausführungsumgebung umsetzen. [<=]

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.

A_18824 - Automatische Wiederherstellung eines konsistenten Zustands der VAU nach Systemfehlern

Die Vertrauenswürdige Ausführungsumgebung des E-Rezept-Fachdienstes MUSS nach Fehlern in der Datenverarbeitung automatisch, d. h. ohne administrative Eingriffe, die Klartextdaten berühren könnten, in einen konsistenten Systemzustand zurückkehren. [<=]

A_18825 - Fehlererkennung für Anwender ermöglichen

Der E-Rezept-Fachdienst MUSS jeden Verarbeitungsvorgang eines Anwenders in solcher Weise durchführen, dass der Anwender erkennen kann, wenn der Abschluss seines Verarbeitungsvorgangs aufgrund von Systemfehlern gescheitert ist. [<=]

A_18826 - Vorgangswiederholung nach Fehler gewährleisten

Der E-Rezept-Fachdienst MUSS die Wiederholung von aufgrund von Systemfehlern gescheiterten Verarbeitungsvorgängen ermöglichen und dies so umsetzen, dass die Vorgangswiederholung durch die Client-Anwendung in Form eines einfachen „erneut versuchen“ umgesetzt werden kann. [<=]

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.

A_18741 - E-Rezept-Fachdienst - Anbieterausschlüsse

Der Anbieter E-Rezept-Fachdienst DARF NICHT Anbieter der folgenden Funktionen, Dienste oder Produkttypen gemäß [gemKPT_Arch_TIP] sein:

• Identity Provider

[<=]

A_18687 - E-Rezept-Fachdienst – Verfügbarkeit

Der Anbieter E-Rezept-Fachdienst MUSS die Hochverfügbarkeit des Dienstes sicherstellen. [<=]

A_18743 - E-Rezept-Fachdienst - Maximales Rezeptaufkommen

Der E-Rezept-Fachdienst MUSS in der Lage sein, mindestens die in TAB_SYSLERP_002 und TAB_SYSLERP_003 genannten Maximalwerte der Rezeptaufkommen bewältigen zu können.

Tabelle 2628: TAB_SYSLERP_002 Maximales Aufkommen nach Rezeptzeilen (Muster 16) 2018 an ausgewählten Wochentagen

In 2018 war der 17.12. der Tag, an dem die meisten Rezepte ausgestellt wurden. Der Tag, an dem die meisten Rezepte in 2018 in einer Apotheke eingelöst wurden, war der 18.12.

Tabelle 2729: TAB_SYSLERP_003 Gesamtes Aufkommen nach Rezeptzeilen (Muster 16) 2018 kumuliert nach Wochentagen

[<=]

A_18745 - E-Rezept-Fachdienst - Antwortzeiten

Der E-Rezept-Fachdienst MUSS alle Aufrufe seiner Schnittstellen so beantworten, dass in Primärsystemen und den FdV keine Verzögerungen in den übergeordneten Abläufen entstehen. [<=]

A_19014 - Ende-zu-Ende-Verifikation bei Produkt-Changes

Der Anbieter E-Rezept-Fachdienst MUSS den Erfolg eines Produkt-Changes durch eine hinreichende Anzahl erfolgreich durchlaufener, dem Produkt-Change angemessener Anwendungsfälle oder Bearbeitungsvorgänge verifizieren. [<=]

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.

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

A_18689 - Frontend des Versicherten – Zusätzliche Funktionalitäten

Das E-Rezept-Frontend des Versicherten KANN zusätzliche Funktionalität enthalten, sofern diese nicht den Schutz der personenbezogenen und medizinischen Daten des Versicherten in der Fachanwendung E-Rezept gefährdet. [<=]

Eine zusätzliche Funktionalität ist beispielsweise die Verfügbarkeitsabfrage der Verordnung in einer Apotheke,Anfrage zur Belieferung durch eine Apotheke oder Download digitaler Beipackzettel. 

A_20207 - Frontend des Versicherten - Makelverbot

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

A_18528 - Frontend des Versicherten – GUI

Das E-Rezept-Frontend des Versicherten MUSS eine grafische Oberfläche (GUI) zum Ausführen der E-Rezept-Anwendungsfälle anbieten. [<=]

A_18529 - Frontend des Versicherten – Barrierefreiheit

Das E-Rezept-Frontend des Versicherten SOLL Bedienungselemente der Barrierefreiheit umsetzen. [<=]

A_18533 - Frontend des Versicherten – Nutzung interoperabler Schnittstellen

Das E-Rezept-Frontend des Versicherten MUSS die interoperablen Schnittstellen gemäß TAB_SYSLERP_022 nutzen.

Tabelle 2830: TAB_SYSLERP_022 Nutzung Schnittstellen eRp-FdV

[<=]

A_18789 - Frontend des Versicherten – E-Rezept-Token erzeugen

Das E-Rezept-Frontend des Versicherten MUSS einen E-Rezept-Token mit den folgenden Inhalten auf Basis des E-Rezepts erzeugen:

1.                      Rezept-ID
2.                      AccessCode

[<=]

A_18534 - Frontend des Versicherten – E-Rezept-Token als DataMatrix-Code anzeigen

Das E-Rezept-Frontend des Versicherten MUSS einen E-Rezept-Token optisch als DataMatrix-Code gemäß ISO/IEC 16022 darstellen können. [<=]

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.

A_18535 - Frontend des Versicherten – E-Rezept-Token einscannen

Das E-Rezept-Frontend des Versicherten MUSS einen DataMatrix-Code gemäß ISO/IEC 16022 einscannen und den E-Rezept-Token dekodieren können. [<=]

A_18537 - Frontend des Versicherten – E-Rezept-Token importieren und exportieren

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

Der Export kann bspw. durch das Weiterleiten mittels eines Messenger-Dienstes oder E-Mail erfolgen. Beim Export sind datenschutzrechtliche Anforderungen zu beachten. Näheres hierzu regelt die Rechtsverordnung nach § 360 Abs. 5 PDSG.

A_18539 - Frontend des Versicherten – E-Rezept anzeigen

Das E-Rezept-Frontend des Versicherten MUSS die fachlichen Inhalte eines E-Rezepts anzeigen können. [<=]

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.

A_18540 - Frontend des Versicherten – Abgebende LEI im Verzeichnis suchen

Das E-Rezept-Frontend des Versicherten MUSS es dem Versicherten ermöglichen, eine abgebende LEI für den Versand des E-Rezept-Tokens aus dem Verzeichnisdienst der TI auszuwählen. [<=]

A_20225 - Frontend des Versicherten – Neutralität in der Verzeichnissuche

Das E-Rezept-Frontend des Versicherten MUSS Such- und Filterkriterien wettbewerbsneutral ausgestalten (z.B. Sortierung nach Alphabet, nächster Standort, etc.) und das Ergebnis einer Such- bzw. Filterabfrage im VZD vollständig anzeigen, sodass keine Hervorhebung oder andere Art der Bevorzugung von Apotheken bei der Darstellung erfolgt. [<=]

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.

A_18541 - Primärsystem - Signaturverfahren auswählen

Das Primärsystem MUSS es dem verordnenden und abgebenden Akteur ermöglichen, für Anwendungsfälle des E-Rezepts, welche das Signieren von Dokumenten beinhalten, zwischen Einzel-, Stapel- und Komfortsignatur auszuwählen. Eine Defaultauswahl soll konfigurierbar sein. [<=]

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

A_18747 - Primärsystem - Hinweis unzulässiger Statuswechsel

Das Primärsystem MUSS, wenn ein Statuswechsel als unzulässig abgelehnt wird, dem verordnenden oder abgebenden Akteur einen Hinweis mit dem aktuellen Status des E-Rezepts geben. [<=]

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.

A_18688 - Primärsystem - E-Rezept-Daten für medizinische Anwendungen nutzen

Das Primärsystem SOLL den verordnenden und abgebenden Akteur dabei unterstützen, die Daten des E-Rezepts für andere Anwendungen der TI zu nutzen. [<=]

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

A_18542 - Primärsystem verordnende LEI – Nutzung interoperabler Schnittstellen

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS die interoperablen Schnittstellen gemäß TAB_SYSLERP_023 nutzen.

Tabelle 2931: TAB_SYSLERP_023 Nutzung Schnittstellen PS verordnende LEI

[<=]

A_18544 - Primärsystem verordnende LEI – E-Rezept um Rezept-ID ergänzen

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS ein E-Rezept gemäß den Vorgaben des fachlichen Informationsmodells mit einer vom E-Rezept-Fachdienst bereitgestellten Rezept-ID ergänzen. [<=]

A_18545 - Primärsystem verordnende LEI – Rezept-ID einmalig verwenden

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS eine vom E-Rezept-Fachdienst bereitgestellten Rezept-ID für genau ein E-Rezept verwenden. [<=]

A_18612 - Primärsystem verordnende LEI – Verordnungsdatensatz prüfen

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS beim Erstellen des E-Rezepts die Korrektheit und Vollständigkeit des Verordnungsdatensatzes entsprechend des fachlichen Informationsmodells prüfen. [<=]

A_18613 - Primärsystem verordnende LEI – Kein E-Rezept unsigniert einstellen

Das Primärsystem der verordnenden Leistungserbringerinstitution DARF ein E-Rezept NICHT in den E-Rezept-Fachdienst einstellen, wenn das Aufbringen der QES nicht erfolgreich durchgeführt wurde. [<=]

A_18614 - Primärsystem verordnende LEI – E-Rezept-Token erzeugen

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS einen E-Rezept-Token mit den folgenden Inhalten auf Basis eines E-Rezepts erzeugen:

• Rezept-ID
• AccessCode

[<=]

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

A_18543 - Primärsystem verordnende LEI – E-Rezept-Token ausdrucken

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS E-Rezept-Token als DataMatrix-Code gemäß ISO/IEC 16022 ausdrucken können. [<=]

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.

A_18616 - Primärsystem verordnende LEI – E-Rezept-Token speichern

Das Primärsystem der verordnenden Leistungserbringerinstitution MUSS einen E-Rezept-Token für den Zeitraum, in dem das E-Rezept einlösbar ist, vorhalten. [<=]

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

A_18547 - Primärsystem abgebende LEI – Nutzung interoperabler Schnittstellen

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS die interoperablen Schnittstellen gemäß TAB_SYSLERP_024 nutzen.

Tabelle 3032: TAB_SYSLERP_024 Nutzung Schnittstellen PS abgebende LEI

[<=]

A_18548 - Primärsystem abgebende LEI – DataMatrix-Code einscannen

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS E-Rezept-Token als DataMatrix-Code gemäß ISO/IEC 16022 einscannen können. [<=]

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

A_18758 - Primärsystem abgebende LEI – E-Rezept-Token empfangen

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS einen E-Rezept-Token mittels des E-Rezept-Fachdienstes empfangen können. [<=]

A_18549 - Primärsystem abgebende LEI – E-Rezept-Token importieren

Das Primärsystem der abgebenden Leistungserbringerinstitution KANN Funktionalitäten anbieten, E-Rezept-Token aus Drittanwendungen zu importieren. [<=]

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

A_18551 - Primärsystem abgebende LEI – Signatur des E-Rezepts prüfen

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS die Signatur des E-Rezepts prüfen und eine Warnung anzeigen, falls die Prüfung nicht erfolgreich oder technisch nicht möglich war. [<=]

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

A_18552 - Primärsystem abgebende LEI – E-Rezept anzeigen

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS ein E-Rezept anzeigen können. [<=]

A_18791 - Primärsystem abgebende LEI – AccessCode speichern

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS den im E-Rezept-Token für ein E-Rezept übermittelten AccessCode speichern, um ihn beim Aufruf einer Operation an den E-Rezept-Fachdienst übermitteln zu können.  [<=]

A_18553 - Primärsystem abgebende LEI – Geheimnis zur Statusänderung "in Abgabe (gesperrt)" speichern

Das Primärsystem der abgebenden Leistungserbringerinstitution MUSS das beim Abruf des E-Rezepts übermittelte Geheimnis zur Statusänderung "in Abgabe (gesperrt)" speichern und beim Aufruf der Operation zum Zurückgeben oder Löschen des E-Rezepts bzw. zum Abruf der Quittung zurück übermitteln.  [<=]

4.2 Fachanwendungsübergreifende Produkttypen

4.2.1 Produkttyp Identity Provider

Der Identity Provider (IdPIDP) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen bereitstellt. Die Bereitstellung von Authentifizierungsbestätigungen und Identitätsmerkmalen erfolgt in Form von Bearer Token (AuthN-Token). Der IdPIDP 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 IdPIDP die Identitäten einer Gruppe von TI-Teilnehmern abdeckt.

Für die Fachanwendung E-Rezept werden IdPsIDPs 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

A_18797 - IdPIDP - Umsetzung des IdPIDP gemäß OpenID Connect

Der IdPIDP MUSS als OpenID Provider gemäß OpenID Connect 1.0, Protocol Suite "Complete", umgesetzt werden, siehe [OIDC]. Darin referenzierte Standards, wie z.B. OAuth 2.0 [OAUTH2], MÜSSEN beachtet werden. [<=]

A_18803 - IdPIDP - Zulässige Client-Profile

Der IdPIDP MUSS die Authentifizierung von Nutzern gemäß demjenigen Client Profil durchführen, welches zum Frontend bzw. Primärsystem passt (siehe [OAUTH2], Section 2.1. "Client Types"):

• Frontend des Versicherten bzw. Primärsystem als native Applikation (allgemein: Ausführung der Fachlogik auf dem Gerät des Nutzers):
  Client Profil  "Native Application"
• Primärsystem als Web Applikation (Ausführung der Fachlogik serverseitig, in sicherer Umgebung):
  Client Profil "Web Application"

Es sind keine weiteren Client-Profile zulässig. [<=]

A_18815 - IdPIDP - Zulässiger Protokollablauf bei der Bereitstellung von Token

Der IdPIDP MUSS entsprechend  mit dem Authentisierungsmodul und dem Client (Relying Party) gemäß Grant Type "Authorization Code" interagieren. [<=]

A_18805 - IdPIDP - Zulässige Clients

Der IdPIDP MUSS seine Dienste ausschließlich den Anwendungen und Diensten der TI sowie weiteren Anwendungen gemäß [gemRL_NvTIwA] zur Verfügung stellen. [<=]

A_18811 - IdPIDP - Nur registrierte Clients

Der IdPIDP MUSS Requests einer unregistrierten Relying Party (Client) mit einem Fehler abweisen. [<=]

A_18812 - IdPIDP - Client-Authentisierung

Der IdPIDP MUSS eine Relying Party (Client) anhand der bei der Registrierung festgelegten Identifikationsmerkmale authentifizieren. [<=]

A_18838 - IdPIDP - Ablehnung nicht erfolgreich authentifizierter Clients

Der IdPIDP MUSS einen Client erfolgreich authentifizieren, bevor er dessen Request bearbeitet. Der IdPIDP MUSS mit einem Fehler reagieren, falls er den Client nicht erfolgreich authentifizieren kann. [<=]

A_18799 - IdPIDP - Authentisierung mittels Smart Cards der TI

Ein IdPIDP MUSS für die von ihm verwalteten TI-Teilnehmer die Authentisierung mittels Smart Card ermöglichen, sofern dieser über eine Smart Card der TI verfügt. Die Authentifizierung erfolgt auf Basis des Nutzerzertifikats (AUT-Identität) im Challenge-Response-Verfahren. Der IdPIDP MUSS dazu dem Authentisierungsmodul eine Challenge übergeben. [<=]

A_18914 - IdPIDP - Schnittstelle für die Ressource signierte Challenge

Ein IdPIDP MUSS für die Authentisierung mittels Smart Card dem Authentisierungsmodul eine Schnittstelle mit der logischen Operation "signierte Challenge übergeben" bereitstellen. [<=]

A_18865 - IdPIDP - Einwilligung in die Nutzung von Identitätsattributen

Ein IdPIDP MUSS für die von ihm verwalteten TI-Teilnehmer eine Einwilligung in die Nutzung von Identitätsattributen einholen, bevor diese erstmalig in einem AuthN-Token dem Client bereitgestellt werden. Der IdPIDP MUSS dazu dem Authentisierungsmodul die angefragten Identitätsattribute bereitstellen. [<=]

A_18915 - IdPIDP - Schnittstelle für die Ressource Einwilligung

Ein IdPIDP MUSS für die Einwilligung in die Nutzung von Identitätsattributen dem Authentisierungsmodul eine Schnittstelle mit der logischen Operation "Einwilligung erteilen" bereitstellen. [<=]

A_19011 - IdPIDP - Schnittstelle für die Anforderung des AuthN-Token

Ein IdPIDP MUSS eine Schnittstelle I_Authenticate (AuthN-Token anfordern) bereitstellen, über die die Relying Party für einen übergebenen AuthN-Code einen AuthN-Token anfordern kann. Diese Schnittstelle entspricht dem Token Endpoint gemäß OAuth 2.0 [OAUTH2]. [<=]

A_18819 - IdPIDP - Nutzung der PKI durch den IdPIDP

Der IdPIDP MUSS, wenn für einen TI-Teilnehmer Identitäten über die PKI der TI bereitgestellt werden, vorhandene Dienste der PKI verwenden, insbesondere bei der TSL- oder OCSP-Abfrage für die Zertifikatsprüfung. [<=]

A_18808 - IdPIDP - Abdeckung der fachlichen Identitätsattribute PKI-basierter Identitäten

Der IdPIDP MUSS, wenn für einen TI-Teilnehmer Identitäten sowohl AuthN-Token vom IdPIDP als auch Zertifikate durch die PKI bereitgestellt werden, mindestens die fachlichen Identitätsattribute unterstützen, die in den Zertifikaten enthalten sind. [<=]

A_18809 - IdPIDP -Minimierung der Authentisierungsanfragen, komfortabler Single Sign-On

Der IdPIDP MUSS Authentisierungsanfragen an bereits authentifizierte Nutzer auf solche Fälle beschränken, in denen eine erneute Authentisierung durch den Nutzer aus Gründen der Sicherheit erforderlich ist oder von der Anwendung explizit angefordert wird. [<=]

4.2.1.2 Betriebliche Aspekte

A_18904 - IdPIDP – Verfügbarkeit

Der Anbieter des IdPIDP MUSS die Hochverfügbarkeit des Dienstes sicherstellen. [<=]

Der Anbieter des IdPIDP 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.

A_18903 - IdPIDP - Anbieterausschlüsse

Der Anbieter des IdPIDP DARF NICHT Anbieter der folgenden Funktionen, Dienste oder Produkttypen gemäß [gemKPT_Arch_TIP] sein:

• E-Rezept-Fachdienst

[<=]

A_18810 - IdPIDP - Registrierung von Clients

Der Anbieter des IdPIDP MUSS ein Verfahren bzw. eine Schnittstelle bereitstellen, über welche sich Dienste der TI als Relying Party (Clients) für die Nutzung des IdPIDP registrieren können. [<=]

A_18801 - IdPIDP - Widerspruchsfreiheit von IdPIDP und PKI

Der Anbieter des IdPIDP MUSS, wenn für einen TI-Teilnehmer Identitäten sowohl über die PKI als auch den IdPIDP bereitgestellt werden, sicherstellen, dass sich die beiden Identitäten bezüglich der aktuellen Gültigkeit und der inhaltlichen Aussagen nicht widersprechen. [<=]

A_18802 - IdPIDP - Widerspruchsfreiheit von IdPIDP und Verzeichnisdienst

Der Anbieter des IdPIDP MUSS, wenn für einen Teilnehmer Identitätsattribute sowohl über den Verzeichnisdienst als auch den IdPIDP bereitgestellt werden, sicherstellen, dass sich die beiden Identitätsattribute bezüglich der aktuellen Gültigkeit und der inhaltlichen Aussagen nicht widersprechen. [<=]

A_18939 - IdPIDP - Bereitstellung Authentisierungsmodul

Der Anbieter des IdPIDP SOLL ein Authentisierungsmodul für die gängigen mobilen Betriebssysteme iOS und Android bereitstellen, das den Authentifizierungsvorgang des Nutzers über eine Schnittstelle zwischen IdPIDP und dem Authentisierungsmodul auf dem Gerät des Nutzers steuert. [<=]

A_19016 - Verifikation von Produkt-Changes

Der Anbieter des IdPIDP MUSS den Erfolg eines Produkt-Changes durch eine hinreichende Anzahl erfolgreich durchlaufener, dem Produkt-Change angemessener Anwendungsfälle oder Bearbeitungsvorgänge verifizieren. [<=]

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 IdPIDP, 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 IdPIDP stellt das Authentisierungsmodul die Einwilligung des Nutzers und die für die Authentifizierung des Nutzers erforderlichen Daten bereit. Das Authentisierungsmodul alleine speichert den IdPIDP-Sitzungsschlüssel (Subject Session ID) und ermöglicht einen Single Sign-On für alle den IdPIDP nutzenden Anwendungen auf dem Gerät des Nutzers.

A_18813 - Authentisierungsmodul - Umsetzung gemäß OpenID Connect

Das Authentisierungsmodul MUSS so umgesetzt werden, dass es dem User Agent gemäß OpenID Connect 1.0, Protocol Suite "Complete", entspricht, siehe [OIDC]. Darin referenzierte Standards, wie z.B. OAuth 2.0 [OAUTH2], MÜSSEN beachtet werden. [<=]

A_18814 - Authentisierungsmodul - Zulässiger Protokollablauf bei der Bereitstellung von Token

Das Authentisierungsmodul MUSS entsprechend  mit dem IdPIDP und der Anwendung (Client, Relying Party) gemäß Grant Type "Authorization Code" interagieren. [<=]

A_18816 - Authentisierungsmodul - Authentisierung mit Smart Cards der TI

Das Authentisierungsmodul MUSS eine Authentisierung des Nutzers per Smart Card ermöglichen. Falls der IdPIDP dazu eine Challenge an das Authentisierungsmodul übergibt, MUSS das Authentisierungsmodul das Zertifikat der AUT-Identität des Nutzers ermitteln, die Challenge mit dem zugehörigen Schlüssel signieren lassen und die signierte Challenge zusammen mit dem Zertifikat an den IdPIDP übergeben. [<=]

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

A_18917 - Authentisierungsmodul - Einwilligung in die Nutzung von Identitätsattributen

Das Authentisierungsmodul MUSS vom Nutzer eine Einwilligung in die Bereitstellung von Identitätsattributen durch den IdPIDP an die Anwendung einholen. Falls der IdPIDP dazu die angeforderten Identitätsattribute an das Authentisierungsmodul übergibt, MUSS das Authentisierungsmodul die Einwilligung des Nutzers einholen und an den IdPIDP übergeben (siehe ). [<=]

A_18817 - Authentisierungsmodul - Authentisierung mit SMC-B

Das Authentisierungsmodul MUSS für die Authentisierung von Leistungserbringerinstitutionen die Signaturfunktion I_Sign_Operations::external_Authenticate gemäß   und die Zertifikatsabfrage der SMC-B (AUT-Identität) über die Client-Schnittstelle des Konnektors nutzen. [<=]

A_18818 - Authentisierungsmodul - Authentisierung mit eGK

Das Authentisierungsmodul MUSS für die Authentisierung von Versicherten mittels eGK die Signaturfunktion und die Zertifikatsabfrage der eGK (AUT-Identität) über einen Kartenleser/die NFC-Schnittstelle des Geräts des Nutzers nutzen. [<=]

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

A_18940 - Authentisierungsmodul - Schnittstelle für Fachlogik-App

Das Authentisierungsmodul MUSS einen Systemdienst auf der Betriebssystemplattform des Gerät des Nutzers mit einer Schnittstelle (Authentisierung anfordern) anbieten, über die das E-Rezept-Modul Frontend des Versichertenein Clientsystem einen Authentifizierungsrequest an das Authentisierungsmodul zur Authentifizierung des Nutzers gegenüber dem IdPIDP weiterleiten kann. [<=]

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.

A_18867 - VZD - Authentifizierung auf Basis Identitätsbestätigung des IdPIDP

Der Verzeichnisdienst MUSS es ermöglichen, dass sich der aufrufende Nutzer mittels einer durch einen Identity Provider ausgestellten Identitätsbestätigung authentifiziert. [<=]

A_18837 - VZD - Erreichbarkeit im Internet

Der Verzeichnisdienst MUSS im Internet erreichbar sein. [<=]

A_18941 - VZD - Einschränkung abfragbarer Informationen für Versicherte

Der Verzeichnisdienst MUSS die für Versicherte bereitgestellte Schnittstelle so einschränken, dass ausschließlich die für die Suche und Adressierung von abgebenden LEI  notwendigen Informationen abgefragt werden können. [<=]

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.

A_18555 - Logische Operation "E-Rezept-ID abrufen"

Die Schnittstelle MUSS die logische Operation "E-Rezept-ID abrufen" implementieren.

Tabelle 3133: TAB_SYSLERP_025 Operation E-Rezept-ID abrufen

Mit dieser Operation kann ein Verordnender eine Rezept-ID abrufen. Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Als Aufruf-Parameter der FHIR-Operation $create der Ressource Task wird ein strukturierter Datensatz mit FHIR-Operationsparametern (Workflowidentifier) übergeben, da das entsprechende E-Rezept inkl. E-Rezept-ID im nächsten Schritt vom Konnektor signiert werden muss.   

Die Operation liefert die Rezept-ID ( PrescriptionId) als ID der angelegten Ressource Task und generiert den AccessCode ( AccessCode) als external Identifier in den Datensatz, welcher den Zugriff auf das E-Rezept erlaubt. Der Task erhält den Status "initialisiert" (" draft"). [<=]

A_18556 - Logische Operation "E-Rezept einstellen"

Die Schnittstelle MUSS die logische Operation "E-Rezept einstellen" implementieren.

Tabelle 3234: TAB_SYSLERP_026 Operation E-Rezept einstellen

Mit dieser Operation kann eine verordnende LEI ein E-Rezept im E-Rezept-Fachdienst um den qualifiziert signierten Anteil ergänzen. Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Der AccessCode muss dem beim Einstellen erzeugten Geheimnis entsprechen, mit dem der Versicherte den Zugriff auf das E-Rezept steuert. 

Die Operation muss vor dem Statuswechsel prüfen, ob das E-Rezept den Status "initialisiert" ("draft") hat. 

Die Operation prüft die Gültigkeit der QES (signature) und den Inhalt des im QES-Datensatz enthaltenen FHIR-Bundles und erzeugt bei Korrektheit aller Daten eine Signatur über das Bundle mit der Signaturidentität ID.FD.SIG, die als Kopie für den Versicherten mit Zugriff auf den Task zum Abruf durch den Versicherten abgelegt wird. Der Datensatz der QES wird als Binary-Objekt gespeichert. Sind alle Daten valide und die QES gültig erhält das E-Rezept (der Task) den Status "offen" ("ready"). [<=]

A_18557 - Logische Operation "E-Rezept durch Verordnenden löschen"

Die Schnittstelle MUSS die logische Operation "E-Rezept durch Verordnenden löschen" implementieren.

Tabelle 3335: TAB_SYSLERP_027 Operation E-Rezept durch Verordnenden löschen

Mit dieser Operation kann eine verordnende LEI den Status des E-Rezepts im E-Rezept-Fachdienst auf "gelöscht"  (Status des Task " cancelled") ändern. Die Operation löscht die personenbezogenen und medizinischen Daten aus dem E-Rezept-Datensatz. 

Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Der AccessCode muss dem beim Einstellen erzeugten AccessCode entsprechen, mit dem der Versicherte den Zugriff auf das E-Rezept steuert. 

Die Operation muss vor dem Statuswechsel prüfen, ob das E-Rezept den Status "offen" (" ready") hat. Die Operation liefert neben dem http-Status-Code über den Erfolg der Operation keine weiteren Daten zurück. [<=]

A_18559 - Logische Operation "E-Rezept durch Abgebenden abrufen"

Die Schnittstelle MUSS die logische Operation "E-Rezept durch Abgebenden abrufen" implementieren.

Tabelle 3436: TAB_SYSLERP_028 Operation E-Rezept durch Abgebenden abrufen

Mit dieser Operation kann eine abgebende LEI  ein E-Rezept vom E-Rezept-Fachdienst abrufen.
Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Der AccessCode muss dem beim Erstellen des Task erzeugten AccessCode entsprechen, mit dem der Versicherte den Zugriff auf das E-Rezept steuert.  Die Operation muss vor dem Statuswechsel zu "in Abgabe (gesperrt)" (" in-progress") prüfen, ob das E-Rezept den Status "offen" (" ready") hat.
Die Operation erzeugt ein Geheimnis zur Statusänderung ( Secret) im Task, mit der der abgebenden LEI nachfolgende Zugriffe auf die Ressource gewährt werden. In der Response wird der Task und der beim Einstellen des E-Rezepts hinterlegte QES-Datensatz in einem FHIR-Bundle zurückgegeben. [<=]

A_18560 - Logische Operation "E-Rezept durch Abgebenden löschen"

Die Schnittstelle MUSS die logische Operation "E-Rezept durch Abgebenden löschen" implementieren.

Tabelle 3537: TAB_SYSLERP_029 Operation E-Rezept durch Abgebenden löschen

Mit dieser Operation kann eine abgebende LEI den Status ( Task.status) des E-Rezepts im E-Rezept-Fachdienst auf "cancelled" ändern. Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Das  Secret muss dem beim Abruf des Rezepts erzeugten Geheimnis entsprechen und der Task den Status " in-progress" haben. Die Operation löscht die personenbezogenen und medizinischen Daten aus dem E-Rezept-Datensatz und ändert den Status des referenzierten Task auf "cancelled". [<=]

A_18561 - Logische Operation "E-Rezept durch Abgebenden zurückgeben"

Die Schnittstelle MUSS die logische Operation "E-Rezept durch Abgebenden zurückgeben" implementieren.

Tabelle 3638: TAB_SYSLERP_030 Operation E-Rezept durch Abgebenden zurückgeben

Mit dieser Operation kann eine  abgebende LEI den Zugriff auf das E-Rezept wieder freigeben (der Status des Task wird auf " ready" gesetzt).
Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen.  

Die Operation muss vor dem Statuswechsel prüfen, ob der Task den Status " in-progress" hat und ob das übermittelte Geheimnis ( Secret) dem beim Abrufen des E-Rezeptes im Task erzeugten Geheimnis entspricht. [<=]

A_18562 - Logische Operation "Quittung abrufen"

Die Schnittstelle MUSS die logische Operation "Quittung abrufen" implementieren.

Tabelle 3739: TAB_SYSLERP_031 Operation Quittung abrufen

 

Mit dieser Operation kann eine abgebende LEI den Status des E-Rezepts im E-Rezept-Fachdienst auf "quittiert"  ("completed") ändern. Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Mit der Aktualisierung der Task  in den Status "completed" gesetzt. Der E-Rezept-Fachdienst prüft die übergebene MedicationDispense strukturell und erzeugt eine Signatur mit der Signaturidentität ID.FD.SIG als FHIR-Bundle, die am Task als Workflow-Output zum Abruf gespeichert und an ebenso den Aufrufenden zurückgegeben wird. Die MedicationDispense wird für den Versicherten zum Abruf gespeichert.    

Die Operation muss vor dem Statuswechsel prüfen, ob der Task den Status " in-progress" hat und ob das übermittelte Geheimnis ( Secret) dem beim Abrufen des E-Rezeptes im Task erzeugten Geheimnis entspricht. 

Die Operation übermittelt im Response die signierte Quittung ( Receipt) als Provenance-Ressource. [<=]

A_19125 - Logische Operation "Quittung erneut abrufen"

Die Schnittstelle MUSS die logische Operation "Quittung erneut abrufen" implementieren.

Tabelle 3840: TAB_SYSLERP_031 Operation Quittung erneut abrufen

Mit dieser Operation kann eine abgebende LEI eine Quittung erneut abrufen. Dafür wird eine lesende Anfrage an den Task gestellt, zu dem die Apotheke das während der Belieferung erzeugte Geheimnis ( Secret) kennt. Der E-Rezept-Fachdienst prüft intern zusätzlich die Rolle des Aufrufenden im IdentityToken und ob das währen der Dispensierung erstellte Secret gleich dem übergebenen Parameter Secret entspricht. [<=]

A_18868 - Logische Operation "E-Rezepte durch Versicherten abrufen"

Die Schnittstelle MUSS die logische Operation "E-Rezepte durch Versicherten abrufen" implementieren.

Tabelle 3941: TAB_SYSLERP_043 Operation E-Rezepte durch Versicherten abrufen

Mit dieser Operation kann ein Versicherter alle für ihn im E-Rezept-Fachdienst abgelegten E-Rezepte abrufen. 

Die Operation muss auf Basis der KVNR in der Identitätsbestätigung ( IdentityToken) die E-Rezepte im E-Rezept-Fachdienst auswählen. 

Die Operation muss prüfen, ob die einzelnen E-Rezepte einen Status ungleich "initialisiert" ("draft") und "gelöscht" ("cancelled") haben. Die Ausgabe der Tasks erfolgt inkl. der serverseitig signierten FHIR-Bundles. [<=]

A_18564 - Logische Operation "E-Rezept durch Vertreter abrufen"

Die Schnittstelle MUSS die logische Operation "E-Rezept durch Vertreter abrufen" implementieren.

Tabelle 4042: TAB_SYSLERP_032 Operation E-Rezept durch Vertreter abrufen

Mit dieser Operation kann ein Versicherter oder Vertreter ein im E-Rezept-Fachdienst abgelegtes E-Rezept ( Task) inkl. serverseitiger Signatur ( Provenance) abrufen. Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Der AccessCode muss dem beim Einstellen erzeugten Geheimnis entsprechen, mit dem der Versicherte den Zugriff auf das E-Rezept steuert. Ruft der Versicherte selbst ein einzelnes E-Rezept über die ID ab, muss der AccessCode nicht übergeben werden.  

Die Operation muss prüfen, ob das E-Rezept einen Status ungleich "initialisiert" ("draft") und "gelöscht" ("cancelled") hat. Die Ausgabe des Tasks erfolgt inkl. des serverseitig-signierten FHIR-Bundles.  [<=]

A_18565 - Logische Operation "E-Rezept durch Versicherten löschen "

Die Schnittstelle MUSS die logische Operation "E-Rezept durch Versicherten löschen" implementieren.

Tabelle 4143: TAB_SYSLERP_033 Operation E-Rezept durch Versicherten löschen

Mit dieser Operation kann ein Versicherter ein für ihn abgelegtes E-Rezepts im E-Rezept-Fachdienst löschen ("cancelled"). Die Operation muss auf Basis der KVNR in der Identitätsbestätigung ( IdentityToken) prüfen, ob das E-Rezept für den Versicherten erstellt wurde und ob das E-Rezept einen Status ungleich "in Abgabe (gesperrt)" (" in-progress") hat. Der AccessCode muss dem beim Einstellen erzeugten AccessCode entsprechen, mit dem der Versicherte den Zugriff auf das E-Rezept steuert. Die Operation löscht die personenbezogenen und medizinischen Daten aus dem E-Rezept-Datensatz. [<=]

A_19140 - Logische Operation "Dispensierinformationen durch Versicherten abrufen"

Die Schnittstelle MUSS die logische Operation "Dispensierinformationen durch Versicherten abrufen" implementieren.

Tabelle 4244: TAB_SYSLERP_054 Operation Dispensierinformationen durch Versicherten abrufen

Mit dieser Operation kann ein Versicherter die Dispensierinformationen für seine E-Rezepte abrufen. Die Operation muss auf Basis der KVNR in der Identitätsbestätigung ( IdentityToken) filtern, sodass nur die Dispensierinformationen zurückgegeben werden, die für den Versicherten erstellt wurden.  [<=]

A_19141 - Logische Operation "Dispensierinformation für ein einzelnes E-Rezept abrufen"

Die Schnittstelle MUSS die logische Operation "Dispensierinformationen für ein einzelnes E-Rezept durch Versicherten abrufen" implementieren.

Tabelle 4345: TAB_SYSLERP_058 Operation Dispensierinformation für ein einzelnes E-Rezept durch Versicherten  oder Vertreter abrufen

Mit dieser Operation kann ein Versicherter die Dispensierinformationen für ein einzelnes E-Rezept abrufen. Die Operation muss zur Autorisierung des Aufrufenden ( IdentityToken) die Rolle prüfen. Der AccessCode muss dem beim Einstellen erzeugten AccessCode entsprechen, mit dem der Versicherte den Zugriff auf das E-Rezept steuert. Im Ergebnis wird das E-Rezept inklusive der Dispensierinformationen zurückgegeben. [<=]

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.

A_18869 - Logische Operation "E-Rezept-Nachricht einstellen"

Die Schnittstelle MUSS die logische Operation "E-Rezept-Nachricht einstellen" implementieren.

Tabelle 4446: TAB_SYSLERP_044 Operation E-Rezept-Nachricht einstellen

Mit dieser Operation kann der aufrufende Akteur eine E-Rezept-Nachricht einstellen. Die Nachricht als Communication-Objekt enthält den Identifikator des Empfängers als Communication.recipient (Telematik-ID oder Versicherten-ID) und die Operation übernimmt den Identifikator des Absenders aus dem IdentityToken (Versicherten-ID oder Telematik-ID als Communication.sender). Optional kann der Absender die verordnete Medication als Objekt in Communication.about oder eine Referenz auf den umzusetzenden Task in Communication.basedOn einfügen. [<=]

A_18870 - Logische Operation "E-Rezept-Nachrichten abrufen"

Die Schnittstelle MUSS die logische Operation "E-Rezept-Nachrichten abrufen" implementieren.

Tabelle 4547: TAB_SYSLERP_050 Operation E-Rezept-Nachrichten abrufen

Mit dieser Operation kann der aufrufende Akteur alle für ihn eingestellten E-Rezept-Nachrichten abrufen. 

Die Operation wählt die Nachrichten auf Basis der Telematik-ID für Leistungserbringerinstitutionen bzw. KVNR für Versicherte in der Identitätsbestätigung ( IdentityToken) aus (Telematik-ID bzw. Versicherten-ID muss gleich Communication.recipient sein). [<=]

A_20261 - Logische Operation "E-Rezept-Nachricht löschen"

Die Schnittstelle MUSS die logische Operation "E-Rezept-Nachricht löschen" implementieren.

Tabelle 48: TAB_SYSLERP_060 Operation E-Rezept-Nachricht löschen

Mit dieser Operation kann der aufrufende Akteur eine von ihm eingestellte E-Rezept-Nachricht über die beim Einstellen erzeugte Ressourcen-ID {ID} löschen.
Die Operation prüft auf Basis der Telematik-ID für Leistungserbringerinstitutionen bzw. KVNR für Versicherte in der Identitätsbestätigung (IdentityToken), ob der aufrufende Nutzer derjenige Absender der Nachricht ist, der in Communication.sender angegeben ist. Wurde die Nachricht vom Empfänger bereits abgerufen (Attribut Communication.received ungleich Null), meldet der E-Rezept-Fachdienst dies im http-Response-Header "Warning". [<=]

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. 

A_18871 - Logische Operation "Zugriffsprotokolleinträge durch Versicherten abrufen "

Die Schnittstelle MUSS die logische Operation "Zugriffsprotokolleinträge durch Versicherten abrufen" implementieren.

Tabelle 4649: TAB_SYSLERP_051 Operation Zugriffsprotokolleinträge durch Versicherten abrufen

Mit dieser Operation kann ein Versicherter alle im Zugriffsprotokoll abgelegten Einträge ( AuditEvents) abrufen. 

Die Operation wählt die Protokolleinträge auf Basis der KVNR in der Identitätsbestätigung ( IdentityToken) aus. Mittels URL-Parameter-Filter kann zusätzlich nach Ereignissen gefiltert werden (z.B. nicht älter als <date>). [<=]

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 IdPIDP benötigt. Dazu wird hier eine Ressource definiert.

A_18887 - Logische Operation "signierte Challenge übergeben"

Die Schnittstelle MUSS die logische Operation "signierte Challenge übergeben" implementieren. 

Mit dieser Operation kann das Authentisierungsmodul eine signierte Challenge, zusammen mit dem Zertifikat des Nutzers, an den IdPIDP übergeben (Signatur per AUT-Identität der Smart Card). Die Challenge erhält das Authentisierungsmodul zuvor vom IdPIDP. [<=]

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 IdPIDP benötigt. Dazu wird hier eine Ressource definiert.

A_18888 - Logische Operation "Einwilligung erteilen"

Die Schnittstelle MUSS die logische Operation "Einwilligung erteilen" implementieren. 

Mit dieser Operation kann das Authentisierungsmodul die Einwilligung des Nutzers für die Verwendung der Identitätsattribute (Consent) an den IdPIDP übergeben. Die angeforderten Identitätsattribute erhält das Authentisierungsmodul zuvor vom IdPIDP. [<=]

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 4750: TAB_SYSLERP_052 Schutzbedarf der maßgeblichen Informationsobjekte

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

Tabelle 4851: 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:

A_19010 - Vertrauenswürdigkeit des Anbieters

Der Anbieter des E-Rezept-Fachdienstes MUSS für den Betrieb des E-Rezept-Fachdienstes geeignet sein.
Das heißt insbesondere, dass das Vertrauen in ihn gesetzt werden kann, dass er organisatorische oder technische Schwachstellen im E-Rezept-Fachdienstes nicht für unberechtigte Zugriffe auf E-Rezepte ausnutzt. [<=]

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:

A_18566 - Schutz der Kommunikation

Der E-Rezept-Fachdienst MUSS sicherstellen, dass alle Komponenten des E-Rezept-Fachdienstes vertraulich miteinander kommunizieren. [<=]

A_18851 - Kommunikation nur zwischen Berechtigten

Der E-Rezept-Fachdienst MUSS sicherstellen, dass er nur berechtigte Kommunikationsbeziehungen zulässt. [<=]

A_18569 - Ablegen und Abrufen von E-Rezepten nur durch berechtigte Leistungserbringer

Der E-Rezept-Fachdienst MUSS sicherstellen, dass nur zum Einstellen berechtigte Leistungserbringer E-Rezepte einstellen und nur zur Abgabe berechtigte Leistungserbringer E-Rezepte abrufen können. [<=]

A_18570 - Verbot der Auswertung von Beziehungen zwischen LE, LEI und Versicherten

Der E-Rezept-Fachdienst MUSS verhindern, dass eine Auswertung von Beziehungen zwischen LE, LEI und Versicherten möglich ist. [<=]

A_18571 - Verbot der Profilbildung

Der E-Rezept-Fachdienst MUSS verhindern, dass eine Profilbildung durch den Anbieter des E-Rezept-Fachdienstes erfolgen kann. [<=]

A_18844 - Schutzmaßnahmen gegen die OWASP Top 10 Risiken

Der E-Rezept-Fachdienst MUSS Maßnahmen zum Schutz vor der aktuellen Version der OWASP-Top-10-Risiken umsetzen. [<=]

A_18845 - Schutz der E-Rezepte

Der E-Rezept-Fachdienst MUSS sicherstellen, dass E-Rezepte während der Verarbeitung vor dem Zugriff durch den Anbieter technisch geschützt sind.  [<=]

A_18846 - Speicherung von E-Rezepten nur verschlüsselt

Der E-Rezept-Fachdienst MUSS sicherstellen, dass E-Rezepte nur verschlüsselt  persistent im E-Rezept-Fachdienst gespeichert werden. [<=]

A_18847 - Speicherung von Nachrichten nur verschlüsselt

Der E-Rezept-Fachdienst MUSS sicherstellen, dass Nachrichten nur verschlüsselt persistent im E-Rezept-Fachdienst gespeichert werden. [<=]

A_18841 - Erkennung Anomalien auf Netzwerkebene

Der E-Rezept-Fachdienst MUSS Anomalien auf Netzwerkebene erkennen und darauf reagieren können. [<=]

A_18923 - Authentisierungsniveau für E-Rezept-Fachdienst mindestens "hoch"

Der E-Rezept-Fachdienst MUSS AuthN-Token des IdPIDP ablehnen, die nicht mittels eines geeigneten technischen Verfahrens, das zur Authentifizierung einen hohen Sicherheitsstandard gewährleistet erstellt wurden.  [<=]

A_20555 - Informationen zum Erstellen von E-Rezept-Token für E-Rezept-FdV

Der E-Rezept-Fachdienst MUSS sicherstellen, dass bei Clientsystemen des Versicherten nur das E-Rezept-FdV einen E-Rezept-Token erzeugen kann. [<=]

A_20556 - Identifikation Frontend des Versicherten

Der E-Rezept-Fachdienst MUSS Clientsysteme des Versicherten identifizieren können. [<=]

A_20557 - Zulässigkeit von Operationen für Clientsysteme des Versicherten

Der E-Rezept-Fachdienst MUSS sicherstellen, dass er für Clientsysteme des Versicherten ausschließlich die jeweils dafür spezifizierten Operationen ausführt. [<=]

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.

A_18872 - Umsetzung des E-Rezept-Verwaltung in einer Vertrauenswürdigen Ausführungsumgebung (VAU)

Der E-Rezept-Fachdienst MUSS die Verarbeitung der fachlichen Operationen im Verarbeitungskontext einer Vertrauenswürdigen Ausführungsumgebung (VAU) umsetzen. [<=]

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.

A_18873 - Verarbeitungskontext der VAU

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS sämtliche physikalischen Systemkomponenten sowie sämtliche Softwarekomponenten umfassen, deren Sicherheitseigenschaften sich auf den Schutz der personenbezogenen medizinischen Daten vor Zugriff durch Unbefugte bei ihrer unverschlüsselten Verarbeitung auswirken können. [<=]

A_18874 - Verschlüsselung von außerhalb des Verarbeitungskontextes der VAU gespeicherten Daten

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS sicherstellen, dass sämtliche schützenswerten Daten vor einer Speicherung außerhalb der VAU verschlüsselt werden. [<=]

A_18875 - Geschützte Weitergabe von Daten an autorisierte Nutzer durch die VAU

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS sicherstellen, dass sämtliche schützenswerten Daten ausschließlich über sichere Verbindungen an autorisierte Nutzer weitergegeben werden. [<=]

A_18567 - Transportverschlüsselte Übertragung von Daten

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS sicherstellen, dass er nur transportverschlüsselt mit Clients kommuniziert. [<=]

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

A_18568 - Möglichkeit der Authentisierung gegenüber Clients

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS sich gegenüber Clients, die mit ihm kommunizieren, authentisieren. [<=]

A_18876 - Verschlüsselung der E-Rezept-Daten und technischen Daten der VAU

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS für die Verschlüsselung aller E-Rezept-Daten sowie eigener technischer Daten den Persistenz-Schlüssel verwenden. [<=]

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.

A_19070 - Begrenzung der mit einem Persistenz-Schlüssel gesicherten Datenmenge

Der Verarbeitungskontext des E-Rezept-Fachdienstes MUSS den Persistenz-Schlüssel regelmäßig wechseln und damit sicherstellen, dass in den außerhalb der VAU gespeicherten Daten nur jeweils kleine Segmente mit einem Persistenz-Schlüssel verschlüsselt sind. [<=]

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.

A_18877 - Isolation der VAU von Datenverarbeitungsprozessen des Anbieters

Die VAU des E-Rezept-Fachdienstes MUSS die in ihren Verarbeitungskontexten ablaufenden Datenverarbeitungsprozesse von allen sonstigen Datenverarbeitungsprozessen des Anbieters trennen und damit gewährleisten, dass der Anbieter des E-Rezept-Fachdienstes vom Zugriff auf die in der VAU verarbeiteten schützenswerten unverschlüsselten Daten ausgeschlossen ist. [<=]

A_18878 - Ausschluss von Manipulationen an der Software der VAU

Die VAU des E-Rezept-Fachdienstes MUSS eine Manipulation der für Verarbeitungskontexte eingesetzten Software oder ihrer Konfiguration erkennen und eine Ausführung der manipulierten Software verhindern. [<=]

A_18879 - Ausschluss von Manipulationen an der Hardware der VAU

Die VAU des E-Rezept-Fachdienstes MUSS die Integrität der für Verarbeitungskontexte eingesetzten Hardware und ihrer Konfiguration schützen und damit insbesondere Manipulationen an der Hardware durch den Anbieter des E-Rezept-Fachdienstes ausschließen. [<=]

A_18880 - Kontinuierliche Wirksamkeit des Manipulationsschutzes der VAU

Die VAU des E-Rezept-Fachdienstes MUSS den Ausschluss von Manipulationen an der für Verarbeitungskontexte eingesetzten Hardware und Software durch den Anbieter des E-Rezept-Fachdienstes mit Mitteln umsetzen, deren dauerhafte und kontinuierliche Wirksamkeit gewährleistet werden kann. [<=]

A_18881 - Kein physischer Zugang des Anbieters zu Systemen der VAU

Die VAU des E-Rezept-Fachdienstes MUSS mit technischen Mitteln sicherstellen, dass niemand, auch nicht der Anbieter des E-Rezept-Fachdienstes, während der Verarbeitung personenbezogener medizinischer Daten Zugriff auf physische Schnittstellen der Systeme erlangen kann, auf denen Verarbeitungskontexte ausgeführt werden. [<=]

A_18882 - Nutzdatenbereinigung vor physischem Zugang zu Systemen der VAU

Die VAU des E-Rezept-Fachdienstes MUSS mit technischen Mitteln sicherstellen, dass physischer Zugang zu Hardware-Komponenten der Verarbeitungskontexte nur erfolgen kann, nachdem gewährleistet ist, dass aus ihnen keine Nutzdaten extrahiert werden können. [<=]

A_18832 - Gute Prüfbarkeit der Sicherheitseigenschaften von Code in der VAU

Die VAU des E-Rezept-Fachdienstes MUSS die Verarbeitungslogik in Verarbeitungskontexten mittels Komponenten umsetzen, die ein hohes Maß an Gewissheit bei der Feststellung der Sicherheitseigenschaften der Anwendung ermöglichen und dazu auf Ebene des Codes (der Trusted Computing Base) möglichst kompakt gehalten werden. [<=]

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.

A_18833 - Persistenz-Schlüssel der VAU von HSM bereitgestellt

Die VAU des E-Rezept-Fachdienstes MUSS den für die verschlüsselte Speicherung von E-Rezept-Daten außerhalb der Verarbeitungskontexte erforderlichen symmetrischen Persistenz-Schlüssel im Zuge des Startvorgangs jedes Verarbeitungskontextes aus einem HSM beziehen. [<=]

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.

A_18834 - Integritätsprüfung der VAU

Das HSM des E-Rezept-Fachdienstes MUSS sicherstellen, dass es der VAU den benötigten Persistenz-Schlüssel erst zur Verfügung stellt bzw. Signaturen für die VAU im Rahmen des Verbindungsaufbaus von Clients zur VAU erst erstellt nachdem der Verarbeitungskontext seine Integrität gegenüber dem HSM nachgewiesen hat. [<=]

A_18883 - HSM-Kryptographieschnittstelle und Persistenz-Schlüssel verfügbar nur für Verarbeitungskontexte der VAU

Die VAU des E-Rezept-Fachdienstes MUSS mit technischen Mitteln, die auch Manipulationen durch den Anbieter des E-Rezept-Fachdienstes ausschließen, gewährleisten, dass nur integere Verarbeitungskontexte der VAU Zugriff auf die Kryptographieschnittstelle des HSM zur Nutzung des privaten Schlüsselmaterials für ihr Dienstzertifikat und zum Bezug des Persistenz-Schlüssels erhalten kann. [<=]

A_18884 - Aktivierung des Verarbeitungskontextes der VAU

Die VAU des E-Rezept-Fachdienstes MUSS mit technischen Mitteln gewährleisten, dass schützenswerte Nutzdaten im Verarbeitungskontext erst nach Bezug des Persistenz-Schlüssels entschlüsselt und verarbeitet werden können. [<=]

A_18885 - Keine Speicherung der Persistenz-Schlüssel in Verarbeitungskontexten der VAU

Die VAU des E-Rezept-Fachdienstes DARF den Persistenz-Schlüssel in Verarbeitungskontexten NICHT über einen Neustart hinaus speichern oder verwenden. [<=]

A_18886 - Datenschutzkonformes Logging und Monitoring des Verarbeitungskontextes der VAU

Die VAU des E-Rezept-Fachdienstes MUSS die für den Betrieb eines Fachdienstes erforderlichen Logging- und Monitoring-Informationen in solcher Art und Weise erheben und verarbeiten, dass mit technischen Mitteln ausgeschlossen ist, dass dem Anbieter des E-Rezept-Fachdienstes vertrauliche oder zur Profilbildung geeignete Daten zur Kenntnis gelangen.  [<=]

A_18920 - Managementprozesse des HSM

Der E-Rezept-Fachdienst MUSS die Managementprozesse des HSM so gestalten, dass ein Missbrauch des Schlüsselmaterials durch den Betreiber des E-Rezept-Fachdienstes ausgeschlossen wird. [<=]

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.

A_19001 - Isolation zwischen Datenverarbeitungsprozessen mehrerer Verarbeitungskontexte der VAU

Die VAU des E-Rezept-Fachdienstes MUSS die in ihr ablaufenden Verarbeitungen für die Daten eines Verarbeitungskontextes von den Verarbeitungen für die Daten anderer Verarbeitungskontexte in solcher Weise trennen, dass mit technischen Mitteln ausgeschlossen wird, dass die Verarbeitungen eines Verarbeitungskontextes schadhaft auf die Verarbeitungen eines anderen Verarbeitungskontextes einwirken können. [<=]

A_19002 - Verfügbarkeit des Persistenz-Schlüssels in der VAU

Die VAU des E-Rezept-Fachdienstes MUSS sicherstellen, dass der für die Speicherung von Daten außerhalb der VAU genutzte Persistenz-Schlüssel ausschließlich innerhalb von Verarbeitungskontexten der VAU verfügbar ist. [<=]

A_19003 - Schutz des Persistenz-Schlüssels der VAU

Die VAU des E-Rezept-Fachdienstes MUSS sicherstellen, dass kein Verarbeitungsvorgang zum Verlust von Vertraulichkeit oder Integrität des Persistenz-Schlüssels führen kann. Dies gilt auch im Falle von Manipulationsversuchen seitens authentisierter Akteure sowie im Falle von Verarbeitungsfehlern jeder Art. [<=]

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.

A_19005 - Fault Isolation und Wiederherstellung

Der E-Rezept-Fachdienst MUSS sicherstellen, dass Fehler in Verarbeitungsvorgängen auf die Verarbeitung des jeweils in Verarbeitung befindlichen E-Rezepts begrenzt bleiben und dass die Wiederherstellung eines konsistenten Systemzustands aus den persistierten Daten immer möglich ist. [<=]

A_19006 - Zuordnung von Verarbeitungskontexten und persistenten Datenstrukturen

Der E-Rezept-Fachdienst SOLL die Struktur der persistenten Datenhaltung darauf ausrichten, dass im Rahmen der Wiederherstellung eines konsistenten Systemzustands nach einem Verarbeitungsfehler die Rekonstruktion nur des Verarbeitungskontextes des von dem Verarbeitungsfehler direkt betroffenen E-Rezepts aus dem persistenten Datenspeicher erforderlich ist. [<=]

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:

A_18572 - Information zur Einsatzumgebung

Das E-Rezept-Frontend des Versicherten MUSS sicherstellen, dass der Nutzer über die Annahmen und Anforderungen an die Einsatzumgebung des FdV informiert wird. [<=]

A_18573 - Anzeige von Protokolldaten

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

A_18574 - Schutz der sensiblen Daten im E-Rezept-Frontend des Versicherten

Das E-Rezept-Frontend des Versicherten MUSS Maßnahmen zum Schutz vor der aktuellen Version der OWASP-Mobile-Top-10-Risiken umsetzen. [<=]

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

A_18575 - Verhindern von Session Hijacking im E-Rezept-Frontend des Versicherten

Das E-Rezept-Frontend des Versicherten MUSS sicherstellen, dass eine eRp-Session nicht von anderen Anwendungen auf dem Gerät übernommen werden kann. [<=]

5.3 Anforderungen an den Identity Provider

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

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

A_18861 - Gewährleistung des Schutzbedarfs

Der IdPIDP MUSS sicherstellen, dass die Prozesse zur Verwaltung der Identitätsmerkmale deren Schutzbedarf gewährleisten. [<=]

Durch einen Missbrauch des IdPIDP (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 IdPIDP geeignete Maßnahmen umzusetzen, die das Risiko eines solchen Missbrauchs verhindern.

A_18862 - Transportverschlüsselte Übertragung von AuthN-Token

Der IdPIDP MUSS sicherstellen, dass er nur transportverschlüsselt mit Clients kommuniziert. [<=]

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

A_18863 - Authentifizierungsverfahren mit hohem Sicherheitsstandard

Der IdPIDP MUSS Authentifizierungsverfahren mit einem hohen Sicherheitsstandard anbieten. [<=]

A_18864 - Sicherheitsbetrachtungen berücksichtigen

Der IdPIDP MUSS die Sicherheitsbetrachtungen der eingesetzten Standards berücksichtigen. [<=]

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

A_18860 - Zeitliche Begrenzung AuthN-Token

Der IdPIDP MUSS AuthN-Token zeitlich begrenzen. [<=]

A_18858 - Ungültigkeit AuthN-Token nach Logout

Der IdPIDP MUSS sicherstellen, dass nach einer Abmeldung des Nutzers die AuthN-Token nicht mehr verwendbar sind. [<=]

A_18857 - Widerruf AuthN-Token durch Nutzer

Der IdPIDP MUSS sicherstellen, dass ein Nutzer ein für ihn ausgestelltes AuthN-Token jederzeit für ungültig erklären kann. [<=]

A_18856 - Beschränkung auf erforderliche Informationen

Der IdPIDP DARF NICHT mehr Identitätsmerkmale in einen Token eintragen, als durch den Nutzer angefordert werden. [<=]

A_18859 - Verbot der Profilbildung

Der IdPIDP MUSS verhindern, dass eine missbräuchliche Profilbildung möglich ist. [<=]

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

Abbildung 1: ABB_SYSLERP_001 Übersicht der Fachanwendung E-Rezept 

Abbildung 2: ABB_SYSLERP_002 Fachliches Rollenmodell

Abbildung 3: ABB_SYSLERP_003 Funktionale Zerlegung E-Rezept 

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

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

Abbildung 6: ABB_SYSLERP_005 Anwendungsfälle E-Rezept

Abbildung 7: ABB_SYSLERP_006 Systemzerlegung E-Rezept

Abbildung 8: ABB_SYSLERP_008 Informationsmodell E-Rezept 

7.4 Tabellenverzeichnis

Tabelle 1 : TAB_SYSLERP_048 Fachliche Rollen

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

Tabelle 3 : TAB_SYSLERP_006 Beschreibung Status Task

Tabelle 4: TAB_SYSLERP_005 Anwendungsfall E-Rezepte erzeugen 

Tabelle 5: TAB_SYSLERP_006 Anwendungsfall E-Rezept einstellen

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

Tabelle 7: TAB_SYSLERP_009 Anwendungsfall E-Rezepte durch Versicherten abrufen

Tabelle 8: TAB_SYSLERP_041 Anwendungsfall E-Rezept durch Vertreter abrufen

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

Tabelle 10: TAB_SYSLERP_011 Anwendungsfall Nachricht durch Versicherten übermitteln

Tabelle 11: TAB_SYSLERP_037 Anwendungsfall Nachrichten durch Versicherten empfangen

Tabelle 12: TAB_SYSLERP_013061 Anwendungsfall Protokolldaten abrufen Nachricht durch Versicherten löschen

Tabelle 13: TAB_SYSLERP_036013 Anwendungsfall Nachrichten durch Abgebenden empfangen Protokolldaten abrufen

Tabelle 14: TAB_SYSLERP_055036 Anwendungsfall Nachricht Nachrichten durch Abgebenden übermittelnempfangen

Tabelle 15: TAB_SYSLERP_014055 Anwendungsfall E-RezeptNachricht durch Abgebenden abrufenübermitteln

Tabelle 16: TAB_SYSLERP_015062 Anwendungsfall E-Rezept Nachricht durch Abgebenden zurückgebenlöschen

Tabelle 17: TAB_SYSLERP_016014 Anwendungsfall E-Rezept durch Abgebenden löschenabrufen

Tabelle 18: TAB_SYSLERP_017015 Anwendungsfall Quittung abrufen E-Rezept durch Abgebenden zurückgeben

Tabelle 19: TAB_SYSLERP_057016 Anwendungsfall Quittung erneut abrufen E-Rezept durch Abgebenden löschen

Tabelle 20: TAB_SYSLERP_018017 Anwendungsfall Dispensierdatensatz durch Abgebenden signierenQuittung abrufen

Tabelle 21: TAB_SYSLERP_045 AuthN-Token durch Versicherten anfordern057 Anwendungsfall Quittung erneut abrufen

Tabelle 22: TAB_SYSLERP_046 AuthN-Token durch LEI anfordern018 Anwendungsfall Dispensierdatensatz durch Abgebenden signieren

Tabelle 23: TAB_SYSLERP_019 Schnittstellen E-Rezept-Fachdienst045 AuthN-Token durch Versicherten anfordern

Tabelle 24: TAB_SYSLERP_021 Bedingungen zum Löschen von E-Rezepten046 AuthN-Token durch LEI anfordern

Tabelle 25: TAB_SYSLERP_040 Zugangsberechtigungen Operationen019 Schnittstellen E-Rezept-Fachdienst

Tabelle 26: TAB_SYSLERP_002 Maximales Aufkommen nach Rezeptzeilen (Muster 16) 2018 an ausgewählten Wochentagen021 Bedingungen zum Löschen von E-Rezepten

Tabelle 27: TAB_SYSLERP_003 Gesamtes Aufkommen nach Rezeptzeilen (Muster 16) 2018 kumuliert nach Wochentagen040 Zugangsberechtigungen Operationen E-Rezept-Fachdienst

Tabelle 28: TAB_SYSLERP_022 Nutzung Schnittstellen eRp-FdV002 Maximales Aufkommen nach Rezeptzeilen (Muster 16) 2018 an ausgewählten Wochentagen

Tabelle 29: TAB_SYSLERP_023 Nutzung Schnittstellen PS verordnende LEI003 Gesamtes Aufkommen nach Rezeptzeilen (Muster 16) 2018 kumuliert nach Wochentagen

Tabelle 30: TAB_SYSLERP_024022 Nutzung Schnittstellen PS abgebende LEIeRp-FdV

Tabelle 31: TAB_SYSLERP_025 Operation E-Rezept-ID abrufen023 Nutzung Schnittstellen PS verordnende LEI

Tabelle 32: TAB_SYSLERP_026 Operation E-Rezept einstellen024 Nutzung Schnittstellen PS abgebende LEI

Tabelle 33: TAB_SYSLERP_027025 Operation  E-Rezept durch Verordnenden löschen-ID abrufen

Tabelle 34: TAB_SYSLERP_028026 Operation E-Rezept durch Abgebenden abrufeneinstellen

Tabelle 35: TAB_SYSLERP_029027 Operation E-Rezept durch AbgebendenVerordnenden löschen

Tabelle 36: TAB_SYSLERP_030028 Operation E-Rezept durch Abgebenden zurückgebenabrufen

Tabelle 37: TAB_SYSLERP_031029 Operation Quittung abrufen E-Rezept durch Abgebenden löschen

Tabelle 38: TAB_SYSLERP_031030 Operation Quittung erneut abrufen E-Rezept durch Abgebenden zurückgeben

Tabelle 39: TAB_SYSLERP_043031 Operation E-Rezepte durch Versicherten Quittung abrufen

Tabelle 40: TAB_SYSLERP_032031 Operation E-Rezept durch Vertreter Quittung erneut abrufen

Tabelle 41: TAB_SYSLERP_033043 Operation  E-RezeptRezepte durch Versicherten löschenabrufen

Tabelle 42: TAB_SYSLERP_054032 Operation Dispensierinformationen durch Versicherten E-Rezept durch Vertreter abrufen

Tabelle 43: TAB_SYSLERP_058033 Operation Dispensierinformation für ein einzelnes E-Rezept durch Versicherten  oder Vertreter abrufen löschen

Tabelle 44: TAB_SYSLERP_044054 Operation E-Rezept-Nachricht einstellen Dispensierinformationen durch Versicherten abrufen

Tabelle 45: TAB_SYSLERP_050058 Operation Dispensierinformation für ein einzelnes E-Rezept-Nachrichten durch Versicherten  oder Vertreter abrufen

Tabelle 46: TAB_SYSLERP_051044 Operation Zugriffsprotokolleinträge durch Versicherten abrufenE-Rezept-Nachricht einstellen

Tabelle 47: TAB_SYSLERP_052 Schutzbedarf der maßgeblichen InformationsobjekteTabelle 47: TAB_SYSLERP_050 Operation E-Rezept-Nachrichten abrufen

Tabelle 48: TAB_SYSLERP_053 Schutzbedarf der maßgeblichen ProzesseTabelle 48: TAB_SYSLERP_060 Operation E-Rezept-Nachricht löschen

Tabelle 49: TAB_SYSLERP_051 Operation Zugriffsprotokolleinträge durch Versicherten abrufen

Tabelle 50: TAB_SYSLERP_052 Schutzbedarf der maßgeblichen Informationsobjekte

Tabelle 51: TAB_SYSLERP_053 Schutzbedarf der maßgeblichen Prozesse

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