AI Dent
§6 Section 6 of 6 2,958 words · 13 min

Regulation, Data and Governance for AI in UK Dental Practice

Most of the friction in buying dental AI is not clinical. It is working out which of four separate rulebooks a product sits under, who carries the liability when it is wrong, and what you are supposed to have written down before the first radiograph goes through it. AI medical device regulation in dentistry in the UK is not one framework. It is device law (MHRA), data protection law (ICO), clinical safety standards (DCB0129 and DCB0160), and NHS procurement assurance (DTAC, DSPT), plus your GDC obligations sitting underneath all of it. Vendors will hand you a certificate for the first one and hope you assume it covers the rest.

This page is about the gap between “CE marked” and “safely deployed in my practice”.

What actually makes a dental AI tool a medical device

The test is intended purpose, not technology. If software is intended for diagnosis, prevention, monitoring, prediction, prognosis or treatment of disease, it is a medical device under the UK Medical Devices Regulations 2002 (SI 2002/618, as amended). The MHRA leans on MDCG 2019-11 for the qualification logic, and so do the Approved Bodies.

Run your shortlist through it honestly:

ToolDevice?Why
Caries and bone-level detection on bitewings (Pearl Second Opinion, Overjet, VideaHealth, Diagnocat)YesDiagnostic output about a specific patient
CBCT segmentation for implant planning (Relu Creator, Diagnocat)YesInforms treatment planning
Cephalometric auto-tracing (AudaxCeph, WebCeph, CephX)Yes, usuallyMeasurement driving orthodontic diagnosis
Photo-based remote triage (SmileMate / DentalMonitoring)YesUrgency and referral decisions
Ambient note-taking that transcribes only (Heidi, Tortus, Accurx Scribe)Usually noNo clinical interpretation, but read the intended purpose statement, since summarisation that suggests diagnoses moves the line
Recall and lead chasers (Dengro, Dental Intelligence style analytics)NoAdministrative
Rota and stock forecastingNoAdministrative

The interesting cases are the ones vendors describe as “just a workflow tool”. A front-desk assistant that reads a patient’s free-text symptom description and sorts it into “emergency today / routine / advice only” is making a triage decision. Under EU MDR Rule 11 that is Class IIa at minimum. If your supplier is selling that as unregulated software, they have either taken deliberate legal advice you should ask to see, or they have not thought about it.

Reading a UKCA or CE certificate properly

Three things go wrong here routinely.

First, the class mismatch. The old UK MDR 2002 classification rules put a lot of standalone software in Class I, which the manufacturer self-declares with no Approved Body involvement, then registers with the MHRA (currently £240 per registration application). EU MDR Rule 11 pushes the same software to Class IIa or IIb, which requires a Notified Body audit of the quality system and technical documentation. So the identical product can legitimately say “Class I, UKCA” and “Class IIa, CE” on two different pieces of paper. The CE route has had far more scrutiny applied to it. Ask which certificate the product you are buying is actually placed on the GB market under.

Second, the timeline. Following SI 2023/627, GB accepts CE marked general devices compliant with the old MDD until 30 June 2028 where the certificate remains valid, and MDR or IVDR compliant devices until 30 June 2030. That is not a permanent arrangement, and a three-year practice contract signed in 2027 can outlive the supplier’s route to market. Put a regulatory-continuity clause in.

Third, and most important, the intended purpose statement. This is the legally operative text and it is usually two sentences buried in the instructions for use. A tool cleared for “detection of caries in the permanent dentition on bitewing and periapical radiographs, as a concurrent read by a qualified dentist” does not cover: primary teeth, panoramics, CBCT slices, autonomous reporting, or a hygienist using it unsupervised. Running it outside that scope is off-label use. You become responsible for the evidence, and your indemnifier may take a view.

Get the intended purpose in writing before purchase, paste it into your AI register verbatim, and write down the uses you are explicitly ruling out.

The numbers the brochure leaves out

Detection metrics are quoted at the population level and then applied per surface, which quietly destroys their usefulness.

