# Master Patient Index: The Hidden Foundation Every Healthcare System Depends On

> How patient identity management actually works — deterministic vs probabilistic matching, IHE PIX/PDQ profiles, Global Patient ID reconciliation, and why getting MPI wrong is the most expensive mistake in healthcare IT.

Author: Ala Ben Aicha

Canonical page: https://alabenaicha.me/insights/master-patient-index-identity-management

Updated: 2026-10-05

## The Problem That Breaks Everything Else

Every healthcare integration project I have worked on eventually comes down to one question: **is this the same patient?**

It sounds simple. It is not. A patient named "Max Müller" born on March 15, 1985, is admitted to Hospital A and assigned MRN H-A-12345. The same person visits a radiology center and gets MRN RAD-67890. They have a prescription at a pharmacy under a third ID. Their insurance company knows them by yet another number. And in the Swiss EPD, they have an EPD-MPI-ID that is different from all of the above.

If your systems cannot reliably determine that all of these records belong to the same person, nothing else works. Lab results go to the wrong chart. Medications are prescribed without knowing what the patient is already taking. Billing claims are rejected because the patient identity does not match across systems. And in the worst case, clinical decisions are made based on someone else's medical history.

This is why the **Master Patient Index (MPI)** is not a nice-to-have infrastructure component — it is the foundation that every other integration depends on. And getting it right is significantly harder than most organizations realize.

## How Patient Identity Matching Works

An MPI maintains a registry of patient identities across all connected systems and uses matching algorithms to determine when records from different systems refer to the same person.

### Deterministic Matching

Deterministic matching looks for **exact matches on high-confidence identifiers**. If two records share the same Swiss AHV number (756.1234.5678.90), they are the same person. No ambiguity.

```
Record A (Hospital EHR)          Record B (Lab System)
┌──────────────────────┐         ┌──────────────────────┐
│ MRN: H-A-12345       │         │ MRN: LAB-67890       │
│ Name: Max Müller     │         │ Name: M. Mueller     │
│ DOB: 1985-03-15      │         │ DOB: 1985-03-15      │
│ AHV: 756.1234.5678.90│         │ AHV: 756.1234.5678.90│
└──────────────────────┘         └──────────────────────┘
                    │                 │
                    └────────┬────────┘
                             │
                    Deterministic Match
                    (AHV numbers are identical)
                             │
                    ┌────────▼────────┐
                    │  Global Patient  │
                    │  ID: GP-001      │
                    │                  │
                    │  H-A-12345 ═══╗  │
                    │  LAB-67890 ═══╝  │
                    └─────────────────┘
```

Deterministic matching is reliable but limited. It only works when:

* Both systems capture the same identifier (not always the case)
* The identifier is entered correctly (typos in ID numbers are common)
* The identifier exists (newborns, emergency patients, and tourists may not have national IDs)

### Probabilistic Matching

When deterministic matching fails — and it fails frequently — the MPI falls back to **probabilistic matching**. This uses statistical algorithms to calculate a "match score" based on multiple demographic fields.

The algorithm considers:

| Field         | Match Weight | Rationale                                         |
| ------------- | ------------ | ------------------------------------------------- |
| Date of Birth | High         | Rarely changes, relatively unique                 |
| Last Name     | Medium-High  | Stable but affected by marriage, transliteration  |
| First Name    | Medium       | Nicknames, abbreviations (Max vs Maximilian)      |
| Gender        | Low          | Low discriminating power but useful for filtering |
| Address       | Low-Medium   | Changes frequently, useful for disambiguation     |
| Phone Number  | Medium       | Changes but useful when available                 |

For each pair of records, the algorithm calculates a composite score. If the score exceeds a **high-confidence threshold** (e.g., 95%), the records are automatically linked. If the score falls between a **review threshold** (e.g., 80-95%), the match is flagged for manual review by a data integrity analyst. Below the review threshold, the records are treated as distinct patients.

**The Müller Problem:**

In Switzerland and across German-speaking Europe, names like Müller, Meier, Schmidt, and Fischer are extremely common. A probabilistic matcher might encounter:

* Max Müller, born 1985-03-15, Zurich
* Max Mueller, born 1985-03-15, Zürich
* Maximilian Müller, born 1985-03-15, Zurich

