Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation NCPeH-Fachdienst

    

     

      
Version
      
2.0.1
     
     

      
Revision
      
1175014
     
     

      
Stand
      
25.03.2025
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
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-Mitgliedsstaaten 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) inklusive der Dispensationsmeldung (eDispensation).

Der Austausch medizinischer Daten und die damit einhergehende Bereitstellung von elektronischen Dienstleistungen soll durch die von den beteiligten EU-Mitgliedsstaaten 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ährleistungen.

1.4 Abgrenzungen

Die vom NCPeH-FD bereitgestellten (angebotenen) Schnittstellen, über die die grenzüberschreitende Datenübertragung mit NCPeHs anderer europäischen Mitgliedsstaaten erfolgt, sind durch die eHDSI spezifiziert und haben normativen Charakter. In diesem Dokument wird auf die eHDSI-Spezifikationen referenziert (siehe auch [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 [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 Management-Schnittstellen 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-Mitgliedsstaaten 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 Standardblauf besteht aus Aktivitätsschritten, die auf "Technische Use Cases" (TUC) verweisen. Die TUCs sind im [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 Versicherten, ihre Gesundheitsdaten in andere europäische Mitgliedsstaaten mitzunehmen und sie dort mit behandelnden 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 Mitgliedsstaates 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-Mitgliedsstaates 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 des 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 Mitgliedsstaaten vereinbarten Kodierungssysteme.

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

Abbildung 1 stellt die Architektur für den NCPeH-FD Anwendungsszenario Patient Summary 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 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-Rezepte) in einer Apotheke ihrer Wahl im europäischen Ausland einzulösen. Für dieses Anwendungsszenario stehen den Versicherten die EU-Mitgliedsstaaten 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 Mitgliedsstaat 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 Mitgliedsstaat.

Verwaltung von Zugriffsberechtigungen für E-Rezepte

Vor dem Abruf oder Einlösen von E-Rezepten in anderen EU-Mitgliedsstaaten (Land-B) erteilt eine versicherte Person über seine 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 sein E-Rezept-FdV die Entscheidung, aus welchem anderen europäischen Mitgliedsstaat die Apotheker bzw. Leistungserbringer (LE-EU) auf seine 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. Zugriffcode ist zeitlich auf eine Stunde begrenzt. Mit der Erstellung jeder Zugriffsberechtigung werden Informationen zur KVNR der versicherten Person, zum Ländercode des berechtigten EU-Mitgliedsstaates (Land-B), Zugriffscode und Zeitpunkt der Erstellung der Berechtigung gespeichert. Die gespeicherten Informationen inkl. Zugriffscode werden der Person auf seinem 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 E-Rezept-spezifische Clientfunktionalität 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.

Den Authentisierungsprozess initiiert der NCPeH-FD 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 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-Mitgliedsstaates (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 sind in 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,
• 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 und tritt als Document Consumer für die ePA-AS und den E-Rezept-FD auf. 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 neuen 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 Mitgliedsstaaten ü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

Die Verwaltung der in der Tabelle TAB_NCPeH_KONFIGURATIONSPARAMETER aufgelisteten Konfigurationsparameter werden durch den Systemadministrator über eine Managementschnittstelle des NCPeH-FD verwaltet und wird im Anwendungsfall [5.3.4 NCPeH.UC_8 - Konfigurationsparameter verwalten] beschrieben.

Tabelle 2: TAB_NCPeH_Konfigurationsparameter

4.1.2 Datenaustausch mit zugelassenen EU-Ländern

Ein grenzüberschreitender Austausch von Gesundheitsdaten mit anderen europäischen Ländern kann erst dann erfolgen, wenn die dafür notwendigen technischen und organisatorischen Voraussetzungen geschaffen sind. Das jeweilige europäische Land, mit dem die Gesundheitsdaten ausgetauscht werden sollen, muss nachweisen, dass es die Vorgaben zur Interoperabilität, Sicherheit und Datenschutz der eHDSI- und EU durch das Land erfolgreich umgesetzt hat. Ferner bedarf das Land vor der eigentlichen Inbetriebnahme mit einem neuen Dienst, Anwendungsfall oder Feature die offizielle Zustimmung durch das eHealth Network (das höchste Entscheidungsgremium in der EU zur eHealth). Auch die Entscheidung, ob ein Austausch von Gesundheitsdaten mit einem bestimmten europäischen Land erfolgen soll, muss durch Deutschland getroffen werden. Daher ist es notwendig, dass der NCPeH-FD die Länderidentitäten verwaltet, mit denen ein grenzüberschreitender Datenaustausch zulässig ist.

Nach Erhalt einer Anfrage von einem NCPeH Land-B für einen grenzüberschreitenden Anwendungsfall gemäß [eHDSI_Audit_Trail_Profile#1.2.3] MUSS der NCPeH-FD einen Non-Repudiation of Receipt Eintrag gemäß [4.1.7.2 Non-Repudiation of Receipt erstellen] in der Komponente Audit Repository speichern. Im weiteren Verlauf der Verarbeitung der Anfrage MUSS der NCPeH-FD gemäß [eHDSI_Audit_Trail_Profile#1.2.3] einen Audit Trail Eintrag gemäß [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen] in der Komponente Audit Repository speichern.

Der NCPeH-FD MUSS vor der weiteren Verarbeitung der Anfrage prüfen, ob die Identität des Land-B, von dem die Anfrage stammt, auf der WHITELIST_NCPeH_COUNTRY-B (siehe [4.1.1 Konfigurationsparameter]) enthalten ist. Dabei MUSS der NCPeH-FD die Identität des Land-B vom gültigen TLS-Zertifikat des NCPeH Land-B aus dem Element Subject: C (Country) verwenden. Falls der Ländercode nicht auf der Liste WHITELIST_NCPeH_COUNTRY-B enthalten ist, MUSS der NCPeH-FD eine Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit dem Fehlercode ERROR_GENERIC gemäß [eHDSI_NCPeH_Components#6.4] antworten.

Falls Die Prüfung im Zusammenhang mit der Nutzung der Schnittstelle [6.1.1 Operation Cross_Gateway_Patient_Discovery::RespondingGateway_PRPA_IN201305UV02] erfolgt, dann MUSS der NCPeH-FD mit der Fehlermeldung gemäß folgender Tabelle an den NCPeH Land-B antworten:

Tabelle 3: TAB_NCPeH_XCPD_Fehlermeldung_nicht_zugelassenes_EU-Land

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. 

4.1.3 eHDSI Basisleistungen

Die Schnittstellen des NCPeH-FD sind durch IHE XCPD Profile bzw. IHE XCA 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 NCPeHs (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 Sicherheitstokens 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. Der Aufbau des gegenseitigen Vertrauens zwischen NCPeH-FD und anderen NCPeHs und zentralen eHDSI-Diensten MUSS gemäß Vorgaben aus [eHDSI_Messaging_Profile#3] und [eHDSI_NCPeH_Configuration_Production_Environment] zur Einrichtung und Anwendung von TESTA-ng und TLS erfolgen.

Der NCPeH-FD MUSS beim Aufbau von TLS-Verbindungen innerhalb der eHDSI Vorgaben aus [eHDSI_Messaging_Profile#1.2] umsetzen. Dabei MUSS der NCPeH-FD TLS-Version 1.2 und TLS-Version 1.3 unterstützen. Er DARF NUR empfohlene Cipher Suiten gemäß Vorgaben aus [SOGIS-IS-2020#6.1] akzeptieren.

Der NCPeH-FD MUSS das beim TLS-Handshake empfangene TLS-Zertifikat des NCPeH Land-B nach Vorgaben aus [4.1.3.6 Validierung von Zertifikaten in eHDSI] prüfen und erst bei erfolgreicher Zertifikatsprüfung eine sichere TLS-Verbindung zum NCPeH Land-B aufbauen. 

Falls bei der Überprüfung des TLS-Zertifikats die Gültigkeit erfolgreich bestätigt werden konnte, MUSS der NCPeH-FD aus dem Element Subject: C (Country) den Ländercode des Landes entnehmen, in die Variable tls_country zwischenspeichern und in den Kontext der weiteren Verarbeitung der jeweiligen eHDSI-Anfrage bringen.

Tritt bei der Prüfung des TLS-Zertifikats ein Fehler auf, MUSS der NCPeH-FD den Aufbau der TLS-Verbindung zum NCPeH Land-B abbrechen. 

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. Daher MUSS der NCPeH-FD die Aktualität seiner Systemzeit gemäß Vorgaben aus [eHDSI_Messaging_Profile#4] abfragen und konsistent halten (Synchronisation).

4.1.3.3 eHDSI Identifier

Die eHDSI definiert konkrete URNs, OIDs und Coding Schema gemäß [eHDSI_NCPeH_Components#6.2], die im NCPeH-FD zu verwenden sind.

4.1.3.4 Allgemeine Fehlerbehandlung

Der NCPeH-FD MUSS die Behandlung von Fehler in der Kommunikation, Nachrichten- und Dokumentenkodierung und Nachrichtenverarbeitung gemäß Vorgaben aus [eHDSI_Messaging_Profile#6] umsetzen.

In Abhängigkeit von der jeweiligen Situation wird bei Fehlerfällen auf konkrete Fehlernachrichten bzw. -codes in den einzelnen technischen Use Cases (TUC) im [6 Funktionsmerkmale] näher eingegangen.

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_Certificate_Profile#3.1]). Der NCPeH-FD benötigt das TLS-Zertifikatsprofil für Land-A Szenarien und für Land-B Szenarien sowohl das Seal- als auch TLS-Zertifikatsprofil, um sichere Verbindungen zu anderen NCPeHs oder zentralen Diensten der eHDSI herzustellen. Der Herausgeber (CA) der beiden Zertifikatstypen ist GlobalSign.

Der Prozess zur Antragstellung für TLS-Zertifikate der eHDSI ist in [eHDSI_Certificates_Procedure_Request#II- TLS Certificates] und zur Verlängerung bzw. Erneuerung von Zertifikaten ist in [eHDSI_Certificates_Procedure_Request#IV- Certificates Renewal] beschrieben. Die Beschreibung der Sperrung von Zertifikaten der eHDSI ist in [eHDSI_Certificates_Procedure_Request#III- Certificates Revocation] enthalten.

Der NCPeH-FD MUSS sein privates TLS-Schlüsselmaterial im HSM erzeugen und dort zur Signaturerstellung anwenden. Der NCPeH-FD MUSS die öffentlichen Zertifikate des Herausgebers (Root und Intermediate) gemäß [eHDSI_Certificates_Procedure_Request] in seinem lokalen Truststore in der VAU hinterlegen, die bei der Prüfung von Zertifikatsketten als Vertrauensanker zu betrachten sind. Ferner MUSS der NCPeH-FD die öffentlichen Zertifikate des eHDSI Configuration und Terminology Service in seinem lokalen Truststore in der VAU speichern. Die Aufnahme der öffentlichen Zertifikate in dem lokalen Truststore erfolgt gemäß Anwendungsfall [5.3.4 NCPeH.UC_8 - Konfigurationsparameter verwalten].

Der Systemadministrator muss sicherstellen, dass an den NCPeH-FD über eine Management-Schnittstelle nur gültige, nicht abgelaufene oder nicht gesperrte Zertifikate des CA oder der zentralen Dienste der eHDSI zur Installation im lokalen Truststore übergeben werden. Bei der Installation der Zertifikate MUSS der NCPeH-FD alte Zertifikate der CA und der zentralen eHDSI-Dienste aus dem lokalen Truststore entfernen. Bei der Befüllung des Truststore MUSS der NCPeH-FD alle Service Metadata der berechtigten NCPeH Land-B (gemäß Einträgen im Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B aus [4.1.1 Konfigurationsparameter]) vom Configuration Service der eHDSI herunterladen, in den lokalen Truststore aufnehmen und alte Zertifikate der NCPeH Land-B aus dem Truststore entfernen (siehe [4.1.4 Service Metadata des NCPeH Land-B abrufen]). 

Das Vertrauen zum NCPeH Land-B wird durch die eHDSI-PKI sichergestellt, da die gegenseitige Authentifizierung der beiden Kommunikationsteilnehmer beim Aufbau der TLS-Verbindung unter Nutzung der TLS-Zertifikate erfolgt, deren Zertifikatsherausgeber (CA) der gemeinsame Vertrauensanker ist. Bei Erstellung von SAML-Assertions (Identity und TRC Assertion) durch NCPeH Land-B, deren Signatur mit einem Seal-Zertifikat der eHDSI erstellt wurde, kann durch die Prüfung im NCPeH-FD auf gemeinsamen Zertifikatsherausgeber (CA) das Vertrauen zu dem Seal-Zertifikat herstellen. 

Wird für die Signatur der SAML-Assertions im Land-B ein Seal-Zertifikat einer anderen PKI verwendet, muss der NCPeH Land-B eine SMP-Datei inkl. des öffentlichen Seal-Zertifikats einrichten und sie auf dem zentralen eHDSI Configuration Service mit anderen NCPeHs teilen. Damit der NCPeH-FD das Seal-Zertifikat prüfen kann, MUSS im NCPeH-FD das öffentliche Zertifikat des Herausgebers, welches das Seal-Zertifikat ausgestellt hat, in den lokalen Truststore aufgenommen werden (siehe [4.1.1 Konfigurationsparameter]). Der NCPeH-FD MUSS die Prüfung des Seal-Zertifikats gemäß [4.1.3.6 Validierung von Zertifikaten in eHDSI] durchführen. Dadurch kann der NCPeH-FD dem öffentlichen Seal-Zertifikat vertrauen und die Integrität und Authentizität der SAML-Assertion des NCPeH Land-B validieren.

4.1.3.6 Validierung von Zertifikaten in eHDSI

Der NCPeH-FD MUSS das zu prüfende Zertifikat des NCPeH Land-B (SEAL- oder TLS-Zertifikat) gemäß Vorgaben aus [eHDSI_X509_Certificate_Profile#2.4] und nach folgenden Schritten überprüfen:

1. Gültigkeitsprüfung des zu prüfenden Zertifikats:
   Prüfung des Zertifikats auf seine aktuelle zeitliche Gültigkeit, damit ist der Zeitraum gemeint, der im Feld validity steht. Dabei kommt folgender Algorithmus zu tragen: notBefore =< Referenzzeitpunkt && notAfter >= Referenzzeitpunkt entspricht einem zeitlich gültigen Zertifikat. Der Referenzzeitpunkt ist die aktuelle Systemzeit des NCPeH-FD.
   
2. Prüfung der Extension KeyUsage auf Vorhandensein:
   Zudem muss die KeyUsage auf die richtige Belegung entsprechend der vorgesehenen KeyUsage gemäß [eHDSI_X509_Certificate_Profile#3.1] geprüft werden.
3. Ermittlung des passenden öffentlichen CA-Zertifikats aus dem lokalen Truststore:
   Issuer DName des Zertifikats muss identisch mit dem Subject DName des CA-Zertifikats sein und AuthorityKeyIdentifier des Zertifikats mit SubjectKeyIdentifier des CA-Zertifikats
4. Mathematische Prüfung der Signatur des Zertifikats mit Hilfe des ermittelten CA-Zertifikats:
   Die Signatur und der verwendete Algorithmus werden aus dem Zertifikat ausgelesen. Verifikation der Signatur und Hashwert-Vergleich (siehe Verfahren in [RFC5280#6.1]).
   
5. Status- und Sperrprüfung mittels CRL-Prüfung oder OCSP-Abfrage:
   Hinweis: Der Downloadpunkt für Status- und Sperrprüfung ist gemäß [eHDSI_X509_Certificate_Profile#3.1] entweder im Element CRL Distribution Points oder im Element Authority Info Access des TLS-Zertifikats enthalten.
6. 1. CRL-Prüfung - Validierung einer CRL und Ermittlung der Sperrinformation zum Zertifikat:
      Vor dem Download der CRL-Datei muss geprüft werden, ob unter Berücksichtigung der Dauer des Konfigurationsparameters CRL_CACHE_REFRESH_PERIOD ([4.1.1 Konfigurationsparameter]) gültige Sperrliste im NCPeH-FD vorliegt (z. B. im lokalen Cache). Ein Zwang, CRL-Daten zu cachen, existiert nicht.
      Falls die CRL-Daten nicht im lokalen Cache vorhanden sind, kann eine CRL gemäß [eHDSI_X509_Certificate_Profile#3.1] (siehe Element CRL Distribution Points) heruntergeladen werden, unter Einhaltung der maximalen zeitlichen Dauer des Herunterladens der CRL (siehe Konfigurationsparameter CRL_DOWNLOAD_TIMEOUT gemäß [4.1.1 Konfigurationsparameter]). Die zeitliche Gültigkeit der heruntergeladenen CRL (Systemzeit < crl.NextUpdate) (siehe [RFC5280#5.1.2.5]) wird geprüft. Es wird anhand der IssuingDistributionPoint-Erweiterung in der Sperrliste (CRL) geprüft, ob es sich um eine indirekte CRL (indirectCRL-bit) handelt (siehe [RFC5280#5.2.5] und [X.509#7.12]). Prüfung der Signatur der CRL erfolgt gemäß [RFC5280#6.3.3]. Die Auswertung der CRL-Einträge erfolgt mit der Suche nach der Zertifikatsseriennummer des zu überprüfenden Zertifikats in der CRL (siehe [RFC5280#6.3.3]). Bei der Verarbeitung der CRL sind Vorgaben aus [eHDSI_X509_Certificate_Profile#3.2] zu berücksichtigen. Falls bei der Suche ein oder mehrere Einträge gefunden wurden, wird die CRL-Entry-Erweiterung „CertificateIssuer“ ausgelesen und deren Inhalt mit dem Issuer DName des Zertifikats verglichen. Nur wenn der Inhalt der CertificateIssuer-Erweiterung mit diesem DName übereinstimmt, ist das Zertifikat gesperrt, siehe [RFC5280#6.3.3].
      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.
      
      
   2. OCSP-Abfrage - Ermittlung der Statusinformation zum Zertifikat durch Abfrage des zugeordneten OCSP-Dienstes:
      Vor der OCSP-Abfrage muss geprüft werden, ob unter Berücksichtigung der Dauer des Konfigurationsparameters OCSP_CACHE_REFRESH_PERIOD (siehe [4.1.1 Konfigurationsparameter]) gültige Statusinformationen zum prüfenden Zertifikat bereits vorliegen (z. B. im lokalen Cache). Ein Zwang, OCSP-Responses zu cachen, existiert nicht.
      Ansonsten wird die OCSP-Abfrage für das zu prüfende Zertifikat mit dem Parameter ENFORCE_CERTHASH_CHECK=true gesendet, unter Beachtung des Konfigurationsparameters OCSP_RESPONSE_TIMEOUT (siehe [4.1.1 Konfigurationsparameter]) bei Nicht-Erreichbarkeit oder ohne Antwort vom OCSP-Responder. Die OCSP-Response muss gemäß [RFC6960#4.2] verarbeitet werden. Wenn der zuständige OCSP-Responder die Statusinformation des Zertifikats mit einem Wert „revoked“ oder „unknown“ zurückgibt oder eine erforderliche certHash-Erweiterung fehlt bzw. falsch ist, DARF das Zertifikat NICHT als gültig bewertet werden.

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, muss der NCPeH-FD über die gültigen Service Metadata der NCPeH Land-B verfügen.

Die auf dem eHDSI Configuration Service verfügbaren Service Metadata der NCPeH Land-B befinden sich in einem öffentlichen Verzeichnis, aus dem alle NCPeHs die Service Metadata abrufen können. Der NCPeH-FD MUSS täglich die Service Metadata der NCPeH Land-B (siehe Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B [4.1.1 Konfigurationsparameter]

) mittels des SMP/SML-Protokolls gemäß Vorgaben aus [eHDSI_Service_Location_and_Capability_Lookup_Profile#3] und [BDX-smp-v1.0] vom eHDSI Configuration Service abrufen. Beim Abruf von länderspezifischen Service Metadata MUSS der NCPeH-FD das Element ServiceGroup/ParticipantIdentifier nach folgender Struktur befüllen und in der Anfrage an den eHDSI Configuration Service senden: 
"urn:ehealth:" + Ländercode + ":ncp-idp". Der Ländercode des Land-B muss dem Format gemäß ISO 3166-1 Alpha 2 entsprechen.

Der NCPeH-FD MUSS im Erfolgsfall das in der Rückmeldung enthaltene XML-Dokument (SignedServiceMetadata-Dokument) auf Schemavalidierung nach Vorgaben aus [BDX-smp-v1.0] prüfen. Falls das Dokument schemakonform ist, MUSS der NCPeH-FD die vom eHDSI Configuration Service erstellte Dokumentensignatur aus dem Element SignedServiceMetadata/Signature auf Gültigkeit gemäß Vorgaben aus [BDX-smp-v1.0#3.6.2] prüfen. Bei dem Zertifikat aus dem Element ds:X509Data MUSS es sich um das öffentliche Zertifikat des eHDSI Configuration Service handeln und das Zertifikat MUSS bereits im lokalen Truststore des NCPeH-FD vorhanden sein. Dieses Zertifikat MUSS gemäß [4.1.3.6 Validierung von Zertifikaten in eHDSI] geprüft werden. 

Der NCPeH-FD DARF für die Events "IDP Provide HCP Authentication used for proprietary issuance" und "NCP Provide TRC Assertion" gemäß [eHDSI_Audit_Trail_Profile#2.3.5.7] NUR die Service Metadata zur weiteren Datenverarbeitung extrahieren, deren folgende Elemente die Prüfkriterien erfüllen:

Tabelle 4: TAB_NCPeH_Service_Metadata_IDP_Provider

Falls bereits für ein ausgewähltes ProcessIdentifier (siehe Tabelle TAB_NCPeH_Service_Metadata_IDP_Provider und unten Abschnitt "Speicherung von Referenzwerten") bezogen auf ein Land-B im Truststore ein Zertifikat vorhanden ist, MUSS der NCPeH-FD die SMP-Datei auf Aktualität prüfen, bevor mit Signatur- und Zertifikatsprüfung der SMP-Datei begonnen wird. Die Prüfung besteht aus einem Vergleich des bereits in der VAU gespeicherten Referenzwertes SignatureValue (siehe unten Abschnitt "Speicherung von Referenzwerten") mit dem Wert des Elementes ServiceMetadata/ServiceInformation/Extension/Signature/SignatureValue aus der neu heruntergeladenen SMP-Datei. Falls die Werte identisch sind, kann davon ausgegangen werden, dass die SMP-Datei keine Änderungen enthält und das im Truststore vorhandene Zertifikat nicht aktualisiert oder entfernt werden muss. An dieser Stelle der NCPeH-FD SOLL die SMP-Datei nicht weiterverarbeiten.

Ansonsten, falls die Werte unterschiedlich sind, MUSS der NCPeH-FD mit der weiteren Verarbeitung der SMP-Datei fortsetzen. 

Jede ausgewählte ServiceMetadata-Datei enthält eine Signatur, die mit dem Schlüsselmaterial des NCPeH Land-B erstellt wurde. Die Gültigkeit der Signatur soll die Integrität der jeweiligen ServiceMetadata bestätigen. Der NCPeH-FD MUSS das Zertifikat aus dem Element ServiceMetadata/ServiceInformation/Extension/Signature extrahieren und die vollständige Zertifikatskette überprüfen, ob das Zertifikat von der vertrauenswürdigen CA der eHDSI ausgestellt wurde. Die Überprüfung des extrahierten Zertifikats MUSS gemäß [4.1.3.6 Validierung von Zertifikaten in eHDSI] durchgeführt werden. Der NCPeH-FD MUSS die Signatur aus dem Element ServiceMetadata/ServiceInformation/Extension/Signature nach Vorgaben aus [BDX-smp-v1.0#3.6.2] validieren.

Nach erfolgreicher Signatur- und Zertifikatsprüfung MUSS der NCPeH-FD das nächste Zertifikat aus dem folgenden Element der ServiceMetadata extrahieren, gemäß Vorgaben im [4.1.3.6 Validierung von Zertifikaten in eHDSI] prüfen und nach erfolgreicher Zertifikatsprüfung NUR dieses Zertifikat in den lokalen Truststore aufnehmen:

• ServiceMetadata/ServiceInformation/ProcessList/Process/ServiceEndpointList/Endpoint/Certificate
  (der Wert ist mit Base64 kodiert und muss evtl. vor Aufnahme in den Truststore dekodiert werden)

Speicherung von Referenzwerten

In diesem Zusammenhang MUSS der NCPeH-FD folgende Referenzwerte mit dem vorher extrahierten Zertifikat in Verbindung setzen und in der VAU speichern:

• Ländercode des NCPeH Land-B
• ServiceMetadata/ServiceInformation/ProcessList/Process/ProcessIdentifier
• ServiceMetadata/ServiceInformation/ProcessList/Process/ServiceEndpointList/Endpoint/ServiceActivationDate
• ServiceMetadata/ServiceInformation/ProcessList/Process/ServiceEndpointList/Endpoint/ServiceExpirationDate
• ServiceMetadata/ServiceInformation/Extension/Signature/SignatureValue
  

Der NCPeH-FD MUSS vor der Aufnahme des Zertifikats aus dem Element ServiceMetadata/ServiceInformation/ProcessList/Process/ServiceEndpointList/
Endpoint/Certificate in den lokalen Truststore sicherstellen, dass für das jeweilige Event "IDP Provide HCP Authentication used for proprietary issuance" bzw. "NCP Provide TRC Assertion" gemäß [eHDSI_Audit_Trail_Profile#2.3.5.7] in dem Zeitintervall aus der ServiceMetadata (ServiceActivationDate bis ServiceExpirationDate) kein anderes Zertifikat im lokalen Truststore enthalten ist.

Die Inhalte aus den extrahierten ServiceMetadata, deren Validierung der Signaturen und Zertifikate und Prüfung auf Schemakonformität mit einem Fehler enden, DÜRFEN NICHT in den lokalen Truststore bzw. in der VAU des NCPeH-FD aufgenommen oder für Zwecke der Datenverarbeitung im NCPeH-FD verwendet werden.

Der NCPeH-FD MUSS bei jedem Abruf der ServiceMetadata eines NCPeH Land-B vom zentralen eHDSI Configuration Service einen Audit Trail Eintrag gemäß [4.1.7.5 Security Audit Trail Eintrag erstellen] erstellen und im lokalen Audit Repository speichern.

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 Assertion obligatorischer Bestandteil jeder eHDSI-Anfrage. Jeder NCPeH Land-B, der die SAML Assertion 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 muss 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 werden. 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, muss vom Land-B dem NCPeH-FD über den eHDSI Configuration Service zum Herunterladen bereitgestellt werden (siehe [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 im [4.1.3.5 Umgang mit Zertifikaten der eHDSI] und [4.1.4 Service Metadata des NCPeH Land-B abrufen] 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.

Die eingehende SOAP-Anfrage muss im Security Header genau eine Identity Assertion für einen LE-EU enthalten. Falls die Anfrage eine zusätzliche Identity Assertion für Next of Kin oder für einen weiteren LE-EU enthält, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und die Anfrage mit dem Code Sender und Subcode Invalid Security Token gemäß Vorgaben aus [eHDSI_NCPeH_Components#4.4.2.4] zurückweisen.

Der NCPeH-FD MUSS folgende Elemente prüfen:

• Der Wert des Elements Assertion/AuthnStatement/AuthnInstant DARF NICHT in der Zukunft liegen. Eine tolerierbare Zeitabweichung DARF bis maximal eine Minute (60 Sekunden) betragen.
• Falls das Element Assertion/AuthnStatement/SessionNotOnOrAfter angegeben ist, DARF der Wert NICHT in der Vergangenheit liegen. Eine tolerierbare Zeitabweichung DARF bis maximal einer Minute (60 Sekunden) betragen.

Die IdA MUSS die Vorgaben aus [eHDSI_SAML_Profile#2] erfüllen. Der NCPeH-FD MUSS das Profil des öffentlichen Zertifikats aus dem Element Envelope/Header/Security/Assertion/Signature/KeyInfo der IdA gemäß Vorgaben aus [eHSDI_Certificates_Profile] prüfen. Die Validierung des öffentlichen Zertifikats MUSS gemäß Vorgaben aus [4.1.3.5 Umgang mit Zertifikaten der eHDSI] erfolgen.

Der NCPeH-FD MUSS die elektronische Signatur der IdA validieren, indem er den Security Header gemäß Vorgaben aus [OASIS_WS-Security#8.4] verarbeitet. Schlägt die Signaturvalidierung fehl, MUSS der NCPeH-FD die SMP-Datei des NCPeH Land-B gemäß [4.1.4 Service Metadata des NCPeH Land-B abrufen], erneut herunterladen und ggf. das entsprechende Seal-Zertifikat für Identity Assertions im Truststore aktualisieren. Nach erfolgreicher Aktualisierung des Seal-Zertifikats im lokalen Truststore MUSS der NCPeH-FD die elektronische Signatur der IdA gemäß [OASIS_WS-Security#8.4] validieren.

Schlägt die Validierung erneut fehl, so verhält sich die zugehörige Transaktion wie ein Authentifizierungsfehler. Der NCPeH-FD MUSS bei Fehlern, die bei der Verarbeitung und Validierung der IdA entstehen, mit einer entsprechenden Fehlermeldung gemäß [eHDSI_NCPeH_Components#4.4.2.4] auf die erhaltene SOAP-Anfrage antworten.

Der NCPeH-FD MUSS im Erfolgsfall (erfolgreiche Validierung der IdA) aus der IdA folgende Identitätsattribute des LE-EU einlesen und in die entsprechenden Variablen abspeichern, damit er die Identitätsattribute in den TUCs für Zwecke der Protokollierung und in Prüfschritten weiterverarbeiten kann:

Tabelle 5: TAB_NCPeH_Identitätsattribute_LE-EU 

Der NCPeH-FD MUSS die Werte der oben genannten Variablen eindeutig der Session mit dem Fachdienst der TI zuordnen, an die das konkrete Anwendungsszenario (z.B. PS-A), die Identität des Land-B innerhalb der TI, die Identität des LE-EU und die Identität des Versicherten gebunden sind. Durch die Zuordnung der Variablen zu der entsprechenden Session MÜSSEN Identitätsattribute anderer LE-EU in anderen Sessions des NCPeH-FD unberührt bleiben. 

Der NCPeH-FD DARF nur Anfragen annehmen und bearbeiten, in denen das Element urn:oasis:names:tc:xspa:1.0:subject:purposeofuse den Wert TREATMENT enthält. Enthält das Element einen anderen Wert oder erfüllt die IdA nicht die Syntaxvorgaben aus [eHDSI_SAML_Profile], MUSS der NCPeH-FD die weitere Bearbeitung der Anfragen abbrechen und die Anfragen mit dem Code Sender und Subcode Invalid Security Token gemäß den Vorgaben aus [eHDSI_NCPeH_Components#4.4.2.4] zurückweisen. Die fachlichen Fehler im Zusammenhang mit der IdA werden in Abhängigkeit vom jeweiligen Anwendungsfall in entsprechenden TUCs behandelt. Die übrigen Fehler MÜSSEN gemäß [eHDSI_NCPeH_Components#4.4.2.4] behandelt werden.

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-Assertion. Sie bescheinigt das Bestehen einer Behandlungsbeziehung zwischen einem Versicherten und einem LE-EU und liefert Informationen über den Kontext eines bestimmten Behandlungsszenarios. Die Datenstruktur, Empfehlungen und Einschränkungen zur Nutzung der TRC Assertion sind in [eHDSI_SAML_Profile#4] profiliert und beschrieben. In Security Header von XCPD-Anfragen ist nur eine IdA vorgesehen, eine TRC Assertion DARF dort NICHT enthalten sein. Erst nach erfolgreicher Identifizierung des Versicherten im EU-Ausland MUSS mit den nachfolgenden Anwendungsschritten des LE-EU im Security Header der Nachrichten neben der IdA auch eine TRC Assertion übermittelt werden.

Der NCPeH-FD MUSS das öffentliche Zertifikat aus dem Element Envelope/Header/Security/Assertion/Signature/KeyInfo der TRC Assertion gemäß Vorgaben aus [eHSDI_Certificates_Profile] verifizieren.

Der NCPeH-FD MUSS die elektronische Signatur der TRC Assertion validieren, indem er den Security Header gemäß Vorgaben aus [OASIS_WS-Security#8.4] verarbeitet. Schlägt die Signaturvalidierung fehl, MUSS der NCPeH-FD die SMP-Datei des NCPeH Land-B gemäß [4.1.4 Service Metadata des NCPeH Land-B abrufen] erneut herunterladen und ggf. das entsprechende Seal-Zertifikat für TRC Assertion im Truststore aktualisieren. Nach erfolgreicher Aktualisierung des Seal-Zertifikats im lokalen Truststore MUSS der NCPeH-FD die elektronische Signatur der TRC Assertion gemäß [OASIS_WS-Security#8.4] validieren.

Schlägt die Signaturvalidierung erneut fehl, so verhält sich die zugehörige Transaktion wie ein Autorisierungsfehler. Der NCPeH-FD MUSS bei Fehlern, die bei der Verarbeitung und Validierung der TRC Assertion entstehen, mit einer entsprechenden Fehlermeldung gemäß [eHDSI_NCPeH_Components#4.4.2.4] auf die erhaltene SOAP-Anfrage antworten.

Der NCPeH-FD MUSS folgende Elemente prüfen:

• Der Wert des Elements Assertion/Advice/AssertionIDRef MUSS identisch mit dem Wert des Elements Security/Assertion@ID aus der IdA sein
• Der Wert des Elements Assertion/AuthnStatement/AuthnInstant DARF NICHT in der Zukunft liegen. Eine tolerierbare Zeitabweichung DARF bis maximal einer Minute (60 Sekunden) betragen.
• Falls das Element Assertion/AuthnStatement/SessionNotOnOrAfter angegeben ist, DARF der Wert NICHT in der Vergangenheit liegen. Eine tolerierbare Zeitabweichung DARF bis maximal einer Minute (60 Sekunden) betragen.

Neben Vorgaben aus [eHDSI_SAML_Profile#4] MUSS der NCPeH-FD folgende Prüfschritte durchführen und im Erfolgsfall die entnommenen Werte aus der TRC Assertion in die entsprechenden Variablen für Zwecke der internen Verarbeitung der entsprechenden XCA-Anfragen zu der internen Session (bezogen auf Identität des LE-EU, Land-B und Versicherten) zwischenspeichern:

Tabelle 6: TAB_NCPeH_TRC Assertion 

Falls es bei der Durchführung der Prüfkriterien zu Fehlern kommt, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und die Anfrage mit dem Code Sender und Subcode Invalid Security Token gemäß Vorgaben aus [eHDSI_NCPeH_Components#4.4.2.4] zurückweisen. Dabei MUSS der NCPeH-FD einen Audit Trail Eintrag gemäß Vorgaben aus [eHDSI_SAML_Profile#4.4] erstellen und in das Audit Repository schreiben.

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

Der NCPeH-FD MUSS die Struktur und die Werte für die einzelnen Elemente des SAR-Objektes gemäß Definition in [eHDSI_Audit_Trail_Profile#1.2.2] Abschnitt Non-Repudiation of Origin implementieren. Für die Kennzeichnung von Nachrichtentypen bzw. -transaktionen im SAR-Objekt MÜSSEN Werte aus [eHDSI_Audit_Trail_Profile] Table 7 "eHealth DSI Event IDs" verwendet werden. Das erstellte SAR-Objekt MUSS in dem Audit Repository des NCPeH-FD gespeichert werden. 

Nachweis für die Kommunikation mit dem entsprechenden Fachdienst der TI

Bei den Anfragen an die entsprechenden Fachdienste der TI zum Abruf von Versichertendaten MUSS der NCPeH-FD in das Element des SAR-Objektes SubmissionAcceptanceRejection/RecipientsDetails/EntityDetails/CertificateDetails/X509Certificate das öffentliche TLS-Zertifikat des jeweiligen Fachdienstes der TI (ePA Aktensystem, E-Rezept-Fachdienst) in Base64-Kodierung eintragen. Der NCPeH-FD MUSS in das Element SubmissionAcceptanceRejection/SenderDetails/CertificateDetails/X509Certificate das eigene öffentliche TLS-Zertifikat der eHDSI eintragen. Beim Element SubmissionAcceptanceRejection/SenderMessageDetails/MessageSubject MUSS der NCPeH-FD in Abhängigkeit vom TUC, in dem die Erstellung des SAR-Objektes initiiert wird, einen der folgenden Werte eintragen:

• bei [TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen] im Zusammenhang mit dem Anwendungsfall [5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren] den Wert ITI-55,
• bei [TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen] im Zusammenhang mit dem Anwendungsfall [5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren] den Wert ITI-55,
• bei [6.2.4 TUC_NCPeH_035: Demographische Versichertendaten aus E-Rezept extrahieren] den Wert ITI-55,
• bei [TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen] im Zusammenhang mit dem Anwendungsfall [5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten] den Wert ITI-38,
• bei [6.2.5 TUC_NCPeH_036: Liste der einlösbaren E-Rezepte des Versicherten aus dem E-Rezept-FD abrufen] den Wert ITI-38,
• bei [TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen] im Zusammenhang mit den Anwendungsfällen [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen] und [5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen] den Wert ITI-39,
• bei [6.2.6 TUC_NCPeH_037: Abzugebende E-Rezepte vom E-Rezept-FD abrufen] den Wert ITI-39,
• bei [6.2.7 TUC_NCPeH_038: Dispensierdokumente an E-Rezept-FD übermitteln] den Wert ITI-41.

Die restlichen Elemente des SAR-Objektes müssen nach Vorgaben aus [eHDSI_Audit_Trail_Profile#1.2.2] verarbeitet werden.

Wenn der NRO Eintrag nicht erstellt oder nicht im Audit Repository gespeichert werden konnte, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage vom NCPeH-Land-B abbrechen und mit einer Fehlermeldung gemäß [eHDSI_Messaging_Profile#6.2.1] und dem Code "Receiver" und Subcode "Audit Log Failure" aus [eHDSI_Messaging_Profile#6.2.2] antworten. Der NCPeH-FD MUSS das Element "Reason/Text" (siehe [eHDSI_Messaging_Profile#6.2.1]) mit der Fehlernachricht "It was not possible to create the Non-Repudiation of Origin entry in Germany." befüllen.

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. 

Nach dem Eingang der Nachricht MUSS der NCPeH-FD ein ARbR-Objekt erstellen und die Struktur und die Werte für die einzelnen Elemente des ARbR-Objektes gemäß [eHDSI_Audit_Trail_Profile#1.2.2] Abschnitt Non-Repudiation of Receipt verwenden. Für die Kennzeichnung von Nachrichtentypen bzw. -transaktionen im ARbR-Objekt MÜSSEN Werte aus der Tabelle in [eHDSI_Audit_Trail_Profile#2.3.5.8] verwendet werden. Das erstellte ARbR-Objekt MUSS in dem Audit Repository des NCPeH-FD gespeichert werden. 

Nachweis für die Kommunikation mit entsprechenden Fachdiensten der TI

Beim Erhalt von Antworten von den Fachdiensten der TI MUSS der NCPeH-FD in das Element des ARbR-Objektes  SubmissionAcceptanceRejection/SenderDetails/CertificateDetails/X509Certificate das öffentliche TLS-Zertifikat des jeweiligen Fachdienstes der TI (ePA Aktensystem, E-Rezept-Fachdienst) in Base64-Kodierung eintragen. Ferner MUSS der NCPeH-FD in das Element AcceptanceRejectionByRecipient/RecipientsDetails/EntityDetails/CertificateDetails/X509Certificate das eigene öffentliche TLS-Zertifikat der eHDSI eintragen. Beim Element AcceptanceRejectionByRecipient/SenderMessageDetails/MessageSubject MUSS der NCPeH-FD in Abhängigkeit vom jeweiligen TUC, in dem die Erstellung des ARbR-Objektes initiiert wird, einen der folgenden Werte eintragen:

• bei [6.2.4 TUC_NCPeH_035: Demographische Versichertendaten aus E-Rezept extrahieren] den Wert ITI-55,
• bei [TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen] im Zusammenhang mit dem Anwendungsfall [5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren] den Wert ITI-55
• bei [TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen] im Zusammenhang mit dem Anwendungsfall [5.1.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren] den Wert ITI-55,
  
• bei [TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen] im Zusammenhang mit dem Anwendungsfall [5.1.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten] den Wert ITI-38,
  
• bei [6.2.5 TUC_NCPeH_036: Liste der einlösbaren E-Rezepte des Versicherten aus dem E-Rezept-FD abrufen] den Wert ITI-38,
• bei [TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen] im Zusammenhang mit den Anwendungsfällen [5.1.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen] und [5.1.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen] den Wert ITI-39,
• bei [6.2.6 TUC_NCPeH_037: Abzugebende E-Rezepte vom E-Rezept-FD abrufen] den Wert ITI-39,
• bei [6.2.7 TUC_NCPeH_038: Dispensierdokumente an E-Rezept-FD übermitteln] den Wert ITI-41.

Die restlichen Elemente des ARbR-Objektes müssen nach Vorgaben aus [eHDSI_Audit_Trail_Profile#1.2.2] verarbeitet werden.

Wenn der NRR Eintrag nicht erstellt oder nicht im Audit Repository gespeichert werden konnte, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage vom NCPeH-Land-B abbrechen und mit einer Fehlermeldung gemäß [eHDSI_Messaging_Profile#6.2.1] und dem Code "Receiver" und Subcode "Audit Log Failure" aus [eHDSI_Messaging_Profile#6.2.2] antworten. Der NCPeH-FD MUSS das Element "Reason/Text" (siehe [eHDSI_Messaging_Profile#6.2.1]) mit der Fehlernachricht "It was not possible to create the Non-Repudiation of Receipt entry in Germany." befüllen.

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

4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen

Der Inhalt und die Struktur von eHDSI Audit Trail Schemata sind in [eHDSI_Audit_Trail_Profile#2] spezifiziert. Der NCPeH-FD MUSS den Audit Trail Eintrag nach dem eHDSI Audit Trail Schema "Patient Privacy" gemäß [eHDSI_Audit_Trail_Profile#2.3.2] erzeugen. Dieses Audit Schema dient zum Schutz der Privatsphäre der Versicherten und der Dokumentation von Verantwortlichkeiten des Anbieters des NCPeH-FD für die Datenverarbeitung in Bezug auf die Rechte des betroffenen Versicherten und der ordnungsgemäßen Erfüllung dieser Pflichten. Folglich dient dieser Audit Trail auch dazu, den Versicherten in die Lage zu versetzen, sich über alle Verwendungen seiner medizinischen Daten zu informieren. Durch die Analyse dieses Audit Trails soll der Versicherte die Rechtmäßigkeit aller Zugriffe auf seine Daten beurteilen können.

Für die Nachvollziehbarkeit und Nichtabstreitbarkeit (Non-Repudiation) von durchgeführten Vorgängen zum Nachrichtenaustausch verlangt die eHDSI gemäß [eHDSI_Audit_Trail_Profile#2.3.4], dass der vollständige Security Header jeder Nachricht vom NCPeH-FD in einem Audit Trail Eintrag erfasst und in dem Audit Repository gespeichert werden muss. Die erfassten Audit Trails MÜSSEN auch die relevanten "Participant Object"-Elemente enthalten, wie es in [eHDSI_Audit_Trail_Profile#2.3.4] beschrieben ist.

Wenn der Audit Trail Eintrag nicht erstellt oder nicht im Audit Repository gespeichert werden konnte, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage vom NCPeH-Land-B abbrechen und mit einer Fehlermeldung gemäß [eHDSI_Messaging_Profile#6.2.1] und dem Code "Receiver" und Subcode "Audit Log Failure" aus [eHDSI_Messaging_Profile#6.2.2] antworten. Der NCPeH-FD MUSS das Element "Reason/Text" (siehe [eHDSI_Messaging_Profile#6.2.1]) mit der Fehlernachricht "It was not possible to create the Patient Privacy Audit Trail entry in Germany." befüllen.

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

Der NCPeH-FD MUSS bei jeder Transformation und Transkodierung von Gesundheitsdaten des Versicherten in das entsprechende eHDSI Pivot Dokumentenformat (CDA Level 1 oder Level 3) einen Audit Trail Eintrag erstellen und in das Audit Repository schreiben. Der Audit Trail Eintrag MUSS dem Audit Schema gemäß [eHDSI_Audit_Trail_Profile#2.3.5.5] entsprechen.

Der NCPeH-FD MUSS Angaben zum Element EventIdentification gemäß Vorgaben in [eHDSI_Audit_Trail_Profile#2.3.1.1 und #2.3.5.5] umsetzten.

Der NCPeH-FD MUSS Vorgaben zum ActiveParticipant gemäß Vorgaben in [eHDSI_Audit_Trail_Profile#2.3.1.5] umsetzen.

Der NCPeH-FD MUSS nach Vorgaben aus [eHDSI_Audit_Trail_Profile#2.3.3.5] für die angeforderten Gesundheitsdaten des Versicherten ein ParticipantObjectIdentification Element erstellen und nach Durchführung der Transformierung und Transkodierung ein weiteres ParticipantObjectIdentification Element erstellen. Das Attribut ParticipantObjectID MUSS bei Abruf von Gesundheitsdaten von Fachdiensten der TI in beiden Elementen den Wert nach folgender Vorschrift enthalten:

1. Identifier der abgerufenen Gesundheitsdaten:
2. 1. Für das ePKA MIO MUSS der Wert aus der Variable METADATA_ePKA_MIO_uniqueId übernommen werden, siehe [6.1.3.1 TUC_NCPeH_005: Cross Gateway Retrieve Request zur Abfrage der Patient Summary CDA Level 3 verarbeiten])
   2. Beim Abruf von ePrescriptions MUSS je "innerem Bundle" aus der Liste fhir_erp_bundle_collection ein eigener Audit-Trail-Eintrag erstellt und dafür die eindeutig zugeordnete E-Rezept-Id übernommen werden, siehe [6.1.3.10 TUC_NCPeH_030: Abgerufene E-Rezepte transkodieren und transformieren].
3. "^"
4. Das entsprechende Kürzel für die grenzüberschreitende Fachanwendung (z.B. PS für Patient Summary, eP für ePrescription), gefolgt von einer Endung ".XML" oder ".PDF"
   
   Beispiele: "PS.XML", "PS.PDF", "eP.XML" oder "eP.PDF"
   
   Nutzungsvorschrift:  Die Endung aus dem jeweiligen Eingangsparameter DocumentUniqueId der XCA-Anfrage MUSS mit dem Wert im Schritt 3 identisch sein.

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"

Das Attribut ParticipantObjectID MUSS beim Senden von Gesundheitsdaten an Fachdienste der TI in beiden Elementen den Wert nach folgender Vorschrift enthalten:

1. Identifier der gesendeten Gesundheitsdaten:
2. 1. Beim Übermitteln von Dispensierdokumenten an den E-Rezept-Fachdienst MUSS pro Eintrag in der Liste xdr_request_cda_dispensation_documents ein eigener Audit-Trail-Eintrag erstellt und dafür die E-Rezept-ID aus dem jeweiligen Dispensierdokument übernommen werden, siehe [6.1.5.4 TUC_NCPeH_034: Dispensierdokumente transkodieren und transformieren].
      

Nutzungsvorschrift: Eine eventuell vorhandene Endung "^eP.XML" oder "^eP.PDF" DARF NICHT in der ID enthalten sein, da die Dispensierung zu einem E-Rezept nur einmalig und unabhängig vom zuvor abgerufenen CDA-Format des E-Rezeptes durchgeführt wird.

Beispiel: ParticipantObjectID="160.000.000.000.123.76"

Ferner MUSS der NCPeH-FD für jede Transaktion (Anfrage und Antwort, außer bei XCPD) einzeln ein ParticipantObjectIdentification Element gemäß Vorgaben aus [eHDSI_Audit_Trail_Profile#2.3.4] erstellen.

Wenn der Audit Trail Eintrag nicht erstellt oder nicht im Audit Repository gespeichert werden konnte, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage vom NCPeH-Land-B abbrechen und mit einer Fehlermeldung gemäß [eHDSI_Messaging_Profile#6.2.1] und dem Code "Receiver" und Subcode "Audit Log Failure" aus [eHDSI_Messaging_Profile#6.2.2] antworten. Der NCPeH-FD MUSS das Element "Reason/Text" (siehe [eHDSI_Messaging_Profile#6.2.1]) mit der Fehlernachricht "It was not possible to create the Translation Audit Trail entry in Germany." befüllen.

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 7: TAB_NCPeH_Beispiel_Translation_Audit_Trail 

4.1.7.5 Security Audit Trail Eintrag erstellen

Wenn der NCPeH-FD einen eigenen SMP-Datensatz (Service Metadata) auf dem zentralen eHDSI Configuration Service veröffentlicht oder vom zentralen eHDSI Configuration Service einen SMP-Datensatz eines NCPeH Land-B heruntergeladen hat, dann MUSS der NCPeH-FD einen Audit Trail Eintrag gemäß dem Patient Privacy Audit Schema (siehe [4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen]) erstellen und im Audit Repository speichern. Der Audit Trail Eintrag MUSS dem Audit Schema gemäß [eHDSI_Audit_Trail_Profile#2.3.5.4] entsprechen.

Wenn der Audit Trail Eintrag nicht vollständig im Audit Repository gespeichert werden kann, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage vom NCPeH-Land-B abbrechen und mit einer Fehlermeldung gemäß [eHDSI_Messaging_Profile#6.2.1] und dem Code Receiver und Subcode Audit Log Failure aus [eHDSI_Messaging_Profile#6.2.2] antworten. Der NCPeH-FD MUSS das Element Reason/Text (siehe [eHDSI_Messaging_Profile#6.2.1]) mit der Fehlernachricht It was not possible to create the Security Audit Trail entry in Germany. befüllen.

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

Tabelle 8: 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 de LE-EU 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.

Falls die Variable ida_permissions aus [4.1.5 Validierung der Identity Assertion des LE-EU] nicht leer ist, MÜSSEN bei der Prüfung durch die benannten technische Use Cases mindestens die folgenden Permission Codes aus [eHDSI_SAML_Profile#2.5] enthalten sein, um auf einen entsprechenden fachanwendungsspezifischen Dienst zugreifen zu dürfen:

Tabelle 9: TAB_Zugriffsberechtigung_durch_Prüfung_PermissionCodes

Falls in der Identity Assertion des LE-EU kein Identity Attribut "permission" mitgeliefert wird, dann muss nach [eHDSI_SAML_Profile#2.3] die Prüfung der Zugriffsberechtigung anhand des Rollencodes des LE-EU nach nationalen Vorgaben erfolgen.

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:

Falls die Variable ida_permissions leer ist, dann MUSS die Rolle des LE-EU anhand des Inhalts der Variablen ida_practitioner_role_code aus [4.1.5 Validierung der Identity Assertion des LE-EU] geprüft werden und genau einen der Codes aus der folgenden Tabelle (nach [eHDSI_SAML_Profile#2.3]) enthalten: 

Tabelle 10: TAB_Zugriffsberechtigung_durch_Prüfung_RollenCodes

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) zur Verfügung. Der NCPeH-FD ist zuständig für den Verbindungsaufbau und -abbau zu diesen Diensten. 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. 

Die Tabelle TAB_NCPeH_Schnittstellen_TI-Dienste listet die relevanten Schnittstellen der zentralen Diensten der TI für den NCPeH-FD auf. Diese Schnittstellen werden vom NCPeH-FD genutzt, um Endpunkte der Fachdienste zu lokalisieren, TI-Zertifikate zu validieren und sichere Verbindungen zu den Fachdiensten herzustellen.

Tabelle 11: TAB_NCPeH_Schnittstellen_TI-Dienste

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

Wenn der NCPeH-FD TLS-gesicherte Verbindungen zu Diensten der TI über das zentrale Netz der TI aufbaut, dann MUSS er folgende Vorgaben zur sicheren Nutzung von TLS beachten:

• [gemSpec_Krypt#3.3.2 "TLS-Verbindungen"] allgemein,
• beim Verbindungsaufbau zu ePA-Aktensystemen zusätzlich [gemSpec_Krypt#3.15.3 "ePA-spezifische TLS-Vorgaben"]
• beim Verbindungsaufbau zum E-Rezept-Fachdienst zusätzlich [gemSpec_Krypt#A_21332*] (unter Beachtung des Verbots von RSA-basierten Ciphersuiten für den NCPeH-FD nach A_25639),
• [gemSpec_PKI#8.4.1 "TLS-Verbindungsaufbau"].

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

Für die vom NCPeH-FD mittels TLS zu nutzenden Dienste ist nur eine einseitige Authentisierung im TLS-Handshake vorgesehen.

Bei der Server-Authentisierung des jeweiligen Dienstes MUSS der NCPeH-FD eine Prüfung der Zertifikate nach [4.2.3 Prüfung von nonQES-Zertifikaten] durchführen. Zusätzlich MUSS der NCPeH-FD eine Prüfung des FQDN durchführen und sicherstellen, dass der FQDN im Zertifikat mit dem der Komponente zugeordneten FQDN übereinstimmt.

Der NCPeH-FD MUSS den Aufbau der TLS-Verbindung zum entsprechenden Service-Endpunkt des Dienstes der TI abbrechen, wenn eine der obigen Prüfungen mit einem Fehler beendet wird. 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

Der NCPeH-FD MUSS alle nonQES Zertifikate, die er aktiv verwendet (z. B. TLS Verbindungsaufbau oder Aufbau eines VAU-Kanals) auf Integrität und Authentizität prüfen.

Falls die Prüfung eines Zertifikats kein positives Ergebnis ("gültig") liefert, so MUSS der NCPeH-FD die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.

Der NCPeH-FD MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können.

Tabelle 12: TAB_nonQES_Zertifikatsübersicht

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

Der NCPeH-FD MUSS die X.509 nonQES Zertifikate der TI nach [gemSpec_PKI#TUC_PKI_018] im Kontext der jeweiligen Aktivität nach TAB_nonQES_Zertifikatsübersicht mit folgenden Parametern prüfen:

Tabelle 13: TAB_Prüfparameter_nonQES_Zertifikate_TI

Der NCPeH-FD MUSS die Vorgaben zur Prüfung der Sperrinformation von Zertifikaten nach [gemSpec_PKI#A_23225-*] umsetzen. Der NCPeH-FD KANN auf eine Zwischenspeicherung der Sperrinformation von Zertifikaten verzichten, wenn das definierte Prüfintervall eines Zertifikats gleich oder größer als OCSP_CACHE_REFRESH_PERIOD ist. Der Konfigurationswert OCSP_CACHE_REFRESH_PERIOD entspricht dem in A_23225-*, Punkt 2 definierten Wert "D".

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

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 14: 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

Der NCPeH-FD MUSS bei einem Internet Zertifikat sowohl eine Signaturprüfung als auch eine Prüfung der zeitlichen Gültigkeit durchführen. Falls diese Prüfung negativ ausfällt, MUSS er das Zertifikat als "ungültig" bewerten.

Der NCPeH-FD MUSS das Zertifikat anhand der Signaturprüfung auf ein CA-Zertifikat einer CA, die die "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates" ([https://cabforum.org/baseline-requirements-documents/]) erfüllt, zurückführen können. Ansonsten MUSS er das Zertifikat als "ungültig" bewerten.

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 [4.1.1 Konfigurationsparameter]) 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 [4.1.1 Konfigurationsparameter]) 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 [4.1.1 Konfigurationsparameter]) 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 [4.1.1 Konfigurationsparameter]). 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 [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 15: 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.

Falls beim TLS-Verbindungsaufbau ein Fehler oder Timeout auftritt, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage eines NCPeH Land-B und der dabei ermittelten Daten abbrechen und 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 "Unable to connect to the national electronic health record system." befüllen.

Hinweis: Eine Beispielimplementierung für den Aufbau der TLS-Verbindung zu einem ePA-Aktensystem ist unter [github-Link-TLS] veröffentlicht.

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 [4.1.6 Validierung der TRC Assertion],
• Identifier des LE-EU gemäß Variable ida_name-id aus [4.1.5 Validierung der Identity Assertion des LE-EU] und
• Ländercode des Land-B gemäß Variable tls_country aus [4.1.3.1 Sicherer Kanal: TESTA-ng und TLS]
  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 [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 [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 [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 [4.1.5 Validierung der Identity Assertion des LE-EU],
• Interne Variablen aus [4.1.5 Validierung der Identity Assertion des LE-EU],
• Referenz zu einem VAU-Kanal für das ePA-Aktensystem (siehe [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 [4.1.1 Konfigurationsparameter]) 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 [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 16: 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 [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 17: 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.

Hinweis: Eine Beispielimplementierung für den Aufbau der VAU-Kanals zu einem ePA-Aktensystem ist unter [github-Link-VAU] veröffentlicht.

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 [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 [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 [4.1.1 Konfigurationsparameter]). 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 [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 [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 [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 [4.2.5 Lokalisierung der Service-Endpunkte der ePA]). Für weiterführende Informationen zur Verwendung des VAU-NP siehe [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 18: 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 [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 19: 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 Mitgliedsstaaten 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.

Der NCPeH-FD MUSS privates Schlüsselmaterial vom Zertifikatsprofil "SM-B NCPeH" (C.HCI.AUT, C.HCI.ENC, C.HCI.OSIG), die dem NCPeH Land-B als Repräsentation in der TI eindeutig zugeordnet sind, in einem HSM, dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde, integritätsgeschützt und vertraulich erzeugen. Die Prüftiefe für Einsatz von HSM MUSS gemäß Vorgaben aus [4.3 Sicherheit und Datenschutz] entsprechen.

Der Anbieter des NCPeH-FD MUSS einen sicheren Prozess zur Personalisierung des HSM definieren und etablieren, der die in Tabelle Tab_NCPeH_Personalisierung_HSM genannten Aspekte beinhaltet. Der NCPeH-FD MUSS fest kryptographisch mit dem HSM gekoppelt sein, sodass eine hinsichtlich Vertraulichkeit und Integrität geschützte, beidseitig authentisierte Verbindung zwischen NCPeH-FD und HSM besteht und ausschließlich der NCPeH-FD die auf dem HSM gespeicherten TI-Identitäten nutzen kann. Parallel zu diesen Anforderungen siehe auch die Sicherheitsanforderung [A_22909 - Anbieter des NCPeH-Fachdienstes - Sicherer Betrieb und Nutzung eines HSMs].

Tabelle 20: Tab_NCPeH_Personalisierung_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 Zusammenhang mit HSM insb. zur sicheren Aufbewahrung von privaten Schlüssel, die von der TI und eHDSI ausgestellt wurden, sind für HSM-Kryptographieschnittstelle, Intergritätsprüfung der VAU, Managementprozesse des HSM, sicherer Betrieb und Einsatz zertifizierter HSM im [4.3 Sicherheit und Datenschutz] weitere relevante Anforderungen enthalten.

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, muss der NCPeH-FD zuerst die Identität (Ländercode) des NCPeH Land-B innerhalb der eHDSI ermitteln. Im Rahmen der gegenseitigen TLS-Authentisierung mit dem NCPeH Land-B MUSS der NCPeH-FD aus dem eHDSI-TLS-Zertifikat des NCPeH Land-B die Landidentität ermitteln, den Ländercode (ISO 3166-1 Alpha 2) gemäß [eHDSI_Certificate_Profile#3.1] Element Subject C (Country) bzw. siehe auch Variable tls_country im [4.1.3.1 Sicherer Kanal: TESTA-ng und TLS]. Im nächsten Schritt kann der NCPeH-FD anhand der ermittelnden Länderidentität über das Zertifikatselement "commonName" des Zertifikatsprofils "SM-B NCPeH" (siehe [gemSpec_PKI#"SM-B NCPeH"]) das passende Signaturzertifikat als Repräsentation des NCPeH Land-B im HSM eindeutig referenzieren und verwenden. Dabei MUSS der NCPeH-FD die inhaltliche Struktur des Zertifikatselements commonName beachten: 

<Kurzform des Ländernamens> (<zweistelliger Ländercode>)

Beschreibung des Aufbaus:

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 Zuordnung des Zertifikats zu dem NCPeH 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

Der NCPeH-FD MUSS bei der Kommunikation mit dem E-Rezept-FD in allen HTTP-Requests im äußeren Request den HTTP-Header "user-agent" nach der Vorgabe [gemILF_PS_eRp#A_20015*] erstellen und befüllen.

Der NCPeH-FD MUSS bei der Kommunikation mit dem E-Rezept-FD in allen HTTP-Requests im äußeren Request den HTTP-Header "X-erp-user" nach der Vorgabe [gemILF_PS_eRp#A_21568*] erstellen und dabei den Wert "n" als NCPeH-FD einfügen.

Der NCPeH-FD MUSS bei der Kommunikation mit dem E-Rezept-FD in allen HTTP-Requests im äußeren Request den HTTP-Header "X-erp-resource" nach der Vorgabe [gemILF_PS_eRp#A_21569*] setzen und dabei den entsprechenden Wert gemäß der Tabelle "TAB_NCPeH_HTTP-Header_X-erp-resource" einfügen.

Tabelle 21: TAB_NCPeH_HTTP-Header_X-erp-resource

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

Der E-Rezept-FD ist gemäß den Festlegungen in [gemSpec_FD_eRp#Servicelokalisierung] lokalisierbar. Dabei nutzt der NCPeH-FD die Lokalisierungsinformationen gemäß Vorgabe aus [gemILF_PS_eRp#A_19451*]. Die URL für die Kommunikation mit dem E-Rezept-FD bildet der NCPeH-FD nach der Vorgabe aus [gemILF_PS_eRp#A_19744*].

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

Das Redundanzkonzept 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. Die möglichen Reaktionen darauf sind entweder eine erneute DNS-Abfrage für den Erhalt einer neuen IP-Adresse durchzuführen oder eine der weiteren IP-Adressen aus der letzten DNS-Abfrage zu nutzen.

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

Für die Kommunikation mit dem E-Rezept-FD gelten die Vorgaben zur TLS-gesicherten Kommunikation nach [gemILF_PS_eRP#Kommunikation zu den Diensten der TI] und [4.2.2.1 TLS-Verbindungsaufbau zu Diensten der TI über das zentrale Netz der TI].

Die Kommunikation zum E-Rezept-FD wird zusätzlich zu TLS über einen sicheren Kanal zwischen der VAU-Umgebung des NCPeH-FD und der VAU im E-Rezept-FD gesichert (Verschlüsselung auf HTTP-Ebene). Beim Aufruf der Operationen des E-Rezept-FD muss eine verschlüsselte Kommunikation gemäß der Vorgabe [gemILF_PS_eRp#A_19741*] gewährleistet werden.

Der NCPeH-FD MUSS in der Rolle als E-Rezept-Client beim Aufbau von VAU-Kanälen zum E-Rezept-FD die Vorgaben aus [gemSpec_Krypt#VAU-Protokoll für E-Rezept] umsetzen.

Wenn der NCPeH-FD das VAU-Zertifikat des E-Rezept-FD mit dem Ergebnis gültig geprüft hat, dann KANN er dieses Zertifikat für 12h zwischenspeichern und nutzen.

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

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 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 [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 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-Fachdienst Verordnungen in der alten und neuen Profilversion. D.h. der NCPeH muss für diesen Zeitraum und zusätzlich für die Dauer der Gültigkeit der Verordnungen (maximal 365 Tage nach Ende des Übergangszeitraumes) in der Verarbeitung der Response der Operation POST /$get-eu-prescriptions mehrere (ggf. mehr als zwei) Profilversionen unterstützen.

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. D.h. der NCPeH muss innerhalb dieses Übergangszeitraumes die für die Operation POST /$get-eu-prescriptions und POST /Task/$eu-close unterstützte Profilversion von der alten auf die neue Profilversion umstellen.

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 - die 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 Betreiber des NCPeH-FD selbst. Qualitätsgesicherte Prozesse in Form von Audits der gematik und der EU halten die Überprüfungsergebnisse fest. 

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

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

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

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

Die folgenden Anforderungen verhindern Profilbildungen über Versicherte und Leistungserbringer(-institutionen) durch den Anbieter bzw. dessen Mitarbeiter.

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: für die Verschlüsselung gelten die Anforderungen aus [gemSpec_Krypt].

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.

Hinweis: Zwischenspeicherung entspricht nicht einer Verarbeitung im RAM innerhalb der VAU.

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.1 Datenschutzrechtliche- und informationssicherheitstechnische 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.

4.3.2 Verarbeitungskontext des NCPeH-FD

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

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

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

Der Verarbeitungskontext umfasst sämtliche physikalischen Systemkomponenten sowie sämtliche Softwarekomponenten, deren Sicherheitseigenschaften sich auf den Schutz der personenbezogenen medizinischen Daten vor Zugriff durch Unbefugte bei ihrer unverschlüsselten Verarbeitung auswirken können.

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

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

4.3.3 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld

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

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#Performancevorgaben 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 NCPeHs. 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 Mitgliedsstaaten (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 24: 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 25: 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 26: 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 NCPeHs 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/] 

4.5 Test des NCPeH-FD

Zum Test des NCPeH-FD werden hier im engeren Sinne die technischen Aktivitäten zur Prüfung der Funktionalität der Anwendungsszenarien "Patient Summary Land-A", "ePrescription/eDispensation Land-A" und die Integration des NCPeH-FD in die Telematikinfrastruktur betrachtet.

Themen zum Compliance Check und dem zugehörigen Self-Assessments werden von der eHDSI vorgegeben und beschrieben, siehe dazu [eHDSI Compliance Check Framework] und [eHDSI Compliance Check Services].

Zur Sicherung der Funktionalität, Interoperabilität und Nutzbarkeit der Anwendungsszenarien "Patient Summary Land-A" und "ePrescription/eDispensation Land-A" ergeben sich für den Test verschiedenste Aufgaben. Allgemein lassen sich diese aber in folgende Abschnitte aufteilen:

1. Test der Anwendung während der Entwicklung in der eigenen Entwicklungsumgebung mit Integration in die Testumgebung RU der Telematikinfrastruktur.
2. Abnahmetest des NCPeH-FD zum Nachweis der Interoperabilität mit der TI durch die gematik mit Integration in die Testumgebung TU, Unterstützung bei Zulassungstests anderer am Anwendungsverlauf beteiligter TI-Produkte (ePA FdVs, ePA-Aktensysteme, IDP-Dienst).
3. Tests der Anwendung mit Integration in die Umgebung der eHDSI.
4. Test der Anwendung in der Produktivumgebung (PU).

4.5.1 Durchführung eigenverantwortliche Tests des Herstellers bzw. Betreibers

Der Hersteller bzw. Anbieter des NCPeH-FD MUSS eigenverantwortliche Tests ("EvT") des NCPeH-FD durchführen. Dabei wird davon ausgegangen, dass sich Hersteller und Anbieter untereinander abstimmen, wer für die Durchführung der verschiedenen Testarten verantwortlich ist.

Für die Durchführung der EvTs gilt als Grundlage [gemKpt_Test#2.4.1 Eigenverantwortlicher Test]. Abweichend von den dortigen Vorgaben erfolgt eine Prüfung der EvTs nicht über die Bereitstellung von Testprotokollen und Testberichten, sondern über einer Vorführung, bei dem der gematik die wichtigsten Ergebnisse der Tests in einem Vor-Ort-Termin präsentiert und Funktionalitäten vorgeführt werden. Der Umfang und Fokus der Vorführung wird vorab mit der gematik abgestimmt. Das mit der gematik abgestimmte Protokoll der Vorführung wird als Dokumentation des EvT von der gematik aufgenommen.

Ergänzend zu den Festlegungen von [gemKpt_Test#2.4.1 Eigenverantwortlicher Test] KANN der Produkttest als Teil des EvT ohne weitere Abstimmung mit dem Testmanager mit Simulatoren in einer eigenen Testumgebung durchgeführt werden (ohne Anbindung an die RU). Damit soll insbesondere die Durchführung von negativen Tests erleichtert werden. Es gilt jedoch weiterhin, dass der produktübergreifende Test als Teil des EvT gemäß [gemKpt_Test] in der RU integriert durchgeführt werden muss.

4.5.2 Bereitstellung von Testobjekten des NCPeH-FD in der TI

Im Rahmen der Entwicklung der Anwendungsszenarien PS-A und ePeD-A sind integrative Tests mit den daran beteiligten Produkten der TI (NCPeH-FD, ePA FdV, ePA-Aktensystem, E-Rezept-FdV, E-Rezept-Fachdienst, IDP-Dienst und zentrale Produkte der TI) durchzuführen. Dies erfolgt zum einen entwicklungsbegleitend in der Umgebung RU und zum anderen zu Abnahme- bzw. Zulassungszwecken in der TU (siehe [gemKpt_Test]).

Der Anbieter des NCPeH-FD MUSS jeweils ein Testobjekt NCPeH-FD in den Umgebungen RU und TU bereitstellen. Er MUSS eigene integrative Tests mit Produkten der TI in der RU durchführen. Der Anbieter MUSS anderen Herstellern bzw. Betreibern von beteiligten TI-Produkten die Durchführung integrativer Tests in der RU und der gematik die Durchführung von Zulassungs- bzw. Abnahmetests in der TU ermöglichen. Er MUSS der BfArM im Rahmen der Entwicklung und Pflege des MTCs die Durchführung von Tests ermöglichen. Er MUSS sich mit der gematik zur Durchführung gemeinsamer, integrativer Tests (Connectathon) abstimmen, um die Verfügbarkeit der zu integrierenden Produkte und die Teilnahme der Hersteller dieser Produkte sicherzustellen.

Der Anbieter des NCPeH-FD MUSS der gematik Abnahmetests zur Prüfung der korrekten Integration in die TI - insbesondere der Anwendungen ePA und E-Rezept - ermöglichen. Die Durchführung dieser Tests sind gemeinsam zu koordinieren.

Für die Bereitstellung der Produkte in den beiden Umgebungen gilt [gemKpt_Test#3 Systemumgebungen]. Die konkret umzusetzenden Anforderungen sind im [gemProdT_NCPeH_FD] aufgeführt.

4.5.3 Testspezifische Funktionen im NCPeH-FD

4.5.3.1 Tracing mit ePA-Aktensystemen in Nichtproduktivumgebungen

Für die Fehlersuche in Nichtproduktivumgebungen -- insbesondere bei IOP-Problemen zwischen Produkten verschiedener Hersteller in einer fortgeschrittenen Entwicklungsphase -- hat es sich als notwendig erwiesen, dass der Klartext der Kommunikation zwischen ePA-Client und VAU-Instanz eines ePA-Aktensystems lesbar sein muss.

Der NCPeH-FD MUSS die Vorgaben aus [gemSpec_Krypt#7.7 Tracing in Nichtproduktivumgebungen] als ePA-Client umsetzen.

Der NCPeH-FD MUSS sicherstellen, dass die Mechanismen für das Tracing mit dem ePA-Aktensystem gemäß [gemSpec_Krypt#A_24477*] in der Produktivumgebung nicht zum Einsatz kommen und dass der VAU-Kanal im Produktivsystem entsprechend Vorgaben aus [gemSpec_Krypt#Transport und Sicherung von Nutzdaten] als produktiv gekennzeichnet werden.

Die umzusetzenden Anforderungen sind in [gemProdT_NCPeH_FD] aufgeführt.

Als weiterführende Information siehe auch [gemSpec_Aktensystem_ePAfueralle#3.19.4 Tracing in Nichtproduktivumgebungen].

4.5.4 Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI

Um anderen Herstellern, der BfArM als auch der gematik eine eigenständige und automatisierte Durchführung von integrativen Tests in den Umgebungen RU und TU zu ermöglichen, MUSS der Anbieter des NCPeH-FD eine Schnittstelle zum Auslösen von Anwendungsfällen in beiden Umgebungen bereitstellen (NCPeH-Testinterface). Das NCPeH-Testinterface MUSS die parallele Durchführung von Tests ermöglichen, um mehrere Nutzer parallel bedienen zu können.

Das NCPeH-Testinterface SOLL in Form einer Simulation eines NCPeH Land-B erfolgen, in der auch die eHDSI-Schnittstellen zur Kommunikation mit dem NCPeH-FD genutzt werden. In den nachfolgenden schematischen Darstellungen der Testaufbauten wird sie als Simulation des NCPeH Land-B dargestellt.

Der Zugang zum NCPeH-Testinterface MUSS mittels Gateway über das Internet ermöglicht werden. Das NCPeH-Testinterface SOLL über TLS mit beidseitiger Authentifizierung abgesichert werden.

Die konkrete technische Beschreibung der Triggerschnittstelle [gemTestTriggerNCPeH] wird in GitHub bereitgestellt.

4.5.4.1 Daten für das automatisierte Auslösen von Anwendungsfällen

Das NCPeH-Testinterface nutzt für einige Eingabeparameter Objekte, an die zu definierende Datenprofile gekoppelt sind (EuCountryCode, IdAAssertionProfile/ProfileName, TRCAssertionProfile/ProfileName, DispenseProfile, PatientProfile).

Ein Datenprofil fungiert einerseits wie ein Template, in dem die Daten hinterlegt sind, die für die Kommunikation über die eHDSI-Schnittstelle verwendet werden sollen, so dass diese nicht alle über das NCPeH-Testinterface bereitgestellt werden müssen. Damit soll auch die Komplexität der Schnittstelle reduziert werden. Andererseits definiert es auch Daten, die in die Kommunikation mit dem NCPeH-FD eingehen. Am wichtigsten ist hier die Referenz auf die zu verwendende Zertifikate.

Datenprofile, die von der gematik oder Herstellern beteiligter TI-Produkte benötigt werden, MÜSSEN im Rahmen der Bereitstellung der Schnittstelle zwischen dem Betreiber des NCPeH-Testinterface und der gematik abgestimmt werden. Die gemeinsam definierten Datenprofile MÜSSEN mit dem NCPeH-Testinterface zur Nutzung bereitgestellt werden. Es MUSS möglich sein, Datenprofile hinzuzufügen, zu ändern oder zu löschen.

Das Objekt EuCountryCode referenziert folgendes Datenprofil:

• Das TLS-Zertifikat, das für die Kommunikation mit dem NCPeH-FD genutzt werden soll.
• Die HomeCommunityId, die in dem Profil per Default für den NCPeH Land-B genutzt werden soll.

Das Objekt IdAAssertionProfile referenziert folgendes Datenprofil:

• Das Signatur-Zertifikat, das zum Signieren der IdA-Assertion zum Einsatz kommen soll.
• Der Wert, der im SAML-Element Assertion/Subject/NameID einzutragen ist (Identifier des LE-EU) als auch das Format des Wertes (Attribut @Format).
• Die Werte, die in dem Profil per Default in den Attributen der Struktur AttributeStatement einzutragen oder wegzulassen sind:
• • urn:oasis:names:tc:xspa:1.0:subject:subject-id,
  • urn:oasis:names:tc:xacml:2.0:subject:role,
  • urn:ehdsi:names:subject:clinical-speciality,
  • urn:ehdsi:names:subject:on-behalf-of,
  • urn:oasis:names:tc:xspa:1.0:subject:organization,
  • urn:oasis:names:tc:xspa:1.0:subject:organization-id,
  • urn:ehdsi:names:subject:healthcare-facility-type,
  • urn:oasis:names:tc:xspa:1.0:environment:locality,
  • urn:oasis:names:tc:xspa:1.0:subject:hl7:permission.

Das Objekt TRCAssertionProfile referenziert folgendes Datenprofil:

• Das Signatur-Zertifikat, das zum Signieren der TRC Assertion zum Einsatz kommen soll.
• Der Wert, der im SAML-Element Assertion/Subject/NameID einzutragen ist (Identifier des LE-EU) als auch das Format des Wertes (Attribut @Format).

Das DispenseProfile wird definiert, da für den Test der Dispensierung ein oder mehrere Dokumente im eHDSI CDA-Pivotformat generiert werden müssen, die aus einem Land-B stammen. Die Erstellung dieser Dokumente MUSS der Land-B Simulator durchführen, bei denen die angegebenen DispenseProfile und den weiteren übergebenen Parametern zugrunde liegen.

Das Objekt DispenseProfile definiert benötigte Datenanteile für ein Dispense-Dokument nach [eHDSI_CDA_Format]:

• Medicinal Product Identifier,
• Medicinal Product Brand Name,
• Medicinal Product Classification,
• Medicinal Product Package Data,
• Active Ingredients Data,
• Marketing Authorization Holder,
• Falls nötig und in gemeinsamer Abstimmung, weitere benötigte medizinische Daten zur Dispensierung.

Mit der KVNR wird für die Generierung von Dispensier-Dokumenten zukünftig auch ein PatientProfile referenziert. Neben der KVNR selbst werden dafür folgende weitere Daten benötigt:

• Insurance Number,
• Given Name,
• Family Name,
• Gender.

Das NCPeH-Testinterface gibt als Response auf die REST-Requests die Inhalte der Nachrichten von der eHDSI-Schnittstelle zurück (siehe [gemTestTriggerNCPeH]). Also den jeweiligen IHE-Request und die IHE-Responses, die mit dem NCPeH-FD ausgetauscht wurden. Beides wird jeweils aufgeteilt in die HTTP-Request bzw. HTTP-Response-Zeile, den http-Header und den http-Body, jeweils Base64-kodiert. Damit soll dem aufrufenden Testfall die Möglichkeit gegeben werden, die Reaktion des NCPeH-FD direkt zu prüfen und zu bewerten.

4.5.5 Testdurchführung nach Vorgaben der eHDSI

Die eHDSI beschreibt in [eHDSI Test Services], insbesondere im [eHDSI Test Framework] ihre Anforderungen und das Vorgehen für den Test der verschiedenen Anwendungsszenarien. Die dort definierten Testphasen "Formal / Upgrade Pre-Production Test" (PPT) und "Produktion Environment Test" (PET), sind verpflichtend. Der Anbieter MUSS an diesen Testphasen teilnehmen und die Vorgaben aus dem [eHDSI Test Framework] umsetzen. Verantwortlich für Organisation und Teilnahme an den eHDSI Testevents ist der deutsche Anbieter des NCPeH.

Der Anbieter des NCPeH-FD SOLL frühzeitig Tests mit einem europäischen Partner durchführen, um die beidseitige Interoperabilität der NCPeHs zu prüfen. Der Anbieter SOLL zusätzlich an den Testphasen Connectivity Testing und Preparatory Pre-Production Testing (Pre-PPT) teilnehmen.

Zur Teilnahme an den Testphasen PPT und Pre-PPT MUSS es mindestens eine rechtzeitige Abstimmung mit der gematik geben (mind. 12 Wochen vor Beginn der Testphase). Über die gematik muss hierbei die zeitliche Verfügbarkeit der benötigten Produkte der TI in einer der Umgebungen RU oder TU sichergestellt werden (z. B. zum Ausschluss von eventuellen Wartungsphasen von Fachdiensten in der TI). Es ist außerdem zu klären, welche Unterstützung seitens der gematik im Verlauf der Testdurchführung benötigt werden.

4.5.6 Schematischer Testaufbau

In den folgenden Kapiteln wird informativ der geplante bzw. mögliche Aufbau der Testumgebungen für die verschiedenen Testphasen dargestellt. Abweichungen können auftreten und sind zwischen Anbieter und der gematik im Rahmen der Entwicklung abzustimmen.

4.5.6.1 Testaufbau für integrative Tests in der Telematikinfrastruktur

Der integrative Test des NCPeH-FD mit Produkten der TI (ePA FdV, ePA-AS, E-Rezept-FdV, E-Rezept-Fachdienst, IDP-Dienst und zentrale Produkte der TI) erfordert eine unabhängige Testdurchführung, da verschiedene Produkthersteller, das BfArM und die gematik Bedarf an einer eigenen Qualitätssicherung haben. Da in dieser Entwicklungsphase die Tests noch auf das deutsche Umfeld beschränkt sind, muss es eine Möglichkeit geben, die verschiedenen Anwendungsfälle der Szenarien automatisiert anzustoßen, die die integrativen Aktivitäten mit den Produkten der TI auslösen. Dies sind die Anwendungsfälle, die eine Interaktion mit den Produkten der TI bewirken. Um den verschiedenen testdurchführenden Instanzen diese Testmöglichkeit zu bieten, wurde das NCPeH-Testinterface in [4.5.4 Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI] definiert.

Der mögliche Aufbau der Testumgebung für den Anbieter des NCPeH-FD in der RU wird in der folgenden Grafik schematisch dargestellt. Je nach testdurchführender Instanz kann die Zuordnung zu den herstellerspezifischen Umgebungsanteilen variieren.

Abbildung 4: Schematischer Testaufbau für den integrativen Test des NCPeH-FD mit der Telematikinfrastruktur 

Die Simulation der E-Rezept-App und die Primärsystemsimulation werden zusammen mit der Konnektor Service Plattform KSP von der gematik bereitgestellt. Dies soll vor Allem die Möglichkeit bieten, in einem testvorbereitenden Schritt jeweils ein spezifisches, zum Testfall passende Dokumente im relevanten Fachdienst der TI einzustellen (automatisiertes Testdatenmanagement für Testdokumente und Berechtigungsmanagement).

Verschiedene Test-FdVs müssen für die Berechtigung des NCPeH-FD in ePA-Aktensystemen bzw. dem E-Rezept-Fachdienst zum Einsatz kommen. Wenn die Mechanismen zur Berechtigung des NCPeH-FD in den Anwendungen ePA und E-Rezept einsatzbereit sind, wird damit eine NCPeH-FD-Identität mit Repräsentation eines EU-Landes berechtigt. Vor diesem Zeitpunkt kann mit einer deutschen LE-Identität anstelle einer NCPeH-FD-Identität getestet werden. Das Test-FdV wird nach [gemKpt_Test#9.1 Bereitstellung von Remote-Test-FdVs] von den Herstellern der FdVs bereitgestellt.

Die ePA-Aktensysteme müssen in den Umgebungen RU und TU einen Sensorpunkt zum Aufzeichnen der TLS-entschlüsselten Kommunikation mit den ePA-Clients bereitstellen. Der Sensorpunkt ist über das Access Gateway des ePA-Aktensystems nach [gemSpec_Aktensystem_ePAfueralle#3.19.4 Tracing in Nichtproduktivumgebungen] erreichbar. Das von der gematik zur externen Nutzung bereitgestellte Tool [gemTigerProxy] kann mit Hilfe der Vorgaben aus [gemSpec_Krypt] und dem Sensorpunkt die VAU-Kommunikation entschlüsseln (siehe auch [4.5.3.1 Tracing mit ePA-Aktensystemen in Nichtproduktivumgebungen]). Auf diese Weise wird eine Überprüfbarkeit der VAU-verschlüsselten Kommunikation eines ePA-Clients mit einer VAU-Instanz eines ePA Aktensystems ermöglicht.

Ein ähnlicher Aufbau ergibt sich für die Hersteller der ePA- und E-Rezept-Produkte und bei Bedarf für die BfArM in der RU. Abweichungen können hier je nach Nutzer im (Nicht-)Bedarf eines Konnektors oder eines FdVs zum Dokumenten- und Berechtigungsmanagement auftreten.

Abweichend von der schematischen Darstellung erfolgt der Testaufbau für den Test durch die gematik in der TU.

4.5.6.2 Testaufbau für den (Pre-)PPT

In den eHDSI-Testphasen Pre-PPT und PPT liegt der Testfokus auf der Interoperabilität der eHDSI-Schnittstellen, der Konformität der Dokumente Patient Summary, ePrescription/eDispensation und der Usability des Gesamtablaufs aus Sicht des europäischen LE. Der PPT ist dabei Bestandteil des Zulassungsverfahrens der EU. Die Forderung der eHDSI nach verschiedenen, realitätsnahen Dokumenten macht es wiederum notwendig, unterschiedliche ePKA-Dokumente im ePA-Aktensystem und verschiedene E-Rezepte im E-Rezept-Fachdienst bereitstellen zu können. Hierfür sollen Komponenten aus dem Testaufbau wiederverwendet werden (Dokument oder E-Rezept einstellen via Primärsystemsimulation und KSP).

Da der zeitliche Rahmen für die Entwicklung der Produkte der TI und die zeitliche Organisation der Testphasen in der EU nicht leicht in Übereinstimmung zu bringen sind, muss für die Durchführung des PPT eine Entscheidung über die zu nutzende Umgebung in Abstimmung mit der gematik getroffen werden. Die Herausforderungen zur Festlegung einer Umgebung werden vor allem auf die Neu-Entwicklung von EU-Szenarien zutreffen. Ziel ist es, den PPT möglichst nicht auf Produktinstanzen der RU durchzuführen, die zur Weiterentwicklung der jeweiligen Produkte genutzt werden ("RU-Dev"). Ein Prep-PPT oder PPT DARF jedoch NICHT in der PU durchgeführt werden.

Die Sicherstellung der Verfügbarkeit der TI-Produkte erfolgt über die in [4.5.5 Testdurchführung nach Vorgaben der eHDSI] geforderte Abstimmung mit der gematik. Je nach Absprache und Vorbereitung kann hier auch eine Unterstützungsleistung durch die gematik notwendig werden.

4.5.6.3 Testaufbau für den PET

Das [eHDSI Test Framework] definiert eine Durchführung von Tests in der Produktivumgebung nach Erteilung der Betriebserlaubnis (Product Environment Test - PET). Diese Tests MÜSSEN im Rahmen der Inbetriebnahme eines neuen Anwendungsszenarios bzw. des Upgrades auf eine neue eHDSI Releaseversion ("Wave") erfolgen. Dementsprechend muss produktübergreifend eine Möglichkeit geschaffen werden, diese Tests mit der Produktivumgebung der TI durchzuführen.

In Vorbereitung des PET MUSS sich die DVKA Versichertenidentitäten zu Prüfzwecken mit zugehörigen Konten in den ePA-Aktensystemen beschaffen. Dazu können eGK Prüfkarten für die Rolle und Identität eines Prüfversicherten über den gematik WEB-Shop [gemWebShop] bestellt werden. In [gemSpec_Aktensystem_ePAfueralle#2.4 Validierungskonto] werden Festlegungen getroffen, um Validierungskonten mit Hilfe der KVNR der eGK Prüfkarten erstellen lassen zu können. Diese eGK Prüfkarten sind auch für die Durchführung von PETs mit E-Rezepten und dem produktiven E-Rezept-FdV zu nutzen.

Die DVKA MUSS sich um LE-DE (Ärzte oder Zahnärzte) kümmern, um für den PET realitätsnahe ePKA-Dokumente in den Validierungskonten eines ePA-Aktensystems und realitätsnahe E-Rezepte in den E-Rezept-Fachdienst einstellen zu können. Das Einstellen der ePKA-Dokumente und E-Rezepte erfolgt dabei in der Umgebung des jeweiligen LE-DE.

Die Erteilung der Zugriffsbefugnis des NCPeH-FD auf das ePKA-Dokument der Prüfidentität kann mittels ePA-FdV einer Krankenversicherung erfolgen, für die der Betreiber eines ePA-Aktensystems die Prüfidentität bereitstellt. Die Erteilung der Zugriffsberechtigung des NCPeH-FD auf E-Rezepte der Prüfidentität kann mittels gematik E-Rezept-App erfolgen.

Da die eHDSI im [eHDSI Test Framework] auch festlegt, dass im PET Nachweise zu durchgeführten Anpassungen bzw. zur Erfüllung von Auflagen erbracht werden können bzw. sollen, ist - je nach konkreter Situation - mit umfangreicheren Testaktivitäten und Bedarf an ePKA-Testdokumenten oder E-Rezepten zu rechnen. Demzufolge sollten friendly User LE-DE mit verschiedenen Primärsystemen und Konnektoren zum Einsatz kommen können, um unterschiedlich erzeugte ePKA-Dokumente oder E-Rezepte bereitzustellen. Je nach Situation kann dabei die Bereitstellung von Dokumenten vorbereitend erfolgen oder sie muss zum Zeitpunkt der Testdurchführung erfolgen.

Die Testdurchführung ist mit dem Betrieb der gematik abzustimmen. Insbesondere die Sicherstellung der Verfügbarkeit der TI Produkte und passenden Produktversionen ist hier relevant.

Abbildung 5: Schematischer Aufbau für den Produktivtest des NCPeH-FD mit der eHDSI

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 [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 Management-Schnittstelle in einem 4-Augen-Prinzip. Diese enthaltenen Informationen (Service Metadata) über die angebotenen Dienste des NCPeH-FD in der eHDSI. Die Systemadministratoren MÜSSEN in der Lage sein, die Service Metadata anderen Teilnehmern (NCPeH Land-B) zur Verfügung zu stellen. 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 Zertifikate, aber auch Angaben für LE-EU zur Identifizierung von Versicherten aus Deutschland im Ausland. Die Systemadministratoren MÜSSEN die Service Metadata auf dem zentralen Configuration Service der eHDSI hochladen bzw. 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 Management-Schnittstelle liegt in Hoheit des Anbieters des NCPeH-FD (Siehe [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 [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 Management-Schnittstelle 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 Management-Schnittstelle liegt in Hoheit des Anbieters des NCPeH-FD (Siehe [1.4 Abgrenzungen] und [2 Systemüberblick]).

6 Funktionsmerkmale

6.1 eHDSI

6.1.1 Operation Cross_Gateway_Patient_Discovery::RespondingGateway_PRPA_IN201305UV02

Tabelle 37: TAB_NCPeH_Cross_Gateway_Patient_Discovery

Die Zuordnung von IHE XCPD-Anfragen zu passenden Anwendungsszenarien MUSS anhand des root-Attributs aus dem livingSubjectID/value-Element erfolgen. Es MUSS das livingSubjectID/value-Element genutzt werden, in dem der Zugriffscode enthalten ist, mit dem der LE-EU vom Versicherten zum Zugriff auf die demographischen Versichertendaten berechtigt worden ist. Der NCPeH-FD MUSS in der Lage sein, anhand der IHE XCPD-Anfrage und den Kriterien aus der Tabelle TAB_NCPeH_Kriterien_Zuordnung_IHE_XCPD-Anfragen_zu_Anwendungsszenarien eindeutig das Anwendungsszenario zu adressieren. Darüber hinaus MUSS er den richtigen TUC aufrufen, in dem die Anfrage weiterbearbeitet wird.

Tabelle 38: TAB_NCPeH_Kriterien_Zuordnung_IHE_XCPD-Anfragen_zu_Anwendungsszenarien 

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] 
• [4.1.8 Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] 
• [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_PSA erfüllen.

Tabelle 39: TAB_NCPeH_XCPD_Prüfkriterien_PSA

Die Variablen OID_KVNR_ASSIGNING_AUTHORITY und OID_AC_ePKA_ASSIGNING_AUTHORITY sind im [4.1.1 Konfigurationsparameter] 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 40: TAB_NCPeH_XCPD_Prüfschritte_Fehlermeldungen_PSA

Hinweis: Die Variablen ida_healthcare_facility_type_code, ida_name-id, ida_practitioner_role und ida_point_of_care sind im [4.1.5 - Validierung der Identity Assertion des LE-EU] 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 [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 [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 [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 [4.1.1 Konfigurationsparameter] 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_namenszusatz patient_vorsatzwort patient_nachname
  birthTime	patient_geburtsdatum Die Vorgaben zum Datumsformat MÜSSEN gemäß [IHE_XCPD_Profile] 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

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.1 - Konfigurationsparameter]
• [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.7 - Non-Repudiation und Audit Trail Schemas]
• [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI]
• [4.1.9 Format und Validierung der KVNR]
• [4.2.1 - Schnittstellen zu Diensten der zentralen TI]
• [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 die XCPD-Anfrage zwei livingSubjectID-Elemente und die zugehörigen Attribute die Prüfkriterien aus der Tabelle "TAB_NCPeH_XCPD_Prüfkriterien_ePeD-A" erfüllen.

Tabelle 41: TAB_NCPeH_XCPD_Prüfkriterien_ePeD-A

Die Variablen OID_KVNR_ASSIGNING_AUTHORITY und OID_AC_eRp_ASSIGNING_AUTHORITY sind im [4.1.1 - Konfigurationsparameter] definiert.

Die KVNR und der Zugriffscode werden 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. 

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

Tabelle 42: TAB_NCPeH_XCPD_Prüfschritte_Fehlermeldungen_ePeD-A

Hinweis: Die Variablen ida_healthcare_facility_type_code, ida_name-id, ida_practitioner_name, ida_practitioner_role und ida_point_of_care sind im [4.1.5 - Validierung der Identity Assertion des LE-EU] definiert.

Das folgende Beispiel eines Patient Demographics Query Request stellt das IHE XCPD-Profil des Interaktionstyps HL7 PRPA_IN201305UV02 dar. Die Nachricht enthält eine Krankenversichertennummer (KVNR) sowie einen Zugriffscode. Aus Gründen der Übersichtlichkeit enthält das Beispiel in dem soapenv:Header-Element keine Angaben zum Sicherheitsobjekt (Assertion), (siehe [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_erp

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

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.3 - eHDSI Basisleistungen]
• [4.1.7 - Non-Repudiation und Audit Trail Schemas] 

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 MUSS der NCPeH-FD folgende Vorgaben umsetzen:

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

1. den Wert des Parameters patient_kvnr,
2. den senkrechte Strich ohne Anführungszeichen: "|",
3. den Wert des Zugriffscode aus der XCPD-Anfrage, zwischengespeichert in der Variable xcpd_accesscode_erp (siehe [6.1.1.3 TUC_NCPeH_023: Patient Demographics Query Request für ePeD-A verarbeiten]).
   
   Beispiel für den gesamten Wert des Attributs patient/id@extension:  B123456789|A2C4E6

• patient/id@root muss den Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY enthalten (siehe [4.1.1 - Konfigurationsparameter]).

• Der NCPeH-FD MUSS die ermittelten demographischen Versichertendaten aus dem [6.2.4 TUC_NCPeH_035: Demographische Versichertendaten aus E-Rezept extrahieren] den untergeordneten Elementen des patientPerson-Elements entsprechend folgender Regelungen zuordnen:
  

Die Variablen patient_kvnr, patient_vorname, patient_prefix, patient_namenszusatz, patient_vorsatzwort, 
patient_nachname und patient_geburtsdatum sind im [6.2.4 TUC_NCPeH_035: Demographische Versichertendaten aus E-Rezept extrahieren] 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.2 Operation Cross_Gateway_Query::FindDocuments

Tabelle 43: TAB_NCPeH_Cross_Gateway_Queries

Die eHDSI klassifiziert die Anwendungsszenarien bzw. Dokumentenklassen auf der Grundlage von so genannten semantischen Signifiers. Daher MUSS der NCPeH-FD in der Lage sein, die auf LOINC-Codes abgebildeten semantischen eHDSI-Signifiers aus der XCA.FindDocuments-Anfrage (siehe XDSDocumentEntryClassCode) eindeutig zu erkennen, um sie dem entsprechenden Anwendungsszenario zuordnen zu können. In der Anfrage MUSS die Information über das Klassifikationsschema des Signifiers mit der OID 2.16.840.1.113883.6.1 identisch sein. Der Wert des Parameters XDSDocumentEntryClassCode MUSS folgendem Format entsprechen:

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

Die folgende Tabelle enthält Kriterien für die Zuordnungen von IHE XCA-Anfragen zu den entsprechenden TUCs, in denen die Anfragen durch den NCPeH-FD weiterverarbeitet werden.

Tabelle 44: TAB_NCPeH_Kriterien_Zuordnung_IHE-XCA.Query_Anfragen_zu_Anwendungsszenarien 

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] 
• [4.1.8 Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] 
• [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 dem [4.1.1 Konfigurationsparameter]
   
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 [4.1.6 Validierung der TRC Assertion]) sein
• Der in dem Parameter enthaltene Zugriffscode muss identisch mit dem Wert der Variable trc_accesscode (siehe [4.1.6 Validierung der TRC Assertion]) sein
• Die im Parameter enthaltene OID muss identisch mit dem Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY (siehe [4.1.1 Konfigurationsparameter]) 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

Hinweis: Die Initiierung der Variablen ida_healthcare_facility_type_code, ida_name-id, ida_practitioner_role und ida_point_of_care erfolgt im [4.1.5 Validierung der Identity Assertion des LE-EU] und die Variablen
trc_kvnr und trc_accesscode im [4.1.6 Validierung der TRC Assertion].

Das folgende Beispiel zeigt die Struktur der Cross Gateway Query Anfrage: 

Ausgabeparameter des TUC

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

• KVNR
• Zugriffscode

6.1.2.2 TUC_NCPeH_004: Cross Gateway Query 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 NCPeH-FD MUSS die Inhalte und Struktur der XCA.Query-Antwort nach Vorgaben aus [eHDSI_XCA_Profile#2.2] umsetzen. Zusätzlich müssen Vorgaben gemäß [ebRIM_Representation_DocumentEntry#4.2.3.2] zur Erstellung von DocumentEntry-Elementen und -Attributen beachtet werden.

Der NCPeH-FD MUSS für das ePKA MIO des Versicherten zwei ExtrinsicObject-Elemente erstellen. Das eine ExtrinsicObject-Element MUSS das Name-Subelement mit dem Wert "Patient Summary PDF/A document" enthalten. Das zweite ExtrinsicObject-Element MUSS das Name-Subelement mit dem Wert "Patient Summary coded document" enthalten. Darüber hinaus MÜSSEN in beiden ExtrinsicObject-Elementen für Subelemente die Nutzungskonventionen gemäß der Tabelle Nutzungskonvention_Erstellung_XCA.Query-Response_PS beachtet werden.

Tabelle 46: TAB_NCPeH_Nutzungskonvention_Erstellung_XCA.Query_Response_PS-A

Der NCPeH-FD MUSS Vorgaben aus [eHDSI_XCA_Profile#2.2.1] zur Erstellung von ebRIM-Assoziations-Elementen in der Query-Response erfüllen. Der Wert des sourceObject-Attributs MUSS den Wert des id-Attributs des jeweiligen ExtrinsicObject-Elementes enthalten.

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

Das folgende Beispiel stellt die Struktur und Inhalte einer Query-Response dar:

Ausgabeparameter des TUC

• Dieser TUC hat keine Ausgabeparameter.

6.1.2.3 TUC_NCPeH_025: Cross Gateway Query Request für ePeD-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 - Non-Repudiation und Audit Trail Schemas]
• [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI]
• [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 aus [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 ist inhaltlich nach der folgenden Vorschrift strukturiert:

1. "'",
2. der unveränderbare Teil der KVNR des Versicherten (10 Stellen),
   Der Wert MUSS gemäß den Vorgaben im [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 [4.1.1 - Konfigurationsparameter],
   
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 sein (siehe [4.1.6 - Validierung der TRC-Assertion]).
• Der in dem Parameter enthaltene Zugriffscode muss identisch mit dem Wert der Variable trc_accesscode sein (siehe [4.1.6 - Validierung der TRC-Assertion]).
• Die im Parameter enthaltene OID muss identisch mit dem Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY sein (siehe [4.1.1 - Konfigurationsparameter]).

Der NCPeH-FD MUSS bei der Prüfung des Parameters XDSDocumentEntryClassCode auf folgende Prüfkriterien achten:

• Der classCode MUSS den Wert 57833-6 enthalten.
  Der Wert 57833-6 ist ein Code aus dem Codesystem LOINC und hat den Display Name "Prescription for medication" (siehe [LOINC_ePrescription]). classCode DARF andere Codes NICHT enthalten.
• Das Klassifikationsschema MUSS die OID 2.16.840.1.113883.6.1 enthalten. Die OID referenziert auf das Kodiersystem LOINC.
• Der Parameter MUSS mit dem folgendem Wert identisch sein:
  ('57833-6^^2.16.840.1.113883.6.1').

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 47: TAB_NCPeH_XCA_QUERY_ePeD-A_Fehlerbedingungen_Fehlercodes