Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation NCPeH-Fachdienst

    

     

      
Version
      
1.6.0
     
     

      
Revision
      
950941
     
     

      
Stand
      
15.07.2024
     
     

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

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 A und Land B.
• 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-Fachdienst 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 Standablauf besteht aus Aktivitätsschritten, die auf "Technische Use Cases" (TUC) verweisen. Die TUCs sind im Kapitel 6 Funktionsmerkmale beschrieben. Die TUCs sind eigene modulare Funktionsmerkmale bzw. Verantwortungsbereiche, die von verschiedenen Anwendungsfällen oder anderen TUC wiederverwendet werden können. In diesen Verantwortungsbereich greifen keine anderen Funktionsmerkmale (TUC) ein.

TUCs werden im Dokument nach folgendem Muster dargestellt:

<TUC_NCPeH_XXX>: <Titel des TUC>

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

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

1.5.3 Anforderungen

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

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

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

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

2 Systemüberblick

Der NCPeH-FD ermöglicht Versicherten ihre Gesundheitsdaten in andere europäische Mitgliedsstaaten mitzunehmen und sie dort mit behandelnden Leistungserbringer zu teilen. Der NCPeH-FD ist in seiner Rolle als Service Provider beteiligt an der europäischen eHealth-Infrastruktur (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 Leistungserbringern 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.

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
• 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 auf. Die Anfragen des NCPeH-FD zur Initiierung und Durchführung des Authentifizierungsprozesses werden von ePA an den IDP-Dienst delegiert. 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.

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.8 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äß Kapitel 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 Kapitel 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_

Nach Versand der Fehlermeldung an das NCPeH Land-B MUSS der NCPeH-FD gemäß [eHDSI_Audit_Trail_Profile#1.2.3] 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 Kapitel 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 Kapitel 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.8 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 Kapitel 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 Kapitel 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.
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äß Kapitel 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 Kapitel 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 Kapitel 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äß Kapitel 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äß Kapitel 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 Kapitel 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äß Kapitel 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 Kapitel 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 Kapitel 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äß Kapitel 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äß Kapitel 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 C.FD.TLS-S des jeweiligen Fachdienstes gemäß der entsprechenden Rolle aus [gemSpec_OID#GS-A_4446-*] 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 6.2.2 TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen den Wert ITI-39
• bei 6.2.1 TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen den Wert ITI-38.

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 C.FD.TLS-S des jeweiligen Fachdienstes der TI und mit der entsprechenden Rolle des Fachdienstes gemäß Festlegung aus [gemSpec_OID#GS-A_4446-*] 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.2 TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen den Wert ITI-39
• bei 6.2.1 TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen den Wert ITI-38.

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 in beiden Elementen den Wert nach folgender Vorschrift enthalten:

1. Identifier der angeforderten Gesundheitsdaten (für das ePKA-MIO ist der Wert aus der Variable METADATA_ePKA_MIO_uniqueId zu übernehmen, siehe 6.1.3.1 TUC_NCPeH_005: Cross Gateway Retrieve Request zur Abfrage der Patient Summary CDA Level 3 verarbeiten )
2. "^"
3. Das entsprechende Kürzel für die grenzüberschreitende Fachanwendung (z.B. PS für Patient Summary), gefolgt von einer Endung ".XML" oder ".PDF"
   
   Beispiel: "PS.XML" oder "PS.PDF"
   
   Nutzungsvorschrift:  Die Endung aus dem Eingangsparameter DocumentUniqueId der XCA-Anfrage MUSS mit dem Wert im Schritt 3 identisch sein.

Beispiel: ParticipantObjectID="1.2.84.116.1.800.254.370.349.563.1605.469.534.1338^PS.XML"

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

Beim Aufbau von TLS-gesicherten Verbindungen zu Diensten der TI über das zentrale Netz der TI MUSS der NCPeH-FD die Vorgaben zur sicheren Nutzung von TLS aus:

• [gemSpec_Krypt] in Kapitel 3.3.2 "TLS-Verbindungen" allgemein,
• [gemSpec_Krypt] Kapitel 3.15.3 "ePA-spezifische TLS-Vorgaben" ergänzend für den Zugriff auf Dienste der ePA-Aktensysteme und
• [gemSpec_PKI] Kapitel 8.4.1 "TLS-Verbindungsaufbau"

umsetzen.

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.

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

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 richtige Zertifikatstyp C.FD.SIG enthalten ist. Das 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. Darüber hinaus MUSS der NCPeH-FD 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.

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. 

Hinweis: Der genaue Aufbau des Discovery Documents ist in [gemSpec_IDP_Dienst#Aufbau des Discovery Document] zu finden.

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 den Kapiteln 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 2: 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 Kapitel 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 Kapitel 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 und im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa angeben.

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#Kapitel 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 Kapitel 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 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äß 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 den bestehenden VAU-Kanal gemäß Vorgaben in 4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem schließen. Der NCPeH-FD MUSS das Element Reason/Text gemäß [eHDSI_Messaging_Profile#6.2.1] mit der Fehlernachricht "An error occurred during communication with the national identity provider." befüllen.

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 den Kapiteln 4.2.2 TLS-Verbindungsaufbau zu Diensten der TI 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 Kapitel 4.2.7.7 Authentifizierung mit dem ePA Authorization Service).

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

• Angaben zu Service-Endpunkten des ePA-Aktensystems, in dem das Aktenkonto des Versicherten gehalten wird (siehe 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 Kapitel 4.1.5 Validierung der Identity Assertion des LE-EU,
• Interne Variablen aus Kapitel 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 Kapitel 4.2.7.2 Interne Aktenkontosession für einen Versicherten) abspeichern.  

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

Tritt der Fehler im Kontext von Anwendungsfall 5.1 NCPeH.UC_1 - 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 14: 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.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten, 5.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen oder 5.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. Der NCPeH-FD MUSS 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 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 Kapitel 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 Kapitel 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. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben 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 Kapitel 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 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äß 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 den bestehenden VAU-Kanal gemäß Vorgaben in 4.2.7.6 Schließen eines etablierten VAU-Kanals zum ePA-Aktensystem schließen. Der NCPeH-FD MUSS das Element Reason/Text gemäß [eHDSI_Messaging_Profile#6.2.1] mit der Fehlernachricht "It was not possible to localise the patient's health record account in the national electronic health record system." befüllen.

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) 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 15: 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 Kapitel 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 16: 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 Kapitel 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 Kapitel 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.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.

4.3.1 Datenschutzrechtliche- und informationssicherheitstechnische Anforderungen an die Vertrauenswürdige Ausführungsumgebung

In diesem Abschnitt werden die Anforderungen an den NCPeH-Fachdienst zur Umsetzung einer Vertrauenswürdigen Ausführungsumgebung (VAU) gestellt. Die VAU dient der datenschutzrechtlich zulässigen und sicheren Verarbeitung von schützenswerten unverschlüsselten Daten innerhalb des 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-Fachdienst 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-Fachdienst 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#Kapitel 3.6.3 näher beschrieben. Weitere Referenzen finden sich in Kapitel 6.3 "Country Service Desk" des [eHDSI_Operations_Framework] und in den Kapiteln 03.01 sowie 03.02 des [eHDSI_Requirements_Catalogue].

Der Anbieter des NCPeH-FD DARF nachfolgende Nutzerkreise gemäß [Kapitel6.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-Fachdienst 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-Fachdienst, 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-Fachdienst und den Betreiber zu erfüllenden Anforderungen hinsichtlich der Erfassung und Lieferung von Rohdaten an die gematik, werden in gemSpec_Perf#Rohdaten-Performance-Reporting Spezifika NCPeH-Fachdienst  dargestellt.

Der Betreiber muss sicherstellen, dass die vom NCPeH-Fachdienst 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-Fachdienst 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-Fachdienst verarbeitet werden, welche keine Rückschlüsse auf personenbezogene Informationen in den zur Verfügung gestellten Daten zulässt.

Der NCPeH-Fachdienst 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 eHDSI-Kennzahlen ist 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 Berichtsintervalles 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 Berichtsintervalles 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-Fachdienst. 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 17: 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 18: 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 19: 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-Fachdienst 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-Fachdienst. 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-Fachdienst 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.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 des Anwendungsszenarios "Patient Summary 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 des Anwendungsszenarios "Patient Summary 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.

4.5.2 Bereitstellung von Testobjekten des NCPeH-FD in der TI

Im Rahmen der Entwicklung des Anwendungsszenarios Patient Summary Land A sind integrative Tests mit den daran beteiligten Produkten der TI (NCPeH-FD, ePA FdV, ePA-Aktensystem, 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 Anwendung ePA - 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]. Die konkret umzusetzenden Anforderungen sind im [gemProdT_NCPeH_FD] aufgeführt.

4.5.3 Testspezifische Funktionen im NCPeH-FD

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

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

Als weiterführende Information siehe auch [gemSpec_Aktensystem_ePAfueralle#3.18.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).

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 die Triggerschnittstelle 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 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 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 der Umgebung TU sichergestellt werden (z. B. zum Ausschluss von eventuellen Wartungsphasen des ePA-Aktensystems). 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, 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 des Szenarios anzustoßen, die die integrativen Aktivitäten mit den Produkten der TI auslösen. Dies sind primär die Anwendungsfälle, die in den Kapiteln 5.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren, 5.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten, 5.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen und 5.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen beschrieben sind. Um den verschiedenen Interessenten 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.

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

Die Primärsystemsimulation wird zusammen mit der Konnektor Service Plattform KSP von der gematik bereitgestellt. Sie soll vor Allem die Möglichkeit bieten, in einem testvorbereitenden Schritt jeweils ein spezifisches, zum Testfall passendes ePKA-Dokument im ePA-Aktensystem einzustellen (automatisiertes Testdatenmanagement für Testdokumente).

Ein Test-FdV muss für die Berechtigung des NCPeH-FD zum Einsatz kommen. Wenn die Mechanismen zur Berechtigung des NCPeH-FD in der ePA-Anwendung einsatzbereit sind, wird eine NCPeH-FD-Identität mit Repräsentation eines EU-Landes berechtigt. Vor diesem Zeitpunkt kann mit einer 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.18.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 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.

Der mögliche Aufbau der Testumgebung für Testaktivitäten der gematik in der TU wird in der folgenden Grafik schematisch dargestellt.

Abbildung 4 Schematischer Testaufbau für den integrativen Test der gematik mit der Telematikinfrastruktur

Der größte Unterschied im schematischen Aufbau ergibt sich aus den unterschiedlichen Lokationen der Umgebungen. Dies führt zu der Notwendigkeit, das NCPeH-Testinterface über das Internet erreichbar zu machen.

Ein ähnlicher Aufbau ergibt sich für die Hersteller der ePA-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.

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 und der Usability des Gesamtablaufs aus Sicht des europäischen Leistungserbringers. Die Forderung der eHDSI nach verschiedenen, realitätsnahen Dokumenten macht es wiederum notwendig, unterschiedliche ePKA-Dokumente im ePA-Aktensystem bereitstellen zu können. Hierfür sollen Komponenten aus dem Testaufbau der TU wiederverwendet werden (Dokument einstellen via KSP).

Der PPT MUSS in der TU stattfinden, um die Anforderung der eHDSI an reife, produktionsnahe nationale Produkte sicherzustellen. Typischer Weise sollten dazu die Produkte in der TU bereits eine Zulassung durch die gematik erreicht haben. Die Sicherstellung der Verfügbarkeit der TI-Produkte in der TU 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 (z. B. zum Einstellen unterschiedlicher ePKA-Dokumente und Berechtigungserteilung via FdV).

Der mögliche Aufbau der Testumgebung zur Prüfung der Konformität und Interoperabilität mit der eHDSI wird in der folgenden Grafik schematisch dargestellt.

Abbildung 5 Schematischer Testaufbau für den Konformitätstest des NCPeH-FD mit der eHDSI

Spätestens für die Prüfung der Usability des Gesamtablaufes durch einen europäischen Leistungserbringer wird eine Integration von NCPeHs Land B mit dem NCPeH-FD über das Netzwerk TESTA-ng durchgeführt. Daraus ergibt sich folgender schematischer Aufbau.

Abbildung 6 Schematischer Testaufbau für den Funktionstest des NCPeH-FD mit der eHDSI

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

Die DVKA MUSS sich um LE-DE kümmern, um für den PET realitätsnahe ePKA-Dokumente in den ePA Validierungskonten einstellen zu können. Das Einstellen der ePKA-Dokumente erfolgt dabei in der Umgebung des jeweiligen LE-DE.

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 zu rechnen. Demzufolge sollten friendly User LE-DE mit verschiedenen Primärsystemen und Konnektoren zum Einsatz kommen können, um unterschiedlich erzeugte Dokumente in der ePKA bereitzustellen. Je nach Situation kann dabei die Bereitstellung von ePKA-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 7 Schematischer Aufbau für den Produktivtest des NCPeH-FD mit der eHDSI

5 Fachliche Anwendungsfälle

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

5.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten

5.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen

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

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

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

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

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

5.6 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 Kapitel 1.4 Abgrenzungen und 2 Systemüberblick).

5.7 NCPeH.UC_7 - MTC vom eHDSI Terminology Service herunterladen

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

5.8 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 Kapitel 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 Kapitel 1.4 Abgrenzungen und 2 Systemüberblick).

6 Funktionsmerkmale

6.1 eHDSI

6.1.1 Operation Cross_Gateway_Patient_Discovery::RespondingGateway_PRPA_IN201305UV02

Tabelle 27: 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 28: 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.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

Die Anfrage MUSS dem Nachrichtentyp Patient Registry Find Candidates Query entsprechen, wie er in [eHDSI_XCPD_Profile#2.1] beschrieben ist. Neben den Vorgaben aus [eHDSI_XCPD_Profile] gelten darüber hinaus folgende Einschränkungen, die vom NCPeH-FD zu prüfen sind:

Die root-Attribute der folgenden Elemente aus der Anfrage MÜSSEN identisch mit dem Wert des Konfigurationsparameters HOME_COMMUNITY_ID_NCPeH-FD (siehe Kapitel 4.1.1 Konfigurationsparameter) sein:

Der NCPeH-FD MUSS überprüfen, ob der Wert des root-Attributes des Elementes PRPA_IN201305UV02/sender/device/id im Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B (siehe Kapitel 4.1.1 Konfigurationsparameter) als HomeCommunityId des NCPeH Land-B enthalten ist. Dadurch soll sichergestellt werden, dass die Anfrage tatsächlich von einem NCPeH Land-B stammt, mit dem ein Austausch von Gesundheitsdaten zulässig ist. Falls die Überprüfung der Werte nicht zu einem Treffer geführt hat, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B gemäß mit einer entsprechenden Fehlernachricht gemäß Tabelle TAB_NCPeH_XCPD_Prüfschritte_Fehlermeldungen_PSA antworten.

Der NCPeH-FD MUSS überprüfen, ob die XCPD-Anfrage zwei livingSubjectID-Elemente gemäß Tabelle TAB_NCPeH_XCPD_Prüfkriterien_PSA enthält und ob die zugehörigen Attribute die Prüfkriterien gemäß Tabelle TAB_NCPeH_XCPD_Prüfkriterien_PSA erfüllen.

Tabelle 29: TAB_NCPeH_XCPD_Prüfkriterien_PSA

Die Variablen OID_KVNR_ASSIGNING_AUTHORITY und OID_AC_ePKA_ASSIGNING_AUTHORITY sind im Kapitel 4.1.1 Konfigurationsparameter definiert.

Die KVNR wird 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 mit einer weiteren Verarbeitung der Anfrage abbrechen:

Tabelle 30: TAB_NCPeH_XCPD_Prüfschritte_Fehlermeldungen_PSA

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

Ausgabeparameter des TUC

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

• xcpd_kvnr
• xcpd_accesscode_epka

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

Für diesen TUC gelten folgende übergreifende Festlegungen

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

Ablauf des TUC

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

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

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

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

• patient/id@root MUSS den Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY aus dem Kapitel 4.1.1 Konfigurationsparameter enthalten

• Der NCPeH-FD MUSS die ermittelten demographischen Versichertendaten aus dem Kapitel 6.2.3 TUC_NCPeH_017: Demographische Versichertendaten aus NFD des ePKA MIO übernehmen den untergeordneten Elementen des Elements <patientPerson /> entsprechend folgender Regelungen zuordnen:
  
  

  Element	Verwendungskonvention
  name/given	Das Element muss identisch mit dem Wert der Variable patient_vorname sein.
  name/family	Das Element muss aus einzelnen Werten der Parameter in folgender Reihenfolge bestehen, die Parameter sind durch ein Leerzeichen getrennt: patient_namenszusatz patient_vorsatzwort patient_nachname
  birthTime	Das Element muss den Wert des Parameters patient_geburtsdatum enthalten und Vorgaben zum Datumsformat gemäß [IHE_XCPD_Profile] umsetzen.

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 31: 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 32: Kriterien_Zuordnung_IHE-XCA-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.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.2 Anschluss an die Telematikinfrastruktur 

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.

Der NCPeH-FD MUSS die Variable ida_permissions aus dem Kapitel 4.1.5 Validierung der Identity Assertion des LE-EU gemäß Vorgaben aus 4.1.8 Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI prüfen.

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)
   Die Versichertenkennung aus dem Parameter ist eine 10-stellige KVNR, Format: [A-Z][0-9]{9} und hat folgenden Aufbau: 1. Stelle: Alpha-Zeichen (Wertebereich A - Z, ohne Umlaute), 2. bis 10. Stelle: 9-stellige Ziffernfolge.
3. Der senkrechte Strich ohne Anführungszeichen: "|"
4. 6-stelliger Zugriffscode
5. "^^^&amp;"
6. Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY aus dem Kapitel 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 Kapitel 4.1.6 Validierung der TRC-Assertion) sein
• Der in dem Parameter enthaltene Zugriffscode muss identisch mit dem Wert der Variable trc_accesscode (siehe Kapitel 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 Kapitel 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 33: TAB_NCPeH_XCA_QUERY_ERRORS 

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 34: Nutzungskonvention_Erstellung_XCA.Query-Response_PS

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

Ausgabeparameter des TUC

Dieser TUC hat keine Ausgabeparameter.

6.1.3 Operation Cross_Gateway_Retrieve::RetrieveDocument

Tabelle 35: TAB_NCPeH_Definition_Operation_RetrieveDocument

Der NCPeH-FD MUSS in der Lage sein, aus der IHE XCA.RetrieveDocument-Anfrage für jedes DocumentRequest-Element anhand der Kriterien aus der Tabelle TAB_NCPeH_Kriterien_Zuordnung_IHE-XCA.RetrieveDocument_Anfragen_zu_Anwendungsszenarien das passende Anwendungsszenario eindeutig zu bestimmen und die Anfrage dem entsprechenden TUC zuzuordnen, von dem aus die Anfrage weiterverarbeitet wird. 

Tabelle 36 TAB_NCPeH_Kriterien__Zuordnung_IHE-XCA.RetrieveDocument_Anfragen_zu_Anwendungsszenarien 

6.1.3.1 TUC_NCPeH_005: Cross Gateway Retrieve Request zur Abfrage der Patient Summary CDA Level 3 verarbeiten

Für diesen TUC gelten folgende übergreifende Festlegungen

• 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 

Ablauf des TUC

Der NCPeH-FD MUSS die Verarbeitung der Anfrage neben Vorgaben aus [eHDSI_XCA_Profile#2.4] auch nach folgenden Kriterien umsetzen:

Tabelle 37: TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA3

Falls es bei der Verarbeitung der Anfrage zu Fehlerfällen oder zur Verletzung der Nutzungskonvention (siehe Tabelle TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request) kommt, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit einer entsprechenden Fehlernachricht und dem Fehlercode ERROR_PS_GENERIC gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten.

Beispiel für eine XCA.Retrieve-Anfrage in der eHDSI zur Abfrage eines kodierten ePKA MIO:

Ausgabeparameter des TUC

• METADATA_ePKA_MIO_repositoryUniqueId
• METADATA_ePKA_MIO_uniqueId

6.1.3.2 TUC_NCPeH_006: Cross Gateway Retrieve Response mit Patient Summary CDA Level 3 senden

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 Antwort auf die Anfrage vom NCPeH Land-B gemäß Vorgaben aus [eHDSI_XCA_Profile#2.4] erstellen und dabei folgende Nutzungsvorgaben beachten:

Tabelle 38: TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Response_PSA_CDA3

Beispiel einer Retrieve-Response mit einem CDA-Dokument Level 3 in Base64-Kodierung.

Ausgabeparameter des TUC

• Keine

6.1.3.3 TUC_NCPeH_007: Cross Gateway Retrieve Request zur Abfrage der Patient Summary CDA Level 1 verarbeiten

Für diesen TUC gelten folgende übergreifende Festlegungen

• 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 

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äß Kapitel 4.1.7.3 Patient Privacy Audit Trail Eintrag erstellen in der Komponente Audit Repository speichern. Bei der Erstellung von Audit Trails MÜSSEN die 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 aber nachdem die Antwort an NCPeH Land-B gesendet wurde.

Der NCPeH-FD MUSS die Verarbeitung der Anfrage neben Vorgaben aus [eHDSI_XCA_Profile#2.4] auch nach folgenden Kriterien umsetzen:

Tabelle 39: TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA1

Falls es bei der Verarbeitung der Anfrage zu Fehlerfällen oder zur Verletzung der Nutzungskonvention (siehe Tabelle TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request) kommt, MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit einer entsprechenden Fehlernachricht und dem Fehlercode ERROR_PS_GENERIC gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten.

Beispiel einer XCA.Retrieve Anfrage in der eHDSI zur Abfrage des ePKA MIO eines Versicherten im PDF/A-Format:

Ausgabeparameter des TUC

• METADATA_ePKA_MIO_repositoryUniqueId
• METADATA_ePKA_MIO_uniqueId

6.1.3.4 TUC_NCPeH_008: Cross Gateway Retrieve Response mit dem Patient Summary CDA Level 1 senden

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 Antwort auf die Anfrage vom NCPeH-Land B gemäß Vorgaben aus [eHDSI_XCA_Profile#2.4] erstellen und folgende Nutzungsvorschriften beachten:

Tabelle 40: TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Response_PSA_CDA1

Beispiel einer Retrieve-Response mit einem CDA-Dokument embedded PDF/A Level 1 in Base64-Kodierung.

Ausgabeparameter des TUC

• Keine

6.1.3.5 TUC_NCPeH_009: NFD des ePKA MIO transkodieren und transformieren

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.7.4 Translation Audit Trail Eintrag erstellen  

Ablauf des TUC

Um die medizinischen Versichertendaten in das eHDSI CDA Pivotformat Level 3 umwandeln zu können, ist es bei diesem TUC erforderlich, dass der NFD des ePKA MIO des Versicherten im Klartext vorliegt. Der NCPeH-FD DARF die DPE-Daten aus dem ePKA MIO (siehe Komposition KBV_PR_MIO_DPE_Composition_DPE) NICHT verarbeiten oder daraus Versichertendaten beziehen.

Für eine erfolgreiche Transkodierung des NFD des ePKA MIO muss der NCPeH-FD den MTC inkl. Transkodierungs- bzw. Mappingdaten enthalten, die die Verbindungen zwischen Konzepten in verschiedenen Codesystemen definieren. Die Transkodierungsregeln definieren konkrete Assoziationen zwischen Konzepten, die in ePKA MIO verwendet werden und Konzepten, die zu Value Sets im MVC gehören. Sie legen fest, wie ein Code in einem bestimmten Codesystem, welches im ePKA MIO verwendet werden darf, auf einen anderen Code in einem anderen Codesystem gemäß MVC (siehe [eHDSI_MVC]) abgebildet wird. Das Vorgehen zum Herunterladen der korrekten Version des MTC vom zentralen eHDSI Configuration Service ist im Kapitel 5.7 NCPeH.UC_7 - MTC vom eHDSI Terminology Service herunterladen beschrieben.

Der NCPeH-FD MUSS anhand der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD aus ePKA MIO die Transformierung und Transkodierung durchführen. Alle anderen Inhalte des FHIR-Bundle ePKA MIO DÜRFEN NICHT für Zwecke der grenzübergreifenden Übertragung oder internen Verarbeitung verwendet werden.

Der NCPeH-FD MUSS zur Transformierung der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD in das eHDSI Patient Summary CDA Pivotformat Level 3 die Vorgaben gemäß [eHDSI_CDA_Format] umsetzen und dabei das CDA Document Template "eHDSI Patient Summary" verwenden. Die Identifizierung von relevanten strukturierten Elementen aus der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD und die Umwandlung dieser in das eHDSI Patient Summary CDA Pivotformat Level 3 unter Anwendung von Transkodierungsregeln MUSS der NCPeH-FD nach Vorgaben der BfArM umsetzen.

Nach erfolgreicher Transformierung und Transkodierung MUSS der NCPeH-FD das neu erstellte CDA-Dokument gemäß Schema und Schematrons für Patient Summary Document (CDA-Level 3) aus [eHDSI_CDA_Format] validieren.

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

Ausgabeparameter des TUC

• Strukturierte Inhalte der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD im eHDSI Patient Summary CDA Pivotformat Level 3

6.1.3.6 TUC_NCPeH_010: NFD des ePKA MIO ins PDF/A-Format transformieren

Für diesen TUC gelten folgende übergreifende Festlegungen 

• 4.1.7.4 Translation Audit Trail Eintrag erstellen  

Ablauf des TUC

Der NCPeH-FD MUSS anhand der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD aus dem ePKA MIO die Transformierung ins PDF/A-Format durchführen. Alle anderen Inhalte des FHIR-Bundle ePKA MIO DÜRFEN vom NCPeH-FD NICHT für Zwecke der grenzübergreifenden Übertragung oder internen Verarbeitung verwendet werden. Der NCPeH-FD DARF die DPE-Daten aus dem ePKA MIO (siehe Komposition KBV_PR_MIO_DPE_Composition_DPE) NICHT verarbeiten oder daraus relevante Versichertendaten beziehen.

Der NCPeH-FD MUSS zur Transformierung der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD in das eHDSI CDA embedded PDF/A Pivotformat Level 1 nach Vorgaben gemäß [eHDSI_CDA_Format] umsetzen und dabei das CDA Document Template "eHDSI Patient Summary PDF embedded" verwenden. Die Transformierung von Daten aus der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD in das eHDSI CDA embedded PDF/A Pivotformat Level 1 MUSS der NCPeH-FD nach Vorgaben der BfArM umsetzen.

Nach erfolgreicher Transformierung MUSS der NCPeH-FD das neu erstellte CDA-Dokument gemäß Schema und Schematrons für Patient Summary Document (CDA Level 1) aus [eHDSI_CDA_Format] validieren.

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

Ausgabeparameter des TUC

• Inhalte der FHIR-Komposition KBV_PR_MIO_NFD_Composition_NFD im  eHDSI CDA embedded PDF/A Pivotformat Patient Summary Level 1

6.1.4 Nutzung der Schnittstelle des zentralen eHDSI Configuration Service

6.1.4.1 TUC_NCPeH_011: Service Metadata erstellen

Für diesen TUC gelten folgende übergreifende Festlegungen

Keine

Ablauf des TUC

Durch diesen TUC ermöglicht der NCPeH-FD über eine Management-Schnittstelle, den angemeldeten Systemadministratoren Service Metadata der angebotenen eHDSI-Schnittstellen des NCPeH-FD zu erstellen, zu verwalten und zu signieren. Der NCPeH-FD MUSS sicherstellen, dass der Systemadministrator und die in diesem TUC beschriebenen Abläufe von den restlichen Daten und Prozessen in der VAU isoliert sind. 

Der NCPeH-FD MUSS dem authentifizierten Systemadministrator ermöglichen, über eine Management-Schnittstelle für jeden der folgenden Dienste bzw. Interaction Pattern eine separate ServiceMetadata-Datei neu zu erstellen oder bereits im NCPeH-FD vorhandene ServiceMetadata-Dateien auszuwählen und verwalten zu können:

• Patient Identification and Authentication (XCPD)
• Request of Data (für Operationen XCA.Query und XCA.Retrieve)
• International Search Mask (für Operation ehealth-107)

Dabei MUSS der NCPeH-FD Vorgaben zur Befüllung der Service Metadata für den jeweiligen eHDSI-Dienst des NCPeH-FD aus [eHDSI_Audit_Trail_Profile#2.3.5.8] berücksichtigen. In jeder Service Metadata MUSS das Element ServiceMetadata/ServiceInformation/ParticipantIdentifier den Wert urn:ehealth:de:ncp-idp enthalten. 

Das Element ServiceMetadata/ServiceInformation/DocumentIdentifier MUSS in Abhängigkeit von dem jeweiligen Interaction Pattern folgende Angaben enthalten (für die inhaltliche Struktur des Schemas siehe [eHDSI_Service_Location_and_Capability_Lookup_Profile#3.1.4]):

Tabelle 41: TAB_NCPeH_Service_Metadata_DocumentIdentifier 

Bei der Befüllung der Service Metadata für die vom Systemadministrator ausgewählten Service Metadata müssen die Vorgaben aus [eHDSI_Service_Location_and_Capability_Lookup_Profile#3.1.4] umgesetzt werden.

Für jeden Dienst bzw. Interaction Pattern aus der oberen Tabelle MUSS in jeder Service Metadata ein ServiceMetadata/ServiceInformation/ProcessList/Process/ProcessIdentifier Element mit einem entsprechenden Wert aus der Tabelle TAB_NCPeH_SERVICE_METADATA_PROCESSIDENTIFIER erstellt werden:

Tabelle 42: TAB_NCPeH_Service_Metadata_ProcessIdentifier

Für das Interaction Pattern ISM (International Search Mask) MUSS das Attribut ProcessList/Process/ServiceEndpointList/Endpoint@transportProfile den Wert urn:ehealth:transport:none enthalten. Für andere Interaction Pattern müssen Werte für das Attribut transportProfile aus dem Kapitel [eHDSI_Service_Location_and_Capability_Lookup_Profile#3.1.4] genommen werden.

Jeder der oben genannten Interaction Pattern MUSS im Element ProcessList/Process/ServiceEndpointList/Endpoint/ServiceDescription entsprechend der folgenden Tabelle eine Bezeichnung des Dienstes enthalten:

Tabelle 43: TAB_NCPeH_Service_Metadata_ServiceDescription

Für jeden Dienst bzw. Interaction Pattern MUSS das Element ServiceActivationDate ein Datum enthalten, das den Beginn der Bereitstellung des Dienstes darstellt. Angaben zum Element ServiceExpirationDate KÖNNEN gemacht werden. Ferner SOLL für jeden Dienst bzw. Interaction Pattern entweder das Element TechnicalContactUrl mit Angaben zu einer Webseite, auf der weitere relevanten Informationen (z.B. Kontaktdaten des Anbieters des NCPeH-FD) enthalten sind, oder das Element TechnicalInformationUrl mit Angaben zu einer E-Mail-Adresse des Anbieters des NCPeH-FD befüllt werden.

Das folgende Beispiel enthält Service Metadata für den XCPD Service:

Tabelle 44: TAB_NCPeH_Service_Metadata_XCPD-Service 

Beim Interaction Pattern ISM MUSS das Element ServiceMetadata/ServiceInformation/ProcessList/Process/ServiceEndpointList/Endpoint/Extension/searchFields Angaben zur Durchführung der Versichertenidentifizierung im Ausland enthalten und damit Vorgaben zur Anwendung der International Search Mask enthalten. Der NCPeH-FD MUSS Vorgaben aus [eHDSI_Requirements_Catalogue#02.01.02] zur Erstellung der International Search Mask umsetzen. Zusätzlich MUSS der NCPeH-FD folgende Vorschrift beachten:

Tabelle 45: TAB_NCPeH_Service_Metadata_ISM 

Folgendes Beispiel stellt die inhaltliche Struktur der deutschen International Search Mask inkl. Bildmaterialien, die den LE-EU bei der Findung der Krankenversichertennummer und des Geburtsdatums auf der eGK des Versicherten unterstützen sollen:

Tabelle 46: TAB_NCPeH_International_Search_Mask

Jede Service Metadata MUSS nach Vorgaben aus [eHDSI_Service_Location_and_Capability_Lookup_Profile#3.1.4] elektronisch signiert werden. Die Signaturerstellung MUSS mittels des privaten Schlüsselmaterials des TLS-Zertifikates durchgeführt werden, welches durch die eHDSI-PKI ausgestellt wurde. Das private Schlüsselmaterial MUSS im HSM erzeugt und dort zur Signaturerstellung angewendet werden (siehe 4.1.3.5 Umgang mit Zertifikaten der eHDSI. Nur auf explizite Anforderung des Systemadministrators MUSS der NCPeH-FD die ausgewählten Service Metadata mit dem privaten Schlüsselmaterial des TLS-Zertifikats gemäß Vorgaben aus [BDX-smp-v1.0#3.6.2] signieren. Der NCPeH-FD DARF NICHT ohne Zustimmung durch einen Systemadministrator die ausgewählte Service Metadata automatisch signieren. Der Wert der Signatur MUSS im Element ServiceMetadata/ServiceInformation/Extension/Signature zusammen mit dem öffentlichen TLS-Zertifikat enthalten sein.

Ausgabeparameter des TUC

• Eine oder mehrere signierte ServiceMetadata-Dateien

6.1.4.2 TUC_NCPeH_012: Signed Service Metadata auf eHDSI Configuration Service hochladen

Für diesen TUC gelten folgende übergreifende Festlegungen

• Öffentliche Zertifikate des Configuration Service der eHDSI sind im lokalen Truststore des NCPeH-FD (siehe Kapitel 4.1.3.5 Umgang mit Zertifikaten der eHDSI)
• 4.1.3 eHDSI Basisleistungen 

Ablauf des TUC

In diesem TUC kann ein authentifizierter Systemadministrator die ausgewählten Service Metadata auf den Configuration Service der eHDSI hochladen.

Der NCPeH-FD MUSS sicherstellen, dass das Hochladen der ausgewählten und signierten Service Metadata auf dem Configuration Service der eHDSI erst dann erfolgen kann, nachdem eine präventive Kontrolle der Inhalte der Service Metadata nach dem Vier-Augen-Prinzip erfolgt ist. Die offizielle Entscheidung zum Hochladen der Service Metadata auf dem Configuration Service der eHDSI MUSS durch einen anderen authentifizierten Systemadministrator erfolgen, dessen Identität nicht mit der Identität des Systemadministrators gleichzusetzen ist, der die Service Metadata zuletzt geändert hat. Das Ziel des Vier-Augen-Prinzips ist es, das Risiko von Fehlern und Missbrauch zu reduzieren. 

Falls es im Rahmen der präventiven Kontrolle (Vier-Augen-Prinzip) zu einer Änderungen an der Service Metadata durch einen zweiten Systemadministrator kommt, wird die in der Service Metadata enthaltene Signatur unbrauchbar und die Service Metadata muss erneut signiert werden (siehe Kapitel 6.1.4.1 TUC_NCPeH_011: Service Metadata erstellen).

Das Hochladen der Service Metadata erfolgt mittels SMP/SML-Protokolls. Um auf eine Patient Summary in der eHDSI erfolgreich zugreifen zu können, muss ein NCPeH Land-B in der Lage sein, wichtige Metadaten über die Dienstendpunkte des eHDSI Service Providers (NCPeH Land-A) zu ermitteln. Daher MUSS der NCPeH-FD die Kommunikation zum eHDSI Configurations Service nach Vorgaben aus [eHDSI_Service_Location_and_Capability_Lookup_Profile] und [SMP_SML_eDelivery_BB#5] umsetzen. Nach erfolgreichem Hochladen bzw. Aktualisieren der Service Metadata auf dem eHDSI Configuration Service MUSS der NCPeH-FD dem Systemadministrator über die Management-Schnittstelle eine Erfolgsmeldung anzeigen. 

Falls die Service Metadata aufgrund eines Kommunikationsfehlers mit dem eHDSI Configuration Service nicht veröffentlicht bzw. aktualisiert werden können, MUSS der NCPeH-FD über die Management-Schnittstelle dem Systemadministrator die Fehlerdetails, Fehlercode und -beschreibung gemäß vorgegebenen Standards in [eHDSI_Service_Location_and_Capability_Lookup_Profile#3.1.1] anzeigen.

Der NCPeH-FD MUSS nach Veröffentlichung bzw. Aktualisierung einer Service Metadata auf dem eHDSI Configuration Service einen Audit Trail Eintrag nach Vorgaben aus Kapitel 4.1.7.5 Security Audit Trail Eintrag erstellen erstellen und in das lokalen Audit Repository speichern.

Ausgabeparameter des TUC

Keine

6.2 Telematikinfrastruktur

6.2.1 TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.2.1 Schnittstellen zu Diensten der zentralen TI 
• 4.2.7.1 TLS-Verbindungsaufbau zum ePA-Aktensystem 
• 4.2.7.2 Interne Aktenkontosession für einen Versicherten 
• 4.2.7.3 Lokalisierung der Akte eines Versicherten 
• 4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem 
• 4.2.7.5 Nutzung eines etablierten VAU-Kanals zum ePA-Aktensystem 
• 4.2.7.7 Authentifizierung mit dem ePA Authorization Service 
• 4.2.7.8 Adressierung des Aktenkontos 
• 4.2.8 Befüllung von SOAP Header Elementen für Zugriff auf ePA XDS Document Service 
• 4.2.9 Elektronische Identitäten des NCPeH-FD 

Ablauf des TUC

Zur Ermittlung von demographischen Versichertendaten oder medizinischen Daten des Versicherten ist es notwendig, zuerst die UniqueID des FHIR-Bundles des ePKA MIOs vom XDS Document Service des in der Aktenkontosession zugeordneten ePA Aktensystems zu ermitteln (Metadaten).

Wenn der NCPeH-FD in einer existierenden Aktenkontosession für den Versicherten die Metadaten zu dem ePKA MIO zwischengespeichert hat, dann KANN der NCPeH-FD die benötigten Metadaten aus dieser Session als Ausgabeparameter dieses TUCs wiederverwenden (Caching der Metadaten).

Wenn der NCPeH-FD keine Metadaten des ePKA MIO aus einer Aktenkontosession nutzen kann, dann MUSS der NCPeH-FD eine Suchanfrage an den XDS Document Service senden. Der NCPeH-FD MUSS dafür die Operation I_Document_Management::RegistryStoredQuery gemäß [ITI-18] "Registry Stored Query", Query "FindDocument" nutzen. Zu weiterführenden Informationen siehe zusätzlich auch [gemSpec_Aktensystem_ePAfuerAlle#Registry Stored Query [ITI-18]].

Der NCPeH-FD agiert als "Document Consumer", während den XDS Document Service des ePA-Aktensystems eine "Document Registry" umsetzt (siehe Operation I_Document_Management::RegistryStoredQuery gemäß [gemSpec_Aktensystem_ePAfueralle]).

Der NCPeH-FD MUSS im RegistryStoredQuery-Request die Parameter wie folgt befüllen: 

• returnType = LeafClass
• AdhocQuery id = (Stored Query Id für FindDocuments gemäß [ITI-18])
• $XDSDocumentEntryPatientId = (MUSS den Identifier des Versicherten gemäß der Bildungsregel in [gemSpec_Aktensystem_ePAfueralle#A_14974-*] enthalten)
• $XDSDocumentEntryFormatCode = (MUSS den Wert des Konfigurationsparameters ePKA_MIO_FORMATCODE gemäß 4.1.1 Konfigurationsparameter enthalten)
• $XDSDocumentEntryStatus = urn:oasis:names:tc:ebxml-regrep:StatusType:Approved

Der NCPeH-FD DARF in dem RegistryStoredQuery-Request NICHT das Attribut home benutzen (keine Angabe einer homeCommunityId für das ePA Aktensystem).

Beim Einstellen des ePKA MIO in dem XDS Document Service durch einen LE kann die bestehende Version durch eine neue Version des ePKA MIO ersetzt werden. Der XDS Document Service setzt intern den Status availabilityStatus  (Metadatenattribut) für ältere Dokumente auf Deprecated und für das aktuelle Dokument auf den Wert Approved.
Durch Setzen des Parameters returnType auf LeafClass in der Anfrage soll die Liste der Suchergebnisse auf Dokumente beschränkt werden. Die Metaattribute von z.B. Verzeichnissen sollten nicht in die Liste der Suchergebnisse aufgenommen werden.

Der NCPeH-FD MUSS in die Operation RegistryStoredQuery den SOAP-Header nach 4.2.8 Befüllung von SOAP Header Elementen für Zugriff auf ePA XDS Document Service mit aufnehmen.

Nach Versand der Anfrage an das ePA-Aktensystem MUSS der NCPeH-FD einen Non-Repudiation of Origin Eintrag gemäß 4.1.7.1 Non-Repudiation of Origin erstellen in der Komponente Audit Repository speichern. 

Nach Erhalt der Antwort von dem ePA-Aktensystem 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.

Auf die gestellte Anfrage antwortet der ePA XDS Document Service mit passenden Suchergebnissen (Metadatenattribute).

Der Wert des Parameters DocumentEntry.formatCode aus der Antwort MUSS identisch mit dem Wert des Konfigurationsparameter ePKA_MIO_FORMATCODE (siehe 4.1.1 Konfigurationsparameter) sein.

Der NCPeH-FD MUSS aus der Antwort folgende DocumentEntry Metadatenattribute gemäß [IHE_ITI_TF_Vol3#4.2.3.2] extrahieren, die im Zusammenhang mit dem ePKA MIO stehen und für Zwecke der internen Datenverarbeitung verwenden:

Tabelle 47: TAB_NCPeH_Relevante_Metadatenattribute_ePKA-MIO 

Falls dieser TUC im Kontext des Anwendungsfalls 5.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren aufgerufen wird, MUSS der NCPeH-FD folgende Prüfschritte durchführen. Bei nicht erfolgreicher Ausführung der Prüfschritte MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit der Fehlernachricht bzw. Reason Encoding inkl. acknowledgementDetail antworten:

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

Folgende Anforderung gilt bei der Nutzung dieses TUC durch die Anwendungsfälle wie 5.2 NCPeH.UC_2 - Metadaten über ePKA MIO auflisten, 5.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen oder 5.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen:

Der NCPeH-FD MUSS eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit dem Fehlercode ERROR_GENERIC_DOCUMENT_MISSING gemäß [eHDSI_XCA_Profile#2.4] und [eHDSI_NCPeH_Components#6.4] antworten, falls die Antwort des ePA XDS Document Service keine Metadatenattribute des geforderten ePKA MIO enthält oder in der Antwort Metadatenattribute leer oder Angaben über andere Datensätze enthalten sind, die nicht zu ePKA MIO entsprechen oder die Vorgaben aus TAB_NCPeH_Relevante_Metadatenattribute_ePKA-MIO verletzt wurden.

Wenn der NCPeH-FD gültige Metadaten zum ePKA MIO des Versicherten gefunden hat, dann KANN er diese Daten in der internen Aktenkontosession des Versicherten und LE-EU zwischenspeichern.

Ausgabeparameter des TUC

Nach erfolgreicher Ausführung dieses TUC stehen im NCPeH-FD folgende Ausgabeparameter für die weitere Datenverarbeitung zur Verfügung:

• METADATA_ePKA_MIO_creationTime
• METADATA_ePKA_MIO_repositoryUniqueId
• METADATA_ePKA_MIO_uniqueId
• METADATA_ePKA_MIO_patientId

6.2.2 TUC_NCPeH_014: FHIR-Bundle ePKA MIO abrufen

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.7 Non-Repudiation und Audit Trail Schemas 
• 4.2.1 Schnittstellen zu Diensten der zentralen TI 
• 4.2.7.1 TLS-Verbindungsaufbau zum ePA-Aktensystem 
• 4.2.7.2 Interne Aktenkontosession für einen Versicherten 
• 4.2.7.3 Lokalisierung der Akte eines Versicherten 
• 4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem 
• 4.2.7.5 Nutzung eines etablierten VAU-Kanals zum ePA-Aktensystem 
• 4.2.7.7 Authentifizierung mit dem ePA Authorization Service 
• 4.2.7.8 Adressierung des Aktenkontos 
• 4.2.8 Befüllung von SOAP Header Elementen für Zugriff auf ePA XDS Document Service 
• 4.2.9 Elektronische Identitäten des NCPeH-FD 

Ablauf des TUC

Um die relevanten Daten (demographische oder medizinische Versichertendaten - abhängig vom jeweiligen Anwendungsfall) aus dem ePKA MIO des Versicherten abrufen zu können, MUSS der NCPeH-FD eine Anfrage an den ePA XDS Document Service über die Operation I_Document_Management::RetrieveDocumentSet (siehe [gemSpec_Aktensystem_ePAfuerAlle#RetrieveDocumentSet [ITI-43]]) gemäß [ITI-43] "Retrieve Document Set" senden. Dabei agiert der NCPeH-FD als IHE-XCA-Akteur „Document Consumer“, während den ePA XDS Document Service eine "Document Repository" umsetzt.

Der NCPeH-FD MUSS mit der Anfrage folgende Parameter senden:

• DocumentEntry.uniqueId muss den Wert aus der Variable METADATA_ePKA_MIO_uniqueId (siehe Kapitel 6.2.1 TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen) enthalten
• DocumentEntry.repositoryUniqueId muss den Wert aus der Variable METADATA_ePKA_MIO_repositoryUniqueId (siehe Kapitel 6.2.1 TUC_NCPeH_013: Metadatenattribute des ePKA MIO abrufen) enthalten.

Der NCPeH-FD MUSS in die Anfrage zur Operation RetrieveDocumentSet den SOAP-Header nach 4.2.8 Befüllung von SOAP Header Elementen für Zugriff auf ePA XDS Document Service mit aufnehmen.

Nach Versand der Anfrage an den ePA XDS Document Service 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.

Nach Erhalt der Antwort von dem ePA XDS Document Service MUSS der NCPeH-FD einen Non-Repudiation of Receipt Eintrag gemäß 4.1.7.2 Non-Repudiation of Receipt erstellen in die Komponente Audit Repository speichern.

Falls die Antwort mittels MTOM/XOP [MTOM] kodiert ist (siehe [gemSpec_Aktensystem_ePAfuerAlle#A_17832]), MUSS der NCPeH-FD die Nachricht gemäß Vorgaben aus [MTOM] mit Verweis auf [IHE-ITI-TF2x#v3.6] dekodieren können, so dass die weitere interne Verarbeitung der Nachricht möglich ist.

Die vom ePA XDS Document Service erhaltene Antwort auf die gestellte Anfrage MUSS genau ein FHIR-Bundle ePKA MIO des Versicherten im Klartext enthalten. Das zu verwendete Format des FHIR-Bundle ePKA MIO ist durch [KBV_ePKA_MIO_Format] vorgegeben. Die Spezifikation des ePKA MIO v1.0.0 ist von der mio42 GmbH auf den Webseiten der KBV unter [Simplifier_ePKA_MIO] veröffentlicht. Die Version v1.0.0 des ePKA MIO ist für die interne Datenverarbeitung im NCPeH-FD normativ. 

Der NCPeH-FD MUSS die innerhalb des FHIR-Bundles ePKA MIO mindestens die enthaltene Komposition 
KBV_PR_MIO_NFD_Composition_NFD einer FHIR-Validierung gegen die ePKA MIO Schema-Definition der KBV [Simplifier_ePKA_MIO] unterziehen, damit der nachfolgende Workflow ausschließlich auf Basis von schemakonformer Daten erfolgt. Die KBV stellt zum ePKA MIO in [Simplifier_ePKA_MIO_Validierungspakete] relevante Dateien bzw. Validierungspakete zur Verfügung, die zur Implementierung des ePKA MIO und der FHIR-Validierung benötigt werden. Die FHIR-Validierung des ePKA MIO MUSS lokal innerhalb der VAU-Umgebung im NCPeH-FD erfolgen. Der NCPeH-FD DARF NICHT das ePKA MIO an externe Dienste zur FHIR-Validierung senden. Bei Invalidität MUSS der NCPeH-FD die weitere Verarbeitung und Nutzung von Daten aus dem ePKA MIO abbrechen und dem NCPeH-FD mit einer entsprechenden Fehlernachricht gemäß Tabelle TAB_NCPeH_Abruf_ePKA-MIO_Fehlerbehandlung_Zusammenhang_PI oder TAB_NCPeH_Abruf_ePKA-MIO_Fehlerbehandlung_Zusammenhang_PS antworten.

Wenn dieser TUC im Kontext des Anwendungsfalls 5.1 NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren aufgerufen wird, MUSS der NCPeH-FD, in Abhängigkeiten von der aufgetretenen Fehlerbedingung aus Tabelle "TAB_NCPeH_Abruf_ePKA-MIO_Fehlerbehandlung_Zusammenhang_PI", eine weitere Verarbeitung der Anfrage abbrechen und mit der entsprechenden Fehlernachricht bzw. Reason Encoding inkl. acknowledgementDetail dem NCPeH Land-B gemäß [eHDSI_XCPD_Profile#2.3.3] antworten.

Tabelle 48: TAB_NCPeH_Abruf_ePKA-MIO_Fehlerbehandlung_Zusammenhang_PI 

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

Folgende Anforderung gilt bei der Nutzung dieses TUC durch die Anwendungsfälle wie 5.3 NCPeH.UC_3 - ePKA MIO des Versicherten abrufen oder 5.4 NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen:

Bei folgenden Fehlerbedingungen MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem NCPeH Land-B mit einer Fehlernachricht gemäß [eHDSI_XCA_Profile#2.4] und Tabelle "TAB_NCPeH_Abruf_ePKA-MIO_Fehlerbehandlung_Zusammenhang_PS" antworten:

Tabelle 49: TAB_NCPeH_Abruf_ePKA-MIO_Fehlerbehandlung_Zusammenhang_PS

Ausgabeparameter des TUC

• Bei Erfolg: FHIR-Bundle ePKA MIO

6.2.3 TUC_NCPeH_017: Demographische Versichertendaten aus NFD des ePKA MIO übernehmen

Für diesen TUC gelten folgende übergreifende Festlegungen

• keine

Ablauf des TUC

Die Struktur der demographischen Versichertendaten im FHIR-Bundle ePKA MIO ist in der Komposition KBV_PR_MIO_NFD_Composition_NFD durch das Profil [Simplifier_ePKA_MIO_NFD_Patient] definiert. Der NCPeH-FD DARF NICHT die DPE-Daten aus ePKA MIO (siehe Komposition KBV_PR_MIO_DPE_Composition_DPE) verarbeiten und daraus die demographischen Versichertendaten beziehen. Der NCPeH-FD MUSS folgende demographische Versichertendaten aus dem genannten Profil extrahieren und in die entsprechende Variablen abspeichern:

Das FHIR-Profil Patient im ePKA MIO [Simplifier_ePKA_MIO_NFD_Patient] lässt ein Fehlen des Geburtsdatums zu, wenn stattdessen die Extension "data-absent-reason" angegeben ist.

In diesem Fall MUSS der NCPeH-FD das Geburtsdatum in der Variablen patient_geburtsdatum so mit Nullen auffüllen, dass eine schematisch gültige Anzahl an Ziffern für das Geburtsdatum in die XCPD-Response an den NCPeH Land-B aufgenommen werden kann.

Beispiele:

• 0
• 00000000

Hinweis: Der LE-EU kann anhand dieser Information erkennen, dass das Geburtsdatum künstlich aufgefüllt wurde und muss den Wert mit dem Patienten vor Ort abklären.

Ausgabeparameter des TUC

• patient_kvnr
• patient_vorname
• patient_nachname
• patient_vorsatzwort
• patient_namenszusatz
• patient_geburtsdatum

6.3 Administration

6.3.1.1 TUC_NCPeH_018: Systemadministrator oder Prozessverantwortlicher anmelden

Für diesen TUC gelten folgende übergreifende Festlegungen

• Keine

Ablauf des TUC

Der NCPeH-FD MUSS dem Systemadministrator bzw. Prozessverantwortlichen (berechtigte Akteure) eine Management- oder technische Schnittstelle zur Verfügung stellen, über die sie IT-Aktivitäten am NCPeH-FD durchführen können. Zu den IT-Aktivitäten gehören in Abhängigkeit vom jeweiligen Anwendungsfall die Erstellung und Verwaltung von Service Metadata des NCPeH-FD auf dem Configuration Service des NCPeH-FD, die Aktualisierung von Konfigurationsparametern (siehe Kapitel 4.1.1 Konfigurationsparameter), der Abruf des aktuellen MTC vom Terminology Service der eHDSI und der Abruf von Evidence und Audit Trail Einträgen.

Die technische Ausgestaltung der Management- bzw. technischen Schnittstelle und der begleitenden Prozesse liegt in der Verantwortung des Anbieters des NCPeH-FD.

Der NCPeH-FD MUSS sicherstellen, dass sich der Akteur mindestens mit einem 2-Faktor authentisiert. Der NCPeH-FDMUSS den Kommunikationskanal mit gegenseitiger Authentifizierung zwischen der Management- bzw. technischen Schnittstelle und dem Client des Akteurs oder zu einem anderen vertrauenswürdigen System (z. B. Identity Provider) des Anbieters mittels TLS Version 1.2 oder Version 1.3 aufbauen.

Der NCPeH-FD MUSS erfolgreich authentifizierten und berechtigten Akteuren die Nutzung der administrativen Aktivitäten über die Management- bzw. technischen Schnittstelle ermöglichen. 

Der Akteur DARF KEINEN Zugriff auf die personenbezogenen Daten in der VAU haben oder andere Prozesse in der VAU beeinträchtigen.

Für die Gewährleistung der ordnungsgemäßen IT-Administration und des geforderten Sicherheitsniveaus MUSS der NCPeH-FD relevante Vorgaben aus Kapitel 4.3 Sicherheit und Datenschutz umsetzen.

Ausgabeparameter des TUC

• Identitätsangaben des authentifizierten Akteurs
  (Die Identitätsangaben dienen z. B. zur Unterscheidung von Systemadministratoren bei der Anwendung des Vier-Augen-Prinzips. Die Identitätsangaben sollen auch für Protokollierungszwecke verwendet werden.) 

6.3.1.2 TUC_NCPeH_019: Änderungen an Konfigurationsparameter planen

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.1 Konfigurationsparameter 

Ablauf des TUC

Der NCPeH-FD MUSS den authentifizierten Systemadministratoren über die Management-Schnittstelle ermöglichen, einzelne Konfigurationsparameter des NCPeH-FD (siehe Kapitel 4.1.1 Konfigurationsparameter) auszuwählen und ihre Werte zu verändern. Der NCPeH-FD DARF die veränderte Konfigurationsparameter NUR nach Durchführung des Vier-Augen-Prinzips persistieren (siehe 6.3.1.3 TUC_NCPeH_020: Änderungen an Konfigurationsparametern und im Truststore aktivieren). Bis zur Durchführung der Persistierung MUSS der authentifizierte Systemadministrator die veränderten Werte der Konfigurationsparameter im NCPeH-FD aufrufen und sie verändern können. Der NCPeH-FD MUSS sicherstellen, dass die restlichen Daten und Datenverarbeitungsprozessen in der VAU isoliert von den in diesem TUC beschriebenen Abläufen bleiben. 

Der NCPeH-FD MUSS es den authentifizierten Systemadministratoren ermöglichen, beim Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B folgende Aktivität durchzuführen:

• Der Systemadministrator erstellt einen neuen Eintrag für ein Land-B und den NCPeH Land-B. Die relevanten Informationen zum Land-B und NCPeH Land-B sind zum Zeitpunkt der Erstellung des Eintrages nicht in der Liste enthalten. Pro Land-B und NCPeH Land-B darf höchsten ein Eintrag in der Liste existieren.
• Der Systemadministrator wählt einen Eintrag für ein bestimmtes Land-B aus und ändern den Wert des Attributes HomeCommunityId des NCPeH Land-B. Dabei DARF der Systemadministrator das Attribut Ländercode NICHT verändern. 
• Der Systemadministrator wählt einen Eintrag für ein bestimmtes Land-B aus und entfernt den kompletten Eintrag aus der Liste. 

Außerdem MUSS der NCPeH-FD dem Systemadministrator über die Management-Schnittstelle ermöglichen, neue öffentliche Zertifikate des Herausgebers (Root und Intermediate), der zentralen Dienste eHDSI Configuration Service und eHDSI Terminology Service zur Installation in den lokalen Truststore einzubringen. Der Systemadministrator MUSS über die Management-Schnittstelle des NCPeH-Facdhienstes bereits im Truststore enthaltene Zertifikate des Herausgebers (Root und Intermediate), der zentralen Dienste eHDSI Configuration Service und eHDSI Terminology Service anhand den Angaben aus den Zertifikatselementen subject und validity einzeln auswählen und zur Löschung aus dem Truststore vorschlagen zu können.

Ausgabeparameter des TUC

• Identitätsangaben des Systemadministrators, der die Änderungen geplant hat
  (Die Identitätsangaben dienen z.B. zur Unterscheidung von Systemadministratoren bei der Anwendung des Vier-Augen-Prinzips)
• Liste der geplanten Änderungen

6.3.1.3 TUC_NCPeH_020: Änderungen an Konfigurationsparametern und im Truststore aktivieren

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.1 Konfigurationsparameter 
• 4.1.3.5 Umgang mit Zertifikaten der eHDSI 
• 4.1.4 Service Metadata des NCPeH Land-B abrufen 

Ablauf des TUC

In diesem TUC MUSS ein authentifizierter Systemadministrator die Konfigurationsparameter aus Kapitel 6.3.1.2 TUC_NCPeH_019: Änderungen an Konfigurationsparameter planen, die von einem anderen Systemadministrator geändert wurden, offiziell zur Aktivierung freigeben.

Der NCPeH-FD MUSS sicherstellen, dass die Aktivierung von Änderungen an den Konfigurationsparametern erst dann erfolgen kann, nachdem eine präventive Kontrolle der vorgeschlagenen Änderungen nach dem Vier-Augen-Prinzip stattgefunden hat. Die offizielle Freigabe zur Aktivierung von vorgeschlagenen Änderungen an den Konfigurationsparametern MUSS durch explizite Anforderung eines authentifizierten Systemadministrators erfolgen, dessen Identität nicht mit der Identität des Systemadministrators gleichzusetzen ist, der die Änderungen an Konfigurationsparametern zuletzt erstellt hat. Das Ziel des Vier-Augen-Prinzips ist es, das Risiko von Fehlern und Missbrauch zu reduzieren. 

Der NCPeH-FD MUSS sicherstellen, dass während der Durchführung des Vier-Augen-Prinzips keine Änderungen an den Konfigurationsparametern durch Systemadministratoren erfolgen können. Falls während der Anwendung des Vier-Augen-Prinzips vom prüfenden Systemadministrator festgestellt wird, dass die vorgeschlagenen Änderungen an den Konfigurationsparametern nicht korrekt sind, MUSS der prüfende Systemadministrator die Aktivierung von Änderungen ablehnen können und den Systemadministrator, der die Änderungen erstellt hat, auffordern die betroffenen Konfigurationsparameter zu korrigieren.

Falls der prüfende Systemadministrator die offizielle Aktivierung von Änderungen an den Konfigurationsparametern freigegeben hat, MÜSSEN vom NCPeH-FD folgende Vorgaben umgesetzt werden:

• Bei der Erstellung eines neuen Eintrages für ein Land-B im Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B MUSS der NCPeH-FD den Ländercode und die HomeCommunityId des NCPeH Land-B in den Eintrag persistieren und aktivieren. Ferner MÜSSEN die ServiceMetadata-Dateien des NCPeH Land-B vom eHDSI Configurations Service gemäß Vorgaben aus Kapitel 4.1.4 Service Metadata des NCPeH Land-B abrufen abgerufen werden. Falls die heruntergeladenen ServiceMetadata-Dateien erfolgreich auf Authentizität und Identität geprüft wurden, MÜSSEN die entsprechenden Zertifikate aus ServiceMetadata gemäß Kapitel 4.1.4 Service Metadata des NCPeH Land-B abrufen in den lokalen Truststore aufgenommen werden.
• Bei Änderungen von Einträgen in dem Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B DARF NUR die HomeCommunityId des NCPeH Land-B geändert werden. Der Ländercode aus dem Eintrag MUSS unberührt bleiben. Der NCPeH-FD SOLL an dieser Stelle die Abläufe aus dem Kapitel 4.1.4 Service Metadata des NCPeH Land-B abrufen NICHT durchführen.
• Beim Löschen eines Eintrages aus dem Konfigurationsparameter WHITELIST_NCPeH_COUNTRY-B MUSS der NCPeH-FD alle Zertifikate des betroffenen NCPeH Land-B aus dem lokalen Truststore entfernen. Zusätzlich MÜSSEN Referenzwerte gemäß Kapitel 4.1.4 Service Metadata des NCPeH Land-B abrufen aus dem NCPeH-FD gelöscht werden, die mit den Zertifikaten des NCPeH Land-B verknüpft sind.

Bei Installation und Aktivierung der öffentlichen Zertifikate des Herausgebers (Root und Intermediate), der zentralen Dienste eHDSI Configuration Service und eHDSI Terminology Service MUSS der NCPeH-FD dem prüfenden Systemadministrator Zertifikatsinhalte aus Elementen subject und validity (Gültigkeit des Zertifikats von - bis) anzeigen. Nach dem der prüfende Systemadministrator die Zertifikate zur Aktivierung freigegeben hat, MUSS der NCPeH-FD die neuen Zertifikate in den lokalen Truststore installieren und sofort aktivieren.

Bei Entfernung von ausgewählten Zertifikaten aus dem Truststore MUSS der NCPeH-FD dem prüfenden Systemadministrator Zertifikatsinhalte aus Elementen subject und validity (Gültigkeit des Zertifikats von - bis) anzeigen. Nachdem der prüfende Systemadministrator die Entfernung der Zertifikate freigegeben hat, MUSS der NCPeH-FD diese Zertifikate aus dem Truststore dauerhaft entfernen.

Nach erfolgreicher Aktivierung der geänderten Konfigurationsparameter und Zertifikaten MUSS der NCPeH-FD dem prüfenden Systemadministrator über die Management-Schnittstelle eine Erfolgsmeldung anzeigen. Falls Fehler bei der Aktivierung von geplanten Änderungen auftreten, MUSS der NCPeH-FD dem prüfenden Systemadministrator eine verständliche Fehlermeldung inkl. Fehlergrund anzeigen. 

Im Fehlerfall MÜSSEN, in den von geplanten Änderungen betroffenen Konfigurationsparametern die ursprünglichen Werte wiederhergestellt werden, die die Konfigurationsparameter vor Beginn der Aktivierung hatten. Bei Fehlern zur Installation und Aktivierung von Zertifikaten MUSS der ursprüngliche Zustand des Truststore vor der Aktivierung wiederhergestellt werden.  

Ausgabeparameter des TUC

Keine

6.3.1.4 TUC_NCPeH_021: Ausgewählte Evidence und Audit Trail Einträge ermitteln

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.7 Non-Repudiation und Audit Trail Schemas 

Ablauf des TUC

Der NCPeH-FD MUSS den authentifizierten Prozessverantwortlichen Audit Trails (Prozessverantwortlicher) über eine technische Schnittstelle ermöglichen, im Audit Repository nach Evidence- (SAR- und ARbR-Objekte) und Audit Trail-Einträgen (Patient Privacy und Translation) zu suchen und sie auszulesen. Der Prozessverantwortliche DARF andere Daten NICHT auslesen oder Datenverarbeitungsprozesse in der VAU beeinträchtigen können. 

Der NCPeH-FD MUSS die Suche nach Evidence und Audit Trail Einträgen durchführen, wenn eine der folgenden Gruppen von Parametern in der Suchanfrage des Prozessverantwortlichen enthalten ist:

• Gruppe 1: KVNR des Versicherten und Kalenderjahr oder
• Gruppe 2: KVNR des Versicherten, Identifier des Leistungserbringers (gemäß ida_name-id aus Kapitel 4.1.5 Validierung der Identity Assertion des LE-EU) und Kalenderjahr oder
• Gruppe 3: KVNR des Versicherten, Identifier der Leistungserbringerinstitution (gemäß ida_organization-id aus Kapitel 4.1.5 Validierung der Identity Assertion des LE-EU) und Kalenderjahr.

Der NCPeH-FD MUSS vor dem Suchvorgang die Suchparameter auf folgende Formatvorgaben prüfen: 

• Identifier der Leistungserbringerinstitution MUSS Vorgaben aus gemäß [eHDSI_SAML_Profile#2.3]
• Kalenderjahr MUSS dem Format YYYY entsprechen.

Falls die Suche erfolgreich war MUSS der NCPeH-FD die ermittelten Evidence im Format gemäß Vorgaben aus [eHDSI_Audit_Trail_Profile#1.2] dem anfragenden Prozessverantwortlichen bereitstellen. Dabei MUSS der NCPeH-FD die Authentizität und Integrität der Evidence sicherstellen. Die ermittelten Audit Trail Einträge aus den Suchergebnissen MÜSSEN im Dokumentenformat nach Vorgaben aus [eHDSI_Audit_Trail_Profile#2] in der Antwort an den Prozessverantwortlichen gesendet werden.

Der NCPeH-FD MUSS den authentifizierten Prozessverantwortlichen über die technische Schnittstelle ermöglichen, nach Security Audit Trail Einträgen (siehe Kapitel 4.1.7.5 Security Audit Trail Eintrag erstellen) in dem Audit Repository unabhängig von Evidence und anderen Audit Trail Einträgen zu suchen. Der NCPeH-FD MUSS dem Prozessverantwortlichen ermöglichen, unabhängig vom Kalenderjahr nach Security Audit Trail Einträgen zu suchen, da in dem Security Audit Trail Schema keine Erfassung von personenbezogene Daten vorgesehen ist und das Schema auf das Interaction Pattern Configuration Manager (siehe [eHDSI_Audit_Trail_Profile#2.3.5.7] beschränkt ist. Der NCPeH-FD MUSS die Suchanfragen nach Security Audit Trail Einträgen akzeptieren und durchführen, wenn in den Suchparametern Angaben zu Events mit Bezug auf das Interaction Pattern Configuration Manager gemäß [eHDSI_Audit_Trail_Profile#2.3.5.7] enthalten sind. Der NCPeH-FD MUSS im Erfolgsfall die Suchergebnisse über die technische Schnittstelle dem Prozessverantwortlichen auf seine Anfrage antworten.

Wenn in den Anfragen obligatorische Suchparameter fehlen, oder die Suchparameter erfüllen die oben genannten Formatvorgaben nicht oder die Suche ergibt keine Suchtreffer, MUSS der NCPeH-FD dem anfragenden Prozessverantwortlichen mit einer Fehlernachricht inkl. Fehlergrund antworten.  

Ausgabeparameter des TUC

• Suchergebnisse im Erfolgsfall: Evidence und Audit Trails oder Security Audit Trails

6.3.1.5 TUC_NCPeH_022: MTC in der VAU speichern

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.3 eHDSI Basisleistungen 
• 4.1.7.5 Security Audit Trail Eintrag erstellen

Ablauf des TUC

Dieser TUC beschreibt, wie ein neuer MTC auf Anfrage des authentifizierten Systemadministrators durch den NCPeH-FD vom Central Terminology Service (CTS) abgerufen und lokal in der VAU installiert bzw. aktiviert wird. Die Bereitstellung des MTC erfolgt über RESTful Schnittstellen des CTS. Der Betrieb des Central Terminology Service und Definition der RESTful Schnittstellen liegt im Zuständigkeitsbereich des eHDSI Solution Providers.

Der NCPeH-FD MUSS sich gegenüber dem Central Terminology Service gemäß [eHDSI_CTS#4.3] authentisieren und seine Zugangsdaten TERMINOLOGY_SERVICE_USERNAME und TERMINOLOGY_SERVICE_PASSWORD (siehe Kapitel 4.1.1 Konfigurationsparameter) zusammen mit der HTTP POST Anfrage an folgende Schnittstelle des Terminology Service senden:

TERMINOLOGY_SERVICE_BASE_URL + "/ehealth-term-server/login"

Nach erfolgreicher Authentifizierung und Aufbau einer gültigen Session zum CTS MUSS der NCPeH-FD vom CTS relevante Entitäten des MTC mittels einzelner RESTful-Schnittstellen gemäß Vorgaben aus [eHDSI_CTS_API] abrufen.

Falls der Central Terminology Service im Erfolgsfall mit einem Response Code 200 antwortet, muss im Body-Teil der Antwort die entsprechende Entität des MTC im Format application/json enthalten sein. Falls es sich doch um ein anderes Format handelt, MUSS der NCPeH-FD eine weitere Verarbeitung des MTC und seiner Entitäten abbrechen und dem Systemadministrator über die entsprechende Management-Schnittstelle (bei manueller Aktualisierung) oder als ein Protokolleintrag (bei automatisierter Aktualisierung) mit einer entsprechenden Fehlernachricht antworten. Der NCPeH-FD MUSS sicherstellen, dass die abgerufene Entität inklusive der Referenzen zu anderen Entitäten des MTC die Schemavorgaben gemäß [eHDSI_CTS_API#Models] erfüllt.

Vor der lokalen Installation der Entitäten des MTC in der VAU MUSS der NCPeH-FD sicherstellen, dass in einem Fehlerfall die aktuell in der VAU installierten und aktivierten Entitäten des MTC wiederhergestellt werden können (Backup des vorherigen MTC). Während der Installation und Aktivierung des neuen MTC MUSS der NCPeH-FD sicherstellen, dass zu dem Zeitpunkt laufende Prozess der Transformierung und Transkodierung von ePKA MIO der Versicherten ins eHDSI Pivotformat nicht beeinträchtigt werden.

Der NCPeH-FD MUSS bei der erfolgreichen Installation und Aktivierung des MTC in der VAU einen Audit Trail Eintrag nach Vorgaben aus Kapitel 4.1.7.5 Security Audit Trail Eintrag erstellen erstellen und dabei folgende Vorgaben berücksichtigen:

Tabelle 50: TAB_NCPeH_Audit_Trail_Synchronize_MTC

Nach erfolgreicher Installation und Aktivierung des gesamten MTC in der VAU oder bei Fehlern bei der Authentisierung des NCPeH-FD gegenüber dem Central Terminology Service, gescheitertem Abruf einzelner Entitäten des MTC oder bei fehlgeschlagener Installation und Aktivierung des MTC in der VAU MUSS der NCPeH-FD dem Systemadministrator über die Management-Schnittstelle (bei manueller Aktualisierung) eine Meldung anzeigen und ein Protokolleintrag erstellen. Im Falle eines Fehlers MÜSSEN die Meldung und der Protokolleintrag Informationen über die Fehlerdetails enthalten.

Ausgabeparameter des TUC

keine

7 Anhang – Europäische Krankenversicherungskarte

Ein Abbild der Vorderseite der eGK soll zur besseren Verständlichkeit mit der International Searchmask mitgeliefert werden (siehe TAB_NCPeH_Service_Metadata_ISM in 6.1.4.1 TUC_NCPeH_011: Service Metadata erstellen ).

Abbildung 8: Vorderseite der eGK - Identifikationsdokument

Ein Abbild der Rückseite der eGK - die europäische Krankenversichertenkarte - soll zur besseren Verständlichkeit mit der International Searchmask mitgeliefert werden (siehe TAB_NCPeH_Service_Metadata_ISM in 6.1.4.1 TUC_NCPeH_011: Service Metadata erstellen ).

Abbildung 9: Rückseite der eGK - die europäische Krankenversichertenkarte

8 Anhang – Verzeichnisse

8.1 Abkürzungen

8.2 Begriffe

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

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

8.5.2 Weitere Dokumente