A familiar name appears in the diary. Is this a returning client, a different person with similar details, or a second record created during a hurried booking? The safest answer is not an automatic merge. It is a short, owned check that keeps both records protected until the clinic has enough reason to resolve them.
Why duplicates begin before the appointment
Online booking, telephone enquiries, reception changes and imported lists can all introduce slightly different versions of the same person’s details. A shortened name, a changed email address or an old telephone number can make an existing client look new. The reverse is also possible: two different people can share a name, postcode or contact detail.
That makes duplicate handling an identity and workflow problem, not a spelling-cleanup task. Joining the wrong records can expose one person’s information to another and place the wrong forms, photographs, notes or payment context in front of a practitioner. Leaving a genuine duplicate unresolved can split the clinic story across two places.
Start with a possible match, not a conclusion
A system may surface a possible match, but it should not quietly decide that two records belong to one person. Give the booking or reception user three clear states: use the verified existing record, create a genuinely new record, or send the possible match to an authorised review queue.
The match prompt should reveal only the minimum information needed for that user’s role. It should not turn the search screen into a directory of client names, treatment histories or photographs. The ICO’s data-protection-by-design guidance connects strong defaults with data minimisation and limiting access to the people who need it.
Read the ICO’s guidance on data protection by design and by default.
Use a clinic-defined identity check
There is no universal field that proves two clinic records are the same person. Names can change or be shared. Contact details can be recycled, mistyped or used by a family. A clinic should define a proportionate check for its services and document who may perform it. The software should support that process without prescribing clinical suitability or presenting a probabilistic match as fact.
NHS England Digital’s Master Person Service describes how large health datasets use several stages of demographic matching and warns that individual identifiers may be incomplete, inconsistent or duplicated. A private aesthetic clinic is not being told to reproduce that national service. The useful lesson is narrower: matching is evidence-based work, and one similar field is not certainty.
Read NHS England Digital’s overview of the Master Person Service.
Keep the booking moving without guessing
A possible duplicate should not force reception to inspect clinical history or make an irreversible choice. A calm workflow can hold the booking request, record that a possible match needs review, and give it to an authorised person. The client does not need to see another record or be asked to repeat sensitive history in ordinary email.
Useful operational states might be:
- Possible match: enough similarity to pause, not enough to combine.
- Review assigned: a named authorised person owns the check.
- Distinct clients: records remain separate and the reason is recorded.
- Same client confirmed: the clinic’s controlled resolution process can begin.
- Unable to confirm: no merge is performed and the uncertainty remains visible.
These are workflow examples, not legal or clinical rules. Each clinic needs its own policy, appropriate access controls and advice for the services it provides.
Resolve, do not simply delete
If two records are confirmed as one client, the clinic still needs to decide what happens to each connected item. Deleting the smaller record first can detach useful context or remove the explanation for earlier activity. A controlled resolution should preserve source, authorship and timing, identify conflicts, and make the destination clear.
Depending on what exists, the authorised reviewer may need to check:
- future and historical appointments;
- assigned forms and their versions;
- protected notes, documents and photographs;
- treatment, product and batch context;
- payments, refunds or balances;
- portal access and communication preferences; and
- which record identifiers appear in an export or integration.
A conflict should become a visible decision, not a “last value wins” rule. The ICO’s accuracy guidance stresses understanding the source and status of information and taking reasonable steps when data may be wrong or misleading.
Read the ICO’s current accuracy-principle guidance. The ICO marks this guidance as under review, so the article’s review date matters and clinics should check the current source.
Separate the review queue from the clinical record
The queue only needs enough information to show the possible match, owner, status and next action. It should not become a parallel clinical record. Keep health information, photographs and detailed treatment context inside the protected client record, and never place them in analytics, URLs, ordinary email or a general-purpose task board.
Use fixed, non-sensitive analytics events if the clinic measures the workflow at all. For example, record that a duplicate-review screen was opened or a generic outcome was recorded. Do not send names, contact details, record identifiers, match candidates or outcome reasons to marketing analytics.
Test the awkward cases before launch
- A returning client books with a new email address.
- Two different clients share a name and postcode.
- A family contact number appears on more than one genuine record.
- An imported record and an online-booking record contain different spellings.
- A user can see one clinic but tries to open a possible match belonging to another.
For each case, verify what the booking user sees, what the authorised reviewer sees, which action is reversible, whether the reason is auditable and whether changing an identifier or URL can expose another client or clinic. A matching interface is not secure if its server accepts a record the user was never authorised to view.
A five-minute duplicate-record huddle
- Review only open possible matches and their owners.
- Prioritise those connected to today’s appointments without exposing extra detail.
- Record whether the records are distinct, confirmed as one client or still uncertain.
- Resolve connected-item conflicts before retiring any duplicate shell.
- Check that the client-facing next step uses the correct record.
Questions to ask a clinic-software supplier
- Does a possible match stay a suggestion until an authorised person reviews it?
- What minimum information is shown to booking and reception users?
- Can the clinic keep two genuine clients separate even when details overlap?
- Does a controlled resolution preserve source, authorship and timing?
- Are connected appointments, forms, media, payments and portal access checked explicitly?
- Are cross-clinic and horizontal access failures tested on the server?
- Can the workflow be measured without sending client information to analytics?
One client story, without unsafe assumptions
The goal is neither zero duplicate alerts nor aggressive merging. It is a clinic day where a possible match becomes a visible, owned decision and the wrong history never appears simply because two fields looked similar. Explore Rytura’s current online-booking boundaries, client-record scope and security approach. The availability register remains the source of truth; this article does not claim that automatic duplicate detection or merging is currently live.