← All articles

Master patient index: what it is and why it matters

Master patient index: what it is and why it matters

Decorative title card illustration

A master patient index (MPI) is a database that assigns one persistent identifier per patient and links every record of that person across every system in a health service. It exists to stop the same patient acquiring multiple different charts under five slightly different name spellings. When it works, clinicians see the whole patient; when it fails, they see a fragment and act on incomplete information.

TL;DR:

  • Maintaining high IHI capture rates at registration points reduces duplicate creation and improves overall match accuracy.
  • Regular manual review of “possible match” cases helps catch errors that automated algorithms may overlook, lowering overlay risks.
  • Leadership with clear accountability, including clinical and privacy owners, is essential to govern and improve MPI performance effectively.
  • Standardized data formats and adherence to national standards like AUCDI and NSQHS support better matching and interoperability.
  • Continuous monitoring of duplicate and false-match rates, along with pilot testing thresholds, is vital for incremental MPI improvement over time.

Table of Contents

What is a master patient index (and how does it differ from an EMPI)?

A master patient index is the registry that answers one question for every clinical and administrative system in a health organisation: is this the same person we’ve seen before? Practitioners sometimes call it a patient identifier system, and vendors often use the terms MPI, EMPI (enterprise master person index), and master patient registry interchangeably. There’s a real distinction worth knowing, though.

An MPI traditionally sat inside a single facility, matching records within one hospital’s patient administration system. An enterprise master person index does the same job across an entire network: multiple hospitals, community health services, allied health providers, and sometimes aged care or disability support partners feeding into one shared index. Digital Health Australia describes EMPI solutions as systems that apply matching algorithms to spot duplicates and assign each person one enterprise identifier, rather than leaving that identifier trapped in a single facility’s local database.

This differs fundamentally from a local patient identifier, which is just a medical record number generated by one system for its own internal use. A local ID has no meaning outside that system. Patient A might be MRN 445291 at the hospital and an entirely different number at the community health centre down the road, with nothing connecting the two unless an MPI sits above both and reconciles them.

Where an MPI typically plugs into the broader health IT stack:

  • Electronic health record (EHR) systems, where it supplies the master identifier that ties a patient’s history together across departments and admissions.
  • Referral platforms, so a specialist receiving a referral can confirm they’re looking at the same patient the GP described, not a namesake.
  • My Health Record and national digital health infrastructure, where consistent identity underpins what gets uploaded and viewed.
  • Billing, scheduling, and practice management systems, which need one clean patient record to avoid double-ups in invoicing and appointment history.
  • Allied health and non-traditional care settings, including dementia and aged care support services, where patients often move between multiple providers who each hold a partial record.

The practical upshot for anyone doing healthcare data management: the MPI isn’t a nice-to-have add-on bolted onto an EHR. It’s the foundation the EHR and everything else stands on. Get the index wrong and every downstream system inherits that error.

How does an MPI match patient records?

Matching is the actual mechanics of an MPI, and it comes down to three broad approaches, each with different failure profiles.

Hands verifying patient identification data

Deterministic matching compares fields exactly: same Medicare number, same date of birth, same surname, and the system declares a match. It’s fast, explainable to an auditor, and easy to build. Its weakness is brittleness. A single typo, a hyphenated surname entered without the hyphen, or a recently changed name after marriage, and a deterministic rule will miss a match it should have made, creating a duplicate instead.

Probabilistic matching takes the opposite approach. Instead of requiring exact agreement, it scores similarity across multiple fields (name, date of birth, address, sex, phone number) and weights each field by how reliably it distinguishes one person from another. A shared surname carries less weight than a shared date of birth plus postcode combination, because surnames repeat far more often in a population. The NCBI’s overview of patient identity management frames this as one of two core strategies available when a shared unique identifier isn’t reliably present: score-based matching, or algorithmic linkage that tolerates messy, inconsistent input data.

