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

Wenn du im Fintech gearbeitet hast, hast du wahrscheinlich ISO 8583 geparst. Wenn du in der Logistik gearbeitet hast, hast du mit EDI zu tun gehabt. Wenn du mit Healthcare-Daten gearbeitet hast — konkret wenn du eine Live-Integration zwischen zwei Krankenhaussystemen gebaut hast — hast du HL7 v2 gesehen, und du hast Meinungen darüber, die du vorher nicht hattest.

Ich schrieb die HL7-Integration zwischen King Hussein Cancer Centre (KHCC) und HAKEEM, Jordaniens nationalem EHR, während ich bei Electronic Health Solutions zwischen 2010 und 2013 arbeitete. So hat das wirklich ausgesehen.

Wie eine HL7-v2-Nachricht aussieht

Fangen wir mit dem Wire-Format an, weil das das Erste ist, bei dem Engineers ein Gesicht machen.

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||||||||ONCOLOGY|||V|||||||||||||||||||||||20120315

Das ist ein ADT^A01 — eine Admit/Discharge/Transfer-Nachricht, Event A01 bedeutet Patientenaufnahme. Jedes Segment ist pipe-delimited. Felder innerhalb eines Segments sind durch Pipes getrennt. Sub-Felder durch ^. Sub-Sub-Felder durch &. Sich wiederholende Felder durch ~.

Das MSH-Segment ist der Nachrichten-Header: sendende Anwendung, sendende Einrichtung, empfangende Anwendung, empfangende Einrichtung, Timestamp, Nachrichtentyp, Nachrichten-ID, Processing-ID, Version. Das PID-Segment ist die Patienten-ID: Patienten-ID-Liste (es kann viele geben, aus vielen Systemen), Name, Geburtsdatum, Geschlecht, Adresse, Sprache, Familienstand, Religion, Kontonummer.

HL7 v2.3 — die Version, mit der wir arbeiteten — wurde 1997 finalisiert. Das Pipe-delimited Format datiert aus einer Zeit, als Bandbreite teuer war und XML die Enterprise-Welt noch nicht erobert hatte. Es ist nicht schön. Es mappt direkt auf die Art, wie Krankenhaussysteme Patientendaten tatsächlich speichern und austauschen — weshalb es trotz der Existenz von FHIR, CDA und jedem anderen Standard, der es ersetzen sollte, bis heute das dominierende Wire-Format im Healthcare-Bereich ist.

Warum KHCC eine spezifische Integrationsherausforderung war

King Hussein Cancer Centre ist kein Allgemeinkrankenhaus. Es ist eine spezialisierte Onkologieeinrichtung. Patienten kommen per Überweisung von anderen Krankenhäusern zu KHCC — von denen viele in Jordaniens nationalem System bereits auf HAKEEM waren.

Das bedeutet, eine Patientenakte beginnt nicht bei KHCC. Sie beginnt an der überweisenden Einrichtung — sagen wir, Prince Hamza Hospital — wo der Patient zuerst mit einer Erkrankung diagnostiziert wurde, die onkologische Expertise erforderte. Diese Patientenakte enthält Demographiedaten, Erstdiagnose, Medikamentengeschichte, Laborbefunde. All das lebt in HAKEEM.

Wenn dieser Patient zur Krebsbehandlung in KHCC ankommt, hat KHCC sein eigenes EHR. Seinen eigenen Patienten-ID-Raum. Sein eigenes Datenmodell für klinische Konzepte wie Chemotherapie-Protokolle, Strahlentherapiepläne und onkologie-spezifische Labor-Panels. Die Herausforderung ist nicht nur “KHCCs Daten in HAKEEM bekommen.” Die Herausforderung ist Patienten-Identitäts- Auflösung über zwei Systeme, die demselben Menschen verschiedene IDs zugewiesen haben, gefolgt von bidirektionaler Datensatz-Synchronisation, die beide Systeme aktuell hält, ohne Duplikate zu erstellen oder klinischen Kontext zu verlieren.

HL7 v2 ist die Transport-Schicht für dieses Problem. Es ist nicht die Lösung für dieses Problem. Die Lösung ist ein Patienten-Matching-Algorithmus, ein Master Patient Index und eine Message-Routing-Schicht, die versteht, welche Events in einem System Nachrichten an das andere auslösen sollen.

Die Teile, die wirklich schwer sind

Hier ist, was “einfach HL7 parsen” auslässt.

Patientenidentität ist kein gelöstes Problem. KHCC wies ihre eigenen Medical Record Numbers (MRN) zu. HAKEEM pflegte sein eigenes nationales Patienten-ID-Schema. Das PID-Segment hat ein Feld für eine Patienten-ID-Liste — PID-3 — genau weil ein Patient mehrere IDs über mehrere Systeme hat. Aber zu wissen, dass der Patient die IDs 12345 bei KHCC und 98765 in HAKEEM hat, erfordert eine Mapping-Tabelle, und diese Tabelle aufzubauen erfordert entweder einen automatisierten probabilistischen Matching-Algorithmus (matche auf Name + Geburtsdatum + Geschlecht + Adresse, score die Konfidenz) oder einen manuellen Abgleichsprozess oder — in der Praxis — beides, mit verschiedenen Regeln für verschiedene Konfidenzschwellen.

