Wie HL7 und FHIR die Interoperabilität in der Gesundheitsversorgung im Justizvollzug verbessern

Warum Interoperabilität im Gesundheitswesen im Justizvollzug schwieriger ist

Ein Patient kann noch während einer laufenden Behandlung von einem lokalen Gefängnis in eine andere Justizvollzugsanstalt verlegt werden – und manchmal erreichen seine medizinischen Unterlagen die neue Einrichtung nur unvollständig oder gar nicht. Auch Krankenhäuser außerhalb des Justizvollzugs haben mit fragmentierten Patientendaten zu kämpfen. Im Justizvollzug kommen jedoch häufige Verlegungen, ein höherer Anteil an Patienten mit chronischen Erkrankungen und Suchterkrankungen sowie die gesetzliche Fürsorgepflicht hinzu. Fehlende Patientenakten sind hier deshalb nicht nur ein organisatorisches Problem, sondern können auch rechtliche Konsequenzen haben.

Die Vielzahl unterschiedlicher Anbieter verschärft das Problem zusätzlich. Ein lokales Gefängnis kann ein EHR-System nutzen, eine staatliche Justizvollzugsanstalt ein anderes und das externe Krankenhaus wiederum ein drittes. Labor- und Apothekensysteme werden häufig von weiteren, unabhängigen Anbietern bereitgestellt.

HL7 v2: der bewährte Standard

Seit den 1980er-Jahren bildet HL7 Version 2 (HL7 v2) eine wichtige Grundlage für den Nachrichtenaustausch in der Healthcare-IT. Das textbasierte Format verwendet senkrechte Striche (Pipes) als Trennzeichen und ist trotz seines Alters noch immer weit verbreitet: Laborsysteme, Apothekensysteme und ältere EHR-Systeme unterstützen HL7 v2 häufig standardmäßig.

Eine typische HL7-v2-Nachricht besteht aus mehreren Segmenten:

• MSH: Nachrichtenkopf, Absender, Empfänger, Zeitstempel
• PID: Patientenidentifikation
• OBR/OBX: Aufträge und Untersuchungsergebnisse

Im Justizvollzug wird HL7 v2 häufig für Laboraufträge und -ergebnisse eingesetzt. Eine Pflegekraft in einer Justizvollzugsanstalt fordert beispielsweise eine grundlegende Stoffwechseluntersuchung an. Der Auftrag wird als ORM-Nachricht übermittelt. Sobald das Labor die Probe ausgewertet hat, wird das Ergebnis als ORU-Nachricht zurückgesendet. Dieser Austausch funktioniert in der Regel gut, wenn beide Systeme HL7 v2 unterstützen, was bei vielen älteren Labor- und Apothekensystemen der Fall ist.

Eine Schwäche von HL7 v2 liegt jedoch in seiner Flexibilität. Die Spezifikationen lassen Interpretationsspielraum, sodass Anbieter den Standard unterschiedlich umsetzen können. Zwei Systeme können daher beide HL7-v2-konform sein und trotzdem nicht ohne Weiteres miteinander kommunizieren. In solchen Fällen ist eine zusätzliche Mapping-Schicht erforderlich.

CDA: Dokumente statt Nachrichten

Die Clinical Document Architecture (CDA) verfolgt einen anderen Ansatz. Anstelle kleiner transaktionsbezogener Nachrichten bündelt CDA ein vollständiges klinisches Dokument in strukturiertem XML. Das Continuity of Care Document (CCD) ist eine standardisierte Form eines CDA-Dokuments und wird häufig verwendet, um eine Zusammenfassung der bisherigen Behandlung auszutauschen.

Ein Beispiel aus der Gesundheitsversorgung im Justizvollzug: Ein Patient wird nach einem Krankenhausaufenthalt zurück in die Justizvollzugsanstalt verlegt oder für eine Behandlung an einen Facharzt überwiesen. Hier ist CDA besonders hilfreich, da ein einziges Dokument unter anderem Diagnosen, Medikamentenlisten, Allergien und kürzlich durchgeführte Behandlungen enthalten kann. Das ist besonders wichtig, wenn einem Arzt nur wenig Zeit bleibt, um sich vor einem Schichtwechsel einen Überblick über einen neuen Patienten zu verschaffen.

