Was sollte geschehen, nachdem ein MPI einen Patienten-Match gefunden hat?
Ein MPI hat zwei Datensätze als wahrscheinlichen Treffer identifiziert. Das System kann beide Datensätze behalten und eine Beziehung zwischen ihnen herstellen oder einen Datensatz in den anderen konsolidieren.
Diese Aktionen werden manchmal als aufeinanderfolgende Schritte desselben Prozesses betrachtet. In der Praxis identifiziert Matching lediglich Datensätze, die zur selben Person gehören könnten. Es legt nicht fest, was als Nächstes mit ihnen geschehen soll.
Mit Linkage können Anwendungen verwandte Datensätze abrufen, Identifikatoren systemübergreifend zuordnen und eine longitudinale Patientenansicht aufbauen, 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 Konflikte bei Werten müssen aufgelöst werden.
Wann ist also eine Verknüpfung ausreichend, und wann erfordert ein Patient-Identity-Workflow einen Merge? Die Antwort hängt von der Match-Konfidenz, der Datenzuständigkeit, der Provenienz, den nachgelagerten Workflows und den Konsequenzen einer fehlerhaften Entscheidung ab.
Warum ein fehlerhafter Merge nicht gleichbedeutend ist mit einem übersehenen Treffer
Ein falsch-negativer Treffer lässt Datensätze derselben Person getrennt. Die Patientenhistorie bleibt möglicherweise unvollständig, die Daten sind jedoch weiterhin den ursprünglichen Identitäten zugeordnet.
Ein falsch-positiver Treffer hat eine andere Wirkung. Sobald Datensätze zweier Personen zusammengeführt werden, können deren demografische, administrative und klinische Informationen Teil derselben Patientenidentität werden.
Der ONC Patient Identification and Matching Final Report beschreibt falsch-positive Treffer als ein größeres Patientensicherheitsrisiko als übersehene Treffer, da Versorgungsmaßnahmen auf Grundlage von Informationen einer anderen Person eingeleitet werden könnten. Diese Asymmetrie ist ein Grund dafür, dass Matching-Systeme häufig so konfiguriert werden, dass sie einige ungelöste Duplikate tolerieren, anstatt die Anzahl der Overlays zu erhöhen.
Patient-Overlay
Ein Overlay entsteht, wenn Informationen zweier Patienten in einem einzigen Datensatz vermischt werden.
Der entstehende Datensatz kann Informationen eines anderen Patienten enthalten, darunter:
- Allergien;
- Medikationen;
- Diagnosen;
- Laborbefunde;
- Blutgruppe;
- Prozeduren.
Fehlerhafte klinische Informationen können Behandlungsentscheidungen beeinflussen. Der Merge kann einem Patienten außerdem Zugang zu geschützten Gesundheitsdaten (PHI) einer anderen Person ermöglichen – über ein Patientenportal, eine Offenlegungsanfrage oder eine identitätsbasierte Zugriffsregel.
Wenn ein fehlerhafter Merge zu einem unberechtigten Zugriff auf oder einer unberechtigten Offenlegung von PHI führt, muss der Vorfall möglicherweise gemäß der HIPAA Breach Notification Rule bewertet werden. Nach 45 CFR Part 164 gilt eine unzulässige Nutzung oder Offenlegung von PHI als Breach, sofern die verantwortliche Stelle oder der Geschäftspartner nicht nachweist, dass eine geringe Wahrscheinlichkeit der Kompromittierung der Daten besteht.
Die Konsequenzen können daher über Datenqualität und klinische Sicherheit hinausgehen und Untersuchungs-, Melde- und Behebungspflichten nach sich ziehen.
Unmerge
Die Reaktivierung des Quelldatensatzes stellt nicht notwendigerweise den Zustand vor dem Merge wieder her.
Das Korrektiv-Team muss möglicherweise Encounters, Beobachtungen, Dokumente, Abrechnungen und weitere Ressourcen prüfen, um zu bestimmen, welchem Patienten jeder Eintrag ursprünglich gehörte. Einige Systeme unterstützen Unmerge nur durch einen manuellen Prozess. Andere erfordern die Rekonstruktion der Originaldatensätze aus der Audit-Historie.
Auditierbarkeit muss daher von Anfang an in den Merge-Workflow integriert werden. Die Organisation muss in der Lage sein, den Quell- und Zieldatensatz, die geänderten Werte, die genehmigungspflichtige Person und die der Entscheidung zugrunde liegenden Nachweise zu identifizieren.
Downstream-Propagation
Aktualisierungen der Patientenidentität können von EHRs, Laboren, Abrechnungssystemen, Patientenportalen, Analyseumgebungen und Payer-Anwendungen konsumiert werden.
Ein fehlerhafter Merge kann diese Systeme weiterhin beeinflussen, nachdem der MPI korrigiert wurde. Jeder Empfänger benötigt eine Möglichkeit, die Korrektur zu verarbeiten und festzustellen, 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 eines Merge bedeuten nicht, dass jeder Treffer ungelöst bleiben sollte. Sie bedeuten, dass das Erkennen einer Person über Datensätze hinweg und die physische Konsolidierung dieser Datensätze als separate Entscheidungen behandelt werden sollten.
Der Treffer ist noch nicht eindeutig
Probabilistisches Matching unterteilt Ergebnisse üblicherweise in eindeutige Treffer, mögliche Treffer und Nicht-Treffer.
Ein eindeutiger Treffer kann im Rahmen einer genehmigten Richtlinie für die automatische Verarbeitung qualifizieren. Ein möglicher Treffer erfordert eine zusätzliche Prüfung.
Während der Fall geprüft wird, bleiben beide Datensätze verfügbar. Ein Data Steward kann Identifikatoren, demografische Attribute, fehlende Werte, Quellenreliabilität 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 offen lassen. Eine Bestätigung stellt fest, dass die Datensätze zur selben Person gehören. Sie erfordert für sich genommen keine physische Konsolidierung.
Die Datensätze gehören zu verschiedenen Organisationen
Ein HIE, ein Labornetzwerk, eine Krankenhausgruppe oder ein Payer-Provider-Austausch muss möglicherweise erkennen, dass mehrere lokale Identifikatoren auf dieselbe Person verweisen.
Jeder Teilnehmer führt weiterhin seinen eigenen Patientendatensatz und bleibt für seine Daten verantwortlich. Ein gemeinsamer Identity-Service kann die Identifikatoren zuordnen und verwandte Informationen abrufen, ohne die Datenzuständigkeit der Quelldatensätze zu übertragen.
Das IHE Patient Identifier Cross-referencing-Profil (PIX), das Patient Demographics Query-Profil (PDQ) und das Cross-Community Patient Discovery-Profil (XCPD) adressieren die Patientenidentifikation und Cross-Referenzierung innerhalb und zwischen Healthcare-Communities. Die ONC Interoperability Standards Platform listet diese Profile als Produktionsansätze für den Austausch von Patientenidentitätsinformationen auf.
Ohne einen Governance-Rahmen, der eine Konsolidierung ausdrücklich genehmigt, sollte ein organisationsübergreifender Treffer zu einer Verknüpfung und nicht zu einem Merge führen.
Der Quellkontext muss erhalten bleiben
Patienteninformationen können aus Systemen mit unterschiedlichem Autoritätsniveau, unterschiedlichem Vollständigkeitsgrad und unterschiedlicher Verlässlichkeit stammen.
Eine Quelle kann einen verifizierten rechtlichen Namen enthalten. Eine andere kann eine aktuellere Adresse oder Telefonnummer aufweisen. Durch das Getrennthalten der Datensätze ist es möglich, diese Werte gemeinsam anzuzeigen und dabei zu erhalten, woher jeder Wert stammt, wann er empfangen wurde und welche Organisation ihn bereitgestellt hat.
Dies unterstützt auf natürliche Weise Provenienz- und Audit-Anforderungen. Ein zusammengeführter Datensatz kann Provenienz ebenfalls bewahren, aber die Implementierung muss diese explizit speichern, nachdem die ursprünglichen Quellgrenzen aufgehoben wurden.
Der Workflow benötigt nur eine kombinierte Ansicht
Ein registry-artiger MPI ordnet eine Enterprise-Identität den Patientenidentifikatoren der einzelnen Quellsysteme zu.
Anwendungen können diese Verknüpfungen nutzen, um verwandte Datensätze zu finden und sie 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, Care Coordination und systemübergreifenden Zugriff unterstützen, ohne einen einzigen physischen Patientendatensatz zu erstellen. Der ONC-Bericht über Master Data Management in HIE Infrastructures beschreibt diese Verwendung eines Master-Identifikators zur Verbindung lokaler Patientenidentitäten in verteilten Systemen.
Wann ein einziger physischer Datensatz notwendig wird
Linkage funktioniert, solange konsumierende Anwendungen mit mehreren verbundenen Datensätzen arbeiten können. Es reicht nicht mehr aus, wenn ein operativer Prozess eine einzige aktive Patientenidentität erfordert.
Ein Duplikat innerhalb eines einzelnen EHR kann beispielsweise die Abrechnung, transaktionale Aktualisierungen, identitätsbasierten Zugriff oder die Pflege eines zentralisierten System of Record beeinträchtigen. In diesem Fall löst das gemeinsame Abrufen verwandter Datensätze das Problem nicht. Das Duplikat selbst muss entfernt werden.
Bevor die Organisation voranschreitet, muss sie drei Dinge feststellen:
- Sie hat die Befugnis, beide Datensätze zu konsolidieren.
- Die Datensätze wurden als zur selben Person gehörend bestätigt.
- Eine verknüpfte Ansicht kann die betriebliche Anforderung nicht erfüllen.
Der eindeutigste Merge-Fall ist ein bestätigtes Duplikat innerhalb eines einzigen EHR, MPI oder anderen Systems, das von derselben Organisation kontrolliert wird.
Ein zweiter Datensatz kann aufgrund einer Schreibvariante, unvollständiger Registrierungsdaten, eines fehlenden Identifikators oder einer doppelten Registrierung während eines Notfallkontakts erstellt worden sein. Sobald das Duplikat bestätigt ist, kann das Führen beider Datensätze Prozesse weiterhin stören, die auf einer einzigen Patienten-ID basieren.
Organisationsübergreifender Merge ist ein gesonderter Fall. Er erfordert einen vereinbarten Governance-Rahmen, der die Zuständigkeit für die resultierende Identität, die Merge-Befugnis und die von beteiligten Systemen erwarteten Aktionen definiert.
Das IHE Patient Master Identity Registry-Profil (PMIR) beschreibt einen Workflow, bei dem mehrere Master-Identitäten zu einer Golden Patient Identity konsolidiert werden und die Entscheidung an die Dateneigentümer weitergegeben wird. Ohne diese Art von Governance bleibt das organisationsübergreifende Identity Management ein Linkage-Anwendungsfall.
Was vor einem Merge geklärt werden muss
Sobald die physische Konsolidierung gerechtfertigt ist, muss das Team bestimmen, wie der Merge die Patientenidentität und die damit verbundenen Daten verändern wird.
Quelle und Ziel auswählen
Ein Datensatz wird zum Ziel-Identitätsdatensatz. Der andere wird zur Quelle, die ersetzt oder inaktiviert wird.
Der Zieldatensatz sollte nicht allein deshalb ausgewählt werden, weil er zuerst erstellt wurde. Die Entscheidung kann auch davon abhängen, welche Identifikatoren bereits in Gebrauch sind, die Autorität und Vollständigkeit jedes Datensatzes sowie die Systeme, die auf sie referenzieren.
Survivorship-Regeln definieren
Bestätigte Duplikat-Datensätze können dennoch unterschiedliche Namen, Identifikatoren, Adressen, Telefonnummern und demografische Attribute enthalten.
Survivorship-Regeln legen fest, welche Werte in den Zieldatensatz übernommen werden. Sie können priorisieren:
- eine autoritative 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, Provenienz oder einen anderen Audit-Mechanismus weiterhin zugänglich sein. Andernfalls kann es unmöglich sein zu erklären, wie der Zieldatensatz entstanden ist, oder den Zustand vor dem Merge zu rekonstruieren.
Bei Linkage müssen diese Konflikte nicht sofort aufgelö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 Quellpatienten referenzieren.
Ein Merge muss diese Referenzen identifizieren und auf den Zieldatensatz umleiten. Der Umfang kann über die im MPI gespeicherten Daten hinausgehen und verbundene Anwendungen einschließen, die die Identität bereits empfangen oder kopiert haben.
Vorbereitung auf Korrekturen
Die Organisation muss verstehen, was ihre Systeme automatisch rückgängig machen können und was nicht.
Ein Korrekturprozess sollte definieren:
- wie ein fehlerhafter Merge erkannt und untersucht wird;
- wer entscheidet, welche Daten zu welchem ursprünglichen Patienten gehören;
- wie der Zustand vor dem Merge rekonstruiert wird;
- wie nachgelagerte Systeme die Korrektur erhalten;
- wie Datenschutz- und Patientensicherheitsvorfälle behandelt werden.
Diese Kontrollen sind Bestandteil der Merge-Bereitschaft und keine Maßnahmen, die erst nach dem ersten Fehler konzipiert werden sollten.
Einen Treffer von der Erkennung zum Merge führen
Ein kontrollierter Patient-Identity-Workflow trennt Kandidatengenerierung, Identitätsbestätigung und physische Konsolidierung voneinander.
1. Kandidaten finden
Die Matching-Engine vergleicht Identifikatoren und demografische Attribute und gibt Datensätze zurück, die zur selben Person gehören könnten.
Das Ergebnis sollte die beim Matching verwendeten Nachweise und – soweit zutreffend – 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-Queue eingereiht.
Der Prüfer untersucht die verfügbaren Nachweise und bestätigt den Treffer, lehnt ihn ab oder lässt den Fall offen.
4. Die Identity-Aktion wählen
Ein bestätigter Treffer kann verknüpft bleiben, wenn der Workflow lediglich Zugriff auf verwandte Datensätze benötigt.
Der Fall wird zum Merge weitergeleitet, wenn eine 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:
Match → Klassifizieren → Bei Bedarf prüfen → Verknüpfen oder Zusammenführen
Linkage ist das angemessene Ergebnis für unsichere Fälle, verteilte Datenzuständigkeit und Workflows, die nur eine kombinierte Ansicht benötigen. Merge bleibt bestätigten Fällen vorbehalten, in denen ein einziger physischer Datensatz betrieblich erforderlich ist.
Patient Matching, Linkage und Merge in FHIR
FHIR stellt für jeden Teil des Workflows einen separaten Mechanismus bereit.
Patient/$match
Patient/$match nimmt Patientenidentitätsinformationen entgegen und gibt Kandidaten-Patient-Ressourcen zurück.
Implementierungen können einen Score von 0 bis 1 einschließen, der die Konfidenz jedes Ergebnisses darstellt. Der Score kann anschließend anhand der Schwellenwerte der Organisation bewertet werden.
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 Identifikatoren und Daten. Damit eignet sich Patient.link für Cross-References, registry-artige MPI-Implementierungen und Beziehungen, die möglicherweise überprüft oder entfernt werden müssen.
FHIR definiert vier Patient-Link-Typen: replaced-by, replaces, refer und seealso.
Patient/$merge
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-Links eine Spur der Beziehung zwischen den Ressourcen erhalten.
FHIR trennt diese Mechanismen, weil die Bestätigung eines Patienten-Matches nicht immer die Konsolidierung der Datensätze erfordert.
Den Workflow mit MDMbox verwalten
MDMbox unterstützt Matching, Linkage, Stewardship und Merge als separate Bestandteile des Patient-Identity-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 Prüfung weitergeleitet werden können.
Wenn ein bestätigtes Duplikat konsolidiert werden muss, leitet Patient/$merge Referenzen auf den Zieldatensatz um und bewahrt die Beziehung zwischen den Patient-Ressourcen.
Die Organisation definiert die Richtlinie hinter diesen Aktionen, einschließlich Match-Schwellenwerte, Merge-Befugnis, Stewardship-Verantwortlichkeiten, Survivorship-Regeln und die Systeme, die Identitätsaktualisierungen empfangen müssen.
Einen Workflow prüfen, bevor Merge aktiviert wird
Die Patient Identity: Link or Merge? Decision Checklist hilft Teams zu bestimmen, ob ein Workflow Linkage, Stewardship-Review oder physische Konsolidierung erfordert.
Der erste Teil behandelt Zuständigkeit, Match-Konfidenz und die Notwendigkeit eines einzigen Patientendatensatzes. Der zweite Teil prüft, ob die erforderlichen Merge-Kontrollen vorhanden sind.
