Storno ist kein Rollback

Konzept: Storno ist kein Rollback

Die Intuition sagt: Ein Storno nimmt das vorherige Ereignis zurück, der Zustand von vorher kommt wieder. HL7 v2 kennt diesen Mechanismus nicht. Ein Storno ist ein eigenständiges Ereignis mit vollem Segmentinhalt — und welchen Zeitpunkt dieser Inhalt beschreibt, ist pro Event einzeln festgelegt, nicht einheitlich.

Event	Storniert	Anlass laut Standard
A11	A01 (Aufnahme) bzw. A04 (Registrierung)	Fehleingabe oder Entscheidung, doch nicht aufzunehmen
A12	A02 (Verlegung)	Fehleingabe oder Entscheidung, doch nicht zu verlegen
A13	A03 (Entlassung)	Fehleingabe oder Entscheidung, doch nicht zu entlassen
A38	A05 (Voraufnahme)	Fehleingabe oder Rücknahme der Voraufnahme

Storno heißt nicht „war ein Fehler”

Der Standard nennt für jedes dieser Events zwei gleichrangige Anlässe: Fehleingabe und reale Entscheidungsänderung. Sie sagen fachlich Gegensätzliches:

Anlass	Aussage über den Vorgang
Fehleingabe	Die Aufnahme hat nie stattgefunden. Es gab nichts.
Entscheidungsänderung	Die Aufnahme findet nicht wie geplant statt. Der Vorgang lebt weiter, oft unter neuer Fallnummer.

Für den Empfänger sind beide ununterscheidbar. Ein Zielsystem, das A11 als „Datensatz löschen” implementiert, hat sich für eine der beiden Lesarten entschieden, ohne dass die Nachricht sie hergibt — und liegt in der Hälfte der Fälle falsch.

Für den Anlass gibt es kein Standardfeld

Das nächstliegende Feld wäre EVN-4 (Event Reason Code) mit HL7-Tabelle 0062. Deren Wertevorrat ist vollständig:

Code	Bedeutung
01	Patient request
02	Physician/health practitioner order
03	Census management
O	Other
U	Unknown

Die Unterscheidung „Fehleingabe versus Entscheidungsänderung” ist darin nicht abbildbar. Das dafür naheliegende Feld führt die entscheidende Semantik nicht. In der Praxis läuft sie deshalb über ein Z-Segment oder eine bilaterale Absprache — was bedeutet: Sie gehört ausdrücklich ins Schnittstellenkonzept, sonst existiert sie nicht.

Wo bleibt, was am Vorgang hing

Die Folgefrage jedes Stornos lautet: Was geschieht mit den Objekten, die am stornierten Vorgang hängen — eingereichte Dokumente, unterschriebene Aufklärungen, Termine, Freischaltungen?

Aus „der Fall existiert nicht mehr” folgt nicht, dass diese Objekte mit verschwinden. Eine digital unterschriebene Aufklärung ist ein Dokument mit eigener Aufbewahrungspflicht; sie hängt fachlich am Patienten und am Eingriff, nicht am Aufenthaltsdatensatz. Wird sie durch ein Storno-Event mitgerissen, ist das kein Anzeigeproblem, sondern gelöschte Dokumentation — und im ungünstigen Fall muss ein Patient kurz vor dem Eingriff neu unterschreiben.

Die Zeitrichtung des Zustandsbilds wechselt

Das ist der Kern. Dasselbe Feld, dieselbe Fehlerklasse „Storno”, entgegengesetzte Richtung:

• A12: PV1-3 muss den Ort zeigen, den der Patient vor der ursprünglichen Verlegung hatte.
• A13: PV1-3 soll den Ort zeigen, an dem der Patient nach der Stornoverarbeitung ist — und der Standard weist ausdrücklich darauf hin, dass dieser vom Ort vor der irrtümlichen Entlassung abweichen kann.

Der Grund ist fachlich zwingend: Eine stornierte Verlegung hat ein eindeutiges „vorher”. Eine stornierte Entlassung hat keines, weil zwischen A03 und A13 Zeit vergeht, in der das Bett neu belegt sein kann.

Und eine Feinheit für die Konzeptdiskussion: Die Rückwärtsrichtung ist verbindlich, die Vorwärtsrichtung nur empfohlen. Ein Haus kann bei A13 abweichen, ohne formal unkonform zu sein. Genau deshalb gehört A13 ausdrücklich in jedes Schnittstellenkonzept.

Beispiel (synthetisch)

Irrtümliche Entlassung, vierzig Minuten später storniert. In der Zwischenzeit wurde das Bett neu belegt, die Patientin liegt real in 3B-09.

