MPI-Anbieter waren sich uneinig. Wir haben Patient Merge gelöst

Nach zwei Jahrzehnten Arbeit hat das IHE PIX/PDQ-Komitee die Semantik von Patient-Merge bewusst als implementierungsdefiniert belassen. Der Standard besagt, dass Merges innerhalb einer Patient Identity Domain stattfinden, legt jedoch nicht fest, was ein Merge bewirkt – und überlässt die „Verantwortung für Qualität und Verwaltung von Patientendemografie-Informationen innerhalb jeder Patient Identity Domain" den Implementierern. Das ist keine Lücke in der Spezifikation – es ist ein Eingeständnis. Es gibt kein einzig richtiges Merge-Verfahren.

IHE ist damit nicht allein. Eine aktuelle Branchenanalyse bezeichnet Merge-Operationen als „verstreute SOPs statt eines einheitlichen, auffindbaren Rahmens" – kein Normungsgremium, keine Regulierungsbehörde hat diese Lücke geschlossen. ONC und CMS schreiben Audit-Trails vor und treiben die Erkennungsraten kontinuierlich in die Höhe; das eigentliche Merge-Verfahren schreibt keiner von beiden vor. Es ist dasselbe Eingeständnis, das IHE gemacht hat – nur eine Ebene weiter oben.

Unser vorheriger Beitrag endete mit dem Versprechen von $unmerge. Dieses Versprechen gilt weiterhin, aber eine Frage blieb offen: Warum sollten Merge und Unmerge überhaupt auf diese Weise funktionieren? Dieser Beitrag schließt diese Lücke. Es geht darum, warum ein servergesteuertes Merge nicht funktionieren kann – egal wie intelligent der Server ist.

Was die FHIR-Spezifikation heute bietet

FHIR R5 definiert Patient/$merge auf Reifegrad 0. Eingaben: source-patient, target-patient, optionales result-patient. Vom Server wird erwartet, dass er die Quelle deaktiviert, Identifier kopiert und Referenzen aktualisiert. Wie er dies jeweils tut, bleibt der Implementierung überlassen. Die Operation hat sich seit dem Erscheinen von R5 nicht über Reifegrad 0 hinausbewegt.

Der Grund dafür ist nicht mangelndes Engagement. Es liegt daran, dass jeder Aspekt von „Merge" eine Richtlinienentscheidung ist – und Richtlinien variieren strukturell: über Anbieter, über Deployments und über Rechtssysteme hinweg.

Merge und Link sind Punkte auf demselben Spektrum

Vor den Achsen eine Neubewertung. Merge und Link werden häufig als konkurrierende Operationen zusammengefasst, aber sie sind Punkte auf demselben Spektrum.

Am Link-Ende überleben beide Datensätze, Referenzen bleiben an ihrem Ziel, beide bleiben aktiv, und nachgelagerte Daten bleiben jeweils am entsprechenden Datensatz hängen. Am Merge-Ende entscheidet Survivorship darüber, welche Felder erhalten bleiben, Referenzen werden umgeschrieben, die Quelle wird deaktiviert oder gelöscht, und abgeleitete Daten müssen neu bewertet werden. Reale Implementierungen liegen zwischen diesen Polen: CommonWell bewertet die Link-Stärke explizit; Oracle Health Millennium hält die Quelle inaktiv, aber über die ID adressierbar; VistA löscht hart; NHS PDS setzt den alten Identifier außer Kraft und leitet historische Abfragen um. Je mehr sich eine Implementierung wie ein Link verhält, desto weniger legt sie über den überlebenden Zustand fest. Je mehr sie sich wie ein Merge verhält, desto mehr Richtlinien muss sie übernehmen.

Die vier nachstehenden Achsen definieren, wo eine Implementierung auf diesem Spektrum steht. Sie sind keine geringfügigen Variationen innerhalb von „Merge als Operation" – sie sind das, was Link von Merge trennt. Sobald jede Achse mehrere legitime Antworten hat, explodiert die Anzahl der Kombinationen schnell.

Vier Achsen der Variabilität

Survivorship – welche Felder erhalten bleiben

Wenn zwei Patientendatensätze zusammengeführt werden, gibt es Konflikte bei Dutzenden von Feldern: Name, Adresse, Telefon, Identifier, Allergien, Problemliste, Medikamente, Code-Status. Welcher Wert gewinnt, ist die Survivorship-Regel.