Event-Sequenzierung ist klinisch bedeutsam. Eine HL7-ADT-Nachricht trägt einen Event-Typ — A01 ist Aufnahme, A02 ist Transfer, A03 ist Entlassung, A08 ist Patienten-Informations-Update. Diese Events müssen in Reihenfolge ankommen und in Reihenfolge verarbeitet werden, oder dein klinisches Bild ist falsch. Ein Patient, der aufgenommen (A01), transferiert (A02) und dann entlassen (A03) wurde, sieht sehr anders aus als einer, bei dem diese Nachrichten außer der Reihe ankommen und als aufgenommen, entlassen, dann in eine Abteilung transferiert verarbeitet werden, die er bereits verlassen hatte.

In einer hochvolumigen Krankenhausintegration kommen Nachrichten nicht immer in Reihenfolge an. TCP gibt dir zuverlässige Zustellung; es gibt dir keine Anwendungsebene-Reihenfolge-Garantien, wenn Nachrichten asynchron von verschiedenen Systemen produziert werden. Du brauchst Sequenznummern, Message-Acknowledgment (ACK/NAK) und eine Queue mit Retry-Logik, die NAKs handhabt, ohne die Nachricht zu verlieren oder das Ziel mit Duplikaten zu überfluten.

Die Implementierung des sendenden Systems ist die reale Spezifikation. HL7 v2.3 ist ein Standard. Aber der Standard hat optionale Felder, optionale Segmente und erheblichen Spielraum für Implementierungsvariationen. Was KHCCs EHR tatsächlich in PID-3 schickte, war das, was zählte — nicht was die HL7-Spec sagt, was dort sein sollte. Ich verbrachte nennenswerte Zeit mit KHCCs technischem Team damit, ihre tatsächlichen ausgehenden Nachrichten zu analysieren, um zu verstehen, was wir empfangen würden, weil die Implementierungsdokumentation unvollständig war. Das ist normal. Jede HL7-Integration, von der ich gehört habe, hat eine Version dieser Geschichte.

Wie die Message-Routing-Schicht aussah

Die HAKEEM-KHCC-Integration verwendete das HL7-Messaging-Package in VistA — die MUMPS-Routinen in diesem Package handhabten eingehende Nachrichten-Parsing und -Routing auf der HAKEEM-Seite. Ich schrieb die Routinen, die spezifische Event-Typen handhabten — primär ADT-Events für Patientenbewegungen und ORM/ORU-Paare für Labor-Aufträge und -Ergebnisse.

Der Flow für eine Überweisung:

  1. Das überweisende Krankenhaus (auf HAKEEM) schickt den Patienten zu KHCC.
  2. KHCC registriert den Patienten in ihrem System, weist ihre MRN zu.
  3. KHCC schickt ein ADT^A01 an HAKEEM, das die Aufnahme bestätigt.
  4. Die HAKEEM-HL7-Routing-Schicht empfängt das A01, löst die Patienten-Identität über das MPI-Mapping auf und aktualisiert die Patientenakte in HAKEEM mit den KHCC-Encounter-Informationen.
  5. Labor-Ergebnisse aus KHCCs Onkologie-Panels fließen über ORU^R01-Nachrichten zurück und landen in der Patientenakte in HAKEEM, sichtbar für die überweisenden Ärzte, die noch die primäre Betreuungsbeziehung halten.

Dieser letzte Punkt ist klinisch wichtig. Ein Onkologe bei KHCC behandelt den Krebs. Der Allgemeinmediziner an der überweisenden Einrichtung verwaltet noch die Hypertonie, den Diabetes und alles andere des Patienten. Sie müssen die Onkologie-Ergebnisse sehen. Die HL7-Integration ist das, was das möglich macht, ohne dass der Patient Papierdokumente zwischen Einrichtungen tragen muss.

Was ich heute, zwölf Jahre später, über HL7 denke

HL7 v2 ist keine schöne Software. Aber es ist die Art von Hässlich, die deinen Respekt verdient: hässlich, weil die Problemdomäne hässlich ist, nicht weil die Designer es nicht versucht haben.

Healthcare-Daten sind unordentlich, weil Healthcare unordentlich ist. Patienten haben mehrere IDs, weil sie mit mehreren Systemen interagieren. Events haben Reihenfolge-Anforderungen, weil klinische Timelines für Diagnose und Behandlung wichtig sind. Die Feld-Optionalität, die die Spec locker wirken lässt, ist da, weil verschiedene klinische Fachrichtungen verschiedene Datenanforderungen haben und der Standard alle bedienen muss.

FHIR ist in den meisten Hinsichten wirklich besser — RESTful, JSON oder XML, ressourcenorientiert, modernes Tooling. Es ist auch zwölf Jahre neuer. 2012 war FHIR eine Entwurfsspezifikation. HL7 v2 war das, was Krankenhaussysteme sprachen. Du integrierst mit dem, was da ist.

Die Engineers, die Healthcare-Integrationen bauen, tun Arbeit, die der Großteil der Industrie nicht sieht und über die er nicht nachdenkt. Die HL7-Nachricht, die dein Laborergebnis vom Labor-System in deine Akte und auf den Bildschirm deines Arztes trägt, ist Sanitärinstallation. Niemand bemerkt die Leitungen, bis sie kaputt gehen.

Ich bemerkte die Leitungen. Ich baute einen Teil davon. Die Rohre laufen noch.