In EHR integration, the safe way to match patients is to rely first on the identifier the hospital's EHR already trusts. That is its own patient ID or MRN, tied to the system that issued it. Use exact rules when you have that ID. Use scored matching only for the cases where you don't, and send every uncertain result to a human instead of letting your system guess.
You probably know the situation. Your product collects patient details at intake. The hospital has its own records in Epic, Oracle Health or something older. Somebody has to decide whether "Jon Smith, 07/03/1984" in your database is the same person as "Jonathan Smith, 03/07/1984" in theirs. If you decide wrong one way, you create a duplicate. If you decide wrong the other way, you attach one patient's results to someone else.
Why is patient matching hard when both systems have the data?
The US has no national patient identifier, and the data people type in is messy. An MRN is only unique inside the facility that issued it. So an MRN from one hospital means nothing to the clinic down the road, and it means nothing to your app unless you store which system it came from.
The usual ways matching fails are predictable:
- Day and month swapped in a date of birth, especially when staff or patients use different date formats.
- Name changes after marriage or divorce, hyphenated surnames, nicknames, and first and middle names entered the wrong way round.
- Twins and family members who share a surname, an address, a phone number and sometimes an insurance subscriber ID.
- Newborns registered as "Baby Girl Patel" and renamed days later.
- Junior and senior with the same name at the same address.
Every one of these looks like a perfect match on some fields and a clear mismatch on others.
Deterministic or probabilistic matching: which should you use?
Use both, in that order. Deterministic matching links records only when specific fields agree exactly, for example the same MRN from the same issuing system. Probabilistic matching gives each field a score and adds them up.
Deterministic rules are predictable and easy to explain to a hospital's compliance team. Their weakness is that a single typo means no match, so you get duplicates.
Probabilistic matching, usually based on the Fellegi-Sunter model, handles messy data better. A matching rare surname counts for more than a matching "Smith". A matching date of birth counts for more than a matching sex. You then set two thresholds:
- Above the upper threshold: link automatically.
- Below the lower threshold: treat as a new or different patient.
- In between: send to human review.
If the hospital supports the FHIR Patient/$match operation, it will return candidates with a grade such as certain, probable or possible. Treat only "certain" as safe to link without a person checking. A "probable" result is still a guess.
Which identifiers should you rely on?
Not all fields deserve the same trust. This is a sensible starting order:
| Identifier | Trust | Why |
|---|---|---|
| EHR patient ID or MRN plus issuing system | High | It is the hospital's own key, but only within that system |
| Date of birth | High | Stable, but watch for day and month swaps |
| Legal first and last name | Medium | Changes over a lifetime, and spellings vary |
| Phone and email | Medium | Families share them, and numbers get recycled |
| Last four of SSN | Medium | Useful when present, often missing, and sensitive to store |
| Sex | Low | Too few values to tell people apart, and it can change |
| Address | Low | People move, and households share it |
One field should never be enough by itself: the insurance member ID. Dependants often share the subscriber's number, and it changes when the employer switches plans.
Once a link is confirmed, store the EHR's patient ID against your record. From then on, match on that ID and stop re-matching on demographics.
What does it cost you to get this wrong?
Duplicates are the mild failure. A patient's history gets split across two records, so a clinician may miss an allergy or order a test that was already done. Someone at the hospital then has to find and merge the records by hand.
Overlays are the serious failure. An overlay is two different people merged into one record. Lab results, notes and medications go to the wrong person. That is a clinical safety problem and a privacy disclosure at the same time. Separating the records afterwards is slow, manual work, and some hospitals will switch off an interface until it has been cleaned up.
Trust matters too. Hospital integration teams remember the vendor whose feed created a mess, and that memory comes back at contract renewal and in reference calls.
When do you not need any of this?
If your app runs inside the EHR through a SMART on FHIR launch, the EHR tells you which patient is open. There is nothing to match. The same goes for an app that only receives patients from the hospital's ADT feed with the MRN attached.
In those setups, store the ID the EHR gives you and handle merge events properly. You only need matching logic when your system creates patients on its own, for example through self-registration, a referral form or a partner's data, and then has to connect them to hospital records.
How should the human review queue work?
The queue is where uncertain matches get settled, so it needs an owner, a clear screen and a record of every decision.
Show both records side by side with the differing fields highlighted. Give the reviewer three choices: same person, different people, or needs more information. Save the decision, the reason and the reviewer's name.
While a match is pending, hold the clinical data for that patient. Do not create a placeholder record that someone will have to merge later. Remember every "different people" decision so the same pair is not flagged again next week.
Track how long items sit in the queue. A queue nobody works is worse than having no queue, because it hides data clinicians expect to see. Review the decisions every month and use them to adjust your thresholds.
What should you require from the team before any patient data syncs?
Before a single record moves, ask your team or vendor for these:
- A written matching policy, agreed with the hospital's health information management team. They own record integrity, and they will have to live with your rules.
- A test set of hard cases (twins, name changes, swapped dates, newborns) built from synthetic or de-identified data, with the expected result written down for each one. Without it, nobody can tell whether a threshold works.
- Thresholds set from test results, not guessed. Guessed numbers drift towards whatever clears the backlog fastest.
-
Handling for EHR merges and unmerges, through HL7 v2 ADT A40 messages or the FHIR
Patient.link"replaced-by" field. Hospitals merge records all the time, and your links have to follow. - An audit trail for every link and unlink, so you can answer when a record was linked, why, and by whom.
- A way to unlink. If a link cannot be reversed, an overlay becomes permanent.
- A dry run period where matching runs against the real feed without writing anything, so you can review the results first.
- Monitoring of new duplicates, queue size and manual overrides, with alerts when any of them jumps.
A good question for any vendor: "Show me what your system does when the EHR merges two patients we have already linked." A vague answer tells you what you need to know.
If you are planning an integration and want a second opinion on your matching approach, our guide to healthcare app development covers the wider build. You can also send your plan to Geminate Solutions for a free review. We sign an NDA before we talk and reply within 24 hours.
Top comments (0)