MSH|^~\&|KIS|KH-SYNTH|PORTAL|KH-SYNTH|20260814144108||ADT^A13|MSG01893|P|2.5|||AL|AL|||UNICODE UTF-8
EVN|A13|20260814144108|||PFL3B^Kaiser^Ulrike^^^^^^KH-SYNTH^^^^PRN|20260814144000
PID|1||10004711^^^KH-SYNTH^MR||Musterfrau^Anke^^^^^L||19780314|F
PV1|1|I|INN^3B^09^KH-SYNTH||||1234^Berger^Jan^^^Dr.^^^KH-SYNTH^^^^DN|||INN|||||||||F0091234^^^KH-SYNTH^VN|||||||||||||||||||||||||20260812093000|""

Zwei Dinge sind hier bewusst gesetzt: PV1-3 trägt den neuen Ort (3B-09), nicht den vor der Entlassung. Und PV1-45 steht auf "" — das Entlassdatum wird aktiv genullt, nicht weggelassen. Wer es wegließe, hätte nach der Delta-Regel gesagt „bleibt wie es ist”, und der Aufenthalt trüge weiterhin ein Entlassdatum.

Portalbezug

Ein Storno ist für ein Patientenportal der heikelste ADT-Vorgang, weil er sichtbare Zustände zurückdreht, die der Patient möglicherweise schon gesehen hat. Zwei Fragen entscheiden über das Verhalten: Wird der Aufenthalt gelöscht oder als storniert markiert? Und was passiert mit Dokumenten, Terminen und Freischaltungen, die daran hängen?

Regel fürs Schnittstellenkonzept

Je Storno-Event ist schriftlich festzulegen, welches Zustandsbild der Sender in PV1-3 füllt (Zeitpunkt vor oder nach dem stornierten Ereignis) und ob Felder wie PV1-45 aktiv genullt oder weggelassen werden. „Wir stornieren korrekt” ist keine prüfbare Zusage.

Transfer

Der häufigste Satz in dieser Fehlerklasse — „bei Verlegungen funktioniert unser Storno seit Jahren” — ist kein Ausweichen, sondern der eigentliche Befund: Ein Sendesystem, das eine korrekte Regel auf das falsche Event anwendet, bleibt jahrelang unauffällig, weil das häufigere Event richtig bedient wird. Kahn-Kategorie: Plausibility. Zwei Patienten in einem Bett fällt keinem Validator auf, aber jedem Bettenbelegungsabgleich. Einordnung nach dem Kategorienraster: Beim Zeitrichtungsfehler (A12-Regel auf A13 angewandt) ist es die fünfte Kategorie — die Aussage ist vollständig und wird korrekt verstanden, sie war nur nicht gemeint. Beim Anlass (A11: Fehleingabe oder Entscheidungsänderung?) ist es die dritte — die Aussage ist unterbestimmt, der Empfänger muss wählen, und auch „nichts löschen” wäre geraten. Dieselbe Eventfamilie trägt beide Klassen; welche vorliegt, entscheidet sich daran, ob die Aussage vollständig ist. Vorgehen: Diagnoseleitfaden, Schritt 5.

Fragen an die Kunden-IT

• Woran erkennt der Empfänger, ob eine Fehleingabe oder eine Entscheidungsänderung vorliegt? Wenn die Antwort „gar nicht” lautet: welche Lesart soll das Zielsystem annehmen, und ist das schriftlich festgehalten?
• Welches Zustandsbild füllt euer KIS je Storno-Event in PV1-3 — den Ort vor oder nach dem stornierten Ereignis? Bitte getrennt für A12 und A13 beantworten.
• Werden bei A13 die Entlassfelder aktiv mit "" genullt oder weggelassen?
• Nutzt ihr EVN-4 (Event Reason Code)? Mit welchen Werten — und tragen sie die Unterscheidung, die ihr eigentlich meint?
• Was soll das Zielsystem bei A11 tun — den Datensatz löschen, deaktivieren, oder als storniert kennzeichnen? Was passiert mit daran hängenden Dokumenten?
• Wie lange nach dem Ereignis kann bei euch noch storniert werden? Gibt es eine Frist, oder ist es unbegrenzt?
• Sendet ihr A38, oder werden Voraufnahmen anders zurückgenommen?

Lektüre & Belege

• HL7 v2.5.1, Kapitel 3 — Patient Administration — Trigger Events A11, A12, A13, A38 im Wortlaut, inklusive der Formulierungen zu PV1-3
• IHE ITI-31 — Patient Encounter Management — A11 und A13 gehören zum Basic Subset, A12 und A38 zur Inpatient/Outpatient-Option
• Tabelle 0003 — Event Type (THO 6.0.1) · Tabelle 0062 — Event Reason (THO 6.0.1)
• Siehe auch: Leer heißt nicht leeren · PV1 und die Fallidentität
• Sammlung aller Referenzen: Quellen & Lektüre