Jeder seriöse MPI-Anbieter macht dies konfigurierbar und nicht fest codiert:

• IBM InfoSphere MDM liefert vier unterschiedliche Merge-Party-Survivorship-Regeln als einsteckbare Java-Klassen, die bei der Erkennung verdächtiger Duplikate und bei explizitem Party Collapse ausgelöst werden. Die Regel ist ein Konfigurationsparameter, kein fest codierter Algorithmus.
• Verato bietet Auto-Steward und Smart Steward als eigenständige Stewardship-Produkte an: Das eine löst Duplikate automatisch gegen eine Referenzdatenbank auf, das andere liefert KI-gestützte Empfehlungen für menschliche Stewards – zwei unterschiedliche Antworten auf die Frage, ob diese Entscheidung überhaupt automatisiert werden kann.
• Smile CDR, ein FHIR-natives MDM, macht Survivorship zu einem JavaScript-Handler, den der Client schreibt. Hilfsfunktionen wie mergeAll() und replaceAll() werden bereitgestellt; der Handler kombiniert sie oder implementiert eine eigene feldbasierte Logik. Es gibt keinen Standard – der Client wird gezwungen, die Richtlinienentscheidung explizit zu treffen.

Wenn eine einzige korrekte Survivorship-Strategie existieren würde, hätten die Anbieter sie fest codiert. Das haben sie nicht, weil es sie nicht gibt.

Die Kosten, wenn die Richtlinie falsch liegt, sind unmittelbar. Ein AHRQ PSNet-Fall beschreibt einen Patienten, dessen Kontrastmittelallergie während der Abgleichung entfernt wurde, weil ein Kliniker sie als „keine echte Allergie" eingestuft hatte. Das EHR zeigte daraufhin „keine bekannten Allergien" an – und der Patient wurde anschließend für ein Kontrast-CT eingeplant. Dieselbe Fehlerklasse wie bei einem naiven Merge: Eine Regel nach dem Muster „Quellen, die minderwertig erscheinen, verwerfen" löschte still und heimlich klinisch relevante Daten. Eine andere Survivorship-Richtlinie – niemals eine Allergie entfernen, immer zur Überprüfung markieren – hätte dies verhindert.

Die Patientenidentifikations-Leitlinien von ECRI benennen die Richtungspräferenz direkt: „Doppelte Datensätze sind fehlerhaft zusammengeführten Datensätzen vorzuziehen." Im Zweifel Datensätze getrennt halten statt zusammenführen. Die Regel lässt sich nicht generisch kodieren, weil „fehlerhaft" durch den klinischen Kontext definiert wird, den der Server nicht sieht.

Referenzbehandlung – was mit Zeigern auf die Quelle geschieht

Jeder Merge wirft eine zweite Frage auf: Dutzende oder Tausende von Ressourcen referenzieren den Quellpatienten – Encounters, Observations, Claims, Appointments. Was passiert mit diesen Referenzen?

Öffentliche Implementierungen geben unterschiedliche Antworten:

• Oracle Health Millennium (Cerner) liefert einen zusammengeführten Patienten als inaktiv mit einem Link zum aktuellen Patienten zurück und dokumentiert, dass das Aufheben der Zusammenführung unterstützt wird.
• VistA (VA) verschiebt Daten vom FROM- zum TO-Datensatz, setzt betroffene Dateien neu und eliminiert den FROM-Datensatz als aktiven Eintrag. Ist ein Feld in FROM befüllt und in TO leer, wird dieser Wert automatisch übertragen; um stattdessen ein leeres Ergebnis zu erhalten, muss der Quellwert außerhalb des Merge-Workflows gelöscht werden.
• CommonWell Health Alliance, ein US-weites Gesundheitsinformationsnetzwerk, modelliert Identität als Links zwischen Organisationen statt als einen einzigen zusammengeführten Überlebens-Datensatz. Diese Links werden mit Levels of Link Assurance (LOLA) bewertet.
• NHS England's PDS führt bestätigte doppelte NHS-Nummern zu einer einzigen überlebenden Nummer zusammen, und die API-Dokumentation beschreibt, wie abgelöste NHS-Nummern eine Ersatznummer zurückgeben.

