GDPR in healthcare: controller, processor and de-identified data

A hospital that signs a contract with a software or artificial intelligence (AI) vendor remains, in almost every case, legally responsible for patient data. The vendor works on the hospital's instructions, inside a contract whose content is fixed by law. This article explains what the General Data Protection Regulation (GDPR) requires in that relationship, where the line runs between pseudonymised, anonymised and "de-identified" data, and what the enforcement numbers in healthcare show.

Health data: a special category with its own legal bases

The GDPR prohibits, as a rule, the processing of "data concerning health", together with genetic and biometric data (Article 9(1)). The prohibition is lifted only in the cases listed in Article 9(2). For a hospital, the most used are:

• Point (h): processing necessary for diagnosis, the provision of health care or the management of health systems and services, on the basis of law or a contract with a health professional. Paragraph 3 adds: the data are processed by, or under the responsibility of, a person bound by professional secrecy.
• Point (i): public interest in the area of public health, including quality and safety standards of health care.
• Point (j): scientific research or statistics, with the safeguards of Article 89.
• Point (a): the patient's explicit consent, for specified purposes.

The practical consequence: a hospital information system, an appointment module or an assistant for frequently asked questions does not need separate consent if it serves the medical act or the administration of the service (point (h)). The definition is wide: under Article 4(15), it covers any data about physical or mental health, including the provision of health care services, which reveal health status. An appointment history at an oncology department qualifies.

Controller and processor: who answers for what

The GDPR defines two roles. The controller determines the purposes and means of processing (Article 4(7)). The processor processes data on behalf of the controller (Article 4(8)). The hospital decides why and how patient data are used, so it is the controller. The vendor that receives the data to deliver a service is the processor. The controller may only use processors that provide "sufficient guarantees" of security (Article 28(1)); the processor may not engage a sub-processor without written authorisation (paragraph 2) and remains fully liable for it (paragraph 4).

What the contract must contain (Article 28(3))

The contract between hospital and vendor must stipulate that the processor:

1. processes the data only on documented instructions from the controller;
2. ensures that authorised persons have committed themselves to confidentiality;
3. takes all security measures required by Article 32;
4. respects the conditions for engaging sub-processors;
5. assists the controller in responding to patients' requests (access, rectification, erasure);
6. assists the controller with security, breach notification and impact assessments (Articles 32 to 36);
7. deletes or returns all data at the end of the service;
8. makes available all information needed to demonstrate compliance and allows audits.

The Dedalus Biologie case shows what happens when these clauses are missing. According to CNIL, the French data protection authority, on 15 April 2022 the company, a software vendor for laboratories, was fined EUR 1.5 million after a leak of medical data of about 500,000 people. According to Orrick's analysis, the breaches were of Articles 28(3), 29 and 32: the contracts lacked the mandatory clauses, the vendor migrated more data than its clients had asked for, and the data were not encrypted. The fine went to the processor, not to the laboratories.

The vendor does not "take over" responsibility for patient data. The hospital remains the controller, and the vendor answers for what it does with the data outside the instructions and for their security.

Minimisation, pseudonymisation, anonymisation and "de-identification"

Article 5(1)(c) requires data to be "adequate, relevant and limited to what is necessary" for the purpose. For a software project the concrete question is: which fields does the vendor need to deliver the function? Three terms are often confused here, and the difference between them decides whether the GDPR still applies.

Term	What it means	Does the GDPR still apply?	Example
Pseudonymisation (Article 4(5))	Data can no longer be attributed to a person without "additional information", kept separately and protected	Yes. According to the European Data Protection Board, EDPB (17 January 2025), pseudonymised data remain personal data	Name replaced by a code; the lookup table stays at the hospital
Anonymisation (Recital 26)	The person "is not or no longer identifiable", taking into account the means "reasonably likely to be used" (cost, time, technology)	No. The GDPR does not apply to anonymous information	Aggregated statistics by age group with no way to re-identify
"De-identification"	A term with no definition in the GDPR. In practice it covers anything from removing the name to true anonymisation	It depends on what was actually done	An image set with direct identifiers removed

When a vendor says it works on "de-identified data", the right question is: is there still a reasonable way to re-identify people? If the hospital keeps the lookup key, the data are pseudonymised and the whole GDPR regime applies, including the Article 28 contract. EDPB Guidelines 01/2025 state explicitly that pseudonymisation reduces risk but does not take the data outside the regulation.

Research, transfers and AI projects: impact assessment and human oversight

For research, Article 89(1) requires appropriate safeguards and minimisation, in an order of preference: pseudonymisation "provided that those purposes can be fulfilled in that manner", and where the purposes can be met without identifying people, processing is done that way. A research contract should fix the precise purpose, the legal basis (Article 9(2)(j)), the form in which the data leave (pseudonymised or anonymised) and who keeps the key.

The GDPR does not require data to be stored on EU territory, but a transfer outside the European Economic Area is allowed only through the mechanisms of Chapter V. According to the European Commission, since 10 July 2023 an adequacy decision covers the EU-US Data Privacy Framework: data can flow to US companies participating in it, while standard contractual clauses and binding corporate rules remain available for the rest. Breaching the transfer rules falls in the upper tier of fines (Article 83(5)).

Article 35 requires a data protection impact assessment (DPIA) before any processing which, in particular through new technologies, is likely to result in a high risk. Paragraph 3(b) makes it mandatory for large-scale processing of special categories, so an AI project on a hospital's patient records qualifies almost automatically. The minimum content (paragraph 7): a description of the processing and its purposes, an assessment of necessity and proportionality, the risks to patients and the measures to address them.

