What a Dental Enquiry Form Collects, and Where It Must Not Land

“Tell us about your problem” is the most common field on a dental practice website. The moment a patient answers it honestly, the form is collecting data concerning health, and the law’s starting position on that is not caution. It is prohibition, lifted only by a specific condition.

This is a practical account of what a dental enquiry form collects in law, which conditions realistically apply, and why the destination of the form matters far more than the form itself. It is the other half of what a dental website may say, which covered advertising. It is not legal advice. Your indemnifier and your data protection lead decide this for your practice.

What the form is actually collecting

Article 9(1) of the UK GDPR begins from a prohibition:

A patient typing “broken molar, in pain since Tuesday, I’m diabetic” into a web form has given you data concerning health. So has the one uploading a photograph of a tooth. The prohibition then lifts only where Article 9(2) provides a condition, and for a dental practice two are realistic.

The health-care condition, and the catch in it

Article 9(2)(h) permits processing “necessary for the purposes of… medical diagnosis, the provision of health or social care or treatment”, on the basis of domestic law, and “subject to the conditions and safeguards referred to in paragraph 3”. In the UK the domestic-law half is Schedule 1, paragraph 2 of the Data Protection Act 2018, the health or social care purposes condition.

Paragraph 3 is the catch, and it is the part that bears on how a website is built:

Read that against a typical practice website and the problem is obvious. The condition is about who holds the data. A clinical detail that lands in a shared mailbox, a marketing platform, a spreadsheet, or a form plugin’s database is no longer sitting under the responsibility of someone bound by professional secrecy. It is sitting wherever the website happened to put it.

Explicit consent, and why it is the weaker option

Article 9(2)(a) allows processing where “the data subject has given explicit consent… for one or more specified purposes”. Practices often reach for this because a tick box is easy to build. It is also fragile: consent must be freely given and withdrawable, and a patient in pain ticking a box to be allowed to ask a question is not the strongest example of a free choice. Which condition your practice relies on is a decision for your data protection lead, not for your web agency, but it is worth making deliberately rather than inheriting it from a form plugin.

The form is not the problem. The destination is.

Almost every dental website we look at has the same architecture: a contact form, a plugin that stores every submission in the site’s own database, and an email notification to a practice address. For a general enquiry that is fine. For the message that says “I’ve had a swelling under my jaw for three days”, three things have just happened:

• Health data is sitting in the website’s database, on the public internet, backed up to wherever backups go, readable by anyone with WordPress admin, including whoever built the site.
• It has been emailed in plain text to an address that may be a shared inbox on a free mail provider.
• Nobody decided any of that. It is simply what the plugin does by default.

The fix is not a better consent notice. It is an architecture where clinical detail either never reaches the website, or does not stay there.

What we build instead

• Ask less on the public form. Name, how to reach them, whether they are an existing patient, urgency, and preferred times. That is enough to call somebody back, and it is not special category data.
• Give the clinical question its own route. A phone number, or a channel into the practice’s own clinical or triage system where confidentiality obligations already apply, not the marketing website’s form handler.
• Do not store submissions on the website where clinical detail is possible. Where a form must capture it, the entry should pass through and be deleted, not accumulate in the database for years.
• Be careful with photographs. “Send us a picture” is a clinically useful feature and a data protection decision; it needs a destination chosen on purpose.
• Name the recipients. Who at the practice receives enquiries, on what system, and who else can read that mailbox. Most practices have never written this down.
• Keep enquiries out of the marketing list. A patient asking about pain has not opted into anything, and merging the two is how a reminder campaign ends up referencing a treatment.
• Say it plainly in the privacy notice: what the form collects, where it goes, how long it is kept, and who sees it.

Our dentists page covers the wider site: how practices present treatments, pricing and new-patient journeys. The advertising rules that govern what those pages may claim are in the companion post.

What we would not build for a practice

• A “describe your symptoms” free-text box on a public form that emails a shared mailbox.
• A form plugin retaining every submission indefinitely on a site that also runs a page builder, a chat widget and a dozen other plugins.
• An AI chat assistant answering clinical questions. It would be collecting health data and giving an answer the practice is accountable for. See what your chatbot says, your business said.
• Enquiry data flowing into a marketing automation tool because it was the convenient integration.
• A consent tick box presented as the solution to an architecture that should not have collected the data in the first place.

Sources and method

• UK GDPR, Article 9: the prohibition in paragraph 1, the conditions in paragraph 2 including (a) and (h), and the secrecy requirement in paragraph 3.
• Data Protection Act 2018, Schedule 1, paragraph 2: the health or social care purposes condition.
• Data Protection Act 2018, section 11(1): who satisfies the obligation of secrecy.

What this post does not do. Central Systems builds websites; we are not lawyers, data protection officers or clinicians, and this is not legal, regulatory or clinical advice. It does not tell any practice which Article 9 condition to rely on, what its retention periods should be, or what its privacy notice must say. Those are for the practice, its data protection lead and its indemnifier. It does not cover clinical record keeping, NHS information governance, the Caldicott principles, DSPT requirements, or what to do about a personal data breach, each of which has its own rules. Legislation is amended; the linked sources are authoritative and this page is not.

Questions practices ask us

Is a name and phone number special category data?

On its own, no. It is ordinary personal data. It becomes data concerning health when it is attached to something revealing a health condition, which is exactly what a symptoms box invites.

Can we not just add a consent box?

Explicit consent is a lawful condition under Article 9(2)(a), so it can be part of the answer. It does not fix where the data then goes, and the secrecy requirement attached to the health-care condition is about exactly that.

Our booking system asks about medical history. Is that a problem?

Not inherently. A clinical system built for a practice is the appropriate place for it. The question is whether that is the system collecting it, or whether a marketing website is collecting it first and passing it along.

What about enquiries that arrive by email anyway?

They will, and that is a practice process question rather than a website one. What the website controls is whether it invites clinical detail into a channel that was never designed to hold it.

Does this mean no online booking?

No. Appointment type, times and contact details are ordinary personal data. The care is needed around free-text clinical boxes, uploads and medical history questionnaires.

Who decides all this for us?

Your data protection lead, with your indemnifier where it touches clinical confidentiality. Our part is building a site that can implement whatever they decide, instead of one that quietly decided for them.