CDA-Dokumente können sowohl von Menschen als auch von Maschinen gelesen werden. Das ist einer der Gründe, warum sich das Format trotz neuerer Standards bis heute gehalten hat. Der dokumentenbasierte Ansatz bringt jedoch auch Einschränkungen mit sich. Sollen einzelne Werte aus einem CDA-Dokument extrahiert werden, sind zusätzliche Parsing- und Mapping-Prozesse erforderlich – insbesondere wenn verschiedene Implementierungen optionale Abschnitte und strukturierte Einträge unterschiedlich verwenden. Genau diese Lücke sollte FHIR unter anderem schließen.

FHIR: Datenaustausch auf Basis einzelner Ressourcen

Fast Healthcare Interoperability Resources (FHIR) verfolgt wiederum ein anderes Modell. Gesundheitsdaten werden dabei als einzelne, klar definierte Ressourcen dargestellt, beispielsweise Patient, Observation, MedicationRequest oder Encounter. Diese Ressourcen werden häufig über RESTful Healthcare-APIs in JSON oder XML bereitgestellt. Der Standard unterstützt darüber hinaus auch Dokumente, Nachrichten, Transaktionen, Subscriptions und weitere Austauschmodelle.

Für die Gesundheitsversorgung im Justizvollzug ist dieser Ansatz besonders relevant, da FHIR gezielte Abfragen und – sofern die verbundenen Systeme aktuelle Daten bereitstellen – einen nahezu in Echtzeit erfolgenden Zugriff ermöglicht. Ein Telemedizin-Anbieter, der für eine Konsultation auf die Daten einer Justizvollzugsanstalt zugreift, benötigt beispielsweise nicht die gesamte Patientenakte. Über eine FHIR-API lassen sich gezielt aktive Medikamentenverordnungen abrufen. Für einen vollständigen Medikamentenabgleich können allerdings zusätzlich Daten zur Medikamentengabe, -abgabe und zur gemeldeten Einnahme aus anderen angebundenen Systemen erforderlich sein. Eine vergleichbare Granularität mit HL7 v2 oder CDA zu erreichen, erfordert zusätzliche technische Komponenten, über die viele Einrichtungen bislang nicht verfügen.

Integrationsarchitektur

Eine Interface Engine (oder Integrationsplattform) zwischen dem EHR-System einer Justizvollzugsanstalt und externen Systemen ist ein gängiges Architekturmodell bei der EHR-Integration. Eine solche Integrationsschicht übernimmt einen Großteil der Aufgaben rund um die HL7-Integration:

• HL7-v2-Nachrichten von Laboren und Apotheken empfangen und weiterleiten
• Pflichtfelder validieren
• CDA-Dokumente aus Krankenhausüberweisungen verarbeiten
• Anwendungen für autorisierte Abfragen mit einem FHIR-Server oder einer API-Schicht verbinden
• Bestätigungen und fehlgeschlagene Übertragungen verwalten
• Identifikatoren und Codes zwischen verschiedenen Systemen zuordnen

Dadurch lässt sich die Anzahl direkter Punkt-zu-Punkt-Verbindungen reduzieren, die von den einzelnen Systemen gepflegt werden müssen. Für den Dokumentenaustausch und die FHIR-Integration können weitere Komponenten eingesetzt werden: Ein API-Gateway kann Authentifizierungs- und Zugriffsrichtlinien durchsetzen, ein Master Patient Index kann Patientenakten anhand unterschiedlicher Identifikatoren einrichtungsübergreifend zuordnen, und ein FHIR-Server kann Ressourcen speichern und bereitstellen.

Wie Standards Arbeitsabläufe in der Gesundheitsversorgung im Justizvollzug unterstützen

