Two patient records were merged last month and it turns out they are different people. How do you unpick that?

Two people in one chart is an active clinical hazard

Before any conversation about data repair, establish what is happening right now: clinicians are opening a record that contains two people's allergies, medications, results and history, and they are making decisions on it. An overlay — one record holding two identities — is the most dangerous state in patient identity work, and it is dangerous in both directions. Person A may be given a drug they are allergic to because the allergy list they are being shown is B's. Person B's abnormal result may be interpreted against A's history and dismissed.

So the first actions are containment, not correction. Flag the record so anyone opening it is told it is under identity investigation and must verify with the patient in front of them. Establish whether either patient is currently an inpatient, has an open order, has medication being administered, or has a result in flight, because those are the paths where harm is imminent. Suspend automated activity that depends on the record — recalls, outbound referrals, discharge summaries, results routing — because every one of those can carry the mixed data somewhere new while you work. And notify the clinical teams caring for both patients directly rather than relying on the flag being read.

Only then do you start unpicking, and you start by writing down the two identities you believe exist, with the evidence for each, because everything afterwards depends on that determination being right. If the identities are not clearly separable, the answer is to escalate to whoever can settle it — the registration team, the referring practice, the patient — rather than to guess and proceed.

The merge and its consequences are separate problems

A merge is rarely one database operation. It is an operation plus a cascade, and the cascade is where the difficulty lives.

Typically the master index recorded a link, one identifier was retired in favour of a surviving one, the clinical repository moved or re-pointed documents, orders and results, and a notification went out to every subscribing system telling it that the retired identifier is now the surviving one. Those subscribers acted independently: the laboratory system, the imaging archive, the pharmacy, the theatre and clinic scheduling systems, the billing and coding systems, the regional or national record share, the analytics warehouse, and any research extract. Some of them merged in the same way. Some appended. Some rejected the notification and are still holding two records. Some cached the mapping.

That produces the first hard rule of the recovery: the inventory of affected systems is the deliverable, and it must be built from what was actually sent and acknowledged rather than from the architecture diagram. Anything that received the merge notification is now in an unknown state and has to be checked individually, and anything that took an extract after the merge date has propagated the error further.

The second hard rule is that a month is long enough for the mixed record to have produced new artefacts of its own: documents authored against it, coded episodes, claims submitted, letters sent to one patient containing the other's information, and appointments booked. Those are not data rows to be re-pointed. Some are correspondence that has already left the building, and at least one of them is likely to be a disclosure of one patient's information to another, which has its own reporting path.

Re-attribution is a clinical exercise

The instinct is to reverse the merge programmatically, and on a well-designed system a reversal restores the two record shells. What it does not do is decide who each clinical item belongs to.

Every order, result, document, dose, allergy, problem and encounter created before the merge usually carries provenance — the source system, the original identifier, the placer of the order, the location — and that provenance is what re-attributes it. Items created after the merge, on the combined record, may carry no such evidence at all, because the clinician was documenting against one chart that they believed was one patient. A note recording a conversation, an examination finding, a medication decision: which person does it describe? Sometimes the content answers it. Sometimes only the author can, and the answer is to ask them rather than to infer.

So the process is an adjudication with a worklist and named clinical ownership, not a script. Items with unambiguous provenance are re-attributed. Items without it are reviewed by someone qualified to read them. Items that genuinely cannot be attributed are the residue, and the safest handling is usually to make them visible on both records as unattributed with an explanation, rather than to assign them on a balance of probabilities or to delete them. Deleting clinical information because its ownership is uncertain replaces a known problem with an invisible one.

Everything about this argues for one design property, and an interviewer will be listening for you to name it: a merge should be implemented as a reversible link with both identities preserved rather than as a destructive collapse of one record into another. Keeping the original identifiers, the provenance of every item and the merge decision itself as an auditable event is what makes this incident a difficult week instead of an unrecoverable one.

Harm assessment is part of the technical response

The part that gets omitted is that decisions were made on a wrong chart, and someone has to find out whether any of them hurt anybody. That means reviewing what happened to both patients during the affected period: medications prescribed and administered, results acted on and not acted on, diagnoses added, procedures performed, and anything cancelled or deferred on the basis of information belonging to the other person. It also means checking what was sent outwards — letters, referrals, claims, national record updates — and correcting or withdrawing it.

This is also where the organisation's obligations sit. A confirmed disclosure of one patient's record to another, and any clinical harm arising, follow the incident and information-governance routes rather than the change-management one, and the technical team's job is to supply an accurate account of what was combined, when, and where it went. The people who own that decision need a factual timeline, and producing one is much easier if the merge was logged as an event with a payload than if it was a set of updates.

Ask why the merge passed review

Finishing at the data repair is the most common way to lose this question. The interesting question is how two different people came to look like one, and the answer is nearly always one of a small set: matching thresholds set to favour convenience over safety, an automatic merge with no human confirmation, twins or family members sharing surname, address and date of birth, a shared or reused contact detail, a transposed digit in an identifier, or a registration clerk under pressure resolving an ambiguous search by picking the first hit.

The corrective actions follow from which one it was, and they are asymmetric by design. A duplicate record left in place for a day is an inconvenience; a merge of two people is a safety incident. That asymmetry justifies making merges harder than links, requiring a second person's confirmation for any automatic candidate above a threshold, refusing to merge on demographic similarity alone when a discriminating identifier is absent, and sampling completed merges for audit rather than trusting the queue. If the review of this incident produces only a data fix and no change to the threshold, the same case will arrive again.

Unmerging is not the inverse of merging. Reversal restores two record shells; deciding which person each note, dose and result belongs to is clinical work, and the only thing that makes it possible is provenance you decided to keep before you needed it.