Suppose a vendor’s pivotal study reports sensitivity 0.88 and specificity 0.85 at the default confidence threshold. Published dental detection studies commonly land in that band on curated datasets. Now apply it to proximal surfaces in a low-caries adult recall cohort, where prevalence of frank lesions might be around 6% of surfaces scored:

1,000 surfaces, 6% prevalence = 60 diseased, 940 sound

True positives   0.88 x 60  = 53
False negatives             =  7
True negatives   0.85 x 940 = 799
False positives             = 141

Flagged surfaces = 53 + 141 = 194
Positive predictive value = 53 / 194 = 27%

Roughly three in four flagged surfaces are not disease. That is not a broken product, it is Bayes. Shift to a per-patient question in a high-need cohort at 30% prevalence and PPV rises to about 72%. Same model, same threshold, wildly different clinical meaning.

Two governance consequences follow. Ask what the configurable confidence threshold is and whether you can change it (most serious products let you; the default is usually tuned for sensitivity, because missed caries makes worse marketing than over-detection). And decide, in writing, that no restorative decision is made on an AI flag alone. The FP rate is the overtreatment risk, and the GDC will look at the treatment decision, not the software.

While you are asking: what was the training population? A model trained predominantly on US private-practice imaging, on different sensors, at different exposure settings, applied to a deprived NHS cohort in Bradford, is a distribution shift you should be auditing for.

Data protection: you are the controller, whatever the vendor’s contract says

Your practice determines why and how patient data is processed. You are the controller. The AI vendor is a processor, and any cloud hosting they use is a sub-processor. If a supplier’s terms describe them as “joint controller” or, worse, reserve rights to use your patient images for their own product development, that is a substantive change in who is answerable to the ICO and you should push back before signing.

For a mixed practice the lawful basis work is fiddly and worth doing once properly. NHS treatment generally runs on Article 6(1)(e) public task with Article 9(2)(h) for the health data. Private treatment usually runs on Article 6(1)(b) contract, still with Article 9(2)(h). Same patient, same radiograph, two bases, one privacy notice that has to explain both. Your notice also has to name the AI processing: “we use software to assist in reading radiographs” belongs in there, along with the recipient categories.

A DPIA is mandatory here, not advisory. Article 35 plus the ICO’s screening criteria catch this on at least three counts: special category data at scale, innovative technology, and, for some triage tools, automated decision-making. The full method, including the specific risks that actually come up in dental deployments and how to score them, is in writing a DPIA for an AI tool in a dental practice. Do it before go-live. A DPIA written retrospectively to satisfy a CQC inspector is worth very little and is obvious to read.

On automated decisions: the Data (Use and Access) Act 2025 loosened the general prohibition on solely automated decision-making, but decisions based on special category data stayed in the restrictive lane. A triage bot that autonomously tells a patient with facial swelling to book routinely in three weeks, with no human review, is exactly the configuration to avoid. Keep a human in the loop and be able to evidence it from system logs.

International transfers need an IDTA or the UK Addendum to EU SCCs, plus a documented transfer risk assessment. Many US-headquartered dental AI vendors now offer UK or EU hosting (AWS eu-west-2 in London is common), but their support engineers may still access data from outside the UK. Ask specifically: where is data at rest, who can access it, from which country, under what logging, and can support access be made break-glass rather than standing.

Retention is the point everyone forgets. Under the Records Management Code of Practice, dental records are kept for 11 years for adults, or until a child’s 25th birthday, whichever is longer. Your AI processor’s retention period should be shorter and independent. If images sit in the vendor’s cloud indefinitely, you have created a second uncontrolled record with a different retention clock.

Clinical safety: DCB0129 is theirs, DCB0160 is yours

These two standards are the part of the framework practices most often have never heard of.

DCB0129 obliges the manufacturer of health IT to run clinical risk management and produce a Clinical Safety Case Report and Hazard Log. Ask for both. A supplier who cannot produce a DCB0129 safety case has not done the work, and that is a decent single-question filter on a crowded shortlist.