Da klinische Arbeitsabläufe unterschiedliche Anforderungen haben, können verschiedene Verfahren für den Datenaustausch eingesetzt werden. HL7 v2 ist weiterhin bei transaktionsbasierten Integrationen verbreitet, während sich CDA für vollständige klinische Zusammenfassungen eignet. FHIR ermöglicht einen granularen Zugriff über APIs, während für die Abrechnung in der Regel eine separate Familie von Standards zum Einsatz kommt.

In der Praxis überschneiden sich diese Verfahren häufig. Ein externes Krankenhaus kann beispielsweise eine CDA-Entlassungszusammenfassung übermitteln und gleichzeitig ausgewählte Ergebnisse über eine FHIR-API bereitstellen. Für den Medikamentenabgleich kann das System Verordnungen aus dem EHR der Justizvollzugsanstalt mit Daten zur Medikamentengabe in der Einrichtung und der Abgabehistorie aus einem Apothekensystem kombinieren. Die eigentliche Herausforderung besteht darin, diese verschiedenen Datenquellen zusammenzuführen, ohne eine einzelne Ressource als vollständige klinische Patientenakte zu betrachten.

Die folgende Grafik fasst die häufigsten Anwendungsfälle zusammen und zeigt, welche Informationen ausgetauscht werden und welches Integrationsverfahren jeweils typischerweise zum Einsatz kommt:

Sicherheit und Authentifizierung

Für ausgetauschte Daten können gesetzliche oder regulatorische Einschränkungen gelten. Beispielsweise können Unterlagen, die von einem staatlich unterstützten Programm zur Behandlung von Suchterkrankungen geführt werden, unter 42 CFR Part 2 fallen. Gleichzeitig können einzelstaatliche Gesetze zusätzliche Anforderungen an Daten zur psychischen Gesundheit und andere sensible Informationen stellen. Jede Integrationsarchitektur muss solche Vorgaben berücksichtigen.

Entwicklungsteams sollten dabei mindestens einige grundlegende Sicherheitsmaßnahmen beachten:

• Authentifizierung und Autorisierung: FHIR-APIs sollten beides über das API-Gateway oder den FHIR-Server durchsetzen.
• Datenübertragung: Daten sollten über TLS übertragen werden.
• Eingeschränkter Zugriff: Der Zugriff sollte sowohl für Benutzer als auch für Anwendungen begrenzt werden. Dafür können OAuth 2.0 und SMART on FHIR eingesetzt werden.
• System-zu-System-Verbindungen: Hier können eine Authentifizierung mit privaten Schlüsseln oder Mutual TLS zum Einsatz kommen.
• Zugriffsrichtlinien: Sie sollten dem Least-Privilege-Prinzip folgen, auf kurzlebigen Zugangsdaten basieren und eine sichere Schlüsselrotation, Verschlüsselung ruhender Daten sowie rollen- oder attributbasierte Zugriffskontrollen für sensible Daten umfassen.

Bei Legacy-Verbindungen ist zu beachten, dass HL7 v2 keine eigene Authentifizierung bietet. Solche Verbindungen sind daher in der Regel auf abgesicherte Netzwerkkanäle angewiesen.

Systeme im Justizvollzug können zudem Gegenstand rechtlicher Untersuchungen sein. Deshalb muss jeder Zugriff auf eine Patientenakte nachvollziehbar sein. Es sollte erfasst werden, wer auf Informationen zugegriffen oder sie ausgetauscht hat, welche Datensätze betroffen waren und ob die jeweilige Transaktion erfolgreich war. Die entsprechenden Protokolle sollten Aktivitäten über API-Gateway, Interface Engine, FHIR-Server und EHR hinweg miteinander verknüpfen. So können Administratoren einen Datenaustausch rekonstruieren und fehlgeschlagene oder unautorisierte Zugriffe untersuchen.

Patientenabgleich: ein oft unterschätztes Problem