Vier Formen, vier unterschiedliche Positionen auf dem Link↔Merge-Spektrum. Manche behalten beide Datensätze und lösen die Identität über Links auf. Manche schreiben zum Zeitpunkt des Merge jede Referenz auf den überlebenden Datensatz um. Manche behalten die Quelle als inaktiven Datensatz, den Clients weiterhin auflösen können. Andere stützen sich auf einen separaten Zeigermechanismus zwischen alter und aktueller Identität. Alle sind in ihrem jeweiligen Kontext vertretbar.

Quelldatensatz-Disposition – was aus dem Quelldatensatz wird

Bei der Referenzbehandlung geht es um eingehende Zeiger. Die Quelldatensatz-Disposition ist anders: Was passiert mit dem Quelldatensatz selbst nach dem Merge? Die FHIR admin-incubator-Spezifikation listet in einem Satz zwei zulässige Ergebnisse auf – „ein GET auf die Quell-Patient-Ressourcen-ID gibt entweder 200 OK zurück (inaktiv, replaced-by befüllt) oder 404 not found (wenn das Merge-System die Ressource gelöscht hat)". Reale Deployments fügen darüber hinaus weitere Varianten hinzu:

• Inaktiv mit replaced-by-Link. Oracle Health Millennium verwendet genau dieses Modell: Die Quelle wird als inaktiv und mit dem aktuellen Patienten verknüpft zurückgegeben, nur über direkte ID-Abfrage adressierbar, niemals über die Suche.
• Hart gelöscht. VistA verschiebt Daten vom FROM-Datensatz zum TO-Datensatz, setzt betroffene Dateien neu und eliminiert den FROM-Datensatz als aktiven Eintrag. Ein späteres GET findet nichts.
• Abgelöster Identifier, neue kanonische Nummer. NHS England's PDS setzt die alte NHS-Nummer als superseded außer Kraft und gibt eine Ersatznummer aus; historische Abfragen werden zum überlebenden Datensatz weitergeleitet, anstatt den Quelldatensatz selbst beizubehalten.
• Obsolet, aber in einer separaten Zustandsmaschine erfasst. IBM Initiate behält das obsolete Member mit einer eigenen Zeile und dem Verknüpfungstyp Merged, das die EID des Überlebenden trägt. Die Quelle ist weder aktiv noch verschwunden – sie befindet sich in einem eigenen Lebenszyklusstatus, damit das MDM weiterhin über sie urteilen kann.

Hinzu kommen jurisdiktionsspezifische Aufbewahrungs- und Löschungsregeln – DSGVO Artikel 17 in der EU, 42 CFR Part 2-Segmentierung in den USA, staatliche Minderjährigen-Einwilligungsgesetze –, die jeweils einschränken, was der Quelldatensatz werden kann oder muss. Der US-amerikanische föderale Rahmen zeigt dasselbe Muster durch Auslassung: ONC und CMS verlangen Rückverfolgbarkeit und Datenqualität, während Bemühungen wie der im März 2025 neu eingebrachte MATCH IT Act und TEFCA die Identitätsqualität vorgelagert verbessern wollen. Sie versuchen, den Bedarf an Merge zu reduzieren; das eigentliche Merge-Verfahren schreiben sie weiterhin nicht vor.

Nachgelagerte Auswirkungen – abgeleitete Artefakte und Folgearbeiten

Die Zusammenführung des Patientendatensatzes ist nur das Problem erster Ordnung. Das Problem zweiter Ordnung ist alles, was aus dem Datensatz abgeleitet wird und einer mechanischen Referenzumschreibung nicht folgt: Verknüpfungsgraphen im MDM, kumulative Berechnungen wie Strahlendosis oder kumulative Opioid-Gesamtmengen, Caches von Drittanbietern. Zwei öffentliche Beispiele verdeutlichen dies:

