--- { "title": "Linkage vs. Merge in der Patientenidentitätsverwaltung", "description": "Ein Abgleich stellt lediglich fest, dass zwei Datensätze zur selben Person gehören könnten. Ob diese verknüpft oder zusammengeführt werden sollen, ist eine separate Entscheidung – und eine fehlerhafte Zusammenführung ist weitaus schwerer rückgängig zu machen als ein übersehener Treffer.", "date": "2026-09-29", "author": "Valeria Fursa", "reading-time": "12 min read", "tags": ["FHIR Standard", "Master Data Management", "Data Quality", "Compliance", "MDMbox"], "tldr": "Der Abgleich findet Kandidaten – er entscheidet nicht, was mit ihnen geschieht. Linkage behält beide Datensätze, bleibt reversibel und bewahrt den Quellkontext. Merge konsolidiert sie, leitet alle Referenzen um und erzwingt die Auflösung von Konflikten. Ein falsch positives Ergebnis kann klinische Daten eines Patienten in den Datensatz einer anderen Person einbringen, mit möglichen HIPAA-Verletzungsfolgen. Verknüpfen Sie, wenn die Dateneigentümerschaft aufgeteilt ist, wenn das Konfidenzniveau den Schwellenwert nicht erreicht oder wenn eine kombinierte Ansicht die Anforderung bereits erfüllt. Führen Sie nur zusammen, wenn ein einziger physischer Datensatz operativ notwendig ist und die dafür erforderlichen Kontrollen tatsächlich vorhanden sind: Survivorship-Regeln, Audit, Unmerge und Downstream-Propagierung.", "utm-campaign": "fhir_expert", "utm-content": "linkage-vs-merge" } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- ## Was sollte passieren, nachdem ein MPI einen Patientenabgleich gefunden hat? Ein MPI hat zwei Datensätze als wahrscheinliche Übereinstimmung identifiziert. Das System kann beide Datensätze behalten und eine Beziehung zwischen ihnen herstellen oder einen Datensatz in einen anderen konsolidieren. Diese Aktionen werden manchmal als aufeinanderfolgende Schritte desselben Prozesses betrachtet. In der Praxis identifiziert der Abgleich lediglich Datensätze, die zur selben Person gehören könnten. Er bestimmt nicht, was als Nächstes mit ihnen geschehen soll. ![Patient identity workflow after a match. Matching compares two patient records and returns a confidence score without changing any data. The workflow then branches to one of two alternative outcomes: Linkage, which connects both records through an enterprise patient identity while keeping the source records available and the action reversible; or Merge, which consolidates the source record into a target record and requires references and conflicting values to be resolved.](image-1.png "Der Abgleich liefert Kandidaten und ändert nichts. Was als Nächstes geschieht – Linkage oder Merge – ist eine separate Entscheidung.") Mit Linkage können Anwendungen verwandte Datensätze abrufen, Bezeichner systemübergreifend zuordnen und eine longitudinale Patientenansicht erstellen, während die Originaldatensätze unverändert bleiben. Merge verändert die Datensätze selbst. Der Zieldatensatz wird zur aktiven Patientenidentität, Referenzen auf den Quelldatensatz müssen umgeleitet werden, und widersprüchliche Werte müssen aufgelöst werden. Wann ist also eine Verknüpfung ausreichend, und wann erfordert ein Patientenidentitäts-Workflow eine Zusammenführung? Die Antwort hängt von der Übereinstimmungskonfianz, der Dateneigentümerschaft, der Herkunft, den nachgelagerten Workflows und davon ab, was passiert, wenn sich die Entscheidung als falsch herausstellt. ## Warum eine fehlerhafte Zusammenführung nicht gleichbedeutend ist mit einem übersehenen Treffer Ein falsch negativer Befund lässt Datensätze derselben Person getrennt. Die Patientenhistorie kann unvollständig bleiben, aber die Daten sind weiterhin den ursprünglichen Identitäten zugeordnet. Ein falsch positiver Befund hat eine andere Wirkung. Sobald Datensätze, die zwei verschiedenen Personen gehören, zusammengeführt werden, können ihre demografischen, administrativen und klinischen Informationen Teil derselben Patientenidentität werden. Der [ONC Patient Identification and Matching Final Report](https://www.healthit.gov/wp-content/uploads/2017/09/patient_identification_matching_final_report.pdf) beschreibt falsch positive Treffer als ein größeres Patientensicherheitsrisiko als übersehene Treffer, da die Versorgung möglicherweise auf der Grundlage von Informationen erfolgt, die einer anderen Person gehören. Diese Asymmetrie ist ein Grund dafür, dass Abgleichsysteme häufig so konfiguriert werden, dass sie einige ungelöste Duplikate tolerieren, anstatt die Anzahl der Überlagerungen zu erhöhen. ### Patient Overlay Ein Overlay tritt auf, wenn Informationen, die zwei Patienten gehören, in einer Krankenakte vermischt werden. Der resultierende Datensatz kann die folgenden Angaben einer anderen Person enthalten: - Allergien; - Medikamente; - Diagnosen; - Laborbefunde; - Blutgruppe; - Prozeduren. Fehlerhafte klinische Informationen können Behandlungsentscheidungen beeinflussen. Die Zusammenführung kann außerdem einem Patienten über ein Patientenportal, eine Offenlegungsanfrage oder eine identitätsbasierte Zugriffsregel Zugang zu den geschützten Gesundheitsinformationen einer anderen Person verschaffen. Wenn eine fehlerhafte Zusammenführung zu einem unbefugten Zugriff auf oder einer unbefugten Offenlegung von PHI führt, muss der Vorfall möglicherweise im Rahmen der [HIPAA Breach Notification Rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html) bewertet werden. Gemäß [45 CFR Part 164](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164) gilt eine unzulässige Verwendung oder Offenlegung von PHI als Datenschutzverletzung, sofern die betroffene Stelle oder der Geschäftspartner nicht nachweisen kann, dass eine geringe Wahrscheinlichkeit besteht, dass die Informationen kompromittiert wurden. Die Konsequenzen können daher über Datenqualität und klinische Sicherheit hinausgehen und Untersuchungs-, Benachrichtigungs- und Abhilfeverpflichtungen umfassen. ### Unmerge Die Reaktivierung des Quelldatensatzes stellt nicht notwendigerweise den Zustand wieder her, der vor der Zusammenführung bestand. Das Korrektionsteam muss möglicherweise Begegnungen, Beobachtungen, Dokumente, Abrechnungen und andere Ressourcen prüfen, um festzustellen, welchem Patienten jede Information gehörte. Einige Systeme unterstützen das Unmerge nur durch einen manuellen Prozess. Andere erfordern, dass die Originaldatensätze aus der Prüfungshistorie rekonstruiert werden. Die Nachvollziehbarkeit muss daher von Anfang an in den Merge-Workflow integriert sein. Die Organisation muss in der Lage sein, den Quell- und Zieldatensatz, die geänderten Werte, die Person, die die Aktion genehmigt hat, und die für die Entscheidung verwendeten Nachweise zu identifizieren. ### Downstream-Propagierung Aktualisierungen der Patientenidentität können von EHRs, Labors, Abrechnungssystemen, Patientenportalen, Analyseumgebungen und Payer-Anwendungen empfangen werden. Eine fehlerhafte Zusammenführung kann diese Systeme weiterhin beeinflussen, nachdem der MPI korrigiert wurde. Jeder Empfänger benötigt eine Möglichkeit, die Korrektur zu verarbeiten und zu bestimmen, welche zuvor empfangenen Daten geändert werden müssen. Je weiter die Patientenidentität verteilt ist, desto weniger sinnvoll ist es, Merge als lokale Datenbankoperation zu behandeln. ## Wann Patientendatensätze getrennt bleiben sollten Die Risiken einer Zusammenführung bedeuten nicht, dass jede Übereinstimmung ungelöst bleiben sollte. Sie bedeuten, dass die Erkennung einer Person über Datensätze hinweg und die physische Konsolidierung dieser Datensätze als separate Entscheidungen behandelt werden sollten. ### Der Abgleich ist noch nicht eindeutig Probabilistische Abgleichverfahren unterteilen Ergebnisse häufig in eindeutige Treffer, mögliche Treffer und Nicht-Treffer. Ein eindeutiger Treffer kann für eine automatische Verarbeitung im Rahmen einer genehmigten Richtlinie qualifiziert sein. Ein möglicher Treffer erfordert eine zusätzliche Überprüfung. Während der Fall geprüft wird, bleiben beide Datensätze verfügbar. Ein Data Steward kann Bezeichner, demografische Attribute, fehlende Werte, Zuverlässigkeit der Quelle und frühere Identitätsereignisse prüfen, ohne zuvor Daten trennen zu müssen, die bereits zusammengeführt wurden. Der Prüfer kann den Treffer bestätigen, ablehnen oder den Fall ungelöst lassen. Die Bestätigung stellt fest, dass die Datensätze zur selben Person gehören. Sie erfordert an sich keine physische Konsolidierung. ### Die Datensätze gehören verschiedenen Organisationen Ein HIE, ein Labornetz, eine Krankenhausgruppe oder ein Payer-Provider-Austausch muss möglicherweise erkennen, dass mehrere lokale Bezeichner auf dieselbe Person verweisen. Jeder Teilnehmer verwaltet weiterhin seinen eigenen Patientendatensatz und bleibt für seine Daten verantwortlich. Ein gemeinsamer Identitätsdienst kann die Bezeichner zuordnen und verwandte Informationen abrufen, ohne die Eigentümerschaft an den Quelldatensätzen zu übertragen. Das [IHE Patient Identifier Cross-referencing profile (PIX)](https://profiles.ihe.net/ITI/TF/Volume1/ch-5.html), das [Patient Demographics Query profile (PDQ)](https://profiles.ihe.net/ITI/TF/Volume1/ch-8.html) und das [Cross-Community Patient Discovery profile (XCPD)](https://profiles.ihe.net/ITI/TF/Volume1/ch-27.html) befassen sich mit der Patientenidentifikation und der Cross-Referenzierung innerhalb und zwischen Gesundheitsversorgungsgemeinschaften. Die [ONC Interoperability Standards Platform](https://isp.healthit.gov/exchanging-patient-identification-within-and-between-communities) listet diese Profile als produktionsreife Ansätze für den Austausch von Patientenidentitätsinformationen auf. Ohne einen Governance-Rahmen, der die Konsolidierung ausdrücklich genehmigt, sollte ein organisationsübergreifender Abgleich zu einer Verknüpfung und nicht zu einer Zusammenführung führen. ### Der Quellkontext muss erhalten bleiben Patienteninformationen können aus Systemen mit unterschiedlichen Autoritäts-, Vollständigkeits- und Zuverlässigkeitsniveaus stammen. Eine Quelle kann einen verifizierten amtlichen Namen enthalten. Eine andere kann eine aktuellere Adresse oder Telefonnummer aufweisen. Die Datensätze getrennt zu halten ermöglicht es, diese Werte gemeinsam anzuzeigen und dabei festzuhalten, woher jeder Wert stammt, wann er empfangen wurde und welche Organisation ihn geliefert hat. Dies unterstützt auf natürliche Weise Herkunfts- und Prüfanforderungen. Ein zusammengeführter Datensatz kann die Herkunft ebenfalls bewahren, aber die Implementierung muss diese explizit speichern, nachdem die ursprünglichen Quellgrenzen aufgehoben wurden. ### Der Workflow benötigt lediglich eine kombinierte Ansicht Ein MPI nach Registry-Art ordnet eine Enterprise-Identität den Patientenbezeichnern zu, die von einzelnen Quellsystemen verwendet werden. Anwendungen können diese Verknüpfungen nutzen, um verwandte Datensätze zu finden und als longitudinale Patientenansicht darzustellen. Die Quellsysteme bleiben unverändert, und der MPI wird nicht zum transaktionalen Eigentümer ihrer klinischen Daten. Dieses Modell kann Record Discovery, Analysen, Versorgungskoordination und systemübergreifenden Zugriff unterstützen, ohne einen einzigen physischen Patientendatensatz zu erstellen. Der [ONC-Bericht über Master Data Management in HIE-Infrastrukturen](https://www.healthit.gov/wp-content/uploads/2013/01/master_data_management_final.pdf) beschreibt diese Verwendung eines Master-Bezeichners zur Verbindung lokaler Patientenidentitäten in verteilten Systemen. ## Wann ein einziger physischer Datensatz notwendig wird Linkage funktioniert, solange verarbeitende Anwendungen mit mehreren verbundenen Datensätzen arbeiten können. Es ist nicht mehr ausreichend, wenn ein operativer Prozess eine einzige aktive Patientenidentität erfordert. Ein Duplikat innerhalb eines EHR kann beispielsweise die Abrechnung, transaktionale Aktualisierungen, identitätsbasierten Zugriff oder die Pflege eines zentralisierten Systems of Record beeinträchtigen. In diesem Fall löst das gemeinsame Abrufen verwandter Datensätze das Problem nicht. Das Duplikat selbst muss entfernt werden. Vor dem Fortfahren muss die Organisation drei Dinge feststellen: 1. Sie hat die Befugnis, beide Datensätze zu konsolidieren. 2. Es wurde bestätigt, dass die Datensätze zur selben Person gehören. 3. Eine verknüpfte Ansicht kann die operative Anforderung nicht erfüllen. Der eindeutigste Fall für eine Zusammenführung ist ein bestätigtes Duplikat innerhalb eines EHR, MPI oder eines anderen Systems, das von derselben Organisation kontrolliert wird. Ein zweiter Datensatz kann aufgrund eines Schreibfehlers, unvollständiger Registrierungsdaten, eines fehlenden Bezeichners oder einer doppelten Registrierung während einer Notfallaufnahme erstellt worden sein. Sobald das Duplikat bestätigt wurde, können beide Datensätze zu halten Prozesse weiterhin stören, die von einer einzigen Patienten-ID abhängen. Organisationsübergreifende Zusammenführungen sind ein separater Fall. Sie erfordern einen vereinbarten Governance-Rahmen, der die Eigentümerschaft an der resultierenden Identität, die Zusammenführungsbefugnis und die von den beteiligten Systemen erwarteten Maßnahmen definiert. Das [IHE Patient Master Identity Registry profile (PMIR)](https://profiles.ihe.net/ITI/PMIR/) beschreibt einen Workflow, in dem mehrere Master-Identitäten zu einer Golden Patient Identity konsolidiert werden und die Entscheidung an die Dateneigentümer verteilt wird. Ohne diese Art von Governance bleibt das organisationsübergreifende Identitätsmanagement ein Anwendungsfall für Linkage. ## Was vor einer Zusammenführung geklärt werden muss Sobald eine physische Konsolidierung gerechtfertigt ist, muss das Team bestimmen, wie die Zusammenführung die Patientenidentität und die damit verbundenen Daten verändern wird. ### Quelle und Ziel auswählen Ein Datensatz wird zur Zielidentität. Der andere wird zur Quelle, die ersetzt oder inaktiviert wird. Das Ziel sollte nicht allein deshalb ausgewählt werden, weil es zuerst erstellt wurde. Die Entscheidung kann auch davon abhängen, welche Bezeichner bereits in Verwendung sind, die Autorität und Vollständigkeit jedes Datensatzes und die Systeme, die auf sie verweisen. ### Survivorship-Regeln definieren Bestätigte doppelte Datensätze können dennoch unterschiedliche Namen, Bezeichner, Adressen, Telefonnummern und demografische Attribute enthalten. Survivorship-Regeln bestimmen, welche Werte in den Zieldatensatz geschrieben werden. Sie können priorisieren: - eine autoritativere Quelle; - einen verifizierten Wert; - den aktuellsten Wert; - den vollständigeren Datensatz; - eine Entscheidung eines Data Stewards. Werte, die nicht übernommen werden, sollten über die Ressourcenhistorie, die Herkunft oder einen anderen Prüfmechanismus verfügbar bleiben. Andernfalls kann es unmöglich sein zu erklären, wie der Zieldatensatz erstellt wurde, oder den Zustand vor der Zusammenführung zu rekonstruieren. Bei Linkage müssen diese Konflikte nicht sofort gelöst werden. Jeder Wert verbleibt in seinem Quelldatensatz und kann mit seinem ursprünglichen Kontext dargestellt werden. ### Referenzen umleiten Klinische, administrative und finanzielle Daten können bereits auf den Quelldatensatz verweisen. Eine Zusammenführung muss diese Referenzen identifizieren und auf das Ziel umleiten. Der Umfang kann über die im MPI gespeicherten Daten hinaus auf verbundene Anwendungen ausgedehnt werden, die die Identität bereits empfangen oder kopiert haben. ### Auf Korrekturen vorbereiten Die Organisation muss verstehen, was ihre Systeme automatisch rückgängig machen können und was nicht. Ein Korrekturprozess sollte Folgendes definieren: - wie eine fehlerhafte Zusammenführung erkannt und untersucht wird; - wer entscheidet, welche Daten jedem ursprünglichen Patienten gehören; - wie der Zustand vor der Zusammenführung rekonstruiert wird; - wie nachgelagerte Systeme die Korrektur erhalten; - wie Datenschutz- und Patientensicherheitsvorfälle behandelt werden. Diese Kontrollen sind Teil der Merge-Bereitschaft und kein Thema, das erst nach dem ersten Fehler konzipiert werden sollte. ## Einen Treffer von der Erkennung zur Zusammenführung führen Ein kontrollierter Patientenidentitäts-Workflow trennt Kandidatengenerierung, Identitätsbestätigung und physische Konsolidierung. ### 1. Kandidaten finden Die Abgleich-Engine vergleicht Bezeichner und demografische Attribute und gibt Datensätze zurück, die zur selben Person gehören könnten. Das Ergebnis sollte die beim Abgleich verwendeten Nachweise und gegebenenfalls einen Konfidenzwert enthalten. ### 2. Das Ergebnis klassifizieren Jeder Kandidat wird einer operativen Kategorie zugeordnet: - eindeutiger Treffer; - möglicher Treffer; - kein Treffer. Die Organisation definiert die Schwellenwerte und die für jede Kategorie zulässigen Aktionen. ### 3. Unsichere Fälle prüfen Mögliche Treffer bleiben getrennt und werden in eine Stewardship-Warteschlange eingereiht. Der Prüfer untersucht die verfügbaren Nachweise und bestätigt den Treffer, lehnt ihn ab oder lässt den Fall ungelöst. ### 4. Die Identitätsaktion auswählen Ein bestätigter Treffer kann verknüpft bleiben, wenn der Workflow lediglich Zugriff auf verwandte Datensätze benötigt. Der Fall schreitet zur Zusammenführung fort, wenn die Konsolidierung autorisiert ist und ein Prozess eine einzige aktive Patientenidentität erfordert. ### 5. Merge-Kontrollen anwenden Vor der Konsolidierung wählt das Team den Zieldatensatz aus, wendet Survivorship-Regeln an, bewahrt die Entscheidungshistorie und identifiziert betroffene nachgelagerte Systeme. Der Workflow lässt sich wie folgt zusammenfassen: **Abgleich → Klassifizieren → Bei Bedarf prüfen → Verknüpfen oder Zusammenführen** Linkage ist das geeignete Ergebnis für unsichere Fälle, verteilte Dateneigentümerschaft und Workflows, die lediglich eine kombinierte Ansicht benötigen. Merge ist reserviert für bestätigte Fälle, in denen ein einziger physischer Datensatz operativ notwendig ist. ## Patientenabgleich, Linkage und Merge in FHIR FHIR stellt für jeden Teil des Workflows einen separaten Mechanismus bereit. ### [`Patient/$match`](https://fhir.hl7.org/fhir/operation-patient-match.html) `Patient/$match` akzeptiert Patientenidentitätsinformationen und gibt Kandidaten-Patient-Ressourcen zurück. Implementierungen können einen Wert von 0 bis 1 einbeziehen, der die Konfidenz jedes Ergebnisses darstellt. Der Wert kann dann anhand der Schwellenwerte der Organisation bewertet werden. ### [`Patient.link`](https://fhir.hl7.org/fhir/patient-definitions.html#Patient.link) `Patient.link` erfasst eine Beziehung zwischen Patient-Ressourcen, die auf dieselbe reale Person verweisen. Die Ressourcen bleiben getrennt und behalten ihre ursprünglichen Bezeichner und Daten. Dies macht `Patient.link` geeignet für Cross-References, MPI-Implementierungen nach Registry-Art und Beziehungen, die möglicherweise überprüft oder aufgehoben werden müssen. FHIR definiert vier [Patient link types](https://fhir.hl7.org/fhir/valueset-link-type.html): `replaced-by`, `replaces`, `refer` und `seealso`. ### [`Patient/$merge`](https://fhir.hl7.org/fhir/patient-operation-merge.html) `Patient/$merge` konsolidiert eine Quell-Patient-Ressource in eine Ziel-Patient-Ressource. Referenzen auf die Quelle werden auf das Ziel umgeleitet. Die Quelle wird inaktiv, während `replaced-by`- und `replaces`-Verknüpfungen eine Spur der Beziehung zwischen den Ressourcen bewahren. FHIR trennt diese Mechanismen, weil die Bestätigung eines Patientenabgleichs nicht immer eine Konsolidierung der Datensätze erfordert. ## Den Workflow mit MDMbox verwalten MDMbox unterstützt Abgleich, Linkage, Stewardship und Merge als separate Teile des Patientenidentitäts-Workflows. Teams können `Patient/$match` verwenden, um Kandidaten zu finden und zu bewerten. Datensätze, die getrennt bleiben sollen, können über `Patient.link` verbunden werden, während mögliche Treffer zur Überprüfung weitergeleitet werden können. Wenn ein bestätigtes Duplikat konsolidiert werden muss, leitet `Patient/$merge` Referenzen auf das Ziel um und bewahrt die Beziehung zwischen den Patient-Ressourcen. Die Organisation definiert die Richtlinien hinter diesen Aktionen, einschließlich Abgleichschwellenwerte, Zusammenführungsbefugnis, Stewardship-Verantwortlichkeiten, Survivorship-Regeln und die Systeme, die Identitätsaktualisierungen erhalten müssen. ## Einen Workflow prüfen, bevor Merge aktiviert wird Die **Checkliste „Patientenidentität: Verknüpfen oder Zusammenführen?"** hilft Teams dabei zu bestimmen, ob ein Workflow Linkage, eine Stewardship-Überprüfung oder eine physische Konsolidierung erfordert. Der erste Teil behandelt Eigentümerschaft, Abgleichkonfidenz und die Notwendigkeit eines einzigen Patientendatensatzes. Der zweite prüft, ob die erforderlichen Merge-Kontrollen vorhanden sind. {% button href="#get-the-checklist" arrow="false" %}Checkliste herunterladen{% endbutton %}