The interesting question about diagnostic software in dentistry stopped being does it work somewhere around 2024. Caries detection models flag lesions on bitewings with enough reliability that the remaining disagreements are about thresholds rather than capability, and most practice management systems now ship with something running in the background whether the owner asked for it or not.
The questions that replaced it are harder, and they are not technical.
The first one is about workflow order
In most implementations, the software has already analyzed the radiograph by the time the dentist opens it. The findings are on the screen, overlaid, before any independent human read has happened.
This is a design decision, not a technical necessity, and it has a predictable consequence: it is very difficult to disagree with a mark you have already seen. The clinical literature on anchoring is not subtle, and nothing about a dental practice at 3 p.m. makes clinicians immune to it.
A handful of practices have responded by inverting the order — dentist reads first, software overlay second, disagreements logged. It is slower. It is also the only configuration in which the software’s output can be evaluated rather than absorbed.
The second is about what gets found
Higher sensitivity is not free. A model tuned to catch every early lesion will also flag a substantial number of surfaces that would never have progressed to a restoration in the patient’s lifetime.
Dr. Julia Kowalski, who studies restorative failure at the University of Illinois Chicago, is blunt about where this goes. “We spent thirty years learning to leave early lesions alone,” she says. “We are now installing tools that make leaving them alone feel like negligence, and we have not decided what to do about that.”
The decision is not the vendor’s to make. Detection thresholds are configurable in most systems, and the default is set by someone. In practices that have not examined it, the default was set by a company with a commercial interest in the software appearing useful.
We spent thirty years learning to leave early lesions alone. We are now installing tools that make leaving them alone feel like negligence.
The third is about liability, and nobody likes it
If the software flags a lesion and the dentist does not treat it, and the tooth later fails, the record now contains a documented disagreement with an automated finding.
If the software misses a lesion, the record contains nothing at all, and the dentist’s standard of care is unchanged — the software is a tool, not a practitioner, and the professional judgment remains the dentist’s.
The asymmetry is doing quiet work. It pushes toward treatment in exactly the cases where watchful waiting has historically been correct, and it does so without anyone deciding to push. Practice owners should understand that they have inherited this asymmetry by installing the software, and that documenting the reasoning behind a decision not to treat is now a meaningfully different task than it was five years ago.
What owners should actually do
Three things, none of them exciting.
Know what your software’s detection threshold is set to, and know who set it. If the answer is “it came that way,” change that.
Decide deliberately whether the overlay appears before or after the clinician’s read, and write the decision down. This is the highest-leverage configuration choice in the entire system, and most practices have made it by accident.
Finally, treat the software’s disagreements as data worth keeping. The practices getting real value from these tools are the ones tracking where the model and the dentist diverge and looking at the outcomes. The ones getting the least are the ones who bought it, turned it on, and stopped thinking about it — which, at present, is most of them.
