FD-Anforderungen: Communication-Query

Diese Seite enthält die normativen Anforderungen an den TI-Flow-Fachdienst für die Communication-Query-Endpunkte.

Anforderungen aus der Core Spezifikation

Diese Seite enthält die normativen Anforderungen an den TI-Flow-Fachdienst für den Communication-Endpunkt.

Der TI-Flow-Fachdienst MUSS alle Zugriffe auf die Ressource Communication mittels der HTTP-Operationen PUT, PATCH und HEAD unterbinden und mit mit dem HTTP-Code "405 - Method Not Allowed" abbrechen, damit keine unzulässigen Operationen ausgeführt werden können. Der TI-Flow-Fachdienst MUSS beim Aufruf der HTTP-GET, DELETE und POST-Operation auf den Endpunkt /Communication bzw. /Communication/<id> die zeta-user-info.professionOID des Nutzers bestimmen und sicherstellen, dass ausschließlich Nutzer in der Rolle

• oid_versicherter
• oid_oeffentliche_apotheke
• oid_krankenhausapotheke
• oid_kostentraeger

die Operation am Fachdienst aufrufen und bei Abweichungen die Operation mit dem folgenden Fehler:

HTTP-Code	403 - Forbidden
Severity	error
Code	invalid
Details Code	TIFLOW_AUTH_ROLE_NOT_ALLOWED
Details Text	Der Nutzer ist nicht berechtigt, die aufgerufene Operation anzufordern

abbrechen, damit der Nachrichtenaustausch nicht zwischen Unbefugten erfolgt.

GET /Communication

Der TI-Flow-Fachdienst MUSS beim Abrufen von Nachrichten über die http-Operation GET auf den Endpunkt /Communication bzw. beim Abruf einer einzelnen Nachricht über /Communication/<id> ausschließlich die Nachrichten an den Aufrufer zurückgeben, die im Attribut Communication.recipient oder Communication.sender mit dem entsprechenden Identifier https://gematik.de/fhir/sid/telematik-id für Apotheken bzw. http://fhir.de/sid/gkv/kvid-10 für Versicherte den gleichen Typ und den identischen Wert haben wie zeta-user-info.identifier in den Nutzerinformationen, damit keine Nachrichten an Dritte unrechtmäßig ausgelesen werden. Der TI-Flow-Fachdienst MUSS beim Abrufen von Nachrichten über die http-Operation GET auf den Endpunkt /Communication bzw. beim Abruf einer einzelnen Nachricht über /Communication/<id> den Wert des Attributs Communication.received = <aktuelle Systemzeit&gt setzen, wenn dieser Wert zum Zeitpunkt des Abrufs der Nachrichten NULL ist, damit Nutzer eine Filtermöglicheit auf "neue Nachrichten" haben.

POST /Communication

Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication die im http-Request-Body übergebene Communications-Ressource gegen das aus der Kommunikationsbeziehung ableitbare, zulässige Schema gemäß TAB_eRPFD_008 prüfen und den Aufruf bei Nicht-Konformität die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	SVC_VALIDATION_FAILED
Details Text	FHIR Profile Validation Failed

abbrechen, damit ausschließlich konforme E-Rezept-Nachrichten ausgetauscht werden.

sender	recipient	zusätzliche Bedingung	Schema
KVNR	Telematik-ID	Communication.basedOn referenziert Task	https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq
Telematik-ID	KVNR	Communication.basedOn referenziert Task	https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Reply https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DiGA
KVNR	Telematik-ID	Communication.basedOn referenziert ChargeItam	https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReq
Telematik-ID	KVNR	Communication.basedOn referenziert ChargeItam	https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReqReply

Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication, falls die Ressource dem GEM_ERP_PR_Communication_DispReq-Profil entspricht, den Inhalt der contentString-Eigenschaft auf valides JSON sowie gegen die Struktur in "Tabelle: E-Rezept einer Apotheke zuweisen" überprüfen und bei negativem Prüfergebnis, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	SVC_VALIDATION_FAILED
Details Text	FHIR Profile Validation Failed

abbrechen sowie mit einer aussagekräftigen Fehlermeldung in Form einer eingebetteten OperationOutcome-Ressource antworten. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication, falls die Ressource dem GEM_ERP_PR_Communication_Reply-Profil entspricht, den Inhalt der contentString-Eigenschaft auf valides JSON sowie gegen die Struktur in "Tabelle: Nachricht als Apotheke an einen Versicherten schicken" überprüfen und bei negativem Prüfergebnis, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	SVC_VALIDATION_FAILED
Details Text	FHIR Profile Validation Failed

abbrechen sowie mit einer aussagekräftigen Fehlermeldung in Form einer eingebetteten OperationOutcome-Ressource antworten. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication die Absenderidentifikation aus dem zeta-user-info.identifier der Nutzerinformation mit dem entsprechenden System https://gematik.de/fhir/sid/telematik-id für Institutionen der TI bzw. http://fhir.de/sid/gkv/kvid-10 für Versicherte übernehmen sowie das Absendedatum Communication.sent auf die aktuelle Systemzeit des TI-Flow-Fachdienstes setzen, damit Absender und Sendezeitpunkt für den Empfänger eindeutig sind. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication den Empfänger prüfen und, wenn der Empfänger Communication.recipient gleich der Absenderidentifikation zeta-user-info.identifier in der Nutzerinformation ist, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_MESSAGE_TO_SELF
Details Text	-

