DPIA for Health Data: When It Is Required and What It Must Contain

For most of the economy, the DPIA question is genuinely a question. For health organisations it usually is not. Art. 35(3)(b) names processing on a large scale of special categories of data referred to in Art. 9(1) as a case where a DPIA shall in particular be required, and health data is Art. 9(1) data. A hospital information system, a regional registry, a telemonitoring platform, a laboratory information system — each of them lands on that provision before you have assessed anything.

The consequence is that the useful work is not deciding whether. It is producing an assessment that survives being read by a supervisory authority, and knowing when Art. 36 obliges you to show it to one before you go live.

Key Takeaways

• Art. 35(3)(b) makes the DPIA effectively mandatory for large-scale health processing. Recital 91 carves out the individual physician or health professional treating their own patients.
• Art. 35(7) fixes the minimum content in four elements. An assessment missing the necessity-and-proportionality element is the most common defect.
• The DPO must be consulted under Art. 35(2), and their advice and its treatment should be recorded.
• Art. 36(1) requires prior consultation where high risk remains after your mitigations — not where the processing was high risk to begin with.
• A DPIA is a live document: Art. 35(11) requires review at least when the risk represented by the processing changes.

When a Health DPIA Is Required

Art. 35(1) states the general test: where a type of processing, in particular using new technologies and taking account of the nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall carry out a DPIA prior to the processing. A single assessment may cover a set of similar operations presenting similar risks, which is what makes a platform-level DPIA workable.

Art. 35(3) then lists three cases in particular:

• (a) systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based producing legal effects or similarly significant effects — a risk-stratification or triage engine.
• (b) large-scale processing of Art. 9(1) special categories or Art. 10 criminal data — the health case.
• © systematic monitoring of a publicly accessible area on a large scale.

“Large scale” is not defined numerically. Recital 91 gives the direction: it concerns operations aiming to process a considerable amount of data at regional, national or supranational level affecting a large number of data subjects. It also states expressly that processing should not be considered large scale where it concerns patient data processed by an individual physician, other health care professional or lawyer. A single-handed practice is outside 35(3)(b); a group practice with a shared record, a clinic chain, or any platform aggregating across providers is not.

Two further sources bind the analysis. Under Art. 35(4) each supervisory authority publishes a list of processing operations requiring a DPIA, and most national lists name health data explicitly — check the list of your lead authority rather than reasoning from the Regulation alone. And the Article 29 Working Party Guidelines WP248 rev.01, adopted 4 October 2017 and endorsed by the EDPB, set out nine criteria: evaluation or scoring; automated decision-making with legal or similar significant effect; systematic monitoring; sensitive data or data of a highly personal nature; large-scale processing; matching or combining datasets; data on vulnerable subjects; innovative use of new technological or organisational solutions; and processing that itself prevents data subjects from exercising a right or using a service. Meeting two of the nine normally means a DPIA is required. A patient-facing digital-health product typically meets four or five without trying — sensitive data, vulnerable subjects, large scale, and innovative technology.

Art. 35(10) offers the only real exemption: where the processing rests on Art. 6(1)© or (e), the Union or member-state law regulating it already carried out an impact assessment when it was adopted, and that law regulates the specific operation. Public health bodies operating a statutory system sometimes qualify. Read it narrowly — it is not a general exemption for public hospitals.

The Art. 35(7) Content, Applied to a Clinical System

Art. 35(7) requires four elements. The wording is short; the work is in the specificity.

(a) A systematic description of the envisaged processing operations and the purposes, including any legitimate interest pursued. For a clinical system this means every module, not “the EHR”: admissions, clinical documentation, imaging, prescribing, results, secure messaging, billing, research extracts, audit logs, backups, support access. For each, the data categories, the subjects (patients, staff, next of kin, referrers), the recipients, retention, and the Art. 6 basis with the Art. 9(2) condition. This section should be generated from your Art. 30 record, and if it cannot be, the record is the thing to fix first.

(b) An assessment of the necessity and proportionality of the processing in relation to the purposes. The most frequently missing element, and the one authorities probe. It is a justification of each data element against each purpose: why identifiable rather than pseudonymised, why this retention rather than shorter, why this recipient list, why free-text fields that will accumulate data nobody scoped. Data minimisation is argued here or nowhere.

© An assessment of the risks to the rights and freedoms of data subjects. Not IT risk. The harm to the patient: disclosure of a diagnosis to an employer or family member, discrimination in insurance or employment, loss of care continuity if records are unavailable, distress from a wrongful inference, re-identification of a research extract. Assess likelihood and severity, and be explicit that severity is elevated because Recital 75 treats special-category data as inherently high risk.

(d) The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure protection of personal data and demonstrate compliance. Named, owned and dated — role-based access tied to the treating relationship, break-glass procedures with mandatory justification, log review that actually happens, encryption in transit and at rest, pseudonymisation for secondary use, Art. 28 contracts with secrecy obligations, and the Art. 32 controls proportionate to the assessed severity.

