Was ist "HL7 v2"?

7 Minuten Lesezeit
Serie
hl7 • hl7v2 • medical it standards • series • structured data

Dieser Post ist Teil der Serie “Medizinische Datenformate”. Wie immer gilt: Kommentare, Korrekturen, Ergänzungen willkommen.

Ziel dieses Posts ist die Antwort auf die Frage “Was ist eigentlich der Standard ‘HL7 v2’?". Publikum sind Interessierte Personen aller Art, ggf. ist ein wenig klinisches und/oder IT-Wissen notwendig.

HL7 v2.x

Das ist “der” HL7-Standard in Version 2, und Stand heute (2022-01-14) auch der meistgenutzte Standard für die Integration medizinischer Systeme untereinander, von DICOM (was eine andere Zielsetzung hat, mehr dazu in einem anderen Post) vielleicht einmal abgesehen. Wenn jemand sagt “ein System ‘kann’ HL7”, dann ist zu 99% HL7 in Version 2.x gemeint.

  • Erste Veröffentlichung im Oktober 1987
  • Aktuelle Version: 2.9, bzw. Version 2.5 für die deutschen Profile (Stand 2022-01-03)
  • Textbasiertes, proprietäres Datenformat (Beispiel weiter unten)
  • Nachrichten-Charakter - Ereignisse lösen Nachrichten aus die dann von Systemen verarbeitet werden
  • Tief im klinischen IT Umfeld verankert, man kommt heute nicht ohne HL7 v2 aus
  • “Ziel […] ist die Vereinfachung der Umsetzung der medizinischen Prozessabläufe zwischen den beteiligten Systemen und die Schaffung von Interoperabilität zwischen verschiedenen Betreibern und Herstellern." (Wikipedia)

Ein Anwendungsfall ist: Ein Krankenhaus fordert von einem Labor eine Blutuntersuchung an (Nachricht an das Labor: bitte mach die Untersuchung). Das Labor macht die Untersuchung, und schickt die Ergebnisse HL7-encodiert zurück (Nachricht zurück an das Krankenhaus: hier bitte). Die HL7 Nachrichten enthalten dann die notwendigen Metadaten (Patient, Untersuchung, ID der geschickten Blutprobe, etc.) und das Untersuchungsergebnis - entweder in strukturierter Form, oder als eingebettetes Dokument.

Die HL7 v2 Nachrichten sind unterteilt in verschiedene Nachrichtentypen (mehr & Beispiel weiter unten), zB eine ADT Nachricht, mit der man u. a. Patienten-Stammdaten in verschiedenen Systemen aktuell halten kann. Die Veröffentlichung erfolgt auf HL7.org, eine Sammlung der deutschen Profile (ein anderes Wort für “Nachrichtentypen”) auf HL7.de (seit Jahren als “Vorabversion” an der offenbar niemand mehr arbeitet). Dabei werden über HL7 v2 sowohl “Inhalt und Struktur der der zu übermittelnden Daten” festgelegt.

Man kann HL7 v2 Nachrichten nicht “speichern”, bzw. es ergibt keinen Sinn. Die Nachrichten stellen Informations-“Updates” oder Handlungsanweisungen an empfangende Systeme dar, die den Inhalt verarbeiten und ggf. den eigenen Zustand anpassen (Änderung eines Stammdatensatzes, Eintragen einer Diagnose, etc.). Es kann also keinen “HL7 v2 Arztbrief” geben! Es gibt maximal eine Nachricht, die einen Arztbrief (zB als PDF) überträgt. (Eine lesenswerte Abhandlung zum Thema “Message or Document” findet sich bei Ringholm). Man kann - und sollte - Nachrichten allerdings zwischenspeichern, so dass Empfänger, die gerade nicht erreichbar sind, diese nicht verpassen und die darin enthaltene Information nicht leise und unbeachtet verschwindet.