• IBM Initiate dokumentiert, dass wenn Member C in eine neue Entität gemergt wird, Members A und B, die zuvor mit C verknüpft waren, nicht automatisch folgen. Sie erhalten jeweils eine neue EID und durchlaufen den Vergleichsprozess erneut. Der Merge schließt den Verknüpfungsgraphen nicht transitiv ab – das MDM bewertet neu, und einige zuvor verknüpfte Datensätze können woanders oder gar nicht mehr angehängt werden.
• Epics öffentliche EHI-Dokumentation sieht einen expliziten Prüf-Workflow für die Lebensdosis-Historie nach dem Merge vor. Die Tabelle PAT_LIFEDOSE_HX verfügt über dedizierte Spalten für wer den Eintrag nach Merge/Unmerge geprüft hat, wann und ein Prüfgrund-Enum, das Patient Merge, Patient Unmerge, Patient Contact Move mit den Status Need Review, Accepted, Rejected umfasst. Bei kumulativen klinischen Berechnungen gilt die automatisierte Verteilung als unsicher – ein Mensch muss beurteilen, was wohin gehört.

Der gemeinsame Nenner: Einige Post-Merge-Artefakte können nicht in derselben Transaktion umgeschrieben werden. Sie benötigen eine Neubewertung (MDM-Verknüpfungsgraph), eine Weiterleitung in eine Prüfwarteschlange (kumulative Dosis) oder einen Abgleich mit externen Systemen, die die alte Identität gecacht haben. Ein Server, der Merge als „Referenzen umschalten und weitermachen" behandelt, lässt diese Klasse von Arbeiten stillschweigend unerledigt.

Wo die Grenze liegt

Man beachte das Muster. Serverseitiges Merge möchte ein einziger Algorithmus sein. Die Realität besteht aus mindestens vier unabhängigen Richtlinienachsen, jede mit mehreren tatsächlich ausgelieferten Varianten. Das ist eine kombinatorische Explosion, bevor regulatorische Auflagen überhaupt ins Spiel kommen.

Der Ausweg liegt nicht in einem intelligenteren Server. Er liegt darin, die Richtlinie dorthin zu verlagern, wo sie hingehört – zum Client. In unserem $merge sendet der Client ein Transaction Bundle, das jeden PUT, POST und DELETE beschreibt. Der Server ist für die Invarianten zuständig: Atomarität, Audit, Anti-Circular-Merge-Prüfungen, optimistisches Locking über ifMatch. Der Client ist für die Richtlinie zuständig: welche Felder überleben, wie Referenzen umgeschrieben werden, was mit der Quelle passiert und welche nachgelagerten Arbeiten in eine Prüfwarteschlange weitergeleitet werden müssen.

Der Audit-Trail ist kein Nice-to-have. Das Patientenidentifikations-Toolkit von ECRI und die Dokumentationsregeln von CMS verlangen effektiv denselben Nachweis: wer den Merge durchgeführt hat, wann, warum, einen Vor-Merge-Schnappschuss beider Datensätze und die Liste der betroffenen Ressourcen. Auf FHIR abgebildet bedeutet das: ein Task (Operation, Akteur, Grund, verknüpfte Quelle/Ziel), ein Provenance-Eintrag für jede berührte Ressource und die FHIR History API für den Vor-Merge-Schnappschuss – alles in derselben Transaktion wie der Merge selbst geschrieben. Wird irgendetwas davon auf mehrere Transaktionen verteilt, ist der Audit-Trail kein einheitlicher Nachweis mehr.

Unmerge stellt dieselbe Frage auf einer höheren Ebene. Wenn der Merge am Montag stattfand und am Dienstag drei neue Encounters auf den Zieldatensatz gebucht wurden, wohin gehen diese am Mittwoch – zurück zum wiederhergestellten Quelldatensatz, verteilt oder auf dem Zieldatensatz belassen? Wenn die Quelle hart gelöscht wurde, kann sie überhaupt neu erstellt werden? Es gibt keine allgemeine Antwort. Daher spiegelt unser $unmerge das $merge: Der Server ist für Invarianten zuständig, der Client für die Richtlinie – das einzige Design, das wir in dieser Größenordnung sicher gestalten können. Den vollständigen Entwurf beschreiben wir in Designing $unmerge: Reversing the FHIR Patient Merge. Hintergrundinformationen zur zugrunde liegenden Matching- und Master Patient Index-Mechanik finden Sie unter Master Patient Index (MPI): How It Works + Examples.

Möchten Sie clientgesteuertes Merge in Ihrem Projekt ausprobieren? MDMbox ist ab sofort verfügbar.