The first two are almost certainly the same person (ü vs ue transliteration, Zurich vs Zürich). The third might be the same person (Max as a nickname for Maximilian) or a different person entirely. The MPI must be tuned to handle these cases correctly — and "correctly" varies by organization based on their tolerance for false positives vs false negatives.

### The Consequences of Getting It Wrong

**False positive (duplicate merge):** Two different patients are incorrectly linked into one record. Patient A receives Patient B's medication list. This is a direct **patient safety risk** — potentially life-threatening if allergies or contraindications are missed.

**False negative (duplicate creation):** The same patient exists as two separate records. Their clinical history is fragmented. A clinician sees an incomplete picture. Lab results from last week's visit are in one record while today's visit is in another. This leads to duplicate testing, incomplete decision-making, and billing complications.

Both errors create operational and clinical risks. Measure duplicate records, false matches and review effort in the actual population; generic cost estimates cannot establish the cost for a particular hospital.

## IHE Profiles for Patient Identity

The healthcare industry standardizes patient identity operations through **IHE (Integrating the Healthcare Enterprise) profiles**. These define exactly how systems should query and update patient identity across organizational boundaries.

### PIX — Patient Identifier Cross-Referencing

PIX is the profile I implement most frequently. It allows a system to ask: "I know this patient as MRN H-A-12345. What is their ID in the lab system?"

**PIX transactions:**

| Transaction             | Code                      | Purpose                                                            |
| ----------------------- | ------------------------- | ------------------------------------------------------------------ |
| Patient Identity Feed   | ITI-8 (v2) / ITI-44 (v3)  | Register or update a patient identity in the MPI                   |
| PIX Query               | ITI-9 (v2) / ITI-45 (v3)  | Look up cross-referenced identifiers for a known patient           |
| PIX Update Notification | ITI-10 (v2) / ITI-46 (v3) | Notify subscribing systems when identifiers are linked or unlinked |
| Mobile PIX Query        | ITI-83 (FHIR)             | FHIR-based identifier cross-reference query                        |

In the Swiss EPD context, when a hospital system needs to find a patient's EPD-MPI-ID, it sends a PIX query to the community's patient identity manager. The response includes all known identifiers for that patient across participating systems.

### PDQ — Patient Demographics Query

PDQ allows searching for patients by demographic criteria when you do not have any identifier. A clinician entering "Müller, March 1985" into a search box triggers a PDQ query.

| Transaction                | Code                      | Purpose                                                                            |
| -------------------------- | ------------------------- | ---------------------------------------------------------------------------------- |
| Patient Demographics Query | ITI-21 (v2) / ITI-47 (v3) | Search by name, DOB, gender, address                                               |
| Mobile PDQ                 | ITI-78 (FHIR)             | FHIR-based demographic search (`GET /Patient?family=Mueller&birthdate=1985-03-15`) |

### PMIR — Patient Master Identity Registry

PMIR is the newer FHIR-native profile that combines PIX and PDQ functionality into a single, modern framework. It uses FHIR Subscription resources to notify systems of identity changes in real time. For new implementations, I recommend PMIR over the legacy PIX/PDQ profiles.

## Building the Identity Reconciliation Pipeline

When I integrate a new system into an existing healthcare environment, the identity reconciliation pipeline follows a specific pattern:

```
Inbound Patient Data
(from new system)
        │
        ▼
┌──────────────────┐
│  1. Parse Data   │  Extract demographics from HL7 PID
│                  │  segment or FHIR Patient resource
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  2. Normalize    │  Standardize name formats, address
│                  │  formats, date formats, phone formats
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  3. Extract PHI  │  Isolate identifiable fields for
│                  │  privacy-safe matching operations
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  4. Query MPI    │  Deterministic check first (exact ID
│                  │  match), then probabilistic if needed
└────────┬─────────┘
         │
    ┌────┴────┐
    │         │
 Match     No Match
    │         │
    ▼         ▼
┌────────┐ ┌────────────┐
│ Link   │ │ Create New │
│ to     │ │ Global     │
│ Global │ │ Patient    │
│ Patient│ │ Record     │
│ ID     │ │            │
└───┬────┘ └─────┬──────┘
    │             │
    └──────┬──────┘
           │
           ▼
┌──────────────────┐
│  5. Store with   │  Clinical data is stored linked to
│  Global Patient  │  the verified Global Patient ID
│  ID              │
└──────────────────┘
```

### The Normalization Step

This step is more important than most developers realize. Before matching can work reliably, patient data must be normalized:

