KHCC HL7-Integration mit HAKEEM

Die meisten Engineers haben noch nie eine echte HL7-Message gesehen.

Wer im Fintech gearbeitet hat, hat wahrscheinlich ISO 8583 geparst. Wer in Logistics war, hat mit EDI zu tun gehabt. Wer eine Live-Integration zwischen zwei Krankenhaussystemen gebaut hat, der hat HL7 v2 gesehen - und hat Meinungen dazu, die man vorher nicht hatte.

Das Team bei Electronic Health Solutions baute die HL7-Integration zwischen King Hussein Cancer Centre (KHCC) und HAKEEM, Jordaniens nationalem EHR, während des 2010–2013-Engagements. So sah das wirklich aus.

Wie eine HL7-v2-Message aussieht

Das Wire-Format ist das erste, was Engineers ein Gesicht ziehen lässt.

MSH|^~\&|KHCC|KHCC|HAKEEM|MOH|20120315120000||ADT^A01|MSG00001|P|2.3
EVN|A01|20120315120000
PID|1||12345^^^KHCC^MR||AL-MANSOUR^AHMAD^MOHAMMED||19750304|M|||AMMAN^JO||||AR|M||12345
PV1|1|I|ONCOLOGY^101^1^KHCC||||SMITH^JOHN^A^^^DR

Das ist ein ADT^A01 - eine Admit/Discharge/Transfer-Message, Event A01 bedeutet Patientenaufnahme. Jedes Segment ist Pipe-getrennt. Felder innerhalb eines Segments durch Pipes getrennt. Sub-Felder durch ^. Sub-Sub-Felder durch &. Wiederholende Felder durch ~.

Das MSH-Segment ist der Message-Header: sendende Anwendung, sendende Einrichtung, empfangende Anwendung, empfangende Einrichtung, Zeitstempel, Message-Typ, Message-ID, Processing-ID, Version. Das PID-Segment ist die Patientenidentität: ID-Liste, Name, Geburtsdatum, Geschlecht, Adresse, Sprache. Die Version - HL7 v2.3 - wurde 1997 finalisiert. Das Pipe-getrennte Format stammt aus der Zeit vor der Eroberung der Enterprise-Systeme durch XML. Es ist nicht schön. Es mappt direkt darauf, wie Krankenhäuser tatsächlich Patientendaten speichern und austauschen - weshalb es Jahrzehnte später trotz FHIR, CDA und jedes Standards, der es ersetzen sollte, noch das dominante Wire-Format im Healthcare ist.

Warum KHCC eine spezifische Herausforderung war

King Hussein Cancer Centre ist kein allgemeines Krankenhaus. Es ist Jordaniens Flaggschiff-Spezialeinrichtung für Onkologie - ein Centre of Excellence gegründet unter der Schirmherrschaft von Prinzessin Ghida Talal, mit einem Auftrag, der Behandlung, Forschung und Ausbildung in der Region umfasst. Patienten kommen per Überweisung von anderen Krankenhäusern, von denen viele bereits auf HAKEEM waren.

Das bedeutet: Der Patientendatensatz beginnt nicht bei KHCC. Er beginnt in der überweisenden Einrichtung - sagen wir Prince Hamza Hospital - wo der Patient zuerst mit einem Befund diagnostiziert wurde, der onkologische Expertise erfordert. Seine Demographik, Erstdiagnose, Medikamenten-Historie und Laborergebnisse leben alle in HAKEEM.

Wenn dieser Patient bei KHCC ankommt, hat KHCC sein eigenes EHR. Seinen eigenen Patienten-ID-Space. Sein eigenes Datenmodell für Chemotherapie-Protokolle, Bestrahlungsbehandlungspläne und onkologiespezifische Laborpanels.

Die Herausforderung ist nicht “KHCC-Daten in HAKEEM bekommen”. Die Herausforderung ist Patienten-Identitätsauflösung über zwei Systeme, die demselben Menschen verschiedene IDs zugewiesen haben - gefolgt von bidirektionaler Synchronisation, die beide Systeme aktuell hält, ohne Duplikate zu erstellen oder klinischen Kontext zu verlieren.

HL7 v2 ist die Transport-Layer für dieses Problem. Es ist nicht die Lösung dafür.

Die Teile, die wirklich schwer sind

Patientenidentität ist kein gelöstes Problem. KHCC vergab ihre eigenen Medical-Record-Numbers. HAKEEM pflegte sein eigenes nationales Patientenidentifikatoren-Schema. Das PID-3-Feld accommodiert speziell eine Patienten-ID-Liste - weil ein Patient multiple Identifikatoren über mehrere Systeme hat. Aber zu wissen, dass Patient 12345 bei KHCC Patient 98765 in HAKEEM ist, erfordert eine Mapping-Tabelle, und das Bauen dieser Tabelle erfordert entweder probabilistisches Matching auf Name + Geburtsdatum + Geschlecht + Adresse, oder manuelle Abstimmung, oder - in der Praxis - beides, mit verschiedenen Regeln für verschiedene Confidence-Thresholds.

