Patient Matching Without Duplicate Charts

The caller is almost always someone the practice already knows. So the first thing that happens on a call, before a slot is offered or anything is written, is deciding which existing patient this is. The hard version of that job is being willing to fail it: creating a record because the match was merely probable is how one clinical history quietly becomes two.

A duplicate chart is a defect with a delayed cost. Nothing breaks on the day. The appointment is booked, the patient attends, and the practice now holds two records where it should hold one. The damage lands months later, on a clinician who was not on the call, reading a chart that is missing half a history.

That asymmetry, cheap to create and expensive to discover, is why the matching logic refuses rather than resolves. It is worth walking through how it actually decides.

Matching from a web form is comparatively easy. The data arrives typed, the fields are labelled, and the person entering it can be asked to fix a mistake.

A phone call gives none of that. Names arrive spoken, so spelling is a guess and transliteration varies: the same person is Mohammed, Muhammad or Mohamed across three systems. Nicknames dominate, and no exact string comparison connects a record that reads Margaret to a caller who says Peggy.

Telephone numbers look like the strongest identifier and are frequently shared. A household number matches four people, a care home number forty. Matching on the number alone is the exact shape of a confident wrong answer. Date of birth is the most reliable field available and is still not unique, because in any sizeable list some people share one.

Matching is generation, then scoring

The mechanism is two steps, and most of the failure modes live in the second.

First, candidate generation. The agent pulls a small set of possible records from the practice list using the strongest key it has, usually the phone number or the date of birth. This narrows a list of 40,000 patients to a handful of candidates without deciding anything yet, which matters because scoring every record on every call would be both slow and pointless when the phone number alone rules out all but a few.

Then, scoring. Each candidate is scored across the identifiers that agree: name similarity handled phonetically so Peggy reaches Margaret and Mohamed reaches Mohammed, date of birth as an exact match, telephone number, and address where present. The scores are weighted, because a shared birth date is weaker evidence than most people assume and a phonetic name match is stronger than a raw string comparison suggests.

The phonetic step is not a fuzzy string match. It maps a name to how it sounds, so a transliteration and a nickname can both reach the same record, without the loose character comparison that would also drag in genuinely different people who merely spell alike.

The decision then turns on two numbers, not one. The top candidate has to clear a confidence threshold, and the margin between the top candidate and the second has to be wide enough. A high top score with a close runner-up is not a match, it is two plausible people, and the margin is what catches that. Identity is also confirmed against a date-of-birth match within the first 10 seconds, at the Understand stage of the call, so the caller is tied to a record early rather than at the moment of the write.

What ambiguity should trigger

Situation	Tempting behaviour	Correct behaviour
Two records, same birth date, similar name	Choose the more recent	Escalate to a person
Shared household number, nothing else	Choose the frequent caller	Ask for a second identifier, then escalate
Name matches, no birth date given	Proceed on the name	Ask, then escalate if unresolved
Slight spelling variance, all else agrees	Escalate	Proceed, this is a confident match

The bottom row matters as much as the others. A system tuned so cautiously that it escalates every spelling variant is useless and gets switched off. The goal is not maximum caution, it is calibration: confident when the evidence is there, unwilling to guess when it is not.

The three outcomes

Every attempt ends in one of three states, and the design is mostly about being honest which one it is in.

A confident single match. The top candidate clears the threshold and nothing else is close. Proceed.

No match. Nothing plausible exists, so this is a new patient, and creating a record is correct where the practice permits it on a call.

Ambiguous. Two or more candidates are plausible, or one is plausible but weak. This is where products differ, and the wrong move is to take the best candidate. It is wrong even when the best candidate is usually right, because the cost of the occasional error is a split chart nobody notices for months and the saving is a single handover.

The cases that come up weekly

Three situations worth knowing how any vendor handles, because they are common, not rare.

The caller acting for someone else. A parent booking for a child, an adult about a parent. The identity to resolve is not the caller's, and a system that assumes otherwise attaches the appointment to the wrong chart.