abbrechen, damit irreführende Kommunikationsbeziehungen nicht zu einer vermeidbaren Mehrbelastung des TI-Flow-Fachdienstes führen. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication die Nachricht prüfen und, wenn

• der Nachrichteninhalt Communication.payload größer als 10 kByte ist oder
• in von Versicherten eingestellten Nachrichten in Communication.payload eine externe URLs enthält oder
• ein Attachment mit MimeType "application/*" enthält,

, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_COMMUNICATION_PAYLOAD_INVALID
Details Text	-

abbrechen, damit über den TI-Flow-Fachdienst kein Schadcode verteilt wird. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq" durch einen Versicherten über die http-Operation POST auf den Endpunkt /Communication den Versichertenbezug prüfen und, wenn die KVNR des in Communication.basedOn referenzierten Tasks Task.for ungleich der KVNR des Einstellenden in zeta-user-info.identifier in der Nutzerinformation ist, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_INSURANT_NOT_ELIGIBLE
Details Text	-

abbrechen, um irreführende Testnachrichten zu unterbinden, die eine vermeidbare Mehrbelastung für den TI-Flow-Fachdienst darstellen. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq" durch einen Versicherten über die http-Operation POST auf den Endpunkt /Communication die Zulässigkeit der Übermittlung auf Basis des Flowtypes des referenzierten Tasks (Task.extension:flowType) und dem Empfänger Communication.recipient prüfen und, wenn der Empfänger laut TAB_eRPFD_028 den spezifischen Flowtype nicht empfangen darf, die Operation mit dem folgenden Fehler:

HTTP-Code	403 - Forbidden
Severity	error
Code	invalid
Details Code	TIFLOW_RECIPIENT_INVALID
Details Text	-

abbrechen.

Empfänger (Präfix der Telematik-ID)	Zulässige Flowtypes
oid_oeffentliche_apotheke (3-*, 9-*)	160, 166, 200
oid_kostentraeger (8-*)	162

Der Fachdienst E-Rezept MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq", "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_Reply" oder "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DiGA" über die http-Operation POST auf den Endpunkt /Communication prüfen und, wenn das Pflichtfeld Communication.basedOn einen Task referenziert, der nicht existiert, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_TASK_NOT_FOUND
Details Text	-

abbrechen, um Spam und nicht-verordnungsbezogene Kommunikation zu verhindern. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication mit GEM_ERP_PR_Communication_DispReq-Ressource für den in Communication.basedOn referenzierten Task prüfen und, wenn Task.status ungleich ready ist, die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_TASK_STATUS_MISMATCH
Details Text	Task has invalid status.

abbrechen, damit ausschließlich E-Rezepte zugewiesen werden, welche durch den Adressaten abrufbar sind. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication mit GEM_ERP_PR_Communication_DispReq-Ressource für den in Communication.basedOn referenzierten Task prüfen, dass Task.ExpiryDate nicht zu einem früheren Zeitpunkt als dem aktuellem Datum liegt und anderenfalls die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_TASK_EXPIRED
Details Text	Task has expired.

abbrechen, damit ausschließlich E-Rezepte zugewiesen werden, welche deren Einlösefrist noch nicht erreicht ist. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht über die http-Operation POST auf den Endpunkt /Communication mit GEM_ERP_PR_Communication_DispReq-Ressource für den in Communication.basedOn referenzierten Task prüfen, falls die Verordnung als Mehrfachverordnung (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = true) gekennzeichnet ist, ob der Beginn der Einlösefrist (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.start) zum aktuellen oder einem früheren Zeitpunkt als das aktuelle Datum liegt und anderenfalls die Operation mit dem folgenden Fehler:

HTTP-Code	400 - Bad Request
Severity	error
Code	invalid
Details Code	TIFLOW_MVO_NOT_VALID_YET
Details Text	Prescription is not fillable yet.

abbrechen, damit ausschließlich E-Rezepte zugewiesen werden, deren Einlösefrist erreicht ist. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht des Profils "https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Communication_DispReq" oder "https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Communication_ChargChangeReq" zur Versicherter-zu-Apotheken-Kommunikation über die http-Operation POST auf den Endpunkt /Communication prüfen, ob für die Telematik-ID des Empfängers Subscriptions registriert sind und für Registrierungen über den Subscription Service eine Notification (ping : subscription-id) senden. Der TI-Flow-Fachdienst MUSS beim Einstellen einer Nachricht mittels HTTP-POST-Operation über /Communication bei erfolgreichem Abschluss der Operation, den Push Notification Prozess für den Trigger mit der ChannelId "erp.communication.new" und den Versicherten mit der KVNR = Communication.recipient initiieren.

DELETE /Communication

Mit der HTTP-Operation DELETE kann ein Nutzer eine verschickte Kommunikationsnachricht als Absender löschen, um bspw. einen Irrläufer zurückzurufen.

Der TI-Flow-Fachdienst MUSS beim Aufruf der HTTP-DELETE-Operation auf /Communication/<id> die über <id> identifizierte Communication-Ressource anhand der KVNR bzw. Telematik-ID des aufrufenden Nutzers in zeta-user-info.identifier über das Absender-Attribut Communication.sender lokalisieren und löschen, damit Nutzer irrtümlich versendete oder nicht mehr gewünschte Nachrichten vom TI-Flow-Fachdienst entfernen können.

Modulspezifische Anforderungen

POST /Communication

Für Prüfung Payload siehe Datenmodell Payload für Communication-Query