Event-Sequenzierung zählt klinisch. Eine HL7-ADT-Message trägt einen Event-Typ: A01 ist Aufnahme, A02 ist Verlegung, A03 ist Entlassung, A08 ist Informationsaktualisierung. Diese Events müssen in der richtigen Reihenfolge ankommen und verarbeitet werden - sonst ist das klinische Bild falsch. Ein Patient, der aufgenommen, verlegt und dann entlassen wurde, sieht sehr anders aus als einer, bei dem diese Messages außer der Reihe ankommen und als aufgenommen, entlassen, in eine Abteilung verlegt verarbeitet werden, die er bereits verlassen hatte.

In einer Hochvolumen-Integration kommen Messages nicht immer in der richtigen Reihenfolge. TCP gibt zuverlässige Zustellung; es gibt keine Anwendungs-Level-Ordering-Garantien, wenn Messages asynchron produziert werden. Man braucht Sequenznummern, Acknowledgment (ACK/NAK) und eine Queue mit Retry-Logik, die NAKs handhabt, ohne die Message zu verlieren oder das Ziel mit Duplikaten zu fluten.

Die Implementierung des sendenden Systems ist die echte Spezifikation. HL7 v2.3 ist ein Standard mit optionalen Feldern und erheblichem Spielraum für Implementierungsvariationen. Was KHCCs EHR tatsächlich in PID-3 sendete, war das, was zählte - nicht das, was die Spec sagte, was dort sein sollte. Zeit wurde mit KHCCs technischem Team verbracht, ihre tatsächlichen outbound Messages zu analysieren, weil die Implementierungsdokumentation unvollständig war. Das ist normal. Jede HL7-Integration hat diese Geschichte.

Wie die Routing-Layer aussah

Die Integration nutzte das HL7-Messaging-Paket in VistA - MUMPS-Routinen, die eingehende Message-Parsing und -Routing auf der HAKEEM-Seite handhabten. Das Team schrieb Routinen für spezifische Event-Typen: primär ADT-Events für Patientenbewegungen und ORM/ORU-Paare für Labor-Orders und -Ergebnisse.

Der Überweisungsfluss:

1. Das überweisende Krankenhaus (auf HAKEEM) schickt den Patienten zu KHCC.
2. KHCC registriert den Patienten, vergibt seine MRN.
3. KHCC sendet ein ADT^A01 an HAKEEM, das die Aufnahme bestätigt.
4. Die HAKEEM-Routing-Layer empfängt das A01, löst die Patienten-Identität via Master-Patient-Index-Mapping auf und aktualisiert den Patientendatensatz mit den KHCC-Encounter-Informationen.
5. Laborergebnisse von KHCCs Onkologie-Panels fließen via ORU^R01-Messages zurück und landen im HAKEEM-Datensatz des Patienten - sichtbar für die überweisenden Ärzte, die noch die primäre Versorgungsbeziehung des Patienten halten.

Der letzte Punkt zählt klinisch. Ein Onkologe bei KHCC behandelt den Krebs. Der Allgemeinarzt im überweisenden Krankenhaus managt noch den Bluthochdruck des Patienten, den Diabetes, alles andere. Er muss die Onkologieergebnisse sehen, ohne den Patienten auffordern zu müssen, Papierdokumente zwischen den Einrichtungen zu tragen. Die HL7-Integration macht das möglich.

Wie das zwölf Jahre später aussieht

HL7 v2 ist keine schöne Software. Aber es ist die Art hässlich, die Respekt verdient - hässlich, weil die Problem-Domain hässlich ist, nicht weil die Designer es nicht versucht hätten. Healthcare-Daten sind unordentlich, weil Healthcare unordentlich ist. Patienten haben mehrere Identifikatoren, weil sie mit mehreren Systemen interagieren. Events brauchen Ordering, weil klinische Zeitlinien für die Diagnose wichtig sind. Die Feld-Optionalität sieht wie Lockerheit aus; sie ist eigentlich der Standard, der die Breite klinischer Fachgebiete accommodiert, die ihn benutzen müssen.

FHIR ist in den meisten Hinsichten genuinely besser. Im Jahr 2012 war FHIR ein Entwurfs-Spec. HL7 v2 war das, was Krankenhaussysteme sprachen. Man integriert mit dem, was da ist.

Die Engineers, die Healthcare-Integrationen bauen, tun Arbeit, die der Großteil der Industrie nicht sieht. Die HL7-Message, die ein Laborergebnis vom Laborsystem in die Akte zum Bildschirm des Arztes trägt, ist Plumbing. Niemand bemerkt das Plumbing, bis es kaputtgeht. Diese Rohre laufen noch.