FHIR hat die Interoperabilität im Gesundheitswesen nicht gelöst

Ein neuer Health-Tech-Gründer liest zum ersten Mal über FHIR und wird kurz optimistisch. Es gibt einen Standard. Der Standard ist modern. Der Standard basiert auf REST, ist JSON-förmig und OAuth-authentifiziert. Sicherlich bedeutet das, dass EHR-Integration ein gelöstes Problem ist.

Dann integrieren sie sich tatsächlich mit ihrem ersten EHR — und innerhalb einer Woche ist der Optimismus verschwunden. Der Standard existiert. Die Implementierungen stimmen nicht damit überein. Die Lücke zwischen "FHIR-kompatibel" auf der Marketingseite und "spricht mit diesem spezifischen Epic-Deployment" in der Praxis ist enorm — und genau dort liegt die eigentliche Integrationsarbeit.

Wofür FHIR gut ist

Der Standard selbst ist eine echte Leistung. Er definiert Ressourcenformen für die Entitäten, die im Gesundheitswesen wichtig sind — Patienten, Beobachtungen, Diagnosen, Medikamente, Begegnungen — auf eine Weise, die vernünftig modern, vernünftig erweiterbar und weit brauchbarer ist als die Alternativen davor.

Wenn ihr etwas auf der grünen Wiese baut, ist FHIR die richtige Wahl. Euer internes Datenmodell wird am Ende wie FHIR aussehen, auch wenn ihr nicht dort anfangt — also spart ihr euch den unvermeidlichen Rewrite.

Wenn ihr ein generisches Tool baut, das "FHIR-Daten" konsumiert, ohne zu wissen, von welchem System es stammt, bringt euch der Standard vielleicht 80 Prozent des Weges. Für Demos, Prototypen und akademische Arbeiten reicht das.

Wo die Schwierigkeiten beginnen

Die Schwierigkeiten beginnen, wenn ihr mit einem echten EHR in einem echten Krankenhausnetz sprechen müsst. Es gibt drei verschiedene Lücken.

Die anbieterspezifische Lücke. Epic, Cerner, Meditech und Athena alle bieten FHIR-Endpunkte an. Sie bieten nicht alle dasselbe FHIR. Jeder hat seine eigenen Eigenheiten — Felder, die vom Standard gefordert werden, aber in ihren Daten fehlen; Erweiterungen, die in ihrer Version existieren, aber nirgendwo sonst; Felder, die in verschiedenen Deployments mit unterschiedlicher Bedeutung befüllt sind. Das Klischee in der Branche lautet: "Wenn du ein Epic gesehen hast, hast du ein Epic gesehen." Es ist ein Klischee, weil es wahr ist.

Die deployment-spezifische Lücke. Selbst innerhalb eines Anbieters konfiguriert jedes Krankenhaus das System anders. Zwei Epic-Deployments bei zwei verschiedenen Gesundheitssystemen geben Daten zurück, die dem Standard entsprechen, aber subtil verschiedene Dinge bedeuten. Die Art, wie eine Einrichtung einen bestimmten Beobachtungscode verwendet, kann sich mit der Art überschneiden, wie eine andere einen völlig anderen verwendet. Ohne lokales klinisches Wissen sind die Daten gleichzeitig korrekt und unverständlich.

Die historische Datenlücke. FHIR ist modern. Die Daten sind es nicht. Die meisten klinischen Daten in jedem Produktions-EHR stammen aus der Zeit vor der FHIR-Ära und wurden ursprünglich in HL7 v2, ICD-9, benutzerdefinierten Wörterbüchern oder Freitext kodiert. Der FHIR-Endpunkt sitzt über einer Übersetzungsschicht — und die Übersetzungsschicht ist unvollständig, verlustbehaftet und voller Sonderfälle. "Welche Medikamente hat dieser Patient je eingenommen?" via FHIR zu fragen, liefert euch eine Liste. Ob die Liste vollständig ist, ist eine separate Frage — und die Antwort ist fast immer nein.

Was tatsächlich funktioniert

Wir haben viele EHR-Integrationen geliefert. Ein paar Dinge, die sich bewährt haben.

FHIR als Ausgangspunkt behandeln, nicht als Vertrag. Euer Domain-Modell so bauen, wie es aussehen sollte. Dann eine Übersetzungsschicht zwischen FHIR und eurem Modell bauen und diese Schicht als den zerbrechlichsten, am stärksten getesteten Teil eurer Codebasis behandeln. Das ist sie.

Gegen echte (de-identifizierte) Daten testen, nicht gegen die Sandbox. Anbieter-Sandboxes enthalten idealisierte Daten, für die das Marketing-Team des Anbieters sich nicht schämen würde. Produktionsdaten sehen nicht so aus. Zugang zu repräsentativen echten Daten bekommen — anonymisiert, mit den richtigen BAAs — und euren Code dagegen ausführen, bevor ihr live geht. Die Bugs, die ihr so findet, sind die Bugs, die eure Kunden in Woche eins gefunden hätten.

Für graceful Degradation bauen, nicht für Vollständigkeit. Manche Patienten werden Daten haben. Manche nicht. Manche Felder werden befüllt sein. Manche nicht. Die meiste Healthcare-Software scheitert in der Produktion nicht, weil die Daten falsch sind, sondern weil die Software voraussetzt, dass Daten vorhanden sind, die es nicht sind. Defensiv coden, Lücken Nutzern ehrlich anzeigen und niemals stillschweigend auf "kein Wert" zurückfallen, wenn die Antwort "wir wissen es nicht" sein könnte.

Jemanden mit klinischem Know-how im Team haben. Die Daten sind medizinisch. Die Entscheidungen darüber, was zu tun ist, wenn die Daten mehrdeutig sind, sind medizinische Entscheidungen. Wenn euer Team den Unterschied zwischen einer klinisch bedeutsamen Lücke und einer bedeutungslosen nicht erkennen kann, wird das Produkt stillschweigend Entscheidungen treffen, die kein Kliniker gutheißen würde.

Die ehrliche Zusammenfassung

FHIR hat die Interoperabilität im Gesundheitswesen nicht gelöst. Es hat das nächste Jahrzehnt der Arbeit möglich gemacht — was eine andere und genauere Aussage ist. Die eigentliche Integrationsarbeit — der Teil, der die Zeit braucht, der Teil, der die Produktion zusammenhält — liegt auf FHIR, nicht darin. Wer etwas anderes behauptet, hat entweder keine echte Integration geliefert oder verkauft eine.