Master Patient Index premium

When the same person is registered more than once, their history is split across records and nobody can see the whole picture. A Master Patient Index (MPI) keeps track of which records belong to the same real patient, so every system gets one consistent answer to "who is this patient?".

The concept

Every registration desk, department or system creates patients its own way, so one person can end up with several demographic records: "María de los Ángeles Pérez", "Maria Angeles Perez" and "PEREZ MARIA A." may be the same woman. An MPI is the authoritative place that knows, for every real person, which records are theirs. It works in three steps:

Match. Compare patient records and find the ones that probably describe the same person.
Reconcile. Decide, with evidence, whether they really are the same person.
Resolve. Make the answer official, so every record and every EHR of that person leads to one canonical identity, with the history of how that decision was made.

General architecture

In Atomik, identity is not a separate table: it lives in the same store as the clinical data. The MPI builds on two things the repository already keeps:

Demographic records (PERSON), one per registration, committed by the systems that register patients. See Demographics.
EHRs, each linked to a patient's demographic record and holding their clinical history. See EHRs.

On top of them, the MPI indexes new and updated demographic records, finds likely matches without comparing every record with every other one, and scores each pair using the matching rules you configured. Likely matches are kept in a review list with their score and a field-by-field explanation. Confirmed decisions are applied to the records and EHRs, and everything is recorded for audit.

Configurable matching

Patient identification is different in every context: some organizations have a reliable national ID, others only names and birth dates; some want exact matches only, others need to tolerate typos and swapped names. For that reason, Atomik's matching algorithm is highly configurable and adaptable to different contexts and needs, from deterministic to probabilistic matching:

Deterministic: records match when the fields you choose, such as a national ID, are equal.
Probabilistic: each field contributes a weight to a score, so near matches can be found even when the data is imperfect.

Without writing code, you choose which fields count (name, birth date, sex, national ID, for example) and how much each one weighs. Accents and capitalization can be ignored, a typo can weigh less than a different birth date, and a matching national ID can weigh more than a matching first name. Every score comes with the explanation of which fields contributed to it.

Operational model

Register. Registration systems commit each patient as a demographic record, with an EHR linked to it.
Match in the background. New and updated patients are indexed and compared, and likely matches go to the review list.
Reconcile with a person. A registry team reviews the list and decides same person or different people. Both decisions are kept, so a pair marked as different isn't proposed again. Nothing is merged silently.
Resolve. For confirmed matches, one record becomes the primary and the other is locked against new writes. Its EHR is merged into the primary's, and requests for the old EHR are pointed to the canonical one, so the systems that use the old identifiers keep working.
Undo and audit. A merge can be reversed, and the history shows both the merge and the reversal. Each decision can be reviewed: why the records were compared, the evidence, who confirmed it, and what happened to the EHRs.

Why a single patient identity matters

Without one, the risks are concrete:

A clinician opens a chart and doesn't see the allergy recorded under another record.
Results land on the wrong record and have to be re-linked by hand.
Billing sends two statements to the same person.
The opposite mistake also happens: two different people with the same name and birth year get merged, and nobody can say who did it or undo it.
Ad hoc scripts that compare names find exact matches only, miss typos and swapped names, and leave no trace of why something was flagged.

With an MPI you get one chart per patient, a ranked review list instead of a manual search, and identity decisions that are data you can explain, not spreadsheet edits.

Beyond one organization

Today the MPI works inside one organization, resolving identity by merging records. Linking records between organizations without moving them, such as two hospitals or a regional network, is part of Atomik's direction for the next phases and is not available yet.

To see the MPI in a scenario, read the Master Patient Index use case. If you want to talk about your case, get in contact.