Systeme zum Sprechen bringen: Interoperabilität mit FHIR und HIEs

# Systeme zum Sprechen bringen: Interoperabilität mit FHIR und HIEs

Eine Patientin kommt um 2 Uhr nachts bewusstlos in der Notaufnahme an. Sie wurde aus einem kleineren Krankenhaus 40 Meilen entfernt verlegt. Die Sanitäter übergeben eine ausgedruckte Zusammenfassung. Drei Seiten, teilweise unleserlich, ohne aktuelle Medikationsliste. Das aufnehmende Krankenhaus arbeitet mit einer anderen elektronischen Patientenakte (EHR) als die abgebende Einrichtung. Auf dem Papier sind beide Häuser „digital“. Am Krankenbett ist die Datenlücke real und gefährlich.

Diese Lektion verfolgt diese Verlegung, um zu zeigen, wie drei Dinge (HL7-FHIR-APIs, Health Information Exchanges und das TEFCA-Rahmenwerk) diese Lücke schließen oder eben nicht schließen.

Warum Systeme nicht von selbst miteinander sprechen

Eine EHR ist die Software, mit der ein Krankenhaus Patientendaten speichert: Notizen, Labore, Medikamente, Bildgebung, Abrechnung. Im US-Markt dominieren eine Handvoll Anbieter die großen Kliniken, während viele kleinere Anbieter Praxen und ländliche Einrichtungen bedienen.

Das Problem: Jede EHR wurde als geschlossenes System gebaut. Historisch wurden Daten in proprietären Formaten gespeichert. Informationen herauszubekommen hieß oft faxen, ausdrucken oder ein teures individuelles Integrationsprojekt.

Interoperabilität ist die Fähigkeit unterschiedlicher Systeme, Daten auszutauschen und tatsächlich zu nutzen. Nicht nur ein PDF verschieben, sondern strukturierte Daten übertragen, die ein empfangendes System lesen, sortieren und verarbeiten kann.

Zwei Fehlermodi sind für unsere Patientin relevant:

• Gar keine Verbindung. Die Systeme haben keine gemeinsame Leitung.
• Verbindung ohne Nutzbarkeit. Daten kommen als unstrukturierter Block an (ein gescanntes Dokument), also muss eine Ärztin trotzdem drei Seiten lesen, um eine Allergie zu finden.

HL7 und FHIR: eine gemeinsame Sprache

HL7 (Health Level Seven) ist das Standardisierungsgremium, das festlegt, wie Systeme im Gesundheitswesen Daten formatieren und austauschen. Ältere HL7-Standards (v2-Nachrichten und das Dokumentformat CDA) sind weit verbreitet, aber sperrig und mühsam in der Handhabung.

FHIR (Fast Healthcare Interoperability Resources, ausgesprochen „fire“) ist der moderne Standard von HL7. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist relevant, weil ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → dieselbe Web-Technologie nutzt, die auch gewöhnliche Apps antreibt: REST-APIs und JSON. Wenn Sie je eine App genutzt haben, die Ihren Kontostand abruft, ist das dieselbe Architekturidee.

FHIR zerlegt Gesundheitsdaten in „Resources“, jede eine standardisierte Einheit: Patient, MedicationRequest, AllergyIntolerance, Observation (für einen Laborwert oder Vitalparameter), Condition (eine Diagnose).

So sieht ein einzelnes Medikament als FHIR-Resource aus, vereinfacht:

{
  "resourceType": "MedicationRequest",
  "status": "active",
  "medicationCodeableConcept": {
    "text": "Warfarin 5 mg oral tablet"
  },
  "subject": { "reference": "Patient/12345" },
  "dosageInstruction": [
    { "text": "Take 1 tablet once daily" }
  ]
}

Auf diese Struktur kommt es an. Das System des aufnehmenden Krankenhauses kann status: active und Warfarin als Datenfelder lesen, nicht als Text, der in einer gescannten Seite vergraben ist. Es kann eine gefährliche Wechselwirkung automatisch markieren.

In den USA verlangen Bundesvorgaben inzwischen, dass zertifizierte EHRs eine standardisierte FHIR-APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → anbieten. Der 21st Century Cures Act und seine „Information Blocking“-Regeln (durchgesetzt ab 2021) machen es für die meisten Akteure im Gesundheitswesen rechtswidrig, den Zugang zu elektronischen Gesundheitsdaten unangemessen zu behindern. In der Praxis hat das die Anbieter dazu gebracht, FHIR-Endpunkte bereitzustellen. Die Spezifikation selbst finden Sie unter hl7.org/fhir.

