Häufige Fehler in HL7-v2-Nachrichten

Segmente nicht getrennt oder alles in einer Zeile

Symptom

Die Nachricht erscheint als eine lange Zeile, oder Zeilenenden sehen anders aus als erwartet.

Ursache

Der Standard trennt Segmente mit einem Wagenrücklauf (CR). Mails, Logs und Editoren machen daraus Zeilenvorschub (LF) oder CRLF, ersetzen den Umbruch durch Leerzeichen oder zeigen ihn als Text \r.

Lösung

Der Viewer liest CR, LF und CRLF, erkennt wörtliches \r/\n und Leerzeichen vor einer Segmentkennung und sagt, was er angenommen hat. „Zeilenumbrüche reparieren“ liefert die Fassung mit CR. Prüfen Sie bei Leerzeichen-Trennung das Ergebnis: Es ist eine Vermutung.

Meldung des Viewers:

Die Segmente waren mit Zeilenvorschub (\n) statt mit Wagenrücklauf (\r) getrennt, wie es beim Kopieren aus Mails und Logs üblich ist. Der Viewer liest beides; für Systeme, die \r erwarten, bietet die reparierte Fassung den korrekten Umbruch.

Die Nachricht stand in einer Zeile; 2 Segmente wurden an Leerzeichen vor einer Segmentkennung getrennt. Das ist eine Vermutung: Steht in einem Textfeld selbst „ABC|“, wäre die Trennung falsch.

Zwischen Segmenten standen 1 wörtliche Zeichenfolgen „\r“ oder „\n“ (Text statt Zeilenumbruch). Sie wurden in echte Segmenttrennungen umgewandelt.

Zeitstempel oder Text vor MSH

Symptom

Die Nachricht stammt aus einem Log und beginnt mit Datum, Uhrzeit oder Stufe („INFO“).

Ursache

Das ist Teil der Logzeile, nicht der Nachricht. Eine Nachricht muss mit MSH beginnen.

Lösung

Der Viewer ignoriert Text vor „MSH“ und meldet es. Sauberer ist es, die Nachricht ohne Präfix aus dem Log zu kopieren.

Meldung des Viewers:

Zeile 1: Text vor „MSH“ ("2026-10-27 08:00:01 INFO Received: ") wurde ignoriert, vermutlich ein Log-Präfix.

Steuerzeichen am Anfang und Ende (MLLP)

Symptom

Vor „MSH“ und am Ende stehen unsichtbare Zeichen, oder eine Datei beginnt mit einem seltsamen Zeichen.

Ursache

Beim Versand über TCP wird die Nachricht mit den Zeichen Hex 0B (Start) und Hex 1C 0D (Ende) eingerahmt (MLLP). Mitgeschnittene Daten enthalten sie noch.

Lösung

Der Viewer entfernt den Rahmen und meldet es. Ein Byte-Order-Mark am Dateianfang wird ebenfalls ignoriert.

Meldung des Viewers:

MLLP-Rahmen erkannt und entfernt (1 Startzeichen, 1 Endzeichen). Das sind Übertragungszeichen und gehören nicht zur Nachricht.

Datum im falschen Format

Symptom

Geburtsdatum oder Zeitstempel sehen aus wie im Alltag: 05.03.1971 oder 2026-10-27.

Ursache

HL7 v2 erwartet Ziffern ohne Trennzeichen: JJJJMMTT oder länger bis JJJJMMTThhmmss, optional mit Zeitzone. Exportfunktionen von Fremdsystemen schreiben oft das lokale oder das ISO-Format.

Lösung

Der Viewer prüft die bekannten Datumsfelder und nennt das erkannte Format. Korrigiert werden muss im erzeugenden System.

Meldung des Viewers:

PID-7 (Geburtsdatum) „05.03.1971“ sieht nach deutschem Format (TT.MM.JJJJ) aus. HL7 v2 erwartet JJJJMMTT.

Dezimalkomma statt Punkt

Symptom

Ein Messwert wie 5,9 wird vom Empfänger nicht als Zahl gelesen.

Ursache

Bei Werttyp NM in OBX-2 sind nur Ziffern, Vorzeichen und Dezimalpunkt erlaubt. Deutsche Ausgabeformate setzen oft das Komma.

Lösung

