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.