FHIR löst das *Sprachproblem*. Aber eine gemeinsame Sprache bedeutet nicht, dass die beiden Krankenhäuser verbunden sind. Irgendjemand muss immer noch die Leitungen betreiben.

Health Information Exchanges: die Leitungen

Ein Health Information Exchange (HIE) ist eine Organisation, die viele Leistungserbringer verbindet, damit sie Patientenakten teilen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen. Stellen Sie es sich als Vermittlungsstelle vor. Statt dass jedes Krankenhaus eine direkte Verbindung zu jedem anderen Krankenhaus aufbaut (eine unmögliche Zahl an Verbindungen), verbindet sich jedes einmal mit dem HIE, und der HIE leitet die Anfragen weiter.

HIEs gibt es in mehreren Varianten:

• Regionale oder bundesstaatliche HIEs, oft gemeinnützig, mit geografischem Zuschnitt.
• Anbieternetzwerke, in denen Krankenhäuser mit derselben EHR über den Austausch des Anbieters teilen.
• Nationale Netzwerke, die die Verbinder verbinden.

Zurück zu unserer Patientin. Wenn das abgebende und das aufnehmende Krankenhaus beide am selben regionalen HIE teilnehmen, kann die Ärztin in der Notaufnahme das Netzwerk abfragen und ihre Daten ziehen: eine aktive Warfarin-Verordnung, ein aktueller Kreatininwert, eine dokumentierte Penicillinallergie. Die Datenlücke schließt sich.

Teilen sie kein Netzwerk, liefert die Abfrage nichts, und wir sind zurück beim unleserlichen Fax.

Die alte Hürde: zu viele getrennte Netzwerke

Jahrelang hatten die USA einen Flickenteppich. Ein Krankenhaus gehörte vielleicht zu einem bundesstaatlichen HIE und einem Anbieternetzwerk; der Nachbar zu einem anderen nationalen Rahmenwerk. Fragen Sie eines ab, verpassen Sie die anderen. Die Verlegung gelingt oder scheitert abhängig von geografischem und anbieterbezogenem Zufall, nicht vom Bedarf der Patientin.

Genau diese Fragmentierung sollte die neueste Ebene beheben.

TEFCA: ein Netzwerk der Netzwerke

TEFCA steht für Trusted Exchange Framework and Common Agreement. Es ist eine US-Initiative, entstanden unter dem Cures Act und koordiniert von der Bundesbehörde für Gesundheits-IT (ONC), um die großen Netzwerke unter einem gemeinsamen Regelwerk zu verbinden.

Das Kernkonzept: ein QHIN (Qualified Health Information Network). Ein QHIN ist ein großes Netzwerk, das die TEFCA-Anforderungen erfüllt und zustimmt, Daten mit allen anderen QHINs auszutauschen. Die ersten QHINs wurden Ende 2023 benannt, und das Rahmenwerk wächst seitdem.

Die Idee ist elegant. Ein Krankenhaus verbindet sich mit einem QHIN. Dieser QHIN erreicht jeden anderen QHIN. Die aufnehmende Notaufnahme in unserer Geschichte fragt also ihr eigenes Netzwerk ab, und die Anfrage läuft über TEFCA dorthin, wo die Daten der Patientin liegen. Keine Frage mehr nach „sind wir beide im selben konkreten HIE?“

🎬 [VIDEO: „What is TEFCA?“ - youtube.com - eine kurze Erklärung von Gesundheits-IT-Fachleuten, wie das Trusted Exchange Framework Netzwerke landesweit verbindet]

Warum es am Krankenbett trotzdem scheitern kann

TEFCA ist keine Zauberei, und 2026 ist es noch in der Reifephase. Reale Lücken bleiben:

• Teilnahme. Ein Netzwerk hilft nur, wenn beide Krankenhäuser tatsächlich beigetreten sind. Das Onboarding kostet Zeit und Geld, und kleinere ländliche Einrichtungen hinken hinterher.
• Datenqualität. Die Abfrage kann erfolgreich sein und trotzdem einen Datensatz liefern, in dem die Medikationsliste nie aktualisiert wurde. Garbage in, garbage out.
• Patientenzuordnung. Netzwerke müssen bestätigen, dass „Jane Smith, geb. 1975“ in Krankenhaus A dieselbe Person ist wie in Krankenhaus B. Die USA haben keine nationale Patientenkennung, also stützt sich das Matching auf demografische Angaben und kann scheitern oder den falschen Datensatz liefern.
• Zweck und Einwilligung. Regeln bestimmen, *warum* Daten angefragt werden dürfen (Behandlung, Abrechnung, öffentliche Gesundheit). Datenschutzgesetze der Bundesstaaten sorgen für Unterschiede, besonders bei sensiblen Daten wie psychischer Gesundheit.