Referential matching adds a third layer, checking incoming records against a trusted external reference dataset, then using that context to resolve close calls the first two methods can’t confidently settle alone. Referential and probabilistic approaches often run together, because a referential layer trims the false positives a pure probabilistic engine tends to generate.

The data elements that make or break any of these methods are consistent across approaches:

  1. Full legal name (plus any recorded aliases or previous names)
  2. Date of birth
  3. Sex/gender as recorded
  4. Address and contact details
  5. A national or state identifier where one exists (Medicare number, IHI)
  6. Sex-neutral demographic fields used as tie-breakers (postcode, next of kin)

Incomplete registration data at the point of intake is the single biggest driver of poor match quality. If reception staff skip the middle name field or leave date of birth as a placeholder, no matching algorithm downstream can compensate for what was never captured.

Most enterprise-grade systems output a three-tier result: automatic match, automatic no-match, and a “possible match” band that queues for human review. That middle band is where governance earns its keep, and where reconciliation staff spend most of their working day.

Pro Tip: Set your possible match threshold conservatively at first. A tighter threshold means more manual review work in month one, but it protects you from silently merging two different patients, an error that is far harder to unwind than a backlog of pending reviews.

What role do IHIs and HPIs play in patient identity verification?

Australia has a national patient identifier system already, and it’s worth understanding exactly what it covers before assuming it solves your matching problem outright.

The Healthcare Identifiers Service issues a 16 digit Individual Healthcare Identifier (IHI) to consumers, alongside Healthcare Provider Identifiers for individuals (HPI-I) and organisations (HPI-O). The Office of the Australian Information Commissioner confirms Services Australia administers these identifiers while the OAIC provides independent privacy oversight of how they’re used under the Healthcare Identifiers Act 2010.

In theory, an IHI is exactly the kind of persistent, unique national identifier that should make patient matching trivial. If every system consistently captured and stored a patient’s IHI, deterministic matching alone would resolve most cases. In practice, uptake and permitted use have been more limited than that promise suggests.

The constraint is legislative, not technical. The Healthcare Identifiers Act was written narrowly, and the government’s own impact analysis documents that IHIs have enabled specific national services—My Health Record and electronic prescribing chief among them—while broader use across everyday clinical and administrative systems has stayed slow and inconsistent. A defensive posture around penalties for misuse has, if anything, discouraged some organisations from building IHIs deeper into local workflows than strictly required.

Where the reform effort is headed: the Healthcare Identifiers Framework Project is currently consulting on legislative and policy changes designed to broaden permitted use of IHIs and improve interoperability between services. Anyone building or upgrading an MPI now should watch this consultation closely, because the constraints shaping today’s design decisions may loosen.

What this means practically for anyone implementing or operating an MPI:

  • Treat the IHI as a valuable matching input where it’s present and correctly captured, not as a substitute for a full matching engine.
  • Don’t design a system that fails silently when an IHI is missing. Digital Health Australia’s guidance on patient administration systems stresses that consistent IHI capture across registration sources improves linking, but many sources still won’t have it.
  • Build your core matching logic (deterministic plus probabilistic plus referential) to stand on its own, with the IHI layered in as a confidence booster rather than a load-bearing wall.
  • Keep a jurisdictional watch brief. As one industry commentary in Health Services Daily notes, states and territories are progressively aligning their own digital health blueprints to the national identifier framework, so the practical ceiling on IHI usefulness is likely to rise over the life of your system.

Why do duplicate records and overlays happen in an MPI?

Every MPI eventually accumulates errors, and the errors fall into a small number of well-understood categories that are worth naming precisely, because the fix differs for each.

A duplicate occurs when one patient ends up with two or more separate records in the index, usually because a registration clerk couldn’t find the existing record (a name misspelling, an old address, a data entry error) and created a fresh one instead. A overlay, sometimes called an overlap, is the more dangerous cousin: two different patients get merged onto a single record, usually because a probabilistic match scored too confidently on shared demographics like a common surname and matching date of birth. Fragmentation describes the broader pattern of one patient’s clinical history splitting across several unlinked records over time, often the cumulative result of unresolved duplicates never being merged back together.

