The Data Processing Agreement Clauses That Matter in Dental AI

The demo is the fun part. Someone from the vendor loads a bitewing, the overlay lights up an interproximal lesion your associate missed on the first pass, and the room goes quiet in a good way. Then the paperwork arrives: a master services agreement, an order form, and a data processing agreement running to fourteen pages of defined terms. The first two get read. The third gets signed.

That is backwards, because the DPA is the only document in the bundle that says anything about your patients. The MSA covers what happens if the software goes down and who pays for what. The data processing agreement is where UK GDPR Article 28(3) requires the vendor to write down, in binding terms, what it may and may not do with the radiographs, names, dates of birth and NHS numbers you are about to hand over. A practice on a GDS contract is a controller in its own right. No trust information governance team is checking this on your behalf, and CQC inspectors in England will ask for evidence of the arrangement under Regulation 17 when they look at whether you are well-led.

Most DPAs for dental software are competent boilerplate. The eight mandatory Article 28(3) terms will be there, because a lawyer put them there. What separates a DPA that actually protects patients from one that merely exists sits in four clauses. Here is how to find them and what to push back on.

1. The sub-processor list, and whether you ever get to see it

Article 28(2) lets a processor engage sub-processors only with your authorisation. In practice every vendor uses the “general written authorisation” route, which means you agree in advance to a list and they tell you when it changes. Fine, as long as two things are true: the list is specific, and the notice period is real.

Vague lists are the tell. If the DPA says the vendor may use “hosting providers, communications providers and analytics providers,” you have authorised nothing you can audit. What you want is a named list, ideally on a public page with an email subscription, giving entity name, country and function. Ask for it before signing, not after.

The chain matters most in front-desk AI, where it is longest. A triage or reception assistant that answers the phone and books appointments typically sits on top of a cloud host (AWS or Azure), a telephony layer (Twilio or Vonage), a speech-to-text service, a large language model API, and a CRM. That is five organisations touching a caller saying “I’ve got swelling under a crown on my upper left and I’m 34 weeks pregnant.” Special category health data, under Article 9, moving through five contracts you have seen one of.

Radiograph AI has a shorter chain but a heavier payload. Pearl (Los Angeles), Overjet (Boston) and VideaHealth (Boston) are all US-headquartered, which pulls clause three into play. Ask each of them directly: which sub-processors receive the image itself, as opposed to metadata or logs? The answer is usually short and reassuring. Get it in writing anyway.

On notice: 30 days before a new sub-processor goes live, with a right to object and terminate without penalty, is the standard worth holding out for. Ten days is too short to do anything useful. “We will update our website” is not notice.

2. Model training rights, and the word “de-identified”

This is the clause that gets rewritten most often and read least often. Look for any sentence containing “improve,” “enhance,” “develop,” “aggregate,” “de-identified” or “anonymised.” Then read the sentence around it three times.

The common construction goes something like: Supplier may process Customer Data in de-identified and aggregated form to improve, develop and train its products and services. In a practice management context that might be harmless. Applied to radiographs it is doing a lot of work, because a dental image is not easy to de-identify and vendors do not always explain what they strip.

A DICOM file straight off a Carestream or Planmeca sensor looks roughly like this:

(0008,0020) DA [20260114]                     # StudyDate
(0008,0080) LO [Meadow Lane Dental Practice]  # InstitutionName
(0008,1030) LO [Bitewing L/R]                 # StudyDescription
(0010,0010) PN [HALLIDAY^SUSAN^J]             # PatientName
(0010,0020) LO [4857]                         # PatientID
(0010,0030) DA [19630722]                     # PatientBirthDate
(0010,1000) LO [485 736 1234]                 # OtherPatientIDs
(0018,1164) DS [0.048\0.048]                  # PixelSpacing
(0020,000D) UI [1.2.826.0.1.3680043.8.498...] # StudyInstanceUID

Stripping tags (0010,0010) and (0010,0030) is trivial and every vendor does it. Whether they also strip InstitutionName, whether they handle burned-in pixel text on scanned or legacy images, and whether a full-mouth series of an identifiable dentition counts as anonymous at all under UK GDPR Recital 26, are separate questions with less comfortable answers. The ICO’s position is that data is only anonymous if re-identification is not reasonably likely by any means, by anyone. An OPG with restorations, implants and a healed mandibular fracture is a fairly distinctive record.

