Generelle Prinzipien

In diesem Abschnitt werden allgemeingültige Funktionsmerkmale des TI-Flow-Fachdienst und seinen Schnittstellen beschrieben.

Implementierung der Eingansprüfungen für Operationen

Im Rahmen von Operationaufrufen von Clientsystemen führt der TI-Flow-Fachdienst verschiedene Prüfungen durch, bevor der Zugriff auf die Daten erfolgt.

funkt. Eignung: Herstellererklärung Der TI-Flow-Fachdienst MUSS die Prüfungen in der folgenden Reihenfolge durchführen:

1. Prüfung zur Autorisierung
2. Prüfung Pre-condition
3. falls Eingangsartefakt signiert: Signaturprüfung
4. falls Eingangsparameter mit FHIR-Artefakten: FHIR-Validität prüfen
5. Prüfung von Business-Rules

Prüfung	Beispiele
Prüfung zur Autorisierung	Rollenprüfung, Prüfung accesscode/secret
Prüfung Pre-condition	Status des Task
FHIR-Validität prüfen	Prüfen des Datensatzes gegen das Profil "GEM_ERP_PR_MedicationDispense
Signaturprüfung	QES Prüfung bei Einstellen einer Verordnung
Prüfung von Business-Rules	MVO Parameter, PZN Format

Die konkret durchzuführenden Prüfungen sind als Anforderung für jede Operation spezifiziert.

RESTful API

funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS seine Schnittstellen für alle Zugriffe auf alle Datenobjekte und alle Ressourcen in einer RESTful API gemäß der FHIR-Spezifikation in http://hl7.org/fhir/http.html der Version v4.0.1 R4 umsetzen. funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS in seinen Schnittstellen für die Zugriffe durch Leistungserbringer und Leistungserbringerinstitutionen standardmäßig den MimeType application/fhir+xml akzeptieren und in Responses verwenden. funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS in seinen Schnittstellen für die Zugriffe durch Versicherte standardmäßig den MimeType application/fhir+json akzeptieren und in Responses verwenden. funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS in seinen Schnittstellen einen von der Standardfestlegung abweichenden MimeType umsetzen, wenn der jeweilige Client eine entsprechende Anforderung in der Aufrufschnittstelle über den URL-Parameter _format=fhir+xml bzw. _format=fhir+json gemäß http://hl7.org/fhir/http.html#general oder mittels des Accept-Attributs im HTTP-Request-Header als application/fhir+xml bzw. application/fhir+json anfordert, damit Clientsysteme ein für sie leichter verarbeitbares Format in der Antwort erhalten können. funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS über den Endpunkt `<modul>/metadata` das FHIR CapabilityStatement des TI-Flow-Fachdienst des jeweilgen Anwendungsmoduls zurückgeben.

Hinweis: Das Capability Statement bietet eine detaillierte Beschreibung der Fähigkeiten des TI-Flow-Fachdienst und ist entscheidend für das Verständnis der unterstützten FHIR-Funktionalitäten. Je Anwendungsmodul (bspw. Arzneimittel oder DiGA) wird ein eigenes CapabilityStatement bereitgestellt.

Verordnungs-ID

Die Verordnungs-ID wird durch den TI-Flow-Fachdienst beim Anlegen eines Tasks für den Workflow der Verordnung erstellt.

funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS Verordnungs-IDs erzeugen und verwalten, welche der Syntax "aaa.bbb.bbb.bbb.bbb.cc" und der folgenden Semantik genügen

	Bedeutung	Datentyp
aaa	Workflow-Typ	alphanummerisch, mit der Belegung gemäß "flowType" in https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_FlowType
bbb.bbb.bbb.bbb	fortlaufende Nummer	nummerisch, 12-stellig
cc	Prüfnummer Verfahren gemäß [ISO 7064]	nummerisch

damit Tippfehler in der manuellen Erfassung erkannt werden können und die Verordnungs-ID über 11 Jahre eine eineindeutige Zuordnung zwischen allen Datenobjekten im Workflow erlaubt.

Für den Übergang der Anwendung E-Rezept vom E-Rezept-Fachdienst zum TI-Flow-Fachdienst muss es für ein ClientSystem möglich sein zu erkennen, auf welchem Fachdienst ein Task eingestellt wurde, ohne diesen vorher abzufragen.

Der TI-Flow-Fachdienst erzeugt Tasks für jeden Workflow > <flowtype>.010.000.000.000.<prüfziffer>. Siehe hierzu auch die Anforderungen des TI-Flow-Fachdienst für die $create-Operation.

funkt. Eignung: Test Produkt/FA Alle Produkttypen, die eine Verordnungs-ID aus externen Systemen einlesen oder von Benutzern entgegen nehmen, MÜSSEN die Verordnungs-ID gegen ihre Prüfziffer nach dem Modulo-97-Verfahren gemäß [ISO 7064] prüfen und bei Ungültigkeit die Weiterverarbeitung verhindern, damit Benutzerfehleingaben vor der Verarbeitung erkannt werden.

Verarbeitung von Datensätzen

Es gelten folgende Anforderungen und Vorgaben zur Verarbeitung und Interpretation von Zeichen- und Datensätzen im TI-Flow-Fachdienst.

Für die Kommunikation und die Interoperabilität müssen bezüglich Datensätzen einheitliche Vorgaben gelten. Laut FHIR Spezifikation wird für XML und JSON Datensätze das Character Encoding "UTF-8" vorgegeben. Byte Order Marks (BOM) werden nicht angeben.

