Writing a DPIA for an AI Tool in a Dental Practice

A Data Protection Impact Assessment is the piece of paperwork most practices discover they needed about three weeks after the AI radiograph software went live. It is not optional. Article 35 of the UK GDPR requires one before you begin processing that is likely to result in a high risk to people’s rights, and the ICO’s own list of “likely high risk” processing includes the use of innovative technology, large-scale processing of health data, and any automated decision-making with significant effects. An AI tool reading your bitewings hits at least two of those on day one.

The good news: a DPIA for a single dental AI tool is a four-to-six page document, not a dissertation. If you have already read the overview at /regulation-and-governance/, you will know where the DPIA sits alongside your ROPA, your Article 30 records and your DSPT submission. This page is about actually writing the thing.

When you genuinely need one (and when you don’t)

You need a DPIA before you start processing. Retrospective DPIAs are common and technically a breach of the “prior to the processing” wording, though in practice the ICO’s interest is in whether you did the thinking, not the date on the front page. Do it properly, date it honestly, and note in the document that the assessment was completed after go-live if that is what happened.

Three scenarios where a DPIA is clearly required in a dental setting:

Radiograph AI. Tools like Pearl’s Second Opinion, VideaHealth, Overjet or Dentally’s integrated caries detection process identifiable patient images against a model you do not control. Even where inference runs in the UK, you are processing special category data under Article 9 with novel technology. DPIA required.

Patient-facing triage or symptom checkers. A chatbot on your website that asks about pain, swelling and duration, then recommends an urgent appointment or self-care, is making an automated decision with real clinical consequences. Article 22 territory if there is no human review before the outcome reaches the patient.

Front-desk AI that touches clinical notes. Call-answering and scribing tools are where practices get caught out. A receptionist AI that only books slots and reads back availability is low risk. One that transcribes a patient’s call about a broken denture and writes a note into the patient record is processing health data.

Where you probably don’t need a full DPIA: a rota optimiser that only sees staff names and shift times, an accounts tool reading your bank feed, or a marketing platform handling nothing but email addresses and consent flags. Do a short screening note instead, three or four paragraphs saying why you assessed the risk as low, and keep it on file. The ICO expects to see the reasoning, not necessarily the full template.

The seven sections the ICO actually looks for

The ICO’s template has a specific structure, and inspectors, indemnifiers and ICB information governance leads all read it in the same order. Follow it. Inventing your own headings makes your document harder to review and slower to approve.

1. Identify the need for the DPIA
2. Describe the processing (nature, scope, context, purposes)
3. Consultation process
4. Assess necessity and proportionality
5. Identify and assess risks
6. Identify measures to reduce risk
7. Sign off and record outcomes

Section 5 is the one that carries weight, and section 5 is the one most practices write in four bullet points. A dental DPIA for radiograph AI should identify eight to twelve distinct risks with severity and likelihood scored separately.

Describing the processing so it survives scrutiny

Vagueness in section 2 is the single most common failure. “We will use AI to help detect caries” tells a reviewer nothing. You need to be able to answer: what data, from where, to where, for how long, seen by whom.

Here is a worked version for a three-surgery mixed practice adopting Pearl Second Opinion alongside Software of Excellence Exact:

DATA CATEGORIES
  Radiographic images (bitewing, periapical, panoramic) — DICOM/JPEG
  Patient identifiers embedded in image metadata: name, DOB, patient ID
  Clinician ID of the capturing operator
  Date/time of exposure

VOLUME (12-month estimate)
  Active patient list:                    4,150
  Radiographs taken per month:              680
  Images sent for AI analysis per month:    680 (all, no filtering)
  Annual image volume:                    8,160

DATA FLOW
  Sensor (Carestream CS 7200)
    -> practice imaging PC (on-prem, Windows 11)
    -> TLS 1.2+ upload to vendor endpoint
    -> inference in vendor cloud region (confirm: UK or EU?)
    -> detection overlay returned to practice PC
    -> displayed alongside original in Exact

RETENTION
  Vendor-side image retention:  30 days (per contract cl. 8.2)
  Vendor-side model training:   opt-out selected, confirmed in writing 14/03/26
  Practice-side retention:      11 years post-last-treatment (adult),
                                or to age 25 (child), per NHS Records
                                Management Code of Practice 2021
ACCESS
  Practice: 3 dentists, 1 hygienist, 2 nurses (named list held separately)
  Vendor:   support engineers on ticket-raised access only, logged

Notice the unresolved question left visible in that block. A DPIA with an honest open question in it is more credible than one where every line is confidently filled in. Chase the answer, then update the document and re-date it.

Lawful basis: the bit that trips up mixed practices

