Einführung in das App-Transport-Framework

Ziel: Überzeugung zukünftiger Implementierer zu den Vorteilen eines Frameworks für die dezentrale Kommunikation in der TI

Was ist das ATF?

Das App-Transport-Framework (ATF) ist ein Framework, das speziell entwickelt wurde für:

strukturierter dezentraler Datenaustausch: Es ermöglicht den Austausch von komplexen strukturierten Daten, die auf FHIR (Fast Healthcare Interoperability Resources) basieren, und fördert somit eine nahtlose und standardisierte Kommunikation.
Automatisierte Kommunikation (Dunkelverarbeitung): Ermöglicht direkten Datenaustausch zwischen datenhaltenden Systemen, ohne dass menschliche Benutzer in den Prozess involviert sind.
Unterstützung definierter Use Cases: ATF bildet die Basis für klar definierte Use Cases, die spezifische Anforderungen und Rahmenbedingungen für die Datenübertragung festlegen.
Medienunabhängigkeit: Seine Funktionalität ist bewusst unabhängig vom Übertragungsmedium gestaltet.

Vorteile der dezentralen Kommunikation

Die dezentrale Kommunikation bietet folgende Vorteile:

Bessere Kommunikation (vor dem Versand): Der Sender einer Nachricht erhält vom Empfänger die Bestätigung, dass die Nachricht verarbeitet werden kann und der Use Case unterstützt wird.
Bessere Kommunikation (nach dem Versand): Der Sender erhält vom Empfänger die Bestätigung, dass die Nachricht gelesen und verarbeitet wurde.
Direkte Kommunikation: Sender und Empfänger stehen in direktem Austausch und können bei Bedarf auf manuelle Kommunikation wechseln.
Hohe Nachnutzbarkeit der Kommunikationsinfrastruktur: Die anfänglichen Implementierungsaufwände der dezentralen Kommunikation (ATF) entfallen für zukünftige Use Cases.
Einfachere Erweiterung um weitere Use Cases: Die Spezifikation und Umsetzung neuer Use Cases werden vereinfacht, da die Notwendigkeit eines zentralen Dienstes entfällt.

Welches Problem löst das ATF?

Herausforderung der Validierung in Peer-to-Peer Netzwerken

In zentralisierten Systemen übernimmt ein zentraler Server die Validierung eingehender Informationen. In Peer-to-Peer Netzwerken fehlt ein solcher Kontrollpunkt, was spezifische Herausforderungen mit sich bringt:

Dezentrale Validierung: Der Empfänger einer Nachricht fungiert als validierende Instanz für den Sender. Das ATF unterstützt den Empfänger dabei, Validierungsfehler über ein klares Protokoll zu kommunizieren, um eine schnelle Fehlererkennung und -behebung zu ermöglichen.
Fehlerkommunikation: Fehler müssen verständlich an die richtigen Adressaten übermittelt werden. Das ATF schafft einen strukturierten Rahmen für den Austausch von Informationen zur Validität und zum Verarbeitungsstatus von Nachrichten zwischen Sender und Empfänger. Zusätzlich werden die Kontaktinformationen der verantwortlichen Implementierer bereitgestellt, um eine effiziente Fehlerbehebung zu ermöglichen.
Zentrale Fehlerkommunikation und Eskalation: Der Herausgeber des jeweiligen Use Cases (z. B. die Gematik) stellt und pflegt eine Plattform, um Implementierer zu vernetzen, sodass sie sich bei der Entwicklung und dem Testen des jeweiligen Anwendungsfalls gegenseitig unterstützen können.

Wie funktioniert das ATF?

Kernfunktionen und Prozesse:

Das ATF nutzt standardisierte Prozesse für die Systemkommunikation, die speziell auf einzelne Anwendungsfälle zugeschnitten sind:

Verzeichnisdienst (VZD): Im VZD wird hinterlegt, welche KIM-Adressen das ATF unterstützen.
Capability-Message: Der Sender einer Nachricht kann automatisiert beim Empfänger nachfragen, ob der gewünschte Use Case unterstützt wird. Hierbei wird ein CodeSystem zur Anzeige der unterstützen Anwendungsfälle verwendet.
Kapselung der Anwendungsfalldaten: Das ATF fasst die FHIR-Ressourcen eines Anwendungsfalls in einer übergeordneten Ressource (FHIR Bundle) zusammen und integriert relevante Metadaten im Kopfbereich dieser Ressource.
Nachrichten-Repräsentation: Jede ATF-Nachricht verwendet ein im Use Case definiertes CodeSystem, um die spezielle Nachricht des Anwendungsfalls zu repräsentieren.
Empfangsbestätigungen: Jede Nachricht erhält automatisch eine standardisierte Bestätigung, die über die erfolgreiche Verarbeitung oder Fehler informiert und so die Sicherheit und Qualität der Kommunikation erhöht.
Zuordenbarkeit: Jede Nachricht kann einer sendenden Software und einem Hersteller zugeordnet werden, der über eine angegebene Adresse kontaktiert werden kann.
Fallback-Szenario: Jeder Nachrichtentyp kann (wenn im Use Case definiert) über eine XSLT-Definition in ein HTML überführt werden, um den Nachrichteninhalt menschenlesbar zu machen. Der Anhang wird neben dem FHIR-Datensatz bereitgestellt.

Beispiel: Ablauf Rezeptanforderung und -übermittlung - "Happy Case"

Schritt 1: Das Primärsystem der Pflegeeinrichtung (PSP) ermittelt im VZD die KIM-Adresse(n) des Arztes, welche das ATF unterstützen.

Schritt 2: Das PSP sendet eine Capability-Abfrage an die ATF-Adresse(n) der Arzt-Praxis, um die Unterstützen Use Cases zu ermitteln.