DCB0160 applies to the health organisation deploying the software. That is you. It requires a named Clinical Safety Officer (a registered clinician with clinical risk management training), your own hazard log, and a deployment safety case that addresses the risks specific to your setting: your sensors, your staff mix, your patient population. Enforcement in small GDS practices is patchy, but the standard is the recognised benchmark, and it is what a coroner or a GDC panel will be pointed at.

A real hazard log entry looks like this:

HAZ-07   AI flags caries on a sound surface; clinician accepts and restores
Cause    Low PPV at per-surface prevalence; default threshold too permissive
Effect   Unnecessary restoration, loss of sound tissue, complaint
Initial  Severity 3 (Major) x Likelihood 3 (Occasional) = Risk 4 (High)
Ctrl 1   Confidence threshold raised from 0.45 to 0.60
Ctrl 2   Overlay hidden until clinician has recorded their own read
Ctrl 3   Written rule: no restorative decision on AI output alone
Ctrl 4   Monthly double-read audit, 20 consecutive bitewing pairs;
         >10% unexplained disagreement suspends the overlay
Residual Severity 3 x Likelihood 1 (Improbable) = Risk 2 (Acceptable)
Owner    CSO, Dr A. Rahman. Review 6-monthly or on any model update.

Control 2 is the one with real teeth. Sequential reading (clinician first, AI second) preserves independent judgement. Simultaneous overlay produces anchoring, and your audit will show it.

IR(ME)R and the justification you cannot delegate

If a triage tool or a recall algorithm suggests radiographs, note what has and has not happened. Under the Ionising Radiation (Medical Exposure) Regulations 2017, the practitioner (a registered dentist, for dental exposures) must justify each individual exposure, taking account of the specific objectives and the characteristics of that patient. Software cannot be the practitioner. An algorithm recommending bitewings at 12 months does not discharge Regulation 11, and “the system flagged it” is not a justification entry.

Selection criteria still govern. The College of General Dentistry’s Selection Criteria for Dental Radiography and the 2020 UKHSA guidance notes on safe use of dental X-ray equipment remain the reference points. Where an AI tool nudges you towards shorter recall intervals for imaging, that is a dose increase across your list, and the employer’s IR(ME)R procedures and audit should capture it. Count the exposures before and after deployment; if the number per 100 patients has gone up, you need a clinical reason that is not commercial.

The NHS paperwork layer

For England, DTAC (Digital Technology Assessment Criteria) is the usual gate: clinical safety (DCB0129/0160), data protection, technical security, interoperability, and usability and accessibility. It is a supplier self-assessment, which means the value is entirely in the evidence attached. A DTAC returned with “yes” in every box and no certificate numbers, no penetration test summary and no safety case is not an assurance, it is a form.

Separately, NHS-contracted dental practices complete the Data Security and Protection Toolkit annually, with the deadline falling on 30 June. Adding a cloud AI processor changes your answers: asset and information flow records, supplier assurance, and access control all need updating in the same cycle. The toolkit is migrating towards Cyber Assessment Framework alignment across the sector in phases, so check which version applies to you this year rather than copying last year’s submission.

Note also that DTAC and DSPT are England instruments. Device law (UKCA, CE acceptance, MHRA registration) applies GB-wide, but Wales routes assurance through Digital Health and Care Wales and Scotland through its own national arrangements. Northern Ireland remains under EU MDR and IVDR via the Windsor Framework, so a CE mark is required there and a UKCA-only product cannot be placed on the NI market.

Training data and secondary use

The most common contractual trap in dental AI is a licence clause letting the vendor use your radiographs to improve their models. Sometimes it is framed as anonymisation, which is doing a lot of work: a full-mouth series with restoration pattern and a date is not trivially anonymous, and a DOB or NHS number left in DICOM metadata makes the point moot.

