GDPR Patient Intake Forms Software for EU Clinics (2026 Guide)

GDPR Patient Intake Forms Software for EU Clinics (2026 Guide)

Patient intake forms collect some of the most sensitive personal data a clinic handles: health history, current medications, allergies, emergency contact details, and in some cases financial or insurance information. Under GDPR, collecting this data without clear lawful basis, without demonstrating that only necessary data is collected, and without providing adequate security and subject rights mechanisms is a compliance failure with regulatory and financial consequences.

For EU clinics choosing patient intake forms software, GDPR compliance is not a checkbox on a feature list — it is a design requirement that shapes what the software can and cannot do. A form builder that collects every conceivable piece of health information "just in case" violates data minimisation principles. A software vendor that stores form data on servers outside the EU without an adequacy decision or standard contractual clauses creates a data transfer compliance problem. A system that has no mechanism for honouring subject access requests leaves the clinic unable to respond within the GDPR-mandated one-month deadline.

This guide covers how to evaluate patient intake forms software specifically through a GDPR compliance lens for EU clinics.

GDPR Principles Applied to Patient Intake Forms

Lawful basis: Article 6 and Article 9

Patient intake forms typically collect two categories of data:

Standard personal data (name, contact details, date of birth): The lawful basis is GDPR Article 6(1)(b) — processing is necessary for the performance of the service contract with the patient. The patient cannot receive care without the clinic knowing who they are and how to contact them.

Health data (medical history, medications, allergies, diagnoses): This is special-category data under Article 9. The lawful basis for clinical care is Article 9(2)(h) — health care purposes. Processing health data for the purpose of providing health care does not require separate consent from the patient; it is a recognised lawful basis. However, the data protection policy must reference this basis, and the ROPA (Record of Processing Activities) must document it.

Marketing consent (newsletter, promotional communications): If the intake form includes a marketing opt-in, this is separate from the clinical data and requires Article 6(1)(a) explicit consent — freely given, specific, informed, and unambiguous. It cannot be bundled into the clinical consent to treatment.

Data minimisation: collect only what is necessary

Every field on a patient intake form should have a clear clinical or operational justification. Questions that do not serve the clinical purpose of the intake should be removed.

Common examples of non-necessary fields on clinic intake forms:

• Employer name and occupation (unless clinically relevant — e.g., an occupational health or physiotherapy context where work activities drive the presenting condition)
• Religious or political beliefs (not relevant to most clinical care)
• Sexual orientation or gender identity (not relevant unless specifically pertinent to the clinical context)
• Social media handles
• Where the patient first heard about the clinic (this is marketing research, not clinical data — if captured, it should be in a separate, optional section with clear purpose statement)

The principle: if the clinician could not use this field to make a clinical decision, reconsider whether it belongs on the clinical intake form.

Purpose limitation: use data only for stated purposes

Data collected for clinical care (health history, medications) must not be used for marketing purposes without separate consent. If the clinic intends to use intake form data for purposes beyond direct care — research, quality improvement programmes, referral to partner services — these purposes must be disclosed at intake and, where consent is required, obtained explicitly.

Security: secure transmission and storage

Patient intake forms transmit sensitive health data. The software must:

• Use HTTPS for all form submission (encrypted in transit)
• Store form responses in an encrypted database
• Restrict access to form responses by role (not all staff need access to all patient health histories)
• Be GDPR-ready or have an adequacy decision / SCCs in place for any data transfer outside the EU

Retention: defined periods and deletion mechanisms

Intake form data should be retained for the same period as the patient's clinical record — typically 8–10 years from last contact for adult patients, longer for minors. After the retention period, the data should be deleted or anonymised.

The software must support:

• Configurable retention periods per data category
• Deletion or anonymisation workflow at end of retention
• Data subject erasure requests: the ability to delete a specific patient's intake data on request (subject to clinical retention obligations)

Key Features to Evaluate

Purpose-based field design

The software should support configuring which fields are shown based on the purpose of the intake. A field for clinical health history should be separate from a field for marketing consent — both in the form design and in how the data is stored and accessed.

Explicit and separate consent capture

The software must support distinct consent checkboxes for distinct purposes. "I consent to the processing of my health data for clinical care AND to receive the clinic's newsletter AND to participate in anonymous research" in a single checkbox is not valid GDPR consent. Each purpose must have its own checkbox, and none can be pre-ticked.

Secure transmission and EU-hosted storage

Confirm that form submission uses HTTPS (look for the padlock in the browser; verify in the technical documentation). Confirm that form data is stored within the EU — the software vendor's privacy policy or processor terms should specify the data centre location.

Retention and deletion policy alignment

