HL7 erklärt: Wie Laborsysteme Daten mit klinischen Systemen austauschen

Wenn Ihr Labor Testaufträge von einem Krankenhaus oder einer Klinik erhält und Ergebnisse zurücksendet, muss eine Instanz zwischen deren System und Ihrem übersetzen. Diese Instanz ist fast immer HL7.

HL7 steht für Health Level Seven, eine Familie von Standards, die von Health Level Seven International, einer gemeinnützigen Organisation zur Entwicklung von Standards, herausgegeben wird. Die Standards definieren, wie Patientendaten, Untersuchungsaufträge und Ergebnisse strukturiert sind, damit zwei Systeme verschiedener Anbieter, die in unterschiedlichen Jahrzehnten entwickelt wurden, miteinander kommunizieren können.

Dieser Beitrag erläutert, was HL7-Standards sind, welchen Sie in Ihrem Labor wahrscheinlich begegnen werden, was sich in den letzten drei Jahren geändert hat und was in der Praxis erforderlich ist, um ein Laborsystem mit einem klinischen System zu verbinden.

Was ist HL7?

HL7 legt internationale Standards für den Austausch, die Integration, die gemeinsame Nutzung und den Abruf elektronischer Gesundheitsinformationen fest. 

Denken Sie daran: HL7 ist keine einzelne Spezifikation. Es handelt sich um eine Reihe von Spezifikationen, die über drei Jahrzehnte hinweg entwickelt wurden und von denen mehrere gleichzeitig aktiv genutzt werden. Diejenigen, denen ein Labor am ehesten begegnet:

Das Fazit für die Praxis ist, dass v2 und FHIR nicht aufeinanderfolgend sind, sondern nebeneinander existieren. HL7 selbst veröffentlicht einen v2-zu-FHIR-Implementierungsleitfaden , der v2-Segmente, Datentypen und Vokabulare auf FHIR R4-Ressourcen abbildet, gerade weil die meisten Organisationen beide gleichzeitig betreiben und einen definierten Pfad zwischen ihnen benötigen.

Beachten Sie einfach, dass R4 die Version ist, auf der die meisten produktiven Systeme basieren.

• R5 wurde 2023 veröffentlicht und fand nur begrenzte Verbreitung.
• R6 wurde 2026 zur Abstimmung vorgelegt und soll als vollständiger normativer Standard veröffentlicht werden, was bedeuten würde, dass sich die Kernressourcen zwischen den Versionen nicht mehr ändern.
• Wenn Sie derzeit eine Integration planen, ist R4 das sichere Ziel und R6 die Richtung, in die es geht.

Bestätigen Sie, welche Version das System auf der Gegenseite unterstützt, bevor Sie mit dem Design beginnen.

Welche Arten von Laboren verwenden HL7-Nachrichten?

Der Einsatz von HL7 im Gesundheitswesen ist weit verbreitet, und jedes Labor, das Patienteninformationen austauscht, muss HL7-Nachrichten über digitale Plattformen senden und empfangen können.

Hier sind verschiedene Arten von Laboren, die HL7-Nachrichten verwenden:

• Klinische Testlabore.
  ‍Klinische Labore untersuchen Bioproben, die von Patienten entnommen wurden, um medizinische Zustände oder die Wirksamkeit von Behandlungen zu diagnostizieren oder zu überwachen. In diesem Zusammenhang übermittelt HL7 Testergebnisse und Patienteninformationen zwischen einem klinischen Labor und anderen Gesundheitssystemen.
• Pathologische Labore.
  ‍Ähnlich wie klinische Testlabore führen pathologische Labore Untersuchungen an Gewebe oder anderen Bioproben durch, um Krankheiten zu diagnostizieren. HL7 unterstützt den Austausch von Testergebnissen mit anderen Gesundheitssystemen.
• Blutbanken.
  ‍Informationen über Blutspender, Blutentnahmen und Blutuntersuchungen werden mittels HL7 ausgetauscht, um die Ergebnisse von Bluttests oder andere Patienteninformationen an die anfordernden Systeme zu übermitteln.
