Konzept: Der deklarierte Zeichensatz ist eine Behauptung
MSH-18 deklariert den Zeichensatz der Nachricht (im deutschen Umfeld üblich 8859/1), MSH-17 das Land. Beides sind Felder, keine Messungen: Die Deklaration und die tatsächliche Kodierung der Bytes können auseinanderfallen.
Genau in dieser Lücke entsteht Mojibake. Die Datei ist UTF-8, MSH-18 behauptet Latin-1, der Empfänger glaubt dem Feld — und aus „Müller” wird „Müller”. Kein Fehler, keine Ablehnung, kein NAK: die Nachricht ist strukturell einwandfrei, nur der Name ist kaputt. Das fällt erst auf, wenn ein Mensch den Datensatz ansieht.
Warum es in Produktion sichtbar wird und im Test nicht
In ASCII-Testdaten ist der Fall unsichtbar. Solange keine Nachricht einen Umlaut, ein ß oder ein Sonderzeichen trägt, sind UTF-8 und Latin-1 byteweise identisch — der Fehler existiert, aber nichts zeigt ihn. Ein Testset, das nur „Max Mustermann” kennt, kann diese Klasse Fehler nicht finden.
Regel: Umlaute gehören in jedes Testset. Mindestens eine Testnachricht muss ä ö ü ß in einem Namensfeld tragen, und zwar mit der Kodierung, die das Haus real schickt.
Verschärfung
Umlaute allein genügen nicht. Sie prüfen nur die hier beschriebene Verfälschung. Den zweiten Schaden derselben Schicht — den Verlust eines Zeichens, das der vereinbarte Zeichensatz gar nicht kennt — findet ein Testset mit
MüllerundGroßgrundsätzlich nie, weil beide Namen in Latin-1 verlustfrei sind. Vollständige Regel: Ein Testset muss mindestens ein Zeichen enthalten, das der vereinbarte Zeichensatz nicht kennt (etwaś,ł,ğ,ı). Ausführlich: 16-Zeichenverlust ist nicht Mojibake.
Transfer
- Nicht fragen „welchen Zeichensatz nutzen Sie?”, sondern eine echte Nachricht mit Umlaut anfordern und die Bytes ansehen. Die Antwort auf die Frage ist die Deklaration; die Datei ist die Wahrheit.
- Beim Mapping nach FHIR ist der Zielzustand eindeutig: FHIR ist UTF-8. Die Konvertierung gehört an die Systemgrenze und muss der tatsächlichen Kodierung folgen, nicht
MSH-18. - Weicht die Deklaration von den Bytes ab, ist das ein Befund für das Schnittstellenkonzept — nicht etwas, das man im Mapper stillschweigend geraderückt.
Fragen an die Kunden-IT
- Welchen Wert trägt
MSH-18, und stimmt er mit der Kodierung der Nutzdaten überein? Bitte an einer Nachricht mit Umlaut zeigen. - Wird die Kodierung irgendwo auf dem Weg umgeschrieben (Kommunikationsserver, Datei-Export, Datenbank-Collation)?
- Gibt es Felder, in denen historisch bereits Mojibake im Bestand steht? Die wandert sonst unverändert ins Zielsystem.
Lektüre & Belege
- HL7 v2, Kapitel 2 (MSH-17/MSH-18)
- Einordnung: 02-MSH trägt die Identität der Nachricht, nicht ihren Inhalt
- Fortsetzung: 16-Zeichenverlust ist nicht Mojibake — der zweite Schaden auf derselben Schicht. Mojibake ist im Ziel heilbar, Zeichenverlust nicht; diese Unterscheidung entscheidet über Fehlerkategorie, Adressat und Reparaturweg.