Dentists interpret dozens of radiographs a day under time pressure, and agreement between readers on early caries and bone loss is only moderate. Dental AI acts as a second reader: it highlights suspected findings on bitewings, periapicals, panoramic images and CBCT, numbers the teeth, measures bone levels and turns the result into a picture the patient understands. It is a regulated medical device in the EU and supports, but never replaces, the dentist's diagnosis.
Problem & value
- Today: the dentist reads each image visually, often between patients. Early interproximal caries, subtle periapical lesions and progressive periodontal bone loss are easily missed or judged inconsistently between clinicians. Patients often doubt recommendations they cannot see, and insurers ask for documented evidence.
- AI value: consistent second reading, faster charting, objective bone-level measurement, visual case acceptance for treatment plans, and structured documentation for quality management.
- Evidence: systematic reviews of deep learning for caries and periapical lesion detection report that AI assistance can raise reader sensitivity, sometimes at the cost of more false positives; results vary by dataset and reference standard, and few studies are prospective [5][6]. Treat vendor accuracy claims as hypotheses to verify on your own images.
Variants
- General practice (SMB): chairside caries and bone-loss overlay on bitewings/periapicals, integrated in the practice management software (PMS) and imaging software.
- Periodontology: automated bone-level and calculus measurement for staging and recall.
- Oral surgery / implantology / orthodontics: CBCT segmentation of teeth, inferior alveolar canal and sinus, implant planning, cephalometric landmarking, aligner planning.
- Dental service organisations and insurers: retrospective audit of images versus billed procedures (see HLTH-005); sensitive because findings may influence reimbursement.
- Teledentistry / consumer: smartphone photo triage and aligner monitoring; image quality and classification are weaker and the device status must be checked. Related: HLTH-006.
How it works
- acquisition (intraoral sensor / OPG / CBCT)
- DICOM/PACS or imaging software
- quality check (position, cut-off, artefacts, image type routing)
- tooth detection & FDI numbering
- task models: caries / restoration / calculus / periapical lesion detection, bone-level segmentation, anatomy segmentation on CBCT
- overlay + confidence + measurements
- dentist review (accept / reject / edit each finding)
- charting, patient communication view, report draft (LLM, optional)
- Models: U-Net/nnU-Net-style segmentation networks, YOLO/DETR-type detectors for lesions, and 3D segmentation for CBCT; foundation models (SAM variants, MedSAM) help with annotation.
- LLM layer (optional): turns structured findings into record text and patient-friendly wording; see HLTH-003 and HLTH-011. The LLM must not add findings that the image model did not produce.
- Human-in-the-loop: every finding is a suggestion; the dentist confirms, rejects or edits before it enters the chart or a treatment plan. Rejections should be logged as feedback.
Data preparation
The data are intraoral X-rays, panoramic images (OPG) and CBCT volumes, typically stored in the imaging software or a small PACS on a practice server, with charting and patient data in the practice management system. Older images may exist only as JPEG exports, screenshots or film scans.
Typical gaps: images without DICOM metadata or with wrong image-type labels, mixed sensors with different calibration, charting in free text instead of coded findings, duplicates after software migrations, and unclear patient consent for secondary use of images.
Preparation steps: - Check that the imaging software exports DICOM or has a DICOM node; clarify the interface with the vendor (PREP-005). - Convert legacy JPEG and film scans to a consistent format (PREP-006, PREP-007). - For a product evaluation, assemble 100-200 representative images with confirmed findings from the dentists (PREP-018) and use existing charting entries as labels where reliable (PREP-020). - Pseudonymise exports for vendor tests or own development (PREP-022).
For a bought product, data work is small (a few days for interface and test set); for own development it is the largest block because every finding needs expert annotation.
Implementation paths
Which path for whom
- smb (dental practice): Path A, because several CE-marked dental-imaging products exist at practice prices and integrate with common imaging software; the process is standard.
- enterprise (dental chains, DSOs): Path A, because certified products avoid manufacturer duties; negotiate group licences and central hosting instead of building.
- developer: Path C, because open segmentation frameworks (nnU-Net, MedSAM) and local GPUs allow prototyping on pseudonymised images without sending patient data to third parties.
Path A — Buy (recommended)
- Dedicated dental AI vendors: Overjet, Pearl (Second Opinion), VideaHealth, Diagnocat (CBCT and 2D), Denti.AI, Relu (Belgium, CBCT segmentation, EU), Dentalmonitoring (France, patient-side monitoring, EU), Promaton (Netherlands, 3D tooth segmentation for planning, EU), Align Technology and 3Shape (scan and design ecosystems with embedded AI).
- Imaging/PMS vendors with built-in AI: Dentsply Sirona (Sidexis, DS Core), Planmeca, Carestream Dental, Dürr Dental (EU) and CGM Dentalsysteme (EU) integrate or resell AI modules.
- Check: MDR CE certificate covering the specific indication and image types (not only an FDA clearance), notified-body status, EU data residency, DPA, integration with your imaging software, performance data in your population, and exit/export options.
- Choose A when: you are a practice or clinic; self-certified regulatory work is not realistic.
Path B — Build on cloud APIs
- General VLMs (Claude, Gemini, GPT, Mistral) are not validated diagnostic tools for radiographs and must not be used to make findings. Sensible uses: drafting record text from structured findings, patient letters and coding hints (HLTH-005), with the dentist's reviewed result as input.
- If building a diagnostic product, cloud use is limited to training and MLOps in EU regions (e.g. Azure, Google Cloud, AWS EU regions, or sovereign EU clouds) with pseudonymised data.
Path C — Self-host (open source)
- Frameworks: MONAI, nnU-Net, Ultralytics-style detectors, PyTorch; DICOM via Orthanc or dcm4chee, annotation with CVAT or 3D Slicer.
- Open data: ToothFairy (CBCT inferior alveolar canal and teeth segmentation challenge), panoramic datasets such as Tufts Dental Database and DENTEX, used for research and benchmarking, not as proof of clinical performance [3][4].
- Hardware: HW2 is enough for 2D inference and CBCT inference; training 3D models needs HW3.
- Status: a self-built model used for diagnosis is itself a medical device (own CE marking); research or in-house non-clinical evaluation is acceptable only within the limits of MDR Art. 5(5) and national law.
Path D — Custom training
Worth it for manufacturers and large groups: fine-tune on several thousand annotated images from multiple sensors and sites, with a reference standard from consensus of several dentists (and histology or CBCT where possible). Plan for multi-site validation, bias analysis (age, dentition, restorations, sensor type) and post-market surveillance. Annotation is the cost driver.
State of the art (2026)
- Mature tasks: tooth detection and numbering, restoration and implant detection, and CBCT tooth and canal segmentation are largely solved on clean data. Caries, calculus, bone-loss measurement and periapical lesion detection are commercially deployed in 2D radiography.
- Trend: one platform covering 2D radiographs, CBCT, intraoral scans and photos; generative patient-communication and charting; foundation models reducing labelled-data need.
- Limits and failure modes: incipient and secondary caries remain hard; superimposition on panoramic images; metal artefacts on CBCT; distribution shift between sensors, children's mixed dentition and rare pathology; automation bias, where clinicians accept overlays uncritically; over-diagnosis driving unnecessary restorations; commercial conflicts if findings feed upselling.
Shared resources & combinations
- Same stack (segmentation + object-detection + DICOM handling): HLTH-001 radiology, HLTH-002 pathology, HLTH-006 dermatology and ophthalmology, HLTH-016 veterinary diagnostics. One DICOM gateway and one GPU server (HW2/HW3) can host several validated models.
- Combinations: HLTH-003 ambient documentation (notes), HLTH-004 clinical decision support, HLTH-005 coding and billing, HLTH-011 report generation for referrals.
- Data pipeline: consent management, de-identification of DICOM headers, annotation tools and drift monitoring are reusable across imaging use cases.
Effort, cost & KPIs
- Path A: days to weeks; typically a subscription per practice or per site, plus integration with the imaging software.
- Path B: weeks, limited to documentation and communication add-ons.
- Path C: 3-6 months for an evaluation environment; far longer for a certified product.
- Path D: 12+ months including clinical evaluation and CE marking; annotation and regulatory work dominate.
- KPIs: sensitivity/specificity versus consensus reference on local images, override rate, time per image, treatment-acceptance rate, rate of unnecessary interventions, recall compliance, and monitoring of performance by sensor type.
People & change
Practice owner and the lead dentist decide scope and budget; the dental assistants who take the images and use the software daily must be involved from the start, together with the IT service provider (interface, backups, network) and the data protection officer or external DPO. Image data are health data: a DPIA is likely if the vendor processes images in the cloud, and an AVV (Art. 28 GDPR) is mandatory. Inform patients transparently, for example by a sign at reception and a line in the privacy notice.
Works council: depends. Small practices usually have none. Where a chain has a works council, §87(1) no. 6 BetrVG applies if usage logs of individual dentists are suitable for performance monitoring, which the BAG treats as sufficient; §90(1) no. 3 requires timely information about AI-supported work processes. Agree that logs are not used for individual evaluation.
AI literacy (Art. 4 AI Act, support measures): a one-hour introduction on what detection overlays can and cannot do, false positives and automation bias (GUIDE-006). Run a pilot in one treatment room for four to six weeks, count accepted and rejected findings and collect feedback (GUIDE-009). Typical concerns: loss of clinical autonomy and patient trust. The dentist always decides, and showing the overlay to patients can improve acceptance (GUIDE-008).
Risks, regulation & compliance
- EU AI Act: software that interprets images for diagnosis is a medical device under MDR (Regulation 2017/745, Rule 11, typically class IIa or higher). If a notified body is required, the AI system is high-risk under Art. 6(1) with Annex I, and the high-risk obligations apply under the schedule in force (Annex I products: 2 Aug 2028 under the Digital Omnibus on AI, Reg. (EU) 2026/1744). Deployers have duties of human oversight, logging and AI literacy (Art. 4, 14, 26) [1][2].
- Not covered: purely administrative tools (scheduling, record text without diagnostic claims) are usually minimal risk. Qualification follows intended purpose (MDCG 2019-11) [7].
- GDPR: images and charts are health data (Art. 9); needs a legal basis, DPA with the vendor, EU hosting or valid transfer mechanism, and a DPIA for systematic processing. Using patient images to train the vendor's models requires a separate legal basis or opt-out; check contract clauses. Dental imaging also includes biometric-like features; do not use images for identification.
- Professional rules: diagnosis remains with the dentist (national dental law, e.g. Zahnheilkunde- gesetz in Germany); radiation protection law requires justified indication for each image, so AI must not drive additional X-ray exposure. Keep records per national retention periods.
- Mitigations: local validation before go-live, override logging, periodic audit of AI versus dentist findings, contract terms for data use, and clear patient information.
Getting started
- List the image types you use and verify which have CE-marked AI for exactly that indication.
- Run a 4-8 week shadow evaluation of two vendors on 200-500 of your own images, with a consensus reference reading by two dentists.
- Sign the DPA, check EU hosting and training-data clauses, and complete the DPIA.
- Train the team on automation bias and define when findings may enter the chart.
- Track override rate and treatment outcomes monthly and revisit the vendor yearly.
Sources
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
- ToothFairy challenge (CBCT segmentation) — https://toothfairy.grand-challenge.org/
- nnU-Net — https://github.com/MIC-DKFZ/nnUNet
- Schwendicke F. et al., Artificial intelligence in dental research — checklist for authors, reviewers, readers (J Dent) — https://pubmed.ncbi.nlm.nih.gov/32119892/
- Schwendicke F. et al., Convolutional neural networks for dental image diagnostics: a scoping review (J Dent) — https://pubmed.ncbi.nlm.nih.gov/31622674/
- MDCG 2019-11 — Guidance on qualification and classification of software in MDR and IVDR — https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_qualification_classification_software_en_0.pdf
- MONAI — https://monai.io/
- Overjet — https://www.overjet.com/