Wiki - Chris Seyboth

Framing entscheidet, was eine Nachricht ist

4 Min. Lesezeit

Konzept: Framing entscheidet, was eine Nachricht ist

MLLP (Minimal Lower Layer Protocol) ist die übliche Transportverpackung für HL7 v2 über TCP. Es beantwortet genau eine Frage: wo endet eine Nachricht im Bytestrom.

<SB>  ...HL7-Nachricht...  <EB><CR>
0x0B                       0x1C 0x0D

SB = Vertical Tab 0x0B, EB = File Separator 0x1C, CR = 0x0D. TCP liefert einen Strom ohne Nachrichtengrenzen; eine HL7-v2-Nachricht hat weder Längenfeld noch inhaltliches Endekennzeichen. Erst diese drei Bytes erzeugen die Grenze.

Die Inhaltsregel, die daraus folgt

Der Nutzinhalt darf nur Einzelbyte-Werte oberhalb 0x1F enthalten, zusätzlich CR als Segmenttrenner.

  • Ein rohes 0x1C im Feldinhalt — etwa ein Steuerzeichenrest aus einer Altdatenübernahme — ist deshalb kein kosmetischer Mangel, sondern ein vorzeitiges Nachrichtenende. Alles danach fällt aus der Nachricht heraus.
  • Aus demselben Grund sind UTF-16 und UTF-32 als Zeichenkodierung ausgeschlossen: ihre Bytefolgen kollidieren mit den Rahmenbytes. UTF-8 ist unkritisch, weil Folgebytes stets ≥ 0x80 sind.

Damit ist MSH-18 keine Deklarationskosmetik, sondern eine Aussage über Transportfähigkeit.

Was MLLP nicht leistet

Keine Quittung, keine Wiederholung, keine Reihenfolgesicherung, keine Verschlüsselung — dafür TLS oder IPsec eine Schicht tiefer. Die Spezifikation verweist Fehlererkennung ausdrücklich an die darunterliegenden Netzprotokolle.

Und sie lässt offen, was ein Empfänger mit einem nicht wohlgeformten Block tun soll: Verwerfen bis zum nächsten SB, Weiterpuffern oder den Rest als neue Nachricht deuten sind alle drei anzutreffen. Das ist keine Wissenslücke, sondern eine Lücke im Standard — und gehört als solche benannt, statt ein Verhalten anzunehmen.

Portalbezug

Ein an falscher Stelle beendeter Frame kann einen Patienten anlegen und den Aufenthalt verlieren: PID lag vor dem Steuerzeichen, PV1 dahinter. Im Portal existiert der Patient dann ohne Fall — ein Bild, das in der Fehlersuche regelmäßig der Portalseite zugeschrieben wird, obwohl es zwei Schichten tiefer entsteht.

Der Satz, der die Schichten ordnet

Framing entscheidet vor jeder Validierung, was überhaupt eine Nachricht ist. Ein Parser sieht nur den Ausschnitt, den der Rahmen ihm übergeben hat. Ein ACK bewertet nur diesen Ausschnitt. Beide können nicht wissen, dass es mehr gab.

Diese Fehlerklasse liegt damit unterhalb des Quittungsvertrags: MSH-16 regelt, ob über eine Nachricht gesprochen wird — MLLP regelt, was als Nachricht gilt. Eine an falscher Stelle beendete Nachricht kann wohlgeformt, quittierbar und trotzdem unvollständig sein. Nachweisbar nur im Bytestrom oder im Abgleich Quelle↔Ziel.

Regel fürs Schnittstellenkonzept

Steuerzeichen < 0x20 (außer CR) sind sendeseitig vor dem Framing zu entfernen oder zu escapen. Die Zeichenkodierung ist in MSH-18 zu deklarieren und auf Einzelbyte- oder UTF-8-Kodierungen zu beschränken.

Transfer

In den Kahn-Kategorien ist das Completeness — und zwar der Fall, der ausschließlich im Abgleich Quelle↔Ziel auffällt. Für die Inventur-Checkliste lautet die Frage nicht „welches Transportprotokoll”, sondern: Wer bereinigt Steuerzeichen, und an welcher Stelle im Pfad?

Siehe auch: Der ACK-Vertrag · Trennzeichenhierarchie

Fragen an die Kunden-IT

  • Was macht euer MLLP-Reader mit Bytes, die ohne Start Block ankommen — verwerfen, weiterpuffern, oder als Nachricht deuten? Der Standard schreibt nichts vor; die Antwort muss getestet werden, eine Zusage genügt nicht.
  • Prüft der Sendepfad den Nutzinhalt auf Steuerzeichen unterhalb 0x20, bevor gerahmt wird?
  • Welche Zeichenkodierung läuft über die Strecke? Ist sie einzelbyte- oder UTF-8-basiert? (UTF-16/UTF-32 sind mit MLLP nicht transportierbar.)
  • Gibt es bei einer Rahmenverletzung einen Logeintrag oder einen Zähler — oder passiert das lautlos?
  • Wie wird die Strecke überwacht: „Socket offen” oder „letzte Nachricht vor X Minuten”? (Nur das Zweite ist eine Aussage.)
  • Läuft MLLP über TLS oder durch ein separiertes Netzsegment? Mit NIS-2 und § 30 BSIG ist eine flache Struktur, in der jedes Gerät den ADT-Port erreicht, ein benennbares Defizit im Risikomanagement.

Und die Beweisregel, die aus dieser Seite folgt: Wer einen Screenshot aus einem Texteditor als Nachweis vorlegt, hat nichts nachgewiesen. Bei Verdacht auf Framing- oder Encoding-Probleme ist der Hexdump die einzige zulässige Beweisform — hexdump -C, xxd, od -c, cat -v oder Wireshark „Follow TCP Stream → Hex Dump”.

Lektüre & Belege

Graphansicht

Backlinks