Telematikinfrastruktur

Feature: 

ePrescription/eDispensation

Land B

Version
1.0.0_CC
Revision
1582983
Stand
27.04.2026
Status
zur Abstimmung freigegeben
Klassifizierung
öffentlich_Entwurf
Referenzierung
gemF_ePeD-B

Dokumenteninformation

Gender-Hinweis

Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt das Anwendungsszenario zum Abruf von Verordnungsdaten und zum Schreiben von Dispensierdaten von elektronischen Rezepten (E-Rezepten) für eine Person aus einem europäischen Mitgliedstaat (Land A), die ihr E-Rezept aus dem EU-Ausland in einer Apotheke in Deutschland (Land B) einlösen möchte.

In diesem Dokument wird für diesen Anwendungsfall auch die Bezeichnung ePrescription/eDispensation-B verwendet, kurz ePeD-B. 

Dieses Dokument dient dazu, die fachliche Sicht auf den Anwendungsfall ePeD-B zusammenzufassen. Die Ergebnisse der fachlichen Analyse fließen in ein technisches Konzept für das Land-B-System ein, welches auch Teil dieses Dokuments ist. Das technische Konzept wiederum bildet die Grundlage für die Konzeption und die Spezifikation des National Contact Point for eHealth-Fachdienstes (NCPeH-FD) sowie des gesamten Land-B-Systems.

1.1 Zielsetzung

Dieses Dokument beschreibt den Funktionsumfang aus der Sicht der Nutzer und dient dazu, die Bedürfnisse der Nutzer besser zu verstehen. Mit dem ermittelten Funktionsumfang sollen die gematik und die Deutsche Verbindungsstelle Krankenversicherung-Ausland (DVKA) in die Lage versetzt werden, den zusätzlichen Funktionsumfang des National Contact Point for eHealth (NCPeH) zu bewerten und umsetzen zu können. Außerdem sollen Anbieter und Betreiber der weiteren Komponenten des Land-B-Systems in die Lage versetzt werden, den Funktionsumfang der Komponenten bewerten und umsetzen zu können.

1.2 Zielgruppe

Dieses Featuredokument richtet sich an die gematik und ihre Gesellschafter, die DVKA, das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) sowie Hersteller von Apothekenverwaltungssystemen (AVS) als Grundlage für den gemeinsamen Austausch und zur Umsetzung der einzelnen Features.

1.3 Abgrenzungen

In diesem Dokument wird ausschließlich Use Case 1 (UC 1) betrachtet. Die weiteren Use Cases (UC 0, 2, 3, 4) dienen lediglich der Einordnung in den Gesamtkontext.

• UC 0 beschreibt den nationalen E-Rezept Use Case, also eine Verordnung, die in Land A sowohl verordnet als auch dispensiert wird.
• UC 1 beschreibt eine Verordnung in Land A, die in Land B dispensiert wird.
• UC 2 beschreibt eine Verordnung, die in Land B sowohl erstellt als auch dispensiert wird.
• UC 3 beschreibt eine Verordnung in Land B, die in Land A dispensiert wird.
• UC 4 beschreibt eine Verordnung in Land B, die in einem dritten Land C dispensiert wird.

Abbildung 1: Abgrenzungen ePeD-B

1.4 Methodik

Use Case

Ein Use Case beschreibt einen Anwendungsfall. Damit wird unter der Berücksichtigung von Rollen beschrieben, welche Aktivitäten durchgeführt werden sollen, die in einer Funktion zusammengefasst werden können. 

Feature

Ein Feature beschreibt eine abgrenzbare Sammlung von funktionalen Anforderungen, die in Gänze einen eigenständigen Mehrwert und damit eine Funktionalität für das Produkt bereitstellen.

Ein Feature wird mit einer oder mehreren User Stories konkretisiert.

User Story

Eine User Story beschreibt in natürlicher Sprache eine Anforderung aus Nutzersicht. Sie wird anhand einer Satzschablone formuliert und umfasst, was der erwartete Nutzen bzw. die verfolgte Intention hinter der Aktivität ist. Folgendes Schema wird bei der Formulierung der User Stories verwendet:

Akzeptanzkriterien ergänzen die User Story. Damit wird beschrieben, wie die korrekte Umsetzung der User Story getestet werden würde. Dies ist für das Verständnis und für den Test der User Story hilfreich.

Hinweise 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 Allgemeine Rahmenbedingungen

Die allgemeinen Rahmenbedingungen ergeben sich aus dem gesetzlichen Rahmen der Verordnung über den europäischen Gesundheitsdatenraum (EHDS VO) (EU 2025/327), den Guidelines des eHealth Network (eHN) und den Vorgaben der MyHealth@EU - eHealth Digital Service Infrastructure (eHDSI).

Die Anforderungen an das Anwendungsszenario ePrescription/eDispensation-B basieren maßgeblich auf den Vorgaben der eHDSI (v.a. [eHDSI_Requirements_Catalogue]). Diese sind bezüglich der Inhalte der ePrescription allerdings teilweise nicht konsistent mit den Vorgaben der Arzneimittelverschreibungsverordnung (AMVV, § 2) sowie mit den Vorgaben gemäß Durchführungsrichtlinie 2012/52/EU (Anhang). Diese Inkonsistenzen sind mit dem BMG bzw. mit Angehörigen der DG Sante der Europäischen Kommission sowie der eHealth Member States Expert Group (eHMSEG) besprochen worden. Zum Zeitpunkt der Kommentierung des Featuredokuments liegt noch keine Information über die konkreten weiteren Schritte des BMG und der Europäischen Kommission vor. Bis zum Abschluss der weiteren Verfahren sind Anpassungen der Anwendungsfälle daher nicht auszuschließen. Die in diesem Dokument genannten Paragrafen werden unter Vorbehalt der finalen Änderungsverordnung(en) gekennzeichnet und aktualisiert, sobald die neue Version der Verordnung(en) in Kraft tritt.

2.1 Gesetzliche Regelungen in Deutschland

Grundlage für die Inhalte einer Verordnung von Arzneimitteln nach §31 SGB V ist in Deutschland die „Verordnung über die Verschreibungspflicht von Arzneimitteln“ (Arzneimittelverschreibungsverordnung - AMVV). In der [Arzneimittelverschreibungsverordnung §2] ist ebenfalls festgehalten, dass

„Den aus Deutschland stammenden ärztlichen oder zahnärztlichen Verschreibungen sind entsprechende Verschreibungen aus den Mitgliedstaaten der Europäischen Union, aus den Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum und aus der Schweiz gleichgestellt, sofern diese die Angaben nach Absatz 1 aufweisen und dadurch ihre Authentizität und ihre Ausstellung durch eine dazu berechtigte ärztliche oder zahnärztliche Person nachweisen.“
(§ 2 Abs. 1a AMVV)

Somit besteht in Deutschland eine rechtliche Grundlage für die Anerkennung von Rezepten aus dem EU‑Ausland, dem Europäischen Wirtschaftsraum sowie der Schweiz. Die Anerkennung deutscher Rezepte in anderen Mitgliedstaaten der Europäischen Union erfolgt entsprechend der jeweiligen nationalen Umsetzung der einschlägigen EU‑rechtlichen Vorgaben.

2.2 Rechtliche Rahmenbedingungen in der Europäischen Union

Gemäß Artikel 11 Absatz 2 der Richtlinie 2011/24/EU ist die Kommission verpflichtet, Maßnahmen zur Erleichterung der Anerkennung von Verschreibungen zu erlassen, die in einem anderen Mitgliedstaat ausgestellt wurden als in dem, in dem das verschriebene Produkt abgegeben werden soll. Diese Maßnahmen wurden in der Durchführungsrichtlinie 2012/52/EU festgelegt. 

2.2.1 Vorgaben an ärztliche Verordnungen gemäß Durchführungsrichtlinie 2012/52/EU

Die [Durchführungsrichtlinie 2012/52/EU] beschreibt Maßnahmen zur Erleichterung der Anerkennung von in einem anderen Mitgliedstaat ausgestellten ärztlichen Verschreibungen. Im Rahmen dieser Richtlinie ist festgelegt, welche Informationen eine Verschreibung enthalten muss, damit diese in einem Mitgliedstaat der Europäischen Union (EU) akzeptiert wird.

Im Rahmen der Richtlinie wird ebenfalls darauf hingewiesen, dass die Bereitstellung der Informationen nur für jene Verschreibungen gelten soll, die in einem anderen Mitgliedstaat eingelöst werden sollen. 

Die Vorgaben zum Inhalt einer Verschreibung zur Einlösung in einem EU-Mitgliedstaat kann der Durchführungsrichtlinie entnommen werden. 

2.2.2 Vorgaben zu ePrescription und eDispensation gemäß eHN Guideline

Mit der [eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU ePrescription and eDispensation of Authorised Medicinal Products] werden juristische, organisatorische, semantische und technische Anforderungen festgehalten, die sich auf den Abruf von Verordnungsdaten und das Schreiben von Dispensierdaten über den NCPeH beziehen. Darauf aufbauend gelten detaillierte technische Festlegungen, die das Produktverhalten des NCPeH definieren. Diese sind zusammengefasst im [eHDSI_Requirements_Catalogue] (aktuell in der Version 10.0.0 vom 06.03.2026).

2.3 Vorbedingungen zum Abruf von Verordnungsdaten aus dem EU-Ausland

Voraussetzung für die Nutzung von E-Rezepten eines anderen EU-Mitgliedstaats in Deutschland ist die vorherige Anlage und Befüllung von E-Rezepten unter Beachtung der eHDSI-Vorgaben durch autorisierte Leistungserbringer im europäischen Mitgliedstaat des EU-Bürgers. Ferner wird vorausgesetzt, dass eine Netzanbindung an die TI existiert und korrekt freigeschaltet ist, um dadurch den Datenaustausch zu ermöglichen.

2.4 Netzanbindung an das europäische Netzwerk

Die Europäische Kommission hat mit der eHealth Digital Service Infrastructure (eHDSI), oder auch MyHealth@EU Infrastruktur, eine elektronische Infrastruktur geschaffen, durch die bestehende nationale Infrastrukturen grenzüberschreitend vernetzt werden und damit zusätzliche grenzüberschreitende Gesundheitsdienste angeboten werden können. Mit der eHDSI wurde ein Rahmen geschaffen, mit dem die Gesundheitsdaten der Versicherten sicher und interoperabel grenzüberschreitend ausgetauscht werden können. Der Datenaustausch zwischen den einzelnen nationalen Infrastrukturen und der eHDSI erfolgt über die NCPeHs, die unter der Hoheit der einzelnen europäischen Mitgliedstaaten stehen.

Weitere Voraussetzung für den europäischen Datenaustausch ist der Zugang und die Kommunikation mit dem europäischen Netzwerk Trans European Services for Telematics between Administrations - new generation (TESTA-ng). Das Netz TESTA-ng wurde für den steigenden Bedarf an sicherer grenzüberschreitender Zusammenarbeit zwischen den einzelnen Verwaltungen der EU-Mitgliedstaaten aufgebaut und sorgt auf der Netzwerkebene für verschlüsselte und zuverlässige Übertragung von sensiblen Daten. Die eHDSI baut auf TESTA-ng auf. Auf diese Weise wird mittels TESTA-ng ein sicherer Austausch von Gesundheitsdaten zwischen den nationalen Gesundheitsinfrastrukturen der EU-Mitgliedstaaten gewährleistet.

In der aktuellen Konstellation wird in Deutschland die Verbindung zum europäischen Netzwerk über die Anbindung an die Netze des Bundes (NdB) realisiert, welche eine eigene Anbindung an das TESTA-ng unterhalten. Die entsprechende Netzanbindung, Freischaltung und Sicherheitsabnahme muss erfolgreich durchgeführt werden, bevor NCPeHs anderer EU-Mitgliedstaaten eine Abfrage beim deutschen NCPeH-Fachdienst stellen können. Zusätzlich müssen Kommunikationsverbindungen zu den zentralen Diensten der eHDSI möglich sein.

Die eHDSI-Vorgaben fordern im Rahmen der formalen Zulassung zum operativen Betrieb des NCPeH-Fachdienstes eine Konformitätsprüfung [eHDSI_Audit_Framework]. Die Konformitätsprüfung wird durch einen von DG SANTE beauftragten Prüfer durchgeführt, der die Prüfung der Umsetzung des NCPeH gegenüber dem Betreiber durchführt. Damit soll die Konformität des NCPeH des jeweiligen europäischen Mitgliedstaats gemäß Kriterien und Anforderungen der eHDSI auf allen Ebenen eingehalten werden. Die gewonnenen Erkenntnisse sollen die eHDSI und relevanten europäischen Gremien (z.B. eHealth Network) bei der Entscheidung unterstützen, ob der geprüfte NCPeH in den Produktivbetrieb des grenzüberschreitenden eHealth-Informationssystems Cross-Border eHealth Services (CBeHIS) aufgenommen werden kann.

Die Bereitstellung der Ergebnisse der Konformitätsprüfung ist Aufgabe aller an der Entwicklung und dem Betrieb des NCPeH-Fachdienstes beteiligten Partner. Die Verantwortung über die korrekte Abarbeitung der Checkliste obliegt der DVKA, die hierbei von der gematik und dem BfArM unterstützt wird.

2.5 Validierung und Qualitätskontrolle der eingesetzten Terminologien

Im eHDSI-E-Rezept (ePrescription) sind einige Angaben in codierter Form zu erfassen und zu übermitteln. Damit dem Apotheker im Ausland die Bezeichnungen (auch) in seiner Landessprache angezeigt werden können, sieht die eHDSI eine Transkodierung der nationalen Codes in von der eHDSI vorgegebene Codesysteme und Codes vor. Formale Regeln wurden dafür zwischen den Mitgliedstaaten vereinbart. Die Transkodierung erfolgt mit Hilfe eines Master Value Set Catalogues (MVC) und eines länderspezifischen Master Translation Catalogues (MTC). Die Pflege und Qualitätskontrolle des MVC erfolgt gemeinsam durch die EU-Mitgliedstaaten. Den EU-Mitgliedstaaten obliegt die Validierung und Qualitätskontrolle der national eingesetzten Codesysteme und des jeweiligen MTC. In Deutschland obliegt die Festlegung der semantischen Interoperabilität dem Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) entsprechend § 219d Abs. 6 SGB V.

HL7 CDA wurde von der eHDSI als das eHDSI-Dokumentenformat für die grenzüberschreitende Übermittlung und Verarbeitung von E-Rezepten vordefiniert. Innerhalb der TI wird eine FHIR-Profilierung für deutsche E-Rezepte verwendet. Für die grenzüberschreitende Datenübermittlung bedeutet dies, dass eine Transformation der Nutzdaten (ePrescription- und eDispensation-Dokument) zwischen den Dokumentformaten HL7 CDA und FHIR notwendig wäre. Erfolgt die Verarbeitung nicht direkt innerhalb des AVS, ist jedoch keine Transformation notwendig.

3 Anwendungsumfeld

3.1 Anwendungsszenario: ePrescription/eDispensation Land B

Elektronische Rezepte (E-Rezepte) sollen von Bürgern aus einem EU-Mitgliedstaat vor Ort in einer Apotheke in Deutschland eingelöst werden. Voraussetzung für die Einlösung von E‑Rezepten aus einem anderen EU‑Mitgliedstaat ist, dass diese von einem berechtigten Leistungserbringer ausgestellt wurden (siehe Abbildung 2).

Abbildung 2: Systemischer Blick auf das Anwendungsszenario

Die Durchführung des Anwendungsszenarios umfasst:

1. die Authentisierung und Autorisierung des Leistungserbringers in Deutschland (LE-DE) (über den NCPeH-A),
2. die Aufklärung des EU-Bürgers in der Apotheke (mithilfe der Patient Information Notice (PIN-Dokument)),
3. die Identifikation des EU-Bürgers in der Apotheke vor Ort (mithilfe von NCPeH-A und NCPeH-B),
4. die Bestätigung des Behandlungsverhältnisses zum EU-Bürger (mithilfe von NCPeH-B),
5. die Auflistung und der Abruf der einlösbaren Rezepte des EU-Bürgers (vom NCPeH-A an den NCPeH-B),
6. das Schreiben der Dispensierinformation (vom NCPeH-B an den NCPeH-A) sowie
7. die Abgabe des oder der Medikamente an den EU-Bürger.

Abbildung 3: Flussdiagramm Anwendungsszenario ePeD-B

3.2 Akteure und Rollen

Für das Anwendungsszenario ePrescription/eDispensation Land B werden unterschiedliche Akteure und Rollen berücksichtigt.

Akteure, die an der Realisierung des Service ePrescription/eDispensation-B indirekt oder direkt beteiligt sind:

• Anbieter und Betreiber des NCPeH und der Fachanwendung im Land A
• Betreiber der TESTA-ng
• eHDSI Solution Provider (Betreiber und Anbieter der zentralen Dienste der eHDSI)
• DVKA (Anbieter und Betreiber des NCPeH-Fachdienstes)
• Anbieter und Betreiber des NCPeH-Proxy und des EU-Webportals 
• gematik (Test und Bestätigung des NCPeH-Fachdienstes der DVKA)
• eHealth Network (Entscheider zur Inbetriebnahme nach Europa an das TESTA-ng, auf Empfehlung durch die eHealth Member States Expert Group (eHMSEG))
• BfArM (Pflege und Bereitstellung von Terminologien und zugehörigen Transcodier- und Transformationsregeln)
• Beteiligte für die Bereitstellung der Telematikinfrastruktur (Zentrale Dienste etc.)

Zum Zeitpunkt der Kommentierung des Featuredokuments ist noch offen, wer Anbieter bzw. Betreiber des NCPeH-Proxy und des EU-Webportals sein wird.

Rollen, in denen sich Personen als Nutzer an dem Anwendungsszenario beteiligen:

• Bürger aus einem EU-Mitgliedstaat oder einem Mitgliedstaat des Europäischen Wirtschaftsraums (EU-Bürger)
• Leistungserbringer aus einem EU-Mitgliedstaat sowie aus Deutschland (LE-EU und LE-DE)

3.2.1 Selbstverwaltung

Akteure der Selbstverwaltung und des Gesundheitswesens tragen zu den rechtlichen und fachlichen Voraussetzungen für die grenzüberschreitende Nutzung eines E-Rezepts bei. Sie koordinieren die beteiligten Systeme, sichern Qualitätsstandards und unterstützen die Umsetzung auf nationaler Ebene.

• gematik: Verantwortlich für Konzeption, Spezifikation und Produktbestätigung des NCPeH und weiterer Komponenten des Land-B-Systems sowie Spezifikation der User Experience für LE-DE
• DVKA: Anbieter und Betreiber des deutschen NCPeH-Fachdienstes
• DAV/ABDA: Interessensvertretung der Leistungserbringer in der Apotheke in Deutschland und Kommunikation zur Nutzung des EU-E-Rezepts
• BfArM: Terminologieverantwortliche

3.2.2 EU-Bürger

Bürger aus einem europäischen Mitgliedstaat initiieren das Anwendungsszenario, indem sie eine Apotheke in Deutschland aufsuchen, um ein in ihrem Zugehörigkeitsland ausgestelltes E-Rezept einzulösen. Dies bedingt technische und administrative Voraussetzungen und datenschutzrechtliche Anforderungen:

• Es muss ein gültiges E-Rezept im Zugehörigkeitsland (Land A) vorliegen.
• Es soll das gültige E-Rezept in Deutschland (Land B) eingelöst werden.
• Die Person muss vom LE-DE identifiziert werden können (bspw. mithilfe eines gültigen Ausweisdokuments).
• Der Person müssen mithilfe der Patient Information Notice (PIN-Dokument) Informationen über ihre Rechte und Pflichten zum Schutz ihrer persönlichen und gesundheitlichen Daten zur Verfügung gestellt werden.

3.2.3 Leistungserbringer

Im Rahmen der grenzüberschreitenden E-Rezept-Nutzung übernehmen verschiedene Leistungserbringer konkrete Aufgaben entlang des Versorgungsprozesses, von der Verordnung im Land A bis zum Einlösen des E-Rezepts in der Apotheke in Deutschland.

Verordnende Leistungserbringer im Heimatland (Land A) stellen elektronische Rezepte nach den nationalen Vorgaben des Herkunftslandes aus.

Apotheken in Deutschland (Land B) müssen fachlich und technisch in der Lage sein, E-Rezepte aus dem EU-Ausland zu verarbeiten, was voraussetzt, dass sie an die Telematikinfrastruktur (TI) angebunden sind und auf die Anwendung von MyHealth@EU zugreifen können.

Abgebende Leistungserbringer in Deutschland (Land B) tragen die fachliche Verantwortung für die Prüfung des E-Rezepts und die Abgabe des Arzneimittels. Sie stehen in direkter Kommunikation mit dem EU-Bürger, müssen Verordnungsdaten klinisch prüfen (z. B. Plausibilität, Dosierung, Kontraindikationen) und über Besonderheiten des oder der abzugebenden Medikamente informieren (Sprache, Einnahmehinweise etc.).

Hinweis: Eine vollumfängliche pharmazeutische Versorgung und Beratung im Land B kann nicht gewährleistet werden, da dem dispensierenden LE-DE nicht alle relevanten Informationen für eine vollständige Risikoabschätzung vorliegen werden.

3.2.4 Technische Betreiber

Die technische Umsetzung des grenzüberschreitenden E-Rezepts setzt ein Zusammenspiel mehrerer technischer Betreiber von Diensten und Komponenten im europäischen Mitgliedstaat (Land A), in der MyHealth@EU-Infrastruktur und national in Deutschland (Land B) voraus.

Land A

• Anbieter und Betreiber des NCPeH und der Fachanwendung im Land A 

MyHealth@EU Infrastruktur

• Betreiber der TESTA-ng
• eHDSI Solution Provider (Betreiber und Anbieter der zentralen Dienste der eHDSI)

Land B

• DVKA als Anbieter und Betreiber des NCPeH-Fachdienstes
• Anbieter und Betreiber des NCPeH-Proxy und des EU-Webportals
• Anbieter und Betreiber von Diensten und Komponenten in der TI (z.B. zentrale Dienste)

Das Supportkonzept mit beteiligten Akteuren für das Anwendungsszenario ePeD-B wird festgelegt, sobald Anbieter und Betreiber des NCPeH-Proxy und des EU-Webportals feststehen.

3.3 In Scope

Folgende Aspekte werden durch die Umsetzung des Anwendungsszenarios ePeD-B in Apotheken in Deutschland ermöglicht:

• Dispensierung von innerhalb der EU zugelassenen Arzneimitteln auf Basis einer elektronischen Verschreibung eines EU-Bürgers aus einem europäischen Mitgliedstaat unter Berücksichtigung der inhaltlichen Vorgaben gemäß der Durchführungsrichtlinie 2012/52/EU bzw. des [eHDSI_Requirements_Catalogue]
• Einsicht in die vollständigen, aktuellen und im EU-Ausland einlösbaren Verschreibungen eines EU-Bürgers aus einem europäischen Mitgliedstaat
• Einsicht in die vollständigen, aktuellen und nur im europäischen Mitgliedstaat der EU-Bürger einlösbaren E-Rezepte, falls dies durch den europäischen Mitgliedstaat den EU-Bürgern ermöglicht wird
• Substitution auf Basis der deutschen gesetzlichen Vorgaben gemäß §17 ApBetrO

3.4 Out of Scope

Folgende Aspekte werden im vorliegenden Dokument nicht betrachtet:

