Die FHIR-Spezifikation macht keine verbindlichen Vorgaben bezüglich der Methode und des Protokolls über das FHIR-Ressourcen zwischen Systemen ausgetauscht werden sollen. Obgleich der Standard vor dem Hintergrund einer REST-basierten Kommunikation entwicklet wurde, sind auch andere Formen des Datenaustauschs, einschließlich proprietärer Protokolle erlaubt.

Damit soll gewährleistet werden, dass FHIR in allen Umgebungen (auch z.B. innerhalb bestehender nationaler Infrastrukturen) genutzt werden kann.

Die Festlegung des für einen konkreten UseCase am besten geeigneten Paradigmas unter Berücksichtigung aller Rahmenbedingungen gehört mit zu den wichtigsten Entscheidungen bei der Erstellung eines Implementierungsleitfadens.

Die folgende Beschreibung typischer Kommunikationsszenarien soll als Orientierung dienen, um das aus technischer Sicht am besten geeignete Paradigma zu finden.

Dazu sollten die Kriterien aller Szenarien betrachtet werden und dasjenige ausgewählt werden, dessen Kriterien am ehesten auf einen UseCase zutreffen. Diese Entscheidung mag nicht immer eindeutig ausfallen. Oft überwiegen auch andere Betrachtungen als die technische Eignung, wie zum Beispiel die Frage, auf welche exisiterende Infrastruktur zurückgegriffen werden kann.

Nicht selten mag sich herausstellen, dass die dokumentenbasierte Kommunikation über die ePA oder das Messaging via KIM zwar aus technischer Sicht suboptimal aber dennoch alternativlos sind, weil sie die einzige aktuell verfügbaren Kommunikationswege darstellen.

Best Practice...

Client-Server-Kommunikation (Interaktion auf Patientenebene)

Der RESTful Ansatz ist das grundlegende Paradigma, um das herum FHIR entstanden ist. Nur in Verbindung mit einer RESTful API können daher die Features von FHIR optimal genutzt werden.

Die kommunizierenden Systeme stehen in einer Client-Server-Relation zueinander (Server: datenhaltendes, primäres System, Client: datenkonsumierendes bzw. datenlieferndes Subsystem)

Typische Kriterien:

  • Clients verfügen oft über keine eigene Datenhaltung (ggf. nur Caching von häufig/zuletzt verwendeten Daten, Offline-Funktion)
  • Der Client initialisiert die Kommunikation (Query-getrieben)
  • Es wird eine synchrone Kommunikation gewünscht (Anwender wartet auf Antwort)
  • Der Server ist jederzeit erreichbar/verfügbar (Clients können jederzeit weitere benötigte Informationen bei Bedarf abfragen)
  • Die Systeme sollen sich unabhängig voneinander weiterentwickeln können, Updates erfolgen häufig und unregelmäßig.
  • Clients sind verschiedenartig, häufig hochspezialisiert und nutzen oft nur einen kleinen Teil der vom Server bereitgestellten Funktionen
  • Es existiert ein übergreifendes Benutzerkonzept (Anwender des Clients ist dem Server bekannt).

Variante 1: PULL (Client initialisiert die Kommunikation)

Geeignetes Paradigma: RESTful API

Die RESTful API kann bei Bedarf ergänzt werden mit

  • Operations
  • Subscriptions
  • Messaging-Endpoint
  • Document-Endpoint

Variante 2:PUSH (Server initialisiert die Kommunikation)

Geeignetes Paradigma: Subscriptions

Mensch-Mensch-Kommunikation (von strukturierten und/oder unstrukturierten Daten)

Typische Kriterien:

  • Die übermittelten Daten werden im sendenden System von einem Menschen kuratiert/ausgewählt, ggf. mit unstrukturierten Informationen (Anrede, ergänzende/erläuternde Hinweise, Empfehlungen) ergänzt.
  • Die Daten müssen ggf. vom Autor signiert werden
  • Die Daten müssen vom Empfänger in der kommunizierten Form archiviert werden (Nachweispflicht).
  • Die Daten müssen beim Empfänger zunächst nur dem Anwender angezeigt werden können. Eine Übernahme von strukturierten Daten in das empfangende System ist nicht zwingend gewünscht/erforderlich.
  • Die Übernahme von Daten im empfangenden System kann partiell sein (allgemeinmedizinischen PVS übernimmt nur allgemeine medizinische Daten aus einem hochspezialisierten kardiologischen Befund) und kann ggf. vom Anwender gesteuert werden (manuelle Auswahl der Daten, die übernommen werden sollen).

Geeignetes Paradigma: Documents