You need two things: an Article 6 basis and an Article 9 condition. Most dental practices get the first right and skip the second.

For NHS work, Article 6(1)(e), public task, is usually correct, with the task grounded in your NHS contract. For private work, 6(1)(b), contract, fits better. Mixed practices legitimately use different bases for different patients, and your DPIA should say so rather than pretending everyone falls under one.

For Article 9, the condition is almost always 9(2)(h), provision of health care, supported in UK law by Schedule 1 Part 1 paragraph 2 of the Data Protection Act 2018. That paragraph carries a condition many practices miss: the processing must be carried out by or under the responsibility of a health professional, or by someone with an equivalent duty of confidentiality. Write down who that person is. In a small practice it is usually the principal, acting as Caldicott Guardian.

Do not use consent as your basis for the clinical processing. If a patient withdraws consent you would have to stop, and you cannot un-analyse a radiograph. Consent is the right mechanism for optional things: SMS reminders, the practice newsletter, letting the vendor use de-identified images for model improvement.

Scoring risk with numbers instead of adjectives

Use a 1-5 severity by 1-5 likelihood matrix and multiply. Anything scoring 15 or above needs a named mitigation and a named owner before you sign off. Anything at 20 or above should stop the rollout until it is reduced.

A real risk register for radiograph AI in a mixed practice:

That sixth row deserves a note. Residual 8 rather than 3 or 4 is an honest admission that you cannot fully mitigate demographic performance gaps from inside a dental practice. Leaving a genuinely unresolved residual risk in the register, with a monitoring plan attached, is better practice than pretending you solved it.

The questions to put to the vendor before you write

You cannot complete sections 2 and 6 without vendor answers. Send these in writing and keep the replies as an appendix to the DPIA. Sales calls do not count as evidence.

• Where is inference performed, naming the country and cloud region? “Our cloud” is not an answer.
• Are you a processor or a joint controller for this processing, and does your DPA say so in Article 28-compliant terms?
• Do you use practice images for model training or improvement by default, and how do I opt out?
• What is your published sensitivity and specificity for caries detection, on what dataset, and what was the demographic composition of that dataset?
• What regulatory class is the product under UK MDR 2002, and do you hold a UKCA or CE mark with an active EU MDR certificate recognised in Great Britain?
• Do you hold DTAC approval, and can you provide the completed DTAC?
• What is your breach notification timeframe to me as controller? (You need this well inside your own 72-hour clock.)
• Which sub-processors do you use, and how will you notify me of changes?

On that fifth point: vendors quote impressive numbers. Pearl has published sensitivity figures in the region of 0.90 for caries detection against consensus expert reads. Treat any figure as a claim about the vendor’s test set, not a prediction about your patients. Record the claim and the source in the DPIA, and record what you will do to check it locally.

Consultation: two conversations, both minuted

Section 3 asks who you consulted. For most practices the honest answer is “nobody”, which is a gap worth closing cheaply.

Talk to your clinical team. Fifteen minutes at a staff meeting, minuted, covering what the tool does, what it does not decide, and what to do when they disagree with it. Note dissent. If an associate says they do not want AI overlays on their patients’ radiographs, that is a real finding for the DPIA and a real operational question about whether use is per-clinician or practice-wide.

Patient consultation is lighter-touch. You do not need a focus group. A line in your privacy notice, a short paragraph in the waiting-room leaflet, and a note of any patient objections received in the first six months is a proportionate approach for a practice your size. If you are an NHS practice, check whether your ICB’s information governance team wants sight of the DPIA; some do as a condition of certain contracts, and their template may differ from the ICO’s.

Sign-off, review and the DSPT link

The DPO signs section 7 if you have one. Most practices under 250 staff do not need a DPO, but if you process health data on a large scale you may. Where you have no DPO, the principal signs as controller and records that no DPO is appointed and why. Name a review date. Twelve months is standard; six is better for a tool in its first year.

Set a trigger list too, because calendar reviews miss the things that matter: a vendor acquisition, a change of sub-processor, a new model version, a change in the tool’s regulatory class, a near-miss where the AI and clinician disagreed and the clinician was wrong. Any of those means reopening the document rather than waiting for the anniversary.

Your DSPT submission will ask related questions, particularly around assertion 1 on personal confidential data. Cross-reference rather than duplicate: point the DSPT answer at the DPIA and keep both in the same folder as your ROPA entry for the tool. When someone asks to see your governance, one folder with four consistent documents in it is worth more than forty pages of unconnected policy.

One practical warning to finish on. The most common real-world failure is not a badly written DPIA, it is a DPIA that describes a configuration nobody actually implemented. If your document says de-identification is enabled at the gateway, open the settings and check that it is, then write the date you checked in the margin.