• Akteure und Rollen
• Versandapotheken:
• Zum Zeitpunkt der Verfassung dieses Dokuments sehen die eHDSI-Vorgaben vor, dass das Anwendungsszenario ePeD auf Apotheken vor Ort beschränkt ist. Die Anforderungen der eHDSI erfordern eine Identitätsprüfung, die derzeit nur mit einem Lichtbildausweis nachgewiesen werden kann. Für die Inklusion von Versandapotheken in Deutschland ist es notwendig, auch die EUDI Wallet zu berücksichtigen. Diese Anforderungen werden stufenweise nachträglich analysiert und eingearbeitet.
• Apotheke vor Ort:
• Apotheker, Pharmazieingenieure und Apothekerassistenzen:
• Die eHDSI-Vorgaben erfordern eine personenbezogene Multi-Faktor-Authentisierung zum Zwecke der Identifikation, Authentisierung und Autorisierung am NCPeH-B. Für die Einbindung von Apothekern, Pharmazieingenieuren und Apothekerassistenzen in Deutschland im Anwendungsszenario ePeD-B ist es notwendig, dass in der TI personenbezogene Leistungserbringer-Identifikationsmittel für sie existieren. Da diese zum aktuellen Zeitpunkt noch nicht flächendeckend existieren, können zunächst nur die Apotheker, Pharmazieingenieure und Apothekerassistenzen berücksichtigt werden, die ein personenbezogenes Leistungserbringer-Identifikationsmittel besitzen.  
• Pharmazeutisch-technische Assistenten (PTA):
• Im Versorgungsalltag unterstützen PTAs unter Aufsicht der Apotheker bei der Dispensierung und bei der Durchführung technischer Abläufe (Rezeptabruf, Scan etc.). Die Vorgaben der eHDSI erfordern, dass eine personenbezogene Multi-Faktor-Authentisierung zum Zwecke der Identifikation, Authentisierung und Autorisierung am NCPeH-B durchgeführt wird. Für die Einbindung von PTAs in Deutschland im Anwendungsszenario ePeD-B ist es notwendig, dass in der TI personenbezogene Leistungserbringer-Identifikationsmittel für PTAs existieren. Da diese zum aktuellen Zeitpunkt noch nicht existieren, können PTAs zunächst keine eigenständige Dispensierung durchführen. 
• Pharmazeutisch-kaufmännische Angestellte (PKA):
• Im Versorgungsalltag unterstützen PKAs vorrangig bei administrativen Tätigkeiten (z. B. bei Abrechnung oder Bestellwesen), nehmen jedoch in manchen Apotheken eine aktivere Rolle in der Medikamentenausgabe ein. Für das Anwendungsszenario ePeD-B wird diese Rolle nicht berücksichtigt.
• Krankenhausapotheke:
• Eine Krankenhausapotheke kann einen öffentlichen Anteil haben und damit für Bürger zur Verfügung stehen, die ein E-Rezept einlösen möchten. Im Zuge der Einführung des Anwendungsszenarios ePeD-B in Deutschland kann eine Krankenhausapotheke diesen Dienst grundsätzlich anbieten. Es wird in diesem Dokument jedoch nicht näher auf die Besonderheiten von Krankenhausapotheken eingegangen. Die Krankenhaus-internen Abläufe und die Rolle der Krankenhausapotheke für Anordnungen ist vom Anwendungsszenario ePeD-B unberührt.

• Funktionale und technische Aspekte
• EUDI Wallet:
• Die Anforderungen der eHDSI erfordern eine Identitätsprüfung für EU-Bürger, die derzeit nur mit einem Lichtbildausweis nachgewiesen werden kann bzw. eine personenbezogene Multi-Faktor-Authentisierung für Leistungserbringer in Deutschland, die aktuell nur kartenbasiert umgesetzt werden kann. Die Anforderungen der EUDI Wallet werden stufenweise nachträglich analysiert und eingearbeitet.

• Fachliche Aspekte: 
• Es wird in diesem Dokument und über den NCPeH-B nicht abgebildet, wenn:
• E-Rezepte im Land B verordnet wurden und dort eingelöst werden sollen;
• Fälle auftreten, in denen Bürger oder Patienten im Herkunftsland (Land A) bestimmte Informationen (z. B. Verschreibungen, Diagnosen) verbergen, aber im Behandlungsland (Land B) Einsicht in diese Informationen gewähren möchten;
• es sich um Verordnungen von Betäubungsmitteln gemäß Artikel 71(2) der Richtlinie 2001/83/EG handelt;
• es sich um Verordnungen von Medizinprodukten handelt;
• es sich um Verordnungen von nicht-pharmazeutischen Maßnahmen oder Produkten handelt;
• Arzneimittel verordnet wurden, die individuell für Patienten in Apotheken zubereitet werden (Formula magistralis), oder die nach Vorschriften eines Arzneibuchs oder der Apothekenliste in der Apotheke hergestellt werden (Formula officinalis).

4 Motivation

Ausländische Rezepte sind insbesondere bei Apotheken in Grenzregionen ein Regelfall in der Versorgung. Eine Verifizierung ausländischer Rezepte erfolgt aktuell behelfsmäßig über Internetrecherche des Apothekers und Vorlegen des Personalausweises des EU-Bürgers. Eine standardisierte Verifizierung existiert bisher nicht und insbesondere auch eine wiederholte Einlösung kann nicht ausgeschlossen werden. 
Das Ziel ist es, EU-Bürgern eine einfache und rechtssichere Möglichkeit zu bieten, ihre E-Rezepte auch während eines Aufenthalts in Deutschland einzulösen, unter Berücksichtigung der europäischen Interoperabilitätsvorgaben sowie nationaler Regularien.

4.1 Kontinuierliche Arzneimittelversorgung für chronisch erkrankte EU-Bürger

1. Ich als EU-Bürger mit einer chronischen Erkrankung und laufender medikamentöser Langzeitbehandlung möchte mein Rezept aus dem Land A in einer deutschen Apotheke einlösen können, um meine Therapie während eines Aufenthalts im EU-Ausland lückenlos fortsetzen zu können – bspw. auch dann, wenn ich meine aktuelle Medikamentenpackung bereits aufgebraucht habe und laut den Abgaberegeln meines Heimatlandes (z. B. nur eine Packung pro Abgabe erlaubt) keine weitere Packung vorab mitnehmen konnte.

2. Ich als EU-Bürger mit einer chronischen Erkrankung und laufender medikamentöser Langzeitbehandlung möchte mein elektronisches Rezept aus meinem Heimatland in einer Apotheke in Deutschland einlösen können, um meine Therapie auch dann fortsetzen zu können, wenn ich meine Medikamente während eines Aufenthalts im EU-Ausland verloren habe oder sie zu Hause vergessen habe.

4.2 Arzneimittelversorgung für EU-Bürger mit kurzfristigem Bedarf

1. Ich als EU-Bürger mit einem gültigen E-Rezept aus dem EU-Ausland, jedoch ohne laufende Langzeitbehandlung, möchte mein E-Rezept während eines Aufenthalts in Deutschland einlösen können, wenn ich das Medikament vor meiner Abreise im Land A nicht mehr abholen konnte, um dennoch eine notwendige Versorgung sicherzustellen.

2. Ich als EU-Bürger mit einem gültigen E-Rezept aus dem EU-Ausland, jedoch ohne laufende Langzeitbehandlung, möchte mein E-Rezept während meines Aufenthalts in Deutschland einlösen können, wenn ich das verordnete Medikament vergessen oder verloren habe, um die begonnene Therapie fortführen oder abschließen zu können. 

5 Features

Im Folgenden werden das Anwendungsszenario und die zugehörigen fachlichen Informationen im Rahmen von aufeinander aufbauenden Features detaillierter betrachtet. 

Ein Feature umfasst dabei jeweils eine Beschreibung der Anwenderdomäne zur Übersicht über den Workflow des jeweiligen Features sowie die User Stories mit Akzeptanzkriterien.

Legende der Diagramme in der Beschreibung der Anwenderdomäne:

• Grün: Aus vorherigem Feature weiterverwendete fachliche Informationen
• Blau: In diesem Feature neu erzeugte fachliche Informationen

5.1 Authentisierung und Autorisierung des Leistungserbringers in Deutschland

Um eine sichere Gesundheitsversorgung von EU-Bürgern in Deutschland zu gewährleisten, benötigt der Leistungserbringer in Deutschland (LE-DE) Zugriff auf die Gesundheitsdaten des EU-Bürgers. Durch eine eindeutige und sichere Authentisierung sowie Autorisierung des LE wird sichergestellt, dass nur berechtigte und autorisierte LE Zugriff auf grenzüberschreitende Gesundheitsdienste erhalten.

Alle an MyHealth@EU beteiligten Länder sind Teil eines gemeinsamen Vertrauensraums. Eine wesentliche Grundlage für dieses Vertrauen ist die sichere und eindeutige Authentifizierung und Autorisierung jedes LE im lokalen System.

5.1.1 Beschreibung der Anwenderdomäne

Ein LE-DE benötigt persönliche Identifikationsmerkmale und Identifikationsmerkmale der Leistungserbringerinstitution (LEI) (1), um die weiteren Schritte des Anwendungsszenarios durchführen zu können. Diese Identitätsmerkmale werden durch die Smartcards HBA und SMC-B zur Verfügung gestellt. Anhand dieser Smartcards meldet sich der LE-DE am ePeD-B System(detaillierte Beschreibung der beteiligten Komponenten siehe Kapitel 6 ff.) an.

Das ePeD-B System holt einerseits beim zentralen IDP der TI eine Bestätigung der TI-Identität des LE-DE ein (2) und erstellt andererseits eine neue (zeitlich begrenzt gültige) elektronische Identität für diesen (3), die im EU-Kontext funktioniert und Rechte für den Zugriff auf ebendiesen EU-Kontext definiert (4).

Abbildung 4: Authentisierung und Autorisierung des Leistungserbringers in Deutschland

5.1.2 User Stories

1. Als nationale Verbindungsstelle muss ich sicherstellen, dass der LE-DE seine Identität eindeutig und sicher authentisiert, damit ich den LE-DE berechtigen kann, die Daten eines EU-Bürgers gemäß seiner Rolle und seines Profils abrufen zu können.