• Forschungslabore, die mit patientenbezogenem Material arbeiten.
  Translationale Forschungsgruppen, Biobanken und akademische Kerneinrichtungen, die eingewilligte Patientenproben erhalten, benötigen häufig Identifikatoren und Metadaten aus einem klinischen System, ohne dabei die volle Verpflichtung zur klinischen Ergebnisberichterstattung zu übernehmen. Diese Labore benötigen in der Regel eine schmalere HL7-Schnittstelle als ein klinisches Labor, meist nur für eingehende Daten.

HL7 kann auch für den Datenaustausch mit Forschungslaboren (und vielen anderen Labortypen) verwendet werden, die Studien an Patienten durchführen.  

Wie wird HL7 im Gesundheitswesen eingesetzt?

HL7 bietet Laboren eine standardisierte und interoperable Möglichkeit, Informationen mit anderen Gesundheitssystemen auszutauschen, wodurch die Genauigkeit, Effizienz und Qualität der Patientenversorgung verbessert wird.

Hier sind einige Einsatzmöglichkeiten von HL7 im Gesundheitswesen:

• Interoperabilität.
  ‍HL7 ermöglicht Interoperabilität, indem es eine gemeinsame Sprache und ein Rahmenwerk bereitstellt, damit verschiedene Gesundheitssysteme miteinander kommunizieren können. Es stellt sicher, dass Daten präzise und konsistent zwischen unterschiedlichen Systemen ausgetauscht werden können, darunter elektronische Patientenakten (EHR), Laborinformationssysteme, Radiologiesysteme, Apothekensysteme und mehr.
• Austausch von Patientendaten.
  ‍HL7 ermöglicht den Austausch von Patientendaten zwischen Gesundheitsdienstleistern, Krankenhäusern, Kliniken und anderen an der Patientenversorgung beteiligten Einrichtungen. Dies umfasst wichtige Informationen wie demografische Patientendaten (Name, Alter, Geschlecht, Adresse), Krankengeschichte, Allergien, Medikamente und klinische Beobachtungen.
• Klinische Nachrichtenübermittlung.
  ‍HL7 definiert einen Nachrichtenstandard, der die Übermittlung klinischer Informationen wie Laborergebnisse, Radiologieberichte und andere diagnostische Befunde ermöglicht. Dies hilft Gesundheitsdienstleistern, effizient auf Patienteninformationen zuzugreifen und diese zu prüfen, was eine zeitnahe Entscheidungsfindung unterstützt und eine bessere Versorgungsqualität gewährleistet.
• Integration mit elektronischen Patientenakten (EHRs).
  ‍HL7 spielt eine entscheidende Rolle bei der Integration verschiedener Gesundheitsanwendungen in EHR-Systeme. Es ermöglicht den nahtlosen Datenfluss zwischen verschiedenen Systemen und stellt sicher, dass Informationen aus Labortests, Verfahren und anderen Quellen präzise erfasst und in der elektronischen Patientenakte gespeichert werden.

Was sich seit 2023 geändert hat

Die Standards selbst entwickeln sich langsam. Deutlich verändert hat sich, wie konkret Regulierungsbehörden sie inzwischen vorschreiben.

Deutschland: ISiK

Nach § 373 SGB V entwickelt die gematik verbindliche Standards für den Austausch von Gesundheitsdaten mit informationstechnischen Systemen in Krankenhäusern. Das Ergebnis ist ISiK: ein auf FHIR basierendes Profil-Set plus REST-API, das Primärsysteme im Krankenhaus umsetzen müssen. Das Bestätigungsverfahren der gematik ist verpflichtend für Softwareprodukte, die von der Deutschen Krankenhausgesellschaft als bestätigungsrelevant definiert wurden. Stufe 1 war ab 2023 verpflichtend; spätere Stufen haben weitere Module ergänzt, darunter eines für Labordaten.

Für ein Labor, das an ein deutsches Krankenhaus angebunden ist, heißt das: die Gegenstelle spricht zunehmend ISiK-konformes FHIR, nicht generisches HL7 v2.

