Wiki - Chris Seyboth

A08 vs. A31 — das Event benennt die Ebene

5 Min. Lesezeit

Konzept: Das Event benennt die Ebene, nicht nur die Änderung

A08 und A31 transportieren beide geänderte Stammdaten. Sie unterscheiden sich nicht im Inhalt, sondern darin, worüber der Sender spricht.

  • A08 — update patient information. Das Ereignis für den Fall, dass sich Patientendaten geändert haben, ohne dass ein anderes Trigger Event vorliegt. Nachrichtenstruktur: ADT_A01 — also die Struktur der Aufnahme, mit PV1. A08 spricht über einen Patienten in einem Aufenthaltskontext.
  • A31 — update person information. Gehört zur Person-Management-Familie (A28 add, A29 delete, A31 update, A47 change identifier list, A24/A37 link/unlink) und aktualisiert Daten auf Personenebene, unabhängig von einem laufenden Fall. Nachrichtenstruktur: ADT_A05.

Warum das keine Formalie ist

Eine A08 trägt PV1 und behauptet damit immer auch etwas über einen Fall — auch dann, wenn nur der Nachname geändert wurde. Nach der Snapshot-Regel ersetzt jedes gesendete Feld den bisherigen Stand vollständig. Der Empfänger bekommt also zwei Aussagen, obwohl der Sender nur eine machen wollte.

Genau hier liegt die Portalfalle: Ein Portalnutzer hat oft keinen laufenden Fall — Vorab-Onboarding, ambulante Vorbereitung, Wochen nach der Entlassung. Ein KIS, das jede Stammdatenkorrektur als A08 sendet, muss PV1 trotzdem füllen und nimmt dafür in der Regel den zuletzt bekannten Fall. Damit wird ein abgeschlossener Aufenthalt mit aktuellem Zeitstempel erneut behauptet.

Beispiel (synthetisch)

Stammdatenkorrektur nach Heirat. Der Aufenthalt der Patientin ist seit zwei Wochen beendet.

MSH|^~\&|KIS|KH-SYNTH|PORTAL|KH-SYNTH|20260816103012||ADT^A08^ADT_A01|MSG00021|P|2.5
EVN||20260816103012
PID|1||10004711^^^KH-SYNTH^MR||Neumann^Katrin^^^^^L~Berger^Katrin^^^^^M||19870412|F|||Lindenweg 8^^Musterstadt^^12345^DEU
PV1|1|I|INN^204^01^KH-SYNTH|||||||||||||||F0091234^^^KH-SYNTH^VN|||||||||||||||||||||20260731084500

PV1-44 (Aufnahme) ist gefüllt, PV1-45 (Entlassung) fehlt — das Segment endet davor. Nach der Delta-Regel heißt das nicht „keine Entlassung”, sondern „unverändert”. Ob das Zielsystem den Aufenthalt trotzdem als aktiv anzeigt, hängt allein davon ab, wie es die Aktualisierung interpretiert.

Portalbezug

Der typische Ticketverlauf: Die Kunden-IT meldet „wir haben nur den Namen geändert”, im Portal rutscht ein abgeschlossener Aufenthalt an den Anfang der Zeitleiste, und ein Angehöriger fragt, warum die Patientin wieder aufgenommen sei. Quittung MSA|AA, alles formal korrekt.

Was ein PV1 alles behauptet

Die Nebenaussage besteht nicht aus einem Feld, sondern aus dem gesamten Segment. Im Beispiel oben sind das mindestens vier voneinander unabhängige Behauptungen:

FeldDatentypBehauptung
PV1-2 Patient ClassISEs handelt sich um einen stationären Aufenthalt
PV1-3 Assigned Patient LocationPLDer Patient ist diesem Ort zugewiesen — Station, Zimmer, Bett
PV1-19 Visit NumberCXAll das bezieht sich auf diesen Fall
PV1-44 Admit Date/TimeDTM/TSDer Aufenthalt begann zu diesem Zeitpunkt

Zwei Fallstricke beim Lesen dieses Segments:

PV1-3 ist ein Ort, keine Fachabteilung. Der Datentyp ist PL (Person Location): Point of Care, Raum, Bett, Einrichtung. Weil Ortscodes in der Praxis oft sprechend vergeben werden und nach der Fachrichtung der Station benannt sind, liest man leicht eine Fachabteilung hinein. Die steht aber in PV1-10 Hospital Service (IS, benutzerdefinierte Tabelle). Ein sprechender Ortscode bleibt eine Aussage über den Ort — wer ihn als Fachrichtung interpretiert, hat die Achse gewechselt, und ein Zielsystem, das darauf eine Fachabteilungszuordnung baut, tut es ebenso.

Die kausal wirksame Aussage ist selten die auffälligste. Für das Symptom „abgeschlossener Aufenthalt erscheint als aktuell” ist nicht der Ort verantwortlich, sondern die Tatsache, dass der Fall als Ganzes erneut behauptet und damit mit einem aktuellen Änderungszeitpunkt fortgeschrieben wird. Die Ersetzungsprobe trennt beides sauber: Korrigiert man gedanklich nur den Ort, bleibt das Symptom; ersetzt man die A08 durch eine A31, verschwindet es — mit dem PV1 fällt die gesamte Nebenaussage weg.

Regel fürs Schnittstellenkonzept

Für Stammdatenänderungen ohne laufenden Fall ist ein Event auf Personenebene (A31) zu vereinbaren. Ist das Sendesystem dazu nicht in der Lage, ist schriftlich festzuhalten, welchen Fall es in PV1 einsetzt und wie das Zielsystem eine A08 auf einen abgeschlossenen Aufenthalt zu behandeln hat.

Transfer

Wer eine Schnittstellenlandschaft inventarisiert, fragt meist nach welchen Events. Die schärfere Frage ist, auf welcher Ebene ein Sender spricht — und ob er für Personen-Updates ohne Fall überhaupt ein Event hat. Kahn: Eine A08 ohne laufenden Fall ist nicht falsch formatiert (Conformance ist erfüllt), sondern implausibel; das Fehlerbild lebt in der Plausibility-Kategorie und ist nur im Abgleich Quelle ↔ Ziel sichtbar. Einordnung nach dem Kategorienraster: fünfte Kategorie, ungewollte Aussage.

Fragen an die Kunden-IT

  • Habt ihr ein Event für Stammdatenänderungen ohne laufenden Fall? Sendet euer KIS A28/A31/A47 überhaupt, oder ist die Person-Management-Familie nicht implementiert?
  • Wenn eine A08 gesendet wird und kein aktueller Fall existiert — welchen Fall trägt PV1 dann? Den letzten? Einen Dummy? Bleibt das Segment leer?
  • Was soll das Zielsystem tun, wenn eine A08 einen bereits entlassenen Aufenthalt referenziert: Zeitstempel aktualisieren, Aufenthalt reaktivieren, oder nur die Personendaten übernehmen?
  • Wird bei jeder Stammdatenänderung eine A08 gesendet, oder nur bei bestimmten Feldern? Welchen Segmentumfang trägt sie?
  • Kennt euer Zielsystem den Unterschied zwischen ADT_A01 und ADT_A05 in MSH-9.3, oder wird nur der Eventcode ausgewertet?
  • Woraus leitet euer Zielsystem die Fachabteilung ab — aus PV1-10, oder aus dem Ortscode in PV1-3?

Lektüre & Belege

Graphansicht

Backlinks