Two positions are defensible. Either you consent to training on properly de-identified images and get, in the DPA, a written description of exactly which DICOM tags are removed and how pixel-level identifiers are handled. Or you opt out entirely, which most enterprise-tier vendors will grant if asked at contract stage and almost none will volunteer. What you should not accept is a training right with no definition of de-identification attached to it, because then the standard is whatever the vendor decides it is next year.

Ask one more question while you are there: if you leave, does the model keep what it learned? The honest answer is yes, weights cannot be unlearned. That is a reason to settle the training clause up front rather than assume deletion fixes it later.

3. Where the data physically sits

“Cloud” is not a location. Get the region.

Concretely, this means asking whether your images live in AWS eu-west-2 (London) or us-east-1 (Northern Virginia), and whether support staff in a third country can view patient data while troubleshooting. That second one catches people out. Data can be stored in London and still be routinely accessed from Bangalore or Austin, and access is a transfer.

For US vendors, the DPA should point at one of two valid mechanisms: the UK Addendum to the EU Standard Contractual Clauses, or the UK IDTA (in force since 21 March 2022). A third route exists for US recipients certified under the UK Extension to the EU-US Data Privacy Framework, live since 12 October 2023, but check the actual DPF list rather than taking the marketing page at face value. Certification under the EU framework alone does not cover UK transfers. If you rely on the Addendum or IDTA you also need a transfer risk assessment on file, and the ICO publishes a tool for it.

Your DSPT submission, due 30 June each year, asks you to account for where patient data is held. A DPA that says “Supplier may process Customer Data in any country in which it or its sub-processors operate” makes that section impossible to answer honestly. Strike it and substitute a named region with a change-notification obligation. This is the single clause most often conceded in negotiation, because vendors know exactly where their infrastructure is and it costs them nothing to write it down.

4. Deletion on exit, and the format you get back

Article 28(3)(g) says the processor must delete or return all personal data at the end of the service, at your choice. Almost every DPA repeats this. Very few say anything useful about how.

Three things turn the clause from decorative into operational:

A deadline. “Within 30 days of termination” is enforceable. “Promptly” is not. Backups need a longer tail, so expect something like 90 days for backup rotation, with a written commitment that backup copies stay encrypted and inaccessible in the meantime.

An export format defined in the contract. This is where practices get hurt. A practice that ran an AI reading tool for four years across two surgeries, shooting roughly 40 intraoral images a week, has around 8,000 studies in that system. Getting them back as a zip of DICOM files plus a CSV of findings is a migration. Getting them back as 8,000 individual PDFs with the AI annotations flattened into the image is a filing cabinet. Both technically satisfy “return.” Specify DICOM, specify that the original unannotated image is included, and specify a machine-readable index.

A price, or the absence of one. Extraction fees appear at exactly the moment your leverage disappears. Cap them in the DPA or exclude them. A flat “no charge for one complete export on termination” is a reasonable ask and vendors rarely fight it at signature.

Retention cuts the other way too. UK dental records are generally kept 11 years after the completion of treatment for adults, and for children until their 25th birthday. If the AI tool holds the only copy of an annotated radiograph that formed part of a clinical decision, deleting it on exit creates a records problem. Export first, then delete, and put the sequence in the termination clause.

The thirty-minute review

You do not need a solicitor to triage a data processing agreement for dental software. You need to find four things and write four emails.

Two more worth ten seconds each. Breach notification: the DPA should say the processor notifies you “without undue delay,” because your own 72-hour clock under Article 33 starts when you become aware. Anything that gives the vendor five working days has quietly eaten most of your window. And audit rights: a right to receive the vendor’s latest ISO 27001 certificate or SOC 2 report annually is worth more to a practice than a theoretical right to send auditors you will never send.

Wider governance questions, including how these obligations interact with DSPT, CQC and your role as controller, sit in our Regulation, Data and Governance pillar.

One practical note to end on. Every vendor in this market is currently competing hard for UK practices, which means contract terms are more negotiable now than they will be in three years once they have the installed base. The next renewal you sign is the cheapest opportunity you will get to fix the four clauses above. Put them in the email before the trial ends, not after.