Die Leitung kann also existieren und trotzdem ein unvollständiges oder falsch zugeordnetes Bild liefern. Interoperabilität ist eine Kette: Standard (FHIR), plus Netzwerk (HIE oder QHIN), plus Datenqualität, plus Patientenzuordnung, plus Einwilligung. Die Kette ist nur so stark wie ihr schwächstes Glied.

Die Verlegung durch die drei Ebenen gelesen

Bilden wir die Verlegung unserer Patientin um 2 Uhr nachts auf den Stack ab, denn so denkt man über jedes Interoperabilitätsproblem nach.

Ebene 1, die Sprache (FHIR). Beide EHRs sind zertifiziert und stellen FHIR-APIs bereit. Gut. Medikations- und Allergiedaten lassen sich als strukturierte Resources abbilden.

Ebene 2, das Netzwerk (HIE / QHIN). Das aufnehmende Krankenhaus gehört zu einem QHIN. Das Anbieternetzwerk des abgebenden Krankenhauses ebenfalls. Unter TEFCA reicht die Abfrage der Notaufnahme hinüber und liefert die Daten zurück. Diese Ebene entscheidet, ob überhaupt Daten fließen.

Ebene 3, die Realitätsprüfungen. Die Patientin wurde korrekt zugeordnet (ihre demografischen Daten waren sauber). Ihre Medikationsliste war beim letzten Besuch aktualisiert worden. Die Einwilligungsregeln erlaubten eine Behandlungsabfrage. Alle drei hielten, also erscheint das Warfarin auf dem Bildschirm der Notaufnahme, bevor die Ärztin einen Eingriff anordnet, der eine Blutung ausgelöst hätte.

Ändern Sie eine einzige Variable, und die Geschichte endet anders. Wäre das abgebende Krankenhaus nie einem Netzwerk beigetreten, scheitert Ebene 2 und nichts bewegt sich. Wäre ihr Name bei der Aufnahme falsch geschrieben worden, scheitert Ebene 3 und die Abfrage liefert nichts oder, schlimmer, den Datensatz einer anderen Person.

Für eine breite, anbieterneutrale Einführung in den Stand der US-Interoperabilitätspolitik pflegt die Bundesbehörde für Gesundheits-IT öffentliche Ressourcen unter healthit.gov.

Was das für Entscheider bedeutet

Wenn Sie eine Versorgungsorganisation führen oder beraten, ist Interoperabilität keine einzelne Anschaffung. Es ist ein Satz von Fragen:

• An welchen Netzwerken nehmen wir teil, und erreichen sie die Partner, mit denen wir tatsächlich Patienten austauschen?
• Funktionieren unsere FHIR-Endpunkte, und sind sie getestet oder nur technisch „an“?
• Wie gut ist unsere Patientenzuordnung? Eine hohe Rate an Dubletten ist ein stilles Interoperabilitätsversagen.
• Sind unsere Daten aktuell in dem Moment, in dem sie das Haus verlassen?

Die Technologie wird zunehmend standardisiert. Der verbleibende Wert und das verbleibende Risiko liegen in Teilnahme, Datenhygiene und Matching.

Key Takeaways

• FHIR ist die gemeinsame Sprache. Es verwandelt Gesundheitsdaten über gewöhnliche Web-APIs in standardisierte, maschinenlesbare Resources, sodass ein empfangendes System mit Daten arbeiten kann, statt nur ein Dokument anzuzeigen.
• HIEs und QHINs sind die Leitungen. Eine gemeinsame Sprache nützt nichts, wenn die beiden Systeme nicht mit demselben Netzwerk verbunden sind; TEFCA will die großen Netzwerke verknüpfen, sodass eine einzige Verbindung das ganze Land erreicht.
• Die Kette hat schwache Glieder. Auch mit FHIR und TEFCA scheitern Verlegungen an fehlender Teilnahme, veralteten Daten, schlechter Patientenzuordnung (keine nationale Patientenkennung) oder Einwilligungsbeschränkungen.
• Diagnostizieren Sie Interoperabilität in Ebenen. Sprache, Netzwerk sowie Datenqualität plus Matching. Wenn Daten nicht ans Krankenbett gelangen, ist eine bestimmte Ebene gebrochen, und sie zu benennen ist der erste Schritt zur Behebung.