Das HL7 (Health Level 7) ist ein Set internationaler Standards für den elektronischen Austausch von medizinischen, administrativen und finanziellen Daten zwischen Informationssystemen im Gesundheitswesen. Die "7" steht für die siebte Schicht des ISO/OSI-Referenzmodells (Anwendungsschicht).

HL7 zielt darauf ab, Formate und Protokolle zum Austausch von Datensätzen und Dokumenten zwischen Computersystemen im Gesundheitswesen bereitzustellen. Ein weiteres Ziel ist die Standardisierung der auszutauschenden Inhalte und damit eine Vereinheitlichung der Schnittstellen (semantische Operabilität). HL7 ist ein syntaktischer Kommunikationsstandard und wird in Deutschland bisher hauptsächlich im KH-Bereich eingesetzt. Die Bereiche der Abrechnung, Befundermittlung, Aufnahme, Verlegung, Entlassung, Auftragserteilung oder die Terminveregabe verwenden HL7. Der Bereich der Radiologie und Übermittlung von Bildern im Allgemeinen ist etwas ausgeklammert, dort kommt eher der Standard DICOM zum Einsatz.

Wir unterscheiden zwischen vier verschiedenen Ausprägungen von HL7 (v1 existiert implizit nicht):

HL7 v2.x

Ist weit verbreitet und der aktuell wichtigste HL7-Standard.

nicht in XML realisiert sondern mittels Segmenten und Delimitern. HL7 v2-Nachrichten sind event-getriggert und bestehen aus Segmenten, die durch einen Zeilenumbruch terminiert sind. Ein Segment wiederum bestehte aus Feldern und diese wiederum aus Komponenten. Sogenannte Pipes trennen die Als erstes Segment kommt IMMER ein Message-Header (MSH). Er enthält Informationen über die Nachricht, deren Typ und das Trigger-Event. Leere Felder werden mit einem doppelten vertikalen Strich gekennzeichnet, wie in folgendem Beispiel ersichtlich:

MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-  0500||ADT^A01|01052901|P|2.5    EVN||200605290901||||200605290900    PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-  9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST  DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL’S PICKLES^10000 W 100TH  AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN    PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAING  ER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UA  MC^L|||||||||||||||||||||||||||200605290900    OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F    OBX|2|NM|^Body Weight||79|kg^Kilogram^ISO+|||||F    AL1|1||^ASPIRIN    DG1|1||786.50^CHEST PAIN, UNSPECIFIED^I9|||A

Nach dem Header kommen die body-Segmente. Welche body-Segmente verwendet werden, hängt vom Typ der Nachricht ab (Beispielsweise ergäbe AL1 für Allergien keinen Sinn in einer DFT(Detail Financial Transaction)-Nachricht). Es gibt (leider) auch sog. Z-Segmente: Proprietäre Segmente, die häufig genutzt werden wenn ein gewünschtes Segment nicht im Standard enthalten ist. Grundsätzlich gilt: Die Semantik eines Felds ist durch seine Position in der HL7v2-Spezifikation fest definiert. Im folgenden einige Beispiele für body-Segmente:

• EVN: Event Type
• PID: Patient ID mit persönlichen Daten, Wohnanschrift usw.
• NK1: Next of Kin (nächste Angehörige)
• PV1: Patient Visit (wann, welcher Arzt usw.)
• AL1: Allergien
• OBR: Observation Request
• OBX: Befunde (Observation)
• DG1: Diagnose
• IN1: Insurance (Versicherung)
• FT1: Financial Transaction (für DFT-Nachrichten)
• NKE: Notes and Comments

Des Weiteren sind Datentypen für die Segmente festgelegt. Als Antwort auf eine HL7v2-Nachricht kommt immer eine ACK-Nachricht zurück; der Empfang wird üblicherweise quittiert.

Die Übertragung von HL7v2-Nachrichten erfolgt mit einem eigenen Protokoll, dem MLLP (Minimal Lower-Layer Protocol). Es besteht aus einem Header, der eigentlichen Nachricht sowie dem Trailer und wird über TCP/IP übertragen.

HL7 v3

Ist im Gegensatz zu HL7v2 ist diese Version XML-basiert und stützt sich auf das RIM (Reference Information Model), ein generisches Modell, von dem Domänen und Nachrichtentypen abgeleitet werden.

Jedoch gibt es weltweit vergleichsweise wenige Installationen, weil die Entwicklung und die Anpassung von bestehenden HL7v2-Installationen an die neue Version sehr aufwendig und teuer ist. Eine Ableitung dieses Standards (HL7-CDA) erfreut sich aber umso größerer Beliebtheit.

Das RIM

Mehr Informationen finden sich auf der Seite von HL7.

HL7-CDA

Die Version HL7-CDA (Clinical Document Architecture) basiert auf HL7 v3, dient jedoch dem Austausch und der Speicherung klinischer Dokumente, wie z.B. ein Arztbrief. Es bietet auch die Möglichkeit, Bilder und Signaldaten zu enthalten.

• Es ist ein Dokumentenformat, kein Nachrichtenformat.
• Der Header enthält beschreibende Meta-Daten (Patienteninformation, Arzt, Art des Dokuments, Ereignis).
• Der Body enthält die eigentlich interessanten Daten und ist in drei Level unterteilt, die sich in der Art der Strukturierung unterscheiden (siehe nächste Frage).

Welchen Unterschied gibt es zwischen den HL7-CDA Levels 1, 2 und 3?

• Level 1: Header mit Meta-Daten, Struktur und Inhalt in Freitext innerhalb eines Segments (oder PDF, jpeg usw.)
• Level 2: Level1 + Struktur (Felder, z.B. Diagnose, Befund usw.) kodiert, Inhalte in Freitext, mehrere Segmente
• Level 3: Level2 + Hochstrukturiert, auch die Inhalte sind kodiert --> „Clinical Statements“. Beispielsweise Laborwerte in LOINC-Kodierung, Diagnosen oder Befunde in SNOMED CT usw.

Jedoch hat der Freitext immer Vorrang vor der Kodierung!

HL7-FHIR

Das offizielle FHIR-LogoHL7.orgHL7-FHIR wurde als einfacherer Standard als HL7 v3 entwickelt, ist REST-basiert und benutzt aus technischer Sicht XML und JSON.

Er hat eine sog. RESTful API (Application Programming Interface) und nutzt Standards wie SNOMED-CT, LOINC, DICOM, UCUM usw. FHIR besteht aus:

Ressourcen

Sinnvolle (Informations)Einheiten, die in sich abgeschlossen sind, z.B. Patient, Diagnose, Befund

// Referenzieren von anderen Ressourcen  <context>     <reference value="Patient/123"/>  </context>

Referenzen

Das ist ein Verweis einer Ressource auf eine andere Ressource, z.B. Patient Medikament oder Medikament Arzt

Profile

Profile sind Kombinationen von Ressourcen/Referenzen, die in einem bestimmten Kontext sinnvoll sind.

Bezüglich der Sicherheit macht FHIR keine Vorgaben, dieses Feature muss explitzit implementiert werden!

FHIR-URLS

[base-address]/[Type]/[ID]  // zum Beispiel:  http://server.example.com/fhir/Patient/23455

base-address: FHIR-Server, der den globalen Dienst anbietet.

Type: Dienst gleichartiger Ressourcen, z.B. fihr/Patient

id: Identifikation einer bestimmten Ressource, z.B. der Patienten-ID