Fast jedes Unternehmen setzt für das Management der HL7 v2 Datenströme einen sog. “Kommunikationsserver” ein. Dieser fungiert als zentraler Daten-Verteiler, und kann auch kleinere Transformationsaufgaben übernehmen (zB Anpassung von Feldinhalten je nach Empfänger, Übermittlung nur unter bestimmten Bedingungen, etc.). Eine mehr als sinnvolle und unbedingt notwendige Komponente, um effektiv mit HL7 v2 zu arbeiten. Dieser stellt typischerweise auch mit Hilfe besagter Zwischenspeicherung sicher, dass die Nachrichten auch an das Empfängersystem ausgeliefert wurden.

Die in Deutschland verwendete Version 2.5 ist “push-gesteuert”. Das heißt dass Systeme benötigte Informationen nicht von anderen Systemen “anfragen” können. Man muss sich als Empfänger darauf verlassen können, alle Updates (incl. der Nachricht “neues Objekt”) proaktiv erhalten zu haben, um dann einen eigenen Status zu pflegen. (In v2.9 existieren dagegen sog. Queries - V29_CH05_Queries.pdf).

HL7 Nachrichten werden normalerweise unverschlüsselt übertragen. Das muss nicht so sein, ist es allerdings in allen mir bekannten Fällen. Es ist sogar so, dass viele Systeme eine verschlüsselte HL7 v2 Kommunikation gar nicht unterstützen. In v2.9 wurde dazu das “HL7 Healthcare Privacy and Security Classification System (HCS)” aufgenommen. Bis incl. v2.8 (V28_CH01_Intro.pdf, S. 19) hat der Standard eine recht simple Haltung:

HL7 Version 2.8 is largely silent about the issues of privacy authentication and confidentiality of data that pass through HL7 messages. HL7 makes no assumption about the ultimate use of data but rather assumes that both source and destination applications provide for these requirements. In addition, HL7 does not, at this time, specify what, if any, encryption method should be used when transporting HL7-based messages between two or more systems. At this time, HL7 implementers should familiarize themselves with legal and professional requirements for these topics specific to their country’s national or local requirements.

Stand heute kommt an HL7 v2 niemand vobei, es ist tief in alle medizinischen IT Prozesse integriert. HL7 v2 wird dabei für die Kommunikation innerhalb des eigenen Unternehmens genutzt, wie auch für die Kommunikation zwischen Unternehmen.

Interoperabilität

Eine Integration zweier Systeme hat immer folgenden Prozess zur Folge:

  • Abklären welche Nachrichtentypen von beiden Systemen für den spezifischen use case unterstützt werden (manchmal hat man mehrere Möglichkeiten!)
  • Nachrichten-Typen, -Inhalt und Kodierung der Inhalte abstimmen
    • Welche Informationen stehen in welchem Feld? In welchen Feldern werden (welche?) Zusatz-Informationen übertragen?
    • Wie ist diese Information kodiert? Ein Datum kann man als YYYY-MM-DD übertragen, oder als TT.MM.JJJ. HL7 v2 hat hier keine Präferenz, und das ist ein triviales Beispiel.
    • Und nicht zuletzt: Die sog. “Codepage”. Der Standard (“US ASCII”) kennt keine Umlaute, Akzente (é, î, …) oder nicht-lateinischen Buchstaben. Mit dem oft in Deutschland gebräuchlichen Standard ISO 8859/1 geht viel, bis auf zB einige türkische Namen. UTF-8 (der heutige Standard mit dem “alles” geht) ist eine Ausnahme.
  • Finales Verbinden der Systeme
    • Direkt, über einen Kommunikationsserver, ein VPN, SFTP, Dateiablagen, etc. (generell irgendein Verfahren aus dem 20. Jahrhundert)

Eine einmal hergestellte Integration ist weder flexibel noch wiederverwendbar.

Zwei Dinge sollte man über HL7 v2 verstanden haben

Erstens. Es ist kein “Standard” in dem Sinne dass man zwei HL7-Systeme miteinander “verbindet und es läuft”, etwa wie das “iPhone mit der iCloud”, sondern eher “wir verbinden die smarte Glühbirne mit der Heimautomatisierungs-Software” - viel hantieren und danach nicht mehr anfassen. Die Integration zweier Komponenten benötigt grundsätzlich eine individuelle Anpassung aneinander und eine vorhergehende Abstimmung der Parteien.

