All posts

Building a Master Patient Index for a hospital chain — probabilistic matching at 50M records

AJ
AJ FHIR Platform
20 May 2026 · 10 min read
10 min read
JamMPI Patient Identity Golden Records ITI-78 ITI-83 PMIR

The identity problem in a hospital chain

Patient A attends Branch 01 as MRN12345. The same patient attends Branch 03 as PRIV-9901. Without a Master Patient Index, these are two different patients in the FHIR store — and JamGuard cannot detect the Warfarin prescribed at Branch 01 interacting with the Aspirin prescribed at Branch 03.

The three matching strategies

JamMPI runs three strategies in combination on every Patient/$match call:

1. National ID exact match

If the PID segment contains a national identity number (NIC, NHS number, Aadhaar), this is the primary key. A match earns CERTAIN grade (score ≥ 0.95). The comparison is a constant-time string equality check — no probabilistic scoring needed.

2. Jaro-Winkler name + date-of-birth similarity

Family name, given name, and date of birth are scored together using a weighted combination of Jaro-Winkler string distance and exact date comparison. Above the configurable threshold (default 0.85), the match is PROBABLE.

3. Blocking strategy

Without blocking, matching a single patient against 50M records would require 50M comparisons. JamMPI pre-filters candidates by matching the first 3 characters of family name and birth year — reducing the comparison space from O(n) to O(k) where k is typically under 500.

The golden record

Every patient in JamMPI has a golden record — a single canonical FHIR Patient resource that aggregates identifiers from all branches. JamBridge stamps the golden ID on every resource it writes:

{
  "link": [{"type": "refer", "other": {"reference": "Patient/GOLDEN-00441"}}],
  "extension": [{"url": "http://jammpi.io/ext/golden-record-id", "valueString": "GOLDEN-00441"}]
}
Filed under Patient Identity  |  JamMPI Patient Identity Golden Records ITI-78 ITI-83 PMIR
Previous article FHIR Consent resource in practice — mapping GDPR, HIPAA, and DISHA to provision fields Next SMART App Launch v2.2 — what most implementations get wrong about the token response