If you genuinely want to contribute data, that is a defensible decision, but it needs its own lawful basis, its own DPIA section, and transparency in your privacy notice. Research use typically needs the HRA route or explicit consent, not a buried clause in a SaaS agreement. The workable position for most practices: strike the secondary-use clause, permit processing solely for delivering the service to you, and require deletion within 30 days of contract end with written confirmation.

Check the DICOM tags before anything leaves your network. Practices bridging from SOE Exact, R4+, Dentally or CS Imaging are often surprised by how much identifiable data rides along in the header.

After go-live: surveillance is a two-way obligation

The Medical Devices (Post-market Surveillance Requirements) (Amendment) (Great Britain) Regulations 2024 came into force on 16 June 2025 and put real structure on the manufacturer side: a PMS plan, trend reporting, and periodic safety update reports (annually for higher-risk classes, at least every two years for Class IIa). Reporting deadlines for serious incidents are tight: 15 days as standard, 10 days where there has been a death or unanticipated serious deterioration, 2 days for a serious public health threat.

Your side of that is simpler and frequently neglected. If the software misses a lesion that leads to harm, or produces an output that contributes to inappropriate treatment, report it to the MHRA through the Yellow Card scheme and to the manufacturer. Log it internally in the hazard log. Vendors cannot detect a false negative that a clinician silently corrected, so if nobody reports, the surveillance data is systematically blind to exactly the failure mode you care about.

Model updates deserve their own rule. Ask for written notice before any change to the model weights or thresholds, because a silent update invalidates your local validation. Then re-run a short benchmark set after each update: 30 archived cases with known ground truth, compared against the previous version’s outputs. Twenty minutes of work, and it is the only thing that will catch performance drift.

An AI register that survives an inspection

CQC’s Regulation 17 (good governance) expects systems to assess and monitor quality and risk. One page per tool does the job:

Tool              Second Opinion (Pearl Inc.)
Function          Caries / periapical radiolucency detection, IO radiographs
Reg status        CE under MDR, Class IIa, cert no. ________ (Notified Body)
GB route          CE accepted in GB until 30 June 2030
Intended purpose  Concurrent read, permanent dentition, bitewing + PA
Excluded here     Primary dentition, panoramic, CBCT, hygienist-only use
Threshold         Caries confidence 0.60 (vendor default 0.45)
Deployed          Surgeries 1-4, 12 Jan 2026
Clinical owner    Dr A. Rahman (CSO); hazard log DL-2026-03
DPIA              v2.1 signed 08 Jan 2026, review due 08 Jan 2027
Processor         Pearl Inc.; hosting AWS eu-west-2; US support access
Transfer basis    IDTA + TRA, break-glass access, logged
Retention         90 days vendor-side, then deletion; confirmed in writing
Audit             Monthly, 20 consecutive bitewing pairs, double-read
Last audit        02 Sep 2026: 3 disagreements, 0 harm, DL-2026-03/17
DCB0129 SCR       Received v4, 11 Dec 2025
Staff training    All clinicians, 14 Jan 2026; refresher on model update

Keep the audit cadence monthly for the first quarter, then quarterly if disagreement rates are stable. Twenty cases is not a research study, and it is not meant to be. It is enough to notice a step change.

When it goes wrong

A patient complains that a lower right first molar restored in March has now needed endodontics, and the notes say the lesion was “AI-detected, D2”. Work backwards through the register. Was the radiograph within the intended purpose (permanent tooth, bitewing: yes)? What threshold was in force in March, and was there a model update between the clinical decision and now? Does the hazard log show HAZ-07 as a live risk with controls in place, and was Control 2 actually followed, meaning is there a recorded independent clinical read that preceded the overlay?

If the answer to that last question is no, the problem is not the algorithm. It is that the practice deployed a tool with a documented anchoring hazard and never enforced the control it wrote down. That is the finding a GDC panel, an indemnity claims handler or an ICO case officer will land on, and it is the one piece of the whole framework that is entirely within your gift to fix this week: decide the rule, write it in the practice policy, put it in the induction, and check it in the audit.

In this section

The supporting pages under this subject.