Patient Privacy on Website Forms: The Answer for Dentists

#The right worry

Practices are right to ask this. A dental website's forms collect personal data and sometimes health data, and health data carries the strictest rules in every privacy regime. The good news is that a well-designed site collects very little through the website itself, and puts the sensitive parts where they belong. Here is the practical version.

This is general guidance rather than legal advice; the practice's data protection lead or adviser should confirm the specifics.

#Separate the two kinds of form

The booking or enquiry form needs: name, mobile, email, the appointment or question, and a free-text line. That is personal data, held on the basis that you need it to provide the service. No health questions.

The medical history form needs: conditions, medications, allergies, pregnancy, previous reactions, and consent. That is health data, special category under GDPR, protected health information under HIPAA where it applies. It is collected after booking, through a system built for it, and never through a general website contact form.

Keeping the two apart is most of compliance and most of conversion: nobody wants to type their medications into a phone form to find out whether you do Saturday appointments.

#Where medical history goes

• The practice management system's patient portal. Dentally, SOE, Dentrix Ascend and others send a medical history form on booking, and the answers land in the patient record, encrypted, access-controlled, audited. This is the best option and the one to use if you have it.
• A health-data-capable form tool, if the PMS does not have one: tools that state HIPAA compliance and will sign a Business Associate Agreement (US), or that publish a Data Processing Agreement covering special category data (UK/EU). Jotform HIPAA, Typeform with the appropriate plan, IntakeQ and similar. Responses go into the tool's secure storage or the PMS, not into email.
• Paper at the appointment, for practices without either. Slower, but compliant if stored properly.

Never: a Google Form into a spreadsheet, a generic WordPress contact form emailing the answers to reception, or a PDF the patient emails back.

#What the website itself must do

A privacy notice, linked from every form and the footer, saying what is collected, why, on what basis, who processes it (your PMS vendor, your form tool, your email service, your booking system), how long it is kept, and how patients exercise their rights. One page, plain words. Your national regulator provides templates.

HTTPS everywhere. Non-negotiable. Forms on an unencrypted page are a breach waiting to happen.

Minimal fields on the enquiry form. Every field you do not need is data you are responsible for and a reason for the patient to abandon.

A separate, unticked marketing consent box if you send anything beyond appointment communications. Never bundled into the booking terms.

Form delivery to a monitored practice address, not to a personal email, and not to a former employee's. Enquiry emails contain personal data; they should live in the practice's systems and be deleted on a schedule.

No health data in URLs or analytics. Do not pass form answers as query parameters; do not send form field contents to analytics tools. Track that a form was submitted, not what it said.

Cookie consent that actually gates non-essential cookies, in regions that require it (UK, EU and increasingly elsewhere).

Retention. Decide how long enquiry data is kept (a few months for enquiries that did not become patients is typical) and delete on schedule. Patient records follow the statutory clinical retention period, which is much longer, and live in the PMS.

#HIPAA specifics, for US practices

If the practice bills insurance electronically, it is a covered entity. Any vendor that stores or transmits protected health information on its behalf, including a form tool holding medical histories or a booking tool holding appointment types and names, must sign a Business Associate Agreement. Most general-purpose website form plugins will not, which is why medical history does not go through them. The website's enquiry form, collecting name and contact details for a general enquiry, is usually outside PHI; the moment it asks about a dental condition, it is arguably inside. Keep it out.

#GDPR specifics, for UK and EU practices

Health data requires an Article 9 basis, usually explicit consent or the provision of health care by a professional. The form should say why the information is collected and that it is used for treatment. A Data Processing Agreement with each processor. A record of processing activities that includes the website forms. Data subject requests honoured within the statutory period, which means knowing how to export and delete a patient's data across the PMS, the form tool and the email archive.

#A ten-minute check on your current site

1. Does the contact or booking form ask any health question? Remove it.
2. Where does the medical history form live, and where do its answers go? If the answer is "email", change it.
3. Is there a privacy notice linked from the form? Is it accurate about the tools you actually use?
4. Is the marketing consent separate and unticked?
5. Where does the enquiry form deliver, and who reads it?
6. Is every page HTTPS?
7. Do you have a DPA or BAA with your form tool and booking tool?

#Where this sits

Every dental practice site we build keeps the enquiry form minimal, routes medical history through the PMS or a compliant tool, links a privacy notice written for the practice's country, and delivers forms to the practice's own monitored address. It is a small amount of design and it is the difference between a site that is compliant by construction and one that is a complaint waiting to be made.