What should happen after an MPI finds a patient match?
An MPI has identified two records as a likely match. The system can keep both records and establish a relationship between them, or consolidate one record into another.
These actions are sometimes treated as consecutive steps in the same process. In practice, matching only identifies records that may belong to the same person. It does not determine what should happen to them next.
With linkage, applications can retrieve related records, map identifiers across systems, and build a longitudinal patient view while the original records remain intact.
Merge changes the records themselves. The target becomes the active patient identity, references to the source must be redirected, and conflicting values need to be resolved.
So when is a link sufficient, and when does a patient identity workflow require a merge? The answer depends on match confidence, data ownership, provenance, downstream workflows, and what happens if the decision turns out to be wrong.
Why a wrong merge is not equivalent to a missed match
A false negative leaves records for the same patient separate. The patient history may remain incomplete, but the data is still assigned to the original identities.
A false positive has a different effect. Once records belonging to two people are merged, their demographic, administrative, and clinical information may become part of the same patient identity.
The ONC Patient Identification and Matching Final Report describes false-positive matches as a greater patient-safety risk than missed matches because care may be delivered using information that belongs to another person. This asymmetry is one reason matching systems are commonly configured to tolerate some unresolved duplicates rather than increase the number of overlays.
Patient overlay
An overlay occurs when information belonging to two patients is mixed in one medical record.
The resulting record may contain another patient’s:
- allergies;
- medications;
- diagnoses;
- laboratory results;
- blood group;
- procedures.
Incorrect clinical information can affect treatment decisions. The merge may also give one patient access to another person’s protected health information through a patient portal, disclosure request, or identity-based access rule.
When an incorrect merge results in unauthorized access to or disclosure of PHI, the incident may need to be assessed under the HIPAA Breach Notification Rule. Under 45 CFR Part 164, an impermissible use or disclosure of PHI is presumed to be a breach unless the covered entity or business associate demonstrates a low probability that the information was compromised.
The consequences can therefore extend beyond data quality and clinical safety to investigation, notification, and remediation obligations.
Unmerge
Reactivating the source record does not necessarily restore the state that existed before the merge.
The correction team may need to review encounters, observations, documents, claims, and other resources to determine which patient each item belonged to. Some systems support unmerge only through a manual process. Others require the original records to be reconstructed from audit history.
Auditability therefore needs to be designed into the merge workflow. The organization should be able to identify the source and target records, the values that were changed, the person who approved the action, and the evidence used in the decision.
Downstream propagation
Patient identity updates may be consumed by EHRs, laboratories, billing systems, patient portals, analytics environments, and payer applications.
An incorrect merge can continue to affect these systems after the MPI has been corrected. Each recipient needs a way to process the correction and determine which previously received data must be changed.
The wider the distribution of the patient identity, the less useful it is to treat merge as a local database operation.
When patient records should remain separate
The risks of merge do not mean that every match should remain unresolved. They mean that recognizing one person across records and physically consolidating those records should be treated as separate decisions.
The match is not yet conclusive
Probabilistic matching commonly divides results into definite matches, possible matches, and non-matches.
A definite match may qualify for automated processing under an approved policy. A possible match needs additional review.
While the case is under review, both records remain available. A data steward can inspect identifiers, demographic attributes, missing values, source reliability, and previous identity events without first having to separate data that has already been merged.
The reviewer may confirm the match, reject it, or leave the case unresolved. Confirmation establishes that the records belong to the same person. It does not, by itself, require physical consolidation.
The records belong to different organizations
An HIE, laboratory network, hospital group, or payer-provider exchange may need to recognize that several local identifiers refer to the same person.
Each participant still maintains its own patient record and remains responsible for its data. A shared identity service can map the identifiers and retrieve related information without transferring ownership of the source records.
The IHE Patient Identifier Cross-referencing profile (PIX), Patient Demographics Query profile (PDQ), and Cross-Community Patient Discovery profile (XCPD) address patient identification and cross-referencing within and across healthcare communities. The ONC Interoperability Standards Platform lists these profiles as production-level approaches to exchanging patient identity information.
Without a governance framework that explicitly authorizes consolidation, a cross-organizational match should result in linkage rather than merge.
Source context needs to be preserved
Patient information may come from systems with different levels of authority, completeness, and reliability.
One source may contain a verified legal name. Another may have a more recent address or telephone number. Keeping the records separate makes it possible to show these values together while retaining where each value came from, when it was received, and which organization supplied it.
This naturally supports provenance and audit requirements. A merged record can also preserve provenance, but the implementation must store it explicitly after the original source boundaries have been removed.
The workflow only needs a combined view
A registry-style MPI maps an enterprise identity to the patient identifiers used by individual source systems.
Applications can use those links to find related records and present them as a longitudinal patient view. The source systems remain unchanged, and the MPI does not become the transactional owner of their clinical data.
This model can support record discovery, analytics, care coordination, and cross-system access without creating one physical patient record. The ONC report on Master Data Management in HIE Infrastructures describes this use of a master identifier to connect local patient identities across distributed systems.
When one physical record becomes necessary
Linkage works while consuming applications can operate with several connected records. It stops being sufficient when an operational process requires one active patient identity.
A duplicate inside one EHR, for example, may interfere with billing, transactional updates, identity-based access, or maintenance of a centralized system of record. In this case, retrieving related records together does not solve the problem. The duplicate itself needs to be removed.
Before proceeding, the organization needs to establish three things:
- It has authority to consolidate both records.
- The records have been confirmed to belong to the same person.
- A linked view cannot meet the operational requirement.
The clearest merge case is a confirmed duplicate inside one EHR, MPI, or other system controlled by the same organization.
A second record may have been created because of a spelling difference, incomplete registration data, a missing identifier, or duplicate registration during an emergency encounter. Once the duplicate has been confirmed, keeping both records may continue to disrupt processes that depend on one patient ID.
Cross-organizational merge is a separate case. It requires an agreed governance framework that defines ownership of the resulting identity, merge authority, and the actions expected from participating systems.
The IHE Patient Master Identity Registry profile (PMIR) describes a workflow in which multiple master identities are consolidated into one Golden Patient Identity and the decision is distributed to data owners. Without this type of governance, cross-organizational identity management remains a linkage use case.
What needs to be resolved before merge
Once physical consolidation is justified, the team needs to determine how the merge will change the patient identity and the data connected to it.
Select the source and target
One record becomes the target identity. The other becomes the source that is replaced or made inactive.
The target should not be selected only because it was created first. The decision may also depend on which identifiers are already in use, the authority and completeness of each record, and the systems that reference them.
Define survivorship rules
Confirmed duplicate records can still contain different names, identifiers, addresses, telephone numbers, and demographic attributes.
Survivorship rules determine which values are written to the target. They may prioritize:
- a more authoritative source;
- a verified value;
- the most recent value;
- the more complete record;
- a decision made by a data steward.
Values that do not survive should remain available through resource history, provenance, or another audit mechanism. Otherwise, it may be impossible to explain how the target record was created or reconstruct the state before merge.
With linkage, these conflicts do not need to be resolved immediately. Each value remains in its source record and can be presented with its original context.
Redirect references
Clinical, administrative, and financial data may already reference the source patient.
A merge must identify those references and redirect them to the target. The scope may extend beyond data stored in the MPI to connected applications that have already received or copied the identity.
Prepare for correction
The organization needs to understand what its systems can and cannot reverse automatically.
A correction process should define:
- how an incorrect merge is detected and investigated;
- who decides which data belongs to each original patient;
- how the pre-merge state is reconstructed;
- how downstream systems receive the correction;
- how privacy and patient-safety incidents are handled.
These controls are part of merge readiness, not work to be designed after the first error occurs.
Moving a match from discovery to merge
A controlled patient identity workflow separates candidate generation, identity confirmation, and physical consolidation.
1. Find candidates
The matching engine compares identifiers and demographic attributes and returns records that may belong to the same person.
The result should include the evidence used in matching and, where applicable, a confidence score.
2. Classify the result
Each candidate is assigned to an operational category:
- definite match;
- possible match;
- no match.
The organization defines the thresholds and actions permitted for each category.
3. Review uncertain cases
Possible matches remain separate and enter a stewardship queue.
The reviewer examines the available evidence and confirms the match, rejects it, or leaves the case unresolved.
4. Choose the identity action
A confirmed match may remain linked when the workflow only needs access to related records.
The case proceeds to merge when consolidation is authorized and a process requires one active patient identity.
5. Apply merge controls
Before consolidation, the team selects the target record, applies survivorship rules, preserves the decision history, and identifies affected downstream systems.
The workflow can be summarized as:
match → classify → review when needed → link or merge
Linkage is the appropriate outcome for uncertain cases, distributed data ownership, and workflows that only need a combined view. Merge is reserved for confirmed cases where one physical record is operationally necessary.
Patient matching, linkage, and merge in FHIR
FHIR provides a separate mechanism for each part of the workflow.
Patient/$match
Patient/$match accepts patient identity information and returns candidate Patient resources.
Implementations can include a score from 0 to 1 representing the confidence of each result. The score can then be evaluated against the organization’s thresholds.
Patient.link
Patient.link records a relationship between Patient resources that refer to the same real-world person.
The resources remain separate and retain their original identifiers and data. This makes Patient.link suitable for cross-references, registry-style MPI implementations, and relationships that may need to be reviewed or removed.
FHIR defines four Patient link types: replaced-by, replaces, refer, and seealso.
Patient/$merge
Patient/$merge consolidates a source Patient resource into a target Patient resource.
References to the source are redirected to the target. The source becomes inactive, while replaced-by and replaces links preserve a trace of the relationship between the resources.
FHIR separates these mechanisms because confirming a patient match does not always require consolidating the records.
Managing the workflow with MDMbox
MDMbox supports matching, linkage, stewardship, and merge as separate parts of the patient identity workflow.
Teams can use Patient/$match to find and score candidates. Records that should remain separate can be connected through Patient.link, while possible matches can be routed for review.
When a confirmed duplicate must be consolidated, Patient/$merge redirects references to the target and preserves the relationship between the Patient resources.
The organization defines the policy behind these actions, including match thresholds, merge authority, stewardship responsibilities, survivorship rules, and the systems that need to receive identity updates.
Check a workflow before enabling merge
The Patient Identity: Link or Merge? Decision Checklist helps teams determine whether a workflow requires linkage, stewardship review, or physical consolidation.
The first part covers ownership, match confidence, and the need for one patient record. The second checks whether the required merge controls are in place.
