Resolve duplicate registrations without merging the wrong people
For Clinic owner / hospital operations manager · Compare approaches
TL;DR — what you’ll learn
- Treat a similarity match as a candidate for review, not permission to merge.
- Keep person, visit, payer and external identifiers distinguishable.
- Check downstream consequences and reversal support before enabling identity changes.
- Leave ambiguous cases unresolved with an accountable reviewer.
Two registration records share a family phone number and similar names. One belongs to a parent and the other to an adult child. A matching tool assigns a high similarity score and proposes combining them.
This guide evaluates a supervised queue for suspected duplicate registrations. It does not establish an identity-verification policy or authorise a merge. The provider’s medical-records, clinical-safety and privacy owners must supply the evidence and decision rules before the queue can make operational changes.
Ask which identity is actually duplicated
One person can have several visits and payer references without having duplicate person records. Two people can share a phone or address without being the same person. An external identifier also needs its issuing system and scope; a bare number is not a universal identity.
Scroll horizontally to see all columns.
| Record | Question to resolve |
|---|---|
| Person record | Does this represent the same individual under the approved procedure? |
| Visit or encounter | Is this the same episode or a separate attendance? |
| Payer reference | Which policy, claim or account issued the identifier? |
| External system identifier | Which namespace and source assigned it? |
Bahmni's registration documentation describes patient search and visit-linked information. The buyer should test how the actual deployment distinguishes those relationships during a correction.
Give the reviewer evidence and an unresolved option
For the illustrative family pair, display only the information the authorised reviewer needs. Preserve the conflicting fields and their sources. A shared phone is supporting context, not a decisive rule. The reviewer must be able to record “different people” or “insufficient evidence” as well as “confirmed duplicate”.
Avoid a queue that rewards staff for clearing every case. Record the reason for a decision and the policy version used. Do not invent identity-verification requirements in software; the provider's medical-records, privacy and clinical safety owners must agree them.
An AI assistant may summarise differences or suggest candidates. Instructions embedded in an uploaded document cannot grant merge authority. A model confidence score also does not justify overriding a contradictory identifier.
Establish what the system can undo
Ask the vendor to distinguish links, aliases and merges and demonstrate their effects in the intended versions. Do not describe merging as reversible unless recovery is proven across every affected downstream system. If that evidence is unavailable, keep the evaluation at candidate review without enabling the merge.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepCandidate records detected
- B · StepAuthorised reviewer inspects evidence
- C · DecisionIdentity decision supported
- D · StepSeparate records or unresolved queue
- E · StepCheck supported link or merge and downstream impact
- F · DecisionApproved operation and recovery proven
- G · StepHold technical action
- H · StepApply controlled change and reconcile references
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Candidate records detected | Continue | B: Authorised reviewer inspects evidence |
| B: Authorised reviewer inspects evidence | Continue | C: Identity decision supported |
| C: Identity decision supported | No | D: Separate records or unresolved queue |
| C: Identity decision supported | Yes | E: Check supported link or merge and downstream impact |
| E: Check supported link or merge and downstream impact | Continue | F: Approved operation and recovery proven |
| F: Approved operation and recovery proven | No | G: Hold technical action |
| F: Approved operation and recovery proven | Yes | H: Apply controlled change and reconcile references |
The review decision and the technical operation are separate. A confirmed duplicate can remain on hold while the safe correction path is established.
Pilot detection before enabling changes
Have the authorised owner prepare an independent expected decision for each synthetic pair. The candidate tool's suggestion must not become its own answer key.
Scroll horizontally to see all columns.
| Expected class in the reviewed test set | Useful observation | Required stop condition |
|---|---|---|
| Confirmed same person | Does detection find the pair and preserve its evidence? | No technical change until the approved operation is verified |
| Confirmed different people | Does the suggestion incorrectly group them? | Never merge to clear the queue |
| Insufficient evidence | Can the reviewer keep the case unresolved? | No forced yes/no identity decision |
Report incorrect suggestions and missed known pairs separately. Keep unresolved cases out of a claimed accuracy percentage unless the evaluation definition explicitly accounts for them. A small synthetic set demonstrates behaviour on those cases; it does not establish a production identity-error rate. This article covers the supervised decision and its consequences, while clinic software selection tests how reception reaches the review queue.
Begin with synthetic records and read-only candidate detection. Include shared phone numbers, changed names, transposed dates, missing identifiers, twins or similar names, and a pair already reviewed as different people. Let the qualified owner define the expected outcomes for the test set.
Then, in an isolated test environment, demonstrate one approved change and its recovery. Inspect visit references, bills, lab records, attached documents, access logs and outbound interfaces that are actually in scope. Restrict merge permissions and test that an ordinary registration account cannot bypass review.
Measure candidate-review effort, unresolved cases, incorrect suggestions and the completeness of downstream reconciliation. A high proportion of suggested matches accepted by staff is not proof of identity accuracy. Report the test set's limits and keep clinical outcome claims out of the evaluation.
Duplicate-registration work succeeds when it improves traceability without erasing meaningful differences. The ability to stop on uncertain evidence is part of the design, not an incomplete automation feature.
Next actions
- Approve the identity-review procedure and evidence fields with responsible owners.
- Test candidate detection on deliberately ambiguous synthetic records.
- Enable technical changes only after vendor-supported recovery and downstream reconciliation are demonstrated.
Discuss this workflow
Request a registration-quality assessment beginning with read-only duplicate candidates and a reviewed identity-resolution procedure.
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Medical records lead, privacy owner and clinical safety representative: Approved identity-resolution SOP and adjudicated synthetic cases, including shared contact details and conflicting identifiers.
- HIS/LIS/billing vendors and integration owner: Current technical documentation and demonstrated end-to-end recovery; no reversibility claim from a local undo button alone.
References
- Bahmni patient registration — Distinction between demographic/identity information, visits and attached documents; not authority for identity merging or privacy compliance.
Topics: patient registration duplicate records · patient duplicate registration · hospital master patient index · patient record merge controls