Duplicates are created at the front desk, not in the database — so that is where they have to be prevented. The highest-yield interventions are a mandatory search protocol before any new record is created, a standardized way of capturing names and addresses, and a small number of staff authorized to create records at all. Everything downstream — matching algorithms, merge tools, cleanup projects — remediates a problem the registration workflow keeps producing.
The short answer
Patient matching, as ONC defines it, is "the identification and linking of one patient's data within and across health systems in order to obtain a comprehensive view of that patient's health care record," accomplished at minimum by linking demographic fields such as name, birth date, phone number, and address. Every one of those fields is typed by a human, quickly, often while a patient waits. That is the whole problem in one sentence, and it is why this is an operations issue before it is a technology issue.
Duplicates vs. overlays: know the difference
These get used interchangeably and they are not the same thing. They have different causes, different detection methods, and very different clinical consequences.
| Duplicate | Overlay | |
|---|---|---|
| What it is | One patient, two or more records | Two patients, one record |
| Typical cause | Failed search at registration; name variant; new record created "to save time" | Wrong record selected at registration; documentation filed to the wrong chart |
| Clinical risk | Incomplete history — missing allergy, missing med, duplicate order | Wrong history — another person's allergies, meds, and results in your chart |
| How it surfaces | Clinician cannot find a known result; duplicate-detection report | Clinician notices something impossible; patient reports data that is not theirs |
| Severity | Serious | Severe, and harder to fully unwind |
Both matter. But an overlay can put another person's medication list in front of a prescriber, and it is likeliest to be discovered late — which is why the registration protocol below is worth more than any cleanup tool.
Where duplicates actually come from
- The search was too narrow. Staff search an exact spelling, find nothing, create a new record. The existing chart was under a maiden name, a hyphenation, a nickname, or a transposed birth date.
- The search was too slow. If the search screen takes fifteen seconds and there is a line at the desk, a new record is faster. Performance is a matching control.
- Anyone can create a record. The more people who can, the more get created.
- Inbound interfaces create them. Lab, imaging, HIE, and registration feeds can all generate records when demographics do not match cleanly.
- Newborns and unidentified patients. Temporary naming conventions that never get reconciled.
- Names do not fit the fields. Compound surnames, suffixes, and single names that do not map onto a first/middle/last model get entered differently by each person who tries.
- Address entry is free-text. Two spellings of one street produce two "different" patients.
Fixing it at registration
- Mandate a documented search protocol. Not "search first" — an actual sequence: date of birth plus partial last name, then phone, then date of birth alone across a range. Write it down; train to it; audit against it.
- Restrict who can create a record to a small, trained group. Everyone else searches and escalates.
- Make "no match found" a deliberate act. Require users to confirm they ran the protocol before the create screen opens. Friction in this one place is a feature.
- Show enough on search results to disambiguate — full name, date of birth, address, phone, last visit — so staff are not choosing between identical-looking rows.
- Verify two identifiers at every encounter, against the patient, not the paperwork. This is what catches an overlay before it does damage.
- Fix search performance. If it is slow, that is a technology problem masquerading as a training problem, and retraining will not fix it.
Standardize the data, not just the process
Matching algorithms compare fields, and fields entered inconsistently defeat them no matter how sophisticated the algorithm is. Data standardization usually does more for match rates than algorithm tuning.
Address is the worst offender and the most tractable. ONC's Project US@ is a unified specification for representing address in health care, created precisely because inconsistent address formatting undermines patient matching across systems. Adopting a consistent address representation — ideally with validation at the point of entry — improves matching both inside your system and in every exchange you participate in. ONC also publishes the Patient Demographic Data Quality (PDDQ) Framework, a self-assessment tool for evaluating how well you manage demographic data quality, useful if you need to argue internally that this is a managed discipline rather than a front-desk habit.
Measuring your duplicate rate
You cannot manage this without a number, and most practices lack one. Track two:
- Duplicate rate: potential duplicates as a share of total records, from whatever detection your EMR or MPI offers. The absolute figure is nearly meaningless across organizations, since detection thresholds differ. What matters is the trend in your number, and whether it moves when you change the registration protocol.
- New duplicates created per month. This is the one that tells you whether prevention is working. A cleanup project that reduces the backlog while the creation rate holds steady has bought you time, not a fix.
Break the creation rate down by registration user and by inbound interface. It will usually concentrate, and the concentration tells you where to intervene.
Merging safely, and unmerging when you are wrong
Merging is not a database operation; it is a clinical one, and it deserves a controlled workflow.
- Two-person review before any merge. One proposes, another confirms. The cost of a wrong merge — an overlay you created deliberately — far exceeds the cost of a second pair of eyes.
- Compare clinical content, not just demographics. Two records with matching name and date of birth can still be twins. Look at the encounters.
- Know what your EMR does to allergies, medications, problems, and results on merge, and confirm nothing is silently dropped. Test it in a non-production environment first.
- Confirm you can unmerge — and how completely — before you need to. Find out on a test record, not a real one.
- Notify anyone downstream. If merged records were already exchanged, receiving systems may still hold the split version.
- Log every merge with who, when, and why.
Use the SAFER Patient Identification Guide
You do not need to invent an assessment. ONC publishes the SAFER Guides — eight self-assessment guides on EHR safety, updated in 2025 — and one of them, Patient Identification, is specifically about reliably identifying patients in the EHR: ensuring the information displayed and entered is associated with the correct person. It is free, government-published, and structured as recommended practices.
Run it once with the front-desk lead, the practice manager, and whoever administers the EMR in the same room. The value is less in the score than in the conversation, which surfaces the two or three local practices everyone knew were risky and nobody had raised.
The takeaway
Patient matching is treated as an algorithm problem and solved as a workflow problem. Restrict who can create records, mandate and audit a real search protocol, standardize address and name entry, find out what your inbound interfaces do on a non-match, and measure new duplicates per month rather than only the backlog. Then merge carefully, with two people, having already confirmed you can unmerge. The goal is not a clean database — it is that the chart in front of a clinician belongs to the patient in front of them.
Common questions
What is the difference between a duplicate and an overlay?
A duplicate is one patient with two or more records, splitting their history. An overlay is two patients sharing one record, putting one person's data in another person's chart. Overlays are the more dangerous of the two.
What is patient matching?
ONC defines it as the identification and linking of one patient's data within and across health systems in order to obtain a comprehensive view of that patient's health care record — at minimum by linking demographic fields such as name, birth date, phone number, and address.
Can a matching algorithm fix our duplicate problem?
Not on its own. Algorithms compare fields, so inconsistent data entry defeats them. Standardizing how names and addresses are captured, and preventing record creation at the source, moves match rates more than algorithm tuning typically does.
Is there a free tool for assessing patient identification safety?
Yes. ONC's SAFER Guides include a Patient Identification guide — a self-assessment of recommended practices for reliably identifying patients in the EHR — available at no cost from HealthIT.gov.
Common questions
What is the difference between a duplicate and an overlay?
A duplicate is one patient with two or more records, splitting their history. An overlay is two patients sharing one record, putting one person's data in another person's chart. Overlays are the more dangerous of the two.
What is patient matching?
ONC defines it as the identification and linking of one patient's data within and across health systems in order to obtain a comprehensive view of that patient's health care record — at minimum by linking demographic fields such as name, birth date, phone number, and address.
Can a matching algorithm fix our duplicate problem?
Not on its own. Algorithms compare fields, so inconsistent data entry defeats them. Standardizing how names and addresses are captured, and preventing record creation at the source, moves match rates more than algorithm tuning typically does.
Is there a free tool for assessing patient identification safety?
Yes. ONC's SAFER Guides include a Patient Identification guide — a self-assessment of recommended practices for reliably identifying patients in the EHR — available at no cost from HealthIT.gov.