Assuming pseudonymised data is out of scope
Pseudonymised data is still personal data. Only genuinely anonymous data — irreversibly so, judged against reasonably available means — falls outside the regulation.
GDPREU Data Protection
The GDPR — Regulation (EU) 2016/679 — governs how personal data about people in the EU and EEA is collected, processed, stored and shared. Health data is a special category under Article 9: processing it is prohibited by default and permitted only under a specific listed condition, which for most digital health products means explicit consent or a healthcare-provision basis.
- Full title
- Regulation (EU) 2016/679 — General Data Protection Regulation
- Issued by
- European Parliament and Council
- Applies
- EU and EEA, with extraterritorial reach to organisations targeting people in them
What it covers
- A lawful basis for every processing activity, plus an Article 9 condition for health data
- Data minimisation, purpose limitation, and storage limitation
- Data subject rights: access, rectification, erasure, portability, and objection
- Controller and processor roles, and the Article 28 contracts between them
- Security of processing under Article 32
- Data protection impact assessments where processing is high risk — which health data at scale generally is
- Breach notification to the supervisory authority within 72 hours of becoming aware
- Restrictions and safeguards on transfers outside the EEA
In practice
The determination that decides most of the architecture is controller versus processor. Selling a platform to a hospital usually makes the hospital the controller and you the processor, which constrains what you may do with the data — including, critically, whether you may use it to train models. A direct-to-consumer app is generally its own controller, and carries the full weight of consent, rights handling and transparency. Get this wrong and the contracts, the privacy notice and the retention design are all wrong together.
Two further points bite in practice. Consent must be freely given, which is difficult when the service cannot be delivered without the data — so consent is often the wrong basis to reach for first. And secondary use for research or product improvement needs its own analysis, not a clause buried in the terms.
Where teams get it wrong
Reaching for consent as the default basis
It is revocable, it must be freely given, and it collapses awkwardly when the product cannot function without the processing it supposedly authorises.
Quietly training models on customer data
Where you are a processor, using the data for your own purposes without documented instruction is a role breach before it is anything else.
Common questions
Are we a controller or a processor?
Whoever determines the purposes and means of processing is the controller. Selling a platform to a hospital usually makes the hospital the controller and you the processor, which constrains what you may do with the data. A direct-to-consumer app is generally its own controller, carrying the full weight of consent, transparency and rights handling.
Can we train AI models on customer health data?
As a processor, only on the controller’s documented instruction — using it for your own purposes is a role breach before it is anything else. As a controller, you need a lawful basis and an Article 9 condition for that specific secondary purpose. A clause buried in the terms of service is not sufficient for either.
Is pseudonymised data still personal data?
Yes. Pseudonymisation is a security measure, not an exit from the regulation. Only genuinely anonymous data falls outside GDPR, and the test is whether re-identification is possible using means reasonably likely to be used — which is a higher bar than removing direct identifiers.
Working out how GDPR applies to what you are building is usually the first conversation.
Get in touch →