C_11977_Anlage

Inhaltsverzeichnis

1 Änderungen in gemSpec_NCPeH_FD

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

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

1.2 Anpassung an Kapitel "6.1.2 Operation Cross_Gateway_Query::FindDocuments"

Tabelle 2 : TAB_NCPeH_Cross_Gateway_Queries

[...]

Tabelle 3 : TAB_NCPeH_Kriterien_Zuordnung_IHE-XCA.Query-_Anfragen_zu_Anwendungsszenarien 

1.2.1 Neuaufnahme des Kapitels "6.1.2.3 - TUC_NCPeH_XXX: Cross Gateway Query Request für ePeD-A verarbeiten"

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.2 - Datenaustausch mit zugelassenen EU-Ländern 
• 4.1.3 - eHDSI Basisleistungen
• 4.1.5 - Validierung der Identity Assertion des LE-EU
• 4.1.6 - Validierung der TRC-Assertion
• 4.1.7 - Non-Repudiation und Audit Trail Schemas
• 4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI
• 4.1.9 - Validierung der Prüfziffer der KVNR

Ablauf des TUC

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

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

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

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

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

• Der Wert des Parameters muss mit Hochkomma beginnen und enden.
• Die in dem Parameter enthaltene Versichertenkennung muss identisch mit dem Wert der Variable trc_kvnr sein (siehe Kapitel [4.1.6 - Validierung der TRC-Assertion]).
• Der in dem Parameter enthaltene Zugriffscode muss identisch mit dem Wert der Variable trc_accesscode sein (siehe Kapitel [4.1.6 - Validierung der TRC-Assertion]).
• Die im Parameter enthaltene OID muss identisch mit dem Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY sein (siehe Kapitel [4.1.1 - Konfigurationsparameter]).

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

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

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

Tabelle 4 : TAB_NCPeH_XCA_QUERY_ePeD-A_Fehlerbedingungen_Fehlercodes

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

Das folgende Beispiel zeigt die Struktur des XCA.FindDocuments Request für ePrescriptions: 

Ausgabeparameter des TUC

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

• Keine

1.2.2 Neuaufnahme des Kapitels "6.1.2.4 TUC_NCPeH_XXX: Cross Gateway Query Response für ePeD-A versenden"

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.3 - eHDSI Basisleistungen
• 4.1.7 - Non-Repudiation und Audit Trail Schemas
• fhir_erp_bundle_collection - Ein FHIR-Bundle vom Typ collection liegt im Klartext vor. Das FHIR-Bundle enthält mindestens ein inneres, schemakonformes Bundle vom Typ document mit der Profilierung KBV_PR_ERP_Bundle gemäß [KBV_PR_ERP_Bundle] mit Angaben zu jeweils einem E-Rezept.

Ablauf des TUC