Europäische Union: EHDS

Die Verordnung (EU) 2025/327 über den europäischen Gesundheitsdatenraum ist am 26. März 2025 in Kraft getreten. Der allgemeine Geltungsbeginn ist der 26. März 2027. Für Labore ist der 26. März 2031 das relevante Datum: ab dann müssen medizinische Testergebnisse aus Labor- und anderer Diagnostik grenzüberschreitend über MyHealth@EU austauschbar sein.

Frankreich und weitere Mitgliedstaaten

Frankreich verfolgt über das Programm Ségur du numérique en santé einen vergleichbaren Weg, mit einem eigenen Sektor für die medizinische Labordiagnostik und einem Interoperabilitätsrahmen (CI-SIS), der schrittweise von HL7 CDA auf FHIR umgestellt wird. Wer international liefert, sollte davon ausgehen, dass die nationalen Profile voneinander abweichen, auch wenn die Grundlage überall FHIR ist.

Vereinigte Staaten

Die Anforderungen in den USA waren weniger stabil. USCDI v3 bleibt die durch die HTI-1 Final Rule festgelegte Zertifizierungsgrundlage; spätere USCDI-Versionen wurden veröffentlicht, ohne jedoch zu Zertifizierungsanforderungen zu werden. Die HTI-2 Final Rule, die im Januar 2025 in Kraft trat, finalisierte lediglich die TEFCA-bezogenen Bestimmungen aus einem weitaus umfassenderen Vorschlag, und im Dezember 2025 schlug die ASTP/ONC vor, den Großteil des Rests zurückzuziehen. Wenn Ihr Labor unter US-Zertifizierungsanforderungen arbeitet, überprüfen Sie den aktuellen Stand, anstatt sich auf eine veröffentlichte Zusammenfassung zu verlassen – auch auf diese hier.

Anbindung eines Laborsystems an klinische Systeme

Unabhängig vom verwendeten Standard muss die Integration vier Aufgaben zuverlässig erfüllen.

• ‍Auftragseingang.
  Eine eingehende Nachricht enthält Patientenidentifikatoren, den anfordernden Arzt und die angeforderten Tests. Ihr System muss dies in einen Proben-Datensatz umwandeln, mit dem es tatsächlich arbeiten kann – das bedeutet, die Nachrichtenfelder auf Ihre eigenen Probenfelder abzubilden.‍
• Der Probe eine dauerhafte Identität geben.
  Ein Barcode oder eine eindeutige Kennung, die das physische Röhrchen mit dem Datensatz verknüpft und verhindert, dass dieselbe Kennung doppelt registriert wird.‍
• Verarbeitung nachverfolgen.
  Wer hat die Probe wann bearbeitet, was wurde durchgeführt, wie lautete das Ergebnis – mit einer Historie, die einer Überprüfung standhält.‍
• Ergebnis zurücksenden.
  Eine ausgehende Nachricht, die an das Bestellsystem zurückgesendet wird und direkt mit dem ursprünglichen Auftrag verknüpft ist, anstatt frei im System zu stehen.

So unterstützt SciSure dies

SciSure-Forschung bietet Dokumentation für Experimente, Probenregistrierung, Barcode-Workflows, Lagerverwaltung sowie Audit-Trails, die lückenlos erfassen, wer wann welche Änderungen vorgenommen hat. Verbindungen zu externen Systemen werden über die offene API und das SDKvon SciSure hergestellt, wobei Marketplace-Add-ons gängige Instrumenten- und Workflow-Integrationen abdecken.

Für die spezifische Handhabung klinischer Nachrichten ist eine zugeordnete Integration das bewährte Muster: Eine eingehende Nachricht wird analysiert, ihre Felder werden einem definierten Probentyp zugeordnet und der resultierende Probendatensatz trägt einen eindeutigen Barcode in die Verarbeitung. Da die Zuordnung pro Implementierung definiert wird, kann sie genau an die Art und Weise angepasst werden, wie ein bestimmtes Bestellsystem seine Nachrichten befüllt – was in der Praxis selten exakt dem entspricht, was der Standard vorgibt.

