Der Merge paart, er benennt nicht

Konzept: Der Merge paart, er benennt nicht

Ein A40 (merge patient — patient identifier list) sieht aus wie eine Umbenennung: alte Nummer raus, neue Nummer rein. Das ist er nicht. Er ist eine paarweise Zuordnung zwischen zwei Identifier-Listen — und die Paarung läuft weder über die Position noch über den Wert, sondern über den Identifier-Typ (CX.5).

Der MRG-1 trägt den aufzugebenden Identifier, der PID-3 den überlebenden. Jeder Identifier in MRG-1 wird mit dem Identifier gleichen Typs in PID-3 zusammengeführt.

Drei Konsequenzen, die alle drei zubeißen

1. Die Richtung steht in der Rolle der Segmente, nicht in einem Feld. PID-3 ist die überlebende Identität, MRG-1 die aufzugebende. Nirgends steht ein Feld „Richtung”; die Semantik ergibt sich allein daraus, in welchem Segment ein Identifier auftaucht. Das ist der allgemeinere Gedanke: Welche Information trägt hier die Struktur statt eines Feldes?

Die Konsequenz ist unangenehm: Eine vertauschte Achse erzeugt keine fehlerhafte Nachricht, sondern eine wohlgeformte Nachricht mit anderer Bedeutung. Stünde die Richtung in einem Feld, ließe sie sich gegen eine Tabelle prüfen. Weil sie in der Struktur steht, gibt es nichts zu validieren — jeder Validator, jeder Parser und jede Quittung sehen eine einwandfreie A40. Der Empfänger führt korrekt zusammen, nur in die falsche Richtung, und kann protokollarisch nicht anders.

Die einzige verbleibende Verteidigung ist fachliche Plausibilisierung vor der Ausführung: Trägt die aufzugebende Identität deutlich mehr Historie als die überlebende, ist das ein Anlass zum Anhalten, nicht zum Zusammenführen. Ein Merge, bei dem drei Jahre Dokumente auf eine zwei Wochen alte Kurzaufnahme wandern, ist formal einwandfrei und fachlich fast immer verkehrt herum.

Das Fehlerbild ist zudem selbstverstärkend: Nach einem Achsendreher gilt im Quellsystem die eine Identität als führend, im Zielsystem die andere. Jede folgende Nachricht trägt die im Quellsystem überlebende Nummer — die das Zielsystem als aufgegeben kennt. Der Zustand vor dem Merge stellt sich wieder her, mit vertauschten Rollen, und der nächste Merge wiederholt das Spiel.

2. Paarung, nicht Ersetzung. Beide Seiten sind Listen mit Wiederholungen. Es wird nicht „die Akte” auf „die Akte” abgebildet, sondern jeder Identifier auf seinen gleichtypigen Gegenpart. Fehlt der Gegenpart, ist für diesen Identifier keine Paarung definiert — und der Standard sagt nicht, was dann gilt. Der Empfänger muss wählen: paaren über einen anderen Typ, den Merge verwerfen, oder abbrechen. Jede dieser Wahlen ist Raten.

3. A40 ist nicht A47. A47 (change patient identifier list) ändert die Nummer einer Akte. A40 führt zwei Akten zusammen. Wer beides auf denselben Codepfad legt, verliert bei A40 die Daten der aufgegebenen Akte, weil nur die Nummer umgeschrieben und nichts zusammengeführt wird.

Und eine Ebene darunter: CX.4 (Assigning Authority). Zwei gleiche Ziffernfolgen aus zwei Namensräumen sind zwei Identitäten. Ein Empfänger, der CX.1 allein vergleicht, paart Zufälle.

Beispiel (synthetisch)

MSH|^~\&|KIS|KH-SYNTH|PORTAL|KH-SYNTH|20260815091200||ADT^A40^ADT_A39|20260815-4711|P|2.5|||AL|AL|||UNICODE UTF-8
EVN|A40|20260815091200
PID|1||10004711^^^KH-SYNTH^MR~A123456789^^^DEU-KV^NI||Beier^Marlene^^^^^L||19620314|F|||Ringstr. 4^^Musterstadt^^12345^DEU
MRG|9900042^^^KH-SYNTH^PI

