Healthcare and life sciences fundamentals

A patient is a person about whom clinical facts are recorded, and the awkwardness is that the concept is defined by the record rather than by the person. Every organisation that treats someone creates its own patient entity with its own identifier, so one human being routinely exists as a dozen patients across a region and several within a single hospital that has merged with others. Nothing in the data announces that they are the same. The consequence for design is that "patient" is two different things — a local record you own and control, and a person you can only ever approximate through matching — and code that conflates them will eventually attach a result to the wrong human. Keeping the local identity and the resolved identity as separate fields is the cheapest defence.

An encounter is one interaction between a patient and the care system: an outpatient appointment, an inpatient stay, an emergency attendance, a telephone consultation. It matters because it is the hook almost everything else attaches to — the observations taken, the orders placed, the notes written, the diagnoses recorded, the charges generated. Its lifecycle is a small state machine of planned, arrived, in progress, finished and cancelled, and the transitions are what other systems are told about. The design consequence is that an encounter's boundaries decide what a report counts. If an inpatient stay is modelled as one encounter with internal transfers, the ward-level view has to be derived; if each ward is its own encounter, the length of stay has to be assembled.

An episode of care groups the encounters that belong to one clinical problem over time — a pregnancy, a cancer pathway, a course of physiotherapy — so that care delivered across months and departments can be reasoned about as one thing. An encounter is a contact; an episode is a purpose. The distinction is where outcome measurement and pathway analytics live, because a hospital wanting to know whether treatment worked is asking about the episode, not about Tuesday's appointment. It is also the entity most often missing from a schema, since encounters arrive naturally from operational messages while episodes have to be constructed deliberately. Adding them later means inferring groupings from dates and diagnosis codes, which is guesswork with clinical consequences.

A medical record number is an identifier issued by one organisation, unique within that organisation and meaningless outside it. Two hospitals can issue the same digits to different people, and one person carries different numbers at every site they have attended. This is why every identifier in a health message carries an assigning authority alongside the value: the pair is the identity, not the number. Systems that store an MRN as a bare string, or use it as a primary key in a regional aggregation, produce collisions that look like one patient with contradictory history. The correct model is a set of identifiers per patient, each qualified by its issuing system and type, with your own internal key that no external party ever sees.

A master patient index is the service that decides which source records describe the same person. It holds demographic attributes gathered from every contributing system, the links it has asserted between records, a confidence or score for each link, and the history of how those links came to exist. It is deliberately not the clinical record: it resolves identity and points at the systems that hold the data. What makes it a system rather than a table is everything around the matching — a review queue for the ambiguous cases, an audit trail of who confirmed each link, and the ability to reverse a decision. Treating it as a lookup rather than as a workflow is the mistake that leaves an organisation unable to correct its own errors.

Matching is easy to describe and hard to do, and the reason becomes obvious the moment two real records are put side by side.

                 Record A  (site 1, MRN 884120)   Record B  (site 2, MRN 55019)
---------------  ---------------------------      ----------------------------
Surname          O'Brien                          Obrien
Given name       Katherine                        Kate
Date of birth    1981-06-04                       1981-04-06
Sex              F                                F
Postcode         M14 5QT                          M14 5QT
Address line     Flat 2, 14 Elm Road              14 Elm Rd
Phone            07700 900412                     07700 900412
NHS number       (absent)                         999 999 9999

Every difference has an innocent explanation and a sinister one. The apostrophe is a data-entry convention. Kate is a diminutive, not a different name. The birth date is a day-month transposition — or two people born two months apart. The shared postcode and phone could be one person, or a mother and daughter with the same initial. Nothing here is a typo you can safely normalise away.

Deterministic matching applies rules: agree exactly on a trusted identifier, or on surname plus date of birth plus postcode, and link. It is explainable, cheap and auditable, and it fails on exactly the record above, because no rule survives the transposed date. Its failure mode is the false negative — one person split into two charts, each holding half the allergies.

Probabilistic matching scores each field's agreement by how much evidence it carries, using the frequency of the value: agreement on a rare surname is worth far more than agreement on Smith, and agreement on a shared household phone is worth less than it looks. The scores combine into a weight, and two thresholds define auto-link, human review and no-link. Its failure mode is the false positive at the top of the band — two records merged that were never the same person.

The number worth quoting is the width of the review band, because it is a staffing decision rather than an algorithm choice. Narrowing it pushes errors into the record silently; widening it produces a queue that never empties. And the two errors are not symmetrical: a split chart hides history, while a wrong merge actively shows one patient another's results, which is why production systems auto-link only on a narrow, high-confidence path.

Because a national identifier turns identity into a lookup, and its absence turns it into inference over hand-typed demographics. Several countries issue one and mandate its use, so matching is largely solved and the remaining work is validating the check digit and handling the newborn who does not have one yet. In jurisdictions without one — most notably the United States, where an appropriations restriction has long blocked a federal identifier — every organisation runs its own index over names, dates of birth and addresses, all of which change, are misheard and are mistyped. The engineering consequence is that identity becomes a probabilistic subsystem with its own error rates, review staff and safety implications, rather than a foreign key.

You discover that unmerging is not the inverse of merging. Once two records are combined, downstream systems have copied the surviving identifier into orders, results, claims, appointment letters and their own local caches, and each of those copies has to be found and corrected. Clinical documents already contain both patients' data interleaved, so separating them requires clinical judgement about which observation belonged to whom. That is why mature implementations treat a merge as a reversible assertion rather than a destructive update: both source records survive, the link is an entity with an author and a timestamp, and the merged view is computed. Designing for reversal from the start is substantially cheaper than the alternative, which is a manual, clinically supervised data-repair project.