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.

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

Structured Documents vs. Structures Data Capture

Dieses Kapitel soll eine Hilfestellung für die Unterscheidung und Abgrenzung der beiden Paradigmen "Structured Documents" und "Questionnaires"/"Structured Data Capture" bieten.

Zunächst bedienen beide Paradigmen den UseCase, strukturierten Daten in Form eines Dokumentes (abgeschlossene, vollständige, signierbare Aggregation von Informationen) abzubilden. Die Abgrenzung zwischen einem strukturierten Dokument und einem Formular/Questionnaire ist im alltäglichen Sprachgebrauch schwer zu fassen, die entsprechenden Umsetzungen in FHIR haben aber klare Vor- und Nachteile, die eine Entscheidung für das eine oder andere Paradigma erleichtern können.

Structured Documents

Die Erstellung eines strukturierten Dokumentes in FHIR sieht vor, dass vorhandene Informationsobjekte/Ressourcen von einem Anwender zu einem Dokument aggregiert und angeordnet werden. Dazu wird eine Composition-Ressource erstellt, die die Dokumenten-Metadaten (u.a. Art des Dokumentes, Autor, Datum der Erstellung) enthält und eine frei vom Benutzer gewählte oder durch den Dokumenttyp vorbestimmte Struktur vorgibt (sog. "Sections", die das Dokument in Kapitel untergliedern, z.B. bei einem Entlassbrief "Anamnese", "Epikrise", "Entlassmedikation", "Empfehlungen zur Weiterbehandlung).

Der Inhalt der jeweiligen Sections bestehen wahlweise aus HTML-basiertem Freitext/Narrative oder aus Referenzen auf die (z.B. in der Patientenakte) bereits vorhandenen Informationsobjekte (z.B. Diagnosen, Prozeduren, Medikationen), die den strukturierten Inhalt dieser Sections darstellen. Der Narrativ (die menschenlesbare Version) solcher Sections wird in diesem Fall automatisch aus den strukturierten Daten erzeugt.

Um von einer fertig "komponierten" Composition zu einem verkehrsfähigen Dokument zu kommen, wird zum Zeitpunkt der Fertigstellung eine Bundle-Ressource erstellt, die die Composition sowie alle darin referenzierten Ressourcen enthält.

Dieses Paradigma ist empfehlenswert wenn folgende Vorbedingungen gegeben sind:

• dem Anwender soll ein gewisses Maß an Freiraum bei der Gestaltung des Dokumentes gelassen werden (Auswahl von Informationen, alternativer oder ergänzender Freitext)
• die für das Dokument benötigten strukturierten Ressourcen liegen im erzeugenden System bereits in geeigneter Form vor (entweder nativ als FHIR-Ressourcen oder über eine API/Fassade als solche verfügbar)
• die Vorgaben bezüglich der Dokumentenstruktur sind eher grob gefasst und verändern sich im zeitlichen Verlauf wenig
• die vorhandenen Ressourcen können unverändert in das Dokument übernommen werden
• es ist davon auszugehen, dass nachgeodnete Prozesse beim Empfänger des Dokumentes, einzelne Ressourcen daraus extrahieren und unabhängig vom Dokumentenkontext weiterverarbeiten möchten (z.B. Übernahme von Diagnose- und Medikationsdaten in die Patientenakte des Empfängers)
• ein vergleichsweise hohes Datenvolumen ist unproblematisch (z.B. nicht durch Bandbreite beim Transport, Kapazität von Speichermedien begrenzt etc.)

Structured Data Capture

Im Gegensatz zu den strukturierten Dokumenten steht beim Questionnaire/Formular-basierten Ansatz die strukturierte Erfassung von Daten durch einen Anwender im Vordergrund.

Während Structured Documents keine Annahme darüber machen, auf welche Art und Weise die benötigten Daten ursprünglich erhoben wurden, stellen Questionnaires sicher, dass Daten über Systeme und Hersteller hinweg in gleicher Qualität erhoben werden, da die Darstellung der Erfassungsmasken mittels Questionnaires standardisiert und austauschbar gemacht wird.

Die Spezifikation "Structures Data Capture (SDC)" sorgt für die nahtlose Integration von Formularen in die Systeme sowohl des Senders als auch des Empfängers von Formulardaten.

SDC spezifiziert unter anderem, wie Formularfelder mit maschinenlesbaren Anweisungen für die Quellsysteme annotiert werden können, so dass in den Systemen bereits vorhandene Informationen automatisch vorbelegt werden können. Außerderm erlaubt SDC die Annotation mit Anweisungen, wie aus den im Formular erhobenen Daten eigenständige, unabhängig vom Formuarkontext weiterverarbeitbare Ressourcen extrahiert werden können.

Dieses Paradigma ist vorzuziehen wenn folgende Vorbedingungen ganz oder teilweise gegeben sind:

• die Struktur des Dokumentes ist fest vorgegeben, nicht nur in Form von Kapiteln sondern bis hin zu einzelnen Elementen der strukturierten Daten. Der Anwender hat wenig bis keinen Gestaltungsfreiraum. Viele Informationen werden codiert und mit begrenzen Wertemengen (Auswahllisten) oder als ja/nein-Informationen erhoben. Freitextangaben sind in ihrem Umfang begrenzt und meist auf eine konkrete Fragestellung bezogen.
• es kann nicht davon ausgegangen werden, dass alle erforderlichen strukturierten Daten in den Quellsystemen bereits vorhanden bzw. in geeigneter Form (z.B. in geeigneter Grnularität und Codierung) vorhanden sind. Ein Teil der Daten muss ggf. vom Anwender zum Zeitpunkt der Dokumenterstellung eingegeben/ergänz/qualifiziert werden.
• die Leistungsfähigkeit und der Systeme, die das Dokument erstellen müssen und der Umfang der darin zur Verfügung stehenden Menge und Breite an Daten, ist je nach Produkt/Hersteller/Konfiguration/Nutzung sehr unterschiedlich.
• die Vorgaben der Struktur können sich im zeitlichen Verlauf rasch ändern und Änderungen sollten schnell und ohne großen Aufwand/Kosten in den Systemen umsetzbar sein.
• vorhandene Ressourcen aus den Quellsystemen können meist nicht unverändert übermittelt werden, da datenschutzrechtliche Rahmenbedingungen dies verhindern (z.B. das Gebot der Datensparsamkeit). Dies trifft besonders häufig bei der einrichtungsübergreifenden Kommunikation und der Datenmeldung an Register zu.
• die Weiterverarbeitung beim Empfänger erfolgt überwiegend im Dokumentenkontext (z.B. Vergleich mit oder quantitative Analyse von Daten aus identisch strukturierten Dokumenten). Dies trifft besonder häufig auf die Datenverarbeitung in klinischen Studien oder Registern zu. Eine Weiternutzung von Daten außerhalb des Dokumentenkontextes betrifft wenn, dann nur eine Teilmenge der übermittelten Information (z.B. nur Diagnosen und Medikationsdaten)
• das Datenvolumen für die Übermittlung/Speicherung soll möglichst gering sein
• die fachlichen Vorgaben an die Dokumentstruktur sind sehr rigide definiert und lassen sich nicht ohne weiteres (nicht ohne zahlreiche Extensions) auf FHIR-Ressourcen mappen
• es ist relevant, dass die Daten nicht nur in gleicher Struktur übermittelt sondern auch in gleicher Qualität erhoben werden.

Weitere zu berücksichtigende Aspekte

Kompatibilität

Die Verwendung von Strukturierten Dokumenten anstelle von Formularen in Kontexten, wo sehr enge Vorgaben bis auf Element-Ebene insbesondere vor dem Hintergrund der Datensparsamkeit gemacht werden müssen, hat in Deutschland zu der Problematik einer Vielzahl von restriktiven und dadurch inkompatiblen Profilen geführt.

Die Stärke des (SDC-)Questionnaire-Ansatzes liegt in der "separation of concerns". Während die Quellsysteme nur noch dafür sorgen müssen, möglichst viel Informationen für die automatische Vorbefüllung von Questionnaires über eine FHIR-API verfügbar zu machen, sorgen die maschinenlesbaren Regeln in den Questionnaires für die gezielte Auswahl der für einen konkreten Dokumentenkontext benötigten Daten. Quellsyteme können zum Beispiel mit der Bereistellung einer umfassenden Patient-Ressource viele verschiedene restiktive (auch untereinander inkompatible!) Formulardefinitionen bedienen, ohne Änderungen an der Struktur der Ressource vornehmen zu müssen.

Der Nachteil des Questionnaire-Ansatzes besteht darin, dass wenn beim Design eines Questionnaires die Strukturen der FHIR-Ressourcen, die als Quelle für die Vorbelegung bzw. als Ziel der Extraktion dienen, nicht von Anfang an berücksichtigt werden, eine proprietäre Datenstruktur entstehen kann, deren Wiederverwendbarkeit in und Vergleichbarkeit mit anderen Kontexten nicht gewährleistet ist.

Ohne adäquate Annotationen der Formularfelder für die automatische Vorbelegung und geeingete APIs in den Quellsystemen zur Bereitstellung der benötigten FHIR-Ressourcen verursachen Questionnairs im schlimmsten Fall eine komplett redundante Datenerfassung.

generisches Tooling

Tools, die Questionnaire-Ressourcen in ausfüllbare Benuzeroberflächen konvertieren und für die automatische Vorbefüllung sorgen, können generisch implementiert werden. Bei Änderungen vorhandener Formulardefinitionen, bzw. der Nutzung neuer Formulardefinitionen sind dann keine Änderungen am Code mehr erforderlich. Dabei ist jedoch zu beachten, dass eine korrekte, robuste und Feature-vollständige Implementierung eines sog. "Questionnaire-Renderers" durchaus aufwendig und teuer ist, insbesondere wenn dabei auch Funktionalitäten für die automatische Datenvorbelegung und die Datenextraktion berücksichtigt werden sollen. In der FHIR-Community stehen jedoch bereits mehrere OpenSource-Implementierungen zur Verfügung, die angepasst und in vorhandene Systeme integriert werden können.

Innovationszyklen

Neue bzw. geänderte Anforderungen für die Bereitstellung von strukturierten Daten für Register, Studien, Qualitätssicherung, Reporting, Datenbereitstellung in der ePA, intersektorale Kommunikation usw. können mit Hilfe generischer Questionnaire-Renderer theoretisch ohne Änderungen an der Implementierung der Quellsysteme bedient werden.

Das worst case Szenario wäre hier lediglich, dass eine neue Formulardefinition Daten für die automatische Vorbelegung benötigt, die vom Quellsystem noch nicht über eine FHIR-API bereitgestellt werden können und daher vom Anwender zunächst manuell erfasst werden müssten. Ungeachtet dessen könnte das neue Formular innerhalb kürzester Zeit und bei minimalstem Aufwand und Kosten im Quellsystem bereitgestellt, zur Anzeige gebracht und vom Anwender ausgefüllt werden. Die Bereitstellung valider und vollständiger strukturierter Daten wäre ohne zeitlichen Verzug möglich. Notwendige Weiterentwicklungen der FHIR-API um zusätzliche Daten für die automatische Vorbelegung bereitzustellen, können über die normalen Release-Zyklen des Quellsystems nachgeliefert werden.

Datenvolumen und Komplexität

Ein signifikanter Vorteil von Questionnaires ist die erhebliche Reduktion des Datenvolumens bei Questionnaires. Da die Definition und semantische Annotation der Formularfelder im Questionnaire erfolgt, die Datenerfassung- und Kommunikation jedoch in einer Questionnaire-Response, die im einfachsten Fall nur noch aus Key-Value-Paaren besteht (ID des Formularfeldes + erhobenem Wert), reduziert sich das Volumen im Vergleich zu der Aggregation duzender eigenständiger, selbsttragender, vollständig mit Metadaten und Kontext annotierter FHIR-Ressourcen zu einem strukturierten Dokument massiv. Auch die Komplexität kann erheblich reduziert werden: Während ein ausgefülltes Formular im einfachsten Fall aus einer einzigen Ressource (QuestionnaireResponse) besteht, kommt ein patientenbezogenes strukturiertes Dokument mit nicht weniger als drei untereinander verlinkten und ineinander verschachtelten Ressourcen (Bundle, Composition, Patient) aus.

menschenlesbare Repräsentation

Grundsätzlich sollte sich die menschenlesbare Darstellung von strukturierten Dokumenten und QuestionnaireResponses in der Komplexität kaum unterscheiden. Während in ersterem Falle die HTML-Narrative der Composition (der "Dokumentenkopf") und der einzelnen Sections (entweder Freitext oder automatisch generierte HTML-Repräsentationen der strukturierten Daten) konkateniert und ggf. mit einem im Bundle enthaltenen Stylesheet gerendert werden muss, sollten die items einer QuestionnaireResponse als verschachtelte Liste von Fragestellung + gegebener Antwort mit wenig Aufwand visualisierbar sein.

Da jedoch insbesondere die in Deutschland derzeit spezifizierten strukturierten Dokumente überwiegend keine Narrative enthalten, bzw. diese nicht verpflcihtend vorsehen, ist die Visualisierung hier ungleich komplexer, da die verschiedenen Sections der Dokumente eine Vielzahl unterschiedlich profilierter Ressourcen enthalten können, die wiederum über Polymorphismen und Optionalitäten verfügen, die zur Erzeugung einer vollständigen Darstellung alle berücksichtigt/implementiert werden müssen. Insbesondere einfachen Systeme, deren UseCase lediglich die Anzeige stukturierter Dokumente erfordert, wird damit die Teilhabe an der Kommunikation schwer gemacht.