Patient matching looks like a database problem until the wrong two records touch each other. Then it becomes a clinical workflow problem, a support problem, and sometimes a very awkward phone call.
Healthcare software spends a lot of time moving data between systems that were bought in different years, configured by different teams, and fed by humans typing under pressure. Names change. Addresses go stale. Birth dates get transposed. A parent uses a child's phone number. Two people in the same house share almost every obvious identifier. The matching layer has to respect that mess without pretending it can solve identity by vibes.
What is patient matching supposed to decide?
The first decision is whether two records describe the same person strongly enough for the workflow in front of you. That last clause matters. Matching for a read-only patient search is different from matching before you merge charts, import lab results, send outreach, or write back to an EHR.
A good system separates candidate discovery from final action. It can say, "these records might be the same person," without immediately treating them as one record forever. That distinction keeps useful automation from becoming irreversible automation.
Which fields should matter?
Use more than one identifier, and be honest about the quality of each one. Date of birth is useful, but it is not magic. Phone numbers and addresses can be shared or old. Names need normalization, but aggressive normalization can erase meaningful differences. Insurance member IDs, medical record numbers, and source-system IDs can be strong inside a narrow context and misleading outside it.
I prefer matching models that show their work in plain product terms: exact date of birth, similar first name, same phone, different address, source system already linked. The reviewer should not have to reverse-engineer why the software feels confident.
When should the software stop and ask for review?
Ambiguous matches deserve a queue, not a guess. If two candidate records are close enough to be plausible but not close enough to act on, route them to a human with the evidence visible. Put the proposed match, the conflicting fields, the source systems, and the downstream consequence on the same screen.
The review path needs to be fast because identity cleanup can become a hidden tax on operations. If every import creates a pile of low-quality match decisions, the team will start working around the product. That is usually when duplicates multiply quietly.
How should duplicate records be handled?
Duplicate records are normal in real healthcare systems. The product should treat them as a managed state, not as shameful data hygiene nobody talks about. A duplicate can be suspected, confirmed, linked, merged, or rejected. Each state needs an owner and an audit trail.
Merging is the dangerous step. Before a merge, preserve the original source records, show what will happen to appointments, notes, messages, claims, consents, and external references, and make rollback a designed workflow instead of a database favor from the one engineer who knows the tables. The boring recovery path is part of the feature.
What should teams measure?
Measure false matches and missed matches separately. A false match can attach information to the wrong patient. A missed match creates duplicates and extra work. Both are expensive, but they fail differently.
Track how many records go to review, how long review takes, which fields cause conflict, which source systems create the most ambiguity, and how often a human reverses an automated decision. Those numbers tell you whether the matching system is improving or just moving uncertainty into support.
What is a safe starting point?
Start narrow. Use deterministic rules where the identifiers are strong, score softer signals where they help, and keep a human review path for the cases that can hurt people or corrupt the record. Do not let the matching layer silently merge or write across systems until the team has watched enough real traffic to trust its failure modes.
For example, two records might share a surname, address, and household phone but have different birth dates. Show both as candidates with the conflict visible; do not merge them from those shared fields alone. The reviewer needs additional evidence before a write can proceed.
If your team is working through this, I am always glad to compare notes.