GDPR-Compliant Online Booking Form for a Dental Practice: Which Fields You're Allowed to Ask

A booking form looks like the most trivial thing on your website. You drop in a few fields, hit "send", done. The trouble starts the moment you add a field like "what's bothering you?" or "medical history" — because from that point on you're collecting health data, which GDPR treats as a special category with much stricter rules.

The good news: you don't need a lawyer for every field. You need one simple principle — ask only what's strictly necessary to fix an appointment, and gather everything else in the practice, on the medical record, where you have a proper basis and confidentiality. In this article I'll show you concretely which fields you can use, what you should never put in a public form, and how to avoid the situations that trigger audits and fines from the data-protection authority (the ANSPDCP in Romania).

Why health data is a "special" category

GDPR (Article 9) treats health data as a special category — on par with ethnic origin or biometric data. A field like "what hurts", "chronic conditions" or "current medication" falls straight into it. Sometimes it's even implicit: the mere fact that someone books through an "implantology" or "periodontics" section can, on its own, reveal a condition.

This doesn't mean a dental practice isn't allowed to process such data — of course it is, that's the core of the job. It just means you need a stronger basis: either explicit consent, or the exception for the provision of healthcare (Art. 9(2)(h)) by a professional bound by confidentiality.

So the real question isn't "am I allowed?" but "how much health data do I actually need in the online form, and how do I protect it?"

The fields you can ask for a booking

The key principle is data minimisation (Art. 5): collect only what's strictly necessary for the purpose. And a booking form has exactly one purpose — to set a time. For that, this is enough:

• First and last name
• Phone (the channel you confirm on)
• Email (optional)
• The service, at a general level: check-up, cleaning, emergency — a category, not a diagnosis
• Preferred date and time slot
• An optional free-text "message" field where the patient writes whatever they want

That's enough to book anything. Notice that "service" stays general and "message" is optional — the patient decides what to reveal, you don't force it through a required field. Anything about detailed medical history gets filled in at the practice, on the record, where the setting is right.

What you should never put in a public form

These fields create the most risk and are the hardest to justify:

• Detailed medical history, chronic conditions, medication, allergies
• The national ID / personal numeric code (rarely needed to book, but a huge exposure if it leaks)
• Uploading X-rays or medical documents through an ordinary form without a secure channel
• Any required field that forces the patient to disclose a condition just to hit "send"

The logic is simple: the more sensitive data you gather through a website form, the higher the risk and the harder it is to prove it was necessary. Regulators look at exactly that — necessity and proportionality. If you still want the patient to be able to say something about their problem, leave it to the optional free-text field. That's their choice, not an imposed condition.

Consent, legal basis and the privacy policy

For the booking itself, the basis can be "steps prior to entering a contract" or legitimate interest. For any health data you need explicit consent or the healthcare exception. In practice, a correct form has:

• A checkbox that is NOT pre-ticked, with the patient's agreement and a link to the privacy policy
• A clear policy: who the controller is (the practice, with contact details), what data you collect, for what purpose, how long you keep it, and the patient's rights (access, erasure, rectification)
• Marketing consent kept separate — you may not make booking conditional on agreeing to a newsletter or ads

On top of that, keep a record of processing activities and, depending on the size of the practice, assess whether you need a data protection officer (DPO). A checkbox alone doesn't cover you — the whole set-up is what counts.

Where the data ends up: the technical part most people miss

A compliant form isn't only a matter of legal text, it's a matter of security (Art. 32). This is where practices most often slip:

• A site with no HTTPS — data travels unencrypted
• Submissions arriving as plain, unencrypted email in a personal Gmail the whole family can access
• Data sitting in a third-party tool outside the EU with no clear transfer basis
• No retention: leads pile up forever, long after they stopped being relevant

A typical leak isn't a dramatic attack — it's exactly the flow "form → personal inbox → lost phone". In practice you need: HTTPS, restricted password-protected access, a clear list of who sees the bookings, and a reasonable retention period after which you delete. That turns the form from a vulnerability into a controlled process.

What a properly built form looks like in practice

When we build a website for a dental practice at MPO Web Studio, we start from these principles instead of bolting them on at the end: minimal fields, a consent checkbox linked to the policy, HTTPS by default, and data landing in a controlled place rather than a random personal inbox.

We work remotely, across the whole country, and we prepare a free demo of your site with the form already designed this way — you see it working before you pay anything, with transparent pricing and no surprises.

If you'd like us to check your current form together, or build a compliant one from scratch, message us on WhatsApp. We're not a law firm — for fine legal interpretations it's worth consulting the ANSPDCP guidance or a DPO — but the web side we'll make solid from day one.