Reale Aufnahmedaten aus Justizvollzugsanstalten stellen den Patientenabgleich vor Probleme, die in einer sauberen Demo-Datenbank kaum sichtbar werden. Namen können bei der Aufnahme falsch geschrieben werden, Aliasnamen sind keine Seltenheit und Geburtsdaten werden unter Zeitdruck mitunter fehlerhaft erfasst. Wird eine Person in einer Einrichtung unter einem Spitznamen und in einer anderen unter ihrem offiziellen Namen registriert, können die Datensätze nicht ohne Weiteres einander zugeordnet werden.

Ein fehlerhafter Abgleich ist mehr als nur ein Problem der Datenbereinigung. Im schlimmsten Fall werden die Datensätze zweier verschiedener Personen zusammengeführt oder die medizinische Vorgeschichte eines erneut aufgenommenen Patienten wird nicht mit seinem neuen Aufenthalt verknüpft. In beiden Fällen entsteht ein Risiko für die Patientensicherheit.

Eine gängige Methode zur Vermeidung solcher Fälle besteht darin, deterministische Regeln mit probabilistischen oder algorithmischen Verfahren für den Abgleich von Namen, Geburtsdaten, Aliasnamen und anderen verifizierten Identifikatoren zu kombinieren. Unterstützt wird dieser Prozess häufig durch einen Master Patient Index.

Das folgende Beispiel verwendet eine gewichtete deterministische Bewertung für den Fall, dass ein einzelner exakter Identifikator keinen zuverlässigen Treffer liefert:

function exactTextMatch(left, right) {
  return Boolean(
    left &&
    right &&
    left.trim().toLowerCase() === right.trim().toLowerCase()
  );
}

function exactValueMatch(left, right) {
  return Boolean(left && right && left === right);
}

function matchScore(candidate, incoming, weights = {}) {
  const appliedWeights = {
    lastName: 0.3,
    firstName: 0.2,
    dob: 0.35,
    ssnLast4: 0.15,
    ...weights
  };

  let score = 0;

  if (exactTextMatch(candidate.lastName, incoming.lastName)) {
    score += appliedWeights.lastName;
  }

  if (exactTextMatch(candidate.firstName, incoming.firstName)) {
    score += appliedWeights.firstName;
  }

  if (exactValueMatch(candidate.dob, incoming.dob)) {
    score += appliedWeights.dob;
  }

  if (exactValueMatch(candidate.ssnLast4, incoming.ssnLast4)) {
    score += appliedWeights.ssnLast4;
  }

  return score;
}

function findBestMatch(
  candidates,
  incoming,
  threshold = 0.75,
  minimumMargin = 0.15
) {
  const ranked = candidates
    .map(candidate => ({
      candidate,
      score: matchScore(candidate, incoming)
    }))
    .sort((a, b) => b.score - a.score);

  const best = ranked[0];
  const secondBest = ranked[1];

  if (!best || best.score < threshold) {
    return { status: "no_match" };
  }

  if (secondBest && best.score - secondBest.score < minimumMargin) {
    return {
      status: "manual_review",
      candidates: [best, secondBest]
    };
  }

  return {
    status: "matched",
    candidate: best.candidate,
    score: best.score
  };
}

Natürlich sind noch einige Anpassungen erforderlich, bevor dieses Beispiel in einer Produktivumgebung eingesetzt werden kann. Die Implementierung sollte demografische Daten normalisieren, Aliasnamen, fehlende Werte und unterschiedliche Schreibweisen berücksichtigen und die verwendeten Regeln anhand lokaler Patientendaten validieren. Das Beispiel soll lediglich zeigen, wie Schwellenwerte genutzt werden können, um Kandidaten unterhalb eines bestimmten Wertes automatisch auszuschließen. Liegen mehrere Kandidaten bei der Bewertung sehr nah beieinander, ist eine manuelle Überprüfung erforderlich.

Praxisbeispiel: Verlegung eines Inhaftierten bei ausstehendem Laborergebnis

Nehmen wir an, ein Inhaftierter wird von einem lokalen Gefängnis in eine staatliche Justizvollzugsanstalt verlegt, während ein Laborergebnis noch aussteht. Das EHR-System des Gefängnisses hat den ursprünglichen Auftrag als HL7-v2-ORM-Nachricht gesendet. Zum Zeitpunkt der Verlegung hat das Labor das entsprechende ORU-Ergebnis noch nicht zurückgesendet.

