C_11983_Anlage

Inhaltsverzeichnis

1 Änderung in gemSpec_NCPeH_FD

1.1 Neuaufnahme des Kapitels "5.2.3 NCPeH.UC_11 - Ausgewählte E-Rezepte aus ePeD-A abrufen"

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

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

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

1.2 Anpassungen am Kapitel "6.1.3 Operation Cross_Gateway_Retrieve::RetrieveDocument"

Tabelle 2 : TAB_NCPeH_Definition_Operation_RetrieveDocument

Operation

Cross_Gateway_Retrieve::RetrieveDocument

Beschreibung

Diese Operation wird aufgerufen, wenn das Initiating Gateway (NCPeH Land-B) eine Anfrage von einem behandelnden LE-EU empfängt und sie nachfolgend an diese Operation sendet. Durch die Anfrage MUSS der NCPeH-FD anhand konkreter Identifikatoren das ePKA MIO die Gesundheitsdaten des Versicherten aus dem jeweiligen Fachdienst in der TI ermitteln und diese ePA-Aktensystem abrufen und dem NCPeH Land-B im angeforderten eHDSI CDA-Pivotformat bereitstellen. In Abhängigkeit vom angeforderten Dokumentenformat MUSS der NCPeH-FD die abgerufenen Gesundheitsdaten das ermittelte ePKA MIO im strukturierten Dokumentenformat (CDA Level 3) und/oder im PDF/A-Format (CDA Level 1) bereitstellen.

[...]

Tabelle 3 : TAB_NCPeH_Kriterien__Zuordnung_IHE-XCA.RetrieveDocument_Anfragen_zu_Anwendungsszenarien