The software should support a configurable retention period for form data. At end of retention, form responses should be deletable or anonymisable without requiring manual intervention. The software should also support extraction of all intake form data for a specific patient on a subject access request.

Subject access and correction flows

The software must be able to:

• Export all form responses for a named patient (for subject access requests)
• Correct inaccurate data entries (patient's right to rectification under Article 16)
• Delete data at end of retention or on erasure request (Article 17, subject to clinical retention obligations)

Test these flows before purchasing — not all form software that claims GDPR compliance actually implements these mechanisms.

Platform Comparison

Feature	Tregovia	Typeform (enterprise)	Jotform (HIPAA/GDPR tier)	Paper forms (digitised)
Lawful basis documentation	Yes	No (admin responsibility)	No (admin responsibility)	No
Separate consent per purpose	Yes	Manual configuration	Manual configuration	Manual
Privacy controls	Review	EU option available	EU option available	N/A
Subject access export	Yes	Manual	Manual	Manual
Retention policy + deletion	Yes	Manual	Manual	Manual
Clinical record integration	Yes	No	No	No
Flat-rate pricing	Yes	No (per response/user)	No (per user)	N/A

Verify current GDPR feature sets and EU hosting options at each vendor's website.

Setting Up in Tregovia

Tregovia's Forms Intake module (EUR 15/month) can support a GDPR-aware EU clinic intake workflow:

• Structured templates: Intake, consent, feedback, survey, and other template categories
• Configurable fields: Text, textarea, number, date, email, phone, select, multi-select, checkbox, radio, file upload, and signature field types
• Appointment linkage: Templates can be linked to appointment types, and submissions can be tied to a client and appointment
• Review workflow: Submissions move through draft, submitted, reviewed, and archived statuses
• Privacy request support: User and portal export/deletion request flows exist elsewhere in the platform

Processor terms and hosting: Confirm current privacy terms, hosting, retention, and sub-processor terms before collecting special-category health data.

Pricing: Forms Intake module EUR 15/month on top of the EUR 47/month base plan. The base plan includes up to 100 clients and up to 2 staff; extra users are EUR 10/month per 5-seat pack.

FAQ

What intake mistake creates GDPR risk fastest?

Collecting extra data without clear lawful basis — specifically, collecting health data beyond what is needed for the current clinical purpose. A new patient registration form for a physiotherapy clinic does not need to ask about the patient's sexual health history. A dental clinic does not need to ask about mental health diagnoses unless the treatment directly involves that clinical context. Overcollection of special-category health data without a documented basis is one of the fastest ways to attract regulatory attention. Audit your intake forms annually and remove any field whose clinical purpose cannot be stated clearly.

Should marketing consent be bundled into the clinical consent to treatment?

No. GDPR Article 7(2) requires that if consent is given in the context of a written declaration which also covers other matters, the request for consent shall be presented in a manner which is clearly distinguishable from other matters, in an intelligible and easily accessible form, using clear and plain language. A single checkbox that covers clinical consent, marketing consent, and research participation simultaneously fails this requirement. Separate consent fields for each purpose are mandatory. Each should have its own checkbox; none should be pre-ticked.

How do clinics reduce intake friction while remaining GDPR-ready?

Progressive form logic and concise explanations. Rather than presenting a 50-field form at once, progressive logic shows the most essential fields first and reveals additional fields based on responses — a patient who selects "no" to a medication question doesn't see the medication detail fields. Concise explanations tell the patient why each question is asked ("We need your medication list to ensure we prescribe safely") — this both builds trust and demonstrates purpose limitation. The combination of progressive logic and plain-language explanations reduces the perceived burden of intake without reducing the data collected.

What should be reviewed quarterly for intake form GDPR compliance?

Three things: field necessity (is every field still clinically justified? Any new fields added by well-intentioned staff without a documented purpose?), consent language (is the consent text still accurate for the data being collected and the purposes being served? Has the privacy policy been updated since the consent text was written?), and retention settings (has the software configuration been updated to reflect the current retention policy? Any historical data reaching the end of its retention period that needs deletion?). Quarterly review is sufficient for most clinics; annual review is the minimum.

What should happen when a patient requests deletion of their intake form data?

The clinic must respond within one month. For clinical data, the response is typically: the data cannot be fully deleted during the applicable retention period (clinical records must be retained for regulatory and legal purposes), but the patient is informed of this basis and the retention period, and any non-clinical data (marketing consent records, if separate) is deleted immediately. The partial response — explaining what will and won't be deleted, and why — should be documented and retained as evidence of the clinic's compliance with the erasure request. Never ignore an erasure request; even where full deletion is not possible, the obligation to respond and explain is absolute.