Schneller Service
Kostenlose Rückmeldung innerhalb von 24 Stunden
Erfolg durch Erfahrung
Aus über 15.000 Projekten im Jahr wissen wir, worauf es ankommt
Der digitale Marktführer
Unsere Kunden sprechen für uns:
4,9 von 5 Sternen auf Google
Inhaltsverzeichnis
Was ist die HL7-Schnittstelle?
Die HL7-Schnittstelle definiert ein Regelwerk für den elektronischen Austausch klinischer und administrativer Daten zwischen Praxissoftware und Krankenhaussoftware. Sie legt fest, wie Systeme wie Praxisverwaltung, Labor- und Krankenhausinformationssystem strukturierte Nachrichten senden, empfangen und quittieren. Ohne dieses Regelwerk müsste jede Anwendung individuell mit jeder anderen kommunizieren — ein Aufwand, der bei mehreren angebundenen Systemen exponentiell steigt.
Herkunft des Namens: Health Level Seven und Bezug zum OSI-Schichtenmodell
Der Name Health Level Seven verweist auf die siebte und oberste Schicht des OSI-Referenzmodells, die Anwendungsschicht. HL7 International entwickelte den Standard ab 1987 in den USA, um Nachrichten zwischen Krankenhausinformationssystemen zu vereinheitlichen. HL7 v2, seit den späten 1980er-Jahren kontinuierlich weiterentwickelt, dominiert bis heute die Kommunikation zwischen Klinik- und Laborsystemen.
HL7 International, HL7 Deutschland e.V. und weitere nationale Ableger
HL7 International koordiniert die globale Standardentwicklung und veröffentlicht neue Versionen sowie Implementierungsleitfäden. HL7 Deutschland e.V. ist der 1993 gegründete erste nationale HL7-Landesverband weltweit. Der Verein vertritt die Interessen des deutschen Gesundheitswesens innerhalb der internationalen Organisation und passt Standards an nationale Anforderungen an — etwa an Vorgaben der gematik. Vergleichbare Landesverbände bestehen unter anderem in Österreich und der Schweiz.
Wofür die Schnittstelle in der Praxis konkret eingesetzt wird
Die HL7-Schnittstelle überträgt in der Praxis vor allem Laborbefunde, Überweisungsdaten, Abrechnungsinformationen und Patientenstammdaten zwischen dem Praxisverwaltungssystem und externen Laboren, Krankenhäusern oder Facharztpraxen. Ein Laborinstitut sendet beispielsweise das Befundergebnis einer Blutuntersuchung automatisiert an das PVS, ohne dass Praxispersonal die Werte manuell erfasst.
Tipp: Prüfen Sie vor der Anbindung, welche HL7-Version Ihr PVS-Hersteller unterstützt — ältere Systeme arbeiten oft ausschließlich mit HL7 v2.
Wie ist eine HL7-Nachricht aufgebaut?
Eine HL7-v2-Nachricht besteht aus mehreren Segmenten, die jeweils in einer eigenen Zeile stehen. Innerhalb eines Segments trennt ein Pipe-Zeichen (|) die einzelnen Felder voneinander. Caret-Zeichen (^) untergliedern Felder weiter in Komponenten. Diese Struktur ermöglicht eine kompakte, aber für Menschen schwer lesbare Darstellung.
Segmente, Felder und Komponenten (MSH, PID, PV1, OBR, OBX, NK1)
Jedes Segment kodiert einen fest definierten Datenblock. Das MSH-Segment (Message Header) steht immer an erster Stelle und definiert Nachrichtentyp, Absender und Empfänger. Das PID-Segment enthält die Patientenstammdaten, PV1 die Aufenthaltsinformationen, OBR die Untersuchungsanforderung und OBX das eigentliche Befundergebnis.
| Segment | Bedeutung | Praxisrelevanz |
|---|---|---|
| MSH | Message Header — Nachrichtenkopf | Identifiziert Nachrichtentyp und Systeme |
| PID | Patient Identification | Stammdatenabgleich mit dem PVS |
| PV1 | Patient Visit | Aufnahme-, Verlegungs- und Fachrichtungsdaten |
| OBR | Observation Request | Anforderung einer Untersuchung |
| OBX | Observation Result | Konkretes Befundergebnis |
| NK1 | Next of Kin | Angehörigen- und Kontaktdaten |
Beispiel einer HL7-Nachricht in der Praxis
Eine ADT^A04-Nachricht zur ambulanten Patientenregistrierung beginnt typischerweise mit folgendem MSH-Segment:
MSH|^~\&|LABOR|KLINIK|PVS|PRAXIS|<Zeitstempel>||ADT^A04|MSG00123|P|2.5.1
Die Pipe-getrennten Felder benennen der Reihe nach Absender- und Empfängersystem, Zeitstempel, Nachrichtentyp und die verwendete HL7-Version — hier 2.5.1, eine der in der Praxis gängigen v2-Versionen.
Trennzeichen, Escape-Zeichen und Zeichensatz (UTF-8)
HL7 v2 reserviert das Pipe-Zeichen, Caret, Tilde und Backslash als Steuerzeichen. Enthält ein Patientenname ausgerechnet eines dieser Zeichen, muss die sendende Anwendung es maskieren — etwa \F\ für ein Pipe-Zeichen. Fehlt diese Maskierung, bricht der Parser die Nachricht an unerwarteter Stelle auf. Der Zeichensatz UTF-8 verhindert zusätzlich, dass Umlaute oder Sonderzeichen in Patientendaten fehlerhaft übertragen werden.
Welche HL7-Nachrichtentypen kommen in der Arztpraxis vor?
Ein sogenanntes Trigger Event — ein reales Ereignis wie eine Patientenaufnahme oder ein fertiger Laborbefund — löst den Versand der passenden HL7-Nachricht aus. Der Nachrichtentyp im MSH-Segment bestimmt, welches Ereignis eine HL7-Nachricht transportiert. Praxisrelevante Systeme nutzen dabei nur eine begrenzte Auswahl der insgesamt sehr umfangreichen HL7-Nachrichtentypologie.
ADT – Patientenaufnahme, -verlegung und -entlassung (A01, A04, A08)
ADT-Nachrichten (Admission, Discharge, Transfer) melden Statusänderungen eines Patienten. Der Ereignistyp A01 kennzeichnet eine stationäre Aufnahme, A04 eine ambulante Registrierung und A08 eine Aktualisierung bestehender Patientendaten. Praxisverwaltungssysteme verarbeiten ADT-Nachrichten vor allem, um Patientenstammdaten mit angebundenen Kliniken synchron zu halten.
ORU und ORM – Laborbefunde und Anforderungen
ORU-Nachrichten (Observation Result – Unsolicited) übermitteln Laborbefunde vom Labor an die anfordernde Praxis. ORM-Nachrichten (Order Message) transportieren umgekehrt die Anforderung einer Untersuchung von der Praxis an das Labor. Beide Typen bilden gemeinsam den vollständigen Anforderungs-Befund-Kreislauf ab, der in nahezu jeder Praxis mit Laboranbindung eingesetzt wird.
Weitere praxisrelevante Nachrichtentypen
| Nachrichtentyp | Kürzel | Einsatzzweck |
|---|---|---|
| Scheduling Information | SIU | Terminvereinbarung und -änderung |
| Medical Document Management | MDM | Übermittlung von Arztbriefen/Dokumenten |
| Detail Financial Transaction | DFT | Abrechnungsrelevante Leistungsdaten |
| Bar Code / Billing | BAR | Rechnungs- und Kontenabgleich |
Wie erfolgt die technische Übertragung der Daten?
Die HL7-Schnittstelle definiert die Nachrichteninhalte, nicht aber zwangsläufig den Transportweg. Dafür hat sich ein eigenes, schlankes Protokoll etabliert.
MLLP-Protokoll und Portkonfiguration
Das Minimal Lower Layer Protocol (MLLP) kapselt HL7-v2-Nachrichten für die Übertragung per TCP/IP. Es rahmt jede Nachricht mit einem Start- und einem Endezeichen ein, damit der Empfänger erkennt, wo eine Nachricht endet und die nächste beginnt. In der Praxis läuft MLLP häufig über den inoffiziellen, aber branchenweit etablierten Port 2575 — eine feste IANA-Zuweisung existiert dafür nicht. Da MLLP selbst keine Verschlüsselung vorsieht, überträgt eine ungesicherte Verbindung Patientendaten im Klartext. Produktive Anbindungen setzen deshalb zunehmend auf MLLP über TLS.
Bestätigung des Empfangs: ACK- und NACK-Nachrichten
Jedes empfangende System quittiert eine HL7-Nachricht mit einer Antwortnachricht. Bei erfolgreicher Verarbeitung sendet es ein ACK (Acknowledgement), bei einem Fehler ein NACK (Negative Acknowledgement). Ohne diese Quittierung bleibt für das sendende System unklar, ob ein Laborbefund tatsächlich im PVS angekommen ist. Ausbleibende ACK-Nachrichten gelten in der Praxis als erstes Anzeichen für eine gestörte Schnittstelle.
HL7-Kommunikationsserver bzw. -Broker als Schnittstellenlösung
Ein Kommunikationsserver übernimmt die Verteilung und Umwandlung von HL7-Nachrichten zwischen mehreren angebundenen Systemen. Er entkoppelt die Praxissoftware von der direkten Punkt-zu-Punkt-Verbindung zu jedem einzelnen externen System und reduziert dadurch den Pflegeaufwand bei Systemwechseln.
Tipp: Fragen Sie Ihren PVS-Anbieter gezielt, ob ein Kommunikationsserver bereits im Lieferumfang enthalten ist oder separat lizenziert werden muss.
Unterschied zu direkter Systemintegration ohne Middleware
Eine direkte Integration ohne Kommunikationsserver verbindet zwei Systeme unmittelbar über eine feste Punkt-zu-Punkt-Schnittstelle. Das reduziert die Komplexität bei genau einer Verbindung, skaliert aber schlecht: Jedes zusätzliche angebundene System erfordert eine eigene, individuell konfigurierte Verbindung.
HL7 v2, HL7 v3 oder HL7 FHIR – welcher Standard gilt aktuell?
HL7 v2 bleibt trotz seines Alters der in Kliniken und Laboren am weitesten verbreitete Standard. Parallel etabliert sich FHIR (Fast Healthcare Interoperability Resources) zunehmend als moderne Alternative, insbesondere für neue Integrationsprojekte. Der Standard erhielt mit Release 4 im Jahr 2019 erstmals einen normativen Kern.
Vergleich HL7 v2, HL7 v3/CDA und HL7 FHIR
| Standard | Architektur | Typischer Einsatz |
|---|---|---|
| HL7 v2 | Pipe-getrennte Nachrichten, ereignisbasiert | Labor- und ADT-Kommunikation in Kliniken |
| HL7 v3 / CDA | XML-basiert, Referenzinformationsmodell (RIM) | Strukturierte Dokumente, z. B. Arztbriefe |
| HL7 FHIR | REST-API, JSON/XML, ressourcenbasiert | Neue Integrationen, Patienten-Apps, Schnittstellen zu Drittsystemen |
Warum FHIR als Nachfolgestandard an Bedeutung gewinnt
FHIR bildet Patienten, Befunde und Termine als einzeln adressierbare Ressourcen ab und tauscht diese über standardisierte HTTP-Methoden aus. Diese Architektur senkt den Implementierungsaufwand gegenüber HL7 v2 spürbar. Entwickler greifen auf verbreitete Web-Technologien wie JSON und REST zurück, statt proprietäre Parser für pipe-getrennte Nachrichten zu schreiben. HL7 v2 und FHIR schließen sich dabei nicht aus. Viele Praxen und Kliniken betreiben beide Standards parallel — etwa HL7 v2 für Echtzeit-Laborbefunde und FHIR für die Anbindung an Patientenportale.
Abgrenzung zu DICOM als Standard für Bildgebungsdaten
DICOM regelt speziell den Austausch und die Speicherung medizinischer Bilddaten, etwa aus Röntgen, CT oder MRT. Der Standard ergänzt HL7 damit fachlich, statt es zu ersetzen. In der Praxis überträgt HL7 die Auftrags- und Befunddaten, während DICOM die eigentlichen Bilddateien zwischen Modalität und Befundungsstation transportiert.
Wie wird die HL7-Schnittstelle in der Praxis-IT eingebunden?
Die HL7-Schnittstelle wird in der Praxis primär genutzt, um externe Partner an das bestehende Praxisverwaltungssystem anzubinden.
Anbindung von Praxisverwaltungssystem, Labor- und Krankenhausinformationssystem
Das PVS fungiert dabei meist als Empfänger von Laborbefunden und als Sender von Überweisungs- oder Anforderungsdaten. Die konkrete Konfiguration übernimmt in der Regel der PVS-Hersteller oder ein spezialisierter IT-Dienstleister, da er Zugriffsdaten, Portfreigaben und Nachrichtenprofile auf beiden Seiten abstimmen muss.
Tools zur Fehlerdiagnose: Viewer, Parser, Validator
HL7-Viewer stellen empfangene Nachrichten segmentweise lesbar dar und erleichtern die Fehlersuche bei Übertragungsproblemen. Validator-Tools prüfen zusätzlich, ob eine Nachricht dem vereinbarten Nachrichtenprofil entspricht, bevor sie produktiv verarbeitet wird.
Tipp: Bestehen Sie bei der Erstinbetriebnahme auf eine gemeinsame Testphase mit dem Labor oder der Klinik, in der Testnachrichten über einen separaten Port ausgetauscht werden.
Anforderungen an den IT-Dienstleister vor der Anbindung
- [ ] Unterstützte HL7-Version (v2, CDA, FHIR) klären
- [ ] Vorhandenen Kommunikationsserver bzw. dessen Lizenzierung prüfen
- [ ] Portfreigaben und TLS-Verschlüsselung vertraglich festlegen
- [ ] Verantwortlichkeit für Nachrichtenprofile und Mapping definieren
- [ ] Testphase mit Beispielnachrichten vor Produktivbetrieb vereinbaren
Was sind typische Fallstricke und Kosten bei der HL7-Anbindung?
Die HL7-Schnittstelle gilt technisch als robust, verzeiht Konfigurationsfehler aber wenig — viele Probleme entstehen erst im laufenden Betrieb.
Häufige Fehlerquellen: Kodierung, fehlende Zertifizierung, Segmentabweichungen
Unterschiedliche Zeichenkodierungen zwischen Sender und Empfänger führen zu fehlerhaft dargestellten Umlauten in Patientennamen. Abweichende Segmentstrukturen zwischen Systemversionen — etwa ein zusätzliches Pflichtfeld im PID-Segment — lassen den Parser einer Gegenstelle die Nachricht ablehnen. Fehlt zudem eine Zertifizierung der beteiligten Systeme nach dem vereinbarten Nachrichtenprofil, bleibt unklar, wer bei Übertragungsfehlern haftet.
Haftungsrisiko: Bei fehlerhaft übertragenen Laborwerten ohne klare Verantwortungsabgrenzung zwischen PVS-Hersteller und Labor drohen Verzögerungen in der Diagnostik. Vereinbaren Sie vertraglich, wer für die Nachrichtenintegrität haftet.
Kostenfaktoren einer HL7-Schnittstellenanbindung
| Kostenfaktor | Einflussgröße |
|---|---|
| Lizenzierung Kommunikationsserver | Anzahl angebundener Systeme |
| Einrichtung durch IT-Dienstleister | Komplexität der Nachrichtenprofile |
| Laufende Wartung | Update-Zyklen von PVS und Gegenstellen |
| Zertifizierungsaufwand | Anzahl geprüfter Schnittstellenprofile |
FAQ: Häufige Fragen zur HL7-Schnittstelle
Ist die HL7-Schnittstelle für Arztpraxen gesetzlich vorgeschrieben?
Eine generelle gesetzliche Pflicht zur Nutzung von HL7 besteht für Arztpraxen nicht. Faktisch setzen jedoch die meisten Labore, Kliniken und Praxisverwaltungssysteme HL7 als De-facto-Standard voraus. Eine Anbindung ohne HL7-Schnittstelle schränkt den elektronischen Datenaustausch in der Praxis daher erheblich ein.
Was kostet die Einrichtung einer HL7-Schnittstelle in der Praxis?
Die Kosten hängen stark von der Anzahl angebundener Systeme, der genutzten HL7-Version und dem gewählten IT-Dienstleister ab. Einen verlässlichen Richtwert liefert nur ein individuelles Angebot, da Lizenzkosten für Kommunikationsserver und Einrichtungsaufwand je nach Praxissoftware stark variieren.
Wie unterscheidet sich HL7 von DICOM und wann braucht meine Praxis beides?
HL7 überträgt strukturierte Text- und Auftragsdaten wie Befunde und Patientenstammdaten. DICOM überträgt dagegen medizinische Bilddaten aus bildgebender Diagnostik. Praxen mit eigener Bildgebung, etwa Radiologie oder Kardiologie mit Ultraschall, benötigen in der Regel beide Standards parallel. HL7 übernimmt dabei die Auftrags- und Befundkommunikation, DICOM den Bildtransfer.
Was ist der Unterschied zwischen HL7 und der GDT-Schnittstelle?
Die GDT-Schnittstelle verbindet Praxisverwaltungssysteme mit Medizingeräten wie EKG- oder Ultraschallgeräten und ist ein vom Qualitätsring Medizinische Software e. V. (QMS) definierter Standard für den ambulanten Sektor in Deutschland. HL7 stammt dagegen historisch aus dem stationären Bereich und regelt primär die Kommunikation zwischen Praxis-, Labor- und Krankenhausinformationssystemen. Für die Anbindung von Diagnosegeräten direkt an das PVS ist GDT in deutschen Praxen nach wie vor der gebräuchlichere Standard. Eine HL7-GDT-Bridge kann beide Welten verbinden, wenn ein über GDT angeschlossenes Gerät auch Daten an ein HL7-basiertes Krankenhausinformationssystem liefern soll.