AI system for caries and pathology detection on images

A missed lesion on an image means a repeat visit, unnecessary interventions, and loss of patient trust. We develop a caries detection system turnkey: we train a model on your archive of images and hand it over along with operating protocols. The physician sees a prompt for each tooth instead of interpreting the image blindly.
Frequently Asked Questions

Caries detection on images: where accuracy is lost

The flow of images works like this: during a shift, dozens of studies pass through a doctor, and each is allotted limited time.

Early caries is an area of demineralization that differs from healthy enamel on an image by only a few percent of contrast and occupies an area of a few pixels.

Caries detection on images breaks down right here: the lesion is visible, but it can easily be mistaken for sensor noise, a filling artifact, or overlapping contours of adjacent teeth.

The cost of a miss is delayed in time. A lesion within enamel is treated minimally invasively, but after a few months it reaches dentin, and a repeat visit is already a different intervention, a different volume, and a different prognosis for the tooth.

The patient comes not because it has become painful, but because the process has gone beyond the point where it could have been stopped with a minor procedure.

The second source of loss is variability.

Image reading accuracy drops toward the end of a shift, and discrepancies in conclusions between specialists on the same image remain common practice: two doctors give two different descriptions, and the difference is not in qualification but in fatigue and in a different sensitivity threshold.

The load on the doctor grows, and so does the share of cases where a decision is made based on first impression.

All data comes in DICOM — with different imaging parameters, exposure, and calibration, which further blurs the boundary of normal. We break down how this is addressed at the level of data preparation, annotation, and model quality control.

Conclusion speed and completeness of findings: what changes

Conclusion speed and completeness of findings depend not on how fast the doctor works, but on how much routine annotation they do by hand.

During a shift, several dozen images pass through the examination room, and on each one it is necessary to find a lesion, describe it, and not miss a shadow at the edge of a filling. Below is a list of effects that we record before the start and measure at acceptance.

  • Time per image. The model provides preliminary annotation of lesions before the doctor opens the image: all that remains is to confirm the mark or remove it. We calculate the median reading time and the share of images to which the doctor returns repeatedly.
  • Completeness of findings. Caries detection is checked separately on proximal surfaces and at the edge of a filling — where the lesion is lost on film. We calculate the share of findings confirmed by annotation according to the Clinical guidelines for caries diagnosis protocol, where the reference was assembled by two independent reviews.
  • Consistency of conclusions. The mark is linked to the tooth number and anatomical zone, so the description does not depend on who is on shift today. The metric is the share of discrepancies between two doctors on the same image.
  • Share of repeat follow-up examinations. Cases that previously were closed by returning for a repeat appointment now fall into the first visit. We calculate the share of images with an assigned follow-up examination.

Separately, we record the trigger threshold: where the system stays silent and where it calls the doctor to look more carefully. Without this, the metrics are unreadable — an increase in the number of findings is equally well explained by better detection and by noise.

Approaches to caries detection: cloud, local environment, hybrid

The deployment mode is determined by two constraints: where images may be stored and processed, and how long the doctor is willing to wait for a response.

Then a scheme is selected — cloud processing, local environment, or hybrid; switching between them does not require rewriting the model itself, only the image delivery layer and the location of computation change.

Option When it fits Limitations
Cloud image processing Imaging is distributed across several rooms, there are no in-house capacities, and speed of launch matters The image leaves the clinic's environment — a legal basis and patient consent are required; the result depends on the communication channel
Local environment Images must not leave the clinic, and the study flow is stable Requires in-house computing capacities and their maintenance; model updates follow a regulation
Hybrid scheme Acquisition and preprocessing on site, heavy models on remote capacities; some rooms are poorly connected More complex support: two environments, model versions, and routing rules need to be synchronized

What does not depend on the choice of scheme

Integration with the clinic's practice management system. Images are pulled from it automatically as they arrive, and the annotation and conclusion are returned to the patient record — the doctor does not work in a second window or transfer files manually.

In parallel, a log is kept: which image, which model version, which result. It is used to review disputed cases, track the share of discrepancies with the doctor's conclusion, and roll the model back to the previous one if quality dropped after an update.

