ChatGPT
Perplexity
When one patient exists as two records in your EHR and your claims file, cross-source patient identity resolution is the thing that decides whether every count downstream reads them as one person or two.
Most teams know this and handle it as a cleanup task, judged by how many duplicates got merged last quarter. That number gets reported. It usually looks fine.
What it leaves out is who failed to link, and that group is not a cross-section of your patients. It is weighted toward the people who have been to the most places, which is the same group your risk numbers lean on hardest.
One caveat before the evidence. Everything published on this comes from large health systems, health information exchanges, and national research networks. Nobody has measured it at the scale most of you operate, so treat the mechanisms as transferable and the magnitudes as theirs.
Why unresolved patient duplicates cluster around your highest-utilization patients
Why this goes unnoticed
Something in your stack decides whether two records belong to the same person. It might be logic inside the EHR, a master patient index product, or a mapping table somebody wrote three years ago.
Whatever it is, it reports how many duplicates it merged and says nothing about the ones it left alone. Those sit in a queue that gets reviewed for volume, and nobody asks what the patients in it have in common.
What the research found
PCORnet, a national research network, assembled about 170 million patient records from its partner sites. When they checked how many belonged to distinct people, roughly 1 in 5 turned out to be a second copy of somebody already counted.
They then joined the electronic health record data to claims data for the same people. Every clinical characteristic they measured moved up. Rates that had looked settled came in 63% to 173% higher once the records for one person were connected.
Nothing was wrong with the original counts. They were counting a version of the population with pieces of people missing from it.
What this costs you
Your population figures understate the group you most need to see. Risk stratification reads the high-need cohort as smaller and healthier than it is. Any model trained on that population learns from a version of it with the heaviest users thinned out.
How to check
Take last month’s unmatched records and compare them against the matched set on the two or three variables your use case depends on. Encounter count is the fastest one. If the unmatched group averages more visits, your figures are shifted, and you can size the shift.
Stay updated with Simform’s weekly insights.
Why probabilistic and referential matching report the same accuracy and find different patients
Why this goes unnoticed
Vendors lead with accuracy, and on that measure the tools are genuinely close. The figure that separates them is the one nobody puts on a slide.
What the research found
Regenstrief researchers hand-checked 30,000 record pairs from an exchange holding more than 47 million patient registrations, so they knew the true answer for every pair. Then they ran two matching methods against it.
Both were almost never wrong about the matches they made. When either one declared two records the same person, it was right about 999 times out of 1,000.
The gap showed up in what each one found at all. Out of every 100 patients who genuinely had a duplicate sitting in the system, probabilistic matching caught 64. Referential matching caught 94.
The technical names for those two measures are positive predictive value and sensitivity. Only the first tends to appear in a vendor deck.
What this costs you
Take a system holding a million patients where roughly 5% have a duplicate sitting somewhere in it. The weaker method leaves about 18,000 of those patients split across two records. The stronger one leaves around 3,000. Same accuracy on paper, six times the unresolved population underneath.
Those 18,000 are counted twice in every report that runs off the system. Clinicians see part of a history and act on it. And when the vendor renewal comes around, the number in the deck says both products perform at 99.9%.
How to check
Ask your vendor for both figures, measured on a reviewed sample of your own data. If only one number comes back, you have learned which one flatters the product.
Microsoft Fabric resolves identity inside each source and stops at the boundary between them
Why this goes unnoticed
Nothing breaks. The pipeline finishes, the tables fill, and the dashboards refresh on schedule. A patient sitting there as two people produces no error anywhere, because from the system’s side both records are valid.
What the documentation says
Microsoft’s documentation for healthcare data solutions sets out how Fabric handles this. In the reference architecture, an ID gets built for each record from the source system name together with details from the record itself. Two entries from the same EHR for the same person land on the same ID, so duplicates inside that system get caught.
The same person’s record in your claims file gets a different ID, because the source name is part of what produced it. Connecting those two IDs is work you supply, usually through a mapping table that says they are one human being.
That is a design choice with a reason behind it. Deciding when two people with the same name and birth date are the same person is a judgment about your data and your risk tolerance, and no platform can make it for you.
What this costs you
Without that mapping, a patient who appears in both your EHR and your claims file is two people in every report either one feeds. The reports are not wrong about what they were given. Nobody decided what they should have been given.
How to check
Pick one dashboard your leadership team looks at. Trace it back and find out whether anything joined the source systems before those numbers were produced. If nothing did, that dashboard is counting source records and calling them patients.
What this looked like in practice
We built a Fabric data foundation for a global CDMO where the presenting problem was manual reporting effort, not identity. What moved the number was settling what the layers underneath had to agree on before any BI report ran off them, and manual reporting effort came down by half.
The identity question has the same shape. It gets decided before the outputs are trusted, or it gets discovered after somebody notices a figure moved.
The matching threshold you set for the first use case becomes the rule for every use case
You can scope this work. Resolving identity for one use case is defensible, and doing the whole estate before anything ships is how programs stall. What lasts is the rule underneath it.
Somebody decides how similar two records have to be before they count as one person. Same last name and birth date, close enough? Different middle initial, still the same patient? That call gets made once, for one project, and the next project reuses it because it already exists.
Where that number sits also determines which way you fail. Set it loose, and you merge two people who are not the same patient, putting one person’s history in front of a clinician treating another. Set it tight, and you keep the split records the earlier sections describe.
Six months on, a rule written for a billing report is deciding whom your clinical dashboards treat as one human being. Make it deliberate the first time, with whoever owns the clinical risk in the room.
If you are working through the architecture side, Ritesh Shah and Tanguy Carrere walk through consolidating multi-modal patient data in OneLake on August 27, including where identity resolution sits in the flow. You can reserve a spot here.