funkt. Eignung: Test Produkt/FA Der TI‑Flow‑Fachdienst MUSS eingehende Datensätze strikt als UTF‑8 ohne Byte Order Mark (BOM) decodieren und bei fehlgeschlagener Decodierung oder beim Vorhandensein eines BOM die Verarbeitung mit dem folgenden Fehler:

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

abbrechen.

Diese Anforderung zur Verarbeitung von Datensätzen ohne BOM gilt auch, wenn PKCS#7 Container deserialisiert werden.

funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS beim Verarbeiten von PKCS#7 Enveloping-Daten die Anforderungen zur Verarbeitung von Datensätzen im TI-Flow-Fachdienst anwenden.

Für die Erstellung von Datensätzen gelten für Clientsysteme folgende Anforderungen.

funkt. Eignung: Konformitätsbestätigung funkt. Eignung: Konformitätsbestätigung funkt. Eignung: Konformitätsbestätigung funkt. Eignung: Test Produkt/FA funkt. Eignung: Test Produkt/FA Clientsysteme des TI-Flow-Fachdienstes MÜSSEN für die Kommunikation mit dem TI-Flow-Fachdienst ausschließlich das Character Encoding UTF-8 verwenden. funkt. Eignung: Konformitätsbestätigung funkt. Eignung: Konformitätsbestätigung funkt. Eignung: Konformitätsbestätigung funkt. Eignung: Test Produkt/FA funkt. Eignung: Test Produkt/FA Clientsysteme des TI-Flow-Fachdienstes DÜRFEN für die Kommunikation mit dem TI-Flow-Fachdienst in Datensätzen ein Byte Order Mark (BOM) NICHT angeben.

Verarbeitung von FHIR Ressourcen

Verarbeitung von Datumsangaben

In der Verarbeitung der FHIR-Ressourcen ist es wichtig, dass Datums- und Zeitangaben konsistent und eindeutig interpretiert werden.

Aufgrund der Profilierung einiger Datenfelder kommt es vor, dass keine Zeitzoneninformation im Datum enthalten ist. Diese Zeitangaben sollen gemäß der zum jeweiligen Datum gültigen deutschen Zeit (CET/CEST) interpretiert werden. Diese Regelung stellt sicher, dass alle beteiligten Systeme einheitlich und korrekt mit Datums- und Zeitangaben umgehen, unabhängig davon, ob die Angaben in der Vergangenheit oder Gegenwart liegen.

funkt. Eignung: Herstellererklärung funkt. Eignung: Herstellererklärung funkt. Eignung: Herstellererklärung funkt. Eignung: Herstellererklärung funkt. Eignung: Herstellererklärung Clientsysteme des TI-Flow-Fachdienstes MÜSSEN bei der Verarbeitung von FHIR-Ressourcen der Anwendung E-Rezept sicherstellen, dass Datumsangaben ohne explizite Zeitzoneninformationen gemäß der zum jeweiligen Datum gültigen deutschen Zeit (CET/CEST) verarbeitet werden.

Filtern und Sortieren von FHIR-Objekten

Clients erhalten die Möglichkeit, die Rückgabe der Elemente im FHIR-Bundle durch Suchparameter zu filtern und mithilfe von Sortierparameter zu sortieren.

funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS die Suchparameter verarbeiten können, wie sie im CapabilityStatement festgelegt sind. funkt. Eignung: Test Produkt/FA Der TI-Flow-Fachdienst MUSS die Sortierparameter verarbeiten können, wie sie im CapabilityStatement festgelegt sind.

Identifikation des Nutzers

Im Rahmen des Verbindungsaufbaus eines Clientsystems mit dem TI-Flow-Fachdienst authentisiert sich der Nutzer. Der ZETA-Guard übermittelt die Informationen zum Nutzer und das Clientsystem in Http-Headern im Request an den Resource Server (siehe [gemSpec_ZETA#A_25669-*]).

Folgende Informationen sind im Header zeta-user-info enthalten. (siehe zeta-user-info.yaml)

Attribut	Beschreibung	optional
identifier	Telematik-ID, KVNR or other unique identifier	nein
professionOID	Profession identifier (OID)	nein
commonName	Kurzname der Institution	nein
organizationName	Name der Organisation oder Institution	ja

funkt. Eignung: Herstellererklärung Der TI-Flow-Fachdienst MUSS den Http-Header zeta-user-info auswerten, um die Informationen zum Nutzer für die weitere Verarbeitung zu ermitteln.

Die Information zum aufrufenden Nutzer/Institution wird bspw. bei der Prüfung von Autorisierungsregeln (Prüfung der professionOID) und bei der Zugriffsprotokollierung für den Versicherten verwendet.

Folgende Informationen sind im Header zeta-client-data enthalten. (siehe client-data.yaml)

Attribut	Beschreibung	optional
client_id	client identifier	nein
product_id	product identifier	nein
product_version	product version	nein
platform	platform of client instance	ja

funkt. Eignung: Herstellererklärung Der TI-Flow-Fachdienst MUSS den Http-Header zeta-client-data auswerten, um die Informationen zum Clientsystem für die weitere Verarbeitung zu ermitteln.

Die Information zum aufrufenden Clientsystem wird bspw. für die Betriebsdatenerfassung genutzt.