Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

NCPeH-Fachdienst

Version
2.1.0
Revision
1391675
Stand
10.10.2025
Status
zur Abstimmung freigegeben
Klassifizierung
öffentlich_Entwurf
Referenzierung
gemSpec_NCPeH_FD

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Versicherte im deutschen Gesundheitssystem sollen die Möglichkeit bekommen, die eigenen medizinischen Daten auch im EU-Ausland sinnvoll nutzen zu können. Um das zu erreichen, ist es notwendig, die entsprechenden Voraussetzungen zu schaffen, damit die Telematikinfrastruktur (TI) an die europäische Gesundheitsinfrastruktur eHealth Digital Services Infrastructure (eHDSI), auch als MyHealth@EU bezeichnet, angebunden werden kann.

Um einen vernetzten digitalen Binnenmarkt zu verwirklichen, wurde im Rahmen des Infrastrukturprogramms Connecting Europe Facility (CEF, 2014-2021) die sektorspezifische eHDSI entwickelt. Die unmittelbare Kooperation zwischen den EU-Mitgliedstaaten und der Europäischen Kommission verfolgt das Ziel, einen zur Regelversorgung geeigneten Austausch von Versichertendaten umzusetzen. Dieser umfasst die ersten medizinischen Basisanwendungen: die Patient Summary (PS) und das elektronische Rezept (ePrescription) einschließlich der Dispensationsmeldung (eDispensation).

Der Austausch medizinischer Daten und die damit einhergehende Bereitstellung von elektronischen Dienstleistungen soll durch die von den beteiligten EU-Mitgliedstaaten individuell eingerichteten und betriebenen nationalen Kontaktstellen – National Contact Point for eHealth (NCPeH) – unterstützt werden. Der NCPeH unterstützt die eHDSI als landesspezifischer, fachlicher Vermittler, rechtlicher Ankerpunkt sowie technischer Dienstleister für Kommunikations- und Sicherheitsaufgaben (EU Gateway).

Im von der eHDSI spezifizierten Daten- und Kontrollfluss vermitteln die NCPeH zwischen den bestehenden nationalen Gesundheitsinfrastrukturen sowie deren digitalen Diensten. Zur Beschleunigung der Bereitstellung von patientenbezogenen Gesundheitsdaten sind Hilfsmittel seitens des durch das Land-A betriebenen NCPeH-Fachdienst (FD) (ausstellendes oder datenoffenbarendes Land) sowie zur Abfrage und Anzeige von Daten auf Seiten des NCPeH Land-B (datenempfangendes Land) integriert.

Der NCPeH soll zwei grundlegende fachliche Rollen unterstützen. In der Rolle als NCPeH Land-A werden Gesundheitsdaten der Versicherten aus Deutschland zum Abruf durch andere NCPeH bereitgestellt. In der Rolle des NCPeH Land-B werden Gesundheitsdaten über ausländische Patienten vom zuständigen NCPeH Land-A abgefragt. In beiden Rollen werden zusätzliche Aufgaben wahrgenommen, wie bspw. die Transkodierung zwischen den deutschen und europäischen medizinischen Kodesystemen beim Abruf sowie die Bereitstellung technischer Sicherheitsleistungen.

1.1 Zielsetzung

Die vorliegende Spezifikation beschreibt die Anforderungen zu Herstellung, Test und Betrieb des NCPeH-FD.

1.2 Zielgruppe

Das Dokument richtet sich zum Zwecke der Realisierung an Anbieter, Betreiber und Hersteller des NCPeH-FD.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen an den NCPeH-FD.

Wichtiger Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistung.

1.4 Abgrenzungen

Die vom NCPeH-FD bereitgestellten (angebotenen) Schnittstellen, über die die grenzüberschreitende Datenübertragung mit NCPeH anderer europäischen Mitgliedstaaten erfolgt, sind durch die eHDSI spezifiziert und haben normativen Charakter. In diesem Dokument wird auf die eHDSI-Spezifikationen referenziert (siehe auch Kapitel [8.5.2 Weitere Dokumente]).

Nationale vom NCPeH-FD verwendete Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe Kapitel [8.5.1 Dokumente der gematik]).

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

• Der Abruf von Daten aus der elektronischen Patientenkurzakte (ePKA) aus Deutschland in Notfallsituationen ("Emergency") durch Leistungserbringer in anderen europäischen Mitgliedsländern (LE-EU),
• Regelung zur Transformierung der Komposition KBV_PR_MIO_NFD_Composition_NFD des FHIR-Bundle ePKA MIO in das eHDSI CDA Pivotformat Level 3,
• Regelung zur Transformation und (semantischen) Transkodierung von strukturierten Inhalten der Komposition KBV_PR_MIO_NFD_Composition_NFD des FHIR-Bundle ePKA MIO in das eHDSI CDA Pivotformat Level 3,
• Regelung zur Transformierung von Inhalten der Komposition KBV_PR_MIO_NFD_Composition_NFD des FHIR-Bundle ePKA MIO ins eHDSI CDA Pivotformat Level 1 embedded PDF/A,
• Bereitstellung und Auswertung von Audit Trails und Non-Repudiation-Einträgen,
• Definition und Festlegung von Technologien von Administrationsschnittstellen innerhalb der Umgebung des NCPeH-FD des Anbieters,
• Vertreterregelung (Next of Kin),

sowie