The European AI Act (Regulation (EU) 2024/1689) sits on top of the GDPR. According to the European Commission's page, obligations for high-risk systems apply from 2 December 2027, and for systems embedded in regulated products (Annex I, for example medical devices) from 2 August 2028, with "appropriate human oversight measures" among the requirements. Whatever the classification, one operating principle resolves many risks at once: AI-generated text that reaches a patient passes through a human first. A generated summary or answer is a proposal for staff, not a final communication.

Incidents, deadlines and fines: what the healthcare numbers show

Article 33 requires notification of the supervisory authority "without undue delay and, where feasible, not later than 72 hours" after becoming aware of a breach. The processor notifies the controller "without undue delay" (paragraph 2). When the risk to patients is high, the controller informs them too (Article 34). In the contract, the time within which the vendor alerts the hospital must be written explicitly, so that the hospital can meet the 72 hours. Fine ceilings (Article 83): EUR 10 million or 2% of turnover for controller and processor obligations, EUR 20 million or 4% for the principles, Article 9 and transfers.

The real figures in healthcare are far below the ceilings, but rising. According to the CMS GDPR Enforcement Tracker Report 2026 (data up to 1 March 2026), authorities from 27 European countries have imposed 265 fines on hospitals, pharmacies, physicians and healthcare suppliers, totalling about EUR 32.3 million. Earlier editions recorded 202 fines and EUR 16.5 million (May 2024), then 237 fines and EUR 22.8 million (May 2025). New fines in 2025 were 26% more than in the previous period.

The most frequent reason is constant: insufficient technical and organisational measures, with 100 fines and EUR 22.8 million cumulative, according to the 2026 edition. According to the 2025 edition, the average fine for this type of breach jumped in 2024 to EUR 203,423, from EUR 17,500 in 2023. For Romania, the 2024 edition notes that in 2023 the national authority (ANSPDCP) imposed 5 fines in healthcare, second after Italy (23), at an average sector fine of EUR 27,300.

According to ENISA, the EU Agency for Cybersecurity, which analysed 215 publicly reported health-sector incidents between January 2021 and March 2023, ransomware appeared in 54% of incidents and threats against data (leaks, theft) in 46%. Hospitals were the target in 42% of incidents. Only 27% of surveyed organisations had a dedicated ransomware programme. ENISA also notes that many leaks of the pandemic period were accidental, caused by misconfigurations rather than attacks.

Republic of Moldova: Law 195/2024 has replaced Law 133/2011

Until August 2026, data protection in Moldova was governed by Law no. 133/2011, built on Directive 95/46/EC, the predecessor of the GDPR. According to the National Centre for Personal Data Protection (CNPDCP), from 23 August 2026 the legal regime is set by Law no. 195/2024, adopted to align national standards with international ones and to obtain recognition of Moldova as a country with an adequate level of protection. Entry into force is confirmed by the local business press, which also notes the two-year transition period and the graduated approach to sanctions.

The structure of the law follows the GDPR, with the same numbering for the principles (Article 5), the processor (Article 28), security (Article 32), breach notification (Articles 33 and 34) and the data protection officer (Articles 37 to 39). The CNPDCP guidance carries over the deadline too: the controller notifies the Centre "without undue delay and, where feasible, not later than 72 hours". The definition of health data covers "past, present or future" physical or mental health.

Two transitional details matter for hospitals: consents obtained under Law 133/2011 remain valid if they meet the conditions of the new law, and CNPDCP decisions issued under the old law remain in force until amended or repealed. For a vendor serving both countries, the same processing agreement, DPIA and notification procedures cover, in substance, both Romania and Moldova.

What this means for a hospital in Romania or Moldova

The steps below need order more than budget, and a few documents signed before the first line of integration.

1. Set the roles in writing. The hospital is the controller; the vendor is the processor. If the vendor wants the data for its own purposes too, it is no longer a plain processor.
2. Sign the processing agreement before access. Check the eight elements of Article 28(3) and ask for the list of sub-processors.
3. Reduce data to the minimum. An appointment assistant needs a name, a phone number and a time slot, not a diagnosis.
4. Name things correctly. "De-identified" is not a legal status. Write into the contract whether the data are pseudonymised (GDPR applies in full) or anonymised (no reasonable way to re-identify).
5. Run a DPIA for any AI project on patient data. Include the rule "a human checks before text reaches the patient".
6. Fix the notification chain. The vendor alerts the hospital within hours, with a written deadline, so that the hospital can meet the 72 hours.
7. Ask for the location of data and logs. Servers, AI service, and the transfer mechanism if data leave the EU/EEA.
8. Invest in the basic technical measures. Multi-factor authentication, reviewed access logs, encryption, tested backups. According to CMS, their absence is the most frequent reason for fines in healthcare.

Questions for a vendor before signing: Where does the model run and where are the logs kept? Do you use our data to train models for other clients? How quickly do you alert us to an incident? How do you demonstrate that a data set is anonymous and not merely pseudonymised? A serious vendor answers in writing, in the contract.

Consdinamic builds software and AI to order, with its deepest specialisation in healthcare, and works with these rules every day: its own products run in the private medical network Gral Medical (Romania, 29 locations), and in the collaboration with Aiforia (Finland) we work on de-identified digital pathology data sets, with the form of the data and the roles of the parties fixed in the contract before any transfer. The company has been registered in Moldova since 2008, with its EU sister company Softmed Labs SRL.

Conclusion

The GDPR does not stop hospitals from working with software or AI vendors. It asks them to remain conscious controllers, to bind the vendor through a contract with the content of Article 28, and to treat health data as a special category. The difference between pseudonymisation and anonymisation decides whether the regulation applies; "de-identification" has to be translated into one of those two terms. Fines come mostly from insufficient security measures, incidents from ransomware and configuration errors. Since 23 August 2026 Moldova applies the same rules through Law 195/2024, which simplifies the work of anyone serving institutions on both banks of the Prut.