PID-3 trägt zwei Wiederholungen (MR, NI), MRG-1 eine (PI). Für den PI existiert in PID-3 kein gleichtypiger Gegenpart. Die Nachricht ist wohlgeformt, jeder Validator lässt sie durch — und die Paarung ist trotzdem unterbestimmt.

Portalbezug

Der Merge ist das einzige ADT-Ereignis, das eine bereits verarbeitete Historie im Zielsystem rückwirkend umhängt. Im Portal hängen an der aufgegebenen Akte typischerweise eingereichte Dokumente, unterschriebene Aufklärungsbögen und Freischaltungen. Wird der Merge nicht ausgeführt, bestehen zwei Konten weiter, und welches der Patient sieht, hängt am Einladungslink.

Der Vergleich mit FHIR / ISiK

ISiK löst denselben Vorgang im Basismodul über Patient.link: Die obsolete Ressource wird auf active = false gesetzt und trägt link.type = replaced-by auf die überlebende, diese link.type = replaces zurück. Bemerkenswert für die Datenstrecke ist die Empfehlung an den Client, den Zustand einer gecachten Patienteninstanz vor jeder Interaktion per READ zu prüfen und im Zweifel über einen bekannten stabilen Identifier neu zu laden — genau die Rolle, die die Krankenversichertennummer (NI) im Beispiel oben spielt und die im MRG-1 fehlt.

Regel fürs Schnittstellenkonzept

Für jeden Identifier-Typ, der in MRG-1 auftreten kann, ist der gleichtypige Gegenpart in PID-3 verbindlich zu fordern. Fehlt er, ist der Merge als fehlerhaft zu protokollieren und nicht auszuführen — nicht heuristisch zu paaren und nicht still zu verwerfen.

Transfer

Einordnung nach dem Kategorienraster: dritte Kategorie — der Empfänger rät. Abzugrenzen von der fünften: Dort ist die Aussage vollständig und wird korrekt verstanden, hier gibt es nichts korrekt zu verstehen. Wer den Merge still verwirft, hat genauso geraten wie wer paart. Ein MSA|AA ist dabei ehrlich, weil AA nur „meine Anwendung hat verarbeitet” sagt — Verwerfen ist eine erfolgreiche Verarbeitung. Kahn: Conformance (die Paarung ist unterbestimmt) mit Folgewirkung auf Completeness (Dokumente hängen an der Akte, die niemand mehr sieht).

Fragen an die Kunden-IT

• Welche Identifier-Typen sendet ihr in MRG-1, welche in PID-3? Gibt es für jeden Typ in MRG-1 einen gleichtypigen Gegenpart?
• Ist CX.4 auf beiden Seiten gesetzt, und mit demselben Namensraum?
• Nutzt ihr A40 und A47 unterschiedlich, oder laufen beide über denselben Codepfad?
• Was soll im Zielsystem mit Dokumenten, Einwilligungen und Terminen geschehen, die an der aufgegebenen Akte hängen?
• Prüft euer Zielsystem vor dem Zusammenführen die Plausibilität der Richtung — etwa den Umfang der Historie auf beiden Seiten? Falls nein: ein Achsendreher ist dort nicht bemerkbar.
• Wird ein Merge bei euch je rückgängig gemacht? Wenn ja: über welches Event, und was erwartet ihr vom Zielsystem?
• Wie oft kommt das vor? (Bei Häusern mit Notaufnahme-Kurzaufnahmen ist die Antwort meist deutlich höher als geschätzt.)

Lektüre & Belege

• IHE ITI-30 — Patient Identity Management — reproduziert die Definition von A40/A47 und die Regel der typgleichen Paarung
• HL7 v2.5.1, Kapitel 3 — Patient Administration — MRG-Segment und die Merge-Eventfamilie im Normtext
• Tabelle 0203 — Identifier Type (THO 6.0.1) — MR, PI, NI und die übrigen Typcodes
• ISiK-Basismodul — Implementierungsleitfaden auf Simplifier — Abschnitt zu Patient.link und Patient-merge
• Siehe auch: Wiederholung ≠ Komponente · PV1 und die Fallidentität
• Sammlung aller Referenzen: Quellen & Lektüre