• Schreibender Zugriff auf die ePKA-Anwendung durch LE-EU,
• Zugriff auf andere Fachanwendungen eines Versicherten in DE,
• Umsetzung der grenzüberschreitenden Fachanwendung ePrescription/eDispensation Land-B,
• Es erfolgt keine Umsetzung des optionalen Anwendungsfalls "Option to discard a previously performed dispensation" gemäß [eHDSI_Requirements_Catalogue#07.04],
• Für das europäische Anwendungsszenario ePrescription/eDispensation dürfen folgende E-Rezepte gemäß [MyHealth@EU_Scope_and_Business_Goals#"MyHealth@EU OUT OF SCOPE description"] nicht verarbeitet werden:
  
• Betäubungsmittel,
• Arzneimittel, die nach ärztlicher Verschreibung oder nach den Vorschriften eines Arzneibuchs für den Versicherten zubereitet werden (bezeichnet als "formula magistralis" oder "extemporale Zubereitungen"),
• Arzneimittel, die nicht durch ein industrielles Verfahren hergestellt oder bei deren Herstellung kein industrielles Verfahren angewandt wurde,
• Arzneimittel, die nicht als Humanarzneimittel eingestuft sind,
• Lesender und schreibender Zugriff für Leistungserbringer in Deutschland (LE-DE) auf äquivalente ePKA-Daten, die sich in elektronischen Gesundheitsinfrastrukturen anderer EU-Mitgliedstaaten befinden (Szenario Patient Summary Land-B),
• Spezifikationen oder Konzeptionen zum ePA-Aktensystem, zur ePKA-Anwendung im ePA-Aktensystem sowie zum FdV (Frontend des Versicherten) des ePA-Aktensystems.

1.5 Methodik

Die Spezifikation ist im Stil einer RFC-Spezifikation verfasst. Dies bedeutet: 

• Der gesamte Text in der Spezifikation ist für den Anbieter und den Hersteller des Produktes NCPeH-FD, als auch für dessen Betreiber gemäß [gemKPT_Betr] verbindlich zu betrachten und gilt zusätzlich zu den verbindlichen Steckbriefen von Produkt- und Anbietertyp des NCPeH-FD.
• Die Verbindlichkeit SOLL durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet werden. 
• Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet.
• Die Schlüsselworte KÖNNEN außerdem um Pronomen in Großbuchstaben ergänzt werden, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

1.5.1 Anwendungsfälle

Anwendungsfälle als Ausdruck normativer Festlegungen werden durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden im Rahmen einer Abnahme mit dem in diesem Dokument spezifizierten Testaufbau durchgeführt.

Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel des Anwendungsfalles / Akzeptanzkriteriums>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier:
• Bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
• Der Identifier eines Akzeptanzkriteriums wird von System vergeben, z.B. die Zeichenfolge 'ML_' gefolgt von einer Zahl,
• Titel des Anwendungsfalles: Ein Titel, welcher zusammenfassend den Inhalt beschreibt,
• Text / Beschreibung: Ausführliche Beschreibung des Inhalts. Kann neben Text Tabellen, Abbildungen und Modelle enthalten.

Dabei umfasst der Anwendungsfall sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

1.5.2 Technische Use Cases

Jeder Anwendungsfall enthält eine Beschreibung des Standardablaufs (Gutfall). Der Standardablauf besteht aus Aktivitätsschritten, die auf "Technische Use Cases" (TUC) verweisen. Die TUCs sind im Kapitel [6 Funktionsmerkmale] beschrieben. Die TUCs sind eigene modulare Funktionsmerkmale bzw. Verantwortungsbereiche, die von verschiedenen Anwendungsfällen oder anderen TUC wiederverwendet werden können. In diesen Verantwortungsbereich greifen keine anderen Funktionsmerkmale (TUC) ein.

TUCs werden im Dokument nach folgendem Muster dargestellt:

<TUC_NCPeH_XXX>: <Titel des TUC>

• Relevante Übergreifende Festlegungen,
• Ablauf des TUC inkl. spezifischer Fehlerbehandlung,
• Ausgabeparameter des TUC.

Benutzte Schnittstellen und Operationsbezeichnungen in diesem Dokument auf Seiten der eHDSI orientieren sich anhand eHDSI- bzw. IHE-Namensgebung. Bei Schnittstellen zur TI werden die Bezeichnungen der TI genutzt.

1.5.3 Anforderungen

Zusätzlich zu der obigen Festlegung kommen in einigen Abschnitten dieses Dokumentes weiterhin dedizierte Anforderungen zum Einsatz. Dies ist vor allem dann der Fall, wenn damit ein besonderes Prüfverfahren verknüpft ist (z. B. Produktgutachten), dass sich entsprechend auch im Produkttypsteckbrief [gemProdT_NCPeH_FD] widerspiegeln soll.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

An einigen Stellen wird im Dokument auf übergreifende Anforderungen in anderen Dokumenten der TI verwiesen. In diesen referenzierten Anforderungen können teilweise Formulierungen auftauchen wie z.B. "Produkt der TI", "Produkttypen der TI", "Dienste der TI". Mit Nennung dieser Anforderungen in diesem Dokument gelten diese auch für den NCPeH-FD, unabhängig davon, ob der NCPeH-FD als Produkt der TI gilt oder nicht.

2 Systemüberblick

Der NCPeH-FD ermöglicht es Versicherten, ihre Gesundheitsdaten in andere europäische Mitgliedstaaten mitzunehmen und sie dort mit behandelnden Leistungserbringern (LE) zu teilen. Der NCPeH-FD ist in seiner Rolle als Service Provider beteiligt an der europäischen eHealth Digital Services Infrastructure (eHDSI). Dabei ist der NCPeH-FD zuständig für eine interoperable Kommunikation und Datenaustausch zwischen der eHDSI und TI. Die Gesundheitsdaten der Versicherten werden in Fachdiensten der TI (z.B. ePA-Aktensystem oder E-Rezept-FD) verwaltet. Anfragen von anderen EU-Ländern (Land-B), in denen die medizinische Behandlung einer in Deutschland versicherten Person stattfindet, werden vom NCPeH-FD unter Einhaltung von Sicherheitsschutzzielen (z.B. Integrität, Authentizität, etc.) geprüft und an den entsprechenden Fachdienst in der TI weitergeleitet, in dem die angeforderten Gesundheitsdaten der Versicherten enthalten sind.

Jeder NCPeH benötigt als zugelassener Teilnehmer an der eHDSI einen Zugang zu TESTA-ng mittels eines sogenannten "Turnkey Access Point" (TAP), um darüber sicher mit den NCPeH anderer EU-Länder und den zentralen Diensten der eHDSI kommunizieren zu können. Den Zugang zu TESTA-ng gewährt die Kommission einem Mitgliedstaat, indem sie mit ihm ein "Memorandum of Understanding" (MoU) aufsetzt, in dem die Pflichten aller TESTA-ng Nutzer festgehalten sind. Dieses MoU muss von einer Regierungsorganisation des Mitgliedstaates unterschrieben werden. Ein eigener TESTA-ng Zugang des Bundesgesundheitsministeriums ist derzeit nicht vorhanden. Es wurde in Deutschland jedoch ein sog. "Bund-Länder-Kommunen-Verbindungsnetz" (Netze des Bundes (NdB)) aufgebaut, welches wiederum an einen TESTA-TAP angebunden ist. Die DVKA (eine Abteilung des GKV-SV) verfügt bereits im Rahmen des "elektronischen Austauschs von Sozialversicherungsdaten" (Electronic Exchange of Social Security Information) über einen Zugang zum NdB.

Mit der Anbindung an das Netz der TESTA-ng gewährleistet der NCPeH-FD als Bindeglied zwischen der TI und der nationalen Gesundheitsinfrastruktur eines anderen EU-Mitgliedstaates eine sichere Übertragung von Identitäts- und Gesundheitsdaten. Der NCPeH-FD realisiert die Vertraulichkeit und Integrität der verarbeiteten Daten über das Konzept der vertrauenswürdigen Ausführungsumgebung (VAU), die eine vertrauenswürdige Verarbeitung und verschlüsselte Persistierung der Daten sicherstellt.

Zusätzlich protokolliert der NCPeH-FD alle Ereignisse im Zusammenhang mit der Verarbeitung von Identitäts- und Gesundheitsdaten. Dies impliziert das Sammeln vollständiger und zeitbezogener Informationen über die Aktionen und Zustände in Bezug auf den NCPeH-FD (Audit Trails). Neben der Protokollierung führt der NCPeH-FD eine Historie von digitalen Beweisen (Evidenzen), so dass nachvollzogen werden kann, welche Akteure eine Aktion im Zusammenhang mit einer eHDSI-NCPeH-Transaktion durchgeführt haben.

Im Zuge des kontinuierlichen Ausbaus und der Integration weiterer grenzüberschreitender Anwendungsszenarien werden deren Systemübersichten aus Sicht des NCPeH-FD in den folgenden Unterkapiteln aufgenommen bzw. bestehende Systemübersichten entsprechend den Anforderungen des eHDSI und der TI angepasst.

2.1 Patient Summary Land-A

Die zentralen Funktionen der ePA für alle (ePA-Aktensystem) sind das integre Management von definierten Metadaten und den medizinischen Dokumenten als auch die Unterstützung von digitalen Versorgungsprozessen. Das ePA-Aktensystem (ePA-AS) wird den LE und anderen anerkannten Akteuren des Gesundheitswesens zur Verfügung gestellt. Für den NCPeH-FD ist dies der Zugriff auf die elektronische Patientenkurzakte (ePKA) als technischer Client. Gegenüber dem ePA-Aktensystem agiert der NCPeH-FD als ein anerkannter ePA Client. Der NCPeH-FD bietet den LE-EU als Nutzer den Zugang zur ePKA MIO des Versicherten an. Dabei greift der NCPeH-FD als Repräsentant von Land-B in der TI über ein Kommunikationsprotokoll mit Ende-zu-Ende-Verschlüsselung (VAU-Protokoll) auf die relevanten Dienste der ePA zu.

Die Authentifizierung des Land-B erfolgt durch den zentralen Identity Provider (IDP-Dienst) der TI. Als Authentisierungsmittel verwendet der NCPeH-FD das im HSM für das Land-B hinterlegte AUT-Zertifikat des Zertifikatsprofils SM-B NCPeH, um damit die TI-Identität des Land-B gegenüber dem IDP-Dienst nachzuweisen. Der Authentifizierungsprozess erfolgt entsprechend dem OpenID Connect Standard sowie dem Challenge-Response Verfahren. Bei erfolgreicher Authentifizierung erhält das ePA-Aktensystem vom IDP-Dienst ein ID_TOKEN mit relevanten Identitätsmerkmalen. Anhand der Identitätsmerkmalen kann im ePA-AS überprüft werden, ob der NCPeH-FD (als Repräsentant für Land-B in der TI) befugt ist auf ePKA MIO zuzugreifen. Wenn dies der Fall ist, wird im ePA-AS eine User Session für das Land-B gestartet. 

In der User Session können mehrere Health Record Contexts zu verschiedenen Aktenkonten parallel aufgebaut werden, auf die LE-EU aus dem Land-B dann zugreifen können. Im Health Record Context erfolgt die Verarbeitung der (medizinischen) Daten eines Aktenkontos. In einem Health Record Context werden niemals Daten aus unterschiedlichen Aktenkonten verarbeitet.

Die finale Autorisierung des Land-B für den Zugriff durch NCPeH-FD auf ePKA MIO des Versicherten kann vom ePA-Aktensystem erst erfolgen, wenn der Versicherte selbst über sein ePA FdV eine Zugriffsberechtigung (Befugnisvergabe) für das Land-B erteilt hat. Die Dauer der Zugriffsberechtigung ist fest auf eine Stunde begrenzt. Bei jeder Erteilung oder Verlängerung einer Zugriffsberechtigung durch den Versicherten wird ein neuer Zugriffscode generiert. Der Zugriffscode ist mit der Dauer der Zugriffsberechtigung, der KVNR des Versicherten und dem angegebenen Land-B gekoppelt. Nach Ablauf oder Widerruf der Zugriffsberechtigung durch den Versicherten wird auch der Zugriffscode automatisch ungültig. Dadurch können die LE-EU aus dem Land-B durch den NCPeH-FD keinen weiteren Zugriff auf die ePA des Versicherten erhalten.

Die Prüfung von Zugriffsautorisierungen (inkl. Zugriffscode) auf ePKA MIO des Versicherten erfolgt durch den ePA XDS Document Service. Dabei wird vorausgesetzt, dass der NCPeH-FD den Zugriffscode an den ePA XDS Document Service übermittelt hat, welchen der NCPeH-FD aus der eHDSI-Anfrage des NCPeH Land-B übernommen hat. Nach erfolgreicher Prüfung der Autorisierung erfolgt die Bereitstellung des ePKA MIO des Versicherten.

Der Abruf von Metadaten und ePKA MIO des Versicherten durch NCPeH-FD aus dem ePA XDS Document Service erfolgt gemäß den Festlegungen der IHE und ePA.

Durch die Übermittlung der vom NCPeH-FD transkodierten und transformierten ePKA-Daten des Versicherten an das jeweilige NCPeH Land-B stellt der NCPeH-FD sicher, dass die Bedeutung und Aussagekraft der Inhalte des ePKA MIO erhalten bleibt. Zu diesem Zweck konvertiert der NCPeH-FD die ePKA-Daten in das normative und interoperable eHDSI-Pivot-Format und verwendet die von den am eHDSI beteiligten europäischen Mitgliedstaaten vereinbarten Kodierungssysteme.

Abbildung 1: Architektur des NCPeH-FD Patient Summary Land-A

Abbildung 1 zeigt die Architektur des NCPeH-FD für das Anwendungsszenario Patient Summary Land-A. Orange dargestellt sind logische Komponenten des NCPeH-FD. Die grün dargestellten Systeme stellen Produkttypen der TI dar. Die grau dargestellten Systeme befinden sich außerhalb der Systemgrenzen des NCPeH-FD. Die blau dargestellten Schnittstellen (blaue Linien) sind bereits durch die eHDSI spezifiziert, sie werden in diesem Dokument referenziert. Die Nutzung der rot dargestellten Schnittstellen (rote Linien) durch den NCPeH-FD werden in diesem Dokument spezifiziert. Die schwarz dargestellten Verbindungen sind in Verantwortung des Anbieters und werden vom NCPeH-FD Betreiber bereitgestellt.

2.2 ePrescription/eDispensation Land-A

Versicherte aus Deutschland sollen die Möglichkeit haben, ihre elektronischen Rezepte (E-Rezept) in einer Apotheke ihrer Wahl im europäischen Ausland einzulösen. Für dieses Anwendungsszenario stehen den Versicherten die EU-Mitgliedstaaten zur Verfügung, mit denen bilateral ein Agreement zum Datenaustausch zum Abruf der in Deutschland ausgestellten E-Rezepte getroffen wurde. Anhand dieser Liste der Länder können die Versicherten selbst wählen, in welchem verfügbaren europäischen Mitgliedstaat sie ihre E-Rezepte einlösen möchten. Die Nutzung dieser Option ist freiwillig, erfordert jedoch eine vorherige Erteilung der Zugriffsberechtigung durch den Versicherten für den jeweiligen europäischen Mitgliedstaat.

Verwaltung von Zugriffsberechtigungen für E-Rezepte

Vor dem Abruf oder Einlösen von E-Rezepten in anderen EU-Mitgliedstaaten (Land-B) erteilt eine versicherte Person über ihr E-Rezept-FdV einmalig die Einwilligungserklärung in die Nutzung der Anwendung ePrescription/eDispensation. Die Gültigkeit der Einwilligungserklärung ist nicht länderspezifisch. Danach trifft die Person über ihr E-Rezept-FdV die Entscheidung, aus welchem anderen europäischen Mitgliedstaat die Apotheker bzw. Leistungserbringer (LE-EU) auf ihre E-Rezepte zugreifen dürfen. Die Speicherung von Zugriffsberechtigungen erfolgt technisch direkt im E-Rezept-FD. Mit jeder Erteilung einer Zugriffsberechtigung wird ein neuer Zugriffscode generiert. Die erteilte Zugriffsberechtigung inkl. Zugriffscode ist zeitlich auf eine Stunde begrenzt. Mit der Erstellung jeder Zugriffsberechtigung werden Informationen zur KVNR der versicherten Person, zum Ländercode des berechtigten EU-Mitgliedstaates (Land-B), Zugriffscode und Zeitpunkt der Erstellung der Berechtigung gespeichert. Die gespeicherten Informationen inkl. Zugriffscode werden der Person auf ihrem E-Rezept-FdV angezeigt.

Nach Ablauf oder Widerruf der Zugriffsberechtigung durch die versicherte Person wird auch der Zugriffscode automatisch ungültig. Dadurch können die LE-EU keinen weiteren Zugriff auf die E-Rezepte des Versicherten erhalten. Versicherte Personen haben auf ihrem E-Rezept-FdV die Möglichkeit, eine gültige Zugriffsberechtigung mit einer neuen Zugriffsberechtigung zu überschreiben. Dabei wird immer ein neuer Zugriffscode generiert.

Die versicherte Person übergibt die Zugriffsdaten (KVNR und generierter Zugriffscode) an den LE-EU in der Apotheke durch Vorzeigen oder Mitteilen. Durch die Übergabe der Zugriffsdaten hat die Person in dem konkreten EU-Land die Möglichkeit zu steuern, welcher konkrete LE-EU dieses Landes auf seine deutschen E-Rezepte zugreifen darf. Der Abruf oder das Einlösen von E-Rezepten in einer Apotheke im Ausland setzt voraus, dass die Apotheke beim Zugriff auf E-Rezepte die Zugriffsdaten über die Schnittstellen der eHDSI und des NCPeH-FD an den E-Rezept-FD übermittelt. 

Berechtigter Zugriff auf E-Rezepte

Der Zugriff auf E-Rezepte der versicherten Person erfolgt für die LE-EU mittels NCPeH-FD. Dieser enthält die spezifische Clientfunktionalität für E-Rezepte und baut die Verbindung zu zentralen Diensten der TI auf. Eine Nutzung der Schnittstellen des E-Rezept-FD durch den NCPeH-FD ist nur nach erfolgreicher Autorisierung durch den IDP-Dienst möglich.

Der NCPeH-FD initiiert den Authentisierungsprozess gegenüber dem IDP-Dienst entsprechend dem OpenID Connect Standard sowie dem Challenge Response-Verfahren. Als Authentisierungsmittel verwendet der NCPeH-FD das im HSM für das Land-B hinterlegte AUT-Zertifikat des Zertifikatsprofils SM-B NCPeH, um damit die TI-Identität des Land-B gegenüber dem IDP-Dienst nachzuweisen. Eine Interaktion mit dem Nutzer im Hintergrund ist nicht erforderlich.

Der IDP-Dienst agiert dabei als OAuth2 Authorization Server für das E-Rezept und prüft in dieser Funktion, ob das vorgetragene X.509-nonQES-Signatur-Zertifikat zeitlich gültig ist und ob seine Integrität sichergestellt ist.

Der IDP-Dienst führt die Identifikation des NCPeH-FD als den Repräsentanten des Land-B innerhalb der TI durch und stattet diesen anschließend mit ID_TOKEN gemäß [openid-connect-core 1.0 # IDToken] und ACCESS_TOKEN gemäß [RFC6749#section-1.4] und [RFC6749#section-5] aus. Dazu wird ein "Authorization Code Grant" gemäß [RFC6749#section-4.1] genutzt. Um dem erforderlichen Sicherheitsniveau gerecht zu werden, wird zudem PKCE (Proof Key for Code Exchange by OAuth Public Clients) gemäß [RFC7636] angewandt.

Der IDP-Dienst verwendet ACCESS_TOKEN, um die Autorisierung des Zugriffs durch den NCPeH-FD auf den E-Rezept-FD sicherzustellen. Der ACCESS_TOKEN wird vom NCPeH-FD als Bearer Token für den Zugriff auf E-Rezepte versicherten Personen des E-Rezept-FD verwendet. Der ACCESS_TOKEN enthält die bestätigten Identitätsmerkmale, die der E-Rezept-FD benötigt, um die Berechtigung des NCPeH-FD abzuleiten und zu verifizieren. 

Der E-Rezept-FD prüft neben der Validierung des ACCESS_TOKEN auch die zusätzlich hinterlegten Berechtigungsinformationen für die konkrete versicherte Person auf Gültigkeit (KVNR der versicherten Person, Ländercode des berechtigten EU-Mitgliedstaates (Land-B), Zugriffscode und zeitliche Gültigkeit der Berechtigung). Bei erfolgreicher Prüfung wird dem NCPeH-FD der Zugriff auf die angeforderten E-Rezepte der versicherten Person gewährt.

FHIR-Ressourcen

Für den Abruf von E-Rezepten aus dem E-Rezept-FD in diesem Anwendungsszenario wird der Standard FHIR (Fast Healthcare Interoperability Resources) verwendet. In FHIR werden Datenstrukturen und Elemente in "Ressourcen" beschrieben, welche über standardisierte Schnittstellen übertragen werden können. Die Daten werden dabei in XML repräsentiert.

Der NCPeH-FD ruft die Ressource FHIR-Bundle über die entsprechende Schnittstelle des E-Rezept-FD ab. Für eine Beschreibung der FHIR-Ressource siehe [FHIR_Resource_Bundle].

Architektonische Übersicht

Abbildung 2: Architektur des NCPeH-FD ePrescription/eDispensation Land-A

Die Abbildung stellt die Architektur für den NCPeH-FD Anwendungsszenario ePrescription/eDispensation Land-A dar. Orange dargestellt sind logische Komponenten des NCPeH-FD. Die grün dargestellten Systeme stellen Produkttypen der TI dar. Die grau dargestellten Systeme befinden sich außerhalb der Systemgrenzen des NCPeH-FD. Die blau dargestellten Schnittstellen (blaue Linien) sind bereits durch die eHDSI spezifiziert, sie werden in diesem Dokument referenziert. Die Nutzung der rot dargestellten Schnittstellen (rote Linien) durch den NCPeH-FD werden in diesem Dokument spezifiziert. Die schwarz dargestellten Verbindungen liegen in der Verantwortung des Anbieters und werden vom Betreiber des NCPeH-FD bereitgestellt.

3 Systemkontext

3.1 Nachbarsysteme

Der NCPeH-FD nutzt Schnittstellen der folgenden Produkttypen der TI:

• ePA-Aktensystem mit den Diensten:
• Information Service,
• Authorization Service,
• XDS Document Service,
• E-Rezept-Fachdienst (FD),
• Zentraler IDP-Dienst,
• Namensdienst,
• TSP X.509 nonQES,
• TSL-Dienst,
• Betriebsdatenerfassung.

Der NCPeH-FD ist über einen Sicheren Zentralen Zugangspunkt (SZZP) an das zentrale Netz der TI (siehe [gemSpec_Net#3]) angebunden. Er fungiert als Document Consumer für die ePA-AS und den E-Rezept-FD. Der NCPeH-FD nutzt den IDP-Dienst, um sich gegenüber ePA-AS und E-Rezept-FD zu authentisieren bzw. zu autorisieren. Die Dienste der zentralen TI, wie Namensdienst, TSP X.509 nonQES und TSL-Dienst, werden über die logische Komponente National Gateway genutzt.

Der NCPeH-FD zeichnet sein Leistungsverhalten in den Betriebsdaten auf und stellt diese dem Dienst Betriebsdatenerfassung zur Verfügung. Aus den Rohdaten können die Leistungsparameter für den Produkttyp NCPeH-FD ermittelt werden und als Grundlage für die Feststellung der Einhaltung des Service Levels dienen.

Wenn Gesundheitsdaten von Versicherten über den NCPeH-FD grenzüberschreitend mit einem weiteren EU-Land ausgetauscht werden sollen, ist es notwendig, einen entsprechenden Eintrag für das EU-Land im FHIR VZD anzulegen. Ist der Eintrag erstellt, können Versicherte in der FdV nach dem EU-Land suchen. Der Betreiber des NCPeH-FD MUSS über einen organisatorischen Prozess (z.B. Service Request) bei der gematik beantragen, einen Eintrag in der FHIR VZD zu erstellen oder zu verwalten. Der Eintrag MUSS Informationen über das EU-Land und den grenzüberschreitenden Dienst, auf den das EU-Land zugreifen darf, enthalten.

In Richtung der eHDSI kommuniziert NCPeH-FD mit den NCPeH Land-B anderer europäischer Mitgliedstaaten über die eigene logische Komponente eHDSI Service Provider. Die Kommunikation mit dem eHDSI Configuration Service und eHDSI Terminology Service erfolgt ebenfalls über die logische Komponente eHDSI Service Provider des NCPeH-FD.

3.2 Akteure

Im folgenden Abschnitt werden die am NCPeH-FD beteiligten Akteure betrachtet. Ein Akteur ist eine Person, Institution oder ein technisches System, die/das mit dem NCPeH-FD direkt oder indirekt über einen anderen Akteur interagiert. Diese Interaktion wird durch einen Anwendungsfall ausgelöst.

Tabelle 1: TAB_NCPeH_Übersicht_NCPeH-FD_Akteure

4 Übergreifende Festlegungen

Das folgende Kapitel beschreibt übergreifende Anforderungen an den NCPeH-FD zur Unterstützung der Fachlogik.

4.1 Anbindung an die eHDSI

Analog zu den gesetzlichen Vorgaben der Europäischen Union gilt es zwingend, auch die Spezifikation der eHDSI zu beachten.

Als fundamentale Dokumente zur Spezifikation sind die [eHDSI_System_Architecture_Specifications] und [eHDSI_NCPeH_Architecture_Specification] zu beachten. Der [eHDSI_Requirements_Catalogue] spiegelt das Dokument mit den allgemeinen Anforderungen wider. Spezielle Anforderungen, wie z.B. an die Sicherheit und den Datenschutz sind in den entsprechenden Detaildokumenten zu finden, hier sei beispielsweise die [eHDSI_Security_Services_Specification] genannt. Wenn der NCPeH-FD in den Betrieb überführt werden soll, kann zur Erfassung der notwendigen Schritte auf das [eHDSI_Starting_Toolkit] zurückgegriffen werden.

Einen guten Überblick über die bestehenden Spezifikationen für den Betreiber des NCPeH-FD zur Herstellung der technischen und semantischen Interoperabilität innerhalb der eHDSI bietet [eHDSI_Specifications].

4.1.1 Konfigurationsparameter

Hinweis: Der detaillierte Ablauf der Verwaltung von Konfigurationsparametern ist im Anwendungsfall [5.3.4 NCPeH.UC_8 - Konfigurationsparameter verwalten] beschrieben.

4.1.2 Datenaustausch mit zugelassenen EU-Ländern

Die Entscheidung über den Austausch von Gesundheitsdaten mit einem bestimmten europäischen Land obliegt Deutschland. Daher ist es erforderlich, dass der NCPeH-FD die Länderidentitäten verwaltet, mit denen ein grenzüberschreitender Datenaustausch zulässig ist.

Hinweis: Die Zuordnung der LOINC-Codes zu den entsprechenden grenzüberschreitenden Gesundheitsanwendungen ist gemäß den Vorgaben in [eHDSI_NCPeH_Components#"MyHealth@EU CDA Documents and Codes"] festgelegt.

4.1.3 eHDSI Basisleistungen

Die Schnittstellen des NCPeH-FD sind durch IHE XCPD, IHE XCA und IHE XDR Profile definiert. In Anlehnung an das SOA-Modell werden die Nachrichtenstrukturen (Header und Body) durch IHE definiert. In eHDSI wird der SOAP-Header durch WS-Security und SAML geregelt. Der SOAP-Body wird durch den Standard definiert, der die Transaktion regelt und kann auf ebXML für XCA (zum Abrufen von medizinischen Versichertendaten) oder auf HL7V3 für XCPD-Abfragen (zur Versichertenidentifizierung) basieren.

Die eHDSI beschreibt die Nachrichtenstruktur, wie sie zwischen zwei NCPeH (Service Consumer und Service Provider) fließen soll und stellt in [eHDSI_Messaging_Profile#1] Vorgaben zur Implementierung der eHDSI-Nachrichtenstrukturen und zur Verwendung konkreter Sicherheitsstandards zur Verfügung. Außerdem Vorgaben zur Transport- und Nachrichtenschicht, Einbettung von Sicherheitstoken und allgemeine Verarbeitung von SOAP-Nachrichten sind in [eHDSI_Messaging_Profile#5] enthalten. Weiterführende normative Vorgaben zur Nutzung und Verarbeitung der eHDSI-Nachrichtenformate, Transportschicht, SOAP Binding, SAML-Assertions und Signaturerstellung sind in [eHDSI_NCPeH_Components#4.3] enthalten.

4.1.3.1 Sicherer Kanal: TESTA-ng und TLS

Das Vertrauen zwischen Service Consumer, Service Provider und zentralen Diensten der eHDSI basiert auf gegenseitig vertrauenswürdigen und sicheren Kanälen zwischen den zugrundeliegenden Netzknoten.

4.1.3.2 Zeitsynchronisation

Innerhalb des eHDSI Circle of Trust sind alle Clients und Services (Service Consumer, Service Provider, zentrale Dienste) auf eine konsistente Systemzeit angewiesen.

4.1.3.3 eHDSI Identifier

4.1.3.4 Allgemeine Fehlerbehandlung

Hinweis: Die konkrete Ausprägung der Fehlerbehandlung, einschließlich spezifischer Fehlernachrichten und -codes, ist abhängig vom jeweiligen Anwendungskontext und wird in den entsprechenden technischen Use Cases (TUC) im Kapitel [6 Funktionsmerkmale] näher beschrieben.

4.1.3.5 Umgang mit Zertifikaten der eHDSI

Die Authentizität und Integrität der Dienste in der eHDSI-Kommunikation wird mit digitalen Zertifikaten gesichert. Die eHDSI definiert zwei Zertifikatstypen: Seal- und TLS-Zertifikat (siehe [eHDSI_x509_Certificates_Profile#3.1]). Der NCPeH-FD benötigt für Land-A und für Land-B Szenarien sowohl das Seal- als auch TLS-Zertifikatsprofil, um sichere Verbindungen zu anderen NCPeH oder zentralen Diensten der eHDSI herzustellen. Der Herausgeber (CA) der beiden Zertifikatstypen ist GlobalSign.

Hinweis: Die Aufnahme der öffentlichen Zertifikate in dem lokalen Truststore des NCPeH-FD ist im Anwendungsfall [5.3.4 NCPeH.UC_8 - Konfigurationsparameter verwalten] beschrieben.

4.1.3.6 Validierung von Zertifikaten in eHDSI

Hinweis: Der Downloadpunkt für Status- und Sperrprüfungen ist gemäß [eHDSI_X509_Certificates_Profile#3.1] entweder im Element CRL Distribution Points oder im Element Authority Info Access des TLS-Zertifikats enthalten.

Hinweis: Die Validierung der CRL kann unabhängig von der Zertifikatsprüfung durchgeführt werden und muss also nicht bei jeder einzelnen CRL-Prüfung eines Zertifikats durchlaufen werden, solange gewährleistet ist, dass die CRL zeitlich gültig ist. Das Cachen der CRL ist optional.

4.1.4 Service Metadata des NCPeH Land-B abrufen

Die eHDSI sieht vor, dass jeder NCPeH seine Service Metadata mittels des SMP/SML-Protokolls an den Configuration Service der eHDSI übermitteln muss, damit bei grenzüberschreitendem Datenaustausch die Vertraulichkeit, Integrität und Nichtabstreitbarkeit gewährleistet wird. Dies gilt auch für NCPeH Land-B. Damit der NCPeH-FD sichere TLS-Verbindungen zu NCPeH Land-B aufbauen und die Authentizität und Integrität der IdA-/TRC Assertions, die durch NCPeH Land-B oder eine andere Entität aus Land-B ausgestellt wurden, validieren kann, ist es erforderlich, dass der NCPeH-FD über die gültigen Service Metadata der NCPeH Land-B verfügt.

Die auf dem eHDSI Configuration Service verfügbaren Service Metadata der NCPeH Land-B befinden sich in einem öffentlichen Verzeichnis, aus dem alle NCPeH die Service Metadata abrufen können.

Jede ausgewählte ServiceMetadata enthält eine elektronische Signatur, die mit einem Schlüsselmaterial des NCPeH Land-B erstellt wurde. Die Gültigkeit der Signatur soll die Integrität der jeweiligen ServiceMetadata bestätigen.

4.1.5 Validierung der Identity Assertion des LE-EU

Die Identity Assertion ("IdA") des LE-EU wird vom Behandlungsland (Land-B) ausgestellt und enthält Aussagen über die Identität, Authentizität, Zugehörigkeit und Rolle des LE-EU, der demographische oder medizinische Daten des behandelten Versicherten anfordert. Die IdA ist als SAML v2.0 Assertion obligatorischer Bestandteil jeder eHDSI-Anfrage. Jeder NCPeH Land-B, der die IdA zusammen mit eHDSI-Anfragen versendet, steht gemäß [eHDSI_SAML_Profile] für die Richtigkeit, Integrität und Authentizität aller in dieser Assertion gekapselten Informationen ein. Die Identity Assertion des LE-EU wird von dem NCPeH Land-B oder einem Identity Provider aus Land-B elektronisch signiert und in den Security Header Envelope/Header/Security/Assertion der SOAP-Nachricht eingetragen. Das öffentliche Zertifikat des NCPeH Land-B oder des Identity Providers aus dem Land-B, mit dem die Signatur der IdA geprüft werden kann, wird vom Land-B dem NCPeH-FD über den eHDSI Configuration Service zum Herunterladen bereitgestellt (siehe Kapitel [4.1.4 Service Metadata des NCPeH Land-B abrufen]).

Das Prüfen des öffentlichen Zertifikats aus der IdA auf den gemeinsamen Zertifikatsherausgeber (CA), um das Vertrauen zu dem Zertifikat herzustellen, ist in A_28075 und A_28079 beschrieben. Der NCPeH-FD agiert gegenüber NCPeH Land-B als SAML Assertion Consumer und sorgt für ordnungsgemäße Prüfung der IdA und der Verarbeitung von Inhalten der IdA.

Hinweis: Die Behandlung fachlicher Fehlerfälle im Zusammenhang mit der IdA erfolgt anwendungsfallabhängig in den jeweils zugehörigen TUCs.

Neue Afo

Beispiel

Das folgende Beispiel stellt die Struktur einer Identity Assertion eines LE-EU dar:

4.1.6 Validierung der TRC Assertion

Die TRC Assertion ist eine SAML v2.0 Assertion. Sie bescheinigt das Bestehen einer Behandlungsbeziehung zwischen einem Versicherten und einem LE-EU und liefert Informationen über den Kontext eines bestimmten Behandlungsszenarios. Die Vorgaben an die Datenstruktur und Einschränkungen zur Nutzung der TRC Assertion sind in [eHDSI_SAML_Profile#4] profiliert.

Beispiel

Das folgende Beispiel stellt die Struktur einer TRC Assertion dar:

4.1.7 Non-Repudiation und Audit Trail Schemas

4.1.7.1 Non-Repudiation of Origin erstellen

Die Non-Repudiation of Origin (NRO) ist laut [eHDSI_Audit_Profile#1.2.2] als SubmissionAcceptanceRejection (SAR) gemäß [ETSI_REM#5.1.1] definiert. Das SAR-Objekt dient als Nachweis (Evidence), dass eine bestimmte Nachricht vom NCPeH-FD (in der Rolle als Absender) zu dem im Nachweis angegebenen Zeitpunkt erfolgreich bzw. nicht erfolgreich versendet wurde.

Beispiel

Das folgende Beispiel stellt die Struktur eines SAR-Objektes dar:

4.1.7.2 Non-Repudiation of Receipt erstellen

Die Non-Repudiation of Receipt (NRR) ist als AcceptanceRejectionByRecipient (ARbR) gemäß [ETSI_REM#5.1.7] definiert. Das ARbR-Objektes dient als Nachweis, dass die eingegangene Nachricht vom NCPeH-FD empfangen worden ist. 

Beispiel

Das folgende Beispiel stellt die Struktur eines ARbR-Objektes dar:

4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen

Hinweis: Das eHDSI Audit Trail Schema "Patient Privacy" ist ein wichtiges Instrument zum Schutz der Privatsphäre von Versicherten. Es dient der Dokumentation der Verantwortlichkeiten des Anbieters des NCPeH-FD bei der Datenverarbeitung und stellt sicher, dass die Rechte der Versicherten gewahrt und die entsprechenden Pflichten ordnungsgemäß erfüllt werden. Dieses Schema ermöglicht es Versicherten, sich umfassend über jegliche Verwendung ihrer medizinischen Daten zu informieren. Darüber hinaus versetzt es die Versicherten in die Lage, die Rechtmäßigkeit aller Zugriffe auf ihre Daten zu überprüfen und zu beurteilen. Somit bildet dieses Audit Trail Schema ein zentrales Element für Transparenz und Datenschutz in der eHDSI, indem es die Nachvollziehbarkeit der Datenverwendung gewährleistet und die Kontrolle durch die Versicherten selbst ermöglicht.

Beispiel

Das folgende Beispiel stellt die Struktur eines Audit Trail Eintrages nach dem eHDSI Audit Trail Patient Privacy Schema dar:

4.1.7.4 Translation Audit Trail Eintrag erstellen

Beispiele: 

ParticipantObjectID="1.2.84.116.1.800.254.370.349.563.1605.469.534.1338^PS.XML"

ParticipantObjectID="160.000.000.000.123.76^eP.XML"

Beispiel

Das folgende Beispiel stellt die Struktur eines Translation Audit Trail Eintrages nach dem Audit Trail Entries on NCP-Internal Activities gemäß eHDSI Schema dar:

Tabelle 11: TAB_NCPeH_Beispiel_Translation_Audit_Trail 

4.1.7.5 Security Audit Trail Eintrag erstellen

Beispiel

Das folgende Beispiel zeigt die Struktur eines Security Audit Trail Eintrages:

Tabelle 12: TAB_NCPeH_Beispiel_Security_Audit_Trail

4.1.8 Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI

Zur Prüfung der Zugriffsberechtigung eines LE-EU auf einen fachanwendungsspezifischen Dienst der TI müssen bestimmte Identitätsattribute aus der Identity Assertion des LE-EU (IdA) ausgewertet werden. Die Zugriffsrechte auf einen jeweiligen Dienst sind abhängig von dem jeweiligen Anwendungsszenario und werden durch Vorgaben der eHDSI zur IdA technisch geregelt nach [eHDSI_SAML_Profile#2.3 HP Identity Attributes] und [eHDSI_SAML_Profile#2.5 Permission Codes]. Das Zugriffsrecht des NCPeH-FD auf zentrale Dienste der TI bleibt hiervon unberührt.

Das bedeutet, dass § 352 SGB V zur Prüfung der Zugriffsberechtigung auf ePA-Aktensysteme anhand der Rollencodes des LE-EU herangezogen werden muss. Hebammen aus der EU sind dementsprechend nach § 352 Nr. 13 für den Zugriff auf ePA-Aktensysteme ausgeschlossen, da die notwendige Erfüllung von § 134a Absatz 2 SGB V nicht möglich ist. Heilmittelerbringer aus der EU sind nach § 352 Nr. 13 vom Zugriff auf ePA-Aktensysteme ausgeschlossen, da die notwendige Erfüllung von § 124 Absatz 1 SGB V nicht möglich ist. Hilfsmittelerbringer sind für den Zugriff auf ePA-Aktensysteme nach § 352 SGB V aktuell nicht zugelassen.

In diesem Fall ergeben sich nach Bewertung der nationalen gesetzlichen Regelungen folgende zulässige Rollen eines LE-EU zur Ermittlung der Zugriffsberechtigungen auf den jeweiligen fachanwendungsspezifischen Dienst der TI:

4.1.9 Format und Validierung der KVNR

4.2 Anschluss an die Telematikinfrastruktur

4.2.1 Schnittstellen zu Diensten der zentralen TI

Über einen sicheren zentralen Zugangspunkt (SZZP) stehen dem NCPeH-FD Dienste der zentralen TI und fachanwendungsspezifischen Diensten (Fachdienste) der TI zur Verfügung. Der NCPeH-FD ist zuständig für den Verbindungsaufbau und -abbau zu diesen Fachdiensten. Dieser interagiert mit der TI in der Rolle eines Consumer und enthält die Absicherung gegenüber dem Zugriff auf das zentrale Netz der TI und Fachdienste. 

Hinweis: Wenn der Begriff SZZP verwendet wird, sind damit Anbindungstypen SZZP, SZZP-light oder SZZP-light-plus gemeint. Für weitere Informationen zu den einzelnen Anbindungstypen siehe [gemSpec_Net#3.1.1].

4.2.2 TLS-Verbindungsaufbau zu Diensten der TI

Im Rahmen der Weiterentwicklung der TI können zukünftig Dienste der TI sowohl über das geschlossene, zentrale Netz der TI, als auch über das Internet angesprochen werden. Dementsprechend gibt es unterschiedliche Regularien, die bei der sicheren Nutzung von TLS und der Zertifikatsprüfung zu beachten sind. Entsprechende übergreifende oder anwendungsspezifische Vorgaben zum TLS-Handshake werden hier zusammengefasst.

Aktuell werden die vom NCPeH-FD zu nutzenden zentralen und fachanwendungsspezifischen Dienste der TI (hier allgemein als Dienste der TI bezeichnet) nur über das zentrale Netz der TI angesprochen.

Da die Nutzung von RSA mit der Schlüssellänge 2048 nur noch bis Ende 2025 in der TI erlaubt ist, erfolgt in der TI eine Migration auf ECC-basierte Algorithmen (siehe z. B. [gemSpec_Krypt#5]). 

4.2.2.1 TLS-Verbindungsaufbau zu Diensten der TI über das zentrale Netz der TI

Hinweis: Umzusetzende Anforderungen aus diesen Dokumenten werden zusätzlich im Produkttypsteckbrief [gemProdT_NCPeH_FD] aufgeführt.

Hinweis: Eine eventuell weiterführende Fehlerreaktion insbesondere in Richtung NCPeH Land-B wird von den jeweils nutzenden übergreifenden Festlegungen oder Technical Use Cases festgelegt.

4.2.3 Prüfung von nonQES-Zertifikaten

Hinweis: Der zentrale IDP-Dienst wird vom NCPeH-FD per TLS über die zentrale TI angesprochen, liefert jedoch ein Internet-Zertifikat mit einem TI-spezifischen FQDN zur TLS-Authentisierung aus. Weiterführende Informationen siehe z. B. [gemSpec_IDP_Dienst], A_20587* oder A_20688*.

Hinweis: Die OIDs zu Zertifikatsprofilen der TI und die OIDs für technische Rollen können in der [gemSpec_OID] in den Tabellen Tab_PKI_405 bzw. Tab_PKI_406 ermittelt werden. Die Rollen-OIDs sind entsprechend der Zertifikatsprofile im Zertifikat in der Extension "Admission", professionOID zu finden (siehe jeweilige Zertifikatsprofile in [gemSpec_PKI]).

Hinweis: Hier nicht aufgeführte Zertifikatsprofile (z. B. VAU-Zertifikat im "signierten öffentlichen VAU-Schlüssel") durchlaufen einen separat beschriebenen Prüfvorgang.

Hinweis: Hier nicht aufgeführte Zertifikatsprofile (z. B. VAU-Zertifikat des ePA-Aktensystems im "signierten öffentlichen VAU-Schlüssel") durchlaufen einen separat beschriebenen Prüfvorgang.

Da die Nutzung von RSA mit der Schlüssellänge 2048 nur noch bis Ende 2025 in der TI erlaubt ist, erfolgt in der TI eine Migration auf ECC-basierte Algorithmen (siehe u. A. [gemSpec_Krypt#5]). 

4.2.3.1 Prüfung von X.509 nonQES Zertifikaten der TI

Hinweis: Siehe dort auch die Erläuterungen zur Umsetzung der Anforderung in [gemSpec_Krypt], z. B. auch im Falle der Bereitstellung von Sperrinformationen mittels OCSP-Stapling oder im VAU-Verbindungsaufbau (Nachricht 2, siehe [gemSpec_Krypt] A_24608* und A_24425*).

Hinweis: Da die Quellen für Sperrinformationen von Zertifikaten teilweise unterschiedlich vorgegeben sind und der Sinn des Cachings sich aus Quelle und Prüfintervall ergibt, folgt hier eine informative Übersicht:

Tabelle 18: TAB_NCPeH_OCSP_Übersicht_für_Zertifikate_TI

Hinweis: Im Rahmen einer Zertifikatsprüfung nach TUC_PKI_018 beschreibt der untergeordnete TUC_PKI_005 die Ermittlung der Adresse des OCSP-Responders der Zertifikats-herausgebenden CA aus der TSL (siehe [gemSpec_PKI#Statusprüfung]).

4.2.3.2 Prüfung von Internet-Zertifikaten

Hinweis: Eine positiv ausgefallene Signaturprüfung ist gleichbedeutend damit, dass das CA-Zertifikat im Zertifikats-Truststore eines aktuellen Webbrowsers vorhanden ist.

4.2.4 Registrierung als ePA-Client

Der Anbieter des NCPeH-FD MUSS sich als ePA-Client gemäß Vorgaben aus [gemSpec_Aktensystem_ePAfuerAlle#Useragent] registrieren.

Der NCPeH-FD MUSS sicherstellen, dass das HTTP Header Element "x-useragent" bei jedem Request sowohl im HTTP-Header der VAU-Nachricht, als auch im HTTP-Header der Nachricht an alle ePA Services gemäß [gemSpec_Aktensystem_ePAfuerAlle#Useragent] übermittelt wird. Der NCPeH-FD DARF das HTTP Header Element "x-clientid" nur im HTTP-Header der VAU-Nachricht (innerer Request) an ePA Services übermitteln.

4.2.5 Lokalisierung der Service-Endpunkte der ePA

Die Anbieter der ePA-Aktensysteme registrieren die Service-Endpunkte der ePA-Aktensysteme über die übergreifende Domäne epa4all.de, die immer auf IP-Adressen der TI verweist. Für die verschiedenen Umgebungen der TI sind third-level Domänen eingerichtet: .ref (RU1), .dev (RU2), .test (TU) und .prod (PU).

Der NCPeH-FD MUSS die FQDNs jedes Anbieters der ePA-Aktensysteme im Konfigurationsparameter LIST_ePA_ANBIETER_FQDN (siehe A_28017*) in der VAU speichern, die in
[gemSpec_Aktensystem_ePAfuerAlle#A_24592*] fest definiert sind. Die FQDNs MÜSSEN ausschließlich für die Kommunikation mit den ePA-Diensten genutzt werden.

Das Redundanzkonzept der ePA sieht mehrere Instanzen vor, die über verschiedene IP-Adressen angesprochen werden. Folglich liefert die DNS-Namensauflösung verschiedene IP-Adressen zum FQDN zurück. Diese Adressen werden vom DNS-Server in zufälliger Reihenfolge geschickt, sodass es legitim ist, immer den ersten Eintrag für den folgenden Operationsaufruf zu verwenden.

Unspezifiziert ist das Verhalten, wenn die erste Zieladresse nicht erreichbar ist. Empfehlenswert ist die Nutzung der anderen/weiteren IP-Adressen der DNS-Abfrage. Bei Nicht-Erreichbarkeit des Zielhosts der ersten IP-Adresse wird daher empfohlen, weitere Verbindungsversuche auf Basis einer neuen DNS-Abfrage zu tätigen, mit dem Ziel, eine andere IP-Adresse an erster Stelle der DNS-Antwort zu erhalten, als die des nicht erreichbaren Zielhosts.

4.2.6 Nutzung des IDP-Dienstes

Der IDP-Dienst in der zentralen TI muss im Rahmen der Autorisierung des NCPeH an Fachdiensten der TI genutzt werden. Dazu sind folgende Vorgaben einzuhalten.

4.2.6.1 Registrierung beim IDP-Dienst

Der Anbieter des NCPeH-FD MUSS sich über einen organisatorischen Prozess beim Anbieter des IDP-Dienstes für die Dienste registrieren, für die Token abgerufen werden sollen. Der IDP-Dienst vergibt dabei eine client_id. Diese client_id MUSS vom NCPeH-FD bei Nutzung des IDP-Dienstes übertragen werden.

Der Anbieter des NCPeH-FD MUSS die client_id unter dem Konfigurationsparameter CLIENT_ID_IDP_DIENST (siehe A_28017*) speichern.

Weitere Informationen zur Registrierung von Fachdiensten beim IDP-Dienst sind in [gemSpec_IDP_Dienst#Registrierung Anwendungsfrontend und Fachdienst] enthalten.

4.2.6.2 Verarbeitung des Discovery Document

Das Discovery Document des IDP-Dienstes stellt den zentralen Anlaufpunkt dar, anhand dessen alle weiteren „statischen“ Service-Endpunkte des IDP-Dienstes adressiert werden können (gemäß [RFC8414#OAuth 2.0 Authorization Server Metadata]). 

Der NCPeH-FD MUSS das Discovery Document regelmäßig alle 24 Stunden einlesen und auswerten, und danach die darin aufgeführten URI zu den benötigten öffentlichen Schlüsseln (PUKs) und Diensten verwenden. Das Discovery Document ist vom IDP-Dienst unter der URL /.well-known/openid-configuration abrufbar. Die Informationen über die URL des Downloadpunktes des Discovery Document in der zentralen TI sind in [gemSpec_IDP_Dienst#A_19874-05] enthalten.

Der Anbieter des NCPeH-FD MUSS den Downloadpunkt des Discovery Document als Konfigurationsparameter DOWNLOAD_DISCOVERY_DOCUMENT (siehe A_28017*) speichern.

Der NCPeH-FD MUSS das öffentliche X.509 nonQES Zertifikat des Discovery Document gemäß [4.2.3 Prüfung von nonQES-Zertifikaten] auf Integrität und Authentizität prüfen und dabei sicherstellen, dass im Feld certificatePolicies (2.5.29.32) des Zertifikates der policyIdentifier oid_fd_sig für das Zertifikatsprofil C.FD.SIG enthalten ist und das Zertifikat auf die Rollen-OID oid_idpd zurückgeführt wird. Der NCPeH-FD MUSS die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen, wenn die Prüfung kein positives Ergebnis ("gültig") liefert.

Wenn das Ergebnis der Zertifikatsprüfung "gültig" ist, dann MUSS der NCPeH-FD die JWS [RFC7515 # section-3 - Compact Serialization] Signatur des Discovery Documents auf mathematische Korrektheit sowie auf Vorgaben aus [RFC7515#5.2 Message Signature or MAC Validation] auf zeitliche Gültigkeit des ausstellenden Zertifikates innerhalb der TI prüfen. Weiterführende Festlegungen zur Signatur des Discovery Document sind in [gemSpec_IDP_Dienst#A_20591-01] enthalten.

Nach erfolgreicher Zertifikats- und Signaturprüfung des Discovery Document MUSS der NCPeH-FD:

• das öffentliche Zertifikat PUK_IDP_SIG von dem im Element uri_puk_idp_sig des Discovery Document angegebenen URI herunterladen und in der VAU abspeichern,
• das öffentliche Zertifikat PUK_IDP_ENC von dem im Element uri_puk_idp_enc des Discovery Document angegebenen URI herunterladen und in der VAU abspeichern und
• die benötigten URL-Endpunkte für die Kommunikation mit dem IDP-Dienst dem Discovery Document entnehmen, in der VAU zwischenspeichern und zur Kommunikation mit dem IDP-Dienst nutzen.

Hinweis: zur Struktur des Discovery Document siehe auch [gemSpec_IDP_Dienst#Aufbau des Discovery Documents] und [gemSpec_IDP_Dienst#Aufbau des Discovery Document]. 

Falls die Prüfungen kein positives Ergebnis ("gültig") liefern, so MUSS der NCPeH-FD die von den Zertifikaten und den darin enthaltenen Attributen abhängenden Arbeitsabläufe ablehnen. 

4.2.6.3 TLS-Verbindungsaufbau zu Service-Endpunkten des IDP-Dienstes

Der NCPeH-FD MUSS sicherstellen, dass die Kommunikation mit allen Service-Endpunkten des IDP-Dienstes TLS-gesichert erfolgt. 

Der NCPeH-FD MUSS den TLS-Verbindungsaufbau zu den Service-Endpunkten des IDP-Dienstes in der TI nach den Vorgaben aus [4.2.2 TLS-Verbindungsaufbau zu Diensten der TI] und [4.2.3 Prüfung von nonQES-Zertifikaten] durchführen.

4.2.6.4 Authentifizierung per IDP-Dienst für Zugriff auf ePA-Aktensystem

Der ePA Authorization Service leitet die Authentifizierungsanfrage des NCPeH-FD an den IDP-Dienst weiter. Am IDP-Dienst authentisiert sich der NCPeH-FD mittels des im HSM für das Land-B hinterlegten C.HCI.AUT-Zertifikattyps des Zertifikatsprofils SM-B NCPeH. Bei erfolgreicher Authentisierung erhält der NCPeH-FD einen AUTHORIZATION_CODE.

Die Abbildung Nachrichtenfluss für die Authentifizierung gegenüber dem zentralen IDP-Dienst zeigt den allgemeinen Ablauf der Authentifizierung des NCPeH-FD gegenüber dem IDP-Dienst für den Zugriff auf ePA-Aktensysteme. Der folgende Abschnitt enthält eine informative Erläuterung der Abbildung: 

Der NCPeH-FD übermittelt den AUTHORIZATION_CODE an den ePA Authorization Service. Der ePA Authorization Service ruft mittels des AUTHORIZATION_CODE das ID_TOKEN für den NCPeH-FD vom IDP-Dienst ab. Das ID_TOKEN ist vom IDP-Dienst signiert. Als Ergebnis ist ein ID_TOKEN des NCPeH-FD in der VAU des ePA-Aktensystems vorhanden. Ist ein gültiges ID_TOKEN des NCPeH-FD in der VAU vorhanden, startet der ePA User Session Manager eine User Session für den NCPeH-FD für das entsprechende Land-B und der NCPeH-FD kann auf das Aktenkonto des Versicherten zugreifen (sofern eine in ePA vom Versicherten erteilte Befugnis vorhanden ist). 

Mit einer etablierten VAU Session für eine authentisierte, Land-B spezifische NCPeH Identität kann der NCPeH den Zugriff verschiedener LE-EU dieses Landes auf unterschiedliche Versichertenkonten durchführen. Eine bestehende Befugnis für den Zugriff dieses Landes auf ein Konto wird beim Öffnen des jeweiligen Health Record Context durch das ePA-Aktensystem besser geprüft. In der User Session des ePA-Aktensystems können mehrere Health Record Context zu verschiedenen Aktenkonten parallel aufgebaut werden.

Abbildung 3: Nachrichtenfluss für die Authentifizierung gegenüber dem zentralen IDP-Dienst

Der NCPeH-FD startet die Authentifizierung beim ePA Authorization Service. Dieser Ablauf ist im [4.2.7.7 Authentifizierung mit dem ePA Authorization Service] beschrieben.

Senden der Authentifizierungsanfrage an IDP-Dienst

Bei der folgenden Kommunikation mit dem IDP-Dienst DARF der NCPeH-FD NICHT länger auf eine Antwort des IDP-Dienstes warten als der Zeitwert des Konfigurationsparameter IDP_RESPONSE_TIMEOUT (siehe A_28016*). Wenn der Zeitwert überschritten wird, MUSS der NCPeH-FD die Kommunikation mit dem IDP-Dienst abbrechen und diesen Fall als einen Fehler behandeln (siehe in diesem Kapitel den Abschnitt "Umgang mit Fehlern und Timeouts").

Nach dem Abruf der Attestation-Nonce und der Delegierung der Authentifizierungsanfrage vom ePA Authorization Service an den IDP-Dienst MUSS der NCPeH-FD den Antrag zum Erhalt eines AUTHORIZATION_CODE für ein ID_TOKEN in Form eines HTTP/1.1 GET AuthorizationRequest beim Authorization-Endpunkt (siehe URI_AUTH aus dem Discovery Document) stellen. Dabei MUSS der NCPeH-FD die folgenden Attribute, die aus der Response von send_authorization_request_sc stammen, an den IDP-Dienst übermitteln: 

• response_type,
• scope,
• nonce2,
• client_id,
• redirect_uri,
• code_challenge (Hashwert des code_verifier) [RFC7636 # section-4.2],
• code_challenge_method HASH-Algorithmus (S256) [RFC7636 # section-4.3],
• state.

Der Authorization-Endpunkt legt nun eine session_id an, stellt alle nötigen Informationen zusammen und erzeugt das CHALLENGE_TOKEN. Darüber hinaus stellt der Authorization-Endpunkt den im Claim des ePA-Aktensystems vereinbarten, Consent zusammen, welcher die für dessen Funktion notwendigen Attribute beinhaltet. Diese Informationen liefert der Authorization-Endpunkt als Antwort auf den Authorization-Request des NCPeH-FD.

Challenge/Response-Verfahren

Der NCPeH-FD MUSS die JWS [RFC7515 # section-3 - Compact Serialization] Signatur des CHALLENGE_TOKEN auf mathematische Korrektheit sowie auf Vorgaben aus [RFC7515#5.2 Message Signature or MAC Validation] auf zeitliche Gültigkeit gegen den aktuellen öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_SIG" innerhalb der TI prüfen. Die Angaben zum Algorithmus sind in [gemSpec_IDP_Dienst#A_20521-02] enthalten.

Bei erfolgreicher Prüfung der Signatur des CHALLENGE_TOKEN MUSS der NCPeH-FD nun im HSM mit dem Signaturzertifikat C.HCI.AUT des SM-B NCPeH für das entsprechende Land-B gemäß Vorgaben aus [4.2.9 Elektronische Identitäten des NCPeH-FD] das CHALLENGE_TOKEN des IDP-Dienstes signieren und als zu signierende Daten BinaryString den SHA-256-Hashwert des CHALLENGE_TOKEN in Base64-Codierung übergeben. Die Vorgaben für die Anwendung von Algorithmen bei der Erzeugung von Signaturen ist geregelt in [gemSpec_IDP_Dienst#A_21439*]. Der NCPeH-FD MUSS beim Signieren des CHALLENGE_TOKEN den Signatur-Typ ECDSA-Signatur verwenden.

Anschließend MUSS der NCPeH-FD das CHALLENGE_TOKEN zusammen mit der im HSM signierten Challenge-Signatur SIGNED_CHALLENGE_TOKEN und dem öffentlichen Authentifizierungszertifikat C.HCI.AUT der SM-B NCPeH, mit dem öffentlichen Schlüssel des Authorization-Endpunktes PUK_IDP_ENC verschlüsseln, an diesen in Form eines HTTP-POST-Requests senden. Der Request entspricht dem Aufruf "getTokenCode" aus der Abbildung "Nachrichtenfluss für die Authentifizierung mit dem zentralen IDP-Dienst". Weitere Vorgaben an die Struktur des Request und Algorithmen gelten gemäß Vorgaben aus [gemSpec_IDP_Dienst#7.3]. 

Hinweis: Der Aufbau der Anfrage, der einzureichenden Objekte und Vorgaben an die Verwendung von Algorithmen sind in [gemSpec_IDP_Dienst#7.3 Authentication Request] enthalten.

Hinweis: Das Signieren und Verschlüsseln des CHALLENGE_TOKEN ist durch die Verwendung eines Nested JWT [angelehnt an den folgenden Draft: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03] vom IDP-Dienst realisiert. Im cty-Header ist "NJWT" gesetzt, um anzugeben, dass es sich um einen Nested JWT handelt. Das Erstellen der Signatur durch den IDP-Dienst wird dabei durch die Verwendung einer JSON Web Signature (JWS) [RFC7515 # section-3 - Compact Serialization] gewährleistet. Die Verschlüsselung des signierten Token MUSS durch die Nutzung der JSON Web Encryption (JWE) [RFC7516 # section-3] sichergestellt werden. Als Verschlüsselungsalgorithmus MUSS ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Erhalt des AUTHORIZATION_CODE

Der Authorization-Endpunkt des IDP-Dienstes verknüpft die session mit der Identität aus dem Authentisierungszertifikat und erstellt einen AUTHORIZATION_CODE, welchen er als Antwort an den NCPeH-FD zurücksendet.

Der NCPeH-FD MUSS diesen AUTHORIZATION_CODE an den ePA Authorization Service senden. Dieser Vorgang ist im [4.2.7.7 Authentifizierung mit dem ePA Authorization Service] beschrieben.

Umgang mit Fehlern und Timeouts

Kommt es während des Authentisierungsprozesses gegenüber IDP-Dienst im Kontext des Anwendungsfalls [5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren] zu einem Fehler oder Timeout, dann MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage des NCPeH Land-B und der dabei ermittelten Daten abbrechen und dem anfragenden NCPeH Land-B mit einer Fehlernachricht gemäß Tabelle TAB_NCPeH_Authentifizierung_IDP-Dienst_Fehlerbehandlung_XCPD
antworten. 

Tabelle 19: TAB_NCPeH_Authentifizierung_IDP-Dienst_Fehlerbehandlung_XCPD

Bei Fehlerfällen oder Timeouts, die im Zusammenhang mit den Anwendungsfällen wie [5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten], [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen] oder [5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen] entstehen, gilt folgende Anforderung:

Der NCPeH-FD MUSS eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit dem Fehlercode ERROR_PS_GENERIC gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten.

Nach einer Fehlerbehandlung, unabhängig vom Anwendungsfall, MUSS der NCPeH-FD den bestehenden VAU-Kanal gemäß Vorgaben in [4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem] schließen.

Nach der Fehlerbehandlung MUSS der NCPeH-FD das Discovery Document und alle zugehörigen Zertifikate aus der VAU löschen, damit diese Objekte technisch nicht mehr verwendet werden können. Danach MUSS der NCPeH-FD das Discovery Document und alle erforderlichen Zertifikate gemäß Vorgaben aus [4.2.6.2 Verarbeitung des Discovery Document] erneut herunterladen, einlesen, auswerten und in der VAU speichern.

4.2.7 Login in ein ePA-Aktenkonto

Die folgenden Unterkapitel enthalten Vorgaben und Verweise auf entsprechende Dokumente der gematik, die weitere Informationen zum Aufbau von sicheren Verbindungen mit dem ePA-Aktensystem enthalten.

4.2.7.1 TLS-Verbindungsaufbau zum ePA-Aktensystem

Der NCPeH-FD MUSS sicherstellen, dass die Kommunikation mit allen Service-Endpunkten eines ePA-Aktensystems TLS-gesichert erfolgt.

Der NCPeH-FD MUSS den TLS-Verbindungsaufbau zum ePA-Aktensystem in der TI nach den Vorgaben aus [4.2.2 TLS-Verbindungsaufbau zu Diensten der TI] und [4.2.3 Prüfung von nonQES-Zertifikaten] durchführen.

Tritt im Rahmen des Abrufs von demographischen Versichertendaten ein Fehler oder Timeout des TLS-Verbindungsaufbaus zum ePA-Aktensystem auf MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage eines anfragenden NCPeH Land-B abbrechen. In diesem Fall MUSS der NCPeH-FD dem NCPeH Land-B eine Fehlermeldung gemäß den Vorgaben aus [eHDSI_XCPD_Profile#"Error handling"] erstellen und die Antwort gemäß den Vorgaben der Tabelle TAB_NCPeH_TLS_Error_Timeout_ePA_Aktensystem_Fehlerbehandlung_XCPD senden.

Tabelle 20: TAB_NCPeH_TLS_Error_Timout_ePA_Aktensystem_Fehlerbehandlung_XCPD

Tritt im Rahmen des Abrufs von Metadaten oder Gesundheitsdaten des Versicherten ein Fehler oder Timeout des TLS-Verbindungsaufbaus zum ePA-Aktensystem auf, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage eines anfragenden NCPeH Land-B abbrechen. In diesem Fall MUSS der NCPeH-FD dem NCPeH Land-B eine Fehlermeldung gemäß den Vorgaben aus [eHDSI_XCA_Profile] erstellen und an NCPeH Land-B senden, wobei Teile der Fehlernachricht wie folgt zu befüllen sind:

• errorCode gemäß [eHDSI_XCA_Profile#"Error Messages"] und [eHDSI_NCPeH_Components#"MyHealth@EU Error Codes"] = ERROR_INTERNAL_ERROR,
• codeContext = "Unable to connect to the national electronic health record system.",
• severity = urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error,
• location = "An error or timeout has occurred while establishing the TLS connection to the national electronic health record system."

4.2.7.2 Interne Aktenkontosession für einen Versicherten

Eine Aktenkontosession im NCPeH-FD bezeichnet die Sitzung, in der fachliche Anwendungsfälle mit dem ePA-Aktenkonto eines Versicherten ausgeführt werden und dabei innerhalb der Sitzung wiederverwendbare Daten in der VAU zwischengespeichert werden.

Der NCPeH-FD SOLL in der VAU nach einer gültigen Aktenkontosession anhand der folgenden Merkmale suchen:

• KVNR des Versicherten gemäß Variable trc_kvnr aus A_27926*,
• Identifier des LE-EU gemäß Variable ida_name-id aus A_28026* und
• Ländercode des Land-B gemäß Variable tls_country aus A_28067* oder die dem NCPeH Land-B zugeordnete TI-Identität.

Die Liste der Suchergebnisse SOLL NICHT mehr als eine gültige Aktenkontosession enthalten. Wenn mehr als eine gültige Aktenkontosession gefunden wird, dann MUSS der NCPeH-FD alle gefundenen Aktenkontosessions als ungültig markieren und DARF sie NICHT verwenden. Der NCPeH-FD MUSS dann das Suchergebnis in diesem Fall so behandeln, als ob es keine Suchtreffer gab.

Wenn der NCPeH-FD keine gültige Aktenkontosession findet, dann MUSS er eine Lokalisierung des Aktenkontos des Versicherten (siehe Kapitel [4.2.7.3 Lokalisierung der Akte eines Versicherten]) durchführen. Wenn der NCPeH-FD die Existenz des Aktenkontos des Versicherten bei einem ePA-Aktensystem ermitteln konnte, dann MUSS er eine neue Aktenkontosession für den Versicherten in der VAU anlegen und die oben genannten Merkmale in der neuen Aktenkontosession abspeichern.

Wenn der NCPeH-FD eine gültige Aktenkontosession gefunden oder erstellt hat, SOLL er dieser Aktenkontosession für die Bearbeitung der fachlichen Anwendungsfälle des Versicherten nutzen und erforderliche Daten zwischenspeichern.

Eine Aktenkontosession KANN mit einem VAU-Kanal fest verknüpft werden. Wenn eine Aktenkontosession mit einem VAU-Kanal verknüpft ist, dann MUSS der NCPeH-FD sicherstellen, dass der VAU-Kanal mit der zugeordneten TI-Identität des NCPeH Land-B authentifiziert wurde (siehe Kapitel [4.2.7.7 Authentifizierung mit dem ePA Authorization Service]).

Weitere zusätzliche Daten SOLLEN in der Aktenkontosession des Versicherten zwischengespeichert werden:

• Angaben zu Service-Endpunkten des ePA-Aktensystems, in dem das Aktenkonto des Versicherten gehalten wird (siehe Kapitel [4.2.7.3 Lokalisierung der Akte eines Versicherten]).

Folgende ermittelte Daten KÖNNEN in der Aktenkontosession des Versicherten zwischengespeichert werden:

• Angaben zum LE-EU siehe A_28026*,
• Interne Variablen aus A_28026*,
• Referenz zu einem VAU-Kanal für das ePA-Aktensystem (siehe Kapitel [4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem] oder [4.2.7.5 Nutzung eines etablierten VAU-Kanals zum ePA-Aktensystem]),
• Metadaten des Versichertendatensatzes: DocumentUniqueId, RepositoryUniqueId.

Folgende Daten DÜRFEN NICHT in der Aktenkontosession des Versicherten zwischengespeichert werden:

• Zugriffscode,
• Medizinische und personenbezogene Daten des Versicherten.

Der NCPeH-FD MUSS bei Inaktivität einer Aktenkontosession nach Ablauf der zeitlichen Dauer gemäß Konfigurationsparameter ABSOLUTE_TIMEOUT_ePA_SESSION (siehe A_28017*) sicherstellen, dass beim Beenden der Aktenkontosession sämtliche Daten dieser Session aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist.

4.2.7.3 Lokalisierung der Akte eines Versicherten

Die Gesundheitsdaten des Versicherten werden in einem ePA-Aktensystem eines Anbieters gehalten. Ist dem NCPeH-FD nicht bekannt, in welchem ePA-Aktensystem ein Aktenkonto liegt, MUSS der NCPeH-FD den zuständigen ePA Service-Endpunkt ermitteln. Dazu wendet sich der NCPeH-FD an den ePA Information Service außerhalb der VAU eines ePA-Aktensystems, um dort nach der Akte zu fragen.

Der NCPeH-FD MUSS den Status und die Existenz eines Aktenkontos mit Hilfe der Operation getRecordStatus des ePA Information Service bei einem Aktensystemanbieter gemäß REST-Schnittstelle [I_Information_Service] abfragen. Die Operation ermittelt, ob für die übergebene KVNR ein Aktenkonto existiert und in welchem Status ist es. 

Der NCPeH-FD MUSS die Abfrage der Existenz eines Aktenkontos zu einer KVNR gegen die bekannten ePA-Aktensysteme wiederholen, bis diese erfolgreich ist oder alle ePA-Aktensysteme angefragt wurden. Kennt kein ePA-Aktensystem die Akte, hat der Versicherte der ePA widersprochen und es existiert keine Akte. Wenn das ePA-Aktensystem auf die Anfrage mit einem HTTP Status Code 200 OK antwortet, MUSS der NCPeH-FD die relevanten Service-Endpunkte des ePA-Aktensystems in einer neuen Aktenkontosession des Versicherten (siehe Kapitel [4.2.7.2 Interne Aktenkontosession für einen Versicherten]) abspeichern.

In allen anderen Fällen, wo alle verfügbaren ePA-Aktensysteme nicht mit dem HTTP Status Code 200 OK geantwortet haben und damit die Existenz des Aktenkontos des Versicherten nicht bestätigt wurde, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage aus eHDSI abbrechen und dem NCPeH Land-B abhängig vom jeweiligen Anwendungsfall mit einer der folgenden Fehlernachrichten antworten:

Tritt der Fehler im Kontext von Anwendungsfall [AF_10107-01 - Versicherten im Behandlungsland für PS-A identifizieren] auf, MUSS der NCPeH-FD eine Fehlernachricht gemäß Tabelle TAB_NCPeH_Lokalisierung_Akte_Fehler_XCPD_Response erstellen und an NCPeH Land-B versenden.

Tabelle 21: TAB_NCPeH_Lokalisierung_Akte_Fehler_XCPD_Response

Hinweis: Weitere Fehlerbehandlungen werden in den für diesen TUC relevanten übergreifenden Festlegungen beschrieben.

Andernfalls, tritt der Fehler in den folgenden Anwendungsfällen wie [5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten], [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen] oder [5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen] auf, MUSS der NCPeH-FD dem NCPeH Land-B mit dem Fehlercode ERROR_PS_GENERIC gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten.

4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem

Der NCPeH-FD MUSS nach den Vorgaben aus [gemSpec_Krypt#7.1] in seiner Rolle als VAU-Client den Verbindungsaufbau zur VAU eines ePA-Aktensystems durchführen. Dazu muss er den dort beschriebenen Nachrichtenablauf und seine Prüfungen umsetzen:

• Erzeugung und Absenden der Nachricht 1 an das ePA-Aktensystem
• Empfang und Prüfung der Nachricht 2 (Response vom ePA-Aktensystem)
• Erzeugung und Absenden der Nachricht 3 an das ePA-Aktensystem
• Empfang und Prüfung der Nachricht 4 (Response vom ePA-Aktensystem)

Der NCPeH-FD MUSS die Gültigkeitsprüfung der "signierten öffentlichen VAU-Schlüssel" des ePA-Aktensystems nach den Anforderungen A_24958* und A_24624* aus [gemSpec_Krypt] umsetzen.

Der NCPeH-FD MUSS für unterschiedliche NCPeH Land-B mit ihren zugeordneten TI-Identitäten (entsprechend [4.2.9 Elektronische Identitäten des NCPeH-FD] unterschiedliche VAU-Kanäle zum ePA-Aktensystem aufbauen.

Der NCPeH-FD KANN für eine TI-Identität eines NCPeH Land-B mehrere VAU-Kanäle zum ePA-Aktensystem aufbauen. Dies kann z. B. sinnvoll sein, wenn für verschiedene Versicherte aus dem gleichen Land-B parallel fachliche Anwendungsfälle abzuarbeiten sind.

Der NCPeH-FD MUSS beim Aufbau der Nachricht 1 ermitteln, ob für die nach A_25729* zu nutzende Land-B Identität ein VAU-Nutzerpseudonym ("VAU-NP") zwischengespeichert ist. Wenn ein Nutzerpseudonym vorhanden ist, dann MUSS der NCPeH-FD diesen Wert entsprechend [gemSpec_Krypt#A_24757*] im HTTP-Header der Nachricht 1 mitschicken.

Erläuterung: Obwohl die Authentifizierung, mit der dem Land-B zugeordneten SM-B erst nach Aufbau des VAU-Kanals erfolgt (siehe Kapitel [4.2.7.7 Authentifizierung mit dem ePA Authorization Service]), muss bereits zu diesem Zeitpunkt klar sein, für welche Land-B Identität der VAU-Kanal genutzt werden soll. Dies wird auch durch die Nutzung des "VAU-NP" klar. Ein Wechsel der NCPeH-Identität in einem VAU-Kanal ist nicht zulässig.

Falls beim Aufbau des VAU-Kanals ein Fehler oder Timeout auftritt MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage des NCPeH Land-B abbrechen (siehe [gemSpec_Krypt#7.6 Fehlersignalisierung]). Der NCPeH-FD MUSS die Daten zu dem im Aufbau befindlichen VAU-Kanal wie in [4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem] behandeln. Bei einem Fehler oder Timeout im Kontext des Anwendungsfalls [AF_10107-01 - Versicherten im Behandlungsland für PS-A identifizieren] MUSS der NCPeH-FD dem anfragenden NCPeH Land-B mit einer Fehlernachricht gemäß Vorgaben aus der Tabelle TAB_NCPeH_Aufbau_VAU-Kanal_ePA_Fehlerbehandlung_XCPD antworten.

Tabelle 22: TAB_NCPeH_Aufbau_VAU-Kanal_ePA_Fehlerbehandlung_XCPD

Bei Fehlerfällen oder Timeouts, die im Zusammenhang mit den Anwendungsfällen wie 5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten, [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen] oder [5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen] entstehen, gilt folgende Anforderung:

Der NCPeH-FD MUSS eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit dem Fehlercode ERROR_PS_GENERIC gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten.

4.2.7.5 Nutzung eines etablierten VAU-Kanals zum ePA-Aktensystem

Der NCPeH-FD MUSS die Nutzung eines etablierten VAU-Kanals in seiner Rolle als VAU-Client nach [gemSpec_Krypt#7.2 Transport und Sicherung der Nutzdaten] umsetzen.

Der NCPeH-FD DARF im etablierten VAU-Kanal fachliche Requests NICHT an das ePA-Aktensystem senden, solange er sich über diesen Kanal nicht am ePA Authorization Service erfolgreich authentifiziert hat (siehe Kapitel [4.2.7.7 Authentifizierung mit dem ePA Authorization Service]).

Hinweis: Weitere Hintergründe sind [gemSpec_Krypt#7.3 OIDC-Authentisierung eines Clients] zu entnehmen.

Der NCPeH-FD KANN einen für eine Land-B Identität etablierten VAU-Kanal für Operationen auf Konten unterschiedlicher Versicherter nutzen, wenn die zu bearbeitenden UseCases dem gleichen NCPeH Land-B zuzuordnen sind.

Der NCPeH-FD MUSS die serielle Nutzung eines VAU-Kanals sicherstellen (Request-Response-Verfahren, kein Pipelining).

Erläuterung: Es entsteht durch die benötigte Authentifizierung des VAU-Clients ein beidseitig authentifizierter VAU-Kanal und somit eine feste Verknüpfung von einem bestimmten NCPeH Land-B mit diesem VAU-Kanal. Ist ein beidseitig authentifizierter VAU-Kanal idle, so kann dieser für die Abarbeitung eines eingehenden Requests aus dem zugeordneten NCPeH Land-B genutzt werden.

Der NCPeH-FD MUSS als VAU-Client den Neustart/die Wiederholung eines VAU-Verbindungsaufbaus nach [gemSpec_Krypt#A_24773*] unterstützen. In diesem Fall ist der zuvor etablierte VAU-Kanal als geschlossen zu behandeln (siehe Kapitel [4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem]).

Falls bei der Nutzung eines etablierten VAU-Kanals ein Timeout oder ein Fehler nach [gemSpec_Krypt#A_24633*] und [gemSpec_Krypt#7.6 "Fehlersignalisierung"] auftritt MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen. Er MUSS dann dem anfragenden NCPeH Land-B mit einer Fehlernachricht gemäß Vorgaben aus [eHDSI_Messaging_Profile#6.2.1] und dem Code Receiver und Subcode Busy aus [eHDSI_Messaging_Profile#6.2.2] antworten. Der NCPeH-FD MUSS das Element Reason/Text gemäß [eHDSI_Messaging_Profile#6.2.1] mit der Fehlernachricht "Error while communicating with the national electronic health record system." befüllen. 

4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem

Ein ePA-Aktensystem schließt nach 20 Minuten Inaktivität automatisch die Session mit dem ePA-Client (gemSpec_Aktensystem_ePAfuerAlle#A_25006*). Dies erfordert einen zeitlich dazu passenden Umgang mit den VAU-Kanal-Daten, die beim NCPeH-FD verwaltet werden. 

Der NCPeH-FD MUSS nach 19 Minuten Inaktivität eines etablierten VAU-Kanals diesen schließen. 

Der NCPeH-FD KANN einen etablierten VAU-Kanal über eine rechtzeitige Abfrage von /VAU-Status (gemSpec_Krypt#A_25143*) offenhalten (z. B. Abfrage alle 15 Minuten). Das im Verlauf der Autorisierung vom IDP-Dienst an das Aktensystem ausgegebene ID-Token wird im Aktensystem in ein HSM-ID-Token mit einer Gültigkeitsdauer von 24h umgewandelt und gespeichert.

Der NCPeH-FD MUSS den VAU-Kanal spätestens nach Ablauf der im Konfigurationsparameter ePA_VAU_CHANNEL_TIME hinterlegten Zeitdauer schließen. Bei Bedarf ist ein neuer VAU-Kanal zu etablieren (neuer Verbindungsaufbau VAU-Protokoll + anschließende Authentifizierung).

Hinweis: Das Schließen eines VAU-Kanals erfolgt nur durch das Löschen der lokalen, zum Kanal gehörenden Daten. Eine Information über das Schließen des VAU-Kanals vom NCPeH-FD an das ePA-Aktensystem erfolgt nicht.

4.2.7.7 Authentifizierung mit dem ePA Authorization Service

Für weitere Informationen zur Nutzung des VAU-Kanals durch die Land-B Identität siehe A_25729*.

Die Authentifizierung des NCPeH-FD, als Repräsentant des Land-B in der TI, wird durch eine eHDSI-Anfrage aus dem Land-B getriggert, die zu einem Zugriff des NCPeH-FD auf den ePA Authorization Service führt.

Bei der folgenden Kommunikation mit dem ePA Authorization Service DARF der NCPeH-FD NICHT länger auf eine Antwort warten, als der Zeitwert des Konfigurationsparameter ePA_RESPONSE_TIMEOUT (siehe A_28017*). Wenn der Zeitwert überschritten wird, MUSS der NCPeH-FD die Kommunikation abbrechen und diesen Fall als einen Fehler behandeln (siehe in diesem Kapitel den Abschnitt "Umgang mit Fehlern und Timeouts").

Vorbereitend zum OIDC-Flow (siehe Kapitel [4.2.6.4 Authentifizierung per IDP-Dienst für Zugriff auf ePA-Aktensystem]) MUSS der NCPeH-FD beim ePA Authorization Service über den zuvor aufgebauten VAU-Kanal (siehe Kapitel [4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem]) eine Attestation-Nonce abfragen. Dazu MUSS der NCPeH-FD über die REST-Schnittstelle I_Authorization_Service des ePA Authorization Service die getNonce-Operation für Authentifizierungszwecke in Übereinstimmung mit den Vorgaben aus [I_Authorization_Service] verwenden. 

Die getNonce-Operation bezieht einen eindeutigen einmalig generierten Zufallswert für die Client Attestierung (Attestation-Nonce). Der Wert wird im IDP-Dienst verwendet, um eine Client-Sitzung mit einem ID_TOKEN zu verknüpfen und CSRF-Angriffe abzuschwächen. Der Wert wird unverändert von der Authentifizierungsanfrage an das ID_TOKEN weitergegeben.

Der NCPeH-FD MUSS nach Erhalt der Attestation-Nonce, diese im HSM mit dem Signaturzertifikat C.HCI.AUT des SM-B NCPeH für das entsprechende Land-B gemäß Vorgaben aus [4.2.9 Elektronische Identitäten des NCPeH-FD] signieren.
Beim Signieren der Nonce MUSS der Signatur-Typ ECDSA-Signatur mit Kurve P-256 und SHA-256 verwendet werden.

Beginn der Authentifizierung - Authentifizierungsanfrage an ePA Authorization Service

Der eigentliche IDP-Flow startet mit der Authentifizierungsanfrage des NCPeH-FD an den ePA Authorization Service. Dazu MUSS der NCPeH-FD über die REST-Schnittstelle I_Authorization_Service des ePA Authorization Service die send_authorization_request_sc-Operation gemäß Vorgaben aus [I_Authorization_Service] nutzen. Mit dieser Operation wird die Authentifizierung des NCPeH-FD durch den zentralen IDP-Dienst initiiert.

Die Response-Nachricht enthält clientID des ePA-Aktensystems, response_type, redirect_uri, state, code_challenge, code_challenge_method, scope und nonce. Die Delegierung der Anfrage und die Kommunikation mit dem IDP-Dienst ist im [4.2.6.4 Authentifizierung per IDP-Dienst für Zugriff auf ePA-Aktensystem] beschrieben.

Abschluss der Authentifizierung - Senden des AUTHORIZATION_CODE an ePA Authorization Service

Nach erfolgreicher Authentifizierung beim IDP-Dienst und Erhalt des AUTHORIZATION_CODE (siehe Kapitel [4.2.6.4 Authentifizierung per IDP-Dienst für Zugriff auf ePA-Aktensystem]) MUSS der NCPeH über die REST-Schnittstelle I_Authorization_Service des ePA Authorization Service die Operation send_authcode_sc gemäß Vorgaben aus [I_Authorization_Service] nutzen. Mittels der Operation übermittelt der NCPeH-FD den vom IDP-Dienst erhaltenen AUTHORIZATION_CODE an den ePA Authorization Service.

Mit einer gültigen send_authcode_sc-Response entsteht zwischen dem NCPeH-FD und einer VAU-Instanz des ePA-Aktensystems ein beidseitig authentifizierter VAU-Kanal und damit ist die Ausführung von fachlichen Operationen im ePA-Aktensystem für den NCPeH-FD möglich. 

Der NCPeH-FD MUSS nach jeder erfolgreichen Authentisierung die Informationen über VAU-NP nach [gemSpec_Krypt#A24757*] aus der send_authcode_sc-Response entnehmen und für jede Land-B-spezifische SM-B die vom ePA-Aktensystem vergebene VAU-NP zwischenspeichern. Der NCPeH-FD MUSS die VAU-NP Informationen getrennt pro lokalisiertem ePA-Aktensystem zwischenspeichern (siehe Kapitel [4.2.5 Lokalisierung der Service-Endpunkte der ePA]). Für weiterführende Informationen zur Verwendung des VAU-NP siehe Kapitel [4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem]. 

Umgang mit Fehlern und Timeouts

Kommt es während des Verlaufs im Kontext des Anwendungsfalls [AF_10107-01 - Versicherten im Behandlungsland für PS-A identifizieren] zu einem Fehler oder Timeout, dann MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage des NCPeH Land-B und der dabei ermittelten Daten abbrechen und dem anfragenden NCPeH Land-B mit einer Fehlernachricht gemäß Tabelle TAB_NCPeH_Authentifizierung_ePA_Auth_Service_Fehlerbehandlung_XCPD antworten. Der NCPeH-FD MUSS den bestehenden VAU-Kanal gemäß Vorgaben in [4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem] schließen.

Tabelle 23: TAB_NCPeH_Authentifizierung_ePA_Auth_Service_Fehlerbehandlung_XCPD

Bei Fehlerfällen oder Timeouts, die im Zusammenhang mit den Anwendungsfällen wie [5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten], [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen] oder [5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen] entstehen, dann gilt folgende Anforderung:

Der NCPeH-FD MUSS eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit dem Fehlercode ERROR_PS_GENERIC gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten.

4.2.7.8 Adressierung des Aktenkontos

Der NCPeH-FD adressiert das gewünschte Aktenkonto über die KVNR des Versicherten.

Der NCPeH-FD MUSS bei Aufrufen der ePA-Dienste innerhalb der VAU zur Adressierung des Aktenkontos ein HTTP Header Element mit dem Namen "x-insurantId" und der Angabe der KVNR des Versicherten senden. Die KVNR ist der internen Aktenkontosession zu entnehmen (siehe Kapitel [4.2.7.2 Interne Aktenkontosession für einen Versicherten]).

4.2.8 Befüllung von SOAP Header Elementen für Zugriff auf ePA XDS Document Service

Der NCPeH-FD MUSS beim Aufruf der Operation RegistryStoredQuery und RetrieveDocumentSet (Schnittstelle I_Document_Management_Ncpeh) die Elemente im SOAP Header der Anfrage gemäß Vorgaben aus der Schemadefinition [Schema_ePA_XDSDocumentService] nutzen. Dabei MUSS die Befüllung der Elemente gemäß Tabelle TAB_Befüllung_Elemente_SOAP_Header_XDS_Document_Service erfolgen.

Tabelle 24: TAB_Befüllung_Elemente_SOAP_Header_XDS_Document_Service

4.2.9 Elektronische Identitäten des NCPeH-FD

Der NCPeH-FD ermöglicht es anderen europäischen Mitgliedstaaten bzw. den durch sie vertretenen technischen Akteuren NCPeH Land-B, als Nutzer an der TI teilzunehmen. Dabei stellt der NCPeH-FD sicher, dass jedem NCPeH Land-B innerhalb der TI eine kryptographische Identität zugeordnet ist, die er für die Identitätsbestätigung gegenüber einem Dienst der TI verwenden muss.

Hinweis: Parallel zu diesen Anforderungen siehe auch die Sicherheitsanforderung A_22909* zum sicheren Betrieb und Nutzung von HSM.

Hinweis: Der NCPeH-FD verwendet Schlüsselmaterial "SM-B NCPeH" gemäß [gemSpec_PKI#"SM-B NCPeH"] mit der OID-Referenz oid_ncpeh gemäß [gemSpec_OID#Tab_PKI_403].

Im Kapitel [4.3 Sicherheit und Datenschutz] sind weitere relevante Anforderungen enthalten, die sich auf den Einsatz von HSM beziehen, insbesondere im Zusammenhang mit der sicheren Aufbewahrung von privaten Schlüsseln, die von der TI und eHDSI ausgestellt wurden. Diese Anforderungen umfassen Aspekte der HSM-Kryptographieschnittstelle, der Intergritätsprüfung der VAU, der Managementprozesse des HSM, des sicheren Betriebs von HSM sowie des Einsatzes zertifizierter HSM.

Auswahl der NCPeH Identität für ein Land-B

Um das passende Signaturzertifikat als Repräsentation des NCPeH Land-B innerhalb der TI im HSM referenzieren zu können, ermittelt der NCPeH-FD die Länderkennung (Ländercode) des NCPeH Land-B innerhalb der eHDSI.

Diese Zeichenkette entspricht folgendem strukturellen Aufbau:

1. Teilstring: deutsche amtliche Kurzform eines Ländernamens gemäß [LVZ],
2. Teilstring: " (",
3. Teilstring: zweibuchstabiger Ländercode nach DIN EN ISO 3166-1 gemäß [LVZ],
4. Teilstring: ")".

Beispiel einer Zuordnung des Signaturzertifikats zu dem NCPeH von Frankreich: Frankreich (FR)

4.2.10 Übergreifende Vorgaben an die Kommunikation mit E-Rezept-FD

4.2.10.1 Allgemeine Vorgaben an die Kommunikation mit dem E-Rezept-FD

4.2.10.2 Lokalisierung und Namensauflösung des E-Rezept-FD

Hinweis: Der E-Rezept-FD ist gemäß den Festlegungen in [gemSpec_FD_eRp#Servicelokalisierung] lokalisierbar.

Hinweis: Für den Verbindungsaufbau mit dem E-Rezept-FD sind verschiedene Endpunkte in [github_Endpunkte_E-Rezept-FD_IDP-Dienst] angegeben.

Das Redundanzkonzept des E-Rezept-FD sieht mehrere Instanzen vor, die über verschiedene IP-Adressen angesprochen werden. Folglich liefert die DNS-Namensauflösung verschiedene IP-Adressen zum FQDN zurück. Diese Adressen werden vom DNS-Server in zufälliger Reihenfolge geschickt, sodass es legitim ist, immer den ersten Eintrag für den folgenden Operationsaufruf zu verwenden.

4.2.10.3 Verschlüsselte Kommunikation zur VAU des E-Rezept-FD

Hinweis zum Fehlerhandling: Nur wenn der äußere Response des E-Rezept-FD den Response-Code 200 liefert, enthält der Payload eine mittels VAU-Protokoll verschlüsselte Response.

4.2.10.4 Authentifizierung des NCPeH-FD am E-Rezept-FD

Dieses Kapitel beschreibt den Ablauf der Authentisierung und Identifizierung des NCPeH-FD beim IDP-Dienst, um Zugriff auf den E-Rezept-FD zu erhalten, einschließlich der Beantragung und Verwendung von ACCESS_TOKEN sowie der relevanten Sicherheitsmaßnahmen und technischen Spezifikationen.

Der NCPeH-FD, als Repräsentant des NCPeH Land-B in der TI, authentisiert sich gegenüber dem IDP-Dienst für Zugriffe auf Dienste der TI im Rahmen der Anwendung E-Rezept.

Wenn für die TI-Identität des NCPeH Land-B für den Zugriff auf E-Rezept-FD im NCPeH-FD kein gültiges ACCESS_TOKEN vorliegt, dann beantragt der NCPeH-FD das benötigte ACCESS_TOKEN beim IDP-Dienst. Hierfür wird am Authorization-Endpunkt des IDP-Dienstes ein AUTHORIZATION_CODE beantragt, der nach erfolgreicher Verifikation am Token-Endpunkt des IDP-Dienstes gegen ein ID_TOKEN und einen ACCESS_TOKEN getauscht wird.

Die für die Beantragung des AUTHORIZATION_CODE im Challenge-Response-Verfahren notwendige elektronische Signatur erstellt der NCPeH-FD mittels entsprechender AUT-Identität der SM-B für das Land-B gemäß Vorgaben aus [4.2.9 Elektronische Identitäten des NCPeH-FD].

Der IDP-Dienst führt die Identifikation des NCPeH-FD durch, und stattet diese anschließend mit ID_TOKEN gemäß [openid-connect-core#IDToken] und ACCESS_TOKEN gemäß [RFC6749 # section-1.4] & [RFC6749 # section-5] aus. Dabei wurde aus Sicherheitsaspekten der "authorization code grant" gemäß [RFC6749 # section-4.1] gewählt. Um dem erforderlichen Sicherheitsniveau gerecht zu werden, wird zudem die Verwendung von PKCE (Proof Key for Code Exchange by OAuth Public Clients) gemäß [RFC7636] vorgesehen.

Der IDP-Dienst selbst teilt sich in mehrere statisch adressierte Teildienste auf. Diese umfassen:

• Discovery-Endpunkt ("OAuth 2.0 Authorization Server Metadata" [RFC8414]),
• Authorization-Endpunkt (Teil des "The OAuth 2.0 Authorization Framework" [RFC6749]),
• Token-Endpunkt [RFC6749#section-3.2].

Für weitere Informationen zum IDP-Dienst und zum Ablauf der Authentisierung siehe [gemSpec_IDP_Dienst] und [gemILF_PS_eRp#Abruf von Token beim IDP-Dienst].

Für die Nutzung des IDP-Dienstes im Zusammenhang mit dem E-Rezept-FD gelten die übergreifenden Vorgaben aus [4.2.6.1 Registrierung beim IDP-Dienst], [4.2.6.2 Verarbeitung des Discovery Document] und [4.2.6.3 TLS-Verbindungsaufbau zu Service-Endpunkten des IDP-Dienstes].

4.2.10.5 Abruf von Token vom IDP-Dienst

Der folgende Abschnitt umfasst Vorgaben, die den Ablauf der Beantragung und Ausgabe von Token bestimmen.

Der Abruf von Token vom IDP-Dienst für den E-Rezept-FD folgt den Vorgaben aus [gemILF_PS_eRp#Abruf von Token beim IDP-Dienst], die dort auch für den NCPeH-FD vorgegeben werden. In diesem Abschnitt erfolgen zusätzlich einige Präzisierungen für den NCPeH-FD.

Hinweis: Für weitere Informationen siehe auch in der Dokumentation [api-erp] auf github [Als Nutzer gegenüber der Telematikinfrastruktur authentisieren].

4.2.10.6 Erstellung des Payload für die Kommunikation mit dem E-Rezept-FD

Hinweis: ACCESS_TOKEN ist ein vom IDP-Dienst ausgestellter ACCESS_TOKEN. Für mehr Informationen siehe Kapitel [4.2.10.4 Authentifizierung des NCPeH-FD am E-Rezept-FD].

4.2.10.7 Regelung zur Unterstützung von mehreren FHIR-Package Versionen

Der NCPeH-FD setzt für ePeD-A FHIR-Profile aus den folgenden FHIR-Profil-Packages um:

• "kbv.ita.erp" [https://simplifier.net/erezept],
• "de.gematik.erezept.eu" [https://simplifier.net/erezept-workflow-eu].

Das Package "kbv.ita.erp" definiert das Datenmodell für Verordnungsdaten. Es wird durch die Kassenärztliche Bundesvereinigung (KBV) sowie dem GKV-SV verantwortet und durch die KBV veröffentlicht. Die zeitliche Gültigkeit der Versionen des Packages "kbv.ita.erp" ist in [KBV_ITA_VGEX_Technische_Anlage_ERP] beschrieben. Eine neue Version des Package wird in der Regel mit einem Vorlauf von 9 Monaten vor Gültigkeit in der Produktivumgebung veröffentlicht. Diese Regelung schließt einen anderen Vorlauf der Veröffentlichung und Inkraftsetzung nicht aus.

Für die Einführung in den Produktivbetrieb wird den Verordnungsausstellenden Leistungserbringerinstitution (LEI) eine Übergangsfrist von mehreren Monaten nach Gültigkeitsbeginn (beim letzten Profilwechsel 6 Monate) eingeräumt. In diesem Zeitraum akzeptiert der E-Rezept-FD Verordnungen in der alten und neuen Profilversion. D.h.

In den Informationen zu einer Verordnung werden Wertekataloge (bspw. Darreichungsform) verwendet, welche durch die Informationsstelle für Arzneispezialitäten – IFA GmbH (IFA) veröffentlicht werden. Sie werden spätestens 3 Monate vor Gültigkeit in der Produktivumgebung veröffentlicht.

Das Package "de.gematik.erezept.eu" definiert das Datenmodell für die Übermittlung der Dispensierinformationen. Es wird durch die gematik verantwortet und veröffentlicht. Die zeitliche Gültigkeit der Versionen des Packages "de.gematik.erezept.eu" wird in [FHIR_Version_E-Rezept_EU] beschrieben. Eine neue Version des Package wird mit einem Vorlauf von 6 Monaten vor Gültigkeit in der Produktivumgebung veröffentlicht. Für die Einführung in den Produktivbetrieb wird eine Übergangsfrist von 3 Monaten nach Gültigkeitsbeginn eingeräumt.

Die Planung von neuen Profilversionen wird von der gematik auf [api-erp] veröffentlicht.

Hinweise zu anstehenden Veränderungen in FHIR-Profilen sind auch in der [E-Rezept API-Dokumentation#Aktuelles] zu finden.

4.3 Sicherheit und Datenschutz

Die Akzeptanz des NCPeH-FD durch die Nutzer wird maßgeblich durch die Gewährleistung des Datenschutzes und - damit verbunden - der Sicherheit der personenbezogenen medizinischen Daten beeinflusst. Der Datenschutz und die Informationssicherheit des NCPeH-FD wird durch das Aufstellen von umfassenden, prüfbaren Anforderungen durch die gematik sichergestellt. Die Überprüfung dieser Anforderungen geschieht sowohl vor der ersten Inbetriebnahme durch die gematik, als auch regelmäßig im laufenden Betrieb durch den Anbieter des NCPeH-FD selbst. Qualitätsgesicherte Prozesse in Form von Audits der gematik und der EU halten die Überprüfungsergebnisse fest.

4.3.1 Generelle Anforderungen

Hinweis: Die Anforderungen des BSI-Bausteins sind entsprechend des dort genannten Schlüsselwortes („MUSS, DARF NICHT/ DARF KEIN, SOLLTE; SOLLTE NICHT/SOLLTE KEIN, KANN/DARF“) umzusetzen.

Hinweis: Das Löschkonzept kann Teil des Sicherheits- oder Datenschutzkonzeptes des Anbieters sein. Es ist nicht notwendigerweise ein eigenes Dokument erforderlich.

Hinweis: Die Prüfung der eingehenden Nachrichten auf Syntax-, Semantik- und Protokollverletzungen soll insbesondere den Angriffstypen XML Injection, XPath Query Tampering, XML External Entity Injection und XML Signature Wrapping entgegenwirken.

Die Non-Repudiations und Audit Trail Einträge können durch den Versicherten, durch einen befugten Vertreter oder der befugten nationalen Stelle eingesehen werden. Versicherte können bei dem Anbieter des NCPeH-FD beantragen, die Non-Repudiations und Audit Trail Einträge zur Verfügung gestellt zu bekommen.

4.3.2 Anforderungen an die Vertrauenswürdige Ausführungsumgebung

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

Vertrauenswürdige Ausführungsumgebung (VAU): Gesamtheit der für eine sichere Klartextverarbeitung erforderlichen Software und Hardware beim Betreiber des NCPeH-FD. Zur Hardware gehören insbesondere die VAU-Server sowie alle für die betriebliche Steuerung erforderlichen Komponenten (VAU-Management). Zur VAU gehören NICHT die Systeme zur Speicherung von Daten.

VAU-Image: Geprüfte Software zur Verarbeitung von Daten einer Anwendung im Klartext. Das VAU-Image muss alle Software enthalten, die zur sicheren Klartextverarbeitung beiträgt. Es ist die Code-Basis der Verarbeitungskontexte.

VAU-Image-Hersteller: entwickelt die notwendige Software für das VAU-Image.

Verarbeitungskontext: Die Ausführung einer Instanz eines VAU-Images, in dem die Daten einer Anwendung im NCPeH-FD zur Laufzeit im Klartext verarbeitet werden.

4.3.2.1 Schutz der Integrität der VAU

4.3.2.2 Schutz der Daten bei Verarbeitung in der VAU

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

4.3.2.3 Anforderungen zu Schnittstellen des Verarbeitungskontexts

4.3.2.4 Schutz der Daten bei Speicherung außerhalb der VAU

4.3.3 Anforderungen an das HSM

4.4 Betrieb

In diesem Kapitel werden übergreifende, betriebliche Anforderungen getroffen oder auf Kapitel mit speziellen Ausprägungen für den NCPeH Deutschland in normativen Querschnittsdokumenten verwiesen.

4.4.1 Schnittstellen und Anwendungsfälle

Die durch den NCPeH-FD zur Verfügung gestellten Schnittstellen und Anwendungsfälle werden in [gemKPT_Betr#National Contact Point for E-Health (PDT69)] dargestellt.

4.4.2 Leistungsanforderungen

Die vom NCPeH-FD zu leistenden Vorgaben werden übersichtlich in [gemSpec_Perf#Performance Vorgaben NCPeH-Fachdienst dargestellt.

4.4.3 Aufnahme eines Country Service Desks

Der Country Service Desk agiert in erster Linie als First-Level Service Desk für den abgegrenzten Nutzerkreis des NCPeH. Er erfüllt damit sowohl Aufgaben eines User Help Desks (UHD), als auch Aufgaben eines Versicherten Help-Desks (VHD).

Die Anforderungen an den Country Service Desk werden in [gemKPT_Betr#3.6.3] näher beschrieben. Weitere Referenzen finden sich in [gemKPT_Betr#6.3 Country Service Desk] des [eHDSI_Operations_Framework] und in [gemKPT_Betr#03.01] sowie [gemKPT_Betr#03.02] des [eHDSI_Requirements_Catalogue].

Der Anbieter des NCPeH-FD DARF nachfolgende Nutzerkreise gemäß [6.3.1#eHDSI_Operations_Framework] temporär ausschließen, sofern die jeweils angegebenen Bedingungen erfüllt sind:

• Health professional (Leistungserbringer) und Third party vendors / Software integrators (Hersteller): Nur solange keine Funktionalität zum Abruf von Daten europäischer Mitgliedstaaten (Land-B) über den NCPeH-FD in Umsetzung ist.

Auf Anfrage der gematik MUSS der Anbieter des NCPeH-FD darlegen können, welche Nutzerkreise am Country Service Desk teilnehmen.

Der Anbieter des NCPeH-FD SOLL zusätzlich zur eHDSI-Kategorisierung des Country Service Desks, weitere Datenfelder aufnehmen, welche nachfolgend beschrieben werden:

• Requester Name/Identification: Die Person oder Entität, welche den Incident/die Information an den Country Service Desk meldete.
• Submission Date: Das Datum, an dem der Incident/Service Request erstellt wurde.
• Registration Date: Das Datum, an dem der Incident/Service Request zu den technischen Lösungen hinzugefügt wurde.
• Status: Der Status des Incidents/Service Requests nach dem definierten Workflow.

Die Möglichkeit zur Aufnahme dieser Felder zwingt NICHT zur verpflichtenden Nutzung. Die Nutzung der zusätzlichen Felder ist auch stets nach Gesichtspunkten der DSGVO auszurichten. Dies bedeutet vor allem, dass der im Prozess verankerte Zweck zur Erhebung und Speicherung von teils personenbezogenen Daten deutlich ist.

4.4.4 Monitoring

Das Monitoring ist als Teil des Event-Managements gemäß [ITIL] anzusehen. Es umfasst die kontinuierliche Aufnahme und Überwachung von Ereignissen und stellt die Informationsgrundlage zu den verfügbaren IT-Services her. Sowohl der NCPeH-FD, als auch die darunterliegenden Systeme erzeugen zu jeder Zeit Informationen, um den Zustand des jeweiligen Systems zu analysieren und zu bewerten.

4.4.4.1 Erfassung und Lieferung von Rohdaten

Die durch den NCPeH-FD und den Betreiber zu erfüllenden Anforderungen hinsichtlich der Erfassung und Lieferung von Rohdaten an die gematik, werden in [gemSpec_Perf#Betriebsdatenerfassung v2 Spezifika NCPeH-FD] dargestellt.

Der Betreiber muss sicherstellen, dass die vom NCPeH-FD zugänglich gemachten Informationen des folgenden Kapitels im spezifizierten Maß sicher sowohl an die eHDSI, als auch an die gematik erfolgen.

4.4.4.2 Erfassung und Lieferung von eHDSI-Kennzahlen

Um die Anforderungen der eHDSI zur Erfassung und Lieferung von eHDSI-Kennzahlen zu konkretisieren, werden in diesem Kapitel weiterführende Festlegungen dazu getroffen. Der Inhalt und die Implementierungsrichtlinien von eHDSI-Kennzahlen werden genauer unter Kapitel 3, Tabellen 2 bis 25 [eHDSI_Monitoring_Framework] beschrieben.

Der NCPeH-FD MUSS eHDSI-Kennzahlen nach [eHDSI Monitoring Framework] automatisiert erheben.
Alle eHDSI-Kennzahlen zur Erfassung unterschiedlicher Nutzer (distinct users), werden als kritisch eingestuft.
Die restlichen eHDSI-Kennzahlen werden als unkritisch eingestuft.

Vor allem die kritischen eHDSI-Kennzahlen MÜSSEN auf eine Weise im NCPeH-FD verarbeitet werden, welche keine Rückschlüsse auf personenbezogene Informationen in den zur Verfügung gestellten Daten zulässt.

Der NCPeH-FD MUSS jede eHDSI-Kennzahl nach folgendem Schema zugänglich machen:

• für unkritische eHDSI-Kennzahl: unmittelbar nach der Erhebung,
• für kritische eHDSI-Kennzahl: je nach Implementation entweder unmittelbar nach der Erhebung oder via eines anonymisierten Dateiexports am Ende des vorgegebenen Berichtsintervalls.

Das Berichtsintervall für die eHDSI-Kennzahlen sind unter Kapitel 2, Tabelle 1, Spalte "Frequency" des [eHDSI_Monitoring_Framework] zu finden.

Die Erhebung von kritischen Kennzahlen muss innerhalb der VAU erfolgen. Für die konkrete Verarbeitung von kritischen Kennzahlen kommen zwei Ansätze in Frage:

1. Unmittelbares Herausschreiben der eHDSI-Kennzahl mit speziellen Maßnahmen,
2. Sammeln der Daten zur eHDSI-Kennzahl in der VAU und Export am Ende des Berichtsintervalls nach außen.

Für jeden Ansatz wird ein Implementierungsbeispiel grob skizziert:

1. Unmittelbares Herausschreiben

Da bei kritischen eHDSI-Kennzahlen eine Erhebung und Verarbeitung von personenbezogenen Daten - hier der Identifier des Versicherten, also die KVNR - unumgänglich ist, müssen spezielle Maßnahmen umgesetzt werden. Mit Hilfe dieser Maßnahmen muss es dem Betreiber des NCPeH-FD ermöglicht werden, die eHDSI-Kennzahl im eigenen Monitoringsystem auszuwerten und im Berichtszeitraum für das Reporting an die eHDSI zu ermitteln.

Diese Maßnahmen umfassen die starke Pseudonymisierung des identifizierenden Merkmals, der KVNR, sodass ohne Kenntnis des Pseudonymisierungsgeheimnisses, kein Rückschluss auf den Originalwert stattfinden kann. Dafür soll ein sicheres Pseudonymisierungsgeheimnis genutzt werden, welche nach jedem Berichtsintervall (quartalsweise) vollständig erneuert wird. Damit wird verhindert, dass die Pseudonyme über Quartalsgrenzen im Monitoring verfolgt werden können und eine Profilbildung stattfindet.

Als Beispiel wird eine KVNR mit einem 256-bit Pseudonymisierungsgeheimnis mittels SHA256-Algorithmus state-of-the-art pseudonymisiert. Der Hashwert und entsprechende eHDSI-Kennzahl werden herausgeschrieben und der Datensatz im Monitoringsystem des Betreibers zur Laufzeit hinterlegt. Dem Betreiber ist es nun auch während des Berichtszeitraumes möglich, Auswertungen über diese Kennzahl inmitten des Berichtsintervalls durchzuführen. Zur Erstellung des eHDSI-Kennzahlreports ist es dem Betreiber ebenso möglich, diese eHDSI-Kennzahlen mit dem Verlauf über dem Berichtsintervall darzustellen.

Die Problematik dieses Ansatzes besteht in der sicheren Erzeugung und Wiedererzeugung des Pseudonymisierungsgeheimnisses und der Anwendung von starken State-of-the-Art Hashingalgorithmen zur Laufzeit im NCPeH-FD. Dieser Prozess bindet Verarbeitungsressourcen zur Laufzeit für die Generation des Hashes.

2. Sammeln der Daten und Export

In der VAU können personenbezogene Daten nachgehalten und diese in Form einer Datenstruktur für die Datensammlung im Berichtszeitraum weitergenutzt werden. Am Ende eines Berichtsintervalls wird dann pro kritische eHDSI-Kennzahl ein Dateiexport angelegt, welcher die Informationen in anonymisierter Form enthält und diese Informationen für den Betreiber zugänglich macht.

Am Beispiel: KPI-1.12 "Number of citizens who have used the Patient Summary service" wird folgende beispielhafte Datenstruktur in der VAU gehalten:

Tabelle 29: TAB_NCPeH_VAU-Datenstruktur_zu_kritischer_KPI-1.12

Anstatt der KVNR kann auch ein pseudonymer Wert, basierend auf der KVNR, genutzt werden, bspw. mithilfe eines Hashings, jedoch muss weiterhin eine direkte Zuordenbarkeit innerhalb des Berichtszeitraumes für subsequente Anfragen des Versicherten gewährleistet sein.

Am Ende des Berichtszeitraumes wird eine anonymisierte Datei daraus erzeugt und aus der VAU exportiert, welche folgenden beispielhaften Inhalt hat:

Tabelle 30: TAB_NCPeH_Berichtsdatenstruktur_zu_kritischer_KPI-1.12

Als Problematik wird hier das Verhalten über mehrere Laufzeiten hinweg angesehen. Die gespeicherten Daten müssen auch nach einem Neustart/Update der Applikation im Berichtszeitraum zur Verfügung stehen und damit statisch nachgehalten werden. Es werden dadurch in erster Linie Ressourcen zur Verarbeitung und Speicherung gebunden. Zusätzlich zum Exportzeitpunkt auch noch weitere Ressourcen für den Export und das Bereinigen der Datenstrukturen.

Sowohl das Exportprozedere, als auch die Speicherung der Daten muss zum jeweiligen Zeitpunkt den höchsten Sicherheitsanforderungen entsprechen und fehlerfrei funktionieren.

Darüber hinaus stehen die Werte von kritischen eHDSI-Kennzahlen nur einmal im Quartal gesammelt zur Verfügung, sodass es nur vier definierte Datenpunkte pro Jahr geben kann und weitere Rückschlüsse auf Nutzungsverhalten unterbunden sind.

Der Betreiber des NCPeH-FD MUSS eHDSI-Kennzahlen im vorgeschriebenen Intervall und Format an die eHDSI und die gematik liefern. Dabei sind die unterschiedlichen Anlieferwege zu beachten.

Folgende Tabelle listet alle derzeit relevanten eHDSI-Kennzahlen nach [eHDSI Monitoring Framework] auf, die für den implementierten NCPeH geliefert werden müssen:

Tabelle 31: TAB_NCPeH_eHDSI-Kennzahlen

Bei Erweiterung des NCPeH mit zusätzlichen Anwendungsfällen (bspw. ePrescription/Land-B-Szenario) oder bei Aktualisierung der eHDSI-Dokumente folgt "Tabelle 12: eHDSI-Kennzahlen" der normativen eHDSI-Spezifikation und wird entsprechend der dann geltenden eHDSI-Kennzahlen an die geltende Normative angepasst.

4.4.5 Logging

Das Logging ist ebenfalls als Teil des Event-Managements gemäß [ITILv4] anzusehen. Es umfasst die kontinuierliche Aufnahme und Analyse von Informationen rund um vordefinierte Ereignisse (Logeinträge), jedoch mit dem Fokus auf der Nachhaltung von Einträgen aus bestimmten Quellen. Vom NCPeH-FD erzeugte Applikationslogs oder von der VAU ausgegebene Informationen werden hier konkret gesammelt und können dadurch jedoch erst nachgelagert ausgewertet und analysiert werden. Das Logging dient hauptsächlich zur Fehlersuche und dem Nachvollziehen von internen Prozesses des NCPeH-FD, ohne personenbezogene Daten preiszugeben.

Alle erfassten Daten zum Logging MÜSSEN mindestens 90 Tage lang vollständig aufbewahrt werden, um eine nachfolgende Fehlersuche und Tracing zu ermöglichen.

Alle aufgetretenen Fehlermeldungen müssen nach den Vorgaben der eHDSI mit den entsprechenden Codes in das Logging aufgenommen werden. Eine tabellarische Auflistung von Fehlerzuständen und eindeutigen Identifikationsmerkmalen findet sich in Kapitel 6.4 "eHealth DSI Error Codes" [eHDSI_NCPeH_Components] in den Tabellen 1-4. Darüber hinaus sind auch weitere Vorgaben aus spezielleren Transaktionsprofilen einzuhalten. Dazu vor allem die IHE-Profile der eHDSI.

4.4.6 Betriebshandbuch

Das Betriebshandbuch dient zur Dokumentation von operationalisiertem Wissen im Rahmen der Betriebstätigkeiten um den NCPeH-FD. Es ermöglicht einen Wissensaustausch und erleichtert die Abbildung vorhandener Prozesse in lesbarer und verständlicher Form. Die Erstellung und Pflege eines Betriebshandbuches geschieht vorrangig digital und gehört zu den anzufertigenden Dokumentationen des Anbieters.

Da der NCPeH-FD als gegebene Besonderheit sowohl im deutschen, als auch übergreifend im europäischen (und damit englischen) Sprachraum agiert, wird zusätzlich zur Festlegung GS-A_5343 in [gemRL_Betr_TI#2.2.1 Auszüge aus dem Betriebshandbuch der TI-ITSM-Teilnehmer] in Verbindung mit GS-A_4090, eine Erweiterung der Sprachregelung von zu liefernden Dokumentationen in [gemRL_Betr_TI#2.1.2 Kommunikation] mit A_24012* spezifiziert. 

4.4.7 Verwaltung von Einträgen im Verzeichnisdienst FHIR

Um Berechtigungen zum Abruf bzw. der Nutzung des NCPeH als Versicherter hinterlegen zu können, werden zwingend aktuelle Informationen im Verzeichnisdienst FHIR benötigt. Diese Informationen setzen sich sowohl aus dem Angebot des in Betrieb befindlichen NCPeH-FD, als auch aus den von ihm verwalteten SM-B Zertifikaten zusammen.

Hinweis: Das Management von Einträgen im Verzeichnisdienst FHIR kann im Moment über Service-Requests des Anbieters zentrale Dienste gestellt werden. Die gematik stellt dem Anbieter des NCPeH-FD den nötigen Servicekatalogeintrag zur Verfügung.

Weitere Informationen zum Verzeichnisdienst / Verzeichnisdienst FHIR finden sich hier: [https://github.com/gematik/api-vzd/] 

5 Fachliche Anwendungsfälle

5.1 Anwendungsfälle für Patient Summary Land-A

5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren

5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten

5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen

5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen

Dieser Anwendungsfall ist weitgehend identisch mit dem Anwendungsfall [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen]. In diesem Anwendungsfall stellt der NCPeH-FD auf Anfrage des NCPeH Land-B die medizinischen ePKA-Daten des Versicherten im PDF/A-Format bereit. Das ePKA MIO des Versicherten wird dazu in dieses Format transformiert. Dabei bleiben die medizinischen Daten des ePKA MIO so wie sie vom LE in DE im ePA-Aktensystem eingestellt wurden und werden nicht zusätzlich auf englische Begriffe gemäß MTC abgebildet (keine Transkodierung). Bedingung für den erfolgreichen Abruf von ePKA MIO ist eine vorherige Zugriffsfreigabe durch den Versicherten. Die Zugriffsfreigabe erteilt der Versicherte mittels seines FdV im ePA-Aktensystem.

5.2 Anwendungsfälle für ePrescription/eDispensation Land-A

5.2.1 NCPeH.UC_9 - Versicherten im Behandlungsland für ePeD-A identifizieren

Der Anwendungsfall zur Patient Identification für das Szenario ePeD-A ähnelt dem Kapitel [5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren]. Der Unterschied zum Anwendungsfall besteht darin, dass dem LE-EU unter Verwendung der KVNR und des Zugriffscodes des Versicherten die demographischen Versichertendaten aus dem zuletzt im E-Rezept-FD eingestellten E-Rezept übermittelt werden. Die Ermittlung des E-Rezepts erfolgt durch eine Anfrage des NCPeH-FD beim E-Rezept-FD. Voraussetzung für die Ermittlung und Bereitstellung des E-Rezepts ist das Vorliegen einer gültigen Zugriffsberechtigung im E-Rezept-FD. Die Zugriffsberechtigung erteilt der Versicherte im Voraus mit seinem E-Rezept-FdV. Die Verifikation der Zugriffsberechtigung des Versicherten erfolgt durch den E-Rezept-FD. 

5.2.2 NCPeH.UC_10 - Einlösbare E-Rezepte des Versicherten aus ePeD-A auflisten

In diesem Anwendungsfall muss der NCPeH-FD in der Lage sein, auf berechtigte Anfrage des NCPeH Land-B Informationen über die einlösbaren E-Rezepte des Versicherten bereitzustellen. Die Anfrage des NCPeH Land-B enthält die Identität des LE-EU, die KVNR des Versicherten, den Zugriffscode und die elektronische Zusicherung des Abgabelandes (Land-B) über das Bestehen einer Behandlungsbeziehung zwischen dem anfragenden LE-EU und dem Versicherten. Die Ermittlung der einlösbaren E-Rezepte erfolgt durch eine Abfrage des NCPeH-FD beim E-Rezept-FD. Voraussetzung für die Ermittlung von E-Rezepten ist das Vorliegen einer gültigen Zugriffsberechtigung im E-Rezept-FD. Die Zugriffsberechtigung erteilt der Versicherte im Voraus mit seinem E-Rezept-FdV. Der gesamte Prozess endet mit der Übermittlung einer Liste in der EU einlösbarer E-Rezepte des Versicherten an den NCPeH Land-B.

5.2.3 NCPeH.UC_11 - Ausgewählte E-Rezepte aus ePeD-A abrufen

Anhand der Übersicht der einlösbaren E-Rezepte, die dem LE-EU bereitgestellt werden, wählt dieser die E-Rezepte aus, die der Versicherte einlösen möchte. Nach der Abstimmung zwischen LE-EU und Versichertem stellt der LE-EU über den NCPeH Land-B eine Anfrage an den NCPeH-FD, um die E-Rezepte in mindestens einem der beiden Dokumentformaten (eHDSI Pivotformat CDA Level 1 und Level 3) abzurufen.

In diesem Anwendungsfall antwortet der NCPeH-FD auf die berechtigte Anfrage aus Land-B, indem er die E-Rezepte des Versicherten in den angeforderten Dokumentformaten bereitstellt. Hierfür stellt der NCPeH-FD die Schnittstelle gemäß [6.1.3 Operation Cross_Gateway_Retrieve::RetrieveDocument] und nach [eHDSI_XCA_Profile#2.4] zur Verfügung. Die Ermittlung der angeforderten E-Rezepte erfolgt durch eine Anfrage des NCPeH-FD beim E-Rezept-FD. Voraussetzung für die Ermittlung und Bereitstellung der E-Rezepte ist das Vorliegen einer gültigen Zugriffsberechtigung im E-Rezept-FD. Die Zugriffsberechtigung erteilt der Versicherte im Voraus mit seinem E-Rezept-FdV. Die Verifikation der Zugriffsberechtigung des Versicherten erfolgt durch den E-Rezept-FD. 

Der NCPeH-FD stellt sicher, dass die ermittelten E-Rezepte vor der Übermittlung an den NCPeH von Land-B zur Laufzeit transformiert werden und die maschinenlesbaren Elemente der E-Rezepte korrekt transkodiert sind.

5.2.4 NCPeH.UC_12 - Abgabe von Arzneimitteln an Versicherte im Abgabeland

Im Anwendungsfall im [5.2.3 NCPeH.UC_11 - Ausgewählte E-Rezepte aus ePeD-A abrufen] hat der LE-EU Informationen zu den E-Rezepten eines Versicherten abgerufen. Für die E-Rezepte, die er abgeben möchte, sendet der LE-EU Dispensierinformationen im eHDSI eDispensation CDA-Pivotformat über den NCPeH Land-B an den NCPeH-FD. Der NCPeH-FD bestätigt daraufhin den Abschluss des E-Rezept-Workflows für den betreffenden Task und lässt die übermittelten Dispensierinformationen im E-Rezept-FD für den Versicherten speichern.

Der NCPeH-FD übernimmt in diesem Kontext zwei wesentliche Aufgaben. Zunächst stellt er innerhalb der eHDSI eine spezifische Schnittstelle bereit. Diese Schnittstelle entspricht den Vorgaben, die im [6.1.5 Operation Cross-Enterprise Document_Reliable_Interchange::ProvideAndRegisterDocumentSet-b] sowie in [eHDSI_XCA_Profile#2.4] definiert sind. Darüber hinaus ist der NCPeH-FD für die Verarbeitung der Dispensierinformationen verantwortlich. Bevor diese Informationen an den E-Rezept-FD weitergeleitet werden, führt der NCPeH-FD eine Laufzeittransformation durch. Zusätzlich werden die maschinenlesbaren Elemente gemäß den Vorgaben des BfArM transkodiert.

5.3 Administrative Anwendungsfälle

5.3.1 NCPeH.UC_5 - Evidence & Audit Trails aus Audit Repository abrufen

In diesem Anwendungsfall MUSS der berechtigte Prozessverantwortliche über eine technische Schnittstelle Evidence und Audit Trail Einträge aus dem Audit Repository auswählen, die im Zusammenhang mit der Verarbeitung von Identitäts- und medizinischen Daten von Versicherten stehen, um sie anschließend in seinem Monitoringsystem abzurufen und ggf. auszuwerten. Dies kann z. B. in einem Szenario geschehen, in dem überprüft werden muss, ob personenbezogene oder administrative Daten im NCPeH-FD manipuliert wurden (siehe [eHDSI Section II - Security Services#6.5]). Ferner MUSS der berechtigte Prozessverantwortliche Anfragen von betroffenen Versicherten oder der befugten nationalen Stelle beantworten und dabei die für den Fall erforderlichen Nachweise (Evidence) aus dem Audit Repository abrufen und dem Antragsteller bereitstellen.

Zuletzt soll darauf hingewiesen werden, dass ebenfalls die Vorgaben aus [eHDSI_NCPeH_Architecture_Specification] Kapitel „Audit Repository“ für die Umsetzung heranzuziehen sind.

Hinweis: Die Definition und Festlegung der Technologie zur Umsetzung der technischen Schnittstelle liegt in Hoheit des Anbieters des NCPeH-FD (siehe Kapitel [1.4 Abgrenzungen] und [2 Systemüberblick]).

5.3.2 NCPeH.UC_6 - Service Metadata auf eHDSI Configuration Service verwalten

In diesem Anwendungsfall verwalten die berechtigten Systemadministratoren über eine Administrationsschnittstelle die Service Metadata des NCPeH-FD nach dem 4-Augen-Prinzip. Die Service Metadata enthalten Metadaten über einen Dienst, den ein NCPeH Land-B kennen muss, um eine Nachricht an diesen Dienst senden zu können. Dazu gehören unter anderem Angaben zu Netzwerkadressen, Webdienst-Endpunkten, öffentliche Zertifikaten sowie Angaben für LE-EU zur Identifizierung von Versicherten aus Deutschland im Ausland. Die Systemadministratoren sollen mithilfe des NCPeH-FD die Service Metadata auf dem zentralen Configuration Service der eHDSI hochzuladen bzw. sie dort zu verwalten. Dadurch werden die Service Metadata den NCPeH Land-B zum Download zur Verfügung gestellt. Anhand der Service Metadata können NCPeH Land-B die Dienste des NCPeH-FD lokalisieren, den Aufbau von sicheren TLS-Verbindungen zum NCPeH-FD initiieren sowie IHE-Anfragen an die angebotenen Schnittstellen senden.

Hinweis: Die Definition und Festlegung der Technologie zur Umsetzung der Administrationsschnittstelle liegt in Hoheit des Anbieters des NCPeH-FD (siehe Kapitel [1.4 Abgrenzungen] und [2 Systemüberblick]).

5.3.3 NCPeH.UC_7 - MTC vom eHDSI Terminology Service herunterladen

Das BfArM ist in seiner Rolle als Terminologie-Verantwortlicher für die Pflege und korrekte Zuordnung von Codes, Codierungssystemen und Terminologien im MTC verantwortlich (siehe Kapitel [3.2 Akteure]). Sobald das BfArM eine neue Version des MTC für die Nutzung in Deutschland auf dem eHDSI Terminology Service freigegeben hat, MUSS der NCPeH-FD die Version des MTC herunterladen und lokal in der VAU aktivieren. Das Herunterladen und die Aktivierung des MTC kann vom Systemadministrator über eine automatische Aktualisierung und zusätzlich über eine manuelle Aktualisierung beim NCPeH-FD ausgelöst werden.

5.3.4 NCPeH.UC_8 - Konfigurationsparameter verwalten

In diesem Anwendungsfall verwalten die berechtigten Systemadministratoren über eine Administrationsschnittstelle in einem 4-Augen-Prinzip die Konfigurationsparameter des NCPeH-FD, die im [4.1.1 Konfigurationsparameter] definiert sind.

Hinweis: Die Definition und Festlegung der Technologie zur Umsetzung der Administrationsschnittstelle liegt in Hoheit des Anbieters des NCPeH-FD (siehe Kapitel [1.4 Abgrenzungen] und [2 Systemüberblick]).

6 Funktionsmerkmale

6.1 eHDSI

6.1.1 Operation Cross_Gateway_Patient_Discovery::RespondingGateway_PRPA_IN201305UV02

Die Schnittstelle Cross Gateway Patient Discovery stellt bei berechtigten Anfragen über die Operation RespondingGateway_PRPA_IN201305UV02 demographische Versichertendaten bereit. Sie wird vom NCPeH-FD gemäß [eHDSI_XCPD_Profile] implementiert und NCPeH anderer europäischer Mitgliedstaaten (Land-B) zur Nutzung angeboten. Der Operationsname ist gemäß [ITI-55#3.55.6.1] definiert.

Hinweis: Der NCPeH-FD nimmt hier die Rolle als XCPD-"Responding Gateway" ein, während der NCPeH Land-B die Rolle als XCPD-"Initiating Gateway" innehat.

6.1.1.1 TUC_NCPeH_001: Patient Demographics Query Request für PS-A verarbeiten

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.1 Konfigurationsparameter]
• [4.1.3 eHDSI Basisleistungen]
• [4.1.5 Validierung der Identity Assertion des LE-EU]
• [4.1.7.2 Non-Repudiation of Receipt erstellen] 
• [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen] 
• A_28083*, A_28085* und A_28086*
• [4.1.9 Format und Validierung der KVNR] 
• [4.2.1 Schnittstellen zu Diensten der zentralen TI] 
• [4.2.7.3 Lokalisierung der Akte eines Versicherten]
• [4.2.7 Login in ein ePA-Aktenkonto]
• [4.2.9 Elektronische Identitäten des NCPeH-FD]

Ablauf des TUC

Nach Eingang der Anfrage MUSS der NCPeH-FD einen Non-Repudiation of Receipt Eintrag gemäß [4.1.7.2 Non-Repudiation of Receipt erstellen] und einen Audit Trail Eintrag gemäß [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen] in der Komponente Audit Repository speichern. Bei der Erstellung des Audit Trail Eintrages MUSS der NCPeH-FD die Vorgaben aus [eHDSI_XCPD_Profile#3.3] umsetzen. Wenn zum Zeitpunkt der Erstellung des Audit Trail Eintrags nicht alle erforderlichen Daten im NCPeH-FD verfügbar sind, MÜSSEN die Daten in den Audit Trail Eintrag aufgenommen werden, sobald sie im NCPeH-FD verfügbar sind, spätestens aber nachdem die Antwort an NCPeH Land-B gesendet wurde.

Die eingehende Anfrage MUSS dem Nachrichtentyp Patient Registry Find Candidates Query entsprechen, wie er in [eHDSI_XCPD_Profile#2.1] beschrieben ist. 

Das Element QueryByParameter.responsePriorityCode aus der Anfrage MUSS den Wert "I" (Immediate) haben. Nur das Verarbeiten und Senden einer sofortigen Antwort ist zulässig. Falls das Element 
QueryByParameter.responsePriorityCode einen anderen Wert als "I" enthält, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit der Fehlernachricht gemäß Vorgaben aus [ITI-55#3.55.4.1.3] antworten.

Der NCPeH-FD MUSS überprüfen, ob aus der XCPD-Anfrage die zwei livingSubjectID-Elemente die Prüfkriterien aus der Tabelle TAB_NCPeH_XCPD_Prüfkriterien_PS-A erfüllen.

Tabelle 42: TAB_NCPeH_XCPD_Prüfkriterien_PS-A

Die Variablen OID_KVNR_ASSIGNING_AUTHORITY und OID_AC_ePKA_ASSIGNING_AUTHORITY sind in A_28016* bzw. A_28017* definiert.

Die KVNR und der Zugriffscode werden bei der Kommunikation mit dem ePA-Aktensystem verwendet, um das zugehörige ePA-Konto des Versicherten eindeutig ermitteln zu können. Durch die Übermittlung des Zugriffscodes an das jeweilige ePA-Aktensystem des Versicherten wird dort geprüft, ob das europäische Mitgliedsland vom Versicherten ermächtigt ist, durch NCPeH-FD die ePKA-Daten des Versicherten abzurufen.

Der NCPeH-FD MUSS folgende Prüfschritte durchführen und bei Abweichung mit entsprechender Fehlermeldung (siehe Spalte Reason Encoding und acknowledgementDetail) an den NCPeH Land-B antworten und die weitere Verarbeitung der Anfrage abbrechen:

Tabelle 43: TAB_NCPeH_XCPD_Prüfschritte_Fehlermeldungen_PS-A

Hinweis: Die Variablen ida_healthcare_facility_type_code, ida_name-id, ida_practitioner_role_code und ida_point_of_care sind in A_28026* definiert.

Das folgende Beispiel eines Patient Demographics Query Request stellt das IHE XCPD-Profil des Interaktionstyps HL7 PRPA_IN201305UV02 dar. Die Nachricht enthält die Versichertenkennung (KVNR), mit der die zugehörigen demographischen Versichertendaten eindeutig ermittelt werden können, sowie den Zugriffscode, der in den nachgelagerten eHDSI-Anfragen zum Abruf von ePKA-Daten zu verwenden ist. Aus Gründen der Übersichtlichkeit enthält die Nachricht in dem soapenv:Header-Element keine Angaben zum Sicherheitsobjekt (Assertion), hierfür siehe Kapitel [4.1.5 Validierung der Identity Assertion des LE-EU].

Ausgabeparameter des TUC

Nach erfolgreicher Durchführung dieses TUC stehen folgende Ausgabeparameter zur Verfügung und können im entsprechenden Anwendungsfall verwendet werden:

• xcpd_kvnr,
• xcpd_accesscode_epka.

6.1.1.2 TUC_NCPeH_002: Patient Demographics Response für PS-A versenden

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.3 eHDSI Basisleistungen],
• [4.1.7.1 Non-Repudiation of Origin erstellen],
• [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen].

Ablauf des TUC

Der Inhalt und die Struktur der XCPD-Rückmeldung basiert auf der HL7 Patient Registry Find Candidates Query Response gemäß Vorgaben aus [eHDSI_XCPD_Profile#2.3].

Darüber hinaus MÜSSEN folgende Einschränkungen vom NCPeH-FD geprüft werden.

• Die XCPD-Rückmeldung MUSS ein Element /PRPA_IN201306UV02/controlActProcess/subject/registrationEvent/subject1/patient enthalten. 
• patient/id@extension MUSS den Wert nach folgender Vorschrift enthalten:

1. Der Wert des Parameters patient_kvnr (siehe Kapitel [6.2.3 TUC_NCPeH_017: Demographische Versichertendaten aus NFD des ePKA MIO übernehmen])
2. Der senkrechte Strich ohne Anführungszeichen: "|"
3. Der Wert des Zugangscodes aus der XCPD-Anfrage, zwischengespeichert in der Variable xcpd_accesscode_epka (siehe Kapitel [6.1.1.1 TUC_NCPeH_001: Patient Demographics Query Request für PS-A verarbeiten])
   
   Beispiel für den gesamten Wert im Attribut patient/id@extension:  B123456789|A2C4E6

• patient/id@root MUSS den Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY aus A_28016* enthalten

• Der NCPeH-FD MUSS die ermittelten demographischen Versichertendaten aus [6.2.3 TUC_NCPeH_017: Demographische Versichertendaten aus NFD des ePKA MIO übernehmen] den untergeordneten Elementen des patientPerson-Elements entsprechend folgenden Regelungen zuordnen:
  
  

  Element	Verwendungskonvention
  name/given	patient_vorname
  name/family	Der Wert des Element MUSS aus ermittelten Werten in folgender Reihenfolge bestehen, die Werte sind durch ein Leerzeichen getrennt: patient_prefix patient_namenszusatz patient_vorsatzwort patient_nachname
  birthTime	patient_geburtsdatum Die Vorgaben zum Datumsformat MÜSSEN gemäß [IHE_XCPD] umgesetzt werden.

Die Variablen patient_kvnr, patient_vorname, patient_prefix, patient_namenszusatz, patient_vorsatzwort, 
patient_nachname und patient_geburtsdatum sind im [6.2.3 TUC_NCPeH_017: Demographische Versichertendaten aus NFD des ePKA MIO übernehmen] definiert.

Der NCPeH-FD MUSS einen Non-Repudiation of Origin Eintrag gemäß [4.1.7.1 Non-Repudiation of Origin erstellen] in der Komponente Audit Repository speichern.

Das folgende Beispiel einer Patient Demographics Response stellt das IHE XCPD-Profil des Interaktionstyps HL7 PRPA_IN201306UV02 dar. Die Nachricht enthält neben der KVNR des Versicherten auch die ermittelten demographischen Versichertendaten:

Ausgabeparameter des TUC

Dieser TUC hat keine Ausgabeparameter.

6.1.1.3 TUC_NCPeH_023: Patient Demographics Query Request für ePeD-A verarbeiten

Beispiel

Typischerweise werden die KVNR (xcpd_kvnr) und der Zugriffscode (xcpd_accesscode_erp) vom NCPeH-FD beim Zugriff auf E-Rezepte an den E-Rezept-FD übermittelt. Mit der KVNR kann der E-Rezept-FD die demographischen Versichertendaten und die einlösbaren E-Rezepte des Versicherten eindeutig ermitteln. Der Zugriffscode ist Teil der vom Versicherten erteilten Zugriffsberechtigung und wird im E-Rezept-FD gespeichert. Mit der Übermittlung des Zugriffscodes wird dieser dort vom E-Rezept-FD auf Gültigkeit geprüft, bevor der Zugriff auf angefragte E-Rezepte gestattet wird.

Das folgende Beispiel eines gültigen Patient Demographics Query Requests stellt das IHE XCPD-Profil des Interaktionstyps HL7 PRPA_IN201305UV02 dar. Die Nachricht enthält eine Krankenversichertennummer (KVNR) sowie einen Zugriffscode.

6.1.1.4 TUC_NCPeH_024: Patient Demographics Response mit demographischen Versichertendaten für ePeD-A versenden

Beispiel

Beispiel einer Patient-ID im Pfad /PRPA_IN201306UV02/controlActProcess/subject/registrationEvent/subject1/patient/id/@extension: B123456789|A2C4E6

Beispiel

Das folgende Beispiel einer Patient Demographics Response stellt das IHE XCPD-Profil des Interaktionstyps HL7 PRPA_IN201306UV02 dar. Die Nachricht enthält neben der KVNR des Versicherten auch die ermittelten demographischen Versichertendaten:

6.1.2 Operation Cross_Gateway_Query::FindDocuments

Die Schnittstelle Cross Gateway Query stellt die Operation FindDocuments zur Verfügung. Diese Operation wird aufgerufen, wenn der NCPeH Land-B ein Ereignis vom behandelnden LE-EU empfängt und die Anfrage an die Operation sendet. Der NCPeH-FD implementiert die Operation gemäß der Vorgaben aus [eHDSI_XCA_Profile] und stellt sie dem NCPeH Land-B zur Nutzung in der eHDSI bereit. Der NCPeH-FD verwendet die Anfrage, um semantische Bezeichnungen oder Identifikatoren über die verfügbaren Gesundheitsdatensätze (z.B. ePKA MIO, E-Rezepte) des Versicherten aus dem zum jeweiligen Anwendungsszenario passenden Fachdienst der TI zu ermitteln und sie dem NCPeH Land-B mit der Antwortnachricht zu senden.

Hinweis: Der NCPeH-FD nimmt hier die Rolle als "Responding Gateway" ein, während der NCPeH Land-B die Rolle als "Initiating Gateway" innehat.

Die eHDSI klassifiziert die Anwendungsszenarien bzw. Dokumentenklassen auf der Grundlage von so genannten semantischen Signifiers. Ein semantischer eHDSI-Signifier ist eine Zeichenkette, die aus folgenden Elementen konkateniert wird:

1. "('"
2. Ein LOINC-Code
3. "^^"
4. "2.16.840.1.113883.6.1"
5. "')"

Der Wert 2.16.840.1.113883.6.1 ist dabei die OID des Klassifikationsschemas des Signifiers.

6.1.2.1 TUC_NCPeH_003: Cross Gateway Query Request für PS-A verarbeiten

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.2 Datenaustausch mit zugelassenen EU-Ländern],
• [4.1.3 eHDSI Basisleistungen],
• [4.1.5 Validierung der Identity Assertion des LE-EU],
• [4.1.6 Validierung der TRC Assertion],
• [4.1.7.2 Non-Repudiation of Receipt erstellen],
• [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen],
• A_28083*, A_28085* und A_28086*,
• [4.1.9 Format und Validierung der KVNR].

Ablauf des TUC

Der NCPeH-FD MUSS die Umsetzung der Operation Cross_Gateway_Query::FindDocuments gemäß den Vorgaben, Einschränkungen und der definierten Ablauflogik in [eHDSI_XCA_Profile] implementieren.

Nach Eingang der Anfrage MUSS der NCPeH-FD einen Non-Repudiation of Receipt Eintrag gemäß [4.1.7.2 Non-Repudiation of Receipt erstellen] und einen Audit Trail Eintrag gemäß [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen] in der Komponente Audit Repository speichern. Bei der Erstellung des Audit Trail Eintrages müssen Vorgaben aus [eHDSI_XCA_Profile#4.3] umgesetzt werden. Wenn zum Zeitpunkt der Erstellung des Audit Trail Eintrags nicht alle erforderlichen Daten im NCPeH-FD verfügbar sind, MÜSSEN die Daten in den Audit Trail Eintrag aufgenommen werden, sobald sie im NCPeH-FD verfügbar sind, spätestens nach dem Versand der Antwort an NCPeH Land-B.

Der NCPeH-FD MUSS Inhalte des Parameters XDSDocumentEntryPatientId aus der Anfrage auf folgende Kriterien prüfen:

• Der Wert des Parameters XDSDocumentEntryPatientId muss inhaltlich nach der folgenden Vorschrift strukturiert sein:

1. "'",
2. Der unveränderbare Teil der KVNR des Versicherten (10 Stellen),
   Der Wert MUSS gemäß Vorgaben aus [4.1.9 Format und Validierung der KVNR] geprüft und valide sein.
3. Der senkrechte Strich ohne Anführungszeichen: "|",
4. 6-stelliger Zugriffscode,
5. "^^^&amp;",
6. Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY aus A_28016*,
7. "&amp;ISO'".
   
   Beispiel des Wertes: 'B123456789|A2C4E6^^^&amp;1.2.276.0.76.3.1.580.147&amp;ISO'

• Der Wert des Parameters muss mit Hochkomma beginnen und enden,
• Die in dem Parameter enthaltene Versichertenkennung muss identisch mit dem Wert der Variable trc_kvnr (siehe A_27926*) sein,
• Der in dem Parameter enthaltene Zugriffscode muss identisch mit dem Wert der Variable trc_accesscode (siehe A_27926*) sein,
• Die im Parameter enthaltene OID muss identisch mit dem Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY gemäß A_28016* sein.

Falls es bei der Prüfung der oben angegebenen Kriterien zu Fehlern bzw. Abweichungen kommt, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit einer Fehlernachricht antworten. Neben Vorgaben zur Fehlerbehandlung aus [eHDSI_XCA_Profile#2.2.3] und [eHDSI_NCPeH_Components#6.4] MUSS der NCPeH-FD beim Auftreten von Fehlerbedingungen folgende Zuordnung von Fehlernachrichten umsetzen:

Tabelle 45: TAB_NCPeH_XCA_QUERY_Fehlerbedingungen_Fehlercodes_PS-A