Two roles are fixed by the Regulation. Under Art. 35(2) the controller shall seek the advice of the DPO where one is designated; Art. 39(1)© makes advising on and monitoring the DPIA an explicit DPO task. Record the advice and what you did with it — a DPIA with no trace of DPO involvement is a procedural defect independent of its substance. Under Art. 35(9), where appropriate the controller shall seek the views of data subjects or their representatives. For a patient-facing system, a patient panel or representative body is the obvious route, and a documented reason for not doing so is better than silence.

Worked Example: a Patient-Facing Remote Monitoring Platform

A vendor operates a chronic-condition monitoring service. Patients are enrolled by their clinic, use a mobile app, and a connected device uploads readings; clinicians see a dashboard; the vendor also uses aggregated data to improve its algorithms.

Scoping. Two controllerships, not one. The clinic is controller for care; the vendor is processor for that, and controller for its own product-improvement purpose. The DPIA covers both and says which party owns which risk. Where the vendor is also a device manufacturer, the device-specific obligations sit alongside this.

35(3) triggers met. (b) large-scale Art. 9 data, certainly. (a) as well if the dashboard scores or ranks patients for clinician attention. WP248 criteria met: sensitive data, vulnerable subjects, large scale, innovative technology — four.

Risks that actually surface. Device readings continuing after enrolment ends. Push notifications visible on a lock screen disclosing a condition. Analytics or crash-reporting SDKs in the app transmitting to third parties. The product-improvement dataset being identifiable when it does not need to be. Clinician accounts retaining access after they leave the practice. Support engineers with production access.

Measures. Enrolment status enforced at the ingestion layer, not the interface. Neutral notification text by default. No third-party SDK in the app without its own assessment and legal basis. Product-improvement data pseudonymised at extraction with keys held separately. Automated deprovisioning tied to the clinic’s staff register. Support access time-boxed, justified and logged. Then reassess residual risk.

Outcome. If residual risk on the identifiable secondary-use dataset stays high — say pseudonymisation is not achievable because the algorithm needs longitudinal linkage — that is exactly the Art. 36 case. If the mitigations bring it down, document why and proceed.

Art. 36 Prior Consultation

Art. 36(1) requires consultation of the supervisory authority prior to processing where the DPIA indicates the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. The trigger is residual: high risk you have not been able to bring down, not the initial rating that put you into Art. 35 in the first place. Almost every health DPIA starts high; almost none should end there.

Art. 36(3) sets out what you submit — the respective responsibilities of controller, any joint controllers and processors, the purposes and means, the measures and safeguards, the DPO’s contact details, the DPIA itself, and anything else requested. Under Art. 36(2) the authority provides written advice within eight weeks, extendable by six more, and the clock can be suspended while it awaits information. Build that into the launch plan rather than discovering it. Our page on Art. 36 prior consultation covers the procedure, and the general DPIA guide the methodology outside a health context.

When to Redo It

Art. 35(11) requires review, where necessary, at least when there is a change in the risk represented by the processing. In practice, in this sector: a new module or data category, a new recipient or sub-processor, a change of hosting location or a new third-country transfer, the introduction of any automated scoring, a material change in retention, a significant security incident, or a change in national law under Art. 9(4). An annual review cycle plus event triggers is defensible; a DPIA signed once at procurement and never opened again is not, and it is the single most common finding when one is finally requested.

FAQ

Is a DPIA mandatory for every health organisation?

Not literally every one. Art. 35(3)(b) applies to large-scale processing of Art. 9 data, and Recital 91 states that patient data processed by an individual physician or other health care professional is not large scale. Everything above that — group practices with shared records, clinics, hospitals, laboratories, platforms — is caught, and the general Art. 35(1) high-risk test can catch a smaller operation anyway.

Can we reuse one DPIA across several clinical systems?

Art. 35(1) allows a single assessment for a set of similar processing operations presenting similar high risks. Similar means similar in data, purpose, recipients and risk profile. A common template with a per-system annex covering data flows, recipients and measures usually works; a single generic document covering unlike systems does not.

Do we have to publish the DPIA?

No. There is no publication obligation. Some authorities encourage publishing a summary, and doing so can help with the Art. 35(9) requirement to seek data subjects’ views. It must be available to the supervisory authority on request, and under Art. 36(3) it is submitted where prior consultation applies.

The vendor gave us their DPIA. Is that enough?

No. The DPIA obligation falls on the controller. A vendor’s assessment of its own product is useful input on security measures and can be annexed, but it cannot describe your purposes, your lawful bases, your recipients or your retention. Under Art. 28(3)(f) the processor must assist you; assistance is not substitution.

Does a DPIA also satisfy the AI Act?

No. Where an AI system is embedded in a medical device it falls under the Annex I route of Regulation (EU) 2024/1689, whose substantive high-risk obligations now apply from 2 August 2028 following the Digital Omnibus on AI approved by the Council on 29 June 2026. Those obligations run in parallel with Art. 35, not instead of it. Our guide to high-risk AI systems sets out the split; the wider picture for the sector is in the pillar guide for healthcare organisations.