Zweitens. HL7 v2 Daten können strukturiert sein, müssen allerdings nicht. Das Labor kann die Ergebnisse hervorragend als PDF Dokument zurückschicken, was in der Praxis auch zu einem signifikaten Prozentsatz vorkommt. Die Antwort-Nachricht(en) enthalten dann die Informationen über den Auftrag, und als Nutzlast eine PDF Datei mit den Ergebnissen, die dann vom Empfänger entsprechend verarbeitet (also in der Patientenakte gespeichert) wird.

Beispiele typischer Anwendungsfälle für HL7 v2

  • Patientendaten werden über verschiedene Systeme hinweg aktuell gehalten. Das führende System hält alle angeschlossenen Systeme über sog. ADT Nachrichten auf dem neuesten Stand.
  • Labor-, Radiologie-, Pathologie-Anforderungen und die entsprechenden Befundübermittlungen. Eine “Anforderungsnachricht” (zB ORM) geht an den Dienstleister, dieser antwortet später entweder mit einer ORR Nachricht (strukturierte Daten), oder einer MDM Nachricht (eingebettetes PDF).
  • Übertragung von binär-Dokumenten zwischen Systemen. Das geschieht über sog. MDM Nachrichten.
  • Übertragung von Abrechnungsinformationen. Eine BAR Nachricht transportiert Diagnosen und DRGs zu einem verarbeitenden System, das mit einer ACK Nachricht antwortet.

Ganz kurzer technischer Überblick

Generell definiert HL7 v2 sog. “Nachrichtentypen”, die sich nach Inhalt und Anwendung unterscheiden. Hier ein Auszug:

  • HL7 ADT - “Admission, Discharge, Transfer”; Patient/Fall Stammdaten
  • HL7 MDM - “Medical Document Management”; Dokument (unspezifisch, binär, zB PDF)
  • HL7 ORM - “Order Message”; Anforderung
  • HL7 ORR - “Order Response”; Antwort auf eine ORM Nachricht
  • HL7 ORU - “Observation Result Unsolicited”; proaktive Befundübermittlung

… etc. Jede Nachricht besteht intern aus sog. Segmenten unterschiedlicher Typen (EVN, MSA, MSH, OBR, etc.). Zusätzlich zu den definierten Segmenttypen kann man noch eigene sog. “Z-Segmente” definieren und Nutzen, das sind nutzerspezifische, in HL7 v2 nicht enthaltene Erweiterungen.

Beispielnachricht

Ein Beispiel einer ORM-Nachricht könnte folgendermaßen aussehen:

MSH|^~&|HIS|MedCenter|LIS|MedCenter|20060307110114||ORM^O01|MSGID20060307110114|P|2.3
PID|||12001||Jones^John^^^Mr.||19670824|M|||123 West St.^^Denver^CO^80020^USA|||||||
PV1||O|OP^PAREG^||||2342^Jones^Bob|||OP|||||||||2|||||||||||||||||||||||||20060307110111|
ORC|NW|20060307110114
OBR|1|20060307110114||003038^Urinalysis^L|||20060307110114

Was man sofort sieht sind die verschiedenen Nachrichten-Segmente (MSH, PID, PV1, etc.), der Nachrichtentyp (ORM) selbst ist im ersten Segment im 9. Feld kodiert. (Jede HL7 v2 Nachricht beginnt übrigens mit einem MSH Segment, das steht für “Message Header”).

HL7 v2+

Wenn man lange genug sucht stößt man auf Referenzen und Erwähnungen von HL7 v2+. Dies war offenbar ein Versuch, das ehrwürdige HL7 v2 für neue Anwendungsfälle zu erweitern.

Mein persönlicher Eindruck ist jedoch: Das wurde leise abgebrochen. Man findet keine Artikel, Software oder Blogposts, und nur eine einsame Website mit der “working draft” Spezifikation.

Und damit wären wir am Ende meiner Zusammenfassung über HL7 v2(plus).