---
{
  "title": "MPI-Anbieter waren sich uneinig. Wir haben Patient Merge gelöst",
  "description": "FHIR's Patient/$merge setzt voraus, dass der Server weiß, wie er zusammenführen soll. Zwei Jahrzehnte MPI-Anbieterkonfigurationen, divergierende EHR-Anbieter und nationale Registry-Richtlinien zeigen, warum ein einziger Algorithmus nicht jede Organisation bedienen kann.",
  "date": "2026-04-20",
  "author": "Ivan Shukshin",
  "reading-time": "8 min read",
  "tags": ["FHIR Standard", "Aidbox", "System Design", "Integrations", "MDMbox"],
  "tldr": "Die Merge-Logik variiert organisationsübergreifend stark entlang von vier Achsen – Survivorship, Referenzbehandlung, Quelldatensatz-Disposition und nachgelagerte Auswirkungen – und diese Variation ist strukturell bedingt, nicht zufällig. MPI-Anbieter stellen Merge als konfigurierbare Richtlinie bereit, EHR-Anbieter implementieren inkompatible Standards, und nationale Patientenregistries verfolgen grundlegend unterschiedliche Ansätze. Ein einziges servergesteuertes $merge kann all diesen Anforderungen nicht gerecht werden. Die Operation muss anpassbar sein: Der Server ist für die Invarianten zuständig (Atomarität, Audit, Lebenszyklus), der Client für die Richtlinie. Das ist die Gestaltung, die wir für MDMbox gewählt haben."
}
---
Nach zwei Jahrzehnten Arbeit hat das [IHE PIX/PDQ-Komitee](https://profiles.ihe.net/ITI/TF/Volume1/ch-5.html) 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](https://www.contextcapability.com/capabilities/duplicate-record-detection-merger) 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](/blog/beyond-patient-merge) 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](/articles/fhir-r4-vs-fhir-r5-choosing-the-right-version-for-your-implementation) definiert [`Patient/$merge`](https://hl7.org/fhir/R5/patient-operation-merge.html) 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](https://www.ibm.com/docs/en/imdm/11.6.0?topic=data-understanding-merge-party-survivorship-rules) 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](https://verato.com/platform/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](https://smilecdr.com/docs/mdm/mdm_survivorship.html). 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.

![Survivorship strategies](survivorship-strategies.svg)

Die Kosten, wenn die Richtlinie falsch liegt, sind unmittelbar. Ein [AHRQ PSNet-Fall](https://psnet.ahrq.gov/web-mm/patient-allergies-and-electronic-health-records) 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](https://docs.oracle.com/en/industries/health/millennium-platform-apis/mfrap/op-patientid-get.html) zurück und dokumentiert, dass das Aufheben der Zusammenführung unterstützt wird.
- **VistA (VA)** [verschiebt Daten vom FROM- zum TO-Datensatz](https://www.va.gov/vdl/documents/Infrastructure/Dupl_Rec_Merge/xt_73_um_r.pdf), 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](https://www.commonwellalliance.org/wp-content/uploads/2022/07/CommonWell-Services-Specification_v2.15.pdf) 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](https://digital.nhs.uk/services/personal-demographics-service/national-back-office-for-the-personal-demographics-service/data-quality-incidents), und die [API-Dokumentation beschreibt, wie abgelöste NHS-Nummern eine Ersatznummer zurückgeben](https://digital.nhs.uk/developer/api-catalogue/personal-demographics-service-fhir/pds-fhir-technical-conformance---application-restricted-access-mode).

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.

![Reference handling approaches](reference-handling.svg)

### 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](https://build.fhir.org/ig/HL7/admin-incubator/branches/main/en/OperationDefinition-Patient-merge.html)-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](https://www.ibm.com/docs/SSWSR9_12.0.0/com.ibm.mdshs.hubover.doc/topics/c_hubover_merging_records.html) 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.

![Source disposition options](source-disposition.svg)

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](https://www.techtarget.com/searchhealthit/feature/How-the-MATCH-IT-Act-aims-to-reduce-patient-misidentification) 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](https://www.ibm.com/docs/SSWSR9_12.0.0/com.ibm.mdshs.hubover.doc/topics/c_hubover_merging_records.html)** 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](https://open.epic.com/EHITables/GetTable/PAT_LIFEDOSE_HX.htm) 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`](/blog/beyond-patient-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](/articles/designing-unmerge-fhir-patient). Hintergrundinformationen zur zugrunde liegenden Matching- und Master Patient Index-Mechanik finden Sie unter [Master Patient Index (MPI): How It Works + Examples](/articles/master-patient-index-and-record-linkage).

---

*Möchten Sie clientgesteuertes Merge in Ihrem Projekt ausprobieren? [MDMbox](https://www.health-samurai.io/mdmbox) ist ab sofort verfügbar.*