mögliche Protokolle zum Dokumenten-Transfer:

  • HTTP(s) (Document-Endpoint)
  • IHE-MHDS
  • IHE-MHD als Fassade vor IHE-XDS
  • IHE-XDS nativ (nicht ideal, da IHE MHD im FHIR-Kontext kompatibler ist, aber oft unumgänglich, z.B. bei der Kommunikation mit der ePA des Patienten)
  • Filetransfer (wenn's gar nicht anders geht)
  • Attachment an eMail (meistens keine gute Idee, wegen fehlender Verschlüsselung)
  • Attachment an KIM (Hier ist Vorsicht geboten: Wenn auf Empfängerseite eine automatisierte Verarbeitung erfolgen soll, handelt es sich im eine Maschine-Maschine-Kommunikation, die den Spezifikationen des App-Transport-Frameworks der Gematik folgen sollte!)

Payload:

  • Bundle-Ressource vom Typ "document"

Maschine-Maschine-Kommunikation

Typische Kriterien:

  • Die kommunizierenden Systeme stehen in einer Server-Server-Relation (beides datenhaltende Systeme)
  • Es handelt sich um einen gerichteten Versand
  • Es sind keine menschlichen Benutzer in die Kommunikation involviert (Zusammenstellung/Versand und Empfang/Weiterverarbeitung passieren vollautomatisch)
  • Die Systeme stehen nicht in permanentem Austausch
  • Die Daten müssen ggf. vom Sender signiert werden
  • Es ist ggf. kein Handshake-Protokoll möglich, weshalb Metadaten zu sendendem und empfangenden System in den Daten enthalten sein müssen (z.B. Filetransfer)

Geeignetes Paradigma: Messaging

mögliche Protokolle zum Nachrichten-Transfer:

  • HTTP(s) (Messaging-Endpoint)
  • Attachment an KIM gemäß App-Transport-Frameworks
  • TCP/IP oder Filetransfer, analaog HL7 V2 (nur wenn's gar nicht anders geht)

Payload:

  • Bundle-Ressource vom Typ "message"

Mensch-Maschine-Kommunikation (Datenerfassung/-Eingabe durch Anwender)

Typische Kriterien:

  • Die zu kommunizierenden Daten sind nicht oder nur teilweise bereits im sendenden System vorhanden und müssen zunächst durch den Anwender erfasst/ergänzt werden
  • Eine einheitliche Erhebung der Daten (vergleichbare UI, identische Erläuterungen für den Anwender) über mehrere verschiedene implementierende Systeme hinweg, ist von hoher Bedeutung
  • Die Daten sollen ggf. auch mit mobilen Endgeräten erhoben werden können
  • Bei der Spezifikation handelt es sich um die Ablösung bestehender, formularbasierter Prozesse, die ohne große Änderung der Abläufe bzw. Datenmodelle digitalisiert werden sollen
  • Aufgrund von datenschutzrechtlichen Rahmenbedingungen darf nur ein Ausschnitt der in den Primärsystemen ggf. bereits vorhandenen Datenobjekten übermittelt werden (z. B. Patientenstammdaten wie Name und Geburtsdatum aber ohne Adresse, Telefonnummer)
  • Die Daten werden oft nur zwischen anderen gleichartigen Erhebungen verglichen und statistisch ausgewertet. Eine Weiternutzung der Daten in anderen Kontexten ist nicht oder nur teilweise erforderlich.
  • Häufig wird aus den erfassten Informationen ein Gesamtscore ermittelt und nur dieser weiterverwendet.

Geeignetes Paradigma: Questionnaire / QuestionnaireResponse in Verbindung mit SDC (Structured Data Capture)

Die Questionnaire-Extensions im SDC-Implementierungsleitfaden ermöglichen es unter anderem:

  • Items zur Extraktion zu annotieren, so dass die über ein Formular erhobenen Daten auch außerhalb des Formularkontextes wiederverwendet und z.B. über die REST-ful API verfügbar gemacht werden können.
  • Items zur automatischen Vorbelegung ("Prepopulation") zu annotieren um Daten, die in den Systemen bereits vorhanden sind, über die REST-ful API zu ermitteln und redundante Datenerfassung zu verhindern.
  • Items mit Scores zu annotieren und die Gesamtscores von QuestionnaireResponses zu ermitteln.
achtung Um die Kompatibilität von Questionnaires zu anderen FHIR-Implementierungen zu gewährleisten, sollten die SDC-Funktionalitäten zur Prepopulation und Extraction bei allen Projekten von Anfang an mitbedacht werden!

mögliche Protokolle für den Formulardaten-Transfer:

  • HTTP(s) QuestionnaireResponse-Endpoint oder Transaction-Endpoint
  • KIM/TIM, wobei hier sichergestellt werden muss, dass Sender und Empfänger Kenntnis über bzw. Zugriff auf die gleichen Questionnaire-Definitionen haben, da Verlinkung hier ggf. nicht funktioniert.

Payload:

  • QuestionnaireResponse-Ressource oder Transaction-Bundle

Massendatentransfer

Typische Kriterien:

  • Anforderung von großen Datenmengen (z.B. auf Populationsebene)
  • asynchrone Kommunikation
  • Export von (Fall-/Patienten)Akten
  • Exporte auf Systemebene (Archivierung/Migration)

Geeignetes Paradigma: FHIR Bulk Data

mögliche Protokolle:

  • Starten des Exportes mittels Operation (HTTP(s))
  • Bereitstellung des Exportes als Datei (ndJSON) zum Download

Payload:

  • Beliebige FHIR-Ressourcen im ndJSON-Format

Primärsystem-App-Integration ("Fremdaufruf")

Typische Kriterien:

  • Benutzer im Primärsystem startet eine App
  • Benutzer- Patienten-/Fallkontext wird an App übergeben
  • Delegation von Benutzerberechtigungen an aufgerufene App
  • App kann Daten aus Primärsystem abfragen oder zurückschreiben

Geeignetes Paradigma: RESTful API + SMART-on-FHIR

Entscheidungsunterstützung (Anwenderaktion triggert Client/Service)

Typische Kriterien:

  • Benutzeraktion im Primärsystem triggert einen Dienst
  • Kontextdaten zur Benutzerinteraktion werden an Dienst übergeben
  • Dienst gibt Handlungsempfehlung / Warnung / Hinweis zur Integration in die UI der aufrufenden Applikation zurück
  • Beispielsweise: Verordnung eines Medikamentes triggert ein Arzneimittelwechselwirkungssystem, das ggf. eine Warnung erzeugt

Geeignetes Paradigma: CDS-Hooks