Data quality at your dental clinic: why it holds everything else up

What data quality means at a dental clinic

Your clinic's data quality is the percentage of patient records you can actually work with: a mobile number that exists, a record that isn't duplicated, a properly registered last-visit date, and a stored contact consent. More than an IT concept, it's the difference between "I have 3,000 patients in the system" and "I can reach 2,400 of them".

Your practice management software tells you how many records you have. What it doesn't tell you is how many of them work. And the two figures can be surprisingly far apart, because a broken record doesn't announce itself: it keeps its place in the database, counts towards every total, and only fails the day you try to use it.

That's the trap with this problem. An empty chair is visible. A dead phone number isn't: you discover it months later, when the reactivation campaign doesn't arrive, the check-up reminder never goes out, or the forecast misses. That's why almost no clinic knows its real percentage of usable records, and why it's worth calculating.

The four problems that show up in almost every database

After connecting to clinic databases of every size, the patterns we find are almost always the same four:

• Duplicates. The same patient registered twice: once as "Joseph Garcia" and again as "Joseph Garcia Lopez", with the history split between the two records. To the system they're two different people: one gets duplicate messages, the other looks like a dormant patient who actually came in last month.
• Dead phone numbers. Landlines from ten years ago, mobiles that changed, mistyped prefixes, or fields holding notes ("ask for her mother") where a number should be. The message goes out, never arrives, and nobody notices.
• Empty fields. Records with no mobile, no email, or no last-visit date. Without that date, the patient doesn't even appear when you filter for inactive patients: they're invisible to any campaign.
• Inconsistent formats. Dates in three different formats, names in capitals or lowercase depending on who typed them, clinical notes stored in the email field. Every inconsistency is a filter that fails or a future duplicate.

None of this is anyone's fault. A front desk that answers the phone, greets patients and manages the diary doesn't have a spare hour a day to verify records: it's a capacity problem, not a dedication problem. The database ages silently, and you only notice when you try to lean on it.

The arithmetic: what a dirty database costs you

You don't need any tool to estimate your situation. Open your software and review a random sample of 100 records. Count how many have an empty, incomplete or clearly invalid mobile number. Suppose 12 do.

Applied to a database of 3,000 records, that 12% is roughly 360 patients nobody can reach. No reminders, no recall, no reactivation: as far as any campaign is concerned, those 360 patients don't exist.

Now cross that with your dormant patients. If 1,200 haven't visited in over a year and the same 12% have a bad phone number, around 144 will never receive a reactivation message. At an average treatment value of €110, that's 144 × €110 = €15,840 of pending treatment beyond the reach of any campaign, however good it is.

Two caveats, to keep the arithmetic honest. First: not all of those patients would come back even with a correct phone number; some have moved away and others no longer need treatment. Second: your percentage may be higher or lower than the example's, which is why the first step is measuring it with your own sample rather than assuming someone else's average. What doesn't change is the structure of the calculation: every point of bad data is a slice of your database you can't work with.

"We thought we had 9,000 patients. When we looked at how many had a valid mobile number and a registered consent, the real number was quite a bit lower." That's a composite quote (it summarises several real, anonymised conversations with clinics), and it's one of the most repeated lines when a clinic looks closely at its database for the first time.

Why data quality holds everything else up

In the KPIs of a dental clinic we already flagged data quality as the number to prioritise above the rest. The reason is structural: everything you might want to do with your patient database starts with being able to reach people and count correctly. With bad data, all three of these break at once.

Reactivation breaks. Reactivating inactive patients means contacting people who haven't visited in over a year. If the phone number is wrong, the message never lands; if the patient is duplicated, they get two messages; if the consent is missing, you shouldn't be sending it at all. The best-designed campaign can't rise above the ceiling of its contact list.

Recall breaks. Dental recall depends on one specific field: the date of the last visit or check-up. A record without that date never enters the "patients due for a check-up" filter, so even the most disciplined system skips it. A duplicate does the opposite: it reminds the same patient twice, who perceives carelessness where they should perceive care.

