How do you match patient records across systems when there is no shared identifier?

Why there is no join key

Healthcare identifiers are local by design. A medical record number is issued by a facility, means nothing outside it, and is frequently reissued or duplicated within it after a decade of registration desks typing under time pressure. Many jurisdictions have no universal patient identifier at all, and where a national number exists it is often not permitted as a general-purpose key, or is simply absent for a walk-in patient with no documents. So when two hospitals merge, an insurer ingests a provider feed, or a health-information exchange stitches ten sources together, you are matching on demographics: name, date of birth, sex, address, phone, and whatever else the source happens to populate.

Those fields are all unreliable in specific, patterned ways. Names change on marriage and are transliterated inconsistently. Dates of birth are estimated for elderly and paediatric patients and default to the first of January or the first of the month. Addresses go stale faster than any other attribute. Phone numbers are shared across a household. A design that assumes any single field is authoritative will fail on exactly the populations that use the system most.

Deterministic and probabilistic matching

Deterministic matching applies an ordered set of rules over normalised values: same national identifier is a match; failing that, exact surname plus date of birth plus postcode is a match. It is fast, trivially explainable to a clinical safety officer, and easy to audit, which is why it remains the backbone of most production matching. Its weakness is that it is all-or-nothing per rule, so one transposed digit in the date of birth drops a true pair out of every rule that uses it, and rule sets grow into unmaintainable thickets as each missed case earns its own clause.

Probabilistic linkage, the classical form of which is the Fellegi-Sunter model, scores each field comparison instead. For every field you estimate two probabilities: how often that field agrees given the pair really is the same person, and how often it agrees by chance given the pair is not. The ratio of the two, in logs, becomes a weight, and the weights sum to a composite score for the pair. This gets you the behaviour deterministic rules cannot express: agreement on a rare surname is strong evidence, agreement on a common one is weak, disagreement on a mutable field like address is only mildly disconfirming, and a missing field contributes nothing rather than counting against the pair.

Neither approach can compare every record with every other one. Candidate generation, conventionally called blocking, restricts comparisons to records that already agree on something cheap - a phonetic encoding of the surname, the year of birth, the first characters of the postcode - and you run several blocking passes so that a record with one corrupt blocking field is still reachable through another pass. Blocking is where recall is silently lost: a true pair that never becomes a candidate can never be matched, no matter how good the scoring is, and that failure is invisible in any metric computed over the candidate set.

Two errors, very different costs

The output of scoring is not a binary decision but three bands, split by two thresholds: above the upper one, link automatically; below the lower one, leave separate; between them, queue for a human. Where you put those thresholds is a clinical safety decision, because the two errors are not comparable.

A false merge puts one person's allergies, medications, diagnoses and results into another person's chart. A clinician then reads a chart that is internally coherent and wrong, and may act on it - prescribe against an allergy that belongs to someone else, or miss the one that matters. It is simultaneously a disclosure of one patient's record to whoever views the other, so it is a privacy breach as well as a safety event. And it is hard to detect from inside, because nothing about the merged chart looks broken.

A false split leaves two partial charts. That causes real harm too - repeated imaging and its radiation, a duplicated test, a drug interaction missed because the other prescription is in the other record - but a clinician working from a chart is professionally accustomed to charts being incomplete and will ask the patient. The failure is visible and recoverable. So the bias in a clinical setting runs towards leaving records apart and paying for human adjudication, which is the opposite of the tuning you would choose for a marketing customer-360 where over-merging costs an irrelevant email.

Reversibility is an architectural requirement, not a feature

Because false merges happen and are found later, the merge must be undoable, and that constrains how you store it. Source records stay exactly as the source sent them: immutable, keyed by their originating system and local identifier. The match is a separate assertion - these two source records are believed to be the same person - carrying its own provenance: the rule or model version, the score, the fields that drove it, whether a human confirmed it, and when. Unmerging then means retracting an assertion, not reconstructing which datum came from where, which is impossible once you have collapsed two rows into one and thrown the originals away.

The harder half of reversibility is downstream. Anything that consumed the merged identifier - an order, a result, a claim, an analytics extract, another organisation's copy - now holds a link that must be corrected. That is why linkage state is published as events rather than exposed only as current state, and why FHIR models this explicitly on the Patient resource: link records a relationship to another Patient, with types including replaced-by and replaces, so a client that resolves an old identifier can discover it has been superseded, and a retraction is itself an observable change rather than a silent rewrite.

The golden record and the MPI

The master patient index is the component that owns identity: it holds the enterprise identifier, the set of source records asserted to belong to it, and the linkage evidence. The golden record is the projection you read from - one coherent view of the patient assembled from the linked sources by survivorship rules that say which source wins for which field and how recency is broken.

The distinction that matters is that the golden record is derived, never authored. It must be reproducible by replaying sources plus links plus survivorship rules, because that is precisely what makes an unmerge tractable and what lets you re-run a corrected model over history. The moment someone edits the golden record directly to fix a name, you have created a value with no source, and the next rebuild either loses it or you have to keep a pile of manual overrides that themselves become unauditable state.

Where this interview is usually lost

Candidates who have read about entity resolution treat it as a scoring problem and stop at a single threshold and an F-score. That answer fails on two counts at once: it optimises a metric that weighs the two error types equally when clinically they differ by orders of magnitude, and it implies a system with nowhere to put an uncertain pair except into a decision. The strong answer names the asymmetry, sets thresholds from it, keeps a human in the ambiguous band, and can explain how a merge made today gets taken back next year without losing the ability to say which fact belonged to which person.

Design the unmerge before you design the match. If you cannot say which source record contributed each value in the golden record, you have not built a patient index, you have built an irreversible data-quality incident.