Patient Matching Across EHRs: Identity Resolution and Controlled Corrections

Match, link and merge need separate permissions

An enterprise master patient index, or EMPI, maintains the relationship between a person and records held by participating systems. The critical design choice is what the platform is allowed to do with a proposed relationship.

A match is a candidate result. A link records a decision that source records refer to the same person. A merge changes identity records according to the participating systems' rules. A correction revisits an earlier decision and repairs its consequences. These are working distinctions for the architecture described here; vendor terminology varies.

Keep source records addressable after linking them. A source reference should identify the organization, the originating system and its local record. Store an MRN with its assigning authority or namespace. Comparing the string 12345 across two hospitals does not establish a shared identifier.

The HL7 US Identity Matching guide also distinguishes identity verification from patient matching. Proving who is requesting information and locating the right clinical record solve related but different problems. Neither decision should silently grant the other.

Six cases to put in the review queue

The following cases are synthetic acceptance examples. They are neither clinical recommendations nor evidence of a matching system's accuracy.

A reviewer needs the comparison that produced the candidate, including conflicts and missing fields. An unexplained confidence score leaves the operator to reconstruct the evidence manually.

Record the decision, its author and the rule or model version used. Include the source snapshots compared at that moment. If a surname changes tomorrow, yesterday's decision should remain explainable.

Deterministic and probabilistic patient matching

Deterministic patient matching applies explicit comparison rules. Probabilistic matching weighs combinations of evidence. Either approach still needs a policy for conflicting attributes, missing values and ambiguous candidates.

Use deterministic rules where a verified identifier relationship is strong enough for the intended action. Evaluate probabilistic methods where spelling variations or incomplete demographics make exact comparisons insufficient. A hybrid can generate candidates with several methods and apply a separate decision policy afterward. This is an architectural option, not a requirement of FHIR.

Normalization should produce comparison values alongside the originals. Preserve the entered name while deriving a comparison form; retain the original address alongside any standardized representation. An investigation may need to determine whether a mismatch came from the registration desk, a transformation or the matching rule.

The ONC Registrar Playbook illustrates how registration errors and incomplete demographics create identity problems at the source. A matching project therefore needs a data-quality owner as well as an algorithm owner. Repeatedly compensating for one source's missing fields can conceal a correctable registration defect.

Thresholds belong to the local validation process.

Assemble adjudicated examples from the participating sources and define which errors are acceptable for each action. A threshold suitable for suggesting a candidate may be unsuitable for linking records automatically. Do not promote a demonstration score into a production safety rule.

What FHIR patient match actually provides

The FHIR R4 Patient $match operation accepts a complete or partial Patient resource. The base operation does not prescribe a matching algorithm or one universal minimum input set. It returns ranked candidates in a searchset Bundle, with an empty set when no matches are found.

FHIR defines a search score from 0 to 1 and a match-grade extension for the returned candidates. These outputs describe the search result. A score should not be treated as a calibrated probability of shared identity unless the implementation has established that meaning. It also supplies no automatic approval to merge records.

Document the implementation contract: accepted fields, required profiles, identifier namespaces and the interpretation of grades. Define how callers handle an empty result, multiple plausible candidates and a rejected request. A patient-facing application needs a safe unresolved path as much as it needs a successful search path.

The patient-matching guidance in the US implementation guide discusses matching against related Patient records rather than relying only on a flattened projection. Its privacy considerations also keep matching separate from authorization to disclose protected health information. Apply the guide within its stated US and profile context.

The broader transport and mapping work belongs in an EHR integration design. Keep identity policy visible as a separate contract even when the same integration team implements both.

A data model that preserves the decision trail

The following model is a proposed implementation structure, not a standard resource schema.

Keep a SourcePatient for each originating record, with its source identifier and source version. An IdentityCluster groups accepted relationships without erasing the members. A MatchRequest captures the input and comparison context; a MatchDecision records the selected action and supporting evidence. Corrections deserve their own object. An IdentityCorrection should reference the disputed decision, affected records and approved repair plan. A ConsumerReceipt records which downstream systems have applied the correction and which still require attention.

Store the current projection for fast reads, but preserve the decisions that produced it. Restrict the evidence store to authorized roles and set retention rules for demographic snapshots. Traceability does not justify keeping every sensitive field indefinitely.

An external EMPI can supply the candidate engine while a custom layer owns review and downstream corrections. Evaluate that split before choosing to build the matching engine itself. Ask vendors to demonstrate the six cases above using your identifier relationships and representative data, rather than only their prepared sample.

Merge correction extends beyond the registry

Suppose a mistaken link has already influenced a portal's document list. Correcting the identity cluster leaves an operational question: which documents, cached views and pending workflows used the earlier relationship?

Create an impact list before applying the repair. Identify affected consumers and assign an owner for exceptions. Pause unsafe propagation where the product permits it, then apply approved changes and track acknowledgments. A consumer that cannot separate the affected records may need a manual remediation task.

The IHE PMIR profile, version 1.6.0 Trial Implementation, describes identity sources, a registry and consumers. Administrative unmerge is outside its scope. That limitation matters when estimating a correction workflow across products.

In PMIR's ITI-93 transaction, a merge deprecates a Patient record through an inactive status and a replaced-by link. Unmerge is not a generally supported reversal of that transaction; the specification leaves exceptional behavior to local policy. Do not sell a universal undo button on the strength of PMIR support.

For systems that write into an EHR, add the identity decision and current correction state to the write authorization checks. The separate guide to AI agent EHR write access covers the action boundary. A successful identity lookup should never bypass it.

Measure matching quality by action and source

Report candidate-search performance separately from the quality of accepted links. Precision is the share of evaluated positive decisions that are correct; recall is the share of known true relationships that the method finds. Both need an explicitly labeled evaluation set and a defined unit, such as a record pair. Keep false merges visible rather than burying them inside a broad match rate. Track missed links, review volume and the age of unresolved cases. Break results down by originating system and by difficult cohorts, including sparse records and changed demographics.

An overall average can hide a weak integration at one site.

Operational measurements answer another question. Track search latency and the time needed for consumers to acknowledge a correction. Record whether a growing review queue reflects additional traffic, poorer source data or a rule change. Those causes require different responses.

Before rollout, run the candidate process in a mode that records proposed decisions for review. Compare its output with adjudicated cases, investigate disagreements and approve the actions it may perform. Expand those permissions only when the evidence supports the next step.

Scope the healthcare identity integration

A procurement brief should identify the sources, allowed identity actions and unresolved-case owner. Include the correction impact list, validation dataset requirements and the evidence a vendor must retain. Ask how a record remains accessible when the local EHR and identity service disagree.

Pharos Production's healthcare IT solutions are the relevant starting point for discussing an identity layer within a wider clinical product. For a project centered on connecting existing records, use the EHR integration services page to frame the source systems and consumer workflows. Bring a de-identified sample of conflicting records and a list of systems that would need to acknowledge an identity correction.