Schritt 3: Das Praxisverwaltungssystem (PVS) antwortet mit den unterstützen Use Cases und signalisiert, dass es die Rezeptanforderung unterstützt.

Schritt 4: Das PSP sendet eine Rezeptanforderung an das PVS des Arztes.

Schritt 5: Das PVS des Arztes schickt eine ATF-Empfangsbestätigung an das PSP und bestätigt, dass die Daten erfolgreich verarbeitet werden konnten.

Schritt 6: Das PSP interpretiert die erfolgreiche ATF-Empfangsbestätigung und informiert den Nutzer, dass es keine technischen Probleme bei der Verarbeitung der Anfrage gab.

Schritt 7: Der Arzt stellt das Rezept aus und übermittelt sowohl die Rezeptanforderung als auch das Rezept über das PVS an das PSP der Pflegeeinrichtung.

Schritt 8: Das PSP schickt eine ATF-Empfangsbestätigung an das PVS und bestätigt, dass die Daten erfolgreich verarbeitet werden konnten.

Schritt 9: Das PVS interpretiert die erfolgreiche ATF-Empfangsbestätigung und informiert den Nutzer, dass es keine technischen Probleme bei der Verarbeitung der Anfrage gab.

Beispiel: Ablauf Rezeptanforderung und -übermittlung - "Happy Case"

Beispiel: Korrektur einer fehlerhaften Rezeptanforderung

Schritt 1-3: Die Schritte zur Ermittlung der Adresse und des unterstützten Use Cases bleiben identisch.

Schritt 4: Das Primärsystem der Pflegeeinrichtung (PSP) sendet versehentlich eine fehlerhafte Rezeptanforderung (z.B. ein Pflichtfeld ist nicht befüllt) an das Praxisverwaltungssystem (PVS) des Arztes.

Schritt 5: Beim Versuch, die Anforderung zu verarbeiten, stellt das PVS des Arztes durch die FHIR-Validierung fest, dass ein Fehler in der Anforderung vorliegt.

Schritt 6: Das PVS sendet automatisch eine Empfangsbestätigung an das PSP, die auf den spezifischen Fehler in der Rezeptanforderung hinweist.

Schritt 7: Der Nutzer des PSP erhält die Fehlermeldung über die Empfangsbestätigung und korrigiert die Rezeptanforderung (ggf. durch Mitwirken des Anfordernden) entsprechend.

Schritt 8: Die korrigierte Rezeptanforderung wird erneut an das PVS des Arztes gesendet.

Schritt 9: Das PVS verarbeitet die korrigierte Anforderung erfolgreich und sendet eine Bestätigung über die erfolgreiche Verarbeitung zurück an das PSP.

Schritt 10: Die Rezeptanforderung und das ausgestellte Rezept werden an die Pflegeeinrichtung übermittelt.

Beispiel: Ablauf Rezeptanforderung und -übermittlung - Korrekturfall

Entwicklung und Optimierung durch kollaborative Netzwerkinteraktion

Entwicklung einer gemeinschaftlichen und qualitätsorientierten Umgebung:

Das Teilen von Adressen durch "First Mover" in Entwicklungsumgebungen erlaubt es Entwicklern, ihre Systeme durch Tests und Anpassungen kontinuierlich zu verbessern, was die Nachrichtenqualität im Netzwerk stetig erhöht.

Transparenz und Zugänglichkeit: Jede Nachricht im ATF-Netzwerk muss klar das sendende Softwaresystem ausweisen sowie Informationen darüber bereitstellen, wie die Entwickler dieses Systems erreicht werden können.
Qualitätssteigerung durch Feedback: Die Möglichkeit, direkt Feedback zu geben und zu erhalten, fördert die schnelle Behebung von Problemen und Unklarheiten und trägt so zur Qualitätssteigerung der gesamten Netzwerkkommunikation bei.
Kollaborative Optimierung: Durch die frühzeitige Integration und das Testen gegen Erstimplementierungen entsteht ein kollaborativer Prozess, der die Entwicklung robuster und effizienter Kommunikationsstandards fördert.

Welche UsesCases sind für das ATF geplant?

Das App-Transport-Framework (ATF) soll bei den folgenden Use Cases Anwendung finden:

E-Rezept Rezeptanforderung für Pflege und anwendungsfertige Zytostatikazubereitung : Das ATF wird für die Rezeptanforderung in den Bereichen Pflege und anwendungsfertige Zytostatikazubereitung eingesetzt werden, um die Prozesse in diesen Anwendungsfällen zu standardisieren.
E-Rezept Rezeptanforderung für E-BTM Notfallverordnungen (in Planung): In Abstimmung mit dem BMG wird eine Implementierung basierend auf dem ATF favorisiert, um die Nachreichung von BTM-Notfallverordnungen effizient zu unterstützen.

Wo erfahre ich mehr über das ATF?

Das App-Transport-Framework (ATF) ist wie folgt dokumentiert:

Simplifier Projekt: Der Ort zur Begutachtung der FHIR Ressourcen und Pakete.
Implementation Guide (IG): Die detaillierte Beschreibung für Implementierer und Spezifizierer, die auf dem ATF aufbauen wollen.
Proof of Concept: Beispielimplementierung einer ATF Bibliothek in Python, welche in den Beispielimplmentierungen den Anwenungsfällen des ServiceRequest verwendet wird.

Vielen Dank für Ihre Aufmerksamkeit!

Ich hoffe, dass ich Ihnen einen guten Überblick über das App-Transport-Framework geben konnte. Wenn Sie Fragen haben, stehe ich Ihnen gerne zur Verfügung.