C_12089_Anlage_V1.0.0
Prereleases:
C_12089_Anlage
Inhaltsverzeichnis
1 Änderung in gemSpec_NCPeH_FD
1.1 Erweiterung des Kapitels "4.2.6 Nutzung des IDP-Dienstes"
1.1.1 Erweiterung des Kapitels 4.2.6.2 Verarbeitung des Discovery Document
[...]
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 policyIdentifier oid_fd_sig für das Zertifikatsprofil C.FD.SIG enthalten ist und das Zertifikat auf die Rollen-OID oid_idpd zurückgeführt wird. Deras 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.
[...]
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 und
- die benötigten URL-Endpunkte für die Kommunikation mit dem IDP-Dienst dem Discovery Document entnehmen, in der VAU zwischenspeichern und zur Kommunikation mit dem IDP-Dienst nutzen.
Hinweis: zur Struktur des Discovery Document siehe auch [gemSpec_IDP_Dienst#Aufbau des Discovery Documents] und [gemSpec_IDP_Dienst#Aufbau des Discovery Document].
[...]
1.2 Neuaufnahme des Kapitels "4.2.10 Übergreifende Vorgaben an die Kommunikation mit E-Rezept-FD"
1.2.1 Neuaufnahme des Kapitels "4.2.10.1 Allgemeine Vorgaben an die Kommunikation mit dem E-Rezept-FD"
Der NCPeH-FD MUSS bei der Kommunikation mit dem E-Rezept-FD in allen HTTP-Requests im äußeren Request den HTTP-Header "user-agent" nach der Vorgabe [gemILF_PS_eRp#A_20015*] erstellen und befüllen.
Der NCPeH-FD MUSS bei der Kommunikation mit dem E-Rezept-FD in allen HTTP-Requests im äußeren Request den HTTP-Header "X-erp-user" nach der Vorgabe [gemILF_PS_eRp#A_21568*] erstellen und dabei den Wert "n" als NCPeH-FD einfügen.
Der NCPeH-FD MUSS bei der Kommunikation mit dem E-Rezept-FD in allen HTTP-Requests im äußeren Request den HTTP-Header "X-erp-resource" nach der Vorgabe [gemILF_PS_eRp#A_21569*] setzen und dabei den entsprechenden Wert gemäß der Tabelle "TAB_NCPeH_HTTP-Header_X-erp-resource" einfügen.
Table # : TAB_NCPeH_HTTP-Header_X-erp-resource
| Operation | X-erp-resource |
|---|---|
| POST /Task/<id>/$eu-close | Task |
| POST /get-eu-prescriptions | Prescription |
1.2.2 Neuaufnahme des Kapitels "4.2.10.2 Lokalisierung und Namensauflösung des E-Rezept-FD"
Der E-Rezept-FD ist gemäß den Festlegungen in [gemSpec_FD_eRp#Servicelokalisierung] lokalisierbar. Dabei nutzt der NCPeH-FD die Lokalisierungsinformationen gemäß Vorgabe aus [gemILF_PS_eRp#A_19451*]. Die URL für die Kommunikation mit dem E-Rezept-FD bildet der NCPeH-FD nach der Vorgabe aus [gemILF_PS_eRp#A_19744*].
Hinweis: Für den Verbindungsaufbau mit dem E-Rezept-FD sind verschiedene Endpunkte in [github_Endpunkte_E-Rezept-FD_IDP-Dienst] angegeben.
Das Redundanzkonzept sieht mehrere Instanzen vor, die über verschiedene IP-Adressen angesprochen werden. Folglich liefert die DNS-Namensauflösung verschiedene IP-Adressen zum FQDN zurück. Diese Adressen werden vom DNS-Server in zufälliger Reihenfolge geschickt, sodass es legitim ist, immer den ersten Eintrag für den folgenden Operationsaufruf zu verwenden.
Unspezifiziert ist das Verhalten, wenn die erste Zieladresse nicht erreichbar ist. Empfehlenswert ist die Nutzung der anderen/weiteren IP-Adressen der DNS-Abfrage. Bei Nicht-Erreichbarkeit des Zielhosts der ersten IP-Adresse wird daher empfohlen, eine alternative IP-Adresse aus einer DNS-Abfrage zu nutzen.
1.2.3 Neuaufnahme des Kapitels "4.2.10.3 Verschlüsselte Kommunikation zur VAU des E-Rezept-FD"
<< zu Referenzen in andere Kapitel dieses Dokumentes siehe folgende Anlagen zu Änderungseinträgen:
Kapitel "4.2.3 Prüfung von nonQES-Zertifikaten" siehe C_11973_Anlage#1.4,
Kapitel "4.2.2.1 TLS-Verbindungsaufbau zu Diensten der TI über das zentrale Netz der TI" siehe C_11973_Anlage#1.3,
Kapitel "5.2.1 NCPeH.UC_9 - Versicherten im Behandlungsland für ePeD-A identifizieren" siehe C_11976_Anlage,
Kapitel "5.2.2 NCPeH.UC_10 - Einlösbare E-Rezepte des Versicherten aus ePeD-A auflisten" siehe C_11977_Anlage,
Kapitel "5.2.3 NCPeH.UC_11 - Ausgewählte E-Rezepte aus ePeD-A abrufen" siehe C_11983_Anlage,
Kapitel ""5.2.X NCPeH.UC_12 - Abgabe von Arzneimitteln an Versicherte im Abgabeland" siehe C_12045_Anlage.
>>
Für die Kommunikation mit dem E-Rezept-FD gelten die Vorgaben zur TLS-gesicherten Kommunikation nach [gemILF_PS_eRP#Kommunikation zu den Diensten der TI] und [4.2.2.1 TLS-Verbindungsaufbau zu Diensten der TI über das zentrale Netz der TI].
Die Kommunikation zum E-Rezept-FD wird zusätzlich zu TLS über einen sicheren Kanal zwischen der VAU-Umgebung des NCPeH-FD und der VAU im E-Rezept-FD gesichert (Verschlüsselung auf HTTP-Ebene). Beim Aufruf der Operationen des E-Rezept-FD muss eine verschlüsselte Kommunikation gemäß der Vorgabe [gemILF_PS_eRp#A_19741*] gewährleistet werden.
Der NCPeH-FD MUSS in der Rolle als E-Rezept-Client beim Aufbau von VAU-Kanälen zum E-Rezept-FD die Vorgaben aus [gemSpec_Krypt#VAU-Protokoll für E-Rezept] umsetzen.
A_27101 - NCPeH - ePeD-A - Prüfung von VAU-Zertifikaten des E-Rezept-FD
Der NCPeH-FD MUSS die VAU-Zertifikate (X.509-Zertifikate) des E-Rezept-FD gemäß den Vorgaben aus Kapitel [4.2.3 Prüfung von nonQES-Zertifikaten] mit der Rollen-OID oid_erp-vau auf Gültigkeit prüfen. Bei Abweichungen MUSS der NCPeH-FD die Benutzung des Zertifikats für einen Verbindungsaufbau zur VAU ablehnen. [<=]
Wenn der NCPeH-FD das VAU-Zertifikat des E-Rezept-Fachdienstes mit dem Ergebnis gültig geprüft hat, dann KANN er dieses Zertifikat für 12h zwischenspeichern und nutzen.
A_27259 - Verwaltung der VAU-Zertifikate des E-Rezept-FD in der lokalen VAU
Wenn der NCPeH-FD das gültig geprüfte VAU-Zertifikat des E-Rezept-FD für 12h zwischenspeichert, dann MUSS er es in der VAU sicher speichern. Nach Ablauf der gültigen Zwischenspeicherung MUSS der NCPeH-FD das VAU-Zertifikat des E-Rezept-FD sicher löschen, erneut beziehen und auf Gültigkeit prüfen.
[<=]
Hinweis zum Fehlerhandling: Nur wenn der äußere Response des E-Rezept-FD den Response-Code 200 liefert, enthält der Payload eine mittels VAU-Protokoll verschlüsselte Response.
A_27056 - NCPeH - ePeD-A - Patient Identification - Umgang mit Fehlern beim Aufbau des VAU-Kanals zum E-Rezept-FD
Wenn beim Aufbau des VAU-Kanals zum E-Rezept-FD im Rahmen des Anwendungsfalls [5.2.1 NCPeH.UC_9 - Versicherten im Behandlungsland für ePeD-A identifizieren] ein Fehler auftritt, indem der E-Rezept-FD in der äußeren Response einen HTTP Status Code >= 400 liefert, MUSS der NCPeH-FD die weitere Bearbeitung der Anfrage abbrechen und dem NCPeH Land-B mit einer Fehlermeldung antworten, wobei Teile der Antwortnachricht wie folgt zu befüllen sind:
- Reason Encoding (reasonOf-Element) gemäß [eHDSI_XCPD_Profile#2.3.3]=
<mitigatedBy typeCode="MITGT">
<detectedIssueManagement
classCode="ACT" moodCode="ENV">
<code code="InternalError" codeSystem="1.3.6.1.4.1.19376.1.2.27.3"/>
</detectedIssueManagement>
</mitigatedBy>
- Acknowledgement =
acknowledgement.typeCode= AA queryAck.queryResponseCode= AE acknowledgementDetail.Code= ERROR_PI_INTERNAL_ERROR
acknowledgementDetail.Text = Patient Identification Error
acknowledgementDetail.Location = "No provision of patient data due to an internal error."
A_27057 - NCPeH - ePeD-A - Abruf oder Dispensierung von E-Rezepten - Umgang mit Fehlern beim Aufbau des VAU-Kanals zum E-Rezept-FD
Wenn beim Aufbau des VAU-Kanals zum E-Rezept-FD im Rahmen der Anwendungsfälle [5.2.2 NCPeH.UC_10 - Einlösbare E-Rezepte des Versicherten aus ePeD-A auflisten], [5.2.3 NCPeH.UC_11 - Ausgewählte E-Rezepte aus ePeD-A abrufen] und [5.2.X NCPeH.UC_12 - Abgabe von Arzneimitteln an Versicherte im Abgabeland] ein Fehler auftritt, indem der E-Rezept-FD in der äußeren Response eine HTTP Status Code >= 400 liefert, MUSS der NCPeH-FD die weitere Bearbeitung der Anfrage abbrechen und dem NCPeH Land-B mit einer Fehlermeldung antworten, wobei Teile der Antwortnachricht wie folgt zu befüllen sind:
- AdhocQueryResponse@status = urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure
- errorCode gemäß [eHDSI_XCA_Profile#2.2.3] und [eHDSI_NCPeH_Components#6.4] =
ERROR_INTERNAL_ERROR - codeContext = Internal error when querying the patient's ePrescriptions
- severity = urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error
- location = "The VAU connection to the national e-prescription service could not be established"
1.2.4 Neuaufnahme des Kapitels "4.2.10.4 Authentifizierung des NCPeH-FD am E-Rezept-FD"
Der NCPeH-FD, als Repräsentant des NCPeH Land-B in der TI, authentisiert sich gegenüber dem IDP-Dienst für Zugriffe auf Dienste der TI im Rahmen der Anwendung E-Rezept.
Wenn für die TI-Identität des NCPeH Land-B für den Zugriff auf E-Rezept-FD kein gültiges ACCESS_TOKEN vorliegt, dann beantragt der NCPeH-FD das benötigte ACCESS_TOKEN beim IDP-Dienst. Hierfür wird am Authorization-Endpunkt des IDP-Dienstes ein AUTHORIZATION_CODE beantragt, der nach erfolgreicher Verifikation am Token-Endpunkt des IDP-Dienstes gegen ein ID_TOKEN und einen ACCESS_TOKEN getauscht wird.
Die für die Beantragung des AUTHORIZATION_CODE im Challenge-Response-Verfahren notwendige elektronische Signatur erstellt der NCPeH-FD mittels entsprechender AUT-Identität der SM-B für das Land-B gemäß Vorgaben aus Kapitel [4.2.9 Elektronische Identitäten des NCPeH-FD].
Der IDP-Dienst führt die Identifikation des NCPeH-FD durch, und stattet diese anschließend mit ID_TOKEN gemäß [openid-connect-core 1.0 # IDToken] und ACCESS_TOKEN gemäß [RFC6749 # section-1.4] & [RFC6749 # section-5] aus. Dabei wurde aus Sicherheitsaspekten der "authorization code grant" gemäß [RFC6749 # section-4.1] gewählt. Um dem erforderlichen Sicherheitsniveau gerecht zu werden, wird zudem die Verwendung von PKCE (Proof Key for Code Exchange by OAuth Public Clients) gemäß [RFC7636] vorgesehen.
Der IDP-Dienst selbst teilt sich in mehrere statisch adressierte Teildienste auf. Diese umfassen:
- Discovery-Endpunkt ("OAuth 2.0 Authorization Server Metadata" [RFC8414]),
- Authorization-Endpunkt (Teil des "The OAuth 2.0 Authorization Framework" [RFC6749]),
- Token-Endpunkt [RFC6749 # section-3.2].
Für weitere Informationen zum IDP-Dienst und zum Ablauf der Authentisierung siehe [gemSpec_IDP_Dienst] und [gemILF_PS_eRp#Abruf von Token beim IDP-Dienst].
<<Siehe auch zugehörige Änderungen für Clientsysteme des E-Rezept-Fachdienstes in [gemF_eRp_EU], z. B. in [gemF_eRp_EU#7.4.3.3 "Änderungen in 5.1.4.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes"] und [gemF_eRp_EU#7.4.3.4 Änderungen in gemILF_PS_eRp 5.1.4.2 Abruf von Token beim IDP-Dienst]>>
Für die Nutzung des IDP-Dienstes im Zusammenhang mit dem E-Rezept-Fachdienst gelten die übergreifenden Vorgaben aus [4.2.6.1 Registrierung beim IDP-Dienst], [4.2.6.2 Verarbeitung des Discovery Document] und [4.2.6.3 TLS-Verbindungsaufbau zu Service-Endpunkten des IDP-Dienstes].
1.2.4.1 Neuaufnahme des Kapitels "4.2.10.4.2 Abruf von Token vom IDP-Dienst"
Der folgende Abschnitt umfasst Vorgaben, die den Ablauf der Beantragung und Ausgabe von Token bestimmen.
Der Abruf von Token vom IDP-Dienst für den E-Rezept-Fachdienst folgt den Vorgaben aus [gemILF_PS_eRp#Abruf von Token beim IDP-Dienst], die dort auch für den NCPeH-FD vorgegeben werden. In diesem Abschnitt erfolgen zusätzlich einige Präzisierungen für den NCPeH-FD.
A_27077 - NCPeH - ePeD-A - Signatur der Challenge des IdP-Dienstes
Der NCPeH-FD MUSS für die Signatur der Challenge des IdP-Dienstes nach [gemILF_PS_eRp#A_20665*] die Auswahl des korrekten Signaturzertifikat C.HCI.AUT als NCPeH-Identität Land-B gemäß Vorgaben aus Kapitel [4.2.9 Elektronische Identitäten des NCPeH-FD] durchführen. [<=]
A_27078 - NCPeH - ePeD-A - Response auf die Challenge des Authorization-Endpunktes
Der NCPeH-FD MUSS für die Response auf die Challenge des Authorization-Endpunktes nach [gemILF_PS_eRp#A_20667*] das in A_27077 gewählte Signaturzertifikat C.HCI.AUT als NCPeH-Identität Land-B nutzen. [<=]
A_27080 - NCPeH - ePeD-A - Gültigkeitsprüfung der Signatur des ID_TOKEN innerhalb der TI
Der NCPeH-FD MUSS zur Prüfung der Signaturzertifikates des ACCESS_TOKEN nach [gemILF_PS_eRp#A_20674*] und [gemILF_PS_eRp#A_20675*] die Vorgaben aus Kapitel [4.2.3 Prüfung von nonQES-Zertifikaten] umsetzen. [<=]
A_27127 - NCPeH - ePeD-A - Sicheres Löschen des ID_TOKEN und AUTHORIZATION_CODE
Der NCPeH-FD MUSS, nach Erhalt des ID_TOKEN und des ACCESS_TOKEN, vorhandene ID_TOKEN und AUTHORIZATION_CODE-Objekte sicher löschen. [<=]
Hinweis: Für weitere Informationen siehe auch in der Dokumentation api-erp auf github [Als Nutzer gegenüber der Telematikinfrastruktur authentisieren].
1.2.5 Neuaufnahme des Kapitels "4.2.10.5 Erstellung des Payload für die Kommunikation mit dem E-Rezept-FD"
A_27144 - NCPeH - ePeD-A - Übermittlung des HTTP-Header Authorization an E-Rezept-FD
Der NCPeH-FD MUSS sicherstellen, dass im inneren Request für die Operationen /get-eu-prescriptions und /Task/<id>/$eu-close ein HTTP-Header Authorization mit einem gültigen ACCESS_TOKEN an den E-Rezept-FD übermittelt wird. [<=]
Hinweis: ACCESS_TOKEN ist ein vom IDP-Dienst ausgestellter ACCESS_TOKEN. Für mehr Informationen siehe [4.2.10.4 Authentifizierung des NCPeH-FD am E-Rezept-FD].
A_26952 - NCPeH - ePeD-A - Befüllung der Payload-Parameter für Aufruf der Operation /get-eu-prescriptions
Der NCPeH-FD MUSS im inneren Request beim Aufruf der Operation/get-eu-prescriptions eine Payload nach dem FHIR-Profil [GEM_ERPEU_PR_PAR_GET_Prescription_Input] erstellen, darin ein parameter-Element mit dem Namen requestData anlegen und innerhalb des Elements part-Elemente entsprechend den Vorgaben aus der Tabelle "TAB_NCPeH_Payload_Aufruf_Operation_get-eu-prescriptions" erstellen und befüllen.
Tabelle 1 : TAB_NCPeH_Payload_Aufruf_Operation_get-eu-prescriptions
| name | value oder code | system | display |
|---|---|---|---|
| requesttype |
Der entsprechende Wert MUSS in dem Element gesetzt werden, wenn die Operation /get-eu-prescriptions im Zusammenhang mit dem entsprechenden Anwendungsfall aufgerufen wird (für weitere Informationen zum Parameter siehe [gemSpec_eRp_FD#Http-Operation POST get-eu-prescriptions] und [API_EU_E-Rezepte#Abfragen von E-Rezepten des E-Rezept-Fachdienst]):
|
Der folgende Wert MUSS gesetzt werden: "https://gematik.de/fhir/erp-eu/CodeSystem/GEM_ERPEU_CS_RequestType" |
Keine Angaben |
| kvnr | Wenn die Befüllung dieses Parameters im Zusammenhang mit dem Anwendungsfall [5.2.1 NCPeH.UC_9 - Versicherten im Behandlungsland für ePeD-A identifizieren] erfolgt, dann MUSS der folgende Wert in dem Parameter gesetzt werden:
Ansonsten bei allen anderen Anwendungsfällen MUSS der folgende Wert in dem Parameter gesetzt werden:
|
Der folgende Wert MUSS gesetzt werden: "http://fhir.de/sid/gkv/kvid-10" |
Keine Angaben |
| accessCode | Wenn die Befüllung dieses Parameters im Zusammenhang mit dem Anwendungsfall [5.2.1 NCPeH.UC_9 - Versicherten im Behandlungsland für ePeD-A identifizieren] erfolgt, dann MUSS der folgende Wert in dem Parameter gesetzt werden:
|
Der folgende Wert MUSS gesetzt werden: "https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_EU_AccessCode" |
Keine Angaben |
| countryCode | Der Wert der Variable tls_country aus dem TLS-Zertifikat des NCPeH Land-B MUSS gesetzt werden (siehe Kapitel [4.1.3.1 - Sicherer Kanal: TESTA-ng und TLS]) | Der folgende Wert MUSS gesetzt werden: "urn:iso:std:iso:3166" |
Keine Angaben |
| practitionerName | Der Wert der Variable ida_practitioner_name aus der Identity Assertion des LE-EU MUSS gesetzt werden (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) | Keine Angaben | Keine Angaben |
| practitionerRole | Ausgehend vom Wert der Variable ida_practitioner_role aus der Identity Assertion des LE-EU (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) MUSS der NCPeH-FD den Code in den Parameter aufnehmen. Der NCPeH-FD DARF NICHT die Bezeichnung aus dem Wert der Variable ida_practitioner_role dem Parameter zuweisen. Beispiel: Die Variable ida_practitioner_role kann folgenden Wert enthalten: "2262 - Pharmacists". Der Code aus dem Wert wird extrahiert, so dass dem Parameter "practitionerRole" unter dem Element valueCoding/code-Element der Wert 2262 gesetzt wird. |
Der folgende Wert MUSS gesetzt werden: "urn:oid:2.16.840.1.113883.2.9.6.2.7" |
Ausgehend vom Wert der Variable ida_practitioner_role aus der Identity Assertion des LE-EU (siehe Kapitel 4.1.5 - Validierung der Identity Assertion des LE-EU) MUSS der NCPeH-FD eine passende Bezeichnung in Deutsch nach Mapping-Regeln des BfArM ermitteln und in den Parameter aufnehmen. Der NCPeH-FD MUSS sicherstellen, dass nur menschen-lesbare Informationen (also keine Code-Werte) in den Parameter aufgenommen werden. |
| pointOfCare | Der Wert der Variable ida_point_of_care aus der Identity Assertion des LE-EU MUSS gesetzt werden (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) | Keine Angaben | Keine Angaben |
| healthcare-facility-type | Der NCPeH-FD MUSS auf Basis des Wertes aus der Variable ida_healthcare_facility_type aus der Identity Assertion des LE-EU (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) und den Mapping-Regeln des BfArM einen passenden Code aus [https://gematik.de/fhir/erp-eu/ValueSet/GEM_ERPEU_VS_HealthCareFacilityType] ermitteln und in den Parameter aufnehmen. | Der folgende Wert MUSS gesetzt werden: "https://gematik.de/fhir/directory/CodeSystem/OrganizationProfessionOID" |
Ausgehend vom Wert der Variable ida_healthcare_facility_type aus der Identity Assertion des LE-EU MUSS der NCPeH-FD eine passende Bezeichnung in Deutsch nach Mapping-Regeln des BfArM ermitteln und in den Parameter aufnehmen. Wenn ein Mapping nicht erfolgreich durchgeführt werden kann, dann MUSS der originale Texteintrag aus der Variable ida_healthcare_facility_type in den Parameter übernommen werden. |
[<=]
A_27247 - NCPeH - ePeD-A - Befüllung der Payload-Parameter für Aufruf der Operation /Task/
Der NCPeH-FD MUSS im inneren Request beim Aufruf der Operation /Task/<id>/$eu-close eine Payload nach dem FHIR-Profil [GEM_ERPEU_PR_PAR_CloseOperation_Input] erstellen, darin ein parameter-Element mit dem Namen requestData anlegen und innerhalb des Elements part-Elemente entsprechend den Vorgaben aus der Tabelle "TAB_NCPeH_Payload_Aufruf_Operation_Task_id_eu-close" erstellen und befüllen.
Tabelle 2 : TAB_NCPeH_Payload_Aufruf_Operation_Task_id_eu-close
| name | value oder code | system | display |
|---|---|---|---|
| kvnr | Der Wert aus der Variable trc_kvnr (siehe Kapitel [4.1.6 - Validierung der TRC-Assertion]) MUSS gesetzt werden |
Der folgende Wert MUSS gesetzt werden: "http://fhir.de/sid/gkv/kvid-10" |
Keine Angaben |
| accessCode | |
Der folgende Wert MUSS gesetzt werden: "https://gematik.de/fhir/erp/NamingSystem/GEM_ERP_NS_EU_AccessCode" |
Keine Angaben |
| countryCode | Der Wert der Variable tls_country aus dem TLS-Zertifikat des NCPeH Land-B MUSS gesetzt werden (siehe Kapitel [4.1.3.1 - Sicherer Kanal: TESTA-ng und TLS]) | Der folgende Wert MUSS gesetzt werden: "urn:iso:std:iso:3166" |
Keine Angaben |
| practitionerName | Der Wert der Variable ida_practitioner_name aus der Identity Assertion des LE-EU MUSS gesetzt werden (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) | Keine Angaben | Keine Angaben |
| practitionerRole | Ausgehend vom Wert der Variable ida_practitioner_role aus der Identity Assertion des LE-EU (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) MUSS der NCPeH-FD den Code in den Parameter aufnehmen. Der NCPeH-FD DARF NICHT die Bezeichnung aus dem Wert der Variable ida_practitioner_role dem Parameter zuweisen. Beispiel: Die Variable ida_practitioner_role kann folgenden Wert enthalten: "2262 - Pharmacists". Der Code aus dem Wert wird extrahiert, so dass dem Parameter "practitionerRole" unter dem Element valueCoding/code-Element der Wert 2262 gesetzt wird. |
Der folgende Wert MUSS gesetzt werden: "urn:oid:2.16.840.1.113883.2.9.6.2.7" |
Ausgehend vom Wert der Variable ida_practitioner_role aus der Identity Assertion des LE-EU (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) MUSS der NCPeH-FD eine passende Bezeichnung in Deutsch nach Mapping-Regeln des BfArM ermitteln und in den Parameter aufnehmen. Der NCPeH-FD MUSS sicherstellen, dass nur menschen-lesbare Informationen (also keine Code-Werte) in den Parameter aufgenommen werden. |
| pointOfCare | Der Wert der Variable ida_point_of_care aus der Identity Assertion des LE-EU MUSS gesetzt werden (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) | Keine Angaben | Keine Angaben |
| healthcare-facility-type | Der NCPeH-FD MUSS auf Basis des Wertes aus der Variable ida_healthcare_facility_type aus der Identity Assertion des LE-EU (siehe Kapitel [4.1.5 - Validierung der Identity Assertion des LE-EU]) und den Mapping-Regeln des BfArM einen passenden Code aus [https://gematik.de/fhir/erp-eu/ValueSet/GEM_ERPEU_VS_HealthCareFacilityType] ermitteln und in den Parameter aufnehmen. | Der folgende Wert MUSS gesetzt werden: "https://gematik.de/fhir/directory/CodeSystem/OrganizationProfessionOID" |
Ausgehend vom Wert der Variable ida_healthcare_facility_type aus der Identity Assertion des LE-EU MUSS der NCPeH-FD eine passende Bezeichnung in Deutsch nach Mapping-Regeln des BfArM ermitteln und in den Parameter aufnehmen. Wenn ein Mapping nicht erfolgreich durchgeführt werden kann, dann MUSS der originale Texteintrag aus der Variable ida_healthcare_facility_type in den Parameter übernommen werden. |
1.2.6 Neuaufnahme des Kapitels "4.2.10.6 Regelung zur Unterstützung von mehreren FHIR-Package Versionen"
Der NCPeH-FD setzt für ePeD-A FHIR-Profile aus den folgenden FHIR-Profil-Packages um:
- "kbv.ita.erp" [https://simplifier.net/erezept],
- "de.gematik.erezept.eu" [https://simplifier.net/erezept-workflow-eu].
Das Package "kbv.ita.erp" definiert das Datenmodell für Verordnungsdaten. Es wird durch die Kassenärztliche Bundesvereinigung (KBV) verantwortet und veröffentlicht. Die zeitliche Gültigkeit der Versionen des Packages "kbv.ita.erp" ist in [KBV_ITA_VGEX_Technische_Anlage_ERP] beschrieben. Eine neue Version des Package wird mit einem Vorlauf von 9 Monaten vor Gültigkeit in der Produktivumgebung veröffentlicht.
Für die Einführung in den Produktivbetrieb wird den Verordnungsausstellenden Leistungserbringerinstitutionen eine Übergangsfrist von mehreren Monaten nach Gültigkeitsbeginn (beim letzten Profilwechsel 6 Monate) eingeräumt. In diesem Zeitraum akzeptiert der E-Rezept-Fachdienst Verordnungen in der alten und neuen Profilversion. D.h. der NCPeH muss für diesen Zeitraum und zusätzlich für die Dauer der Gültigkeit der Verordnungen (maximal 365 Tage nach Ende des Übergangszeitraumes) in der Verarbeitung des Response der Operation POST /$get-eu-prescriptions mehrere (ggf. mehr als zwei) Profilversionen unterstützen.
In den Informationen zu einer Verordnung werden Wertekataloge (bspw. Darreichungsform) verwendet, welche durch die Informationsstelle für Arzneispezialitäten – IFA GmbH (IFA) veröffentlicht werden. Sie werden spätestens 3 Monate vor Gültigkeit in der Produktivumgebung veröffentlicht.
Das Package "de.gematik.erezept.eu" definiert das Datenmodell für die Übermittlung der Dispensierinformationen. Es wird durch die gematik verantwortet und veröffentlicht. Die zeitliche Gültigkeit der Versionen des Packages "de.gematik.erezept.eu" wird in [FHIR_Version_E-Rezept_EU] beschrieben. Eine neue Version des Package wird mit einem Vorlauf von 6 Monaten vor Gültigkeit in der Produktivumgebung veröffentlicht.
Für die Einführung in den Produktivbetrieb wird eine Übergangsfrist von 3 Monaten nach Gültigkeitsbeginn eingeräumt. D.h. der NCPeH muss innerhalb dieses Übergangszeitraumes die für die Operation POST /$get-eu-prescriptions und POST /Task/$eu-close unterstützte Profilversion von der alten auf die neue Profilversion umstellen.
Die Planung von neuen Profilversionen wird von der gematik auf [api-erp] veröffentlicht.
Hinweis: Für die Versionierung wurde vereinbart, dass in allen Profilen in einem Package die Major und Minor Versionen in der StructureDefinition vorhanden sind und mit der Major und Minor Version der Packageversion übereinstimmt. Das heißt mit jeder Änderung der Major oder Minor-Packageversion ändert sich auch die Profilversion. Bei einem Update der Patchversion des Packages bleiben die Profilversionen gleich.
Hinweise zu anstehenden Veränderungen in FHIR-Profilen sind auch in der [E-Rezept API-Dokumentation#Aktuelles] zu finden.
1.3 Änderung am Kapitel "4.2.7 Login in ein ePA-Aktenkonto"
1.3.1 Änderung am Kapitel "4.2.7.4 Aufbau eines VAU-Kanals zum ePA-Aktensystem"
<<Ablösung der Anforderung A_25729 durch A_25729-01>>
A_25729-01 - Aufbau neuer VAU-Kanal zu einem ePA-Aktensystem nur für genau einen NCPeH Land-B
Der NCPeH-FD MUSS sicherstellen, dass ein zu etablierender VAU-Kanal zu einem ePA-Aktensystem nur für genau einen NCPeH Land-B mit seiner zugeordneten TI-Identität aufgebaut und genutzt wird (siehe [4.2.9 Elektronische Identitäten des NCPeH-FD]). [<=]
1.3.2 Änderung am Kapitel "4.2.7.7 Authentifizierung mit dem ePA Authorization Service"
<<Ablösung der Anforderung A_25897 durch A_25897-01>>
A_25897-01 - Bindung des Authentifizierungsvorgangs an einen mit einem ePA Aktensystem etablierten VAU-Kanal
Der NCPeH-FD MUSS sicherstellen, dass pro etablierten VAU-Kanal mit einem ePA-Aktensystem nur genau ein Authentifizierungsvorgang mit einem Land-B erfolgt und somit der VAU-Kanal zur Nutzung an dieses Land-B gebunden ist. [<=]
1.4 Änderung am Kapitel "8.5.1 Dokumente der gematik"
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.
1.5 Änderung am Kapitel "8.5.2 Weitere Dokumente"
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
|---|---|
| [...] | |
| [KBV_ePKA_MIO_Format] | https://mio.kbv.de/display/PKA1X0X0/Patientenkurzakte+1.0.0 |
| [KBV_ITA_VGEX_Technische_Anlage_ERP] | KBV: TECHNISCHE ANLAGE ZUR ELEKTRONISCHEN ARZNEIMITTELVERORDNUNG (E16A) |
| [TA7_Anhang2] | Anhang 2 – FHIR Versionen zur Technischen Anlage 7 zur Arzneimittelabrechnungsvereinbarung gemäß § 300 Absatz 3 SGB V |
| [...] |
2 Informativ: Änderungen am gemProdT_NCPeH_FD
<<Über die Anpassungen in gemF_EU_eRp werden zusätzliche Anforderungen aus [gemILF_PS_eRp] und [gemSpec_Krypt] aufgeführt, die dem Produkttypsteckbrief gemProdT_NCPeH_FD zugewiesen werden.>>