The identity problem nobody budgets for

One person, several numbers, no authority

A patient may hold a hospital number from this site, another from a site that merged with it a decade ago, a national identifier they do not remember, and an insurer's reference that appears only on billing traffic.

None of these is authoritative in the sense a software engineer would like. Each was correct in its own context and none was designed to be the primary key of a person's life.

The consequence is that identity has to be resolved rather than looked up, and resolution is a process with judgement in it.

Two errors, wildly different costs

A false negative creates a duplicate: the same person appears twice and their history is split. This is bad allergies live on one record and prescriptions on the other.

A false positive merges two people. This is far worse, and it is not symmetrical with the first. One patient inherits another's diagnoses, results and medications, and the error propagates outward through every downstream system that received the merged record.

So the threshold is not a tuning parameter to be optimised for overall accuracy. It is a decision about which error you would rather make, which is a clinical and organisational question. We ask for it to be made explicitly, by people with the standing to make it.

The fields you match on are worse than you think

Names are transliterated inconsistently, ordered differently across systems, and abbreviated at registration by whoever was typing. Dates of birth carry defaults the first of a month, the first of a year that recur thousands of times in a large dataset and match each other perfectly.

Addresses change. Phone numbers are shared between family members. Sex and gender are recorded in fields that different systems use to mean different things.

Any matching rule that treats these as clean equality tests will produce confident nonsense. Treating them probabilistically, with per-field weights reflecting how discriminating each one actually is, is the minimum bar.

Merges must be reversible

Because false positives happen, the merge has to be undoable and undoable properly, not just a flag that hides the join while leaving the merged data mingled.

That is a data-model requirement and it has to be designed in from the start. Retrofitting reversibility onto a system that physically combined two records is close to impossible, which is why we keep the underlying records distinct and the link as a separate, revocable assertion.

The same applies downstream. If a merge was broadcast to five other systems, unmerging is a conversation with five other systems, and that needs to be part of the design rather than a discovery.

Somebody has to work the queue

Below the auto-merge threshold and above the auto-reject threshold is a band of possible matches that need a human. That band is not a temporary condition to be engineered away; it is a permanent part of running the system.

Which means the review tool is a real product surface, not an admin afterthought. It needs to show the evidence side by side, make the decision fast, and record who decided and on what basis.

A hospital that has not staffed this queue will accumulate duplicates regardless of how good the matching is.

Where a national identity helps, and where it does not

A portable health identity of the kind ABDM provides genuinely reduces the problem, because it gives one strong identifier that is not owned by a single organisation.

It does not eliminate it. Not every patient will have one at the point of care, adoption is uneven, and a patient in an emergency is not always in a position to produce anything at all. So probabilistic matching remains the fallback and the fallback is the path that runs on the worst day.