Implementation step by step: from archive audit to model handover

We start not with the model but with the data: the quality of caries detection is determined by the homogeneity of the archive and the rigor of pathology description. Therefore, the audit and scheme come first, and training and handover come last.

The stages are arranged with checkpoints: after each one, we record the result and decide whether to continue.

  1. Audit of the image archive. We look at volume, spread across machines, bitewings, and exposure quality, and search for duplicates and unsuitable frames. The output is a gap map: which stages are missing, what needs to be collected.
  2. Data scheme and annotation. We fix the class dictionary and annotation rules: lesion boundaries, disputed cases, what counts as an artifact. Annotation is performed by doctors, and complex images are agreed by a second specialist — this is where reproducibility is laid down.
  3. Acceptance criteria before training. We agree on what we consider success: sensitivity by caries stage, share of false positives, behavior on images with fillings and implants. A metric not agreed in advance becomes a dispute at delivery.
  4. Model training and validation. We split the holdout set by patients, not by images: otherwise a tooth ends up in both training and validation, and metrics are inflated. A separate run is on data from another clinic.
  5. Testing on the flow. We embed the model into the current image path and compare its output with the doctor's conclusion in a real shift. We calculate missed pathologies and false alarms — the latter are tolerated worse by doctors.
  6. Threshold adjustment. We select the threshold for the scenario: in screening, more alarms are acceptable; in hint mode, fewer. We fix the threshold, otherwise the decision ceases to be repeatable.
  7. Solution acceptance and handover. We hand over weights, configuration, annotation scheme, metrics report, and instructions for doctors. Separately, we describe how to monitor degradation when the machine or imaging protocol changes.

Handover composition: model, annotation, documentation, regulations

Handover of the system is not a single file with weights, but a set according to which the clinic continues to work independently. We check each artifact at acceptance: we run the model on a holdout set of images and compare the result with what is recorded in the documentation.

  • Trained model and inference settings. Weights, trigger thresholds, image preprocessing — in a form that deploys on your equipment without code changes.
  • Annotation description. Class dictionary, rules for borderline cases (shadow, filling artifact, overlap), requirements for the annotator, and quality control procedure.
  • Quality report. Sensitivity and specificity for each pathology class on the holdout set, analysis of typical errors, and applicability boundaries.
  • Solution documentation. Architecture, integration scheme with the doctor's workstation, environment requirements, version log, and acceptance results.
  • Procedure for reviewing findings. Who confirms a trigger, how the doctor's feedback is recorded, and where false positives go.
  • Update procedure. On what data we retrain, how we check a new version before rollout, and how we roll back if quality drops.
  • Instructions for staff. Memos for the radiologist and administrator: how to start a study, how to read the marks, and where to report failures.

Annotation and doctor feedback are what the model grows on further: without them, retraining turns into guesswork. Therefore, we hand over not only the result but also the rules by which it is maintained.

Case study: how the share of missed lesions on a series of images was reduced

Before the project, the system looked at each image separately: a mark was placed on the frame, and the doctor compared projections manually.

In the flow, this produced discrepancies — according to repeat examination data, some lesions on contact surfaces were confirmed only at the second visit, when treatment was already more complex.

Every fourth conclusion went to review, and the average time to analyze one patient remained around 20 minutes.

What was changed

Recognition was moved to the entire series: the algorithm links periapical images and a panoramic image of one patient, tracks the same lesion across different projections, and shows changes between visits.

The doctor sees not only the mark but also its justification — contour, projection, confidence level — so disputed cases are analyzed substantively rather than on a trust/no-trust basis.

Clinical validation was performed on annotations by doctors of the Clinical Center: each discrepancy with a repeat examination was analyzed separately and returned to retraining.

Metrics before and after

  • share of discrepancies with repeat examination — from 28% to 7%;
  • average time per conclusion — from 20 to 6 minutes;
  • number of repeat visits to clarify the diagnosis — almost three times fewer;
  • share of false marks that the doctor removed manually — from 15% to 4%.

It is worth saying separately that tuning was performed on the clinic's own clinical data, not on anonymized sets, so the algorithm behaves predictably on the equipment and positioning already accepted in the room.