The patient whose details changed. A new surname, a new number, a new address. Strict matching on stale identifiers fails exactly the patients who most need continuity.

The genuinely new patient who shares a name and rough birth date with an existing one. Here creating a record is correct, and a cautious system will escalate, which feels like a failure and is the right outcome.

What 2care does with an uncertain match

2care resolves the caller against the practice's own record before anything is created, over each system's official API rather than a parallel copy, so the match is made against the same chart the clinicians read. That single-source choice is the one behind why we skip nightly syncs.

The rule it follows is strict on creation and permissive on recognition. It will accept a nickname, a spelling variant or a changed number as the same person when the other identifiers agree. It will not create anything new while two candidates are plausible. Where the match is ambiguous, the call is handed to a person within about 4 seconds, with the candidate records already gathered, rather than resolved on probability. That costs a handover on a small share of calls and prevents the failure that is expensive and invisible.

New-patient creation, where the practice allows it on a call, is a separate path from the ambiguity path by design. A genuine new patient is not the same thing as an unresolved existing one, and treating them alike is how duplicates are made at scale.

What ambiguity costs at realistic rates

The trade is between handovers and duplicate charts, and it is worth rough numbers on both sides.

Thirty-two handovers a month is a visible, tolerable cost. Thirty-six split charts a year is an invisible, compounding one that surfaces mid-consultation. That asymmetry is the whole justification for escalating rather than guessing.

Why matching needs a signed agreement

Resolving a caller against a patient list is processing protected health information, not transmitting it.

Under HHS guidance the conduit exception covers a vendor with only transient access to what it transmits. Querying a patient list, comparing identifiers and returning a match is none of that, so a signed agreement is required, and it should say which identifiers are retained and for how long.

2care signs a business associate agreement, encrypts patient data with AES-256 at rest and TLS 1.2 or better in transit, and does not use patient data to train shared models. What each framework covers is on the compliance page.

Where this is the wrong fit

Two situations, both worth anticipating rather than discovering.

A practice whose own list already holds duplicates, and most do, will see a higher ambiguous rate than expected, because the ambiguity is real. The system is reporting a data problem, not failing to solve one, and deduplicating the list is a separate exercise no phone system does for you.

A service with weak identifiers, such as a walk-in clinic recording little beyond a name, will produce frequent handovers. That is the honest consequence of the available data, worth measuring in the first fortnight rather than assuming it settles. Those escalations route through triage and routing the same way a clinical handover does.

Frequently asked questions

Does it create a new patient record automatically?

Only where the practice has enabled it, and never to resolve an ambiguous match. Those are separate paths on purpose: an unresolved existing patient is not a new one, and conflating them is how duplicate charts are born.

What does a person receive when a match escalates?

The candidate records already considered, along with what was gathered on the call, so the resolution is a quick check rather than a fresh start. The payload is the one in what an escalation contains.

How does it handle a shared household number?

The number narrows the candidates without resolving them, so it asks for a second identifier. If the answer still leaves more than one plausible record, the call escalates rather than picking the most frequent caller on the line.

Does it match against our record or a copy?

Against the practice's own record. A parallel patient list would recreate the second-source problem live reading avoids, and it would drift out of date the moment a receptionist edited a chart at the desk.

Is any of this covered by a BAA?

Yes. Matching a caller against a patient list is processing protected health information, which makes 2care a business associate rather than a conduit, so a signed agreement is in place before any call is handled.

Count the duplicates in your own list first

Before judging any system's matching, learn your baseline. Search your list for the three commonest local surnames and count the near-duplicates. Then count how many records share a surname and a birth date, and how many share a telephone number, which is higher than most people expect because households do.

Those three counts tell you how much of the ambiguity a system reports is real rather than a shortcoming. A practice with a real duplicate problem will see a system escalating often and correctly, and reading that as poor matching is the wrong conclusion to draw.

See how identity resolution fits the rest of the call in patient intake, or hear an ambiguous match escalate live when you book a demo.