Knowing Who the Patient Is (Demographic Records and Master Patient Index)

Sector: Hospitals, health systems

The scenario

Imagine a hospital that has grown by adding systems: emergency, outpatient, lab, radiology, each with its own registration desk. Every desk creates patients its own way, so one real person can end up with several records. "María de los Ángeles Pérez", "Maria Angeles Perez" and "PEREZ MARIA A." may be the same woman, each record holding a piece of her history.

The question you can't answer is simple: which of these records belong to the same real patient?

What goes wrong without the right tool

  • 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 happens too: two different people with the same name and birth year get merged, and nobody can say who did it or undo it.
  • A script comparing names finds exact matches only, misses typos and swapped names, and leaves no trace of why it flagged something.

What is a Master Patient Index?

A Master Patient Index (MPI) is the answer to that question: one authoritative place that knows, for every real person, which records across the organization are theirs. Any system can then ask "who is this patient?" and get one consistent answer. It works in three steps:

  1. Match. Compare patient records and find the ones that probably describe the same person.
  2. Reconcile. Decide, with evidence, whether they really are the same person.
  3. 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.

How Atomik can be used

  1. Keep identity in the repository. Registration systems commit each patient as a demographic record (PERSON), and each patient has an EHR linked to it.
  2. Define what identifies a patient. Without code, choose which fields count (name, birth date, sex, national ID, for example) and how much each weighs. Accents and capitalization can be ignored, a typo can weigh less than a different birth date, a matching national ID more than a matching first name.
  3. Match in the background. New and updated patients are indexed and compared. Atomik finds likely matches without comparing everyone with everyone, and scores each pair with your rules. Likely matches go to a review list with the score and a field-by-field explanation.
  4. 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.
  5. 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. The systems that use the old identifiers keep working.
  6. Undo mistakes. A merge can be reversed, and the history shows both the merge and the reversal.
  7. Audit. Each identity decision can be reviewed: why the records were compared, the evidence, who confirmed it, and what happened to the EHRs.

How CaboLabs can help

Atomik was built by CaboLabs, a company specialized in healthcare systems integration, data migration and consolidation, and clinical data management and audit. Besides the software, CaboLabs offers services that fit this scenario:

  • Data quality assessment. Before matching, understand how many duplicates, incomplete records and inconsistent values the source systems have. See Clinical Data Quality Assessment.
  • Database audit. Reviewing the databases behind the registration systems for duplicated records, orphaned references and structural problems. See Database Audit & Optimization.
  • Data mapping and migration. Moving patient records from the registration systems into Atomik with documented mapping rules. See Data Mapping & Migration.

None of this is required to use Atomik; you can do it with your own team or another provider. If you'd like to talk about your case, get in touch with CaboLabs.

What this gives you

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.

Where this goes next

Today this is an MPI inside one organization: Atomik holds the demographic records and resolves identity by merging. The same problem exists between organizations, where records can't and shouldn't be merged: two hospitals, a regional network, a national registry that each keep their own patient. Linking those records to the same real person, without moving them, is part of Atomik's direction for the next phases. It is not available yet.

Why Atomik fits

Identity is not a side table; it's the thing every clinical record hangs from. Because Atomik keeps demographic records, EHRs and their history in one standards-based store, a merge can be traced, explained and undone, and the rules for "same person" are yours, not a vendor's black box.

← All use cases