2. Als nationale Verbindungsstelle muss ich sicherstellen, dass eine Authentisierung des LE-DE nach Ablauf von vier Stunden ungültig wird, damit nur berechtigte LE-DE die Daten von EU-Bürgern abrufen können. (Vorgabe des [eHDSI_SAML_Profile] #2.1)

3. Als LE-DE möchte ich eine klare Anleitung und Unterstützung für meine Authentisierung sowie die anschließende Autorisierung erhalten, damit ich sicherstellen kann, dass ich die korrekten Schritte durchführe.

4. Ich als LE-DE möchte bei aufgetretenen Fehlern und Warnungen darüber informiert werden und leicht verständlich mögliche Handlungsoptionen angeboten bekommen, um passend auf Fehlersituationen reagieren zu können.

5. Ich als LE-DE möchte meine Authentisierung einfach abbrechen können, um bei Wegfall des Authentisierungsbedarfes unkompliziert reagieren zu können.

5.2 Information der Betroffenen über ihre Rechte und Pflichten zum Schutz ihrer personenbezogenen und gesundheitlichen Daten

Das Feature ermöglicht die Bereitstellung von Informationen für EU-Bürger (Patient Information Notice (PIN-Dokument)) und LE-DE (Health Professional Information Notice, HPIN-Dokument) über ihre Rechte und Pflichten im Zusammenhang mit der Verarbeitung ihrer personenbezogenen medizinischen Daten. Ziel ist es, Transparenz zu schaffen und die gesetzlichen Informationspflichten zu erfüllen. Die Informationen sollen leicht verständlich, mehrsprachig verfügbar und bezogen auf die Nutzung des grenzüberschreitenden Gesundheitsdienstes ePrescription/eDispensation in Deutschland abrufbar sein.

5.2.1 Beschreibung der Anwenderdomäne

Damit die weiteren Schritte des Anwendungsszenarios durchgeführt werden können, muss derjenige EU-Bürger, welcher das Medikament erhalten möchte, zunächst vor Ort in der Apotheke in Deutschland (2) über die Verarbeitung seiner personenbezogenen und gesundheitlichen Daten informiert werden. Dies erfolgt über ein vereinheitlichtes PIN-Dokument. Dieses PIN-Dokument wird dem EU-Bürger in seiner Landessprache in der Apotheke vor Ort durch den LE-DE zur Verfügung gestellt (3).

Der Anbieter des NCPeH trägt dafür Sorge, dass dem LE-DE das PIN-Dokument in den Sprachen der Mitgliedsländer zur Verfügung gestellt wird (1).

Der LE-DE bestätigt, dass der EU-Bürger das PIN-Dokument zur Kenntnis genommen hat (4). Dafür nutzt er die bereits zuvor ausgestellte elektronische Identität des LE-DE.

Außerdem trägt der Anbieter des NCPeH dafür Sorge, dass dem LE-DE ebenfalls ein HPIN-Dokument zur Verfügung steht (1), welches über das ePeD-B System angezeigt werden kann (5) und den LE-DE seinerseits informiert, welche seiner Daten verarbeitet werden.

Abbildung 5: Information der Betroffenen über ihre Rechte und Pflichten zum Schutz ihrer personenbezogenen und gesundheitlichen Daten

5.2.2 User Stories

1. Als EU-Bürger möchte ich in einer deutschen Apotheke die Information zu meinen Rechten, Pflichten und Verarbeitung meiner Daten bei der Einlösung meiner Rezepte einsehen können, damit ich über die Nutzung meiner Daten informiert bin, bevor der LE-DE auf meine Rezepte zugreift.

2. Als LE-DE möchte ich das PIN-Dokument auch auf Deutsch einsehen können, damit ich den Inhalt verstehen und Fragen des EU-Bürgers beantworten kann.

3. Als LE-DE möchte ich wissen, welche Informationen genau bzgl. meiner Eigenschaft als LE an das Land des EU-Bürgers gesendet werden und welche Rechte und Pflichten ich bei der Verarbeitung meiner persönlichen Daten habe.

4. Als LE-DE möchte ich eine klare und unübersehbare GUI-Führung erhalten, die mich zur PIN-Dokument-Bereitstellung veranlasst, damit ich diese nicht vergessen kann und somit eine Verarbeitung der Daten des EU-Bürgers ohne Bereitstellung des PIN-Dokuments vermeide.

5. Als LE-DE möchte ich eine klare Anleitung und Unterstützung für den Prozess der PIN-Dokument-Bereitstellung und Einsicht in das HPIN-Dokument erhalten, damit ich sicherstellen kann, dass ich die korrekten Schritte zur PIN-Dokument-Bereitstellung und Einsicht in das HPIN-Dokument durchführe.

6. Als Anbieter des NCPeH möchte ich den LE-DE das PIN-Dokument bereitstellen können, damit diese sie bei Bedarf einem EU-Bürger bereitstellen können.

7. Ich als LE-DE möchte bei aufgetretenen Fehlern darüber informiert werden und leicht verständlich mögliche Handlungsoptionen angeboten bekommen, um passend auf Fehlersituationen reagieren zu können.

5.3 Identifikation des EU-Bürgers in der Apotheke vor Ort

Jeder EU-Bürger muss technisch korrekt identifiziert werden, wenn er grenzüberschreitend eine Gesundheitsdienstleistung im Zusammenhang mit MyHealth@EU in Anspruch nimmt und einen LE-DE aufsucht, damit der Zugriff auf die korrekten Daten des EU-Bürgers im Land A sichergestellt wird.

Um jedoch einen EU-Bürger zu identifizieren, benötigt der LE-DE Unterstützung vom Zugehörigkeitsland (Land A): Das Land A stellt eine Suchmaske bereit und definiert, welche Daten vom EU-Bürger für die Suche erforderlich sind und welche national ausgestellten Dokumente als gültig für die Identifizierung seiner Bürger vor Ort in der LEI-DE gelten.

Das Ergebnis der Patientensuche besteht aus einer möglichst umfassenden Teilmenge der demographischen Daten des EU-Bürgers (persönliche Daten). Der Umfang der bereitgestellten Informationen hängt von den gesetzlichen Bestimmungen des Land A sowie von den verfügbaren Daten des EU-Bürgers ab.

Die vom Land A ermittelten persönlichen Daten inkl. der Identifier des EU-Bürgers werden schließlich an den anfragenden LE-DE gegeben. Der LE-DE ist verpflichtet, die Identität des EU-Bürgers mit den elektronisch ermittelten persönlichen Daten des EU-Bürgers zu überprüfen. Er verwendet dafür die vom Zugehörigkeitsland angegebenen Dokumente, um den EU-Bürger zu identifizieren.

5.3.1 Beschreibung der Anwenderdomäne

Die Identifikation findet vor Ort in der LEI-DE statt, indem der EU-Bürger zunächst ein vertrauenswürdiges Ausweisdokument vorlegt (1). Begleitend dazu kann der LE-DE bei Bedarf die Vorgangsbeschreibung der Identifikation einsehen (2).

Für die Suche werden die Identifier des EU-Bürgers genutzt, die der EU-Bürger bereitstellt (3). Zur Suche des EU-Bürgers im System benutzt der LE-DE unter Verwendung seiner eigenen elektronischen Identität die International Search Mask des Landes des EU-Bürgers und sendet eine Anfrage an das ePeD-B System (4).

Anschließend liefert das ePeD-B System die persönlichen Daten des EU-Bürgers (5). Um die Identität zweifelsfrei zu verifizieren, führt der LE-DE einen manuellen Vergleich durch (6). Hierbei wird das physische vertrauenswürdige Ausweisdokument mit den im System vorliegenden persönlichen Daten abgeglichen.

Nach erfolgreichem Abgleich stellt der LE-DE die ermittelten und bestätigten Patient Identifier fest (7), welche durch eine Systemanfrage verknüpft werden.

Abschließend erzeugt das ePeD-B System automatisch eine Identifikationsdokumentation (8), die das ePeD-B System bereitstellt und die final im Dokumentationsarchiv abgelegt wird.

Abbildung 6: Identifikation des EU-Bürgers in der Apotheke vor Ort

5.3.2 User Stories

1. Als LE-DE möchte ich persönliche Daten des EU-Bürgers von der nationalen Infrastruktur des Land A abrufen können, damit ich anhand dieser Daten die Identität des EU-Bürgers abgleichen kann.

2. Als LE-DE möchte ich persönliche Daten des EU-Bürgers von der nationalen Infrastruktur des Land A empfangen können, damit ich die Identität des EU-Bürgers mit diesen Daten abgleichen kann.

3. Als LE-DE möchte ich sicher sein, dass die persönlichen Daten, die ich vom Zugehörigkeitsland erhalte, unverändert und vertrauenswürdig sind, damit ich mich auf die Korrektheit der Informationen verlassen kann.

4. Als LE-DE möchte ich eine klare Anleitung und Unterstützung für den Prozess der Identitätsprüfung erhalten, damit ich sicherstellen kann, dass ich die korrekten Schritte zur Identifizierung des EU-Bürgers durchführe.

5. Ich als LE-DE möchte bei aufgetretenen Fehlern und Warnungen darüber informiert werden und leicht verständlich mögliche Handlungsoptionen angeboten bekommen, um passend auf Fehlersituationen reagieren zu können.

6. Als LE-DE möchte ich die Suche nach persönlichen Daten eines EU-Bürgers wiederholen können, damit ich durch Korrektur oder Erweiterung der Suchparameter ein eindeutiges Suchergebnis erreichen kann.

7. Ich als LE-DE möchte die Identifikation des EU-Bürgers abbrechen können, um auf Wunsch des EU-Bürgers oder meinen Wunsch den Vorgang beenden zu können.

5.4 Bestätigung des Behandlungsverhältnisses zum EU-Bürger

Dieses Feature belegt die Existenz eines Behandlungsverhältnisses zwischen dem EU-Bürger und dem LE-DE in seiner LEI im Kontext der grenzüberschreitenden Versorgung. Dieses Behandlungsverhältnis kann erst existieren, wenn sich der LE-DE erfolgreich authentisiert und autorisiert hat und der EU-Bürger erfolgreich identifiziert wurde. Die Bestätigung des Behandlungsverhältnisses erfolgt durch die nationale Verbindungsstelle in Deutschland und ist nach Vorgaben in [eHDSI_SAML_Profile] #4.1 maximal 2 Stunden gültig.

5.4.1 Beschreibung der Anwenderdomäne

Aufbauend auf der erfolgreichen Identifikation des EU-Bürgers initiiert der LE-DE den nächsten Prozessschritt. Er führt die Bestätigung des Behandlungsverhältnisses im ePeD-B System durch (1). Dabei wird der zuvor im System hinterlegte ermittelte und bestätigte Patient Identifier als Basis für die Zuordnung verwendet.

Im Rahmen dieses Vorgangs überprüft das ePeD-B System die elektronische Identität des LE-DE (2). Die Prüfung ist essenziell, da die Identität spezifische Zugriffsrechte enthält, die für den LE-DE gelten und die Legitimität des Zugriffs sicherstellen.

Nach erfolgreicher Prüfung erzeugt das ePeD-B System die elektronische Bestätigung des Behandlungsverhältnisses (3). Dieses digitale Objekt, auch als TRC-Assertion bezeichnet, weist eine zeitliche Begrenzung auf und enthält eine digitale Signatur im EU-Kontext, um die grenzüberschreitende Anerkennung der Informationsweitergabe und die Sicherheit zu gewährleisten.

Abbildung 7: Bestätigung des Behandlungsverhältnisses zum EU-Bürger

5.4.2 User Stories

1. Als nationale Verbindungsstelle möchte ich die Bestätigung des Behandlungsverhältnisses für LE-DE und die ermittelte EU-Bürger-ID nach EU-Vorgaben erstellen und signieren, um sie authentisch und für EU-Mitgliedstaaten nachprüfbar bereitzustellen.

2. Als LE-DE möchte ich eine klare und unübersehbare GUI-Führung erhalten, damit ich eine Bestätigung des Behandlungsverhältnisses nicht ohne vorhergehende erfolgreiche Identifizierung des EU-Bürgers durchführen kann.

3. Als EU-Bürger möchte ich, dass eine Anfrage zur Bestätigung des Behandlungsverhältnisses zeitlich begrenzt gültig ist, damit meine medizinischen Daten nicht zeitlich uneingeschränkt einsehbar sind.

4. Als LE-DE möchte ich eine klare Anleitung und Unterstützung für den Prozess der Bestätigung des Behandlungsverhältnisses erhalten, damit ich sicherstellen kann, dass ich die korrekten Schritte zur Bestätigung des Behandlungsverhältnisses durchführe.

5. Ich als LE-DE möchte bei aufgetretenen Fehlern darüber informiert werden und leicht verständlich mögliche Handlungsoptionen angeboten bekommen, um passend auf Fehlersituationen reagieren zu können.

6. Ich als LE-DE möchte die Bestätigung des Behandlungsverhältnisses abbrechen können, um auf Wunsch des EU-Bürgers oder meinen Wunsch den Vorgang beenden zu können.

5.5 Auflistung und Abruf der einlösbaren Rezepte des EU-Bürgers

Damit der LE-DE die Rezepte auswählen kann, die der EU-Bürger einlösen möchte, muss für den LE-DE eine Liste der einlösbaren Rezepte des EU-Bürgers einsehbar sein. Falls das Land A informativ auch im EU-Ausland nicht einlösbare Rezepte bereitstellt, die aber im Land A einlösbar wären, so werden diese auch informativ mit angezeigt.

Die einlösbaren Rezepte können in einem weiteren Schritt abgerufen werden, um mehr inhaltliche Details des Rezepts einsehen zu können und das Rezept im nächsten Schritt dispensieren zu können, falls der EU-Bürger dies möchte.

Die Datenelemente der Rezepte sollen wenn möglich auf deutsch übersetzt dargestellt werden, um die Verständlichkeit der Inhalte für den LE-DE zu erleichtern.Die Möglichkeit zur Übersetzung in die deutsche Sprache ist abhängig von der Verfügbarkeit strukturierter und codierter Daten.

5.5.1 Beschreibung der Anwenderdomäne

Sobald die elektronische Bestätigung des Behandlungsverhältnisses zwischen dem EU-Bürger und dem LE-DE vorliegt, stellt das ePeD-B System dem LE-DE die verfügbaren Rezepte bereit (1). Dabei nutzt es erneut die elektronische Identität des LE-DE.

Um die Verständlichkeit und Weiterverarbeitung zu gewährleisten, übersetzt das ePeD-B System die codierten Daten und erzeugt codierte Rezeptinformationen auf deutsch (2). Diese Struktur enthält essenzielle pharmazeutische Details wie den ATC-Code, den Wirkstoff, die Wirkstärke, die Darreichungsform, den Namen des verordnenden LE-EU sowie die Angabe, ob eine Substitution erlaubt ist.

Das ePeD-B System zeigt in der Auflistung den aktuellen Status der Rezepte an (3) und differenziert dabei nach nicht einlösbaren Rezepten und einlösbaren Rezepten des EU-Bürgers. Die Übersicht enthält dabei bereits eine Beschreibung des Rezepts.

Aus den einlösbaren Rezepten ruft der LE-DE einzelne oder mehrere Rezepte ab (4). Die resultierende Menge der abgerufenen, einlösbaren Rezepte enthält mindestens die verpflichtenden Rezeptdaten eines jeden Rezepts aus dieser Menge. Hierbei wird unterschieden in Rezeptdaten, die vorhanden sein müssen und Rezeptdaten, die vorhanden sein sollten (bei Fehlen ist eine Begründung erforderlich). Zudem werden - sofern vorhanden - die Kennzeichnung des Substitutionsverbots sowie optionale Rezeptdaten angezeigt.

Ergänzend bietet der Ablauf eine optionale Validierungsmöglichkeit: Der LE-DE kann das Originalrezept einsehen (5), welches im Datensatz des einlösbaren Rezepts enthalten ist. Für eine bessere Lesbarkeit kann der LE-DE die Spracheinstellung der angezeigten Rezeptdaten ändern (5), beispielsweise um zwischen der Originalsprache (Land A), Englisch oder Deutsch zu wechseln.

Abbildung 8: Auflistung und Abruf der einlösbaren Rezepte des EU-Bürgers

5.5.2 User Stories

1. Als LE-DE möchte ich die einlösbaren Rezepte eines EU-Bürgers mit den wichtigsten Daten auflisten können, um mit dem EU-Bürger eine erste Auswahl der einzulösenden Rezepte treffen zu können.

2. Als LE-DE möchte ich außerhalb des Land A nicht einlösbare Rezepte des EU-Bürgers anzeigen können, sofern diese vom Land A mit ausgegeben werden, um die aktuelle Abgabe von Medikamenten besser bewerten zu können.

3. Als LE-DE möchte ich nach dem Auflisten der Rezepte verstehen können, dass ich in einem weiteren Schritt die vollständigen Rezepte des EU-Bürgers abrufen muss, um den Inhalt der Rezepte bestmöglich verstehen zu können und um das Medikament im Anschluss dispensieren zu können.

4. Als LE-DE möchte ich die vollständigen fachlichen Inhalte eines oder mehrerer Rezepte des EU-Bürgers abrufen und anzeigen können, um Verordnungen aus dem Land A sicher verstehen und korrekt dispensieren zu können.

5. Als LE-DE möchte ich das Originalrezept zu jedem abgerufenen Rezept einsehen und bei Auswahl für die Dispensierung auch speichern können, um ein vollständigeres Verständnis zu den Rezepten eines EU-Bürgers bekommen zu können.

6. Als nationale Verbindungsstelle möchte ich Rezepte nur authentisierten und autorisierten LE-DEs mit gültiger Behandlungsbeziehung zum EU-Bürger zur Verfügung stellen, um die gesetzlichen Anforderungen an IT-Sicherheit und Datenschutz einzuhalten.

7. Als LE-DE möchte ich bei der vollständigen Anzeige der fachlichen Inhalte eines Rezepts zwischen der Originalsprache des Rezepts und der deutschen Sprache wählen können, um ein vollständigeres Verständnis zu den Rezepten eines EU-Bürgers bekommen zu können.

8. Als LE-DE möchte ich sicher sein, dass die persönlichen Daten, die ich vom Zugehörigkeitsland erhalte, unverändert und vertrauenswürdig sind, damit ich mich auf die Korrektheit der Informationen verlassen kann.

9. Als LE-DE möchte ich eine klare Anleitung und Unterstützung für den Prozess des Auflistens und des Abrufs einlösbarer Rezepte des EU-Bürgers erhalten, damit ich sicherstellen kann, dass ich die korrekten Schritte dieses Vorgangs durchführe.

10. Ich als LE-DE möchte bei aufgetretenen Fehlern oder Warnungen darüber informiert werden und leicht verständlich mögliche Handlungsoptionen angeboten bekommen, um passend auf Fehlersituationen reagieren zu können.

11. Ich als LE-DE möchte die Auflistung und den Abruf der einlösbaren Rezepte des EU-Bürgers jederzeit abbrechen können, um auf Wunsch des EU-Bürgers oder meinen Wunsch den Vorgang beenden zu können.

5.6 Schreiben der Dispensierinformation und Abgabe des oder der Medikamente an den EU-Bürger

In diesem Feature wird das Schreiben der Dispensierinformation und die Abgabe des oder der Medikamente an den EU-Bürger betrachtet.

Falls eine Substitution durch den verschreibenden LE im Land A nicht ausgeschlossen wurde, kann der LE-DE auf Basis der deutschen gesetzlichen Regelungen eine Substitution der Verordnung vornehmen.

Der LE-DE muss dann für alle Rezepte, die der EU-Bürger dispensiert haben möchte, eine Dispensierinformation an das Land A zurückschicken. Im Rahmen des Dispensiervorgangs muss außerdem das Medikament an den EU-Bürger übergeben und der Bezahlvorgang abgewickelt werden. Das Land A muss den LE-DE über den Erhalt der Dispensierinformation informieren. Bevor das Land A den Erhalt der Dispensierinformation nicht bestätigt hat, können die einlösbaren Rezepte des EU-Bürgers nicht erneut eingesehen werden. Der Prozess in der Apotheke endet dann, es sei denn, der EU-Bürger möchte weitere Rezepte einlösen oder hat weitere Fragen, die eine erneute Einsicht in die Informationen des EU-Bürgers erfordern.

Der LE-DE sollte den EU-Bürger über das Verschicken der Dispensierinformation an das Land A informieren. 

Die Dispensierinformation sollte möglichst direkt bei Abschluss des Ausgabevorgangs an das Land A verschickt werden, um keine zeitliche Verzögerung der Informationsweitergabe zu haben und damit eingelöste Rezepte nicht erneut dispensiert werden können.Außerdem soll vermieden werden, dass bei einem Versenden der Dispensierinformation nach zeitlichem Ablauf der bestätigten Behandlungsbeziehung der gesamte Ablauf erneut durchgeführt werden muss. Je nach Bedingungen im Land A müsste der EU-Bürger dafür erneut involviert werden, ist aber in der Apotheke nicht mehr verfügbar.

Das Verschicken der Dispensierinformation ist erst möglich, sobald der komplette Dispensiervorgang inklusive Bezahlvorgang abgeschlossen ist, weil das Rezept danach als eingelöst gilt und die Dispensierinformation nicht mehr verändert werden kann.

Bei einer erforderlichen Bestellung des Medikaments muss die Dispensierinformation schon bei ebendieser Bestellung verschickt werden, weil das Rezept bei Abholung je nach Umsetzung im Land A nicht erneut abgerufen werden kann und je nach vergangener Zeitspanne zwischen Bestellung und Abholung das gesamte Anwendungsszenario erneut durchlaufen werden müsste.

5.6.1 Beschreibung der Anwenderdomäne

Nach dem Abruf der Rezeptdaten erfolgt die physische Abgabe der Medikamente sowie die digitale Dokumentation durch den LE-DE. Voraussetzung hierfür ist das Vorliegen der elektronischen Identität des LE-DE sowie die elektronische Bestätigung des Behandlungsverhältnisses.

Der Ablauf beginnt damit, dass der LE-DE ein oder mehrere einlösbare Rezepte festlegt (1). In einem optionalen Zwischenschritt kann der LE-DE das Rezept auf eine Kennzeichnung des Substitutionsverbots prüfen (2). Sofern diese Kennzeichnung nicht vorhanden ist, kann der LE-DE auf gesetzlicher Basis eine Substitution vornehmen. Findet eine Substitution statt, wird diese in der Dispensierinformation dokumentiert.

Anschließend ergänzt der LE-DE für jedes dispensierte Rezept die Dispensierinformation (3). Dieser Vorgang geschieht verkaufsbegleitend. In der Dispensierliste werden die Dispensierinformationen der zu dispensierenden Rezepte gebündelt. Sobald die Liste vollständig ist, übernimmt das ePeD-B System die Dispensierliste für die Weiterverarbeitung (4).

Der Ablauf sieht zudem ein Verfahren bei Fehlern vor: Das ePeD-B System kann einen Dispensierinformationsfehler erzeugen (5). Diesem Fehler werden Handlungsoptionen für das Fehlerbild hinzugefügt. Über diese Optionen wird der LE-DE informiert, um entsprechende Maßnahmen einzuleiten.

Abbildung 9: Schreiben der Dispensierinformation

5.6.2 User Stories

In den folgenden User Stories werden nur die technischen Vorgänge des Schreibens und Verschickens der Dispensierinformation betrachtet, auch wenn der Vorgang zusätzlich die Ausgabe und die Bezahlung des ausgegebenen Medikaments beinhaltet.

1. Als LE-DE möchte ich die Rezepte, die der EU-Bürger dispensiert haben möchte, auswählen und gebündelt dispensieren können, um effizient arbeiten zu können.

2. Als LE-DE möchte ich auf Basis eines Rezepts und den in Deutschland gesetzlich erlaubten Substitutionsmöglichkeiten ein verfügbares Produkt dispensieren können, um eine möglichst umfassende Arzneimittelversorgung sicherzustellen.

3. Als LE-DE möchte ich nach dem Abruf von Rezepten verstehen können, dass ich in einem weiteren Schritt des EU-Workflows die Dispensierinformation an das Land A verschicken muss, um den EU-Workflow korrekt durchzuführen.

4. Als Verarbeiter von Dispensierinformationen im EU-Mitgliedsland möchte ich darüber informiert werden, dass Rezepte eines Bürgers meines Landes eingelöst wurden, um den Medikationsprozess des Bürgers nach eigenem Landesbedarf korrekt dokumentieren zu können.

5. Als LE-DE möchte ich erkennen können, dass der Dispensiervorgang abgeschlossen ist, um sicher zu verstehen, dass ich alle Schritte korrekt befolgt habe.

6. Als EU-Bürger möchte ich weitere Rezepte einlösen können, um eine umfassende Betreuung in der Apotheke zu erhalten.

7.  Ich als LE-DE möchte bei aufgetretenen Dispensierfehlern oder Warnungen darüber informiert werden und leicht verständlich mögliche Handlungsoptionen angeboten bekommen, um passend auf Fehlersituationen reagieren zu können.

8. Ich als LE-DE möchte die Dispensierung ausgewählter Rezepte des EU-Bürgers jederzeit abbrechen können, um auf Wunsch des EU-Bürgers oder meinen Wunsch den Vorgang beenden zu können.

5.7 Nachvollziehbarkeit und Auskunftsansprüche der Datenverarbeitung

Authentisierte und autorisierte Leistungserbringer in Deutschland (LE-DE) können jederzeit eine Anfrage zur Bereitstellung von E-Rezepten eines EU-Bürgers stellen.

Im Streitfall, z.B. wegen einer möglichen Fehlbehandlung, möchte der LE-DE und der EU-Bürger in der Lage sein, die Audit Trails Logs aller Nachrichten anhand eines angeforderten Datensatzes zu erhalten. Um dies zu ermöglichen, geht aus den Audit Trail Logs hervor, wer wann auf welche Daten zugegriffen hat.

Die Inhalte der Audit Trail Logs sind im [eHDSI_Audit_Trail_Profile] vorgegeben.

5.7.1 User Stories

1. Als LE-DE möchte ich, dass alle von mir durchgeführten Zugriffe und Zugriffsversuche auf Rezepte eines EU-Bürgers protokolliert werden, damit diese nachvollzogen werden können und ich mich ggf. gegen falsche Beschuldigungen verteidigen kann.

2.  Als LE-DE möchte ich sicher sein, dass Audit Trail Einträge zu mich betreffenden Vorgängen sicher und unverfälscht gespeichert werden, um eine zuverlässige Auditierung der mich betreffenden Aktivitäten und Daten erhalten zu können.

3. Als nationale Verbindungsstelle möchte ich Daten zur Nachverfolgbarkeit, die entsprechend über eine Schnittstelle abrufbar sein müssen, zur Verfügung stellen können, um berechtigte Auskunftsinteressen bedienen zu können. 

4. Als nationale Verbindungsstelle möchte ich eine Anfrage auf Einsicht in die Audit Trails auf Legitimität prüfen können, um sicherzustellen, dass nur zugriffsberechtigte Personen Einblick in ihre Audit Trail Einträge erhalten.

5.8 Performance und Betrieb

Um einen geordneten Betriebsablauf herzustellen, benötigen die Anbieter des Land-B-Systems, die gematik als gesamtverantwortlicher Betreiber der TI sowie die eHDSI Informationen zur Nutzung und Qualität der eingesetzten Komponenten. Diese setzen sich aus zu definierenden Rohdaten und Use-Case-bezogenen Informationen zusammen. Mithilfe dieser Informationen ist es möglich, den aktuellen Stand der Nutzung der Anwendung nachzuvollziehen sowie bei auftretenden Störungen schnell und gezielt reagieren und eine umgehende Fehlerbehebung vorantreiben zu können.

Im Rahmen der Anwendung ePrescription/eDispensation Land B ist außerdem eine aktuelle und korrekt übersetzte International Search Mask (ISM) von entscheidender Bedeutung, um das Land des EU-Bürgers auszuwählen und die relevanten personenbezogenen Daten zur Identifikation eingeben zu können.

5.8.1 User Stories

1a. Als EU-Bürger möchte ich jederzeit (24 Stunden am Tag, 7 Tage die Woche) bedarfsgerecht und zeitnah Rezepte einlösen können, damit eine bestmögliche Versorgungsqualität gewährleistet ist.

1b. Als LE-DE möchte ich jederzeit (24 Stunden am Tag, 7 Tage die Woche) bedarfsgerecht und zeitnah Rezepte eines EU-Bürgers bearbeiten können, damit eine bestmögliche Versorgungsqualität gewährleistet ist.

2. Als EU-Bürger und LE-DE möchte ich, dass bei der Bereitstellung der Rezepte möglichst geringe Wartezeiten entstehen, damit mehr Zeit für die sichere Identifizierung der Arzneimittel und Beratung zur Verfügung steht.

3. Als LE-DE möchte ich, dass ein Service Desk für mich erreichbar ist, damit ich mich bei technischen Problemen während der Behandlung eines EU-Bürgers an einen zentralen Ansprechpartner wenden kann.

4. Als Anbieter des Land-B-Systems möchte ich mir und der gematik ein Monitoring zu Verfügbarkeit, Auslastung und Sicherheitslage anbieten, damit sichergestellt werden kann, dass eine gleichbleibende Servicequalität im operativen Betrieb vorliegt und wir falls notwendig auf Veränderungen reagieren können.

5. Als eHDSI Solution-Provider und gematik möchte ich regelmäßig über definierte Key Performance Indicators (KPI) informiert werden, um den Zustand und die Nutzung des Systems nachvollziehen und die Servicequalität optimieren zu können.

6. Als Anbieter des Land-B-Systems möchte ich den LE-DE eine stets aktuelle International Search Mask (ISM) zur Länderauswahl bereitstellen, damit der LE-DE seine Aufgaben bestmöglich wahrnehmen kann.

7. Als Anbieter des Land-B-Systems möchte ich den LE-DE eine in die deutsche Sprache übersetzte ISM bereitstellen, damit der LE-DE seine Aufgaben bestmöglich wahrnehmen kann.

8. Als Anbieter des Land-B-Systems möchte ich genau die Länder für den Datenaustausch konfigurieren und zur Nutzung anbieten, mit denen dieser vereinbart wurde, damit der LE-DE nur mit EU-Bürgern von tatsächlich nutzbaren EU-Mitgliedsländern den EU-Workflow starten kann.

9. Als nationale Verbindungsstelle möchte ich meine relevanten Servicedaten auf dem zentralen Dienst der EU bekanntmachen, damit die Anfragen als Land B von anderen Ländern akzeptiert und verarbeitet werden.

10. Als Anbieter des Land-B-Systems möchte ich die Aktualität von Mappingdaten (MVC, MTC, PZN-Tabelle) sicherstellen, damit Übersetzungen medizinischer Daten für die Versorgung in der Apotheke stets auf dem aktuellsten Stand sind.

11. Als Anbieter des Land-B-Systems möchte ich Fehler im laufenden System erkennen, analysieren und nachvollziehen können, um Fehler in funktionalen und nicht-funktionalen Aspekten korrigieren und eine hohe Qualität in der Bereitstellung der Funktionalität sicherstellen zu können.
Hinweis: Es handelt sich hierbei nicht um die in Kapitel 5.7 beschriebenen Audit Trails, sondern um Protokollierung.

12. Als EU-Bürger und LE-DE möchte ich sicher sein, dass meine personenbezogenen Daten in den betrieblichen Protokolldaten bestmöglich geschützt sind, damit keine unberechtigte Person Rückschlüsse auf meine Person und damit verbundene Gesundheitsdaten ziehen kann.

13. Als Anbieter des Land-B-Systems möchte ich die Pflege der Systemkonfiguration sicher gestalten, um fehlerhafte oder unzulässige Änderungen der Systemkonfiguration vorzubeugen bzw. durchgeführte Änderungen nachvollziehen zu können.

6 Einordnung in die Telematikinfrastrukur

Das Anwendungsszenario ePrescription/eDispensation Land B (ePeD-B) ermöglicht es, dass berechtigte Leistungserbringer in Deutschland (LE-DE) E-Rezepte von EU-Bürgern aus anderen EU-Mitgliedstaaten abrufen und dispensieren können.

Die Systemübersicht in der folgenden Abbildung gibt für das Anwendungsszenario ePeD-B einen Überblick über die beteiligten TI-Systeme und externen Systeme sowie über die sichere Kommunikation zwischen ihnen:

Abbildung 10: Systemübersicht des Anwendungsszenarios ePrescription/eDispensation Land B

Der LE-DE verwendet seinen lokalen Rechner mit installiertem Webbrowser, um das aus dem Internet erreichbare EU-Webportal aufzurufen und die Funktionen des ePeD-B Szenarios zu nutzen. Es bietet eine graphische Oberfläche und ermöglicht die Interaktion mit dem Anwendungsszenario ePeD-B. Perspektivisch kann das ePeD-B Szenario direkt über das AVS des LE-DE bedienbar sein, wodurch die direkte Integration der Funktionalitäten in bestehende Systeme ermöglicht wird.

Der gematik-Authenticator ist auf dem Rechner des LE-DE installiert und konfiguriert und ermöglicht mittels des Konnektors oder TI-Gateway den Zugriff auf Smartcards der TI, insbesondere HBA und SMC-B, um die Authentisierung und Identitätsprüfung vorzunehmen. Die Anforderung einer starken Authentisierung und die Verwendung sowohl persönlicher als auch institutioneller Identitätsinformationen stammen aus den Vorgaben der eHDSI. Die Authentisierung erfolgt über die OIDC-Schnittstelle des zentralen IDP-Dienstes der TI und nutzt den Authorization Code Flow.

Der NCPeH-Proxy ist ein neuer Produkttyp der TI und übernimmt die zentrale Rolle als Authorization Server für den Zugriff auf den grenzüberschreitenden eHealth-Dienst ePeD-B. Er verarbeitet die vom IDP-Dienst bestätigten TI-Identitäten, prüft und erteilt im Erfolgsfall eine Zugriffsberechtigung auf den Dienst ePeD-B für den anfragenden LE-DE.

Nach erfolgreicher Authentisierung und damit Anmeldung am EU-Webportal kann der LE-DE die demographischen Daten und E-Rezepte des EU-Bürgers abrufen. Das EU-Webportal sendet die fachlichen Anfragen des LE-DE an den NCPeH-Proxy, der die Anfragen an den NCPeH-FD weiterleitet. Der NCPeH-FD agiert dabei als eHDSI Service Consumer, baut die Vertrauensbeziehung zum NCPeH Land A auf und transkodiert dabei die E-Rezepte nach den Vorgaben der BfArM in die deutsche Sprache.

Die E-Rezepte werden auf dem EU-Webportal angezeigt. Im Rahmen der Abgabe von Arzneimitteln an EU-Bürger erfasst der LE-DE die Dispensierinformationen, die über den NCPeH-Proxy und NCPeH-FD an den NCPeH Land-A übermittelt werden. Der NCPeH-FD implementiert die semantischen Anforderungen der eHDSI und transkodiert die Dispensierinformationen gemäß den Vorgaben des BfArM in das entsprechende eHDSI eDispensation Pivotformat.

6.1 Entscheidung für die Integration von ePeD-B in die Telematikinfrastruktur 1.0

Die Entscheidung, das Anwendungsszenario ePeD-B in die Telematikinfrastruktur 1.0 (TI 1.0) zu integrieren, basiert auf mehreren technischen und regulatorischen Rahmenbedingungen. Eine Integration in die Telematikinfrastruktur 2.0 (TI 2.0) ist derzeit nicht umsetzbar, da zentrale Voraussetzungen für die Nutzung der TI 2.0 fehlen und die termingerechte Bereitstellung des Szenarios ePeD-B gefährden würden.

Die wesentlichen Gründe umfassen das Fehlen klar definierter Anforderungen zur Integration von ZETA Client in das EU-Webportal sowie die fehlende Absicherung durch ZETA Guard im NCPeH-Proxy. Diese Lücken machen eine zuverlässige Nutzung dieser TI 2.0 Leistungsmerkmale in diesem Kontext bis auf weiteres unmöglich. Hinzu kommt, dass derzeit keine hardware-unabhängigen digitalen Identitäten für LE-DE, weder zentral (z.B. als sektoraler IDP für LE) noch dezentral (z.B. Wallet-Lösungen) zur Verfügung stehen. 

Dies schränkt die Nutzung des Anwendungsszenarios ePeD-B im TI 2.0-Kontext ein und macht den Einsatz der Smartcard-basierten TI-Identitäten, wie HBA und SMC-B, in Kombination mit Konnektoren, erforderlich. Das Thema der Nutzung von digitalen Identitäten für LE-DE befindet sich aktuell in einer strategischen Abstimmung mit den Gesellschaftern, sodass derzeit keine projizierte Bereitstellung von hardware-unabhängigen digitalen Identitäten bekannt ist.

Ein weiterer entscheidender Faktor ist die zeitliche Verzögerung, die durch die verspätete Integration der genannten Leistungsmerkmale der TI 2.0 entstehen würde. Diese Verzögerung würde den geplanten Go-Live des Anwendungsszenarios ePeD-B gefährden und damit die Einhaltung der Frist für die Inbetriebnahme der grenzüberschreitenden eHealth-Dienste gemäß EHDS-Verordnung unmöglich machen. Gemäß der EHDS-Verordnung müssen alle EU-Mitgliedstaaten spätestens bis 26.03.2029 mit den relevanten grenzüberschreitenden eHealth-Diensten der ersten prioritären Kategorien einschließlich ePeD-B produktiv verfügbar sein.

Aufgrund dieser Einschränkungen muss das Anwendungsszenario ePeD-B zunächst auf Basis einer Integration in die Telematikinfrastruktur 1.0 umgesetzt werden. Diese Entscheidung stellt sicher, dass die Anforderungen an die sichere Authentisierung und Kommunikation erfüllt werden können und der Go-Live des Szenarios innerhalb der vorgegebenen Frist erfolgt.

6.2 Ausblick

Im Rahmen der zukünftigen Weiterentwicklung des Anwendungsszenarios ePrescription/eDispensation Land B werden Maßnahmen vorgesehen, die eine Erweiterung der Funktionalitäten sowie eine Optimierung der bestehenden Prozesse ermöglichen sollen. Diese Maßnahmen zielen darauf ab, die Integration in die TI 2.0 zu ermöglichen, die User Experience zu steigern und die Sicherheit der Systeme weiter zu erhöhen. Im Folgenden werden zentrale Themen und potenzielle Features beschrieben, die in späteren Ausbaustufen umgesetzt werden könnten:

• Umzug in die TI 2.0 mit Integration des ZETA Clients in das EU-Webportal, Absicherung durch ZETA Guard sowie Nutzung der Zero Trust Architektur:
  Die Integration von ZETA Client und die Client-Attestierung in Webportalen ist für frühestens 2027 geplant. Die Implementierung dieser Funktion für Land B Anwendungsszenarien soll den Zugriff auf den NCPeH-Proxy durch die Einführung von ZETA Guard sichern. Diese Sicherheitslösung gewährleistet einen robusten und zuverlässigen Schutz der Schnittstellen und schützt sensible Daten vor unbefugtem Zugriff.
• Integration des Anwendungsszenarios ePeD-B in das AVS:
  Die  direkte Integration von ePeD-B in das AVS soll die nahtlose Aufnahme europäischer E-Rezepte und die Erstellung von Dispensierinformationen ermöglichen, sowie die leichtere Nutzung des Warenwirtschaftssystems. Dazu gehört auch die Definition und Verarbeitung von Datenformaten für E-Rezepte und Dispensierinformationen.
• Einsatz der Wallet-Lösung für Identity Management:
  Um alternative Authentisierungsmöglichkeiten für Leistungserbringer und ihre Gehilfen zu schaffen, wird die Integration von Wallet-Lösungen in Betracht gezogen. Die Einführung der Wallet-Lösung kann die Akzeptanz und Nutzbarkeit der Land-B Anwendungsszenarien erheblich steigern, gleichzeitig die Diversität der Authentisierungsoptionen erweitern und die Abhängigkeit zu Konnektoren lösen.
  

7 Fachliches Konzept

Der Ablauf des Anwendungsszenarios ist mithilfe des Sequenzdiagramms in folgender Abbildung verbildlicht.

Abbildung 11: Sequenzdiagramm des Anwendungsszenarios ("Main-Flow")

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/overview/main-flow-tech-seq.svg 

7.1 Authentifizierung und Autorisierung des LE-DE

Der Zugriff auf das Anwendungsszenario ePrescription/eDispensation Land B (ePeD-B) und damit auf die E-Rezepte von EU-Bürgern über das EU-Webportal ist ausschließlich nach erfolgreicher Authentifizierung des LE-DE und seiner Institution (LEI-DE) möglich. Für die Durchführung der Authentisierung sind sowohl der Heilberufsausweis (HBA) des LE-DE als auch die SMC-B der LEI-DE erforderlich. Beide Smartcards müssen über den konfigurierten Konnektor oder TI-Gateway erreichbar sein, wobei sich die SMC-B-Karte im freigeschalteten Modus befinden muss. Zusätzlich muss auf dem Rechner des LE-DE, neben einem modernen Webbrowser, die Authentisierungssoftware (gematik-Authenticator) installiert und korrekt konfiguriert sein, sodass sie den Konnektor oder TI-Gateway sowie die Smartcards ansprechen kann.

Die Authentisierung wird durch den LE-DE initiiert, indem er sich über seinen Webbrowser am EU-Webportal anmeldet. Die Kommunikation mit dem zentralen IDP-Dienst und die Durchführung der Authentisierung erfolgt durch den gematik-Authenticator. Dabei wird das OIDC-Protokoll mit Authorization Code-Flow verwendet. Für die Bestätigung der TI-Identitäten gemäß den Anforderungen der eHDSI ist es erforderlich, sowohl den HBA des LE-DE (z.B. Name, Rolle, Identifier) als auch die SMC-B der LEI-DE (Bezeichnung, Typ, Identifier) einzubinden. Im Rahmen des Authentisierungsprozesses kann es erforderlich sein, dass der LE-DE die PIN seiner HBA-Karte am angeschlossenen Kartenterminal eingibt.

Nach erfolgreicher Authentifizierung stellt der IDP-Dienst dem gematik-Authenticator für die Identitäten der Smartcards jeweils einen Authorization Code aus. Diese Codes werden an den NCPeH-Proxy, genauer gesagt an dessen Authorization Service, weitergeleitet. Der Authorization Service tritt gegenüber dem zentralen IDP-Dienst als Client für die Durchführung der PKCE-Challenge auf. Dieser tauscht die Codes beim IDP-Dienst gegen ID-Tokens ein. Die ID-Tokens enthalten die relevanten Identitätsattribute (Claims), die im späteren Verlauf insbesondere für den Zugriff auf das Anwendungsszenario ePeD-B vom NCPeH-FD innerhalb der eHDSI benötigt werden.

Anhand der gewonnenen Identitätsinformationen überprüft der NCPeH-Proxy die Rolle des LE-DE und stellt sicher, dass diese gemäß nationalen Vorgaben für den Zugriff auf das Anwendungsszenario ePeD-B berechtigt ist. Nach der abschließenden Überprüfung der Zugriffsberechtigung wird dem EU-Webportal das Ergebnis der Autorisierung als ncpehprx_access_token zu Verfügung gestellt, welcher vom EU-Webportal für alle nachfolgenden Anfragen an den NCPeH-Proxy gesendet wird.

Der ncpehprx_access_token ist nur kurzzeitig gültig. Eine bedarfsgerechte Verlängerung ist über den Refresh-Token-Mechanismus in Anlehnung an die eHDSI‑Vorgaben zur Identity Assertion eines LE‑DE (siehe [eHDSI_SAML_Profile]) innerhalb von 4 Stunden möglich.

Der LE-DE hat die Möglichkeit, die Session jederzeit über das EU-Webportal manuell zu beenden, wodurch er sich aus dem EU-Webportal abmeldet.

7.2 Information der Betroffenen über ihre Rechte und Pflichten zum Schutz ihrer personenbezogenen und gesundheitlichen Daten

Im Rahmen des Anwendungsszenarios ePrescription/eDispensation Land B ist es wichtig, dass EU-Bürger eine Möglichkeit haben, sich vor jeglichem Zugriff auf ihre personenbezogenen Daten, der Verarbeitung oder der Dispensierung ihrer E-Rezepte über ihre Rechte und Pflichten zum Schutz ihrer personenbezogenen und gesundheitlichen Daten zu informieren.

Der LE-DE muss dem EU-Bürger Informationen über die relevanten Datenschutzbestimmungen und den Schutz seiner persönlichen und gesundheitlichen Daten zur Verfügung stellen. Hierzu kann der LE-DE im EU-Webportal auf eine zentrale Website (siehe [MyHealth@EU_Cross-Border_Health_Services]) weitergeletet, die von der Europäischen Kommission bereitgestellt wird.

Auf dieser Website werden für das Anwendungsszenario ePrescription/eDispensation in Deutschland als Land B vom Anbieter des NCPeH-FD Übersetzungen des Dokuments Patient Information Notice (PIN-Dokument) in verschiedenen europäischen Sprachen zur Verfügung gestellt. Das PIN-Dokument enthält detaillierte Informationen über die Rechte und Pflichten des EU-Bürgers sowie über die Art und Ort der Verarbeitung seiner Daten im Rahmen des grenzüberschreitenden Dienstes. Der LE-DE kann das entsprechende PIN-Dokument in der Sprache des Zugehörigkeitslandes des EU-Bürgers auswählen und bei Bedarf ausdrucken. Alternativ kann der LE-DE den Link zur Website oder direkt zum entsprechenden PIN-Dokument vom EU-Webportal aus digital an den EU-Bürger bereitstellen, z. B. in Form eines QR-Codes.

Darüber hinaus kann sich der LE-DE bei eigenem Interesse über seine eigenen Rechte und Pflichten sowie über die Verantwortlichkeiten der beteiligten Stellen informieren. Hierzu kann er im EU-Webportal auf eine andere externe Website oder Ressource zugreifen, die vom Anbieter des NCPeH-FD bereitgestellt wird. Auf der Webseite kann der LE-DE die Informationen in deutscher Sprache finden.

7.3 Identifikation des EU-Bürgers in der Apotheke vor Ort

Der autorisierte LE-EU wählt im EU-Webportal das Zugehörigkeitsland des EU-Bürgers (Land A) und die Anwendung ePrescription aus. Anschließend wird im EU-Webportal die passende internationale Suchmaske (International Search Mask) angezeigt, die vom Land A definiert und bereitgestellt wird.

Die Suchmaske wird vom Land A definiert, um die Identifikation seiner Bürger im Ausland und ggf. den Zugriff auf ihre Dokumente gemäß den jeweiligen nationalen Richtlinien im Land A zu ermöglichen. Die Verantwortung für die Pflege und Aktualisierung der Suchmaske sowie deren Veröffentlichung über den zentralen eHDSI-Configuration Service liegt vollständig bei Land A. Der NCPeH-FD kann die aktuelle Version der Suchmaske für das Land A über die Mechanismen des zentralen eHDSI-Dienstes abrufen und auf Anfrage dem EU-Webportal zur Verfügung stellen. 

Die Suchmaske kann ein oder mehrere Eingabefelder enthalten. Die Beschriftungen der Eingabefelder werden im EU-Webportal in deutscher Sprache angezeigt. In die Eingabefelder kann der LE-DE die vom EU-Bürger bereitgestellten Identitätsmerkmale und ggf. Zugriffsinformationen für Dokumentensuche manuell eingeben. Nach Eingabe und Bestätigung durch den LE-DE wird eine Anfrage mit den eingegebenen Identitätsmerkmalen zur Validierung sowie zur Ermittlung weiterer demographischer Daten des EU-Bürgers an den NCPeH-Proxy gestellt.

Die gesendete Anfrage des LE-DE enthält neben den Suchparametern auch den ncpehprx_access_token, der im Rahmen des Kapitel 7.1 Authentifizierung und Autorisierung des LE-DE erstellt wurde. Der NCPeH-Proxy prüft die Anfrage auf Vollständigkeit und Gültigkeit, insbesondere die Validität des ncpehprx_access_tokens. Nach erfolgreicher Prüfung ermittelt der NCPeH-Proxy die an die Session gebundenen und vom IDP-Dienst bestätigten Identitätsattribute des LE-DE und der LEI-DE. Diese Identitätsattribute werden zusammen mit den relevanten Daten aus der Anfrage des LE-DE an den NCPeH-FD weitergeleitet.

Der NCPeH-FD übernimmt die Überführung der Identitätsattribute des LE-DE und der LEI-DE in das SAML2.0-Format gemäß den Vorgaben der eHDSI. Dabei wird eine Identity Assertion erstellt, die die Echtheit der Identitäten des LE-DE und der LEI-DE bestätigt. Basierend auf den vom LE-DE über die Suchmaske des Land A eingegebenen Suchparametern erzeugt und stellt der NCPeH-FD an den NCPeH Land A die Suchanfrage inklusive der zuvor erstellten Identity Assertion zur Ermittlung von weiteren demographischen Daten des EU-Bürgers.

Im Erfolgsfall antwortet Land A mit zusätzlichen demographischen Daten und bestätigt gleichzeitig die eindeutige Identitätskennung des EU-Bürgers. Diese Daten werden dem LE-DE im EU-Webportal angezeigt. Basierend auf den bereitgestellten demographischen Daten führt der LE-DE die Identifikation des EU-Bürgers mithilfe eines von diesem vorgelegten Dokuments (z.B. Reisepass) durch.

Die eindeutige Identitätskennung des EU-Bürgers wird für nachfolgende Transaktionen benötigt, z.B. für den Abruf und die eindeutige Ermittlung von E-Rezepten des EU-Bürgers.

Möchte der LE-DE demographischen Daten für denselben EU-Bürger erneut abrufen, dann ist der Inhalt der Suchmaske mit den zuvor eingegebenen Daten vorausgefüllt.

Wenn der LE-DE demographische Daten für einen anderen EU-Bürger abrufen möchte, würden die vom LE-DE in die Suchmaske eingegebenen Identitätsmerkmale und die bereits abgerufenen demographischen Daten im EU-Webportal verworfen und dem LE-DE würde je nach seiner Wahl entweder eine leere Suchmaske für Land A oder die vollständige Übersicht über die EU-Länder angezeigt werden.

Zur Unterstützung des LE-DE bei der Identifikation des EU-Bürgers kann die Suchmaske ergänzende Begleitinformationen, wie erläuternde Texte oder Abbildungen, enthalten. Diese Informationen bieten dem LE-DE zusätzliche Hilfestellung und erleichtern die Identifikation durch visuelle und inhaltliche Veranschaulichungen. Der Zugriff auf diese Begleitinformationen erfolgt optional und kann bei Bedarf vom LE-DE angefordert werden.

7.4 Übersicht über die einlösbaren E-Rezepte eines EU-Bürgers

Der autorisierte LE-DE kann eine Übersicht über die einlösbaren E-Rezepte eines EU-Bürgers abrufen, nachdem die demographischen Daten des EU-Bürgers abgerufen wurden und dessen eindeutige Identitätskennung vom Land A bestätigt wurde. Der LE-DE bestätigt im EU-Webportal die Behandlungsbeziehung zum EU-Bürger gemäß den Anforderungen der eHDSI.

Die gesendete Anfrage des LE-DE über das EU-Webportal an den NCPeH-Proxy enthält die eindeutige Identitätskennung des EU-Bürgers, gegebenenfalls zusätzliche Zugriffsinformationen für die Dokumentensuche (siehe 7.3 Identifikation des EU-Bürgers in der Apotheke vor Ort), die vom Land A für den Zugriff auf die E-Rezepte verlangt werden, sowie den ncpehprx_access_token, der im Rahmen des Kapitel 7.1 Authentifizierung und Autorisierung des LE-DE erstellt wurde. Nach erfolgreicher Validierung der Anfrage ermittelt der NCPeH-Proxy die an die Session gebundenen und vom IDP-Dienst bestätigten Identitätsattribute des LE-DE und der LEI-DE. Diese Identitätsattribute werden zusammen mit den relevanten Daten der Anfrage an den NCPeH-FD weitergeleitet.

Der NCPeH-FD erstellt eine SAML2.0 TRC-Assertion gemäß den Vorgaben der eHDSI, die das Behandlungsverhältnis zwischen LE-DE und dem EU-Bürger bestätigt. Der NCPeH-FD sendet die Anfrage zur Auflistung von einlösbaren E-Rezepten zusammen mit der TRC-Assertion und der bereits in 7.3 Identifikation des EU-Bürgers in der Apotheke vor Ort erstellten Identity Assertion an den NCPeH Land A.

Der NCPeH Land A ermittelt die relevanten Metainformationen zu den einlösbaren E-Rezepten des EU-Bürgers und übermittelt diese an den NCPeH-FD. Die Metainformationen enthalten wichtige Angaben zu den einzelnen E-Rezepten, wie z. B. die E-Rezept-ID, den Wirkstoff, die Dosierung und andere relevante Metainformationen, enhalten nicht vollständige Angaben zu den E-Rezepten.

Falls die Metainformationen kodiert sind (z. B. Wirkstoffbezeichnungen), transkodiert der NCPeH-FD diese gemäß den Mappingregeln des BfArM ins Deutsche. Die transkodierten Metainformationen werden anschließend an den NCPeH-Proxy weitergeleitet, der sie an das EU-Webportal übermittelt. Dort werden die Metainformationen strukturiert und übersichtlich dargestellt. Die Übersicht über die E-Rezepte des EU-Bürgers kann auch nicht einlösbare E-Rezepte enthalten, sofern diese vom Land A mit ausgegeben werden.

Die Auflistung von Metainformationen der E-Rezepte bietet für die einlösbaren E-Rezepte zusätzlich folgende Optionen für den nachfolgenden Rezeptabruf (Kapitel 7.5 Abruf von einlösbaren E-Rezepten eines E-Bürgers ):

• Kodierte Darstellung auf Deutsch:
  Der LE-DE kann den Inhalt des E-Rezepts in kodierter Form und auf Deutsch anzeigen lassen.
• Nicht kodierte Darstellung im PDF/A-Format:
  Alternativ kann der LE-DE das E-Rezept im PDF/A-Format anzeigen lassen. In diesem Fall wird der Inhalt des E-Rezepts in der Sprache des Land A dargestellt und steht nicht in deutscher Sprache zur Verfügung.

7.5 Abruf von einlösbaren E-Rezepten eines E-Bürgers

Der autorisierte LE-DE hat die Möglichkeit, im EU-Webportal mehrere einlösbare E-Rezepte eines EU-Bürgers auszuwählen, um deren vollständigen Inhalt aus Land A abzurufen und anzeigen zu lassen. Der Abruf der ausgewählten E-Rezepte erfolgt über denselben technischen Weg, wie im Kapitel 7.4 Übersicht über die einlösbaren E-Rezepte eines EU-Bürgers beschrieben. Dabei werden die E-Rezepte durch den NCPeH-FD vom Land A abgerufen und über den NCPeH-Proxy an das EU-Webportal bereitgestellt.

Nach erfolgreicher Bereitstellung der E-Rezepte im EU-Webportal werden die vollständigen Inhalte der E-Rezepte dem LE-DE strukturiert und in kodierter Form auf Deutsch angezeigt. 

Zusätzlich hat der LE-DE die Möglichkeit, sich das Originalrezept des abgerufenen E-Rezepts des EU-Bürgers im EU-Webportal anzeigen zu lassen. Das Originalrezept wird im PDF/A-Format dargestellt und enthält den Inhalt des E-Rezepts in der Sprache des Land-A. Eine Übersetzung ins Deutsche ist bei der Anzeige des Originalrezepts nicht vorgesehen. Der LE-DE kann das Originalrezept bei Bedarf herunterladen und lokal auf seinem Rechner abspeichern, um es für Dokumentationszwecke zu verwenden.

7.6 Einlösung von E-Rezepten eines EU-Bürgers

Nach erfolgreichem Abruf der E-Rezepte eines EU-Bürgers muss der autorisierte LE-DE für jedes eingelöste E-Rezept eine Dispensierinformation an das Land A übermitteln, um den EU-Workflow gemäß den Vorgaben korrekt durchzuführen. Dazu wählt der LE-DE im EU-Webportal jedes einzulösende E-Rezepte aus, um für diese passende Dispensierinformationen zu erfassen.

Der LE-DE erfasst alle relevanten Angaben inkl. der Pharmazentralnummern (PZN) zur Abgabe des Medikaments. Falls ein Produkt substituiert wurde, kann der LE-DE in den Dispensierinformationen die Substitution einschließlich der Angaben zum substituierten Produkt angeben.

Der LE-DE hat die Möglichkeit, den Vorgang der Dispensierung jederzeit abzubrechen, entweder auf eigenen Wunsch oder auf Wunsch des EU-Bürgers. Falls der Vorgang ohne Übermittlung der Dispensierinformationen beendet werden soll, zeigt das EU-Webportal eine Warnung an, um den LE-DE auf die fehlende Übermittlung hinzuweisen. Der LE-DE kann in diesem Fall den Vorgang wieder aufnehmen und die offenen Dispensierinformationen vervollständigen.

Nach erfolgreicher Übermittlung der Dispensierinformationen an Land A erhält der LE-DE eine Erfolgsmeldung im EU-Webportal, die den Abschluss des Dispensiervorgangs bestätigt. Anschließend kann der LE-DE entscheiden, ob weitere E-Rezepte des EU-Bürgers dispensiert werden sollen oder ob die Bedienung des EU-Bürgers damit abgeschlossen ist.

Falls der LE-DE die Einlösung weiterer E-Rezepte des EU-Bürgers vornehmen möchte, wählt er im EU-Webportal den Vorgang gemäß dem Kapitel 7.4 Übersicht über die einlösbaren E-Rezepte eines EU-Bürgers aus. Die Rezeptliste wird dann auf Basis einer erneuten Suche angezeigt und der LE-DE kann weitere E-Rezepte auswählen und dispensieren.

Wenn der LE-DE E-Rezepte eines anderen EU-Bürgers abrufen möchte, dann wählt er im EU-Webportal den Vorgang gemäß dem Kapitel 7.3 Identifikation des EU-Bürgers in der Apotheke vor Ort und beginnt damit den Prozess von Neuem. Die personenbezogenen und E-Rezept-Daten des nicht mehr bedienten EU-Bürgers sind im EU-Webportal nicht mehr vorhanden. 

8 Technisches Konzept

Dieses Kapitel beschreibt das technische Konzept für das Anwendungsszenario ePeD‑B und strukturiert den zugrunde liegenden Lösungsraum in die dafür erforderlichen Systeme. Ziel ist es, einen Überblick über den technischen Aufbau, die Verantwortlichkeiten der beteiligten Komponenten sowie deren Zusammenspiel zu vermitteln.

Hierzu werden die technischen Systeme wie das EU‑Webportal, der NCPeH‑Proxy und der NCPeH‑FD vorgestellt. Das Kapitel beschreibt, wie die Systeme erreicht werden, welche Webschnittstellen sie bereitstellen und wie diese aus technischer und fachlicher Sicht genutzt werden.

Darüber hinaus werden die zugrunde liegenden Informationsmodelle vorgestellt, die als Bestandteil der Nachrichten zwischen den Systemen ausgetauscht werden. Abschließend werden die Abläufe der einzelnen Anwendungsfälle detailliert beschrieben und anhand von Sequenzdiagrammen nachvollziehbar dargestellt, um das Zusammenwirken der Systeme transparent zu machen.

8.1 EU-Webportal

Das EU-Webportal besteht aus folgenden Komponenten:

1. Einer clientseitigen WebApp (client-side WebApp)
2. Einem Webserver, welcher die WebApp ausliefert und Nutzungsregeln für diese definiert.

Definition: clientseitige WebApp

Eine clientseitige WebApp im Sinne dieses Konzepts wird wie folgt definiert:

• Bestandteile (Quellcode, Business-Logik, Libraries, statischer Content usw.) zur Nutzung des ePeD-B Szenarios werden vollständig in den Browser des LE-DE geladen und durch die WebApp selbst verarbeitet.
• Durch den Aufruf per Link bzw. URL-Eingabe im bereits vorinstallierten Standard-Browser beim LE-DE wird die WebApp (als Ganzes (Startseite und Bundles) geladen, dort automatisch aufgerufen und gestartet. Der Start passiert im selben Tab, mit welchem der Link geöffnet wurde (vergleichbar mit dem Aufruf einer Website).
• Das GUI der WebApp wird nicht nur im Browser angezeigt, sondern auch vollständig dort gerendert. Es findet keine Pre-Renderung auf dem Webserver statt.
• Die WebApp setzt sich selbst aus Subkomponenten für die Darstellung des GUI (z.B. Widgets, Boxen, Tabellen, Layouts, Formatanweisungen), dessen Rendering und Navigation zusammen. Weiterhin gibt es zur Ablaufsteuerung Subkomponenten für die Zustandsverwaltung, ASL-Kanal und API-Zugriff.
• Die Session-Verwaltung inkl. User-Identifikation erfolgt über OAuth2 Access-Tokens gemäß RFC 6749.
• Die WebApp muss nicht durch den User konfiguriert werden. Die Konfiguration wird durch den Lade- und Startvorgang automatisch ausgeführt.
• Der Login wird unter Verwendung des Authenticators durchgeführt, der auf demselben Arbeitsplatz-PC des LE-DE installiert ist. 
• Persönliche medizinische Daten werden über einen ASL-Kanal Ende-zu-Ende verschlüsselt.
• Es gelten die in Abschnitt 8.1.3 Sichere Auslieferung der WebApp-Bestandteile durch den Webserver beschrieben Sicherungsmaßnahmen für die WebApp.

Folgende Abbildung fasst den Aufbau und die Nutzung der WebApp des EU-Webportals zusammen:

Abbildung 12: Aufbau und Nutzung der WebApp-Komponente

8.1.1 Zugang zum EU-Webportal

Der Zugang zum EU-Webportal erfolgt für die Nutzer über ihren lokal installierten Webbrowser. Die Verbindung zum Webserver des EU-Webportals wird über das Internet hergestellt. Die initiale Verbindung wird zwischen dem Browser und dem EU-Webportal mittels TLS v1.2 oder v1.3 abgesichert.

Nach dem erfolgreichen Verbindungsaufbau lädt der Browser eine WebApp herunter, die direkt im Webbrowser des LE-DE ausgeführt wird. Die WebApp ist eine dynamische Anwendung, über die das Rendering der Webinhalte sowie die Durchführung weiterer Aufrufe und Datenverarbeitungen erfolgt. Die WebApp im Browser stellt die Nutzerschnittstelle zwischen dem LE-DE und den Funktionalitäten des Anwendungsszenarios ePeD-B dar und ermöglicht eine interaktive Nutzung der angebotenen Dienste bzw. Workflows.

Die Authentisierung des LE-DE wird von der WebApp initiiert, sobald der LE-DE eine entsprechende Anfrage stellt. Dabei wird der lokal installierte gematik Authenticator über einen parametrisierten Deeplink aufgerufen. Der gematik Authenticator übernimmt die Authentisierung des LE-DE und seiner Institution (LEI-DE) mittels der HBA und der SMC-B. Zu diesem Zweck muss der gematik Authenticator die zugelassene dezentrale Komponente Konnektor oder TI-Gateway aufrufen können.

8.1.2 Schnittstellen

Tabelle 1: Funktionale Schnittstellen und Operationen des EU-Webportals

Bestimmte API-Calls der WebApp werden nicht durch den einen zusätzlichen ASL-Kanal verschlüsselt und benutzen somit nicht I_Comm_ASL, da hier keine personenbezogenen medizinischen Daten übertragen werden. Stattdessen nutzen sie gewöhnlicher HTTP-Requests/-Responses in einem TLS-Kanal zwischen der WebApp und dem NCPeH-Proxy.

Diese Aufrufe durch die WebApp an folgenden Schnittstellen benutzen nicht I_Comm_ASL:

• I_Authorization (alle mit Authentifizierung des LE-DE gemäß 8.5.2.1 Authentifizierung und Autorisierung des LE-DE befassten Endpoints)
• I_ISM_Service

8.1.2.1 I_Provide_WebApp

Diese Outbound HTTPS-Schnittstelle des Webservers ist read-only und verfügt über einen öffentliche URL an einer noch festzulegenden und zu registrierenden Domain, die eigens für das EU-Webportal vorgesehen ist. Bei Aufruf der Schnittstelle werden alle WebApp-Bestandteile in den Browser geladen, wodurch die WebApp lauffähig in der lokalen Sandbox des Browsers des LE-DE ist.

8.1.2.2 I_WebApp_Deployment

Diese Inbound Schnittstelle des Webservers empfängt neue Versionen der WebApp und legt sie in einem dafür vorgesehenen lokalen Webserver-Pfad ab. Die Schnittstelle ist als Ende (Deployment-Target) einer Build/Deployment-Pipeline gedacht, daher wird das Protokoll für Inbound-Anfragen hier nicht festgelegt.

8.1.2.3 I_Comm_ASL

Zwischen der WebApp und dem VAU-Verarbeitungskontext des NCPeH-FD wird ein logischer Ende-zu-Ende-Kanal für die Inhaltsverschlüsselung aufgebaut, der durch das ASL-Protokoll realisiert wird. Der NCPeH-FD agiert dabei in der Rolle als ASL-Server und implementiert den Endpoint /ASL gemäß den Vorgaben aus [gemSpec_Krypt#ZETA/ASL (VAU-Protokoll)], während die WebApp des EU-Webportals die Rolle des ASL-Clients einnimmt.

Da die TLS-Verbindungen an den jeweiligen Komponenten enden, wird die Vertraulichkeit der Inhalte (Payload) mittels des ASL-Protokolls auf der Anwendungsebene durch eine Ende-zu-Ende Verschlüsselungsschicht zusätzlich abgesichert. Das ASL-Protokoll ermöglicht diese Ende-zu-Ende-Inhaltsverschlüsselung zwischen der Webapp und dem VAU-Verarbeitungskontext des NCPeH-FD. Dadurch wird sichergestellt, dass die Inhalte selbst innerhalb des NCPH-Proxys oder der Webschnittstelle des NCPeH-FD nicht im Klartext vorliegen.

Zum Aufbau der zusätzlichen Verschlüsselungsschicht ist ein zusätzlicher Handshake auf Protokollebene notwendig, welcher in 8.5.2.2 Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD beschrieben ist. Während originäres KEM-TLS, auf welchem das ASL-Protokoll aufbaut, eine Modifikation des TLS-Protokolls auf OSI-Schicht 6/7 darstellt, agiert das ASL-Protokoll gemäß [gemSpec_Krypt#ZETA/ASL (VAU-Protokoll)] nur auf der OSI-Schicht 7. ASL tunnelt seine Handshake-Nachrichten als HTTP-Payloads über eine bereits existierende TLS-Verbindung. Die 24h-Löschfrist (und Neuaushandlung) der im Handshake ausgehandelten symmetrischen Verschlüsselungssschlüssel wird in dem hier beschriebenen ePeD-B Szenario deutlich unterschritten, da der Aufbau und die Lebensdauer eines ASL-Kanals an die kürze, personalisierte Session-Dauer eines LE-DE von 4h gebunden ist.

Diese Inbound-/Outbound-Schnittstelle ist ausschließlich für autorisierte Kommunikation des authentisierten LE-DE vorgesehen, vgl. dazu 8.5.2.3 Nutzung einer autorisierten Verbindung zum NCPeH-FD.

8.1.2.4 I_User_Interaction

Der LE-DE sieht das grafische Frontend der WebApp im Browser und interagiert damit (Maus- und Tastatureingaben). Es ist ein separater [Figma-Clickdummy] für diese Schnittstelle vorhanden.

8.1.3 Sichere Auslieferung der WebApp-Bestandteile durch den Webserver

Da die WebApp vollständig im Browser abläuft, findet kein Rendering und keine Vorverarbeitung auf dem Webserver statt. Stattdessen nimmt der Webserver die Rolle eines Content Delivery Edge-Nodes ein, der dafür optimiert ist, die Bestandteile der WebApp zügig an den Anfragenden (den LE-DE) auszuliefern. Daher ist von entscheidender Bedeutung, dass die Bestandteile der WebApp bei der Auslieferung stets authentisch und aktuell sind. Um das zu erreichen, werden folgende Mechanismen und Techniken eingesetzt.

Einsatz von HTTP Strict Transport Security (HSTS)
Der Webserver zwingt den Browser vor dem Laden der WebApp eine ausschließlich verschlüsselte Verbindung zur Domain mit dem Aufruf-Endpoint der WebApp aufzubauen.

Verwendung von CSP-Response-Header
Der Webserver gibt der WebApp eine strikte Content Security Policy (CSP) aus, die verhindert, dass App-fremde Inhalte nach- oder von der Seite geladen werden. In den Directiven der Policy wird festgelegt, dass WebApp-Bestandteile nur vom Webserver selbst geladen werden dürfen (z.B. Direktive script-src 'self' für clientseitige Skripte).

SRI-Tags für kritische und aktive WebApp-Bestandteile
Mindestens alle Laufzeit-Bestandteile, Libraries und Links zu anderen Bestandteilen der WebApp werden mit Subresource Integrity Tags (SRI-Tags) ausgestattet. Der Browser als Laufzeitumgebung ist somit gezwungen, die Hashes in den SRI-Tags zu validieren. Die SRI-Tags selbst werden bereits während des Build-Prozesses der WebApp erzeugt. Eine notwendige Aktivierung von Cross Origin Resource Sharing (CORS) für diese WebApp-Bestandteile kann zugunsten der SRI-Tags hingenommen werden.

Komponenten-Hashes für jeden Build
Mit jedem Build und anschließendem Deployment/Bereitstellen der WebApp auf dem Webserver werden explizite Hashes für die Komponenten/Resources der WebApp gebildet und am Aufruf dieser attributiert. Gleichzeitig erfolgt der Build für die WebApp ausschließlich aus einem eigenes dafür vorgesehenen Repository, dessen Deployment-Ziel der Aufruf-Endpoint der WebApp auf dem Webserver ist. Durch den Build werden einzigartige Deployment-Artefakte erzeugt, als Bundle zusammengefasst und auf dem Webserver hinterlegt (sog. Immutable Deployment).

Clientseitige und serverseitige SBOM mit inkludierten Komponenten-Hashes
Für alle Bestandteile der WebApp wird durch den Build-Prozess der WebApp zwei SBOMs erstellt, von denen eine Fassung gemeinsam mit der WebApp über I_Provide_WebApp ausgeliefert wird und die andere Fassung serverseitig (am NCPeH-Proxy) hinterlegt wird. Bei Requests durch die WebApp werden vorab alle Elemente der SBOM anhand ihrer Hashes gegen die serverseitige Fassung anhand einer dort hinterlegten Policy auf Identität geprüft. Nur bei vollständiger Identität werden die Client-Requests folgeverarbeitet. Die zwei SBOM-Fassungen haben unterschiedlichen Umfang:

• Die reduzierte Fassung in der WebApp enthält eindeutige Package-Bezeichner für jedes Package, dessen jeweiliger Hash und einen vollständigen Dependency-Tree.
• Die volle Fassung am NCPeH-Proxy enthält neben den Inhalten des Client-SBOM auch Zusatzinformationen wie Komponentenname, Version, Lizenz und Lieferquelle.

Durch die beschriebenen Mechanismen wird sichergestellt, dass nur solche Client-Komponenten mit dem Proxy interagieren, die durch den Aussteller der WebApp im Bereitstellungsprozess selbst für gültig und berechtigt erklärt worden sind.

Darüber hinaus sorgt der Webserver durch entsprechende Konfiguration dafür, dass das Caching bestimmter WebApp-Bestandteile unterdrückt wird.

8.1.4 Ausblick

Weitere Anwendungsszenarien nach ePeD-B könnten über separate, Szenario-spezifische clientseitige WebApps über andere Endpoints des Webservers am EU-Webportal ausgeliefert werden. Eine zwingende Notwendigkeit, alle Szenarien in einer gemeinsamen WebApp auszuliefern, besteht nicht. Das ePeD-B Szenario ist auf den sehr speziellen Bedarf von Apothekern zugeschnitten, daher können dedizierte WebApps für andere diffizile Nutzergruppen sinnvoll sein und werden hier nicht ausgeschlossen.

8.2 NCPeH-Proxy

Der NCPeH-Proxy besteht aus folgenden Komponenten:

1. HTTP-Proxy, durch welchen sämtlicher Traffic zwischen der clientseitigen WebApp des EU-Webportals und dem NCPeH-FD vermittelt wird.
2. Authorization-Service (aka. "Auth-Service"), welcher exklusiv für die NCPeH-Land-B Domäne Autorisierungsdienstleistungen erbringt. Zu diesen Autorisierungsdienstleistungen gehören insbesondere
• Herausgabe signierter ID- und Access-Tokens mit bestimmten Claims auf der Grundlage von definierbaren und definierten Authentisierungsmitteln
• Umtausch von gültigen Tokens von Upstream-IDPs in eigene Tokens mit lokalem, eigen-definierten Scope

8.2.1 Zugang zum NCPeH-Proxy

Der NCPeH-Proxy ist ausschließlich über TLS-gesicherte RESTful Schnittstellen mittels eines dedizierten FQDN über das Internet zugänglich und wird durch API-Calls der WebApp des EU-Webportals genutzt. Dabei ist die Identität und Validität des FQDN durch ein End-Entity-Zertifikat prüfbar, welches von einer CA ausgestellt wurde, die die [Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates] erfüllt. Während der HTTP-Proxy direkt über Webschnittstellen erreichbar ist, kann der Authorization-Service nur durch vorherige Policy-basierte Erlaubnis (vgl. dazu Abschnitt 8.1.3 Sichere Auslieferung der WebApp-Bestandteile durch den Webserver und die Use Cases im Abschnitt 8.5.2 Use Cases im Rahmen der Authentifizierung, Autorisierung) mittelbar durch die WebApp genutzt werden.

8.2.2 Schnittstellen

Tabelle 2: Funktionale Schnittstellen und Operationen des NCPeH-Proxy

8.2.2.1 I_Comm_ASL

Zur grundsätzlichen Beschreibung dieser Schnittstellen sei auf den Abschnitt 8.1.2.3 I_Comm_ASL  verwiesen.

Die Rolle der HTTP-Proxy Komponente des NCPeH-Proxy an diesen beiden Schnittstellen ist es, einerseits die Gateway-Funktionen gemäß 8.2.3 API-Gateway Funktion bereitzustellen und die Use Cases entsprechend ihrer Vorgaben gemäß 8.5 Use Cases  zu verarbeiten andererseits. 

8.2.2.2 I_Authorization

Diese Schnittstelle ist Bestandteil der in Abschnitt 8.2.5 Authentifizierung und Autorisierung beschriebenen Funktionalität.

8.2.2.3 I_Identification

Diese Schnittstelle ist Bestandteil der in Abschnitt 8.2.5 Authentifizierung und Autorisierung beschriebenen Funktionalität.

8.2.2.4 I_ISM_Service

Diese Schnittstelle vermittelt Anfragen zu Suchmasken der zulässigen Länder-A an den NCPeH-FD. Die Funktionsbeschreibung ist in Abschnitt 8.3.2.2 I_ISM_Service zu finden.

8.2.3 API-Gateway Funktion

Die HTTP-Proxy Komponente des NCPeH-Proxy ist mit einer Basis-API-Gateway Funktionalität ausgestattet, die folgendes ermöglicht:

• Anwenden und Auswerten von Gateway-Policies zu HTTP-Traffic (vgl. dazu auch Abschnitt 8.5.2.3 Nutzung einer autorisierten Verbindung zum NCPeH-FD, in welchem die Anwendung von solchen Policies skizziert ist) in Bezug auf
• Pfad-, Methoden-, Header- oder Host-basiertes Routing von eingehenden Requests an die korrekten Services bzw. APIs (als Reverse Proxy)
• Traffic-Splitting auf Basis von Header-Regeln, um z.B. neue Service-Versionen sicher ausrollen zu können
• Traffic-Modification in Bezug auf Hinzufügen/Entfernen/Anpassen von HTTP-Headern, Query-Parametern und Pfaden
• Load Balancing des Traffics auf ggf. mehrere Instanzen des NCPeH-FD oder anderer Backend-Services. Der HTTP-Proxy reagiert dabei dynamisch auf skalierende Instanzen.
• Security-Offloading
• Validierung von JWT ID-Tokens gem. [OpenID Connect Core#2] und Access-Tokens gem. [RFC 9068] sowie [RFC 7519] (vgl. dazu auch Abschnitt 8.5.2.3 Nutzung einer autorisierten Verbindung zum NCPeH-FD)
• TLS-Terminierung
• Anwendung und Auswertung von Gateway-Policies zu Web Security, insbesondere
• IP-White-/Blacklisting
• Schutz vor gängigen Angriffsvektoren
• Ermöglichen/Aufrufen von dedizierten Backend-for-Frontend-Services (BFF-Pattern analog zu [Backends for Frontends]) bzw. Delegationsmöglichkeit an diese Services, ohne selbst API-Aggregation/API-Composition Funktionalität anbieten zu müssen
• Ermöglichen und Anwenden von Resilience-Patterns
• Throttling und Rate Limiting von Requests
• Abfangen und Kompensieren von Backend-Ausfällen durch Mechanismen wie Retries und Circuit Breakern
• Context Propagation zu einem konfigurierbaren OpenTelemetry Collector inkl. Span-Erzeugung von Erzeugung und Weitergabe von Corellation-IDs.

8.2.4 Client Registrierung

Der Authorization-Service des NCPeH-Proxy tritt gegenüber dem zentralen IDP-Dient als Identity Broker für ein Anwendungsfrontend auf. Somit übernimmt der Authorization-Service die Rolle der OIDC Relying Party bzw. des OAuth2-Clients gegenüber dem IDP-Dienst. Daher benötigt der Authorization-Service eine zugewiesene client_id, um Tokens vom IDP-Dienst abfragen zu dürfen. Die zugewiesene client_id (inkl. kryptographisches Material/client_secret) wird im Authorization-Service dann als Credentials dem IDP-Dienst als IDP-Upstream-Provider für OIDC zugeordnet.

Die Zuweisung und Erhalt der client_id erfolgt einmalig und statisch und ist gemäß [gemSpec_IDP_Dienst#3.5] und [gemSpec_IDP_Dienst#A_20742] durchzuführen. Da es keinen Self-Service für die automatisierte Umsetzung des Erhalts der client_id gibt, muss der Onboarding-Prozess der gematik durchlaufen werden, die dann die client_id zuweist.

Der Scope von Tokens, der auf Basis der zugewiesenen client_id in einem Token attributiert ist und durch den IDP-Dienst herausgegen wird, ist "openid ncpeh".

8.2.5 Authentifizierung und Autorisierung

Die Authentifizierung und Autorisierung erfolgt mittels OAuth2 und OIDC am Authorization-Service sowie mittels DPoP am HTTP-Proxy über die Schnittstelle I_Authorization. Da die WebApp des EU-Webportals, die Authentifizierungskomponente (gematik Authenticator) und der Authorization-Service des NCPeH-Proxy asynchron ablaufen, müssen die Schnittstellen zum Authorization-Service einen entkoppelten, nicht sequenziellen Login unterstützen. Gleichzeitig muss der Authorization-Service selbst einen asynchronen Authentication-Flow unterstützen und intern mehrere längerlaufende Autorisierungsanfragen parallel handhaben können. Vgl. dazu 8.5.2.1 Authentifizierung und Autorisierung des LE-DE und 8.5.2.3 Nutzung einer autorisierten Verbindung zum NCPeH-FD.

Der Authentification-Flow umfasst eine Einbindung des zentralen IDP-Dienstes und die Herausgabe von Autorisierungscodes (AUTH_CODE) über die Schnittstelle I_Identification. Um dieses für die WebApp des EU-Webportals abzusichern, unterstützt der Authorization-Service PKCE-Challenges gemäß RFC 7636.

Der Authorization-Service muss in der Lage sein, OAuth2 Authorization-Codes in ID-Tokens umzuwandeln und diese anschließend über eine Exchange-Policy in systemgebundene Access-Tokens und ID-Tokens zu tauschen.

An die WebApp des EU-Webportals herausgegebene Access-Tokens müssen bei Ihrer Benutzung an ein clientseitig generiertes asymmetrisches Schlüsselpaar gebunden sein (DPoP gemäß RFC 9449).

Die API des Authorization-Service muss Konzepte für Multi-Faktor- bzw. Multi-Karten-Logins (HBA + SMC-B über ein eHealth-Kartenterminal) verarbeiten können, wobei diese Smartcards den TI-gebundenen, hardwarebasierten Vertrauensanker bilden.

8.2.5.1 Weitergabe von Identitätsattributen

Der Authorization-Service bezieht die für den in Abschnitt 8.5.2.1 Authentifizierung und Autorisierung des LE-DE  beschriebenen Use Case benötigten Identitätsattribute vom IDP-Dienst in Form zweier ID-Tokens, mappt diese und gibt diese in Form von neuen Claims in neu ausgestellten Tokens mit audience=ncpeh-fd sowie audience=eu-webportal an den NCPeH-FD bzw. die WebApp des EU-Webportals weiter.

Tabelle 3: Verwendete und vom IDP-Dienst bestätigte Identitätsattribute des HBA

Tabelle 4: Verwendete und vom IDP-Dienst bestätigte Identitätsattribute der SMC-B

Die Claims aus diesen beiden Tabellen werden gemappt auf:

• IdA_Claims in ID-Token IdA_raw (audience=ncpeh-fd)
• Disp_Claims in ID-Token euwp_id_token (audience=eu-webportal)

8.2.6 Qualitätsanforderungen an Betrieb und Infrastruktur

Die folgenden systematischen Abbildungen (SysML Requirements Diagramme) fassen die nicht-funktionalen Qualitätsanforderungen (Stereotyp "Requirement") an die Betriebs- und Infrastrukturumgebung des NCPeH-Proxy zusammen und zeigen dabei grobgranulare Lösungsansätze (Stereotyp "Element"), die in der Betriebs- und Infrastrukturumgebung umzusetzen sind.

Bei diesen Lösungsansätze wird zwischen den Typen "Cloud-native OS Feature" und "ermöglicht durch Cloud-native OS" unterschieden. Erstes besagt, dass das Lösungselement idealerweise bereits Feature bzw. Kernbestandteil der Betriebs- und Infrastrukturumgebung sein soll ("out-of-the-box"). Gleichzeitig ist die Betriebs- und Infrastrukturumgebung ein Cloud-natives "Betriebssystem" bzw. eine Cloud-native Laufzeitumgebung. Zweites besagt, dass die Cloud-native Laufzeitumgebung das Lösungselement grundsätzlich ermöglichen muss (z.B. durch einen Plugin-Mechanismus), ohne es selbst direkt bereitstellen zu müssen.

Qualitätsanforderungen an die Ausfallsicherheit der Betriebs- und Infrastrukturumgebung:

Abbildung 13: Qualitätsanforderungen an die Ausfallsicherheit der Betriebs- und Infrastrukturumgebung des NCPeH-Proxy

Qualitätsanforderungen an die Informationssicherheit der Betriebs- und Infrastrukturumgebung:

Abbildung 14: Qualitätsanforderungen an die Informationssicherheit der Betriebs- und Infrastrukturumgebung des NCPeH-Proxy

sonstige Qualitätsanforderungen an die Betriebs- und Infrastrukturumgebung:

Abbildung 15: sonstige Qualitätsanforderungen an die Betriebs- und Infrastrukturumgebung des NCPeH-Proxy

8.2.6.1 Erweiterte Anforderungen an Confidential Computing

Die im vorherigen Abschnitt beschriebenen Qualitätsanforderungen und Leistungsmerkmale an eine Betriebs- und Infrastrukturumgebung ermöglichen eine spätere Migration der beschriebenen Gesamtlösung in eine ZETA-konforme Infrastruktur, die aus den in Abschnitt 6.1 Entscheidung für die Integration von ePeD-B in die Telematikinfrastruktur 1.0 genannten Gründen zur Zeit nicht konzipiert werden kann. Gleichzeitig muss sichergestellt sein, dass diese Cloud-native Infrastruktur

• über ein zu einer VAU-Umgebung (vgl. [gemSpec_NCPeH_FD#Anforderungen an die Vertrauenswürdige Ausführungsumgebung]) äquivalentes Maß an Sicherheitsleistung hinsichtlich Vertraulichkeit verfügt,
• mit anderen TI-Services bzw. -Produkten in einer Betriebsumgebung konsolidiert werden kann, die einen vergleichbar sehr hohen Sicherheits- und Schutzbedarf aufweisen (Nutzung synergetischer Effekte hinsichtlich Ressourcennutzung/-konsolidierung einerseits und Hochskalierfähigkeit der Betriebsplattform andererseits).

Zu diesen Zwecken ist der gesamte Lösungsansatz von Healthcare Confidential Computing gemäß [gemSpec_HCC] und dessen erreichter, finaler Definitionsstand von Q3/2026 als sichere, vertrauenswürdige und Ausführungsumgebung des NCPeH-Proxy vorzusehen. Eine bereits aufgebaute (und damit verfügbare), sichere, vertrauenswürdige Ausführungsumgebung gemäß [gemSpec_HCC] ist betrieblich und infrastrukturell durch die Komponente NCPeH-Proxy nachzunutzen bzw. mitzubenutzen.

Fallback

Aus folgenden Unwägbarkeiten heraus ist es nicht ausschließbar, dass die in den vorherigen Absätzen beschriebene, favorisierte Lösung für die sichere, vertrauenswürdige Ausführungsumgebung nicht oder noch nicht eingesetzt werden kann:

• projektplanerische Machbarkeit (inkl. Zeit-/Terminzielen, Abhängigkeiten),
• Auswertungsergebnisse von parallel stattfindender Markterkundung,
• Festlegungen zur Betreiberrolle.

Beim Eintreten einer solchen Unwägbarkeit sind zwei Fallback-Alternativen vorgesehen für sichere, vertrauenswürdige Ausführungsumgebungen (aufgelistet in der Reihenfolge der Machbarkeit):

1. Nachnutzung der VAU-Betriebsumgebung des NCPeH-FD, womit ein Wechsel des Anforderunghaushaltes von [gemSpec_HCC] hin zu [gemSpec_NCPeH_FD#Anforderungen an die Vertrauenswürdige Ausführungsumgebung] bzgl. der geforderten Sicherheitsleistung verbunden ist.
2. Aufbau, Betrieb und Nutzung einer neuen, eigens umzusetzenden sicheren, vertrauenswürdigen Ausführungsumgebung gemäß [gemSpec_HCC]. Hiermit ist kein Wechsel des Anforderungshaushaltes verbunden.

Zu betonen ist, dass diese beiden Fallback-Alternativen bzgl. der geforderten Sicherheitsleistung der zu schützenden Informationsobjekte mit dem Lösungsansatz zwar wirkungsgleich sind, jedoch

• Fallback-Alternative 1 nicht die in Abschnitt 8.2.6 Qualitätsanforderungen an Betrieb und Infrastruktur genannten Qualitätserforderungen für eine skalierfähige, hochverfügbare, moderne Cloud-Umgebung erfüllt und wenig nachhaltig ist,
• Fallback-Alternative 2 mit zusätzlichen Aufwänden an Anbieter/Betreiber hinsichtlich Implementierung und Bereitstellung der in [gemSpec_HCC] beschriebenen Sicherheitsarchitektur, Plattformleistung und ggf. der Rolle als HCC-Provider verbunden ist. 

Keine Fallback-Alternative (und damit Out of Scope) ist hingegen eine zusätzliche VAU-Betriebsumgebung, die zwar den Anforderungen aus [gemSpec_NCPeH_FD#Anforderungen an die Vertrauenswürdige Ausführungsumgebung] genügt, aber individuell zu implementieren und zu betreiben wäre.

8.3 NCPeH-FD

8.3.1 Zugang zum NCPeH-FD

Die NCPeH-FD-Webschnittstellen für das Anwendungsszenario ePeD-B sind über das Internet zugänglich. Der Zugang zu den Schnittstellen des NCPeH-FD ist ausschließlich für den NCPeH-Proxy vorgesehen. Die Absicherung der Verbindungen zwischen NCPeH-FD und NCPeH-Proxy erfolgt mittels mTLS-Authentifizierung. Direkte Schnittstellenaufrufe von anderen Clients oder Systemen sind nicht zulässig und müssen vom NCPeH-FD aktiv blockiert werden.

Die NCPeH‑FD‑Webschnittstellen für das Anwendungsszenario ePeD‑B sind grundsätzlich über das Internet erreichbar. Der Zugriff auf diese Schnittstellen ist jedoch ausschließlich dem NCPeH‑Proxy vorbehalten.

Die Absicherung der Kommunikation zwischen NCPeH‑FD und NCPeH‑Proxy erfolgt mittels gegenseitiger TLS‑Authentifizierung (mTLS). Direkte Schnittstellenaufrufe durch andere Clients oder externe Systeme sind nicht zulässig und müssen vom NCPeH‑FD technisch unterbunden werden.

Zusätzlich zur Transportverschlüsselung wird der Austausch von E-Rezepten und Dispensierinformationen auf Anwendungsebene mittels ASL (Application Security Layer) verschlüsselt. Die Verschlüsselung erfolgt gemäß den Vorgaben des VAU-Protokolls ([gemSpec_Krypt#"ZETA/ASL (VAU-Protokoll)"]). Dabei agiert der NCPeH-FD in der Rolle als ASL-Server. Die verschlüsselte Payload wird in der WebApp des EU-Webportals im inneren Request des ASL-Kanals erzeugt und über den NCPeH-Proxy an den NCPeH-FD weitergeleitet. Dieser Payload kann ausschließlich vom NCPeH-FD entschlüsselt werden, wodurch die Daten vor unbefugtem Zugriff geschützt sind.

8.3.2 Schnittstellen

Der NCPeH-FD umfasst die eigentlichen Funktionen des Anwendungsszenarios ePeD-B wie in der folgenden Tabelle dargestellt.

Tabelle 5: Funktionale Webschnittstellen und Operationstypen des NCPeH-FD

8.3.2.1 I_Comm_ASL

Der NCPeH-FD stellt für das Anwendungsszenario ePeD-B mehrere Webschnittstellen bereit, die über das HTTPS-Protokoll erreichbar sind. Diese Schnittstellen dienen als Eingangs- und Ausgangspunkte für Anfragen und Antworten, die mittels des NCPeH-Proxy zwischen der WebApp des EU-Webportals und dem NCPeH-FD ausgetauscht werden. Um die Vertraulichkeit und Integrität der personenbezogenen medizinischen Daten zu gewährleisten, wird zusätzlich zur Transportverschlüsselung mittels TLS auf der Anwendungsebene eine Ende-zu-Ende-Inhaltsverschlüsselung durch das ASL-Protokoll implementiert.

Die Anfragen, die über HTTPS an eine Webschnittstelle des NCPeH-FD gesendet werden, werden intern an den VAU-Verarbeitungskontext (Verarbeitungskomponente für verschlüsselte Inhalte) weitergeleitet. Dieser VAU-Verarbeitungskontext ist für die Entschlüsselung, Verarbeitung und Verschlüsselung der Inhalte verantwortlich. Die Antwort des VAU-Verarbeitungskontexts wird wiederum an die Webschnittstelle des NCPeH-FD übergeben und über den NCPeH-Proxy zurück an die WebApp gesendet.

Für weiterführende Informationen zur Nutzung der Webschnittstelle wird auf Kapitel 8.1.2.3 I_Comm_ASL verwiesen.

8.3.2.2 I_ISM_Service

Die Webschnittstelle des NCPeH-FD stellt auf Anfrage des NCPeH-Proxy die aktuellen International Search Masks (ISM) der zulässigen Länder-A bereit. Die ISMs definieren, welche Identitätsattribute für die Identifizierung von EU-Bürgern in den jeweiligen Zugehörigkeitsländern (Länder-A) verwendet werden. Diese Webschnittstelle ist ein essentieller Bestandteil des Anwendungsszenarios ePeD-B und gewährleistet die korrekte Bereitstellung der ISMs.

Der NCPeH-FD verfügt über die Information der zulässigen europäischen Länder (Länder-A), mit denen ein gegenseitiger Betrieb für den grenzüberschreitenden Austausch von ePrescription/eDispensation besteht. Diese Liste wird vom Systemadministrator des NCPeH-FD gepflegt und regelmäßig aktualisiert. Sie dient als Grundlage für die Ermittlung der relevanten Länder, deren ISM abgerufen und bereitgestellt werden müssen.

Der NCPeH-FD nutzt die Information über die zulässigen Länder-A, um einmal täglich die aktuellen ISM dieser Länder vom zentralen eHDSI Configuration Service herunterzuladen. Dieser Abruf erfolgt automatisiert oder auf Anfrage des Systemadministrators und stellt sicher, dass die im NCPeH-FD gespeicherten ISM stets auf dem neuesten Stand sind. Die heruntergeladenen ISM werden verschlüsselt im NCPeH-FD gespeichert.

Auf eine Anfrage des NCPeH-Proxy an die Webschnittstelle des NCPeH-FD liefert der NCPeH-FD die gesamte Liste der aktuell gespeicherten ISM zurück. Da die ISM keine personenbezogenen oder schützenswerten Daten enthalten, ist es nicht erforderlich, dass die Anfrage Identitätsangaben oder Tokens einer WebApp oder LE-DE umfasst.

Die Kommunikation zwischen dem NCPeH-Proxy und der Webschnittstelle des NCPeH-FD erfolgt über TLS v1.3.

8.3.2.3 I_Patient_Identification_Service

Die Webschnittstelle des NCPeH-FD verarbeitet Anfragen zur Bereitstellung von weiteren demographischen Daten des EU-Bürgers aus Land A. Die Anfrage wird durch den NCPeH-Proxy an den NCPeH-Fachdienst übermittelt und besteht aus einem äußeren sowie einem inneren Request.

Der innere Request enthält die fachlichen Suchparameter, die zur eindeutigen Ermittlung demographischer Daten des EU-Bürgers erforderlich sind. Diese Suchparameter sind mittels ASL verschlüsselt, um die Vertraulichkeit der sensiblen personenbezogenen Daten sicherzustellen.

Der äußere Request enthält ein vom NCPeH-Proxy elektronisch signiertes ID-Token. Dieses ID-Token umfasst relevante Identitätsmerkmale des LE-DE sowie der LE-LEI. Basierend auf den im ID-Token enthaltenen Informationsmerkmalen erstellt der NCPeH-FD eine SAML 2.0 Identity Assertion (IdA) für den LE-DE, sofern für den LE-DE im NCPeH-FD noch keine gültige IdA vorliegt. Die IdA wird durch den NCPeH-FD mit dem eigenen privaten eHDSI-SEAL-Schlüsselmaterial elektronisch signiert. Diese dient als Sicherheitsobjekt für diese und nachfolgende Kommunikation mit dem NCPeH Land A, daher wird sie in der VAU des NCPeH-FD gespeichert.

Die Anfrage wird einschließlich der IdA und der fachlichen Suchparameter gemäß den Vorgaben der eHDSI sowie HL7 XCPD an den NCPeH Land A übermittelt. Der NCPeH Land A verarbeitet die Anfrage und liefert als Antwort:

• weitere demographische Daten des EU-Bürgers
• eine bestätigte, eindeutige Patientenidentifikation (Patient Identifier).

Der NCPeH-FD nimmt diese Antwort entgegen, verarbeitet die enthaltenen Informationen und sendet sie gemäß der Beschreibung des Informationsmodells 8.4.2.3 Patient Demographics Response (Domain Identifier: patient_demographics_data) an die WebApp des LE-DE weiter.

8.3.2.4 I_eHealth_Service

Über die Webschnittstelle des NCPeH-FD werden zwei Operationen bereitgestellt:

• Verfügbare Gesundheitsdaten des EU-Bürgers auflisten und
• Ausgewählte Gesundheitsdaten des EU-Bürgers abrufen.

Diese Operationen sind bewusst anwendungsneutral konzipiert, sodass sie unabhängig vom konkreten Anwendungsszenario wie beispielsweise ePeD-B genutzt und auch von zukünftigen Anwendungsszenarien wiederverwendet werden können.

Mit Erhalt der Anfrage werden sowohl Identitätsdaten als auch fachliche Metadaten an die Webschnittstelle übermittelt. Zur Verarbeitung der Anfrage wertet der NCPeH-FD das im äußeren Request enthaltene ID-Token aus. Auf dieser Basis ermittelt er die zuvor erzeugte SAML 2.0 Identity Assertion (IdA) für den LE-DE. Diese Assertion wurde im Rahmen der Webschnittstelle 8.3.2.3 I_Patient_Identification_Service erzeugt.

Zusätzlich generiert der NCPeH-FD eine weitere SAML 2.0 Assertion, (TRC Assertion). Diese dient gegenüber dem anfragenden NCPeH Land-A als elektronischer Nachweis einer bestehenden Behandlungsbeziehung zwischen LE-DE und dem EU-Bürger. Die TRC Assertion wird durch den NCPeH-FD mit dem eigenen privaten eHDSI-SEAL-Schlüsselmaterial elektronisch signiert, um deren Integrität und Authentizität sicherzustellen. Der innere Request der gesamten Anfrage enthält darüber hinaus die fachlichen Nutzdaten, insbesondere:

• LOINC-Code zur eindeutigen Identifikation des Anwendungskontexts,
• Ländercode des Land A,
• Patient Identifier (vom Land A bestätigte eindeutige Kennung des EU-Bürgers),
• optionale Zugriffsinformationen zur Dokumentensuche.

Operation: Verfügbare Gesundheitsdaten des EU-Bürgers auflisten (im Kontext ePeD-B) 

Im Rahmen dieser Operation mit Kontext auf das Anwendungsszenario ePeD-B werden die Daten einschließlich IdA und TRC Assertion gemäß den Vorgaben der eHDSI und dem IHE XCA.Query Profil an den NCPeH Land A übermittelt. Der NCPeH Land A verarbeitet die Anfrage und liefert als Antwort die relevanten Metadaten zu den einlösbaren E-Rezepten des EU-Bürgers zurück. Der NCPeH-FD bereitet diese Metadaten entsprechend dem Informationsmodell 8.4.2.5 Query Response (Domain Identifier: list_available_presciption) auf und sendet sie an die WebApp des anfragenden LE-DE.

Operation: Ausgewählte Gesundheitsdaten des EU-Bürgers abrufen (im Kontext ePeD-B)

Für den Abruf ausgewählter E-Rezepte übermittelt der NCPeH-FD eine Anfrage mit den zuvor erhaltenen und durch den Leistungserbringer ausgewählten Metadaten an das entsprechende Land A. Auch diese Anfrage enthält die erforderlichen Sicherheitsartefakte, die IdA sowie die TRC Assertion, und wird gemäß den Vorgaben von eHDSI und dem IHE XCA.Retrieve Profil an den NCPeH Land A gesendet. Der NCPeH Land A stellt daraufhin die entsprechenden E-Rezepte bereit. Der NCPeH-FD übernimmt die Entgegennahme und leitet die E-Rezepte im Nachrichtenformat gemäß dem Informationsmodell in 8.4.2.7 Retrieve Response (Domain Identifier: list_prescription_retrieved) an die WebApp des LE-DE weiter.

8.3.2.5 I_PZN_Service

Die Webschnittstelle I_PZN_Service dient der technischen Unterstützung des LE-DE bei der Erfassung von Dispensierinformationen im EU‑Webportal. Ziel der Schnittstelle ist es, dem LE‑DE bei der Eingabe von Pharmazentralnummern (PZN) zusätzliche Sicherheit zu geben, indem zu jeder eingegebenen PZN geprüfte Arzneimittelinformationen angezeigt werden. Hierdurch wird die korrekte Identifikation des Arzneimittelprodukts unterstützt und das Risiko von Fehleingaben im grenzüberschreitenden Datenaustausch reduziert.

Die PZN ist ein bundeseinheitlicher, nationaler Identifikationsschlüssel für in deutschen Apotheken vertriebene Arzneimittel, Medizinprodukte und weitere apothekenübliche Produkte. Jede Arzneimittelpackung wird durch eine achtstellige numerische Kennung eindeutig identifiziert, die u. a. Produktbezeichnung, Darreichungsform und Packungsgröße referenziert. Da die PZN ausschließlich innerhalb Deutschlands verwendet wird und in anderen europäischen Staaten nicht direkt interpretierbar ist, ist für den grenzüberschreitenden Datenaustausch eine Validierung und inhaltliche Anreicherung notwendig.

Das EU‑Webportal übermittelt im Rahmen der Dispensierung eine oder mehrere PZN an die Webschnittstelle I_PZN_Service. Nach Eingang der Anfrage prüft der NCPeH‑FD über den I_PZN_Service, ob die empfangenen PZN fachlich und technisch unterstützt werden können. Hierzu werden die PZN automatisiert validiert und gegen die relevanten nationalen Referenzdaten geprüft.

Die für die Prüfung und Anreicherung der PZN erforderlichen Informationen zu Arzneimittelzulassungen werden aus der LTR (Local Terminology Repository) des NCPeH-FD herangezogen. Diese enthält die amtlich geprüften und autorisierten Zulassungsdaten sowie produktbezogene und regulatorische Metadaten zu zugelassenen Arzneimitteln, wie beispielsweise Handelsname, Zulassungsnummer, Zulassungsstatus und weitere relevante Metadaten. 

Die Validierung der PZN und die fachliche Ableitung der Produktinformationen erfolgen auf Basis der vom BfArM bereitgestellten Mapping‑ und Transferregeln. Diese Regeln stellen sicher, dass die abgeleiteten Informationen den regulatorischen Vorgaben entsprechen und konsistent im NCPeH‑Datenaustausch verwendet werden können.

Bei erfolgreich validierten PZN leitet der NCPeH‑FD die erforderlichen nationalen Arzneimittelinformationen ab. Die angereicherten Produktinformationen werden als strukturierte Antwort an das EU‑Webportal zurückgegeben und dort dem LE‑DE angezeigt.

Hinweis:

Das BfArM prüft derzeit, ob die bestehende Vereinbarung mit der Informationsstelle für Arzneispezialitäten (IFA) zur Nutzung von Zuordnungsinformationen zwischen Pharmazentralnummern (PZN) und den jeweiligen nationalen Zulassungsnummern von Arzneimitteln auch für den vorgesehenen Einsatz im Rahmen der Webschnittstelle I_PZN_Service zulässig ist. Sofern die aktuelle Vereinbarung diesen spezifischen Nutzungszweck nicht hinreichend abdeckt, ist die Notwendigkeit einer gesonderten vertraglichen Regelung zur rechtssicheren Bereitstellung und Verwendung der entsprechenden Zuordnungsdaten im Kontext des NCPeH‑FD und der Webschnittstelle I_PZN_Service zu bewerten und gegebenenfalls herbeizuführen.

8.3.2.6 I_Provide_DocumentSet_Service

Die vorliegende Webschnittstelle ist anwendungsneutral konzipiert, sodass sie unabhängig von konkreten Anwendungsszenarien wie ePeD-B genutzt und auch für zukünftige Anwendungsszenarien wiederverwendet werden kann.

Über diese Schnittstelle werden Gesundheitsdaten entgegengenommen, die durch den LE-DE innerhalb der WebApp des EU-Webportals erstellt wurden und zur Weiterverarbeitung an ein Land A übermittelt werden sollen.

Im Rahmen der Nutzung des Dienstes eDispensation erstellt der LE-DE während der Medikamentenabgabe sogenannte Dispensierinformationen. Diese enthalten relevante Angaben zur erfolgten Abgabe eines Medikaments an einen EU-Bürger. Die Dispensierinformationen, bestehend aus PZN-Angaben, werden in der WebApp des LE-DE erfasst und übermittelt diese in einer Anfrage über den NCPeH-Proxy an die Webschnittstelle des NCPeH-FD.

Der innere Request der Anfrage enthält die PZN (zur eindeutigen Identifikation von Dispensierinformationen), demographische Daten des EU-Bürgers sowie einen LOINC-Code (zur eindeutigen Identifikation des Anwendungskontexts). Auf Basis des LOINC-Codes erkennt der NCPeH-FD eindeutig, dass es sich um eine Transaktion im Kontext der Anwendung eDispensation handelt. In der Folge validiert der NCPeH-FD die PZN und leitet die kodierten Arzneimittelinformationen auf Basis der vom BfArM bereitgestellten Mappingregeln ab. Um die Dispensierinformationen für den eHDSI-Datenaustausch und im Land A semantisch nutzbar zu machen, transkodiert der NCPeH-FD die ermittelten und kodierten Arzneimittelinformationen gemäß BfArM-Mappingregeln.

Anschließend übermittelt der NCPeH-FD die Dispensierinformationen konform zu den Vorgaben der eHDSI und des IHE XDR Profils an den zuständigen NCPeH Land A.

Der NCPeH Land A verarbeitet die übermittelten Daten und liefert eine Rückmeldung über den Verarbeitungsstatus der Dispensierinformationen, insbesondere hinsichtlich des Erfolgs oder möglicher Fehler. Der NCPeH-FD nimmt diese Antwort entgegen, verarbeitet sie und stellt das Ergebnis über die Webschnittstelle der WebApp des anfragenden LE-DE zur Verfügung.

8.4 Informationsmodell

8.4.1 Domänenmodell für Land-B-Szenarien

Das Informationsmodell basiert auf dem Domänenkonzept. Die Domäne beschreibt das gesamte Problemfeld, das es - gestützt durch IT-Systeme - zu lösen gilt. Da diese Hauptdomäne zu komplex ist, um sie als Ganzes in einem einzigen "Software-Block" abzubilden, wird sie in kleinere, handhabbare Bausteine zerlegt, die sog. Sub-Domänen. Diese sind logische, fachliche Teilbereiche der Hauptdomäne. Sie helfen dabei, die Komplexität zu reduzieren und das Gesamtsystem besser zu verstehen.

Folgende Sub-Domänen unterschiedlichen Typs werden für das Feature unterschieden:

Die Sub-Domänen können nach ihrem strategischen Wert für die Erfüllung des Szenarios aus dieser Feature-Beschreibung (und folgender Szenarien) nach Typen "Core Domain", "Supporting Domain" und "Generic Domain" klassifiziert werden.

Daraus ergeben sich folgende Implikationen, unterschieden nach Sub-Domänentyp:

Typ "Core":

• Hier sind Alleinstellungsmerkmale und hoher Geschäftswert (Business Value) in der Umsetzung des Szenarios vorhanden.
• Hier entsteht höchster Zugewinn, wenn hier alles fehlerfrei und gemäß der Qualitätsvorgaben umgesetzt wird.
• Hier entsteht höchster Schaden, wenn es hier zu Qualitätsproblemen kommt.
• Hier ist besonders auf eine hochwertige, saubere Software-Architektur zu achten.

Typ "Supporting":

• Hier werden die Grundlagen geschaffen, damit Sub-Domänen vom Typ "Core" funktionieren können, ohne i.d.R. selbst einen eigenen Mehrwert zu liefern.
• Wird in der Regel als Eigenentwicklung durchgeführt, jedoch mit dem Fokus auf schlanke bzw. aufwandsarme Umsetzung.

Typ "Generic":

• Subdomänen dieses Typs bringen keinen Geschäftswert, sondern sind notwendig, weil sonst das Szenario nicht sinnvoll funktionieren kann.
• Es wird versucht, entweder Eigenimplementierungen ganz zu vermeiden oder vollständig die Implementierungen Dritter zu konsumieren und diese entsprechend zu integrieren.

Die Einteilung in Sub-Domänen und die Klassifizierung dieser geben Orientierung beim Zuschnitt der Zielarchitektur (Umsetzung).

8.4.2 Externe Informationsmodelle

Die in diesem Kapitel beschriebenen Informationsmodelle gelten für den Datenaustausch zwischen dem EU-Webportal, NCPeH-Proxy und NCPeH‑FD. Die beschriebenen Informationsmodelle basieren auf dem aktuellen fachlichen und technischen Stand. Zukünftige normative Anforderungen aus der EHDS‑Verordnung sowie dem zugehörigen Implementing Act insbesondere in Bezug auf Schnittstellen und Nachrichtenformate sowie die verpflichtende Nutzung von FHIR‑Profilen können Auswirkungen auf diese Modelle haben. Eine Angleichung an die entsprechenden EHDSI‑Vorgaben ist in einer späteren Umsetzungsstufe vorgesehen.

Die Zuordnung der externen Informationsmodelle zum   erfolgt über das "x-external-reference"-Attribut am jeweiligen Domänenobjekt in [domainobj-eped-b.yaml].

8.4.2.1 International Search Mask (Domain Identifier: list_ism_international)

Das Informationsmodell für die International Search Mask (ISM) ist definiert und bereits im Wirkbetrieb mehrerer EU-Mitgliedstaaten im Rahmen der eHDSI eingesetzt. Die Definition der ISM erfolgte in Zusammenarbeit zwischen dem eHDSI Solution Provider und den beteiligten Mitgliedstaaten.

Das zugehörige XSD-Schema ist unter folgendem Link verfügbar: [eHDSI_ISM_XSD].

Für den Transport mehrerer ISM-Dokumente zwischen NCPeH-FD, NCPeH-Proxy und EU-Webportal wird eine auf FHIR basierende Transportstruktur verwendet. Hierbei dient die Ressource Bundle mit dem Typ collection als technischer Container für mehrere voneinander unabhängige Ressourcen, ohne dass zwischen ihnen eine transaktionale oder semantische Abhängigkeit besteht.

Für jede einzelne ISM wird innerhalb des Bundles eine eigene FHIR Ressource Entry erzeugt, die jeweils eine Instanz der FHIR-Ressource Binary enthält. Die Binary-Ressource dient dabei als generischer Container für nicht-FHIR-konforme Inhalte und ermöglicht den Transport beliebiger Datenformate innerhalb einer FHIR-basierten REST-Schnittstelle.

Das ISM-Dokument im XML-Format wird base64-kodiert in die FHIR Ressource Binary aufgenommen.

8.4.2.2 Patient Demographics Query Request (Domain Identifier: patient_identification_query)

Die Erstellung der Abfragenachricht basiert auf den Vorgaben der ISM des jeweiligen Land A. Die ISM definiert, welche Identitätsmerkmale eines EU-Bürgers für eine Suche nach seinen demographischen Daten übermittelt werden müssen. Diese Angaben werden durch den LE-DE manuell im EU-Webportal erfasst. In diesem Kontext agiert das EU‑Webportal gemäß IHE‑Terminologie als Patient Demographics Consumer. Auf Grundlage dieser Informationen generiert das EU-Webportal die strukturierte Abfragenachricht. Die Anfrage kann beispielsweise Angaben wie Patientenidentifier, Vor- und Nachname, Geburtsdatum, Geburtsort, Wohnadresse oder Geschlecht enthalten.

Die fachliche Struktur der Abfragenachricht basiert auf dem HL7-v3-Nachrichtenmodell PRPA_MT201306UV02 ("Patient Registry Query by Demographics") gemäß [ITI-55] und ist ausschließlich konform zum Element PRPA_MT201306UV02.ParameterList entsprechend den Vorgaben des zugehörigen XSD‑Schemas [PRPA_MT201306UV02.xsd].

Für den Transport vom EU-Webportal zum NCPeH-FD innerhalb der FHIR-basierten Kommunikation wird die ParameterList-Abfragenachricht base64-kodiert in eine Instanz der FHIR-Ressource Binary aufgenommen.

8.4.2.3 Patient Demographics Response (Domain Identifier: patient_demographics_data)

Die vom Land A des EU-Bürgers bereitgestellten demographischen Daten unterstützen den LE-DE dabei, die übermittelten Angaben mit den Daten des vorgelegten Ausweisdokuments abzugleichen und den Identifikationsprozess des EU-Bürgers im Rahmen des eHDSI abzuschließen.

Die fachliche Struktur der Antwortnachricht basiert auf dem HL7-v3-Nachrichtenmodell PRPA_MT201310UV02 ("Patient Registry Find Candidates Query Response") gemäß (ITI‑55) und ist insbesondere konform zur Struktur des Elementes PRPA_MT201310UV02.Patient gemäß dem zugehörigen XSD‑Schema [PRPA_MT201310UV02.xsd]. Die Nachricht kann demographische Angaben wie Patientenidentifier, Name, Geburtsdatum, Geschlecht oder weitere Identitätsmerkmale enthalten, die für die abschließende Patientenidentifikation relevant sind.

Für den Transport innerhalb der FHIR-basierten Kommunikation wird die Antwortnachricht base64-kodiert in einer Instanz der FHIR Ressource Binary abgelegt, die als generischer Container für nicht-FHIR-konforme Inhalte dient.

8.4.2.4 Query Request

Die Anfrage zur Auflistung einlösbarer E-Rezepte des EU-Bürgers aus Land A sieht keine Übermittlung eines Payloads an den NCPeH-FD. Stattdessen werden die notwendigen Angaben, etwa der Patienten Identifier, der LOINC‑Code für die Anwendung ePrescription sowie der Ländercode des Land A als Suchparameter in der URL der Anfrage an NCPeH-FD übergeben.

Aus diesem Grund enthält dieses Unterkapitel kein eigenes Informationsmodell.

8.4.2.5 Query Response (Domain Identifier: list_available_presciption)

Als Antwort auf eine Query-Anfrage zur Auflistung einlösbarer elektronischer Rezepte des EU-Bürgers übermittelt das Land A die relevanten Metadaten zu den verfügbaren E-Rezepten. Diese Metadaten dienen dem EU-Webportal dazu, die vorhandenen E-Rezepte darzustellen und dem LE-DE eine Auswahl der einzulösenden E-Rezepte zu ermöglichen.

Die fachliche Struktur der Antwortnachricht basiert auf dem IHE-Profile Cross Gateway Query Response im Rahmen des Profils Cross-Community Access (XCA). Die Syntax und Semantik der Nachricht entsprechen dabei den Vorgaben der [eHDSI_XCA_Profile#"FindDocuments Response Message"] sowie dem [ITI-38]. Kodierte Inhalte können um entsprechende Transkodierungen ergänzt werden, die vom NCPeH‑FD gemäß den Vorgaben des BfArM erzeugt und in die Antwortnachricht integriert werden.

Für den Transport innerhalb der FHIR-basierten Kommunikation wird die XCA.Query-Antwortnachricht base64-kodiert in einer Instanz der FHIR Ressource Binary abgelegt.

8.4.2.6 Retrieve Request (Domain Identifier: list_selected_presciption_retrieval)

Im Kontext des Abrufs von E-Rezepten des EU-Bürgers wird die Anfragenachricht im EU-Webportal erzeugt. Grundlage für die Struktur und Semantik der Anfrage bildet das Informationsmodell für die Operation der IHE XCA.Retrieve. Diese definiert das Nachrichtenformat.

Im EU-Webportal wählt der LE-DE gezielt diejenigen E-Rezepte aus, die aus dem Land A abgerufen werden sollen. Für jedes ausgewählte elektronische Rezept werden die entsprechenden bereits abgerufenen Metainformationen übernommen. Dazu gehören der eindeutige ePrescriptionId. sowie weitere Identifikatoren, die im Rahmen des IHE XCA Profils zur eindeutigen Referenzierung des Dokuments im Land A erforderlich sind, wie beispielsweise RepositoryUniqueId, DocumentUniqueId und HomeCommunityId. Für die ausgewählten E-Rezepte werden diese Metadaten innerhalb der Anfragenachricht in Form mehrerer DocumentRequest-Elemente abgebildet, wodurch der gleichzeitige Abruf mehrerer ePrescriptions innerhalb einer einzelnen Retrieve-Anfrage ermöglicht wird.

Zur Integration in eine FHIR-basierte Kommunikation wird die XCA.Retrieve Nachricht base64-kodiert und als Payload in einer Instanz der FHIR-Ressource Binary eingebettet.

8.4.2.7 Retrieve Response (Domain Identifier: list_prescription_retrieved)

Als Antwort auf eine Retrieve-Anfrage zum Abruf ausgewählter E-Rezepten des EU-Bürgers übermittelt das Land A die E-Rezepte. Die Antwort entspricht dem Nachrichtentyp RetrieveDocumentSetResponse und erfüllt die Vorgaben aus [ITI-43#3.43.4.2]. Die Antwort kann mehrere E-Rezepte enthalten. Das Informationsmodell der bereitgestellten E-Rezeptformate ist durch die eHDSI in [eHDSI_CDA_ePrescription_L1] und [eHDSI_CDA_ePrescription_L3] definiert. Die E-Rezepte, die dem Dokumentenformat [eHDSI_CDA_ePrescription_L3] entsprechen, werden im NCPeH-FD gemäß BfArM-Vorgaben transkodiert.

Für den Transport innerhalb der FHIR-basierten Kommunikation wird die komplette IHE XCA.Retrieve-Antwortnachricht als base64-kodiert in einer Instanz der FHIR Ressource Binary angehängt.

8.4.2.8 Dispensierdokumente (Domain Identifier: list_dispensation_documents)

Das fachliche Informationsmodell der Dispensierdokumente ist durch die eHDSI definiert und normativ in [eHDSI_CDA_eDispensation] beschrieben. Es legt die inhaltliche Struktur und Semantik der CDA‑basierten Dispensierdokumente fest, die im Rahmen der grenzüberschreitenden E‑Rezept‑Abwicklung verwendet werden.

Die CDA‑Dispensierdokumente enthalten sowohl administrative als auch medizinische Informationen. Dazu gehören insbesondere Angaben zum Patienten, zum Autor des Dokuments (LE‑DE), der eindeutige Prescription Identifier sowie die kodierten Dispensierinformationen als medizinische Angaben zu den tatsächlich abgegebenen Arzneimitteln. Die Dispensierinformationen umfassen unter anderem den Produktnamen, den Wirkstoff, die Darreichungsform sowie die Darreichungsstärke des abgegebenen Arzneimittels.

Die Generierung der CDA‑Dispensierdokumente erfolgt im NCPeH‑FD gemäß den Vorgaben aus [eHDSI_CDA_eDispensation]. Da die PZN ausschließlich in Deutschland verwendet wird und in anderen europäischen Ländern nicht interpretierbar ist, muss der NCPeH‑FD auf Basis der jeweiligen PZN jedes abzugebendes E-Rezeptes eines EU-Bürgers entsprechende nationale sowie eHDSI‑konforme Transkodierungen der Dispensierinformationen ableiten. Diese Transkodierungen erfolgen gemäß den Vorgaben des BfArM und werden anschließend in das CDA‑Dispensierdokument integriert.

Da die Erstellung der CDA‑Dispensierdokumente im NCPeH‑FD durch die Vorgaben des BfArM gesteuert wird, erfolgt die detaillierte Abstimmung der zu übertragenden Daten und Datenstrukturen an der jeweiligen Schnittstelle erst im Rahmen der nachfolgenden Spezifikation.

8.5 Use Cases

8.5.1 Use Case zur Initialisierung der Webapp

AF_10436 - Basis-Initialisierung der WebApp und der Kommunikation

Attribute	Bemerkung
Beschreibung	Der Use Case beschreibt den grundsätzlichen Aufruf der WebApp des EU-Webportals durch den LE-DE, die Initialisierung der WebApp, die Basis-Basisvalidierungen, die vor Benutzung durch den LE-DE erfolgreich abgeschlossen sein müssen, die Basis-Kommunikationskanäle. Bei den Basis-Kommunikationskanälen (Boxen mit orangefarbenen Header) wird der späteste Zeitpunkt gezeigt, zu welchem der jeweilige Kommunikationskanal verfügbar sein muss, damit die anschließenden Ablaufschritte wie beschrieben stattfinden können.
Vorbedingung	siehe Sequenzdiagramm, obere Partition (inkl. Constraints)
Nachbedingung	API-Requests können über bestehende Basis-Kommunikationskanäle gesendet und API-Responses empfangen werden. Bestehende Kommunikationskanäle werden wiederbenutzt (Connection Pooling, Session Resumption) und werden im Bedarfsfall erneut aufgebaut.

Abbildung 16: Sequenzdiagramm - Basis-Initialisierung der WebApp und der Kommunikation

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/common/basic-init_seq.svg

8.5.2 Use Cases im Rahmen der Authentifizierung, Autorisierung

8.5.2.1 Authentifizierung und Autorisierung des LE-DE

AF_10429 - Authentifizierung und Autorisierung des LE-DE

	Authentifizierung und Autorisierung des LE-DE
Beschreibung	Der Use Case beschreibt, wie sich ein Nutzer (LE-DE) gegenüber dem NCPeH-FD legitimiert, um grenzüberschreitende Gesundheitsdienste dieses Szenarios zu nutzen. Kern des Verfahrens ist ein Decoupled-Auth-Flow, bei dem die Weboberfläche und die eigentliche Identitätsprüfung (via gematik Authenticator) entkoppelt voneinander stattfinden. Die Schutzleistung wird durch DPoP (Demonstrating Proof-of-Possession) und PKCE verbessert. Phase 1: Initiierung und Decoupled Request (Partitionen 1 und 5) Das EU-Webportal generiert ein lokales Schlüsselpaar und sendet einen Decoupled Auth Request an den NCPeH-Proxy. Dieser erzeugt eine auth_req_id sowie PKCE-Parameter und liefert eine poll_uri zurück. Das EU-Webportal verbleibt ab diesem Zeitpunkt in einer Polling-Schleife, um auf den Abschluss der Authentifizierung zu warten. Zum Abschluss der Authentifizierung erhält das EU-Webportal die auth_req_id. Phase 2: Authentifizierung (Partitionen 2-4) Parallel zum Polling öffnet der Nutzer den gematik Authenticator (via Deeplink). In einer Schleife erfolgt die Authentifizierung für beide Smartcards (HBA und SMC-B): Consent: Der Nutzer erteilt die Zustimmung zur Identitätsdaten-Übermittlung. Karteninteraktion: Der Konnektor signiert eine Challenge (ggf. nach PIN-Eingabe am Kartenterminal). Token Exchange: Der IDP validiert die Signatur und stellt einen AUTH_CODE aus. Der NCPeH-Auth-Service tauscht diesen Code beim IDP gegen ein ID-Token ein. Phase 3: erneuter Token-Tausch und Policy-Prüfung (Partition 5) Sobald die ID-Tokens für beide Karten vorliegen, führt der Auth-Service interne Prüfungen durch: Access-Token-Generierung: Prüfung der Rollen und Claims aus den ID-Tokens. Erstellung eines spezifischen ncpehprx_access_token. Claims-Mapping: Die Claims werden in ein ID-Token als IdA-Vorstufe transformiert, welcher für den Zugriff auf den NCPeH-FD benötigt wird.
Vorbedingung	Browser geöffnet URL des EU-Webportals aufgerufen
Nachbedingung	Das EU-Webportal erhält im Rahmen des Pollings das fertige Access-Token (gebunden an den DPoP-Schlüssel). Mit dem Vorhandensein dieses Tokens und des ID-Tokens (IdA-Vorstufe) wird ein gesicherter ASL-Kanal (Application Security Layer) zum NCPeH-Fachdienst aufgebaut, über den die eigentlichen Backend-Abrufe erfolgen (Partition 6). Damit nach erfolgreicher Authentisierung der Backend-Zugriff stattfinden kann, muss ein ASL-Kanal gemäß AF_10430 - Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD etabliert sein, jeder Request durch das EU-Webportal gemäß AF_10431 - Nutzung einer autorisierten Verbindung zum NCPeH-FD durchgeführt werden.

Abbildung 17: Sequenzdiagramm - Authentifizierung und Autorisierung des LE-DE

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/auth/auth_seq-alternative2.svg 

8.5.2.2 Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD

AF_10430 - Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD

	Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD
Beschreibung	Bevor das EU-Webportal medizinischen Nutzdaten austauschen kann, wird ein Ende-zu-Ende gesicherter Kanal zum NCPeH-FD hergestellt. Dazu ist ein ASL-Handshake notwendig, der wie beschrieben abläuft.
Vorbedingung	keine (wurde bereits durch den aufrufenden Use Case erfüllt)
Nachbedingung	Es ist symmetrisches K2-Schlüsselmaterial erzeugt für diesen ASL-Kanal, mit jeweils einem Schlüssel für die Kommunikation vom EU-Webportal zum NCPeH-FD und umgekehrt.

Abbildung 18: Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/common/asl-channel_seq.svg 

8.5.2.3 Nutzung einer autorisierten Verbindung zum NCPeH-FD

AF_10431 - Nutzung einer autorisierten Verbindung zum NCPeH-FD

	Nutzung einer autorisierten Verbindung zum NCPeH-FD
Beschreibung	Dieser Use Case beschreibt den abgesicherten Datenaustausch zwischen einem Leistungserbringer (LE-DE) über ein EU-Webportal und dem NCPeH-FD. Der Fokus liegt auf der Ende-zu-Ende-Verschlüsselung der Nutzdaten sowie der mehrstufigen Autorisierung mittels DPoP (Demonstrating Proof-of-Possession) und Access-Tokens. Zu beachten: Die Formate der im Sequenzdiagramm genannten Chiffrate sind den annotierten Anforderungen (A_..) definiert. Das Token DPoP-Token-2 muss bei jedem Request erneut generiert werden. Die hier erwähnten, zu verschlüsselnden Nutzdaten beziehen sich insbesondere auf Informationsobjekte aus 8.4 Informationsmodell, die das Attribut "x-medical-personal-information: true" tragen. Sicherheitslogik der Session-Tupel: Im Diagramm wird ein Session-Tupel-Konzept verwendet, um die Last auf den IDP-Komponenten zu reduzieren und um eine eigene logische Session aufzuspannen. Anhand der grünen Lifelines ist das logische Session-Handling zu erkennen. Diese logische Session wird durch Session-Tupel definiert. Proxy-Ebene: Das Paar (ncpehprx_access_token, IdA_raw) erlaubt es dem Proxy, Requests ohne erneute Rücksprache mit dem AuthService durchzureichen, solange die Validität gegeben ist. Fachdienst-Ebene: Das Paar (IdA_raw, IdentityAssertion) dient der Vermeidung redundanter SAML-Validierungen. Der FD wandelt die Claims des IdA_raw ID-Tokens einmalig in eine interne, signierte Identität (IdentityAssertion) um und speichert diese für die Session-Dauer.  Die Tokens werden wie beschrieben validiert. Invalide Tokens sorgen für ein ungültiges Session-Tupel und somit für eine ungültige Session.
Vorbedingung	Ein ASL-Kanal gemäß AF_10430 - Etablierung eines ASL-Kanals in die VAU-Umgebung des NCPeH-FD muss etabliert sein. Tokenübergabe: Dem EU-Webportal wurde bereits einen ncpehprx_access_token ausgestellt. Tokenübergabe: Der HTTP-Proxy-Komponete wurde bereits ein IdA_raw Token ausgestellt.
Nachbedingung	NCPeH-FD enthält eine gültige IdentityAssertion. Ein Nachweis über die erfolgte Ausstellung der IdentityAssertion ist im NCPeH-FD in Form eines HP Assurance Audit Trail persistiert.

Abbildung 19: Sequenzdiagramm - Nutzung einer autorisierten Verbindung zum NCPeD-FH

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/auth/backend-access_seq.svg

8.5.3 Use Cases im Rahmen der Identifizierung eines EU-Bürgers

8.5.3.1 International Search Masks abrufen

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/functional/ISM%20bereiststellen.svg

8.5.3.2 Demographische Daten eines EU-Bürgers abrufen

AF_10428 - Demographische Daten eines EU-Bürgers abrufen

Alle am Anwendungsfall "Demographische Daten eines EU-Bürgers abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

	Demographische Daten eines EU-Bürgers abrufen
Kurzbeschreibung des Verlaufes	Der LE‑DE kann in der WebApp die jeweils erforderlichen Datenschutzbestimmungen für sich selbst (HPIN-Dokument) oder für den EU‑Bürger (PIN-Dokument) aufrufen. Die Anzeige der Datenschutzbestimmungen ist in der Zielsprache des Zugehörigkeitslandes des EU‑Bürgers möglich. Darüber hinaus kann der LE‑DE die Datenschutzbestimmungen ausdrucken oder in der WebApp einen QR‑Code mit einem Link zur entsprechenden Quelle anzeigen lassen. Auf Anfrage eines LE-DE startet die WebApp eine ISM-Abfrage für die Anwendung ePrescription beim NCPeH-Proxy, der daraufhin eine entsprechende Liste der ISMs zurückliefert. Auf Anfrage eines LE-DE zeigt das EU-Webportal im Browser die Suchmaske für das ausgewählte Land A an. Der LE-DE gibt die erforderlichen Daten manuell in die Suchmaske ein und bestätigt die Anfrage zum Abruf weiterer demographischer Daten eines EU-Bürgers. Die eingegebenen Daten werden vom EU-Webportal verschlüsselt an den NCPeH-FD übertragen und sind damit für Dritte nicht einsehbar. Der NCPeH-FD leitet die vom LE-DE eingegebenen Daten an den NCPeH Land A weiter, um weitere demographische Daten abzurufen und einen eindeutigen Patient Identifier zu bestätigen. Die ermittelten demographischen Daten des EU-Bürgers werden anschließend im EU-Webportal im Browser angezeigt.
Vorbedingung	Der Anwendungsfall AF_10427 - International Search Masks abrufen wurde von dem LE-DE ausgeführt. Der LE-DE ist autorisiert die Anwendung ePrescription zu nutzen. Zwischen Deutschland und Land A besteht eine Vereinbarung über den grenzüberschreitenden Austausch von personenbezogenen Daten. URL oder Inhalte der Datenschutzbestimmungen (HPIN-Dokument und PIN-Dokument) sind in der WebApp enthalten. Die mTLS-Verbindung zwischen NCPeH-Proxy und NCPeH-FD ist aufgebaut.
Nachbedingung	Der Patient Identifier (z.B. zur eindeutigen Ermittlung von einlösbaren E-Rezepten im Land A) ist im EU-Webportal für nachfolgende Transaktionen zwischengespeichert. Zugriffsinformationen für Dokumentensuche (z.B. für berechtigten Abruf von E-Rezepten aus Land-A) sind im EU-Webportal zwischengespeichert. Die demographischen Daten des EU-Bürgers sind im EU-Webportal zwischengespeichert. Die Suchmasken (ISM) sind weiterhin im Webportal vorhanden und können auf Anfrage des LE-DE angezeigt werden. NCPeH-FD enthält Einträge zu Non-Repudiation Origin und Receipt. Der LE-DE kann die Suche nach demographischen Daten desselben EU-Bürgers wiederholen. Dabei ist die Suchmaske des Land A mit den zuletzt vom LE-DE eingegebenen Daten dieses EU-Bürgers vorausgefüllt. Wenn der LE-DE die Suchmaske zur Suche von demographischen Daten eines anderen EU-Bürgers öffnet, dann ist die Suchmaske leer. Die bisher zwischengespeicherten Daten zu vorherigen EU-Bürgern sind nicht mehr im EU-Webportal vorhanden. Ein HP Assurance Audit Trail Eintrag ist gemäß eHDSI-Vorgaben erstellt und im NCPeH-FD persistiert.

Abbildung 21: Sequenzdiagramm - Demographische Daten eines EU-Bürgers abrufen

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/functional/Demographische_Daten_eines_EU-Buergers_abrufen.svg

8.5.4 Use Cases im Rahmen der Belieferung durch eine Apotheke in Deutschland

8.5.4.1 Liste der einlösbaren E-Rezepte eines EU-Bürgers abrufen

AF_10432 - Liste der einlösbaren E-Rezepte eines EU-Bürgers abrufen

Alle am Anwendungsfall "Liste der einlösbaren E-Rezepte eines EU-Bürgers abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

	Liste der einlösbaren E-Rezepte eines EU-Bürgers abrufen
Kurzbeschreibung des Verlaufes	Der LE-DE bestätigt im EU-Webportal die Behandlungsbeziehung zum EU-Bürger Der LE-DE stellt im EU-Webportal die Anfrage zur Auflistung der einlösbaren E-Rezepte des EU-Bürgers. Das EU-Webportal übermittelt mit der Anfrage die Zugriffsinformationen für die Suche nach E-Rezepten (siehe Nachbedingung in AF_10428 - Demographische Daten eines EU-Bürgers abrufen) Der NCPeH-FD überprüft die Zulässigkeit des Abrufs von E-Rezepten aus dem Land A des EU-Bürgers. Der NCPeH-FD ermittelt die bereits erstellte und persistierte elektronische Identität des LE-DE (IdA - Identity Assertion) und prüft deren Gültigkeit. Der NCPeH-FD wandelt die Informationen zur Behandlungsbeziehung in eine SAML 2.0 TRC Assertion gemäß eHDSI-Vorgaben. Die TRC Assertion wird mit der IdA verknüpft und für nachfolgende Transaktionen nutzbar gemacht. Der NCPeH-FD sendet eine Anfrage an den NCPeH Land A, inklusive des eindeutigen Patient Identifiers des EU-Bürgers, um Metadaten der einlösbaren E-Rezepte bereitzustellen. Der NCPeH-FD überprüft die erhaltenen Metadaten auf die Einhaltung der eHDSI-Vorgaben. Die Metadaten werden gemäß den Vorgaben des BfArM transkodiert. Die Metadaten der einlösbaren E-Rezepte werden im EU-Webportal gerendert und dem LE-DE angezeigt.
Vorbedingung	Der LE-DE ist autorisiert die Anwendung ePrescription zu nutzen. Zwischen Deutschland und Land A besteht eine Vereinbarung über den grenzüberschreitenden Austausch von E-Rezepten. Der Anwendungsfall AF_10428 - Demographische Daten eines EU-Bürgers abrufen wurde von dem LE-DE ausgeführt. Die mTLS-Verbindung zwischen NCPeH-Proxy und NCPeH-FD ist aufgebaut. Ein ASL-Kanal zwischen EU-Webportal und NCPeH-FD ist aufgebaut und vorhanden.
Nachbedingung	Der Patient Identifier des EU-Bürgers (z.B. zur eindeutigen Ermittlung von einlösbaren E-Rezepten im Land A) ist weiterhin im EU-Webportal für nachfolgende Transaktionen zwischengespeichert. Metadaten der einlösbaren E-Rezepte sind für nachfolgende Transaktionen im EU-Webportal zwischengespeichert Der NCPeH-FD hat für die ein- und ausgehenden Nachrichten Einträge zu Non-Repudiation Origin und Receipt persistiert. Informationen über erfolgte Events (z.B. Query, Transcoding, Issuance of a TRC Assertion etc.) sind gemäß eHDSI-Vorgaben im passenden HP Assurance Audit Trail Eintrag enthalten.

Abbildung 22: Sequenzdiagramm - Liste der einlösbaren E-Rezepte eines EU-Bürgers abrufen 

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/functional/Liste_der_einloesbaren_E-Rezepte_eines_EU-Buergers_abrufen.svg

8.5.4.2 Ausgewählte E-Rezepte eines EU-Bürgers abrufen

AF_10433 - Ausgewählte E-Rezepte eines EU-Bürgers abrufen

Alle am Anwendungsfall "Ausgewählte E-Rezepte eines EU-Bürgers abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

	Ausgewählte E-Rezepte eines EU-Bürgers abrufen
Kurzbeschreibung des Verlaufes	Der LE-DE wählt im EU-Webportal E-Rezepte aus, deren vollständigen Inhalt er anzeigen möchte. Der LE-DE stellt im EU-Webportal die Anfrage zum Abruf von ausgewählten E-Rezepten. Das EU-Webportal sendet die Anfrage an den NCPeH-FD. Der NCPeH-FD überprüft die Zulässigkeit des Abrufs von E-Rezepten aus dem Land-A des EU-Bürgers. Der NCPeH-FD ermittelt die bereits erstellte und persistierte elektronische Identität des LE-DE (IdA - Identity Assertion) und Bestätigung der Behandlungsbeziehung zum EU-Bürger (TRC Assertion) und überprüft diese auf ihre zeitliche Gültigkeit. Der NCPeH-FD sendet eine Anfrage an den NCPeH Land-A mit Angaben zu den angeforderten E-Rezepten, um diese in eHDSI CDA ePrescription Level 1 und Level 3 Dokumentformaten abzurufen. Der NCPeH-FD überprüft die erhaltenen E-Rezepte auf die Einhaltung der eHDSI-Vorgaben. Der NCPeH-FD überprüft die Patient Identifiers aus den E-Rezepten auf Übereinstimmung. Der NCPeH-FD transkodiert die E-Rezepte gemäß BfArM-Vorgaben. Der NCPeH-FD sendet die transkodierten E-Rezepte ans EU-Webportal. Die E-Rezepte werden dem LE-DE im EU-Webportal angezeigt. Neben der Darstellung der strukturierten Inhalte der E-Rezepte besteht für den LE-DE im EU-Webportal optional die Möglichkeit, sich zusätzlich die Original-E-Rezepte im PDF/A-Format anzeigen zu lassen.
Vorbedingung	Der LE-DE ist autorisiert die Anwendung ePrescription zu nutzen. Der Anwendungsfall AF_10432 - Liste der einlösbaren E-Rezepte eines EU-Bürgers abrufen wurde von dem LE-DE ausgeführt. Die mTLS-Verbindung zwischen NCPeH-Proxy und NCPeH-FD ist aufgebaut. Ein ASL-Kanal zwischen EU-Webportal und NCPeH-FD ist aufgebaut und vorhanden.
Nachbedingung	Der Patient Identifier des EU-Bürgers (z.B. zur eindeutigen Ermittlung von einlösbaren E-Rezepten im Land-A) ist weiterhin im EU-Webportal für nachfolgende Transaktionen zwischengespeichert. Metadaten der einlösbaren E-Rezepte sind für den Dispensiervorgang im EU- Webportal zwischengespeichert. Der NCPeH-FD hat für die ein- und ausgehenden Nachrichten Einträge zu Non-Repudiation Origin und Receipt persistiert. Informationen über erfolgte Events (z.B. Retrieve, Transcoding, etc.) sind im HP Assurance Audit Trail Eintrag enthalten. Im EU-Webportal liegen die Inhalte der abgerufenen E-Rezepte und deren Metadaten vor.

Abbildung 23: Sequenzdiagramm - Ausgewählte E-Rezepte eines EU-Bürgers abrufen

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/functional/Ausgewaehlte_E-Rezepte_eines_EU-Buergers_abrufen.svg

8.5.4.3 Dispensierinformationen an Land A übermitteln

AF_10434 - Dispensierinformationen an Land A übermitteln

Alle am Anwendungsfall "Dispensierinformationen an Land A übermitteln" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

	Dispensierinformationen an Land A übermitteln
Kurzbeschreibung des Verlaufes	Der LE‑DE wählt im EU‑Webportal die zuvor abgerufenen E‑Rezepte des EU‑Bürgers aus, die im Rahmen des Anwendungsszenarios dispensiert werden sollen. Für die ausgewählten E‑Rezepte erfasst der LE‑DE die jeweiligen PZN. Die WebApp übermittelt die eingegebenen PZN an den NCPeH‑FD zur Validierung sowie zur Ermittlung des zugehörigen Produktnamens des Arzneimittels. Als Antwort liefert das NCPeH‑FD den ermittelten Produktnamen zurück, der dem LE‑DE im EU‑Webportal als Bestätigung der eingegebenen PZN angezeigt wird. Für jedes zur Abgabe vorgesehene E‑Rezept erfasst der LE‑DE die entsprechende PZN als Bestandteil der Dispensierinformationen. Die WebApp übermittelt die eingegebene PZN an das NCPeH‑FD zur Validierung und zur Ermittlung des zugehörigen Produktnamens des Arzneimittels. Das NCPeH‑FD liefert als Antwort den validierten Produktnamen, welcher dem LE‑DE im EU‑Webportal angezeigt wird. Nach erfolgreicher Prüfung bestätigt der LE‑DE die offizielle Übermittlung der Dispensierinformationen (insbesondere PZN). Im Rahmen dieser Übermittlung werden zusätzlich die zuvor ermittelten demographischen Daten des EU‑Bürgers an den NCPeH-FD übergeben. Das EU‑Webportal leitet die Dispensieranfrage an das NCPeH‑FD weiter. Das NCPeH‑FD prüft die grundsätzliche Zulässigkeit der Dispensierung von E‑Rezepten in Bezug auf das Zugehörigkeitsland (Land‑A) des EU‑Bürgers. Anschließend ermittelt der NCPeH‑FD die bereits erstellte und persistierte elektronische Identität des LE‑DE (IdA - Identity Assertion) sowie die Bestätigung der Behandlungsbeziehung zum EU‑Bürger (TRC Assertion). Beide Assertions werden auf ihre zeitliche Gültigkeit überprüft. Für jedes abzugebende E‑Rezept erstellt das NCPeH‑FD jeweils ein CDA eDispensation Dokument. Die Dokumente basieren auf den Informationen zum LE‑DE, den demographischen Daten des EU‑Bürgers, den Metadaten des jeweiligen E‑Rezeptes, den aus der PZN abgeleiteten Arzneimittelinformationen sowie den gemäß den BfArM‑Vorgaben transkodierten Werten. Das NCPeH‑FD übermittelt die Anfrage einschließlich der erstellten CDA eDispensation Dokumente an den NCPeH Land‑A. Der NCPeH Land‑A bestätigt mit seiner Antwort die erfolgreiche Verarbeitung der Dispensierinformationen. Der Status der Verarbeitung der Dispensierung wird dem LE‑DE im EU‑Webportal angezeigt.
Vorbedingung	Der LE-DE ist autorisiert die Anwendung eDispensation zu nutzen. Der Anwendungsfall AF_10433 - Ausgewählte E-Rezepte eines EU-Bürgers abrufen wurde von dem LE-DE  ausgeführt. Die mTLS-Verbindung zwischen NCPeH-Proxy und NCPeH-FD ist aufgebaut. Ein ASL-Kanal zwischen EU-Webportal und NCPeH-FD ist aufgebaut und vorhanden.
Nachbedingung	Im EU-Webportal können dispensierte E-Rezepte nicht erneut dispensiert werden. Der NCPeH-FD hat für die ein- und ausgehenden Nachrichten Einträge zu Non-Repudiation Origin und Receipt persistiert. Informationen über erfolgte Events (z.B. Transcoding, etc.) sind im HP Assurance Audit Trail Eintrag enthalten.

Abbildung 24: Sequenzdiagramm - Dispensierinformationen an Land-A übermitteln

[<=]

Vollständige Ansicht der hochauflösenden Version des Sequenzdiagramms:

https://github.com/gematik/api-ncpeh/blob/master/images/feature/eped-b/functional/Dispensierinformationen_an_Land-A_uebermitteln.svg

9 Datenschutz und Informationssicherheit

Das Anwendungsszenario E-Prescription/ E-Dispensation Land B soll es EU-Bürgern ermöglichen, ihre im EU-Heimatland (Land A) ausgestellten E-Rezepte auch in Deutschland (Land B) einlösen zu können. Nach Abgabe durch deutsche Apotheker werden die Dispensierinformationen ins EU-Heimatland zurückgemeldet. Die rechtlichen Grundlagen hierzu werden insbesondere in Kapitel 2.1.beleuchtet. 
Dieses Kapitel gibt einen Überblick über den Schutzbedarf der notwendigen Anwendungsprozesse sowie die darin verarbeiteten maßgeblichen Informationsobjekte, deren Schutzbedarf sowie Maßnahmen zum Schutz dieser. Konkret werden als besonders schützenswerte Daten personenbezogene medizinische Daten des EU-Bürgers verarbeitet. Ebenso werden personenbezogene Daten des LE-DE im Zuge der Authentifizierungs- und Autorisierungsprozesses verarbeitet. Diese Daten unterliegen der Datenschutzgrundverordnung der EU. Die Bewertung der Schutzbedarfe erfolgt nach den Methoden der gematik analog der Produkte der TI, da die personenbezogenen medizinischen Daten des EU-Bürgers als gleichwertig schützenswert zu denen deutscher Versicherter angesehen werden. Die Maßnahmen zum Schutz der Daten orientieren sich am Niveau der Schutzmaßnahmen der Telematikinfrastruktur.

9.1 Benötigte Komponenten und Dienste zur Umsetzung des Szenarios

Zur Umsetzung des Anwendungsszenarios werden die bereits weiter oben beschriebenen Dienste und Komponenten benötigt. Die Bestimmung des Schutzbedarfs der Komponente und Dienste erfolgt nach dem Maximumprinzip der verarbeiteten Informationsobjekte.

Tabelle 6: Schutzbedarf der Dienste und Komponenten 

9.2 Anwendungsprozesse und deren Schutzbedarf

Für den reibungslosen Ablauf des Anwendungsszenarios sind die im Kapitel 8.5 beschriebenen Anwendungsprozesse essentiell. Aufgrund dessen wird der Schutzbedarf der Verfügbarkeit aller Anwendungsprozesse dieses Anwendungsszenarios mit hoch bewertet. 

9.3 Maßgebliche Informationsobjekte und deren Schutzbedarf

Die maßgeblichen Informationsobjekte sowie deren Schutzbedarf sind in der nachfolgenden Tabelle ersichtlich. Die jeweiligen Domänenobjekte befinden sich, soweit vorhanden, zur besseren Nachvollziehbarkeit in Klammern. 

Tabelle 7: Schutzbedarfsfeststellung der maßgeblichen Informationsobjekte

9.4 Maßnahmen zum Schutz der Informationsobjekte

Nachfolgend sollen die Maßnahmen zum Schutz der Informationsobjekte beschrieben werden. Wie bereits erwähnt, werden die Daten von EU-Bürgern als gleichwertig schützenswert zu denen deutscher Versicherter angesehen, sodass auf bewährte Maßnahmen der Produkte der Telematikinfrastruktur zurückgegriffen wird.
Zur Gewährleistung der Vertraulichkeit und Integrität werden personenbezogene medizinische Daten ausschließlich über einen ASL-Kanal von der WebApp in die VAU des NCPeH-FD übertragen. Dies stellt sicher, dass durch den Endpunkt des ASL-Kanals in die vertrauenswürdige Ausführungsumgebung des NCPeH-Fachdienstes sowie die Inhaltsverschlüsselung keine unberechtigten Dritten auf die Daten zugreifen oder diese lesen können. Die Klartextverarbeitung ist somit nur lokal im Browser sowie in der VAU des NCPeH-FD möglich. 
Zum Schutz der im NCPeH-Proxy erzeugten NCPeH-Proxy Access-Token, welche es ermöglichen auf personenbezogene medizinische Daten zuzugreifen, wird eine vertrauenswürdige Ausführungsumgebung gefordert. Diese schließt vor allem unberechtigtem Zugriff durch den Betreiber aus. Die Anforderungen an die VAU werden entweder gleichwertig zum NCPeH-FD umgesetzt oder, falls es zum Zeitpunkt der Umsetzung einen HCC-Provider gibt, durch die Anforderungen der VAU der HCC-Spezifikation. Zusätzlich werden Maßnahmen bereits während der Authentifizierung ergriffen, um das unberechtigte Erhalten und Nutzen der Token zu verhindern. Hier wird auf die Sicherheitsverfahren DPoP und PKCE zurückgegriffen. Während DPoP sicherstellt, dass nur der berechtigte Client das NCPeH-Proxy-Access-Token nutzen kann, ist PKCE als vorgelagerter Sicherheitsmechanismus dafür verantwortlich, dass lediglich der Auth-Service des NCPeH-Proxy die ID-Token erhält, um diese in ein Access-Token umzuwandeln. 
Es erfolgt keine Persistierung personenbezogener Daten im NCPeH-Proxy, sondern lediglich die Verarbeitung personenbezogener Daten zu Zwecken der Authentisierung im Auth-Service.  Die Absicherung der personenbezogenen Daten erfolgt ebenfalls mittels der Verarbeitung innerhalb der VAU sowie einer Transportverschlüsselung zwischen den Diensten.  
Um das Ziel der Nichtverkettung zu wahren, werden die schützenswerten Daten innerhalb einer VAU verarbeitet oder lokal verarbeitet, verschlüsselt und sicher übermittelt. Dies verhindert die Möglichkeit von unberechtigter Profilbildung. Zu Zwecken der Anomalieerkennung werden personenbezogene Daten der Leistungserbringer pseudonymisiert ausgewertet. 
Zur Wahrung der Transparenz über den Zweck und der Rechtmäßigkeit der Verarbeitung der personenbezogenen (medizinischen) Daten sowie die Intervenierbarkeit zur Wahrung der Betroffenenrechte werden sowohl dem Leistungserbringer als auch dem EU-Bürger vor der Datenverarbeitung Informationen zur Verfügung gestellt. Die Informationen für den EU-Bürger werden sowohl von dessen EU-Zugehörigkeitsland als auch von Deutschland zur Verfügung gestellt. Es sind somit zwei PIN-Dokumente vorhanden. Die Dokumente werden vom LE-DE an den EU-Bürger digital oder physisch übergeben oder es wird dem EU-Bürger ein Link  oder eine Information bereitgestellt, welche ihm die Einsichtnahme beider Dokumente ermöglicht. Der EU-Bürger muss zur Wahrung der Betroffenenrechte sich an den NCPeH seines Zugehörigkeitslandes wenden. Der LE-DE erhält ebenfalls eine Information zur Wahrung seiner Betroffenenrechte. Diese wird vom Anbieter des NCPeH-FD bereitgestellt.

Zur Gewährleistung der sicheren Auslieferung und dem Schutz vor Manipulation der Webapp wurden Maßnahmen definiert. Auf die einzelnen Sicherheitsmechanismen wurde bereits in Kapitel 8.1.3 eingegangen.

Betriebliche Sicherheitsanforderungen an die Anbieter der Dienste und Komponenten ergeben sich weiterhin aus der übergreifenden gematik-Spezifikation DS-Anbieter.
Sicherheitsanforderungen an den sicheren Entwicklungsprozess der Hersteller von Komponenten und Dienste ergeben sich aus der übergreifenden gematik-Spezifikation DS-Hersteller.

9.5 Erweiterung der Protokollierung

Für das Anwendungsszenario ePeD-B ist kein eHDSI Patient Privacy Audittrail Eintrag notwendig, da die Einsichtnahme über den NCPeH-Land A (des Heimatlandes) erfolgt. Für das Anwendungsszenario wird jedoch ein Protokolleintrag für den deutschen Leistungserbringer erstellt um bei Unstimmigkeiten dem Leistungserbringer Nachvollziehbarkeit zu ermöglichen. Das Protokoll wird HP Assurance (Healthcare Professional Assurance) genannt. Hier werden neben der Rolle und den Identifikationsdaten des Leistungserbringers, spezifischen Fehlermeldungen unter anderem auch der Patient Identifier, also die spezifischen Suchparameter aus der ISM enthalten sein. Die Festlegung der Protokollierungsinhalte wird in den europäischen Spezifikationen geregelt. Zur Einsichtnahme der Protokolle wendet sich der LE-DE an den Betreiber des NCPeH-FD Deutschland und stellt dort eine Anfrage. Bei berechtigtem Interesse und nach erfolgreicher Identitätsprüfung durch die nationale Kontaktstelle (DVKA) wird die Einsichtnahme ermöglicht. 

9.6 Grenze der Sicherheitsleistung

Da der Patient Privacy Audit Trail Eintrag aufgrund der eHDSI-Spezifikation nur im Zugehörigkeitsland des EU-Bürgers erzeugt und dem EU-Bürger zur Verfügung gestellt wird, können die Betroffenenrechte vollumfänglich auch lediglich dort ausgeübt werden. 
Da die Maßnahmen zum Schutz des autorisierten Zugriffs von jedem Mitgliedsstaat selbst bestimmt werden, kann die Autorisierungsmaßnahme nicht durch diese Spezifikation vorgegeben werden. Die Verantwortung zusätzliche Schutzmechanismen zu etablieren, wie es Deutschland getan hat, liegt somit beim EU-Zugehörigkeitsland. 
Der LE-DE hat trotz allen von der gematik geforderten Sicherheitsmechanismen weiterhin für ein angemessenes Sicherheitsniveau der IT-Infrastruktur in der Leistungserbringerumgebung zu sorgen und somit eine Mitwirkungspflicht, da lokale Sicherheitslücken nicht vollständig durch zentrale Maßnahmen ausgeglichen werden können.

10 Anhang A – Verzeichnisse

10.1 Abbildungsverzeichnis

10.2 Tabellenverzeichnis

10.3 Abkürzungen

10.4 Inkludierte Dokumente

Die nachfolgende Tabelle enthält diejenigen Dokumente, die in dieses Dokument virtuell inkludiert (und somit Bestandteil dieses Dokument sind), jedoch einen anderen Bereitstellungsort (z.B. zwecks besserer Lesbarkeit/Nachvollziehbarkeit/Postprocessing-Möglichkeit) haben.

10.5 Referenzierte Dokumente

10.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

10.5.2 Weitere Dokumente

'