Forecasting breaks. A revenue forecast is built by counting: confirmed appointments, reachable patients, the share that usually responds. If your database says 1,200 dormant patients but 150 are duplicates and 144 unreachable, any forecast built on 1,200 is inflated from birth. The calculation is right; what's wrong is the base it counts on.

The numbers you look at every month (patients recovered, check-ups closed, revenue forecast) rest on the same foundation. When the foundation is off, they all lie at once and in the same direction: they make you believe you have more usable database than you do.

How to audit your database this week

An initial audit is an afternoon's work, not a month's. The goal isn't to fix anything yet: it's to learn how big the problem is.

1. Pull a random sample of 100 records. A hundred is enough for a first estimate; there's no need to review all 3,000.
2. Count four things. Empty or invalid mobile numbers; likely duplicates (same name and date of birth); records with no last-visit date; unregistered contact consents.
3. Extrapolate. The sample's percentage, applied to the total, gives you the picture: 12 bad numbers out of 100 records, in a database of 3,000, is roughly 360 unreachable patients.
4. Prioritise in this order. First, the phone numbers of dormant patients, because that's where pending treatment is waiting. Then duplicates, because they distort every number you track. Secondary fields come last.

Could you fix it by hand? Once, yes. At around 2 minutes per record to verify and correct, 3,000 records is 6,000 minutes: 100 hours of work, two and a half weeks full-time. No front desk has that gap in the diary, which is why the full clean-up gets postponed year after year.

And even if you do it: the database doesn't stay clean. New patients register every week, people change numbers, and duplicates get created in the rush at the desk. A database cleaned in January isn't the same one by June. A one-off clean-up helps; what changes the outcome is quality that maintains itself.

In the AI era, data is the entry ticket

Until recently, a dirty database cost you missed opportunities. In 2026 it costs something more. Any AI system you might want to use at the clinic, from an assistant answering WhatsApp messages to an autonomous system operating the entire front desk, reads your database and works with whatever it finds. It doesn't ask whether the data is good: it uses it.

With clean data, that system multiplies your capacity: hundreds of personalised conversations, each with the right patient context. With dirty data, it multiplies the noise: reminders to old numbers, two messages to the same duplicated patient, forecasts about patients who don't exist. AI amplifies whatever base you give it, in both directions.

That's why data quality has stopped being a maintenance chore and become a condition of entry. A clinic with an orderly database can confidently delegate administrative work to AI systems; one without has to fix the foundations first. The good news is that the two aren't separate steps: the clean-up itself is among the first jobs you can delegate.

One-off clean-up or continuous quality

This is where the approach changes. At Keishal we treat database quality as a continuous process, not an annual project:

• The system analyses your practice management database continuously and detects the usual patterns: duplicates (by fuzzy matching, not just identical names), invalid phone numbers and emails, empty key fields.
• Whatever can be corrected safely is corrected automatically.
• Missing fields get filled the natural way: when a patient replies on WhatsApp, their record is enriched with what the conversation provides.
• And whatever can't be resolved without human judgement is surfaced to the team for review, instead of being decided alone.

All of this happens on top of your current software: Gesden, Nubimed, Dentalink, Clinic Cloud or whichever you use. No migrations, and nothing new for your team to learn.

There's also a layer beyond hygiene. A database with correct, up-to-date data and registered consents is a signal of seriousness about data protection: the patient gets messages through the channel they authorised, with their name spelled right and no duplicates. A patient who sees their clinic taking care of their data trusts it more, and that trust is worth more than any campaign. The specific legal framework is best defined with specialised data protection advice; the practice of caring for data starts in the database itself.

Start by measuring

Data quality can't be fixed in an afternoon, but it can be measured in one. Pull your 100-record sample this week and put the number on the table: what percentage of your database is actually reachable. It's probably the cheapest KPI to calculate in the whole clinic, and it's the one that sets the ceiling for all the others.

And if you want to see what your database looks like when it stays clean on its own, book a demo and we'll show you with your own data.