DocumentUniqueId	Technischer Use Case (TUC)
[...]	[...]
Endet mit "^eP.XML" oder mit "^eP.PDF"	[6.1.3.7 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request für ePeD-A] auf Einhaltung von allgemeinen Kriterien prüfen Anwendungsszenario: ePrescription/eDispensation Land-A
Eine Mischung aus DocumentUniqueId-Elementen mit unterschiedlichen Endungen für verschiedene Anwendungsszenarien (z.B. "^PS.XML" und "^eP.XML")	Das Abrufen von Dokumenten für verschiedene Anwendungsszenarien  in derselben Anfrage wird derzeit nicht unterstützt. 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 der NCPeH-FD MUSS Vorgaben aus [eHDSI_XCA_Profile#4.3] umsetzen. Der NCPeH-FD MUSS eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit einer Cross GatewayRetrieveResponse-Nachricht gemäß Vorgaben aus [eHDSI_XCA_Profile#2.4] antworten und dabei folgende Informationen zum Fehler angeben: errorCode: ERROR_EP_GENERIC codeContext: "" severity: urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error location: "" Nach Versand der Fehlermeldung an den jeweiligen NCPeH Land-B MUSS der NCPeH-FD einen Non-Repudiation of Origin Eintrag gemäß [4.1.7.1 - Non-Repudiation of Origin 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 der NCPeH-FD MUSS Vorgaben aus [eHDSI_XCA_Profile#4.3] umsetzen.
Ein anderer Wert	Das angeforderte Anwendungsszenario und das Dokumentenformat sind nicht bekannt oder werden derzeit nicht unterstützt. 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 der NCPeH-FD MUSS Vorgaben aus [eHDSI_XCPDXCA_Profile#34.3] umsetzen. Der NCPeH-FD DARF die Anfrage zum DocumentRequest-Element NICHT weiter bearbeiten und MUSS auf das DocumentRequest-Element mit dem Fehlercode ERROR_GENERIC antworten. Nach Versand der Fehlermeldung an den jeweiligen NCPeH Land-B MUSS der NCPeH-FD einen Non-Repudiation of Origin Eintrag gemäß [4.1.7.1 - Non-Repudiation of Origin 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 der NCPeH-FD MUSS Vorgaben aus [eHDSI_XCA_Profile#4.3] umsetzen.

1.2.1 Neuaufnahme des Kapitels "6.1.3.7 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request für ePeD-A auf Einhaltung von allgemeinen Kriterien prüfen"

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.2 - Datenaustausch mit zugelassenen EU-Ländern]
• [4.1.3 - eHDSI Basisleistungen]
• [4.1.3.1 Sicherer Kanal: TESTA-ng und TLS]
• [4.1.5 - Validierung der Identity Assertion des LE-EU]
• [4.1.6 - Validierung der TRC-Assertion]
• [4.1.7 - Non-Repudiation und Audit Trail Schemas]
• [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI
• [4.1.9 - Format und Validierung der KVNR]

Der NCPeH-FD MUSS 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 MUSS der NCPeH-FD die Vorgaben aus [eHDSI_XCA_Profile#4.3] umsetzen. Wenn zum Zeitpunkt der Erstellung des Audit Trail Eintrags nicht alle erforderlichen Daten im NCPeH-FD verfügbar sind, MÜSSEN die Daten in den Audit Trail Eintrag aufgenommen werden, sobald sie im NCPeH-FD verfügbar sind, spätestens aber nachdem die Antwort an NCPeH Land-B gesendet wurde.

Beim Auftreten eines der folgenden Fehlerfälle MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit einer Fehlernachricht mittels der Antwortnachricht gemäß Kapitel [6.1.3.8 - TUC_NCPeH_XXX: Cross Gateway Retrieve Response mit ePeD-A senden] antworten:

Tabelle 4 : TAB_NCPeH_Fehlerfälle_Verarbeitung_Cross_Gateway_Retrieve_Request_ePeD-A

Fehlerfall	errorCode (gemäß [eHDSI_NCPeH_Components#6.4])	codeContext	severity	location
Die Variable tls_country aus dem TLS-Zertifikat des NCPeH Land-B (siehe Kapitel [4.1.3.1 Sicherer Kanal: TESTA-ng und TLS]) DARF NICHT leer sein.	ERROR_EP_GENERIC	"The ePrescription service is not agreed  with requesting country. Please contact your service provider or administrator."	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error	"Received country code from TLS certificate= " + Wert der Variable tls_country
Die Variable ida_permissions, falls sie nicht leer ist, enthält nicht alle Permission Codes gemäß den Vorgaben aus Kapitel [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] für den eHDSI Use Case "Request for ePrescriptions"		"Access is not permitted. Please check the access rights for your health professional role in your country."		"Received permission codes=" + Wert der Variable ida_permissions
Die Variable ida_permissions ist leer und die Bedingungen zur Erlangung einer Zugriffsberechtigung auf E-Rezept-FD nach Kapitel [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] sind nicht erfüllt		"Access is not permitted. The information provided about the role of health professional does not comply with German regulations."		"No permission codes received and the access cannot be granted for the received practitioner role code in accordance with national regulations. Received practitioner role code=" + Wert der Variable ida_practitioner_role_code
Der Wert der  Variable  trc_kvnr ist leer oder verletzt die Vorgaben aus Kapitel [4.1.9 Format und Validierung der KVNR].		"Please make sure that the health insurance number is given and correct"		"Insurant number is missing or invalid."
Der Wert der Variable trc_accesscode ist leer oder verletzt die Formatvorgaben aus Kapitel [4.1.6 - Validierung der TRC-Assertion].		"A respective access code has not been transmitted or has not been transmitted properly. Please ask the patient for an access authorisation."		Keine Angaben
Die Anfrage enthält keine DocumentUniqueId-Elemente	ERROR_MISSING_REQUIRED_FIELDS	"The request does not contain any ePrescription ID. Please contact your service provider or administrator."		"Missing any DocumentUniqueId-Element in the request."
Die Variable ida_name-id ist leer.	ERROR_HPI_INSUFFICIENT_INFORMATION	"The information provided about the identifier of health professional is missing."		Keine Angaben
Die Variable ida_practitioner_role ist leer.		"The information provided about the role of health professional is missing."		Keine Angaben
Die Variable  ida_practitioner_name ist leer.		"The information about the name of health professional is missing."		Keine Angaben
Der Wert der Variable ida_practitioner_role_code ist leer oder dieser ist nicht identisch mit einem der möglichen Werte für das Element urn:oasis:names:tc:xacml:2.0:subject:role aus [eHDSI_SAML_Profile#2.3].		"Missing or incorrect information about the role of health professionals."		"Received role code of the health professional from the identity assertion; see element urn:oasis:names:tc:xacml:2.0:subject:role= " + Wert der Variableida_practitioner_role_code, (falls dieser nicht leer ist, ansonsten keine Angaben)
Die Variable ida_point_of_care ist leer.	ERROR_HPI_POC_NO_INFORMATION	"The information provided about the name of the health professional organization is missing."		Keine Angaben
Der Wert der Variable  ida_healthcare_facility_type ist leer oder nicht identisch mit einem der vorgegebenen Werte aus [eHDSI_SAML_Profile#2.3] für das Identitätsattribut urn:ehdsi:names:subject:healthcare-facility-type.		"Missing or incorrect information has been provided about the Healthcare Provider Organisation."		"Received healthcare facility type=" + Wert der Variable ida_healthcare_facility_type (falls dieser nicht leer ist, ansonsten keine Angaben)

Hinweis: Die Initiierung der Variablen ida_permissions, ida_practitioner_role_code, 
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 der Variablen trc_kvnr und trc_accesscode im Kapitel [4.1.6 - Validierung der TRC-Assertion].

Ausgabeparameter des TUC

• Fehlernachricht an NCPeH Land-B (falls vorhanden)

1.2.2 Neuaufnahme des Kapitels "6.1.3.8 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request für ePeD-A CDA verarbeiten"

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.1 - Konfigurationsparameter]
• [4.1.2 - Datenaustausch mit zugelassenen EU-Ländern] 
• [4.1.3 - eHDSI Basisleistungen]
• [4.1.5 - Validierung der Identity Assertion des LE-EU]
• [4.1.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]

Ablauf des TUC

Der NCPeH-FD MUSS zusätzlich zu den Vorgaben aus [eHDSI_XCA_Profile#2.4] für jedes DocumentRequest-Element die Vorgaben aus der Tabelle TAB_NCPeH_Nutzungskonvention_Cross_Gateway_Retrieve_Request_ePeD-A umsetzen.

Tabelle 5 : TAB_NCPeH_Nutzungskonvention_Cross_Gateway_Retrieve_Request_ePeD-A

Element aus der Anfrage	Nutzungskonvention
HomeCommunityId	Dieser Wert, ohne das Präfix "urn:oid:", MUSS identisch mit dem Wert des Konfigurationsparameters HOME_COMMUNITY_ID_NCPeH-FD aus Kapitel [4.1.1 - Konfigurationsparameter] sein. Wenn der Wert des Elementes leer oder nicht identisch mit dem Wert des Konfigurationsparameters  HOME_COMMUNITY_ID_NCPeH-FD ist, MUSS der NCPeH-FD für das angeforderte E-Rezept ein /RetrieveDocumentSetResponse/RegistryResponse/RegistryErrorList/RegistryError-Element in der Antwortnachricht (IHE XCA.Retrieve-Response) gemäß Vorgaben aus [ebRIM_Representation_Document#4.2.4]  und [ITI-43#3.43.5]  erstellen und mit folgenden Angaben zum Fehler befüllen: errorCode: ERROR_EP_GENERIC codeContext: "The Home Community ID for the German NCPeH is wrong. Please contact your service provider or administrator." severity: urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error location: "Received HomeCommunityId= " + Wert aus dem Element HomeCommunityId (falls der Wert nicht leer ist, ansonsten keine Angaben)
RepositoryUniqueId	Dieser Wert MUSS mit dem Wert des Konfigurationsparameters OID_AC_eRp_ASSIGNING_AUTHORITY aus Kapitel [4.1.1 - Konfigurationsparameter] identisch sein. Wenn der Wert des Elementes leer oder nicht identisch mit dem Wert des Konfigurationsparameters  OID_AC_eRp_ASSIGNING_AUTHORITY ist, MUSS der NCPeH-FD für das angeforderte E-Rezept ein /RetrieveDocumentSetResponse/RegistryResponse/RegistryErrorList/RegistryError-Element in der Antwortnachricht (IHE XCA.Retrieve-Response)  gemäß Vorgaben aus [ebRIM_Representation_Document#4.2.4]  und [ITI-43#3.43.5]  erstellen und mit folgenden Angaben zum Fehler befüllen: errorCode: ERROR_EP_GENERIC codeContext: "The Repository Unique ID is not identical to the ID of the German ePrescription Service. Please contact your service provider or administrator." severity: urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error location: "Received RepositoryUniqueid= " + Wert aus dem Element RepositoryUniqueid (falls der Wert nicht leer ist, ansonsten keine Angaben)
DocumentUniqueId	Der Wert DARF NICHT leer sein. Nur der vordere Teil (ohne Endung "^eP.XML" oder "^eP.PDF") des Wertes MUSS als E-Rezept-ID verwendet werden,  um das passende E-Rezept des Versicherten im E-Rezept-FD eindeutig ermitteln zu können. Der NCPeH-FD MUSS die E-Rezept-ID (ohne Endung "^eP.XML" oder "^eP.PDF") aus der Anfrage gemäß den Vorgaben in [gemSpec_DM_eRp#2.2] prüfen. Wenn die Prüfung der E-Rezept-ID erfolgreich war, MUSS der NCPEH-FD die E-Rezept-ID für die weitere Datenverarbeitung in einer Variable list_ePrescription_uniqueIds zwischenspeichern. Wenn festgestellt wird, dass der Wert des Elementes leer ist oder die Prüfung der E-Rezept-ID auf Erfüllung von Vorgaben aus [gemSpec_DM_eRp#2.2] nicht erfolgreich war, MUSS der NCPeH-FD für das angeforderte E-Rezept ein /RetrieveDocumentSetResponse/RegistryResponse/RegistryErrorList/RegistryError-Element in der Antwortnachricht (IHE XCA.Retrieve-Response)  gemäß Vorgaben aus [ebRIM_Representation_Document#4.2.4]  und [ITI-43#3.43.5]  erstellen und mit folgenden Angaben zum Fehler befüllen: errorCode: ERROR_INCORRECT_FORMATTING codeContext: "The identifier of an ePrescription is missing or not correct. Please contact your service provider or administrator." severity: urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error location: "Received DocumentUniqueId= " + Wert aus dem Element DocumentUniqueId" Beim Feststellen eines Fehlers DARF der Wert des Elementes NICHT in der Variable list_ePrescription_uniqueIds zwischengespeichert werden. Die Variable DARF E-Rezept-IDs NICHT enthalten, die die Vorgaben aus [gemSpec_DM_eRp#2.2] verletzen.

Beispiel eines RetrieveDocumentSetRequest zur Abfrage von strukturierten E-Rezepten:

<RetrieveDocumentSetRequest>    <DocumentRequest>       <HomeCommunityId>urn:oid:1.2.276.0.76.4.291</HomeCommunityId>       <RepositoryUniqueId>1.2.276.0.76.4.299</RepositoryUniqueId>       <DocumentUniqueId>160.000.000.000.123.76^eP.XML</DocumentUniqueId>    </DocumentRequest>    <DocumentRequest>       ...    </DocumentRequest> </RetrieveDocumentSetRequest>

Ausgabeparameter des TUC

• list_ePrescription_uniqueIds
  

1.2.3 Neuaufnahme des Kapitels "6.1.3.9 - TUC_NCPeH_XXX: Cross Gateway Retrieve Response mit ePeD-A CDA senden"

Für diesen TUC gelten folgende übergreifende Festlegungen

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

Ablauf des TUC

Dieser TUC enthält die Vorgaben für die Erstellung von IHE XCA.Retrieve-Response Nachrichten.

Als Eingangsparameter für diesen TUC dienen die Listen list_transcoded_eprescriptions_cda und
list_registry_error_transcoding_cda. Beide wurden im Kapitel [6.1.3.10 - TUC_NCPeH_XXX: Abgerufene E-Rezepte transkodieren und transformieren] erstellt. Als weiterer Eingangsparameter für diesen TUC gilt die Liste der RegistryError-Elemente, die ggf. im Kapitel [6.2.6 - TUC_NCPeH_XXX: Abzugebende E-Rezepte vom E-Rezept-FD abrufen] erstellt sind.

Der NCPeH-FD MUSS für jedes DocumentRequest-Element aus der XCA.Retrieve-Anfrage ein entsprechendes DocumentResponse-Element in der XCA.Retrieve-Antwort erstellen, jedoch nur unter der Bedingung, dass in der Liste list_transcoded_eprescriptions_cda ein CDA-Dokument existiert, dessen Document Identifier mit dem Wert des DocumentUniqueId-Elementes aus der XCA.Retrieve-Anfrage übereinstimmt.

Bei der Erstellung der XCA.Retrieve-Antwort MÜSSEN die Vorgaben aus [eHDSI_XCA_Profile#2.4] und [ITI-43#3.43.4.2] umgesetzt werden. Für die Befüllung des DocumentResponse-Elementes MÜSSEN die Nutzungsvorgaben aus der Tabelle AB_NCPeH_Nutzungskonvention_Cross_Gateway_Retrieve_Response_ePeD-A eingehalten werden.

Tabelle 6 : TAB_NCPeH_Nutzungskonvention_Cross_Gateway_Retrieve_Response_ePeD-A

Element in der Antwort	Nutzungskonvention
HomeCommunityId	Dieses Element MUSS mit der HomeCommunityId aus der Anfrage identisch sein. Der Wert besteht aus "urn:oid:" (ohne Anführungszeichen) gefolgt vom Wert des Konfigurationsparameters HOME_COMMUNITY_ID_NCPeH-FD aus Kapitel [4.1.1 - Konfigurationsparameter].  Beispiel: urn:oid:1.2.276.0.76.4.291
RepositoryUniqueId	Dieses Element MUSS mit der RepositoryUniqueId aus der Anfrage identisch sein. Das Element besteht aus dem Wert der Variable OID_AC_eRp_ASSIGNING_AUTHORITY aus Kapitel [4.1.1 - Konfigurationsparameter].
DocumentUniqueId	Der Wert dieses Elementes MUSS identisch mit dem Wert des DocumentUniqueId-Elementes aus der Anfrage sein. Beispiel: 160.000.000.000.123.76^eP.XML
mimeType	text/xml
Document	Dieses Element enthält ein Base64-kodiertes CDA-Dokument aus der Liste list_transcoded_eprescriptions_cda. Der ePrescription-Identifier des CDA-Dokumentes MUSS identisch mit dem Wert des DocumentUniqueId-Elementes aus der Anfrage sein.

Der NCPeH-FD MUSS für jedes DocumentRequest/DocumentUniqueId-Element (für die angeforderten E-Rezepte) aus der Anfrage, für das es

• kein passendes CDA-Dokument mit identischem ePrescription Identifier in der Liste list_transcoded_eprescriptions_cda vorhanden ist,
• kein RegistryError-Element in der Liste list_registry_error_transcoding_cda  zu diesem ePrescription-Identifier existiert,
• kein RegistryError-Element aus Kapitel [6.2.6 - TUC_NCPeH_XXX: Abzugebende E-Rezepte vom E-Rezept-FD abrufen] zu diesem ePrescription-Identifier existiert und
• kein RegistryError-Element aus Kapitel [6.1.3.8 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request zur Abfrage ePeD-A CDA verarbeiten] zu diesem ePrescription-Identifier gibt,

ein /RetrieveDocumentSetResponse/RegistryResponse/RegistryErrorList/RegistryError-Element in der Antwortnachricht (IHE XCA.Retrieve-Response) gemäß den Vorgaben aus [ebRIM_Representation_Document#4.2.4] und [ITI-43#3.43.5] erstellen und folgende Informationen im Fehlereintrag angeben:

• errorCode: WARNING_EP_GENERIC
• codeContext: "The requested ePrescription could not be found."
• severity: urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning
• location: "Received ePrescription identifier: %Wert des Elementes DocumentUniqueId aus der Anfrage%"

Wenn die Listen list_registry_error_transcoding_cda, list_registry_error_xca_retrieve aus dem Kapitel [6.2.6 - TUC_NCPeH_XXX: Abzugebende E-Rezepte vom E-Rezept-FD abrufen] und Kapitel [6.1.3.8 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request zur Abfrage ePeD-A CDA verarbeiten] nicht leer sind, MUSS der NCPeH-FD die Einträge (RegistryError-Element) aus den Listen in die Antwortnachricht übertragen, bevor er die Antwortnachricht an den NCPeH Land-B sendet.

In der Antwortnachricht können [ebRIM_Representation#4.2.4] Error Codes enthalten sein, die entsprechende ResponseStatus-Informationen aufweisen. Das Vorhandensein einer ErrorList ist prinzipiell vereinbar mit einer teilweise erfolgreichen Verarbeitung. Wenn die ErrorList nur Warnings enthält (RegistryError elements mit warning severity, aber ohne error severity), dann MUSS die Verarbeitung als erfolgreich angesehen werden.
Die Rückmeldungen zu Fehlern und Warnungen an den NCPeH Land-B, die bei der Verarbeitung der IHE XCA.Retrieve-Request Nachricht, dem Abruf von E-Rezepten aus dem E-Rezept-FD oder der Transkodierung und Transformierung von E-Rezepten entstanden sind, MÜSSEN das in [ebRIM_Representation#4.2.4] beschriebene Format haben und in die Response-Nachricht aufgenommen werden.
Darüber hinaus MUSS der NCPeH-FD die Vorgaben aus [ebRIM_Representation#4.2.4.2] für die Verwendung des status-Attributs im RegistryResponse-Element und für den Umgang mit dem RegistryErrorList-Element umsetzen.

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

Der NCPeH-FD MUSS unmittelbar nach dem Senden der Antwortnachricht die Listen
list_transcoded_eprescriptions_cda, list_registry_error_transcoding und list_ePrescription_uniqueIds und ihre Verweise auf die TRC Assertion des entsprechenden IHE XCA.Retrieve-Requests löschen.

Beispiel einer Antwortnachricht mit einem ePrescription CDA-Dokument Pivotformat Level 3 in Base64-Kodierung. Aufgrund der Länge des CDA-Dokumentes enthält das Beispiel im Element <Document> einen Platzhalter "...":

<RetrieveDocumentSetResponse>    <RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>    <DocumentResponse>       <HomeCommunityId>urn:oid:1.2.276.0.76.4.291</HomeCommunityId>       <RepositoryUniqueId>1.2.276.0.76.4.299</RepositoryUniqueId>       <DocumentUniqueId>160.000.000.000.123.76^eP.XML</DocumentUniqueId>       <mimeType>text/xml</mimeType>       <Document>PENsaW5pY2FsRG9jdW1lbn...</Document>    </DocumentResponse>    <DocumentResponse>       ...    </DocumentResponse> </RetrieveDocumentSetResponse>

Ausgabeparameter des TUC

• Keine

1.2.4 Neuaufnahme des Kapitels "6.2.6 - TUC_NCPeH_XXX: Abzugebende E-Rezepte vom 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.9 - Elektronische Identitäten des NCPeH-FD]

Ablauf des TUC

Dieser TUC beschreibt den Ablauf des Abrufs der vom LE-EU angeforderten E-Rezepte des Versicherten aus dem E-Rezept-FD. Die angeforderten E-Rezept-IDs sind in der Variable list_ePrescription_uniqueIds zwischengespeichert. Die Vorgaben zur Befüllung der Variable ist im Kapitel [6.1.3.8 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request zum Abruf ePeD-A CDA verarbeiten] beschrieben.

Der NCPeH-FD MUSS sicherstellen, wenn die Liste list_ePrescription_uniqueIds mehrfach dieselbe E-Rezept-ID (ohne die Endungen "eP.XML" und "eP.PDF") enthält, dass die E-Rezept-ID einmal an den E-Rezept-FD übermittelt wird.

Der NCPeH-FD MUSS im inneren Request die HTTP-Operation des E-Rezept-FD mit dem Ausdruck POST /get-eu-prescriptions aufrufen und dabei gleichzeitig mit dem Request den HTTP-Header "Authorization" sowie die FHIR-Parameter gemäß den 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.

Der NCPeH-FD MUSS im Payload innerhalb des requestData-Parameter für jeden Eintrag aus der Variable list_ePrescription_uniqueIds jeweils ein part-Element entsprechend den Vorgaben aus der Tabelle TAB_NCPeH_Payload_PrescriptionIds_Aufruf_Operation_get-eu-prescriptions erstellen und befüllen. Der NCPeH-FD MUSS sicherstellen, dass in der Payload keine E-Rezept-IDs mehrfach enthalten sind.

Tabelle 7 : TAB_NCPeH_Payload_PrescriptionIds_Aufruf_Operation_get-eu-prescriptions

name-Element	valueIdentifier/value-Element	valueIdentifier/system-Element
prescription-id Hinweis: Der Parameter MUSS ausschließlich im Rahmen des Anwendungsfalls "5.2.3 NCPeH.UC_11 - Ausgewählte E-Rezepte abrufen" gesetzt werden. In anderen Anwendungsfällen DARF der Parameter NICHT gesetzt und an E-Rezept-FD übermittelt werden.  Hinweis: Für weitere Informationen zur Struktur des Parameters siehe [API_EU_E-Rezepte"Abfragen von E-Rezepten des E-Rezept-Fachdienst"]	Ausgehend vom Wert der Variable  list_ePrescription_uniqueIds aus dem Kapitel ["6.1.3.7 - TUC_NCPeH_XXX: Cross Gateway Retrieve Request zur Abfrage ePeD-A CDA verarbeiten] MUSS der NCPeH-FD den Wert einer E-Rezept-ID aus der Variable ohne Endungen "^eP.XML" und "^eP.PDF") in den Parameter aufnehmen. Die Endungen DÜRFEN NICHT an den E-Rezept-FD übermittelt werden.	Der folgende Wert MUSS gesetzt werden: "https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_PrescriptionId"

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 die 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 die Komponente Audit Repository speichern.

Bei einer Antwort des E-Rezept-FD mit dem HTTP-Statuscode 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ähnten Vorgaben zum Operationsaufruf erneut mit dem neuen ACCESS_TOKEN und den Vorgaben aus dem Kapitel [4.2.10.5 Erstellung des Payload für die Kommunikation mit dem E-Rezept-FD] durchführen.

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 eine FHIR-Resource resource/Bundle (im weiteren Verlauf des Dokuments als "inneres Bundle" bezeichnet). Der NCPeH-FD MUSS das innere Bundle in allen Bundle/entry-Elementen auf Schemakonformität gemäß den 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_ausgewählte_E-Rezepte_abrufen erstellen und in der Liste 
list_registry_error_xca_retrieve für weitere Datenverarbeitung zwischenspeichern.

Tabelle 8 : TAB_NCPeH_Fehler_nicht_schemakonform_UC_ausgewählte_E-Rezepte_abrufen

errorCode gemäß [eHDSI_XCA_Profile#2.2.3] und [eHDSI_NCPeH_Components#6.4]	codeContext	severity	location
ERROR_INTERNAL_ERROR	"Could not process the ePrescription with the ID= " + Wert der betroffenen E-Rezept-ID	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error	"Received ePrescriptions ID=" + Wert der betroffenen E-Rezept-ID

Der NCPeH-FD MUSS für jede E-Rezept-ID aus der Variable list_ePrescription_uniqueIds) überprüfen, ob in der Antwortnachricht des E-Rezept-FD exakt ein inneres Bundle existiert und ob dieses Bundle im /Bundle/identifier-Element (gemäß FHIR-Profil GEM_ERP_NS_PrescriptionId) einen Wert aufweisen, der mit der jeweiligen E-Rezept-ID identisch ist.

Der NCPeH-FD MUSS für jede E-Rezept-ID, zu der der E-Rezept-FD kein entsprechendes E-Rezept finden konnte, in der Antwortnachricht an den NCPeH Land-B ein AdhocQueryResponse/RegistryErrorList/RegistryError-Element mit Angaben zum Fehler gemäß Tabelle TAB_NCPeH_Error_Not_Found_E-Rezept-ID_UC_ausgewählte_E-Rezepte_abrufen erstellen und dieses in der Liste list_registry_error_xca_retrieve für die weitere Datenverarbeitung zwischenspeichern. Der NCPeH-FD MUSS bei doppelt vorkommenden E-Rezept-IDs aus der Variable list_ePrescription_uniqueIds für jeden einzelnen Eintrag dieser E-Rezept-ID die gleiche Fehlerbehandlung durchführen wie bei nicht doppelten E-Rezepten-IDs.

Tabelle 9 : TAB_NCPeH_Error_Not_Found_E-Rezept-ID_UC_ausgewählte_E-Rezepte_abrufen

errorCode gemäß [eHDSI_XCA_Profile#2.2.3] und [eHDSI_NCPeH_Components#6.4]	codeContext	severity	location
ERROR_NOT_FOUND	"No prescription found for the ePrescription ID= " + Wert der betroffenen E-Rezept-ID	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning	"The ePrescription service could not find a prescription for the ID= " + Wert der betroffenen E-Rezept-ID

Der NCPeH-FD MUSS für die weitere Datenverarbeitung ausschließlich schemakonforme innere Bundles zusammen mit der jeweils zugehörigen E-Rezept-ID (siehe Variable list_ePrescription_uniqueIds) in der Variable fhir_erp_bundle_collection zwischenspeichern. Bei Vorhandensein von mehrfachen Einträgen derselben E-Rezept-ID mit unterschiedlichen Endungen (wie "^eP.XML" und "^eP.PDF") in der Variable list_ePrescription_uniqueIds, dann MUSS der NCPeH-FD das entsprechende innere Bundle in der Variable fhir_erp_bundle_collection mit jedem einzelnen dieser E-Rezept-ID Einträge verknüpfen.

Die inneren Bundles, die nicht schemakonform sind, DÜRFEN NICHT in der Variable fhir_erp_bundle_collection zwischengespeichert werden.

Tritt einer der folgenden Fehlerfälle auf, MUSS der NCPeH-FD die weitere gesamte Verarbeitung der Anfrage abbrechen, in der Antwortnachricht an den NCPeH Land-B ein
/RetrieveDocumentSetResponse/RegistryResponse/RegistryErrorList/RegistryError-Element gemäß den  Vorgaben aus [ebRIM_Representation_Document#4.2.4]  und [ITI-43#3.43.5] erstellen und mit entsprechenden Angaben zum Fehler gemäß Tabelle "TAB_NCPeH_Fehlerfälle_Abzugebende_E-Rezepte_vom_E-Rezept-FD_abrufen" an den NCPeH Land-B befüllen.

Tabelle 10  : TAB_NCPeH_Fehlerfälle_Abzugebende_E-Rezepte_vom_E-Rezept-FD_abrufen

Fehlerfall	errorCode gemäß [eHDSI_XCA_Profile#2.2.3] und [eHDSI_NCPeH_Components#6.4]	codeContext	severity	location
E-Rezept-FD antwortet mit dem HTTP Status Code 200, aber die Antwortnachricht enthält kein FHIR-Bundle vom Typ collection	ERROR_INTERNAL_ERROR	"Internal error when retrieving the patient's ePrescriptions."	rn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error	"The response from the ePrescription service does not contain a FHIR bundle of type collection."
E-Rezept-FD antwortet mit dem HTTP Status Code 400				"The ePrescription service has responded with HTTP status code 400."
E-Rezept-FD antwortet nach einem zweiten Operationsaufruf mit dem HTTP Status Code 401				"The ePrescription service has responded with HTTP status code 401."
Die Variable fhir_erp_bundle_collection ist nach Prüfung der inneren Bundles leer.				"The format of the patient's ePrescriptions is incorrect."
E-Rezept-FD antwortet mit dem HTTP Status Code 403	ERROR_NO_CONSENT	"There is no valid access authorisation for the country of treatment in the ePrescription service. Please ask the patient for access authorisation."		"The ePrescription service has responded with HTTP status code 403"
E-Rezept-FD antwortet mit dem HTTP Status Code 404	WARNING_EP_GENERIC	"No ePrescription for dispensation in EU-countries are available for the patient."	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning	"The ePrescription service has responded with HTTP status code 404."
E-Rezept-FD antwortet mit dem HTTP Status Code 408	ERROR_REGISTRY_NOT_AVAILABLE	"Internal error due to timeout. Please submit the request again."	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error	"The ePrescription service has responded with HTTP status code 408."
E-Rezept-Fachdienst antwortet mit dem HTTP Status Code 500	ERROR_INTERNAL_ERROR	"Internal error when retrieving the patient's ePrescriptions."		"The ePrescription service has responded with HTTP status code 500."
Der E-Rezept-FD antwortet nicht und der hinterlegte Wert im Konfigurationsparameter eRp_RESPONSE_TIMEOUT (siehe Kapitel 4.1.1 Konfigurationsparameter) ist überschritten				"Time-out. ePrescription service is not responding."

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 "Retrieve Document Set [ITI-43] and Cross Gateway Retrieve [ITI-39] 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")
• list_registry_error_xca_retrieve

1.2.5 Neuaufnahme des Kapitels "6.1.3.10 - TUC_NCPeH_XXX: Abgerufene E-Rezepte transkodieren und transformieren"

Für diesen TUC gelten folgende übergreifende Festlegungen

• [4.1.7 - Non-Repudiation und Audit Trail Schemas]

Ablauf des TUC

In diesem TUC führt der NCPeH-FD gemäß den Vorgaben des BfArM die Transformierung und Transkodierung von "inneren Bundles" aus der Liste fhir_erp_bundle_collection in das geforderte eHDSI ePrescription CDA Pivotformat durch. Neben jedem "inneren Bundle" besteht in der Variable fhir_erp_bundle_collection eine eindeutige Referenz zu einem E-Rezept-ID. Anhand der E-Rezept-ID kann in diesem TUC ermittelt werden, ob bei einem referenzierten inneren Bundle eine Transformierung oder sowohl eine Transformierung als auch eine Transkodierung erforderlich ist.

Die Erstellung und Befüllung der Variable fhir_erp_bundle_collection ist im Kapitel [6.2.6 - TUC_NCPeH_XXX: Abzugebende E-Rezepte vom E-Rezept-FD abrufen] beschrieben.

Wenn die E-Rezept-ID mit "^eP.PDF" endet, dann MUSS der NCPeH-FD das referenzierte innere Bundle aus der Liste fhir_erp_bundle_collection in das eHDSI ePrescription Pivotformat CDA Level 1 embedded PDF/A nach Vorgaben aus [eHDSI_CDA_Format_ePrescription] transformieren und dabei das aktuelle CDA Document Template "eHDSI ePrescription PDF embedded" verwenden. Der NCPeH-FD MUSS die Transformierung und Erstellung des PDF/A-Dokumentes nach Vorgaben des BfArM umsetzen.

Disclaimer: Die Vorgaben für die Transformierung der "inneren Bundles" in das eHDSI ePrescription CDA Pivotformat Level 1 embedded PDF/A werden vom BfArM erarbeitet.

Wenn die E-Rezept-ID mit "^eP.XML" endet, MUSS der NCPeH-FD das referenzierte innere Bundle aus der Liste fhir_erp_bundle_collection in das eHDSI ePrescription Pivotformat CDA Level 3 nach den Vorgaben aus [eHDSI_CDA_Format_ePrescription] transformieren und transkodieren. Dabei MUSS das Template "eHDSI ePrescription" verwendet werden.

Disclaimer: Die Vorgaben zur Transformierung und Transkodierung von "inneren Bundles" (FHIR-Profil [KBV_PR_ERP_Bundle]) in das eHDSI CDA Pivotformat ePrescription Level 3 und der Fehlerverwaltung werden vom BfArM erarbeitet.

Für eine erfolgreiche Transformierung und Transkodierung der E-Rezepte MUSS der NCPeH-FD sicherstellen, dass er die aktuellen, von der BfArM bereitgestellten Transformierungs- und Transkodierungsregeln und Daten bei sich integriert hat. Dabei sind die Vorgaben aus "4.2.10.6 Regelung zur Unterstützung von mehreren FHIR-Package Versionen" mit zu berücksichtigen.

Die Ergebnisse der erfolgreichen  Transformierung und Transkodierung MÜSSEN in der Liste list_transcoded_eprescriptions_cda zwischengespeichert werden, um sie im Kapitel [6.1.3.8 - TUC_NCPeH_XXX: Cross Gateway Retrieve Response mit ePeD-A CDA senden] für die Aufnahme in die Antwortnachricht an den NCPeH Land-B vorzubereiten.

Wenn die Transformierung und Transkodierung zu Fehlern oder Warnungen führt, MUSS der NCPeH-FD diese nach Vorgaben aus [ebRIM_Representation#4.2.4] und der BfArM in dem dort beschriebenen Format erfassen. Die Fehler und Warnungen (RegistryError-Elemente) MÜSSEN nach Vorgaben des BfArM für die Attribute errorCode, codeContext,
severity und location erstellt werden. Die erfassten Fehler und Warnungen MÜSSEN in der Liste list_registry_error_transcoding_cda zwischengespeichert werden. Die Angaben zu errorCode MÜSSEN den eHDSI Error Codes gemäß den Vorgaben aus [eHDSI_NCPeH_Components#6.4] entsprechen. Der NCPeH-FD MUSS für codeContext mit menschlich verständlichen Meldungen in englischer Sprache erstellen. Für Angaben zum Attribut location SOLL der NCPeH-FD technische Hinweise auf die Fehlerursache geben. Technische Informationen DÜRFEN Inhalte NICHT angeben, die Rückschluss auf Implementierungsdetails, eingesetzte Frameworks oder Tools zulassen.

Ausgabeparameter des TUC

• list_transcoded_eprescriptions_cda
• list_registry_error_transcoding_cda

1.3 Anpassungen am Kapitel "6.1.3.1 TUC_NCPeH_005: Cross Gateway Retrieve Request zur Abfrage der Patient Summary CDA Level 3 verarbeiten"

[...]

Ablauf des TUC

Der NCPeH-FD MUSS 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 MUSS der NCPeH-FD die Vorgaben aus [eHDSI_XCA_Profile#4.3] umsetzen. Wenn zum Zeitpunkt der Erstellung des Audit Trail Eintrags nicht alle erforderlichen Daten im NCPeH-FD verfügbar sind, MÜSSEN die Daten in den Audit Trail Eintrag aufgenommen werden, sobald sie im NCPeH-FD verfügbar sind, spätestens aber nachdem die Antwort an NCPeH Land-B gesendet wurde.

Der NCPeH-FD MUSS bei der die Verarbeitung der Anfrage neben den Vorgaben aus [eHDSI_XCA_Profile#2.4] auch nach folgenden Kriterien umsetzen: auch die folgenden Vorgaben für das DocumentRequest-Element umsetzen:

[...]

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.

Bei folgenden Fehlerfällen MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit einer Fehlernachricht mittels der Response-Nachricht gemäß [6.1.3.2 TUC_NCPeH_006: Cross Gateway Retrieve Response mit Patient Summary CDA Level 3 senden] antworten:

Tabelle 11 : TAB_NCPeH_Fehlerfälle_Verarbeitung_Cross_Gateway_Retrieve_Request_PSA_CDA3

Fehlerfall	errorCode (gemäß [eHDSI_NCPeH_Components#6.4])	codeContext	severity	location
Die Variable ida_name-id ist leer.	ERROR_HPI_INSUFFICIENT_INFORMATION	"The information provided about the identifier of health professional is missing."	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error	Keine Angaben
Die Variable  ida_practitioner_name ist leer.		"The information about the name of health professional is missing."		Keine Angaben
Die Variable ida_practitioner_role ist leer.		"The information provided about the role of health professional is missing."		Keine Angaben
Der Wert der Variable ida_practitioner_role_code ist leer oder dieser ist nicht identisch mit einem der möglichen Werte für das Element urn:oasis:names:tc:xacml:2.0:subject:role aus dem Kapitel [eHDSI_SAML_Profile#2.3].		"Missing or incorrect information about the role of health professional."		"Received role code of the health professional from the identity assertion; see element urn:oasis:names:tc:xacml:2.0:subject:role= " + Wert der Variableida_practitioner_role_code, (falls dieser nicht leer ist, ansonsten keine Angaben)
Der Wert der Variable  ida_healthcare_facility_type ist leer oder nicht identisch mit einem der vorgegebenen Werte aus [eHDSI_SAML_Profile#2.3] für das Identitätsattribut urn:ehdsi:names:subject:healthcare-facility-type.	ERROR_HPI_POC_NO_INFORMATION	"Missing or incorrect information has been provided about the Healthcare Provider Organisation."		"Received healthcare facility type=" + Wert der Variable ida_healthcare_facility_type (falls dieser nicht leer ist, ansonsten keine Angaben)
Die Variable ida_point_of_care ist leer.		"The information provided about the name of health professional organization is missing."		Keine Angaben
Die Variable tls_country aus dem TLS-Zertifikat des NCPeH Land-B (siehe Kapitel [4.1.3.1 Sicherer Kanal: TESTA-ng und TLS]) DARF NICHT leer sein.	ERROR_PS_GENERIC	"The service request is incorrectly configured and is intended for a different country. Please contact your service provider or administrator."		"Received country code from TLS certificate= " + Wert der Variable tls_country
Die Variable ida_permissions, falls sie nicht leer ist, enthält nicht alle Permission Codes gemäß den Vorgaben aus [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] für den eHDSI Use Case "Request for Patient Summary"		"Access is not permitted. Please check the access rights for your health professional role in your country."		"Received permission codes=" + Wert der Variable ida_permissions
Die Variable ida_permissions ist leer und die Bedingungen zur Erlangung einer Zugriffsberechtigung auf ePA nach [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] sind nicht erfüllt.		"Access is not permitted. The information provided about the role of healthcare professionals does not comply with German regulations."		"No permission codes received and the access cannot be granted for the received practitioner role code in accordance with national regulations. Received practitioner role code=" + Wert der Variable ida_practitioner_role_code
Der Wert der  Variable  trc_kvnr ist leer oder verletzt die Vorgaben aus Kapitel [4.1.9 Format und Validierung der KVNR].		"Please make sure that the health insurance number is given and correct"		"Health insurant number is missing or invalid."
Der Wert der Variable trc_accesscode ist leer oder verletzt die Formatvorgaben aus Kapitel [4.1.6 - Validierung der TRC-Assertion]		"A respective access code has not been transmitted or has not been transmitted properly. Please ask the patient for an access authorisation."		Keine Angaben
Das Element HomeCommunityId entspricht nicht der Nutzungskonvention gemäß Tabelle TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA3.		"The Home Community ID for the German NCPeH is wrong. Please contact your service provider or administrator."		"Received HomeCommunityId= " + Wert aus dem Element HomeCommunityId (falls der Wert nicht leer ist, ansonsten keine Angaben)
Das Element RepositoryUniqueId entspricht nicht der Nutzungskonvention gemäß Tabelle  TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA3.		The Repository Unique ID is not correct. Please contact your service provider or administrator.		"Received RepositoryUniqueid= " + Wert aus dem Element RepositoryUniqueid (falls der Wert nicht leer ist, ansonsten keine Angaben)
Die Prüfung des vorderen Teils (ohne Endung "^PS.XML") des Elementes  DocumentUniqueId gemäß Nutzungskonvention aus Tabelle TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA3 ist nicht erfolgreich.	ERROR_INCORRECT_FORMATTING	"The ID of requested document is missing or not correct. Please contact your service provider or administrator."		Wert des Elementes DocumentUniqueId

Hinweis: Die Initiierung der Variablen ida_permissions, ida_practitioner_role_code, 
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 der Variablen trc_kvnr und trc_accesscode im Kapitel [4.1.6 - Validierung der TRC-Assertion].

[...]

1.4 Anpassungen am Kapitel "6.1.3.3 TUC_NCPeH_007: Cross Gateway Retrieve Request zur Abfrage der Patient Summary CDA Level 1 verarbeiten"

[...]

Der NCPeH-FD MUSS bei der die Verarbeitung der Anfrage neben den Vorgaben aus [eHDSI_XCA_Profile#2.4] auch nach folgenden Kriterien umsetzen: auch die folgenden Vorgaben für das DocumentRequest-Element umsetzen:

[...]

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.

Bei folgenden Fehlerfällen MUSS der NCPeH-FD eine weitere Verarbeitung der Anfrage abbrechen und dem anfragenden NCPeH Land-B mit einer Fehlernachricht mittels der Response-Nachricht gemäß [6.1.3.4 TUC_NCPeH_008: Cross Gateway Retrieve Response mit dem Patient Summary CDA Level 1 senden] antworten: 

Tabelle 12 : TAB_NCPeH_Fehlerfälle_Verarbeitung_Cross_Gateway_Retrieve_Request_PSA_CDA1

Fehlerfall	errorCode (gemäß [eHDSI_NCPeH_Components#6.4])	codeContext	severity	location
Die Variable ida_name-id ist leer.	ERROR_HPI_INSUFFICIENT_INFORMATION	"The information provided about the identifier of health professional is missing."	urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error	Keine Angaben
Die Variable  ida_practitioner_name ist leer.		"The information about the name of health professional is missing."		Keine Angaben
Die Variable ida_practitioner_role ist leer.		"The information provided about the role of health professional is missing."		Keine Angaben
Der Wert der Variable ida_practitioner_role_code ist leer oder dieser ist nicht identisch mit einem der möglichen Werte für das Element urn:oasis:names:tc:xacml:2.0:subject:role aus dem Kapitel [eHDSI_SAML_Profile#2.3].		"Missing or incorrect information about the role of health professional."		"Received role code of the health professional from the identity assertion; see element urn:oasis:names:tc:xacml:2.0:subject:role= " + Wert der Variableida_practitioner_role_code, (falls dieser nicht leer ist, ansonsten keine Angaben)
Der Wert der Variable  ida_healthcare_facility_type ist leer oder nicht identisch mit einem der vorgegebenen Werte aus [eHDSI_SAML_Profile#2.3] für das Identitätsattribut urn:ehdsi:names:subject:healthcare-facility-type.	ERROR_HPI_POC_NO_INFORMATION	"Missing or incorrect information has been provided about the Healthcare Provider Organisation."		"Received healthcare facility type=" + Wert der Variable ida_healthcare_facility_type (falls dieser nicht leer ist, ansonsten keine Angaben)
Die Variable ida_point_of_care ist leer.		"The information provided about the name of health professional organization is missing."		Keine Angaben
Die Variable tls_country aus dem TLS-Zertifikat des NCPeH Land-B (siehe Kapitel [4.1.3.1 Sicherer Kanal: TESTA-ng und TLS]) DARF NICHT leer sein.	ERROR_PS_GENERIC	"The service request is incorrectly configured and is intended for a different country. Please contact your service provider or administrator."		"Received country code from TLS certificate= " + Wert der Variable tls_country
Die Variable ida_permissions, falls sie nicht leer ist, enthält nicht alle Permission Codes gemäß den Vorgaben aus [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] für den eHDSI Use Case "Request for Patient Summary"		"Access is not permitted. Please check the access rights for your health professional role in your country."		"Received permission codes=" + Wert der Variable ida_permissions
Die Variable ida_permissions ist leer und die Bedingungen zur Erlangung einer Zugriffsberechtigung auf ePA nach [4.1.8 - Festlegungen zur Prüfung der Zugriffsberechtigung auf Fachdienste der TI] sind nicht erfüllt.		"Access is not permitted. The information provided about the role of healthcare professionals does not comply with German regulations."		"No permission codes received and the access cannot be granted for the received practitioner role code in accordance with national regulations. Received practitioner role code=" + Wert der Variable ida_practitioner_role_code
Der Wert der  Variable  trc_kvnr ist leer oder verletzt die Vorgaben aus Kapitel [4.1.9 Format und Validierung der KVNR].		"Please make sure that the health insurance number is given and correct"		"Health insurant number is missing or invalid."
Der Wert der Variable trc_accesscode ist leer oder verletzt die Formatvorgaben aus Kapitel [4.1.6 - Validierung der TRC-Assertion]		"A respective access code has not been transmitted or has not been transmitted properly. Please ask the patient for an access authorisation."		Keine Angaben
Das Element HomeCommunityId entspricht nicht der Nutzungskonvention gemäß Tabelle TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA1.		"The Home Community ID for the German NCPeH is wrong. Please contact your service provider or administrator."		"Received HomeCommunityId= " + Wert aus dem Element HomeCommunityId (falls der Wert nicht leer ist, ansonsten keine Angaben)
Das Element RepositoryUniqueId entspricht nicht der Nutzungskonvention gemäß Tabelle  TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA1.		The Repository Unique ID is not correct. Please contact your service provider or administrator.		"Received RepositoryUniqueid= " + Wert aus dem Element RepositoryUniqueid (falls der Wert nicht leer ist, ansonsten keine Angaben)
Die Prüfung des vorderen Teils (ohne Endung "^PS.PDF") des Elementes  DocumentUniqueId gemäß Nutzungskonvention aus Tabelle TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Request_PSA_CDA1 ist nicht erfolgreich.	ERROR_INCORRECT_FORMATTING	"The ID of requested document is missing or not correct. Please contact your service provider or administrator."		Wert des Elementes DocumentUniqueId

Hinweis: Die Initiierung der Variablen ida_permissions, ida_practitioner_role_code, 
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 der Variablen trc_kvnr und trc_accesscode im Kapitel [4.1.6 - Validierung der TRC-Assertion].

[...]

1.5 Anpassungen am Kapitel "6.1.3.2 TUC_NCPeH_006: Cross Gateway Retrieve Response mit Patient Summary CDA Level 3 senden"

[...]

Tabelle 13: TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Response_PSA_CDA3

Element in der Antwort	Nutzungskonvention
[...]	[...]

In der Response können [ebRIM_Representation#4.2.4] Error Codes auftreten, die entsprechende ResponseStatus-Informationen aufweisen. Das Vorhandensein einer Error-List ist prinzipiell vereinbar mit einer teilweise erfolgreichen Verarbeitung. Wenn die ErrorList nur Warnings enthält (RegistryError elements mit warning severity, aber ohne error severity), dann MUSS die Verarbeitung als erfolgreich angesehen werden.
Die Rückmeldungen zu Fehlern und Warnungen an NCPeH Land-B, die bei der Verarbeitung der Anfrage, dem Abruf des ePKA MIO des Versicherten oder der Transkodierung und Transformierung entstanden sind, MÜSSEN das in [ebRIM_Representation#4.2.4] "Success and Error Reporting" beschriebene Format haben und MÜSSEN in die Response-Nachricht aufgenommen werden. Es wird im Fehlerfall ggf. eine Fehlerliste (RegistryErrorList) und darin ein Fehler (RegistryError) je fehlgeschlagenem DocumentRequest mit den Attributen errorCode, codeContext, severity und location 
zurückgegeben.  
Darüber hinaus MUSS der NCPeH-FD die Vorgaben aus [ebRIM_Representation#4.2.4.2] für die Verwendung des status-Attributs im RegistryResponse-Element und die Vorgaben für den Umgang mit dem RegistryErrorList-Element umsetzen.

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

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

[...]

1.6 Anpassungen am Kapitel "6.1.3.4 TUC_NCPeH_008: Cross Gateway Retrieve Response mit dem Patient Summary CDA Level 1 senden"

[...]

Tabelle 14: TAB_NCPeH_Nutzungskonvention_XCA_Retrieve_Response_PSA_CDA1

Element in der Antwort	Nutzungskonvention
[...]	[...]

In der Response können [ebRIM_Representation#4.2.4] Error Codes auftreten, die entsprechende ResponseStatus-Informationen aufweisen. Das Vorhandensein einer Error-List ist prinzipiell vereinbar mit einer teilweise erfolgreichen Verarbeitung. Wenn die ErrorList nur Warnings enthält (RegistryError elements mit warning severity, aber ohne error severity), dann MUSS die Verarbeitung als erfolgreich angesehen werden.
Die Rückmeldungen zu Fehlern und Warnungen an NCPeH Land-B, die bei der Verarbeitung der Anfrage, dem Abruf des ePKA MIO des Versicherten oder der Transformierung entstanden sind, MÜSSEN das in [ebRIM_Representation#4.2.4] "Success and Error Reporting" beschriebene Format haben und in die Response-Nachricht aufgenommen werden. Es wird im Fehlerfall ggf. eine Fehlerliste (RegistryErrorList) und darin ein Fehler (RegistryError) je fehlgeschlagenem DocumentRequest mit den Attributen errorCode, codeContext, severity und location 
zurückgegeben.  
Darüber hinaus MUSS der NCPeH-FD die Vorgaben aus [ebRIM_Representation#4.2.4.2] für die Verwendung des status-Attributs im RegistryResponse-Element und die Vorgaben für den Umgang mit dem RegistryErrorList-Element umsetzen.

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

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

[...]