Konzept: Zusatzinformationen außerhalb des Standards
HL7 v2 deckt nicht alles ab, was ein Haus fachlich braucht. Für die Information, die der Standard nicht trägt, gibt es drei Ablageorte — und sie versagen auf drei verschiedene Arten.
| Weg | Was der Empfänger tut | Fehlermodus |
|---|---|---|
| Standardfeld zweckentfremden | parst korrekt, leitet eine falsche Tatsache ab | falsche Daten |
| Z-Segment / Z-Feld am Segmentende | verwirft lautlos, wenn er es nicht erwartet | fehlende Daten |
| gar nicht in die Nachricht | nichts | fehlende Daten, sichtbar fehlend |
Die Rangfolge nach Schadenshöhe ist nicht die der Sauberkeit: Falsche Daten sind teurer als fehlende, weil sie plausibel aussehen. Fehlende Daten fallen irgendwann jemandem auf.
Was der Standard festlegt
HL7 v2.5.1, Kapitel 2:
- § 2.5.2 — „All segment ID codes beginning with the letter Z are reserved for locally defined segments. No such codes will be defined within the HL7 Standard.”
- § 2.6.2, Regel 1 (Rules for the recipient) — „ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected.”
- § 2.5.3.6 — HL7-Tabellenwerte dürfen lokal nicht umdefiniert, die Tabelle darf aber lokal erweitert werden.
Daraus folgt der tragende Satz:
Ein Z-Segment zu senden ist standardkonform. Es zu ignorieren ist ebenfalls standardkonform. Der Empfänger, der es verwirft, befolgt eine Regel — es gibt kein NACK, keinen Logeintrag, keine Warnung. Die Quittung lautet
AA.
Zwischen „gesendet” und „verarbeitet” steht bei Z-Inhalten nichts als eine Vereinbarung. Der Standard stellt den Briefkasten, nicht die Zustellung.
§ 2.5.3.6 zieht zugleich die Grenze für die Zweckentfremdung: Wer ein Feld mit HL7-Tabellenbindung mit hauseigener Bedeutung belegt, verstößt nicht gegen die Syntax — der Parser ist zufrieden — sondern gegen diese Zeile.
Das Kürzel ist kein Namensraum
Z-Segmentkürzel werden nirgends verwaltet: keine Registrierungsstelle, keine Kollisionsprüfung. Dieselbe Buchstabenfolge kann bei zwei Herstellern zwei verschiedene Segmente bezeichnen, und dieselbe Aufgabe kann in zwei publizierten Fassungen unterschiedlich definiert sein.
Das bekannteste Beispiel ist das Bewegungssegment ZBE, unter anderem in der Fassung von IHE PAM (Transaktion ITI-31) und in der Fassung des HL7-Deutschland-Wikis.
| Feld | IHE PAM ITI-31 | HL7-Deutschland-Fassung |
|---|---|---|
| ZBE-1 | Movement ID (EI, R, [1..*]) | Bewegungs-ID (EI, R, [1..*]) |
| ZBE-2 | Start Movement Date/Time (TS, R) | Zeitpunkt Bewegungsbeginn (TS, R) |
| ZBE-3 | End Movement Date/Time (TS, O) | Zeitpunkt Bewegungsende (TS, O) |
| ZBE-4 | Movement Action (ID, R): INSERT · UPDATE · CANCEL | Verarbeitungskennzeichen (ID, R): INSERT · UPDATE · DELETE · CANCEL · REFERENCE |
| ZBE-5 | Historical Movement Indicator (ID, R) | Merkmal historische Bewegung (ID, R), Y/N |
| ZBE-6 | Original trigger event code (ID, C) | Original Event Code (ID, C) |
| ZBE-7 | Responsible Ward (XON, O) | Zuständige Station (XON, O) |
| ZBE-8 | Responsible Nursing Ward (XON, O) | Zuständige Pflegestation (XON, O) |
| ZBE-9 | — | Bewegungsbereich (CWE, O) |
Die Positionen 1 bis 8 stimmen überein. Genau das macht die Kollision gefährlich: Ein Parser nach der einen Fassung liest eine Nachricht nach der anderen fehlerfrei — Datentypen passen, Pflichtfelder sind belegt, das überzählige Feld wird nach § 2.6.2 Regel 1 ignoriert. Kein Validator schlägt an.
Die Abweichung sitzt im Wertevorrat von ZBE-4, und die beiden zusätzlichen Werte tragen eine fachlich wesentliche Unterscheidung:
- CANCEL — die Bewegung wird zurückgenommen. Sie hat stattgefunden, die Entscheidung wurde geändert.
- DELETE — die Bewegung wird aus der Historie entfernt. Sie war eine Fehleingabe, sie hat nie stattgefunden.
Dieselbe Unterscheidung, die die Storno-Events des Standards nicht tragen (siehe 08-Storno ist kein Rollback). Eine Z-Erweiterung kann sie transportieren — aber nur, wenn beide Seiten dieselbe Fassung meinen.
Die Ebene über der Struktur
Aussagen in HL7 v2 sitzen auf einer Leiter:
Wert → Feld → Segment → Anordnung → Bezugsdokument.
Dass Struktur Semantik trägt, ist die eine Erkenntnis (09-Der Merge paart, er benennt nicht). Die andere: Auch die Struktur ist nur relativ zu einem Dokument lesbar, das nicht mitgeschickt wird. Zwei Systeme können byte-identische Nachrichten austauschen und Verschiedenes sagen.
Die Ebene eines Defekts bestimmt man nicht durch Nachdenken, sondern durch Ausschluss — die Leiter von unten nach oben, auf jeder Sprosse dieselbe Frage: Ist hier etwas falsch? Für einen unbekannten Aktionscode etwa: Feld richtig gewählt und richtig typisiert? Ja. Segment vollständig angekommen und gelesen? Ja. Reihenfolge und Positionen korrekt? Ja. Wert im vereinbarten Vorrat? Nein — hier bricht es. Fassungen deckungsgleich? Nein — das ist der Grund, warum ein solcher Wert überhaupt entstehen konnte.
Daraus die Regel: Zu einem Z-Befund gehören immer zwei Ebenen, nicht eine.
Der Wert bricht, das Bezugsdokument lässt ihn brechen.
Der Unterschied ist praktisch, nicht philosophisch:
| Ebene | Prüfbar? |
|---|---|
| Wert | Ja — gegen eine Werteliste, sofern der Empfänger eine hat und sie durchsetzt. Ein Empfänger, der bei unbekanntem Wert still auf eine Ersatzregel zurückfällt, hat die Liste, meldet den Verstoß aber nicht. |
| Bezugsdokument | Nein. Das Dokument ist nicht Teil der Nachricht. Kein Parser, kein Validator, kein Testfall kann prüfen, ob beide Seiten dasselbe Papier meinen. |
Abgrenzung: Mangel in der Nachricht oder Mangel in der Abbildung
Trifft ein Empfänger auf einen Wert, den sein Vorrat nicht kennt, ist die Einordnung nicht trivial — der Empfänger muss wählen, was oberflächlich nach „Empfänger rät” aussieht. Die Trennlinie:
- Der Mangel liegt in der Nachricht, wenn sie — gegen ihr eigenes Bezugsdokument gelesen — eine Frage offenlässt. Dann ist jede Wahl des Empfängers eine Erfindung.
- Der Mangel liegt in der Abbildung, wenn die Nachricht gegen ihr Bezugsdokument eindeutig ist und nur der Wertevorrat des Empfängers sie nicht abdeckt. Dann ist die Abbildung unvollständig, nicht die Aussage.
Der Sonderfall, in dem beides zusammenfällt: Existiert für das Z-Segment gar kein vereinbartes Bezugsdokument, hat die Nachricht keine eigene Bedeutung, gegen die man prüfen könnte — der Mangel liegt dann in der Nachricht, genauer: in ihrem Fehlen einer Definition.
Die Einordnung entscheidet über die Richtung der Reparatur, und das wird regelmäßig verwechselt: Wer einen Abbildungsmangel diagnostiziert, repariert die Abbildung — nicht den Sender. Ein korrekt arbeitendes Fremdsystem umzubauen, damit das eigene unverändert bleiben kann, ist keine Lösung, sondern eine Verschiebung der Kosten.
Werteangleichung ist eine Zweckentfremdung mit Anlauf
Die naheliegende Reparatur bei divergierenden Wertevorräten lautet: den unbekannten Wert auf einen bekannten mappen. Das ist fast immer falsch, wenn die Werte fachlich Verschiedenes bedeuten.
Wird „Bewegung war eine Fehleingabe” auf „Bewegung wurde zurückgenommen” abgebildet, geht genau die Unterscheidung verloren, deretwegen die Z-Erweiterung überhaupt existiert. Und der Zielwert bedeutet danach zweierlei — je nachdem, aus welcher Quelle er stammt. Das ist die Zweckentfremdung eines Standardwerts, nur diesmal auf der Empfängerseite eingebaut: aus dem Fehlermodus „fehlende Daten” wird der teurere „falsche Daten”.
Kann ein Zielsystem einen fachlichen Fall nicht abbilden, ist die richtige Antwort nicht, den Wert zu verbiegen, sondern:
- das Modell des Empfängers erweitern, oder
- den Verlust dokumentieren und die stille Ersatzregel abschalten, damit der Fall sichtbar scheitert statt leise falsch zu laufen.
Lieber ein Fehler im Log als eine stille Falschverarbeitung. Eine falsche Bewegungshistorie ist teurer als ein Ticket.
Auffällig ist nicht wirksam
Eine Nachricht mit mehreren Abweichungen lädt dazu ein, die sichtbarste für die Ursache zu halten. Die Ersetzungsprobe trennt das: Wäre dieser Befund korrekt — änderte sich das Symptom? Sie hat eine Vorbedingung, die gern übersprungen wird — das Symptom vorher vollständig in seine Einzelteile zerlegen. Wer gegen eine verkürzte Fassung des Symptoms prüft, erklärt einen wirksamen Befund für wirkungslos.
Es gibt drei Klassen, nicht zwei:
| Klasse | Beispiel | Warum |
|---|---|---|
| auffällig, nicht wirksam | ein überzähliges Feld am Segmentende | § 2.6.2 Regel 1 — der Empfänger muss Unerwartetes ignorieren |
| wirksam | ein Wert außerhalb des Vorrats des Empfängers | lenkt die Verarbeitung um |
| wirkungslos, weil ungelesen | ein korrekt belegtes Feld, das der Empfänger nicht auswertet | latenter Defekt — wird wirksam, sobald irgendein Empfänger anfängt, es zu lesen |
Die dritte Klasse ist die gefährlichste, weil sie im Test nie auffällt.
Auffälligkeit ist eine Eigenschaft der Nachricht. Wirksamkeit ist eine Eigenschaft der Verarbeitung. Zwischen beiden liegt der Empfänger, und der entscheidet, was er liest. Deshalb kann man Wirksamkeit nicht ansehen, sondern nur prüfen.
Der Ort ist kein Bewegungsbezeichner
Storno-Events benennen die betroffene Bewegung nicht direkt. Für den Abbruch einer Verlegung legt HL7 v2.5.1 § 3.3.12 fest:
„The A12 event is sent when an A02 (transfer a patient) event is cancelled, either because of erroneous entry of the A02 event or because of a decision not to transfer the patient after all.” „PV1-3 - Assigned Patient Location must show the location of the patient prior to the original transfer.”
Daraus folgt zweierlei.
Erstens identifiziert die Nachricht die stornierte Bewegung nur indirekt und schwach: über den Ausgangsort. Eindeutig ist das nur unter der Zusatzannahme, dass der Patient an diesem Ort genau einmal war — eine Annahme, die niemand prüft. Ein Ort identifiziert eine Bewegung nicht, er grenzt sie bestenfalls ein. Genau diese Lücke füllt eine Bewegungs-ID in einem Z-Segment.
Zweitens unterstellt die Festlegung stillschweigend, die stornierte Verlegung sei die letzte. Wird eine Verlegung mitten in einer Kette storniert, während spätere Bewegungen bestehen bleiben, verlangt der Standard in PV1-3 den Ort vor der stornierten Verlegung — und behauptet damit einen Ort, an dem der Patient nicht mehr liegt. Der Defekt entsteht hier nicht durch eine fehlerhafte Implementierung, sondern durch ein Modell, das den Fall nicht kennt.
Bemerkenswert ist außerdem der erste Satz: Der Standard benennt beide Storno-Anlässe — Fehleingabe gegen Entscheidungsänderung — und stellt trotzdem kein Feld bereit, sie zu unterscheiden.
Portalbezug
Patientenportale bauen aus Bewegungen eine Zeitleiste und eine Ortsangabe — beides patientensichtbar.
ZBE-1sagt, welche Bewegung eine Nachricht meint; der ADT-Trigger allein sagt das nicht („Verlegung storniert”, nicht „diese Verlegung storniert”).ZBE-5unterscheidet nachgetragene historische Bewegungen von aktuellen; fehlt sie, rutscht eine Nachtragung mit dem Empfangszeitpunkt an die Spitze der Zeitleiste. Wird das Segment nach § 2.6.2 verworfen, verschwinden beide Aussagen gleichzeitig und spurlos. Für den Patienten ist der Unterschied zwischen „Ihre Verlegung wurde storniert” und „diese Verlegung gab es nie” nicht kosmetisch.
Beispielnachricht (synthetisch)
Eine Storno-Nachricht, die über ZBE-1 benennt, welche Bewegung sie meint, und über ZBE-4 die Art der Rücknahme:
MSH|^~\&|KIS|HAUS-SYNTH|ZIEL|HAUS-SYNTH|20260817101500+0200||ADT^A12^ADT_A12|MSG00042|P|2.5.1|||AL|NE|DEU|8859/1
EVN|A12|20260817101455+0200
PID|1||1000456789^^^HAUS-SYNTH^MR||Weber^Sabine^^^^^L||19700312|F
PV1|1|I|A2^^^HAUS-SYNTH||||||||||||||||6000123456^^^HAUS-SYNTH^VN
ZBE|BW-3001^HAUS-SYNTH|20260817084500+0200||DELETE|N|A02|||BB1^Bewegungsbereich 1^HAUS-SYNTH-BWB
Gegen die IHE-Fassung gelesen: ZBE-4 trägt einen unbekannten Wert, ZBE-9 existiert nicht und wird ignoriert. Gegen die deutsche Fassung gelesen: eine vollständige, eindeutige Aussage. Dieselben Bytes.
Ein Beispiel für die Zweckentfremdung eines Standardfeldes — PV1-16 (VIP Indicator, HL7-Tabelle 0099) belegt mit einem hausinternen Kennzeichen:
PV1|1|I|A2^^^HAUS-SYNTH|||||||||||||Y|||6000123456^^^HAUS-SYNTH^VN
Der Empfänger liest Tabelle 0099 und leitet daraus VIP-Verhalten ab. Beide Seiten sind standardkonform, die Aussage ist vollständig und wurde korrekt verstanden — der Sender hat etwas anderes gesagt, als er meinte.
Beispiele bauen
Sprechende Codes in Beispielen (
STAT,INN,CHI) verleiten dazu, sie nach ihrem Klang statt nach ihrem Feld zu lesen — und stoßen damit oft genau die Achse an, um die es nicht geht. In Lehrbeispielen neutrale Codes wählen, außer die Bedeutung des Codes ist selbst der Gegenstand. Und beim Lesen umgekehrt: EinCWE/CE-Feld führt den Klartext in Komponente 2 mit — die billigste verfügbare Prüfung.
Transfer
Auswertende Systeme sehen den Aktionscode nicht mehr. Sie sehen eine Bewegungstabelle mit einer Verlegung, die nie stattfand, und ohne eine, die stattfand. Der Defekt ist zu diesem Zeitpunkt zweimal unsichtbar geworden: Kein Validator hat angeschlagen, und niemand kennt die Nachricht mehr. Datenqualität ist keine Eigenschaft eines Datensatzes, sondern eines Übergangs.
Im Kahn-Framework ist ein Wert außerhalb des vereinbarten Vorrats Value Conformance; die Folgen in der Auswertung (eine Bewegung, die es nicht gab) sind Plausibility. Dass derselbe Sachverhalt in zwei Schubladen fällt, ist kein Widerspruch: Das Konformitätsraster fragt, wer den Defekt verursacht hat, das Kahn-Raster fragt, wogegen die Daten messbar abweichen — das eine ist die Ursache, das andere der Messwert.
Die Pointe steckt in Kahns eigener Definition: Value Conformance fragt, ob Daten „in agreement with a prespecified, constraint-driven data architecture” sind. Ohne vereinbartes Bezugsdokument existiert nichts, wogegen gemessen werden könnte — dann ist der Befund als Conformance-Verstoß gar nicht darstellbar. Beide Raster hängen an derselben Voraussetzung, und die ist kein technisches Artefakt, sondern ein Blatt Papier.
Fragen an die Kunden-IT
- Welche Z-Segmente sendet Ihr System — und nach welchem Dokument sind sie definiert (nationale Fassung, IHE-Profil, Herstellerhandbuch, Hausfassung)?
- Welche Werte kann das Verarbeitungskennzeichen in Ihrer Installation annehmen, und ist die Liste konfigurierbar?
- Werden fachliche Zusatzinformationen in Standardfeldern geführt, die dafür nicht vorgesehen sind?
- Gibt es eine Liste, welche Z-Segmente die Zielsysteme auswerten — und welche sie nach § 2.6.2 verwerfen?
- Was tut das empfangende System bei einem Wert, den es nicht kennt: NACK, Logeintrag, oder stille Ersatzregel?
Frage 4 ist die unbequemste: Sie fragt nicht nach dem Sender, sondern nach dem Schweigen des Empfängers. Frage 1 ist die, die einen Fall dieser Art in einer Runde entscheidet — die Antwort bestimmt, auf welcher Seite repariert wird.
Lektüre & Belege
- HL7 v2.5.1, Kapitel 2, § 2.5.2, § 2.6.2, § 2.5.3.6 — https://www.hl7.eu/HL7v2x/v251/std251/ch02.html
- HL7 v2.5.1, Kapitel 3, § 3.3.12 (Cancel transfer, A12) — https://www.hl7.eu/HL7v2x/v251/std251/ch03.html
- IHE ITI Technical Framework Vol. 2b, ITI-31 Patient Encounter Management, Table 3.31-6 — https://profiles.ihe.net/ITI/TF/Volume2/ITI-31.html
- IHE ITI Technical Framework Vol. 1, PAM-Profil (Akteure, Optionen) — https://profiles.ihe.net/ITI/TF/Volume1/ch-14.html
- HL7 Deutschland Wiki: Z-Segmente — https://wiki.hl7.de/index.php/Z-Segmente · Segment ZBE — https://wiki.hl7.de/index.php/Segment_ZBE
- Kahn MG et al. (2016), A Harmonized Data Quality Assessment Terminology and Framework for the Secondary Use of EHR Data
Querverweise: 08-Storno ist kein Rollback · 09-Der Merge paart, er benennt nicht · 10-A08 vs. A31 — das Event benennt die Ebene · 04-PV1 und die Fallidentität · Die sechs Fehlerkategorien · Diagnoseleitfaden