Klären Sie den Umfang realistisch mit Ihrem IT-Team ab, bevor Sie sich festlegen: Die eigentliche Arbeit liegt in der Nachrichten-Zuordnung, der Angleichung der Terminologie und der Fehlerbehandlung – und diese sind spezifisch für das jeweilige Systempaar, das verbunden werden soll.

Wie die Boston University ein Testlabor mit zwei EMR-Systemen vernetzte

Die Boston University richtete im Herbst 2020 ein internes klinisches Testlabor ein, um COVID-19-Proben für Studierende, Dozenten und Mitarbeiter zu verarbeiten. Das Labor musste in zwei separate elektronische Patientenakten-Systeme der Universität integriert werden – eines für Studierende und eines für Mitarbeiter –, um Aufträge zu empfangen und Ergebnisse zurückzusenden. Gleichzeitig war eine Anbindung an die Testroboter erforderlich.

Die APIs von SciSure waren ein entscheidender Faktor bei der Auswahl der Plattform, insbesondere weil sie die von den Robotern erzeugten Dateien verarbeiten konnten. Das Labor nahm zwei Monate nach der Implementierung den Betrieb auf. Es war darauf ausgelegt, über 5.000 Proben pro Tag mit Ergebnissen am nächsten Tag zu bewältigen; in Spitzenzeiten wurden sogar über 9.000 Proben verarbeitet. Zudem verhinderte das System, dass doppelte Barcodes in die Anwendung gelangten – bei diesem Volumen kein unerhebliches Detail.

‍

„Die Benutzeroberfläche von SciSure ELN war für uns leicht verständlich, die Hilfedokumentation klar und umfassend und der Kundensupport effektiv. Die Zusammenarbeit mit dem SciSure-Team war produktiv und partnerschaftlich.“

- Shari Huval, Director of Health, Faculty and Student Ancillary, Boston University Information Services & Technology

‍

‍

Technische Details für IT-Experten…

Wir nutzen eine REST-API-POST-Nachricht, um Verbindungen zwischen Plattformen zu ermöglichen. Der Nachrichten-Header enthält die Mapping-Anweisungen für die Übersetzung der HL7-Felder in eine Probe. Dies erlaubt eine sehr differenzierte Einrichtung, die präzise auf jedes Labor zugeschnitten ist. Das Mapping wird zudem pro Implementierung definiert, wodurch sich das System flexibel an die Art und Weise anpassen lässt, wie ein spezifisches Auftragssystem seine Nachrichten tatsächlich befüllt.

So sieht ein Beispiel-Header aus:

{

   "sampleTypeID": 12485,

   "storageLayerID": 0, /* Optional */

   "position": 0, /* Optional */

   "name": {

       "segment": "MSH",

       "field": 10

   },

   "description": { /* Optional */

       "segment": "MSH",

       "field": 9,

       "component": 3

   },

   "altBarcode": { /* Optional: Alternative Barcode-Informationen. */

       "segment": "OBR",

       "field": 31

   },

   "sampleTypeMetaIDMapping": [ /* Optional: Array von Mappings für die sampleTypeMetaID zum jeweiligen Segment in der HL7-Nachricht */

       {

           "sampleTypeMetaID": 85318,

           "segment": "OBX",

           "field": 5

       },

       {

           "sampleTypeMetaID": 85317,

           "segment": "ORC",

           "field": 2

       }

   ]

}

Und falls Sie technisch nicht so versiert sind: Kein Problem

Das oben gezeigte JSON-Konfigurationsobjekt ordnet HL7-Nachrichtenfelder einem Probentyp zu. Wenn Sie jedoch kein IT-Experte sind, müssen Sie nur Folgendes wissen:

• HL7 ist der Standard, mit dem Laborsysteme und klinische Systeme Testaufträge und Ergebnisse austauschen, ohne dass diese manuell neu eingegeben werden müssen.
• HL7 v2 bildet die Grundlage der meisten bestehenden Schnittstellen. FHIR ist der Standard, auf dem neue Entwicklungen basieren und der zunehmend von EU-weiten und nationalen Vorschriften gefordert wird.
• Jede echte Integration läuft auf ein Mapping hinaus: Welches Feld in deren Nachricht entspricht welchem Feld in Ihrem Probendatensatz und was passiert, wenn die Daten nicht übereinstimmen?
• SciSure Research bietet Probendatensätze, Barcode-Workflows und Audit-Trails sowie eine offene API und ein SDK für die Anbindung an externe Systeme.

Insgesamt ist HL7 für digitale Laborumgebungen unverzichtbar.

Wenn Sie mehr über die Plattform von eLabNext und HL7-Messaging erfahren möchten, vereinbaren Sie eine persönliche Demo, um zu sehen, wie es funktioniert.

Häufig gestellte Fragen

Was ist HL7 einfach erklärt?

‍HL7 ist eine Reihe internationaler Standards für den Austausch von Gesundheitsinformationen zwischen Softwaresystemen. Er legt fest, wie eine Nachricht mit Patientendaten, einem Testauftrag oder einem Testergebnis strukturiert sein muss, damit ein System, das das sendende System noch nie zuvor kontaktiert hat, diese korrekt lesen kann.

Was ist der Unterschied zwischen HL7 v2 und FHIR?

‍HL7 v2 ist ein Nachrichtenformat, das auf durch Pipes getrennte Segmente setzt. Es wurde in den späten 1980er Jahren entwickelt und wickelt noch immer den Großteil des Datenverkehrs für Aufträge und Ergebnisse ab. FHIR ist ein REST-API-Ansatz, der JSON oder XML verwendet, wobei Daten als diskrete Ressourcen modelliert werden. Während v2 Nachrichten zwischen Systemen überträgt, ermöglicht FHIR einem System, genau die benötigten Daten abzurufen. Die meisten Organisationen nutzen beides, weshalb HL7 einen Leitfaden für die Zuordnung zwischen den Standards veröffentlicht hat.

Benötigt ein Forschungslabor HL7?

‍Nur, wenn es Daten mit klinischen Systemen austauscht. Ein Forschungslabor, das mit Proben von Patienten arbeitet, muss möglicherweise Identifikatoren und Metadaten von einem Krankenhaussystem empfangen, was in der Regel eine eingeschränkte, rein eingehende Schnittstelle erfordert. Ein Labor ohne klinischen Datenfluss benötigt HL7 überhaupt nicht.

Ist HL7 dasselbe wie ein LIMS?

‍Nein. HL7 ist ein Kommunikationsstandard. Ein LIMS (Labor-Informations-Management-System) ist eine Software zur Verwaltung von Proben, Arbeitsabläufen und Ergebnissen. HL7 ist eine der Möglichkeiten, wie ein LIMS mit anderen Systemen kommunizieren kann.

Gilt HL7 auch außerhalb der Vereinigten Staaten?

‍Ja. HL7 International verfügt über Partnerorganisationen in ganz Europa und darüber hinaus, und nationale Programme bauen direkt auf diesen Standards auf. Die deutsche ISiK-Spezifikation ist ein eingeschränktes FHIR-Profilset, der französische CI-SIS-Rahmen stellt seine Module von HL7 CDA auf FHIR um, und die Verordnung zum europäischen Gesundheitsdatenraum (EHDS) der EU legt Zeitpläne für den grenzüberschreitenden Austausch von Laborergebnissen fest.

Unterstützt SciSure HL7?

SciSure Research lässt sich über eine offene API, ein SDK und Marketplace-Add-ons mit externen Systemen verbinden. Die Handhabung klinischer Nachrichten wird individuell konfiguriert; besprechen Sie den Umfang daher bitte direkt mit Ihrem IT-Team und SciSure.

Wenn Sie eine Verbindung zwischen Ihrem Labor und einem klinischen System planen, sprechen Sie mit einem SciSure-Experten. Nennen Sie uns die Systeme, die Sie anbinden möchten, und wir gehen gemeinsam durch, was dafür erforderlich ist.