MPI Survivorship Rules And Probabilistic Matching Strategies For Enterprise Patient Identity Resolution

An enterprise Master Patient Index cannot be treated as a duplicate-record database. It is a patient identity resolution system responsible for determining whether records from different EHRs, laboratories, payer platforms, patient portals, imaging systems, and acquired facilities represent the same person.

Patient matching identifies records that probably belong together. Survivorship determines which demographic values become part of the enterprise identity. 

Combining these decisions into one opaque process creates dangerous failure modes: two patients may be incorrectly merged, a single patient may remain split across multiple identities, or an outdated source value may overwrite a verified value.

ONC defines patient matching as identifying and linking one patient’s data within and across healthcare systems to create a more complete record. IHE’s Patient Master Identity Registry profile similarly describes a centrally managed “golden” patient identity while preserving relationships with participating identity sources.

Separate Identity Matching From Attribute Survivorship

A production MPI should maintain four logically separate objects:

1. Source identity: The patient record exactly as received from an EHR or other source.
2. Enterprise identity: The internal enterprise person identifier.
3. Identity crosswalk: The relationship between enterprise identity and source-system identifiers.
4. Surviving demographic view: The currently preferred name, address, phone number, birth date, and other attributes.

Source records should remain immutable or historically versioned. The enterprise record is a derived view, not a destructive replacement for source data.

This separation makes it possible to reverse an incorrect merge, explain why an attribute survived, and rebuild the golden record after changing a rule.

Enterprise MPI Reference Architecture

The ingestion layer can consume HL7 v2 patient-administration events, FHIR Patient resources, batch files, or vendor APIs. The service layer should expose standards-based queries where possible. 

IHE PIX and PIXm support identifier cross-referencing, PDQm supports demographic queries, and FHIR defines Patient/$match for submitting demographic information and receiving ranked potential matches.

Stage 1: Normalize Data Without Destroying Evidence

Matching should use canonical representations while retaining the original values. Normalization commonly includes:

• Unicode, case, whitespace, punctuation, and honorific normalization
• Parsing given, middle, family, previous, and preferred names
• Converting phone numbers into a consistent international representation
• Separating apartment, street, city, state, postal code, and country
• Standardizing common abbreviations and directional values
• Distinguishing missing, invalid, withheld, and unknown values
• Retaining historical names, addresses, phone numbers, and identifiers

Address standardization is especially important. ONC’s Project US@ specification was created to improve the consistent capture and exchange of patient addresses, which can materially improve record linkage. Research using real-world healthcare datasets also found that demographic standardization improved patient-matching sensitivity.

Normalization must not convert missing values into disagreement. A missing phone number provides no evidence. It is not evidence that two records belong to different patients.

Stage 2: Generate Candidates With Multi-Pass Blocking

Comparing every record with every enterprise identity produces quadratic growth. An MPI containing 20 million identities cannot score every possible pair for each registration event.

Blocking reduces the search space by generating candidates through several independent passes, such as:

• Exact birth date plus normalized family-name prefix
• Normalized phone number plus birth year
• Email address plus family name
• Postal code plus birth date
• Phonetic family name plus given-name initial
• Trusted source identifier within its assigning authority

Candidates from all passes are combined before scoring. Relying on one blocking key is unsafe because a typographical error in that key can prevent the correct identity from ever reaching the matcher.

Blocking logic should therefore optimize candidate recall. The scoring stage, not the blocking stage, should make the final identity decision.

Stage 3: Apply Deterministic and Probabilistic Matching

Deterministic rules remain useful for trusted combinations, such as an exact identifier match within the correct assigning authority. However, deterministic matching alone performs poorly when identifiers are missing, demographics change, or data contains transpositions and spelling variations.

A common probabilistic foundation is the Fellegi-Sunter model. For each field, the matcher estimates:

• m-probability: Probability that the field agrees when two records are a true match
• u-probability: Probability that the field agrees when two records belong to different people

The field weight can be represented as:

field_weight = log(m_probability / u_probability)

total_score  = sum(field_weights)

Agreement on a rare family name generally provides more evidence than agreement on a common family name. Approximate comparators such as Jaro-Winkler, edit distance, date transposition detection, nickname tables, and address-component similarity can produce graded agreement levels rather than a binary result.

Fellegi-Sunter parameters may be estimated from manually labelled pairs or through statistical methods such as expectation-maximization. Missing values should be modelled separately rather than automatically scored as disagreements.

The decision logic should remain policy-driven:

if
 trusted_identifier_conflict:
    classify as non-match
elif
 score >= auto_link_threshold and score_margin >= minimum_margin:
    auto-link
