Every booking form on a clinic website collects personal data: name, phone, often the doctor or service, and sometimes a description of symptoms. Under the form there is usually a tick box “I agree with the privacy policy” linking to a page nobody has read, the clinic included. Let us look at what the law requires, where clinics go wrong and how to do it right on the website. The policy text itself is written by your lawyer — this article is about how to put it into practice.
Short answer
A clinic website must explain to the patient who collects their data and why, and obtain a basis for processing — before the data is sent.
- Article 12 of the law: at the moment of collection the patient must learn who the data controller is, what data is collected, why, to whom it is passed and what rights they have.
- Article 7: health data is a special category. In the website form, collect the minimum.
- The consent tick box must not be pre-ticked, and analytics and pixels must not receive data from the form.
In plain wordsConsent is like the patient’s signature on an informed consent form before a procedure. They must know what they are agreeing to and agree themselves, not find the tick already made.
What the law says
The Law of Ukraine “On Personal Data Protection” defines consent as a person’s voluntary expression of will, given with full information, to the processing of data for a stated purpose — in writing or in a form from which consent can be inferred (Article 2).
Consent is not the only basis. Article 11 also names, among the bases, concluding and performing a contract with the data subject or measures preceding the conclusion of a contract at their request, and performing an obligation provided for by law. Which of these is the basis for your booking form — consent, or booking an appointment as a step towards a contract — is for your lawyer to determine.
But whatever the basis, Article 12 requires that at the moment of collection the person learns:
- who the data controller is;
- what data is collected;
- the purpose of collection;
- to whom the data is passed;
- their rights under the law.
For the website this means: the privacy policy must be next to the form, not just in the footer, and answer these five questions for your clinic.
Health data is a separate matter
Article 7 places data concerning health in a special category: processing it is prohibited except in cases defined by law, including with the person’s unambiguous consent or to provide medical services by a licensed institution whose staff are bound to keep medical confidentiality.
In practice for a website:
- For booking, name, phone, doctor or service and time are enough.
- A “describe your symptoms” or “diagnosis” field in a public form is a question for the lawyer: how and where this data is stored, who sees it, whether it goes by email to a shared mailbox or into a messenger.
- Even choosing a service such as “infertility treatment” says something about health — so it must not get into analytics and ad accounts.
What requirements the law sets for advertising medical services themselves is covered in the article on advertising.
Where clinics go wrong on the website
- The tick box is already ticked. Consent must be an action by the patient, not a default setting.
- The policy is a template from the internet. It has other people’s names, another purpose, and nothing about the MIS, CRM or email service the data is actually passed to.
- Form data gets into analytics. Meta or Google pixels and counters sometimes collect form fields or page addresses with parameters in which a name or service is visible.
- Requests go to a messenger. The form sends patient data to a shared receptionists’ chat where everyone sees it, including people who no longer work there.
- Nobody knows where the data lies. Requests on the website, in email, in the CRM — and no retention period.
How to do it right on the website
The booking form. Only the necessary fields. Under the button, a short explanation of who processes the data and why, and a link to the policy that opens alongside without losing the filled-in form. If the basis is consent, the tick box is not ticked in advance and the form cannot be submitted without it. Where the request goes next, into the MIS or CRM, is covered in the article on the website and the MIS.
Recording consent. Together with the request, the website stores when exactly and with which version of the policy the patient agreed. If the policy changes, the old version stays in the archive.
Recipients. The policy lists to whom the data is passed: your MIS or CRM, email service, hosting. If you add a new service, update the policy.
Analytics and advertising. Only the “booking” event goes to GA4 and ad accounts, without name, phone, service or doctor. How to check this is covered in the article on the technical audit.
Cookies. Whether your website needs a consent banner for analytics and advertising cookies is a question for your lawyer. If the clinic sees patients from the EU, GDPR applies to them, and it requires consent for non-essential cookies. Then pixels and analytics switch on only after “Accept”.
Access and retention. Only people who need requests see them, with access by role. A retention period is defined, and after it requests are deleted.
Before launching the booking form
Check as you go
Before launching the form
Your ticks stay in this browser.
Questions clinic owners ask
Can we take a privacy policy template from the internet?
As a draft, yes; as the final text, no. The policy must describe your clinic: who the controller is, what data your website collects, to whom it is actually passed. A template knows nothing about that.
Do we need a tick box if the patient is just booking an appointment?
It depends on the basis for processing: consent, or booking as a step towards a contract for medical services. The lawyer decides. But informing the patient about the controller, purpose, recipients and rights under Article 12 is required in any case.
Can we keep the “describe what is bothering you” field?
Technically yes, but it is health data. Decide with your lawyer whether it is needed in a public form, and make sure this data does not go by email to a shared mailbox, into a messenger or into analytics.
Who is responsible if data from the website leaks?
The clinic, as the data controller. That is why it matters to know where requests are stored, who has access to them, and that the contractor has set things up exactly as the policy describes.
For your developer
- The form. Minimum fields, consent inactive by default, validation does not let the form be submitted without it; the policy link opens without losing the form data.
- Consent log. Time, request identifier and policy version are stored together with the request; policy versions are archived.
- Analytics. Form fields and URL parameters with personal data do not reach the dataLayer, GA4 or pixels; the booking event carries no personal or medical data.
- Cookies. If a banner is needed, analytics and pixels switch on only after consent, and the decision is stored.
- Retention. Requests in the website database with access by role, HTTPS, backups; automatic deletion after the agreed period.
If you would rather not do it yourself
We build clinic websites on WordPress with booking forms that collect only what is needed, store consent and do not pass patient data to analytics. The policy text is written by your lawyer — we implement it on the website. Tell us about your clinic: within two working days we send a structure review, an indicative timeline and a price, with no obligation. See our clinic website page.