Zur Übertragung von Daten vom TI-Flow-Fachdienst an die T-Register Schnittstellen des BfArM Webdienst gelten die folgenden Anforderungen:
Authentifizierung für die Dienste des BfArM
Der TI-Flow-Fachdienst nutzt den OAuth 2.0 Client Credentials Flow nach OAuth 2.0 RFC 6749, section 4.4 zur Authentifizierung an den Diensten des BfArM.
Über einen organisatorischen Prozess müssen Client Credentials beim BfArM angefragt werden, welche zur Authentifizierung des TI-Flow-Fachdienst ggü. dem BfArM Webdienst genutzt werden.
Der Anbieter des TI-Flow-Fachdienst MUSS sich über einen organisatorischen Prozess Client Credentials für den Zugriff auf den BfArM Webdienst beim BfArM registrieren.
Die technische Authentifizierung erfolgt dann über den /token Endpunkt, der durch Angabe der Client Credentials dann einen AccessToken ausstellt. Mit diesem AccessToken ist der TI-Flow-Fachdienst berechtigt Daten am BfArM Webdienst einzustellen.
Abbildung: Authentifizierung BfArM Webdienst
Der TI-Flow-Fachdienst MUSS vor dem Zugriff auf den BfArM Webdienst prüfen, ob der zuletzt bezogene AccessToken noch gültig ist und im Falle der Ungültigkeit einen neuen AccessToken über den /ords/rezepte/oauth/token Endpunkt am BfArM Webdienst beziehen.
Der TI-Flow-Fachdienst MUSS zum Beziehen eines AccessTokens den Endpunkt /ords/rezepte/oauth/token am BfArM Webdienst mit folgenden Parametern aufrufen:
, um einen AccessToken für den Zugriff auf den BfArM Webdienst zu beziehen.
Der TI-Flow-Fachdienst MUSS für den Zugriff auf den BfArM Webdienst einen AccessToken für die Authentifizierung im HTTP-Header wie folgt angeben:
Authorization: Bearer <AccessToken vom Token Endpunkt>
, um auf die Endpunkte des BfArM Webdienstes zugreifen zu können.
Lokalisierung
Der TI-Flow-Fachdienst MUSS einen Konfigurationsparameter BfArM_Domain für die Domain des BfArM Webdienstes verwalten.
Der Defaultwert für den Parameter ist https://webapps-public.bfarm.de.
Der TI-Flow-Fachdienst MUSS zur Lokalisierung des BfArM Webdienstes die im DNS für BfArM_Domain eingestellten Informationen aufrufen.
Bereitstellung digitaler Durchschlag
Nach Abschluss eines Workflows 166 durch Aufrufen der $close Operation erstellt der TI-Flow-Fachdienst den digitalen Durchschlag für den Vorgang des E-T-Rezeptes. Die fachlichen Informationen hierzu sind im Dokument [gemF_eRp_T-Rezept] dokumentiert.
Der TI-Flow-Fachdienst MUSS sicherstellen, dass ausschließlich Daten zu Tasks mit dem Flowtype 166 für den Webdienst des BfArM bereitgestellt werden.
Der TI-Flow-Fachdienst MUSS das Übermitteln der Daten an den BfArM Webdienst asynchron zur Bereitstellung der Daten durch die Clientsysteme umsetzen, damit für das bereitstellende Primärsystem der abgebenden Leistungserbringerinstitution keine verlängerte Verarbeitungsdauer der auslösenden Operation auftritt.
Der digitale Durchschlag zum T-Rezept ist ein Artefakt, welches Informationen zum Vorgang eines E-T-Rezeptes bündelt und gesammelt an das BfArM übermittelt.
Als Datengrundlage für diesen Durchschlag dient der Verordnungsdatensatz samt QES, der Dispensierdatensatz, der Task der Verordnung und Daten der Apotheke aus dem FHIR-VZD. Als Kriterium für die Suche nach Apothekendaten im FHIR-VZD wird die Telematik-ID der Apotheke genutzt.
Der TI-Flow-Fachdienst MUSS für das Bereitstellen eines digitalen Durchschlags für ein E-T-Rezept die Daten der abgebenden Apotheke aus dem Verzeichnisdienst ermitteln, indem an den Verzeichnisdienst folgende Abfrage gestellt wird:
Abfrage der Ressource "HealthcareService",
HealthcareServices, deren Organisation aktiv sind,
HealthcareServices, deren origin tag = ldap ist,
HealthcareServices, deren Organisation als Identifier die Telematik-ID trägt, die im Dispensierdatensatz angegeben wurde,
Einbeziehen der Organisation in das Rückgabeergebnis,
Als Antwort erhält der TI-Flow-Fachdienst mit dieser Anfrage genau drei Ressourcen: Organization, HealthcareService und Location, welche die benötigten Daten zur Apotheke für den digitalen Durchschlag enthalten. Alle Daten sind optional im FHIR-VZD eingetragen, d.h. wenn die Daten nicht vorhanden sind, müssen diese nicht im digitalen Durchschlag enthalten sein.
Anschließend erstellt der TI-Flow-Fachdienst den digitalen Durchschlag für den BfArM Webdienst. Dieser basiert auf einem definierten FHIR-Profil.
Der TI-Flow-Fachdienst MUSS beim Bereitstellen eines digitalen Durchschlag für ein T-Rezept an den BfArM Webdienst einen Datensatz nach dem Profil ERP_TPrescription_CarbonCopy erzeugen.
Der TI-Flow-Fachdienst MUSS den Anwendungsfall "Übertragen des digitalen Durchschlags" gemäß Tabelle TAB_eRPFD_029 ausführen.
Name
Übertragen des digitalen Durchschlags
Auslöser
Abschluss eines E-Rezept Workflows mit Flowtype 166 via Aufruf der $close-Operation
Akteur
TI-Flow-Fachdienst
Vorbedingung
Dem TI-Flow-Fachdienst liegen Client Credentials des BfArM zur Authentifizierung vor
Verordnungsdaten, Dispensierinformationen und Informationen aus dem FHIR-VZD liegen vor
Ein gültiger AccessToken für den Zugriff auf den BfArM Webdienst liegt vor
Nachbedingung
Am BfArM Webdienst wurde der digitale Durchschlag E-T-Rezept erfolgreich übertragen.
Standardablauf
Prüfen, ob ein gültiger AccessToken vorliegt.
Falls nicht: Client Credentials an den Token-Endpunkt übertragen.
AccessToken speichern.
Erzeugen des digitalen Durchschlags E-T-Rezept.
Auftrag zur Übertragung des digitalen Durchschlags E-T-Rezept in einer Warteschlange einstellen.
Aufruf des Endpunktes /ords/rezepte/t-rezept/v1.
Nach erfolgreicher Übertragung: Löschen des Auftrags aus der Warteschlange.
Tabelle: title
Der TI-Flow-Fachdienst MUSS für das Übertragen eines digitalen Durchschlags den BfArM Webdienst RESTful wie folgt aufrufen:
HTTP-Parameter
Wert
Methode
POST
Endpunkt
/ords/rezepte/t-rezept/v1
Header
Authorization: Bearer <AccessToken>
Content-Type: application/fhir+json
X-Request-ID: <random-uuid>
Body
<digitaler Durchschlag E-T-Rezept>
Fehlerbehandlung
Bei der Suche nach Apothekendaten basierend auf der Telematik-lD besteht die Möglichkeit, dass im FHIR-VZD kein Eintrag gefunden wird Falls zu der zu übermittelnden Apotheke (Identifikation durch die Telematik-lD) kein entsprechender Eintrag im FHIR-VZD gefunden werden kann, setzt der TI-Flow-Fachdienst folgendes um:
Die betroffene Telematik-ID wird unverändert in den digitalen Durchschlag aus den Dispensierinformationen übernommen.
Der Wert für commonName aus den Nutzerinformationen der Anfrage (zeta-user-info) wird als Name der Apotheke im digitalen Durchschlag gesetzt. Sollte der commonName in den Nutzerinformationen nicht gesetzt sein (NULL), dann wird “unbekannt” als Name der Apotheke im digitalen Durchschlag gesetzt.
Der Datensatz wird an den BfArM-Webdienst übertragen.
Sollte der übermittelte Datensatz durch das BfArM untersucht werden müssen, erfolgt eine bilaterale Abstimmung zwischen gematik und BfArM zur Klärung des Sachverhalts.
Der TI-Flow-Fachdienst MUSS für das Bereitstellen eines digitalen Durchschlags für ein E-T-Rezept, wenn die Daten der abgebenden Apotheke nicht aus dem Verzeichnisdienst ermittelt werden können,
die Telematik-ID der Apotheke aus den Dispensierinformationen und
den Wert für zeta-user-info.commonName aus Nutzerinformationen bzw. falls zeta-user-info.commonName = NULL den Wert "unbekannt" als Name der Apotheke
in den digitalen Durchschlag übernehmen.
Dieses Vorgehen stellt sicher, dass die Übertragung an das T-Register nicht aufgrund eines fehlenden FHIR-VZD-Eintrags blockiert wird und gleichzeitig die Nachvollziehbarkeit über die Telematik-ID gewährleistet bleibt.
Der TI-Flow-Fachdienst MUSS die Datenübermittlung an den BfArM Webdienst für mindestens eine Minute unterbrechen, wenn ein Aufruf mit dem Statuscode 500 oder 429 scheitert. Bei anhaltenden Problemen MUSS der TI-Flow-Fachdienst einen exponentiellen Backoff-Mechanismus anwenden, der die Wartezeit zwischen den Versuchen sukzessive verdoppelt, um die Systembelastung zu minimieren.
Der TI-Flow-Fachdienst MUSS den Aufruf am BfArM Webdienst als fehlerhaft kennzeichnen und eine detaillierte Fehlermeldung für interne Analysezwecke protokollieren, wenn der BfArM Webdienst auf einen Operationsaufruf mit einem Statuscode 400 (Bad Request) oder 422 (Unprocessable Entity) reagiert.