Der NCPeH-FD MUSS die Inhalte und Struktur der XCA.Query-Antwort nach Vorgaben aus [eHDSI_XCA_Profile#2.2] erstellen. Zusätzlich müssen Vorgaben gemäß [ebRIM_Representation_Document#4.2.3.2] zur Erstellung von DocumentEntry-Elementen und -Attributen beachtet werden.

In diesem TUC werden die Einträge des Eingangsparameters fhir_erp_bundle_collection (siehe Ausgabeparameter im Kapitel 6.2.5 TUC_NCPeH_XXX: Liste der einlösbaren E-Rezepte des Versicherten aus dem E-Rezept-FD abrufen) verarbeitet. Der Eingangsparameter fhir_erp_bundle_collection enthält mindestes einen "inneren Bundle" vom Typ document. In jedem inneren Bundle stellt eine FHIR-Resource Composition vom Profile [KBV_PR_ERP_Composition] eine Referenzsammlung zu allen anderen entry-Elementen (FHIR-Resource) dar, in denen relevante Angaben zu MedicationRequest-, Medication- und Practicioner enthalten sind.

Der NCPeH-FD MUSS für jedes innere Bundle resource/entry-Elemente ermitteln, die zu folgende FHIR-Resources führen:

FHIR-Resource MedicationRequest

• Die Referenz (ein UUID-Wert), die zur FHIR-Resource MedicationRequest mit dem Profil [KBV_PR_ERP_Prescription] führt, ist im Element Bundle/entry/resource/Composition/section/entry enthalten. Dabei MUSS der Code des section-Elements mit dem Wert Prescription identisch sein. Die ermittelte die FHIR-Resource MedicationRequest
  enthält Informationen über die Verordnung.

FHIR-Resource Medication

• Die ermittelte MedicationRequest-Resource enthält im medicationReference-Element wiederum eine Referenz (ein UUID-Wert) auf die eigentliche FHIR-Resource Medication, in der weitere Angaben zur Verordnung enthalten sind.

FHIR-Resource Practicioner

• Die Referenz (ein UUID-Wert), die zur FHIR-Resource Practitioner mit dem Profil [KBV_PR_FOR_Practitioner] führt, ist im Element Bundle/entry/resource/Composition/author enthalten. Das author-Element MUSS vom Typ Practitioner sein. Die ermittelteFHIR-Resource Practitioner enthält Informationen zum verordnenden LE-DE.

Der NCPeH-FD MUSS in der XCA.Query-Antwortnachricht für jedes innere Bundle zu der darin enthaltenen Verordnung (FHIR-Resource MedicationRequest) jeweils ein ExtrinsicObject-Element mit einem Name-Subelement ePrescription source coded PDF/A document und ein weiteres ExtrinsicObject-Element mit einem Name-Subelement 
 ePrescription coded document erstellen.

Darüber hinaus MUSS der NCPeH-FD in den ExtrinsicObject-Elementen Informationen zum verordnenden LE-DE (FHIR-Resource Practinioner aus dem jeweiligen inneren Bundle) angeben und zusätzlich für folgende Elemente die Nutzungskonventionen einhalten:

Tabelle 5 : TAB_NCPeH_Nutzungskonvention_Erstellung_XCA.Query_Response_ePeD-A

Der NCPeH-FD MUSS Vorgaben aus [eHDSI_XCA_Profile#2.2.1] zur Erstellung von ebRIM-Assoziations-Elementen in der Query-Response erfüllen.

Der NCPeH-FD MUSS für AdhocQueryResponse@status in der Antwortnachricht einen entsprechenden Wert setzen, der anhand des Gesamtstatus aller RegistryResponse/RegistryErrorList/RegistryError@Severities-Attribute,  erfolgreich verarbeiteter interner Bundles und unter Berücksichtigung der Kriterien aus der Tabelle "Registry Stored Query [ITI-18] and Cross Gateway Query [ITI-38] Responses" in [ebRIM_Representation_Document#4.2.4.2] zu bestimmen ist. 

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

Das folgende Beispiel stellt die Struktur und Inhalte eines XCA FindDocuments-Response für ePrescriptions dar:

Ausgabeparameter des TUC

• Dieser TUC hat keine Ausgabeparameter.

1.3 Neuaufnahme des Kapitels "6.2.5 TUC_NCPeH_XXX: Liste der einlösbaren E-Rezepte des Versicherten aus dem E-Rezept-FD abrufen"

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.2.1 - Schnittstellen zu Diensten der zentralen TI
• 4.2.10 Übergreifende Vorgaben an die Kommunikation mit E-Rezept-FD
• 4.2.10.4 Authentifizierung des NCPeH-FD am E-Rezept-FD
• 4.2.10.6 Regelung zur Unterstützung von mehreren FHIR-Package Versionen
• 4.2.9 - Elektronische Identitäten des NCPeH-FD

Ablauf des TUC

Mit diesem TUC ruft der NCPeH-FD alle im EU-Ausland einlösbaren E-Rezepte des Versicherten vom E-Rezept-FD ab und erhält ein FHIR-Bundle.

Der NCPeH-FD MUSS im inneren Request die HTTP-Operation des E-Rezept-FD mit dem Ausdruck POST/get-eu-prescriptions aufrufen und zusammen mit dem Request den HTTP-Header "Authorization" und die FHIR-Parameter gemäß Vorgaben aus dem Kapitel "4.2.10.5 Erstellung des Payload für die Kommunikation mit dem E-Rezept-FD" an die HTTP-Operation übermitteln. Der HTTP Parameter_count DARF NICHT im Operationsaufruf angegeben werden.

Für weitere Informationen über die Definition der Schnittstellenoperation/get-eu-prescriptions siehe [gemSpec_FD_eRp#Http-Operation POST get-eu-prescriptions] und [API_EU_E-Rezepte#"Abfragen von E-Rezepten des E-Rezept-Fachdienst].

Nach Versand der Anfrage an den E-Rezept-FD 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 vom E-Rezept-FD 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.

Bei einer Antwort des E-Rezept-FD mit dem HTTP Status Code 401 MUSS der NCPeH-FD für das NCPeH Land-B ein neues ACCESS_TOKEN unter Verwendung der TI-Identität gemäß den Vorgaben in Kapitel ["4.2.10.4 Authentifizierung des NCPeH-FD am E-Rezept-FD"] anfordern. Der NCPeH-FD MUSS die oben erwähnte Vorgaben zum Operationsaufruf erneut mit dem neuen ACCESS_TOKEN und den Vorgaben aus Kapitel [4.2.10.5 Erstellung des Payload für die Kommunikation mit dem E-Rezept-FD] umsetzen.

Wenn der E-Rezept-FD mit dem HTTP Status Code 200 antwortet, ist in der Antwortnachricht ein FHIR-Bundle enthalten. Der NCPeH-FD MUSS validieren, ob das in der Antwortnachricht enthaltene FHIR-Bundle vom Typ collection ist und die Vorgaben aus [FHIR_Resource_Bundle] erfüllt.

Das FHIR-Bundle (im weiteren Verlauf des Dokuments als "äußeres Bundle" bezeichnet) enthält mindestens ein entry-Element. Jedes entry-Element enthält wiederum ein FHIR-Bundle resource/Bundle (im weiteren Verlauf des Dokuments als "inneres Bundle" bezeichnet). Der NCPeH-FD MUSS das innere Bundle in allen entry-Elementen auf Schemakonformität gemäß Vorgaben aus [KBV_PR_ERP_Bundle] prüfen. Jedes innere Bundle kapselt Angaben zu genau einem E-Rezept.

Der NCPeH-FD MUSS für die nicht schemakonformen inneren Bundles in der Antwortnachricht an den NCPeH Land-B jeweils ein AdhocQueryResponse/RegistryErrorList/RegistryError-Element mit Angaben zum Fehler gemäß Tabelle "TAB_NCPeH_Fehler_nicht_schemakonform_UC_Auflistung_von_einlösbaren_E-Rezepten" erstellen.

Tabelle 6 : TAB_NCPeH_Fehler_nicht_schemakonform_UC_Auflistung_von_einlösbaren_E-Rezepten

Der NCPeH-FD MUSS für die weitere Datenverarbeitung ausschließlich schemakonformen innere Bundles in einer Variable fhir_erp_bundle_collection zwischenspeichern. Die inneren Bundles, die nicht schemakonform sind, DÜRFEN NICHT in die Variable fhir_erp_bundle_collection zwischengespeichert werden. Bei der Zwischenspeicherung MUSS der NCPeH-FD sicherstellen, dass das fhir_erp_bundle_collection im Rahmen der weiteren Datenverarbeitung mit der TRC Assertion aus dem entsprechenden IHE XCA.Query-Request verknüpft ist. Der NCPeH-FD DARF das FHIR-Bundle NICHT mit einer anderen TRC Assertion in Verbindung bringen.

Tritt einer der folgenden Fehlerfälle auf, MUSS der NCPeH-FD die weitere Verarbeitung der Anfrage abbrechen, in der Antwortnachricht an den NCPeH Land-B ein AdhocQueryResponse/RegistryErrorList/RegistryError-Element erstellen und mit entsprechenden Angaben zum Fehler gemäß Tabelle "TAB_NCPeH_Allgemeine_Fehlerfälle_Auflistung_von_einlösbaren_E-Rezepten" an den NCPeH Land-B antworten. Die Antwortnachricht MUSS nach Vorgaben aus Kapitel [6.1.2.4 TUC_NCPeH_XXX: Cross Gateway Query Response für ePeD-A versenden] erstellt werden.

Tabelle 7 : TAB_NCPeH_Allgemeine_Fehlerfälle_Auflistung_von_einlösbaren_E-Rezepten

Der NCPeH-FD MUSS für AdhocQueryResponse@status in der Antwortnachricht einen entsprechenden Wert setzen, der anhand des Gesamtstatus aller RegistryResponse/RegistryErrorList/RegistryError@Severities-Attribute,  erfolgreich verarbeiteter innerer Bundles und unter Berücksichtigung der Kriterien aus der Tabelle "Registry Stored Query [ITI-18] and Cross Gateway Query [ITI-38] Responses" in [ebRIM_Representation_Document#4.2.4.2] zu bestimmen ist. 

Ausgabeparameter des TUC

• fhir_erp_bundle_collection (Liste mit Einträgen der inneren Bundles)
• Cross Gateway Query Response inkl. RegistryError-Elementen (falls vorhanden)

1.4 Änderungen am Kapitel "6.1.2.1 TUC_NCPeH_003: Cross Gateway Query Request für PS-A verarbeiten"

Für diesen TUC gelten folgende übergreifende Festlegungen

• 4.1.2 - Datenaustausch mit zugelassenen EU-Ländern
• 4.1.3 - eHDSI Basisleistungen
• 4.1.5 - Validierung der Identity Assertion des LE-EU
• 4.1.6 - Validierung der TRC-Assertion
• 4.1.7.2 - Non-Repudiation of Receipt erstellen
• 4.1.7.3 - Patient Privacy Audit Trail Eintrag erstellen
• 4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI
• 4.1.9 - Validierung der Prüfziffer der KVNR
• 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.

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 des Audit Trail Eintrages müssen Vorgaben aus [eHDSI_XCA_Profile#4.3] umgesetzt werden. Wenn zum Zeitpunkt der Erstellung des Audit Trail Eintrags nicht alle erforderlichen Daten im NCPeH-FD verfügbar sind, MÜSSEN die Daten in den Audit Trail Eintrag aufgenommen werden, sobald sie im NCPeH-FD verfügbar sind, spätestens nach dem Versand der Antwort an NCPeH Land-B.

Der NCPeH-FD MUSS 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.
   Der Wert MUSS gemäß Vorgaben aus Kapitel [4.1.9 "Format und Validierung der KVNR] geprüft und valide sein.
3. Der senkrechte Strich ohne Anführungszeichen: "|"
4. 6-stelliger Zugriffscode
5. "^^^&"
6. Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY aus dem Kapitel [4.1.1 - Konfigurationsparameter]
   
7. "&ISO'"
   
   Beispiel des Wertes: 'B123456789|A2C4E6^^^&1.2.276.0.76.3.1.580.147&ISO'

• Der Wert des Parameters muss mit Hochkomma beginnen und enden.
• Die in dem Parameter enthaltene Versichertenkennung muss identisch mit dem Wert der Variable trc_kvnr sein (siehe Kapitel [4.1.6 - Validierung der TRC-Assertion]).
• Der in dem Parameter enthaltene Zugriffscode muss identisch mit dem Wert der Variable trc_accesscode sein (siehe Kapitel [4.1.6 - Validierung der TRC-Assertion]).
• Die im Parameter enthaltene OID muss identisch mit dem Wert des Konfigurationsparameters OID_KVNR_ASSIGNING_AUTHORITY sein (siehe Kapitel [4.1.1 - Konfigurationsparameter]).

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 8 : TAB_NCPeH_XCA_QUERY_Fehlerbedingungen_Fehlercodes_PS-AERRORS 

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

[...]

1.5 Änderungen am Kapitel "6.1.2.2 TUC_NCPeH_004: Cross Gateway Query Response für PS-A versenden"

[...]

Tabelle 9 : TAB_NCPeH_Nutzungskonvention_Erstellung_XCA.Query_Response_PS-A

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

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

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

[...]

1.6 Erweiterung am Kapitel "8.5.2 Weitere Dokumente"