Verfügt das Justizvollzugssystem über einen gemeinsamen Master Patient Index und ein aktuelles Verlegungsregister, kann die Integrationsschicht erkennen, dass der Patient verlegt wurde. Sobald das ORU-Ergebnis vorliegt, kann das System die von der sendenden und der empfangenden Einrichtung verwendeten Identifikatoren zuordnen, das Ergebnis mit dem ursprünglichen Auftrag verknüpfen und es an die autorisierte Zielstelle übermitteln.

Auch die Protokollierung darf dabei nicht außer Acht gelassen werden. Für jeden Schritt dieses Workflows sollten Bestätigungen gespeichert werden. Das System sollte außerdem doppelte Einträge verhindern und eindeutig festlegen, welches Behandlungsteam für die Prüfung kritischer Ergebnisse und die entsprechenden Maßnahmen verantwortlich ist.

Codebeispiel

Das Engineering-Team von Chudovo war bereits an der Entwicklung dieser Art von FHIR-Client-Logik beteiligt. Auf Grundlage dieser Erfahrung zeigt das folgende Beispiel eine vereinfachte FHIR-Anfrage, mit der die aktiven Medikamentenverordnungen eines Patienten vor einer Verlegung abgerufen werden. Dabei handelt es sich jedoch nicht um eine vollständige, abgeglichene Übersicht aller Medikamente, die der Patient aktuell einnimmt.

async function getActiveMedicationOrders(patientId, fhirBaseUrl, accessToken) {
  const response = await fetch(
    `${fhirBaseUrl}/MedicationRequest?patient=${patientId}&status=active`,
    {
      headers: {
        Authorization: `Bearer ${accessToken}`,
        Accept: "application/fhir+json",
      },
    }
  );

  if (!response.ok) {
    throw new Error(`FHIR request failed: ${response.status}`);
  }

  const bundle = await response.json();
  return bundle.entry?.map((e) => e.resource) ?? [];
}

Fazit

Die wichtigsten Erkenntnisse aus diesem Artikel lassen sich wie folgt zusammenfassen:

• Einige Systeme unterstützen weiterhin ausschließlich HL7 v2 und bieten möglicherweise keine FHIR-Endpunkte an. Die Einführung von FHIR ist daher nach wie vor uneinheitlich.
• Eine Interface Engine kann die Integration verschiedener Systeme erleichtern, bringt jedoch zusätzliche betriebliche Komplexität mit sich. Zudem müssen die Mapping-Regeln kontinuierlich gepflegt werden, wenn Anbieter ihre Formate ändern.
• Mechanismen für den Patientenabgleich können die Zahl fehlerhafter Zuordnungen reduzieren, aber nicht vollständig verhindern. Ein falscher Abgleich hat im Justizvollzug konkrete Folgen und ist weit mehr als nur ein Problem der Datenbereinigung.
• Jede Integrationsschnittstelle erfordert kontinuierliche Wartung und nicht nur einen einmaligen Implementierungsaufwand. Gerade bei begrenzten Budgets muss dieser Aspekt berücksichtigt werden.

Ergänzend zu bestehenden HL7-v2- und CDA-Integrationen kann ein FHIR-basierter Datenaustausch dazu beitragen, Verzögerungen beim Zugriff auf Patientenakten zu reduzieren. Gleichzeitig erhalten medizinische Fachkräfte bessere Informationen für den Medikamentenabgleich, und der Datenaustausch lässt sich transparenter nachvollziehen. Dafür sind jedoch eine zuverlässig implementierte Patientenidentifikation, klar definierte Verantwortlichkeiten innerhalb der Workflows und geeignete Zugriffskontrollen erforderlich. In einem Umfeld, in dem fehlende Informationen nicht nur administrative Probleme verursachen, sondern die Patientensicherheit gefährden können, ist dieser Aufwand gerechtfertigt.