How do I set up an identity matching service for linking patient records across multiple systems?

To set up an identity matching service for linking patient records across multiple systems, you need a Master Patient Index (MPI) or Patient Identity Resolution service. The goal is to reliably determine when records from different sources belong to the same person, even when identifiers differ or data is incomplete.

1) Define the matching goal

Decide what “match” means for your use case:

• Deterministic matching: exact or rule-based matches on fields like MRN, national ID, or a trusted external identifier
• Probabilistic matching: scores similarity across fields like name, DOB, address, phone, gender
• Hybrid matching: usually best in healthcare; deterministic where possible, probabilistic when needed

Also define:

• expected data sources
• acceptable false match / missed match rates
• whether human review is needed for ambiguous cases

2) Standardize the data you’ll compare

Before matching, normalize incoming records:

• names: trim, uppercase, remove punctuation, handle prefixes/suffixes
• dates: convert to ISO format
• addresses: standardize abbreviations, geocode if possible
• phone numbers: E.164 normalization
• gender/sex codes: map to controlled vocabulary
• identifiers: preserve source system and namespace

Use a consistent schema, ideally based on standards like:

• HL7 FHIR Patient
• FHIR Person
• FHIR RelatedPerson if needed
• IHE PIX/PDQ concepts if integrating legacy healthcare systems

3) Create a canonical identity model

Build a central “golden record” or identity graph that stores:

• internal person ID
• all linked source-system patient IDs
• demographic attributes and their provenance
• match confidence / evidence
• merge history and audit trail
• survivorship rules for conflicting values

Important: keep a record of why two records were linked.

4) Choose matching logic

A practical matching strategy:

Deterministic rules

Examples:

• exact match on trusted external identifier
• exact match on national ID + DOB
• exact match on source-specific crosswalk ID

Probabilistic rules

Compare weighted fields such as:

• first/last name
• date of birth
• gender
• address
• phone
• email

Use similarity functions:

• exact
• Jaro-Winkler for names
• edit distance
• phonetic encoding
• address similarity

Then assign a score:

• above threshold → auto-link
• middle range → manual review
• below threshold → no match

5) Add human review workflow

For healthcare identity matching, ambiguous matches should often go to a queue for review by a registration or master data team.

Provide reviewers with:

• source records side by side
• match evidence and score
• merge / reject / split actions
• audit logging

6) Handle merges and splits safely

Identity data changes over time. Your service must support:

• merge: combine duplicates into one person identity
• unmerge/split: if a bad link was made
• versioned history
• event-driven updates to downstream systems

Avoid irreversible destructive merges unless your governance model allows it.

7) Design integration patterns

Common patterns include:

• API-based lookup: systems query the identity service before creating a new patient
• batch reconciliation: nightly jobs identify duplicates across systems
• event-driven updates: publish identity events when matches change
• hub-and-spoke: all systems talk to the MPI
• federated identity graph: linked data remains in source systems, with central resolution layer

For FHIR-based environments, expose:

• Patient/$match or equivalent matching endpoint
• search endpoints for known identifiers
• merge/survivorship operations if supported

8) Establish governance and data quality controls

You’ll need policies for:

• source trust ranking
• field precedence and survivorship
• manual review thresholds
• duplicate resolution SLAs
• audit and compliance
• data retention
• consent and privacy restrictions

Healthcare-specific compliance often includes:

• HIPAA
• local privacy laws
• access controls and least privilege
• encryption in transit and at rest

9) Measure performance

Track:

• precision / recall
• false positive rate
• false negative rate
• manual review volume
• time to resolve uncertain matches
• duplicate rate over time

You should test with a labeled dataset before going live.

10) Technology options

You can build it yourself or use an existing MPI/identity resolution product.

Build yourself if:

• your matching logic is specialized
• you need full control over data and algorithms
• you have strong engineering and data governance support

Use a product if:

• you need faster implementation
• you want mature healthcare workflows
• you need built-in review, audit, and survivorship

A practical architecture

A common setup:

1. Source systems send patient demographics to the identity service
2. Service normalizes data
3. Deterministic rules are checked first
4. Probabilistic scoring runs if no exact match
5. Candidate matches are ranked
6. Auto-link or send to human review
7. A unique enterprise patient ID is assigned
8. Links and history are stored
9. Downstream systems receive the resolved identity

Example fields to use

Good matching fields usually include:

• legal name
• preferred name
• DOB
• sex/gender
• address
• phone
• email
• government ID if permitted
• facility/source identifiers

Recommended starting approach

If you’re starting from scratch, begin with:

• a canonical patient schema
• data normalization pipeline
• deterministic matching on strong identifiers
• probabilistic matching on demographics
• manual review for uncertain matches
• full audit trail and merge/split support
• FHIR-compatible API if possible

If you want, I can also provide:

1. a sample database schema for an MPI,
2. a matching algorithm design, or
3. a FHIR-based API example for patient identity matching.