The root causes cluster around a few predictable moments:

  • Registration under pressure, where reception staff at a busy walk-in clinic skip verification steps to keep a queue moving.
  • System migrations, where data from a legacy platform gets bulk-loaded into a new MPI without full reconciliation, importing years of unresolved duplicates in one pass.
  • Multiple entry points, where a patient registers via a hospital, then again via telehealth, then again via a referred allied health service, each with slightly different demographic capture rules.
  • Newborns and identity changes, where temporary names (“Baby of Smith”), later legal name changes, or gender marker updates create legitimate but tricky matching scenarios.

The consequences aren’t abstract. A duplicate record means a clinician reviewing history sees an incomplete medication list or misses a documented allergy sitting in the other, unlinked record. An overlay is worse: it can mean acting on someone else’s pathology results, allergy status, or medication history entirely. Digital Health Australia’s implementation documentation notes that these errors typically surface when multiple registration sources feed the same enterprise index with slightly different values for the same person, exactly the scenario a well-tuned matching engine exists to catch.

Detection doesn’t require exotic tooling. A few everyday signals are worth building into routine data quality checks:

  • A sudden spike in “possible match” queue volume after onboarding a new referring service.
  • Multiple records sharing an address and phone number but differing on name spelling.
  • Clinical staff manually flagging “I think this is the same patient” more than once a week for the same source system.

Pro Tip: Run a monthly report on records with identical date of birth and postcode but different surnames. It’s a cheap, five-minute query that surfaces a disproportionate share of genuine duplicates hiding in plain sight.

How should a health organisation govern an MPI?

Technology alone doesn’t fix identity errors. Governance does, and the strongest MPI programmes pair the matching engine with clear human accountability. Successful identity programmes consistently pair technical matching capability with a named clinical owner and defined escalation paths, rather than treating identity resolution as a purely IT function.

Build the governance model before you build (or rebuild) the index. At minimum, assign a clinical lead who owns patient safety implications of identity decisions, a privacy officer accountable for HI Act and Privacy Act compliance, and a data steward who owns day-to-day match quality and the possible-match queue. Without this trio, matching decisions drift to whoever happens to be logged in, and accountability disappears the moment something goes wrong.

Follow a structured rollout sequence:

  1. Audit existing identifiers across every source system feeding the index, documenting which fields are captured consistently and which aren’t.
  2. Define your matching algorithm and thresholds with clinical and privacy sign off, not just an IT vendor’s default settings.
  3. Build the integration checklist for every source system and secure messaging endpoint, including how each system will receive and act on merge notifications.
  4. Establish consent and privacy controls, mapping exactly what the HI Act permits regarding IHI use and what the Privacy Act requires for handling sensitive health information more broadly.
  5. Design the manual review workflow, including who resolves possible matches, how long they have, and what gets logged for audit.
  6. Pilot with one or two source systems before enterprise-wide rollout, watching error rates closely.
  7. Train registration and clinical staff on why identity verification at the point of intake matters, not just how to use the software.
  8. Schedule periodic re-audits, because data quality decays without maintenance.

Consent deserves particular care. The HI Act governs how IHIs specifically can be collected, used, and disclosed, while the Privacy Act’s Australian Privacy Principles apply more broadly to the health information the MPI holds. These aren’t the same obligation, and treating them as interchangeable is a common governance gap.

Governance element Owner Key risk if missing
Clinical oversight Clinical lead Identity errors go unnoticed until a safety incident
Privacy compliance Privacy officer HI Act or Privacy Act breach, regulatory exposure
Match quality Data steward Duplicate and overlay rates climb silently
Escalation pathway Named on-call role Urgent overlays sit unresolved for days
Audit logging Data steward + IT No evidence trail if a merge is later challenged

