Konzept: Leer heißt nicht leeren
Ein Update in HL7 v2 sagt nicht nur, was ein Feld jetzt enthält — es sagt auch etwas über die Felder, die es nicht enthält. Das ist im Standard eindeutig geregelt und wird in der Praxis regelmäßig übersehen.
HL7 v2.5, Kapitel 2.5.3:
„Sending the null value, which is transmitted as two double quote marks (""), is different from omitting an optional data field. […] If the null value is sent, the old value should be changed to null. If no value is sent, (i.e., it is omitted) the old value should remain unchanged.”
Damit gibt es in jedem Update genau drei Feldzustände:
| Notation | Bedeutung | Wirkung beim Empfänger |
|---|---|---|
|| | Feld weggelassen | alter Wert bleibt |
|""| | HL7 null value | alter Wert wird gelöscht |
|Wert| | Feld gesetzt | alter Wert wird ersetzt |
Leer ist also keine Lücke, sondern eine Aussage. Wer ein Feld im Sendesystem leert und die Nachricht danach ohne dieses Feld verschickt, hat nicht „die Änderung gesendet” — er hat gesendet, dass sich nichts ändert.
Das Feld ist Snapshot, die Auslassung ist Delta
Für wiederholende Felder folgt daraus eine zweite Regel, die im Standard nicht ausformuliert ist, sich aber zwingend ergibt: HL7 v2 kennt kein „füge eine Wiederholung hinzu” und kein „entferne eine”. Ein gesendetes Feld ersetzt das Feld deshalb vollständig, samt aller Wiederholungen. Nur die Auslassung trägt Delta-Semantik.
Praktische Konsequenz: Eine von zwei Wiederholungen entfernt man, indem man das Feld mit den verbleibenden Wiederholungen neu sendet — nicht mit "", denn das löscht alle.
Wo der Standard selbst weich wird
Zu ADT^A08 heißt es (HL7 v2.3.1, Kap. 3): „This trigger event is used when any patient information has changed but when no other trigger event has occurred.” Und zum Umgang mit Feldern, die nicht unmittelbar zum Ereignis gehören, ausdrücklich: es sei „a matter for implementation negotiation as to whether the receiving systems can capture this changed data.”
Der Standard delegiert die Update-Semantik also selbst an die Schnittstellenvereinbarung. Deshalb existieren zwei unvereinbare Lesarten nebeneinander:
| Lesart | Was ein leeres Feld bedeutet | Typischer Vertreter |
|---|---|---|
| Delta (standardkonform) | unverändert lassen | Sendesysteme, die nur geänderte Felder füllen |
| Snapshot (verbreitete Praxis) | der aktuelle Stand ist genau das, was hier steht | Portale, MPIs, Data Warehouses |
Sender im Delta-Modus + Empfänger im Snapshot-Modus verliert Daten. Sender im Snapshot-Modus + Empfänger im Delta-Modus behält Daten, die es nicht mehr gibt — die gefährlichere Richtung, weil nichts verschwindet und deshalb niemand etwas bemerkt.
A08 oder A31
A08 aktualisiert Patientendaten im Kontext der laufenden Episode, A31 Personendaten unabhängig vom Aufenthalt („An A31 event can be used to update person information on an MPI. It is similar to an A08 […] but an A08 […] should be used to update patient information for a current episode.”). Die Wahl richtet sich nach dem Gegenstand, nicht nach der Systemlandschaft — und sie ändert nichts an der Null-Regel. Ein weggelassenes Feld ist in einer A31 genauso „unverändert”.
Portalbezug
Ein Patientenportal versendet Login-TANs auf Kontaktdaten, die aus ADT stammen. Wird eine Rufnummer im Sendesystem gelöscht und die Löschung nicht als
""übertragen, versendet das Portal weiter an die alte Nummer. Rufnummern werden nach Kündigung neu vergeben — aus einem Anzeigeproblem wird damit ein Zugangsfaktor an einen unbeteiligten Dritten.
Beispielnachricht (synthetisch)
Die Mobilnummer wurde im Sendesystem gelöscht, die E-Mail bleibt bestehen. Diese A08 überträgt die Löschung nicht — PID-13 fehlt vollständig:
MSH|^~\&|KIS|KH-MUSTER^1.2.276.0.76.3.1.999^ISO|PORTAL|KH-MUSTER^1.2.276.0.76.3.1.999^ISO|20260811101500+0200||ADT^A08^ADT_A01|KIS-20260811-005093|P|2.5|||AL|NE|DEU|UNICODE UTF-8
EVN|A08|20260811101200+0200|||MFA07^Timm^Jonas|20260811101200+0200
PID|1||2026000815^^^KH-MUSTER-MPI&1.2.276.0.76.3.1.999.2&ISO^MR||Weber^Anna^Maria^^^^L||19680214|F|||Lindenweg 12^^Musterstadt^^12345^DEU^H|||||||2026000815
Korrekt wäre PID-13 mit der verbleibenden Wiederholung gewesen:
PID|1||2026000815^^^KH-MUSTER-MPI&1.2.276.0.76.3.1.999.2&ISO^MR||Weber^Anna^Maria^^^^L||19680214|F|||Lindenweg 12^^Musterstadt^^12345^DEU^H||^NET^Internet^a.weber@example.org|||||2026000815
Die Nachricht oben ist standardkonform und verursacht den Schaden trotzdem. Der Empfänger rät nicht und mappt nicht falsch — er befolgt die Spezifikation exakt. Das ist eine eigene Fehlerklasse: der Sender hat eine Aussage gemacht, die er nicht machen wollte, und der Empfänger hat sie korrekt verstanden. Beide Seiten sind fehlerfrei, es gibt keinen Fehler, den man zeigen könnte — und genau deshalb entscheidet sich die Zuständigkeit allein über die Vereinbarung.
Regel fürs Schnittstellenkonzept
Eine der beiden Fassungen gehört schriftlich festgelegt. Welche, ist zweitrangig, dass eine gewählt und benannt ist, ist der Punkt.
ADT^A08undADT^A31werden als vollständiger Snapshot der enthaltenen Segmente interpretiert. Ein in der Nachricht leeres Feld gilt als gelöscht. Felder, die das sendende System nicht führt, sind vorab namentlich zu benennen und von dieser Regel ausgenommen.
Gegenrichtung: Löschungen sind ausschließlich über den HL7 null value "" zu übertragen; ein leeres Feld bedeutet unverändert. Diese Fassung ist standardkonform, setzt aber voraus, dass das Sendesystem "" überhaupt emittieren kann — die entscheidende Frage an jede Gegenstelle.
Transfer
Ein korrekt übertragener, aber veralteter Wert ist in den Kahn-Kategorien conformant (gültiger Datentyp) und complete (ein Wert ist vorhanden) — er scheitert allein an Plausibilität und Aktualität. Also genau an der Dimension, die weder Validator noch ACK abdecken. Für die Inventur-Checkliste: pro Strecke festhalten, ob Updates als Delta oder Snapshot gelten und ob das Sendesystem den null value unterstützt.
Siehe auch: Der ACK-Vertrag · Die ADT-Eventfamilie
Fragen an die Kunden-IT
Die erste Frage ist die wichtigste dieser ganzen Seite, und sie wird fast nie gestellt:
- Sendet ihr Snapshot oder Delta? Also: Bedeutet ein fehlendes Feld „unverändert” oder „nicht vorhanden”?
- Unterstützt euer KIS das HL7-Null-Value
""— und sendet es das tatsächlich, wenn ein Feld gelöscht wird? (Beides sind getrennte Fragen.) - Konkreter Testfall: Eine Mobilnummer wird im KIS gelöscht. Welche Nachricht geht raus, und was steht in
PID-13? - Trägt eine A08 den vollständigen Segmentinhalt oder nur die geänderten Felder?
- Steht dazu etwas Schriftliches im Schnittstellenkonzept? Falls nein, ist das der erste Punkt — mündliche Zusagen zur Update-Semantik überleben keinen Release-Wechsel.
Lektüre & Belege
- HL7 v2.5.1, Kapitel 2 — Control — Abschnitt 2.5.3, Behandlung leerer Felder und des Null-Value
"" - HL7 v2.5.1, Kapitel 3 — A08 (update patient information) und A31 (update person information) im Wortlaut
- IHE ITI-30 — Patient Identity Management — A28/A31/A47 als Person-Management-Familie
- Sammlung aller Referenzen: Quellen & Lektüre