The same approach transfers to other areas: one's own annotation and repeat clinical validation are needed at each stage.

How does training on your own images differ from a ready-made solution?

The difference is in what data the model learns to distinguish your images from. A ready-made model is trained on someone else's but large dataset: it confidently finds caries and common pathologies and requires neither annotation nor doctor time from the clinic.

Retraining on your own images gives an answer tailored to your flow — equipment, positioning, patient profile.

A typical model underperforms at the margins: initial lesions in the cervical area, shadows from fillings, overexposure, and sensor artifacts. There the share of misses grows, and the trigger threshold has to be set manually, rechecking each class on your own material.

If the flow is homogeneous and the pathologies are typical, this difference is unnoticeable — a ready-made model with calibration solves the task faster.

Transfer learning works differently. We take a pretrained network, change the classification block for your classes, and retrain on your own image archive with doctor annotation.

Usually a few hundred images per class are enough, including rare cases and borderline examples — these are exactly what determine where the model errs. Most of the time goes not into training but into annotation and resolving contradictions between doctors.

The downside: if the clinic has a single pathology class and it occurs rarely in the flow, annotation and validation consume doctor resources without a noticeable increase in accuracy.

We maintain a holdout set and look at quality by class separately: retraining is justified when it removes a specific type of error rather than 'improving everything at once'.

Common technical questions about implementation in a clinic

The doubts that most often come up at technical meetings before the start concern not the model itself but its integration with the clinic's reality: imaging quality, the cost of an error, the security of patient data, and exchange with the practice management system. Below are direct answers to them.

What should be done if images in the clinic are of different quality?

Before being fed to the model, images are brought to a uniform form: contrast is equalized, and frames below the sharpness threshold are filtered out.

An unsuitable image is marked by the system as requiring retake, and no conclusion is built from it — the share of such frames is visible in the report as a separate line.

How are model errors controlled?

The model outputs a probability for each finding, not a ready diagnosis. The sensitivity threshold is configured for the clinic: where it is more important not to miss a pathology, it is lowered, accepting more false positives. The doctor confirms or rejects disputed cases, and it is exactly these that go into retraining.

How is medical data protected?

Images are processed within the clinic's environment, without uploading to external services. Personal data is separated from the study: the model works with the image, not with the surname and record number. Access is role-based, and data accesses are recorded in a log.

How does the system integrate with the clinic's practice management system?

Exchange goes through the standard interfaces of the medical system: images are pulled from the archive, the conclusion is returned to the patient record, and the examination list comes from the schedule.

If there is no open interface, we install an intermediate layer and agree on the export format with the system vendor.

Let's discuss the task: which images and which pathologies are important to cover

For the task discussion to produce a result rather than turn into a retelling of general expectations, it is useful to gather several inputs in advance.

They determine both the scope of work and the order of stages: from them we understand where the bottleneck is — in the data, in annotation, or in how the result reaches the doctor. Below is a list of what most often helps move faster to project estimation.

  • Archive volume: how many images exist now, how many arrive per month, and whether they are stored in one place. This determines whether there is enough material for training and how to build annotation.
  • Image types: periapical, panoramic, intraoral photographs. Different modalities give a different picture, and mixing them into one task should be done deliberately.
  • Priority pathologies: caries at different stages, changes at the root apex, bone loss. The order of importance sets the phasing — we first cover what has the higher cost of error.
  • Annotation state: whether there are doctor conclusions, in what form they are stored, and who annotated disputed cases according to which protocol.
  • Access procedure: how anonymized images are transferred, who within the clinic sees the result and in what form — a conclusion or a mark on the image.
  • Integration point: a separate window for the doctor, operation within the current system, or batch archive review.
  • Acceptance criteria: what we consider readiness — share of missed pathologies, number of false positives per image, response time.

After that, we return with a project estimate and work plan, where a separate stage is testing on the flow: the model looks at images in the same mode in which the clinic operates, and we compare its answers with doctors' conclusions.

AI Development Areas

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1393
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1368
  • B2B Advance company logo design
    B2B Advance company logo design
    815
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1139
  • AIDER company logo development
    AIDER company logo development
    1057
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1152