Change management matters as much as the technical build. Staff who’ve worked around a clunky legacy system for years will find workarounds for a new one too, unless training explains the patient safety stakes plainly and registration workflows are genuinely easier, not just different.

Which standards govern MPI design in Australia?

Four reference points shape how a compliant, well-built MPI should be designed and operated, and each affects a different layer of the system.

  • The Australian Core Data for Interoperability (AUCDI) standardises the data elements systems exchange, which directly affects match quality: if two systems capture “name” or “address” in structurally different formats, matching accuracy suffers regardless of how good the algorithm is.
  • Digital Health Australia’s EMPI and patient administration system guidance sets expectations for how enterprise indexes should ingest, deduplicate, and expose patient records to connected systems, and is the most practical implementation reference available.
  • The Healthcare Identifiers Act 2010 governs what you’re legally permitted to do with IHIs and HPIs, and, as covered earlier, currently limits broader operational use pending the ongoing framework reform.
  • The National Safety and Quality Health Service (NSQHS) Standards don’t mention MPIs by name, but patient identification is a recurring theme across the Standards, and a poorly governed index is a defensible audit finding waiting to happen during accreditation.

Together, these four references answer most of the “how should we build this” and “what are we allowed to do” questions a governance committee will raise. Standards also shape practical operational choices: how detailed your audit logging needs to be, whether you participate in a Healthcare Provider Directory (HPD), and what data elements you’re expected to capture at minimum during registration to remain interoperable with connected services.

How do you measure and test MPI accuracy?

You can’t govern what you don’t measure, and error-rate calculation for an MPI comes down to a small set of metrics applied consistently over time.

The two headline metrics are the duplicate rate (the proportion of patients in the index who have more than one active record, calculated as duplicate patient count divided by total unique patients) and the false-match rate (the proportion of automatic matches later found, on manual review, to be incorrect overlays). Both need a denominator big enough to be statistically meaningful, and both need periodic manual chart review to validate, because the matching engine itself is the last thing you should trust to mark its own homework.

Sampling design matters more than sampling volume. Reviewing a stratified sample, split by source system and by match-score band, gives a far more reliable estimate than reviewing a random flat sample, because most real errors cluster in specific score bands, particularly the “possible match” zone where the engine itself is least confident. Concentrating manual review effort there catches more genuine errors per hour of clinical or admin time spent.

Metric What it measures Typical data source
Duplicate rate Patients with more than one active record Automated query across the index
False-match rate Automatic matches later found incorrect Manual chart review of a sampled cohort
Possible-match resolution time Average time to clear the manual review queue Workflow/ticketing system logs
Source-system error contribution Which feeding system generates the most errors Stratified sample by source system

Automated validation checks should run continuously between formal audits: flagging records with impossible field combinations, tracking possible-match queue growth week on week, and alerting when a single source system’s contribution to the error rate spikes after an integration change. Tie corrective action to a threshold, not a gut feeling. If the false-match rate on a given source system crosses an agreed line, that’s the trigger to pause automatic matching from that source and revert to manual review until the root cause is found.

Where does AI-assisted matching fit alongside an MPI?

An MPI answers “is this the same patient?” An AI-powered coordination layer answers a different, complementary question: “which practitioner is the right fit for this patient, right now?” The two problems sit next to each other in the patient journey, and treating them as one solved system is a common design mistake.

Meddle’s platform sits in this second category. It matches patients to practitioners using an algorithm that weighs symptoms, preferences, and practitioner availability, rather than resolving identity across clinical systems. Meddle reports a high matching success rate, alongside meaningful reductions in administrative hours for the clinics using it. Where this becomes genuinely useful for identity and coordination workflows is at the referral boundary: once a patient is matched to the right allied health discipline, accurate underlying patient identity data still determines whether that referral, and the clinical history attached to it, arrives intact at the receiving practitioner.