* **Name normalization** — "Dr. Max J. Müller-Schmidt" becomes structured components: prefix="Dr.", given="Max", middle="J.", family="Müller-Schmidt"
* **Transliteration** — "Müller" and "Mueller" are recognized as equivalent (critical in multilingual Switzerland)
* **Address standardization** — "Bahnhofstr. 12" and "Bahnhofstrasse 12" are the same address
* **Phone normalization** — "+41 44 123 45 67" and "044 123 45 67" are the same number
* **Date parsing** — "15.03.1985" (European format) and "1985-03-15" (ISO format) must be correctly handled

I implement these normalization rules as a shared library within the integration engine, so every channel applying identity logic uses the same rules consistently.

### The PHI Extraction Step

When performing identity matching — especially in distributed architectures — it is essential to minimize the exposure of Protected Health Information (PHI). The pipeline extracts only the demographic fields needed for matching and performs the MPI query with these fields alone. Clinical data (diagnoses, medications, lab results) never enters the matching pipeline.

This is particularly important in the Swiss context, where the Federal Act on Data Protection (FADP/nDSG) imposes strict requirements on health data processing. The identity matching service should operate on a minimum-necessary data principle.

## MPI Architecture in the Swiss EPD

The Swiss EPD's federated community model creates unique identity management challenges. Each EPD community (Stammgemeinschaft) operates its own patient identity infrastructure, and cross-community patient identification uses the XCA and XCPD profiles.

```
Community A (CARA)                Community B (AD Swiss)
┌────────────────────┐            ┌────────────────────┐
│  Patient Identity  │            │  Patient Identity  │
│  Manager           │            │  Manager           │
│  ┌──────────────┐  │            │  ┌──────────────┐  │
│  │ MPI-A        │  │            │  │ MPI-B        │  │
│  │ GP-A-001 ═══►│──┤    XCPD    ├──│◄═══ GP-B-042 │  │
│  │ (Max Müller) │  │◄──────────►│  │ (Max Müller) │  │
│  └──────────────┘  │            │  └──────────────┘  │
│                    │            │                    │
│  EPD-MPI-ID:       │            │  EPD-MPI-ID:       │
│  2.16.756...001    │            │  2.16.756...001    │
│  (same person)     │            │  (same person)     │
└────────────────────┘            └────────────────────┘
```

The EPD-MPI-ID is the "golden" identifier that links a patient's records across all communities. When a clinician in Community B needs records from Community A, the system:

1. Looks up the patient's EPD-MPI-ID via PIX
2. Sends a cross-community query (XCA ITI-38) to Community A using this ID
3. Community A returns the patient's document references
4. The clinician retrieves the actual documents (XCA ITI-39)

This cross-referencing chain is only as reliable as the identity matching at each step. A mismatch at any point in the chain means the wrong records — or no records — are returned.

## Practical Recommendations

### 1. Invest in Data Quality at the Source

The best MPI in the world cannot fix garbage input. Implement front-end validation on patient registration forms: mandatory fields, format validation, duplicate checks at the point of entry. Every record that enters the system clean saves exponentially more effort than cleaning it later.

### 2. Tune Your Matching Thresholds Carefully

There is no universal "correct" threshold for probabilistic matching. A hospital in a small Swiss canton with a homogeneous population can use higher auto-merge thresholds than a university hospital in Zurich that serves an international population with diverse naming conventions.

### 3. Build a Data Stewardship Process

Automated matching handles the clear cases. But the ambiguous matches — those in the "review zone" between auto-merge and auto-separate — require human review. Invest in a data integrity team with clear workflows, SLA targets, and escalation paths.

### 4. Monitor Duplicate Rates Continuously

Track your duplicate rate as a key metric. Set thresholds from local data, false-match risk and review capacity; no single duplicate-rate target fits every institution.

### 5. Plan for FHIR-Native Identity

If you are building new integrations, implement PIXm/PDQm (FHIR-based) rather than the legacy v2/v3 profiles. The PMIR profile is the future direction, and investing in it now avoids a second migration later.

## Conclusion

Patient identity management is the unglamorous but absolutely critical foundation of healthcare interoperability. Without reliable identity matching, every integration — from lab result routing to cross-border EPD access — is built on sand.

For a scoped review of identifiers, matching rules and reconciliation workflows, use the project contact route. Define the identity policy with the organization responsible for the clinical record.