Skip to main content

Cross-branch patient identity

The hardest problem in a hospital chain is not the integration — it is the identity. A patient 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.

The golden record

JamMPI maintains a golden record for each patient. Every time JamBridge receives a message, it calls JamMPI's Patient/$match to resolve the patient to a golden record ID.

Branch 01: Patient/MRN12345 ─┐
Branch 03: Patient/PRIV-9901 ─┼──► Patient/GOLDEN-00441
Branch 07: Patient/H-20891 ─┘

The golden record ID is stamped on every FHIR resource:

{
"resourceType": "Patient",
"link": [{"type": "refer", "other": {"reference": "Patient/GOLDEN-00441"}}],
"extension": [{"url": "http://jammpi.io/ext/golden-record-id", "valueString": "GOLDEN-00441"}]
}

Every downstream system that queries HAPI by golden ID gets all records from all branches.

Matching algorithm

Three strategies in combination:

National ID exact match (CERTAIN)

If PID-3 carries a national ID (NIC, NHS number, Aadhaar), this is the primary key. Constant-time string equality. Score ≥ 0.95.

Jaro-Winkler + DOB (PROBABLE)

Family name, given name, and date of birth scored together. Jaro-Winkler gives extra weight to matching prefixes — correct for human names. Above threshold (default 0.85). Score ≥ 0.85.

Blocking strategy

Pre-filter candidates by first-3-chars of family name and birth year before running Jaro-Winkler. Reduces comparison space from O(n) to O(~500) even at 50M records.

When no match is found

If no candidate meets min-grade, JamBridge creates a new patient resource without a golden link. The patient appears in the FHIR store as an unlinked record. A daily JamMPI reconciliation job re-runs matching on unlinked records and proposes merges for human review.

Manual merge / unmerge

JamMPI provides an admin UI for reviewing POSSIBLE-grade matches and approving or rejecting merges. All merge decisions are audited.