A few things this kind of AI matching does well, and a few it deliberately doesn’t attempt:

  • Speeds up discipline and practitioner matching, cutting the time a patient waits between referral and first appointment.
  • Automates referral coordination and messaging between referring and receiving practitioners.
  • Does not replace clinical judgement or identity governance. Meddle positions itself explicitly as an augmenting tool sitting alongside, not instead of, the clinical oversight a health organisation already runs.
  • Requires the same procurement scrutiny as any system touching patient data. Teams evaluating an AI-enhanced matching layer should check its privacy safeguards, its integration approach with existing referral and records systems, and how it handles the handoff of identity data at the point of booking.

Anyone assessing this kind of platform for their own clinic should look closely at how it handles the referral and booking workflow end to end before assuming it solves identity matching on its own.

What should you do first to fix or build an MPI?

Start with a 30/90/180 day rhythm rather than a big-bang project.

In the first 30 days, audit your current duplicate and possible-match volumes, and pull together the working group: a clinical lead, a privacy officer, and a data steward, at minimum.

  1. Run the duplicate-rate and false-match sampling described above to get a baseline before changing anything.
  2. Identify which source systems contribute the most errors and why.
  3. Confirm your current IHI capture rate across registration points.

By 90 days, pilot any threshold or matching-engine change on one source system only, and measure the effect before rolling wider.

  1. Document the pilot’s error-rate change against baseline.
  2. Update registration training based on what the audit surfaced.

By 180 days, decide whether to escalate to executive sponsorship, and that decision should hinge on one thing: does fixing this require budget or authority beyond what the working group already controls? If the answer is yes, that’s the trigger, not an arbitrary calendar date.

What the research actually tells us about MPI success

The conventional advice on MPIs treats them as a procurement decision: pick a vendor, configure the matching thresholds, go live. That undersells the problem. The evidence points somewhere else entirely: the organisations with clean indexes aren’t the ones with the fanciest probabilistic engine, they’re the ones who put a named clinical lead and a privacy officer in the room before the software vendor.

What’s overrated is chasing a perfect automated match rate. Pushing thresholds aggressively to reduce manual review load is exactly how overlays happen, and an overlay is a worse patient-safety event than a duplicate sitting unresolved for a week. What’s underrated is the unglamorous discipline of registration training. Most identity errors trace back to what happened, or didn’t happen, at the front desk, not to a flaw in the matching algorithm downstream.

If you’re prioritising one thing first, prioritise measurement. You cannot govern, budget for, or defend an MPI programme to your executive team without a baseline duplicate rate and false-match rate in hand. Everything else, including whether to lean harder on national identifiers as the reform agenda progresses, follows from knowing where you actually stand today.

— Taylor

Sources

FAQ

What is the difference between an EHR and an MPI?

An electronic health record stores a patient’s clinical history and documentation; a master patient index is the underlying registry that confirms which patient a given record belongs to. The EHR depends on the MPI for accurate identity, not the other way around.

How does an MPI work in practice?

An MPI compares incoming patient demographic data against existing records using deterministic rules, probabilistic scoring, or referential matching, then assigns a single enterprise identifier once it’s confident the records belong to the same person. Uncertain cases go to a manual “possible match” review queue rather than being auto-resolved.

Is an IHI the same thing as a master patient index?

No. An Individual Healthcare Identifier is a single 16 digit number issued to a consumer under the Healthcare Identifiers Act; the MPI is the broader system that uses the IHI, alongside other demographic data, to match and link records across systems.

What causes duplicate records in a master patient index?

Duplicates most often occur when a registration clerk can’t locate an existing patient record due to a name variation, data entry error, or missing field, and creates a new record instead of matching to the existing one.

How do organisations measure MPI accuracy?

Organisations typically calculate a duplicate rate and a false-match rate, validated through stratified manual chart review focused on records that scored in the uncertain “possible match” band during automated matching.