Der Viewer warnt, wenn OBX-5 nicht zu NM passt. Ändern Sie das Format im Absender oder den Werttyp auf ST, falls Text gemeint ist.

Meldung des Viewers:

OBX-5 „5,9“ ist als Zahl (NM) gekennzeichnet, aber keine reine Zahl. Ein Dezimalkomma statt Punkt ist eine mögliche Ursache.

Leere Pflichtfelder und Nullwert

Symptom

Ein Empfänger lehnt die Nachricht ab oder löscht Daten, obwohl nichts gelöscht werden sollte.

Ursache

Leer (||) heißt „keine Angabe“, zwei Anführungszeichen ("") heißen „Wert löschen“. Das wird gern verwechselt. Dazu kommen Felder, die das Profil verlangt, aber leer sind.

Lösung

Der Viewer meldet leere Felder, die üblicherweise gefüllt sind, und kennzeichnet Nullwerte. Ob ein Feld in Ihrem Fall Pflicht ist, entscheidet das Schnittstellenprofil.

Meldung des Viewers:

PID-3 (Patientenkennungen) ist leer. Dieses Feld ist normalerweise ein Pflichtfeld.

PID-29 enthält den Nullwert "" (zwei Anführungszeichen). Das bedeutet „Wert löschen“ und ist etwas anderes als ein leeres Feld.

Kaputte Umlaute

Symptom

Aus „ä“ wird „ä“ oder ein Ersatzzeichen (�).

Ursache

Die Bytes wurden mit einem anderen Zeichensatz gelesen, als sie geschrieben wurden, typischerweise UTF-8 als ISO-8859-1 oder umgekehrt. MSH-18 nennt den Zeichensatz, die tatsächliche Kodierung muss dazu passen.

Lösung

Beim Öffnen einer Datei können Sie im Viewer den Zeichensatz wählen. Er meldet die typischen Muster.

Meldung des Viewers:

Zeichenfolgen wie „ä“ deuten darauf hin, dass UTF-8-Text als ISO-8859-1/Windows-1252 gelesen wurde. Prüfen Sie den Zeichensatz.

Trennzeichen im Freitext

Symptom

Nach einem Textfeld sind Felder verschoben, oder ein Name taucht in Subkomponenten auf.

Ursache

Ein |, ^ oder & im Text wird als Trennzeichen gelesen, wenn es nicht maskiert ist: \F\, \S\, \T\.

Lösung

Maskieren im erzeugenden System. Der Viewer erkennt dieses Problem nicht von selbst, weil unmaskierte Zeichen gültige Syntax sind. Prüfen Sie im Viewer, ob Felder an unerwarteten Stellen enden.

Falsche Zählung bei MSH

Symptom

Der Nachrichtentyp oder die Version „stimmen nicht“, wenn Felder per Skript abgezählt werden.

Ursache

MSH-1 ist das Trennzeichen selbst. Beim Zerlegen an | steht MSH-2 an erster Stelle, alles ist um eins verschoben.

Lösung

Zählen Sie bei MSH anders als bei anderen Segmenten oder verwenden Sie eine Bibliothek, die das kennt. Der Viewer zählt korrekt.

Erwartete Segmente fehlen

Symptom

Eine ORU-Nachricht ohne OBX oder eine ADT ohne EVN.

Ursache

Der Nachrichtentyp in MSH-9 legt fest, welche Segmente üblich oder erforderlich sind. Ein Export kann sie weglassen.

Lösung

Der Viewer weist auf fehlende, üblicherweise erwartete Segmente hin. Er prüft aber nicht die genaue Reihenfolge und nicht die Spezifikation einer Version.

Meldung des Viewers:

Segment EVN fehlt. Bei ADT-Nachrichten wird es üblicherweise erwartet.

Ungewöhnliche Trennzeichen

Symptom

Die Felder werden von einem Semikolon oder Tabulator getrennt.

Ursache

Die Trennzeichen stehen in MSH-1 und MSH-2 und dürfen vom Üblichen abweichen. Ein Empfänger, der | fest voraussetzt, scheitert.

Lösung

Der Viewer liest die Zeichen aus dem MSH und nennt sie.

Meldung des Viewers:

Ungewöhnliche Trennzeichen: Feld „;“, Komponente „^“, Wiederholung „~“, Escape „\“, Subkomponente „&“. Üblich sind | ^ ~ \ &.