elif score >= review_threshold:
    send to identity review
else
:
    create or retain separate identity

The score margin between the highest and second-highest candidates is important. 
A high score is not sufficient when two identities have nearly identical evidence, as may occur with twins, parent-child records, or patients sharing names and addresses.

Use separate thresholds for different workflows. 

Searching for possible patients may favor recall. Automatically merging longitudinal clinical records should favor extremely high precision because a false merge can combine allergies, medications, diagnoses, and billing activity belonging to different people.

Stage 4: Build Safe Identity Clusters

Pairwise matches should not be converted into unrestricted transitive merges.

If record A matches B and B matches C, it does not automatically follow that A and C represent the same person. Identity clustering must re-evaluate the complete cluster and enforce cannot-link constraints such as conflicting verified identifiers, incompatible birth dates, or mutually exclusive demographic evidence.

Each cluster should store:

• Enterprise patient identifier
• Source-system identifiers and assigning authorities
• Pairwise scores and rule versions
• Match decision and reviewer evidence
• Merge, split, and unmerge history
• Effective and expiration dates
• Provenance for every surviving attribute

Stage 5: Apply Attribute-Level Survivorship Rules

Survivorship must operate at the attribute level rather than selecting one entire source record as the winner. Typical rule precedence includes:

1. Verification status
2. Source authority
3. Semantic validity
4. Effective date and recency
5. Completeness
6. Frequency across independent sources
7. Manual identity-steward decision

Different attributes require different policies:

• Identifiers: Preserve every valid identifier with its assigning authority. Never overwrite one facility’s MRN with another facility’s MRN.
• Legal name: Prefer a verified registration or authoritative identity source while retaining previous and alternate names.
• Birth date: Use authority and verification, not simple recency. A recently entered birth date is not automatically more accurate.
• Address and contact data: Prefer validated, patient-confirmed, deliverable, and recent values while maintaining history.
• Deceased status: Require authoritative evidence and controlled review because an incorrect value can suppress care and patient access.
• Sex and gender-related attributes: Preserve the original meaning, terminology, source, and effective period rather than collapsing distinct concepts into one field.

A survivorship decision should produce the selected value, source, rule identifier, confidence, and decision timestamp.

Merge, Unmerge, and Downstream Reconciliation

A merge should be implemented as a reversible identity event, not a database deletion.

The workflow should snapshot both identities, designate the surviving enterprise identifier, mark the subsumed identity as inactive or redirected, update the crosswalk, publish a merge event, collect acknowledgements, and reconcile downstream references.

IHE PMIR supports creating, updating, deprecating, and merging patient master identities and notifying subscribed consumers of identity changes. However, each downstream data custodian must still determine how clinical references are reconciled.

An unmerge procedure is equally important. The system must identify which encounters, documents, results, claims, and portal accounts moved during the merge and restore them without damaging legitimate updates made afterward.

Validate the MPI With Operational Evidence

MPI accuracy should be measured against manually reviewed gold-standard record pairs. At minimum, monitor:

• Precision and false-positive merge rate
• Recall and missed-match rate
• Review-queue acceptance and rejection rates
• Duplicate creation by facility and registration channel
• Merge and unmerge frequency
• Score distribution and threshold drift
• Missingness by demographic field and source
• Performance across relevant demographic and operational cohorts

Published patient-matching research has used manually reviewed datasets to compare matching strategies and recommends reproducible evaluation rather than relying on vendor-reported match percentages.

Rule, normalization, or threshold changes should first run in shadow mode. 

Compare the proposed decisions with the current production engine, investigate changed clusters, and obtain identity-governance approval before deployment.

Build an Enterprise Patient Identity Resolution Service With CapMinds

Enterprise patient identity resolution requires more than installing an MPI product. 

It requires data profiling, source-specific normalization, probabilistic model calibration, survivorship governance, standards-based integration, and operational processes for resolving uncertain identities.

CapMinds provides end-to-end patient identity and healthcare interoperability services, including:

• Enterprise MPI architecture and implementation
• Patient demographic data-quality assessment
• Deterministic and probabilistic matching strategy
• Attribute survivorship and source-trust design
• HL7 ADT, FHIR, PIXm, PDQm, and API integration
• Duplicate remediation and identity crosswalk migration
• Merge, unmerge, reconciliation, and audit workflows
• Match-performance monitoring and threshold optimization

Before consolidating records across EHRs, facilities, or acquired healthcare organizations, engage the CapMinds team for a technical assessment of your patient identity architecture, data quality, matching risk, and downstream reconciliation requirements.

Schedule a Healthcare SOC Architecture Assessment