GDPR for Medical Device Manufacturers and SaMD

Start with the appointment that almost every non-EU manufacturer has already made, and the one it has almost certainly not.

Under Art. 11 of Regulation (EU) 2017/745 (MDR) — and Art. 11 of Regulation (EU) 2017/746 for in vitro diagnostics — a manufacturer not established in a member state may place a device on the Union market only if it designates a sole Authorised Representative in the Union. Every regulatory-affairs department knows this. It is contracted, budgeted, renewed and named on the label.

The GDPR’s Art. 27 EU representative is a different obligation, under a different regulation, with a different trigger, different tasks, a different liability regime and, in practice, a different appointee. The MDR Authorised Representative does not satisfy Art. 27 GDPR. Neither does an MDR importer or distributor. This gets missed because the two communities barely overlap: the people who understand MDR Art. 11 do not read the GDPR, and the people who understand GDPR Art. 27 have never opened the MDR.

Key Takeaways

• MDR Art. 11 and GDPR Art. 27 are separate, cumulative appointments. Holding one does not discharge the other.
• Check your MDR mandate. It is drafted around conformity and vigilance and will not cover supervisory-authority correspondence about personal data.
• A manufacturer is usually a processor for data handled on a hospital’s instruction and a controller for telemetry it collects for its own purposes, including post-market surveillance.
• MDR Art. 83 obliges you to collect post-market data; GDPR Art. 5(1)© obliges you to collect no more than you need. Both hold, and the reconciliation belongs in the DPIA.
• Informed consent to a clinical investigation under MDR Art. 63 is not a GDPR lawful basis.

Two Representatives, Two Regulations

	MDR Art. 11 Authorised Representative	GDPR Art. 27 EU Representative
Instrument	Regulation (EU) 2017/745; Art. 11 of 2017/746 for IVDs	Regulation (EU) 2016/679
Trigger	Manufacturer not established in a member state places a device on the Union market	Controller or processor not established in the Union, caught by Art. 3(2)
Subject matter	Device conformity, safety and vigilance	Processing of personal data
Appointment	A sole representative, by written mandate accepted in writing, effective at least for a generic device group	Designated in writing, established in a member state where the data subjects are (Art. 27(3))
Core tasks	Verify the EU declaration of conformity and technical documentation; keep copies available; registration duties; forward authority requests; cooperate on corrective actions; pass on complaints (Art. 11(3))	Act as contact point for supervisory authorities and data subjects (Art. 27(4)); hold the Art. 30 record; cooperate under Art. 31
Liability	Jointly and severally liable for defective devices where the manufacturer has not complied with Art. 10 (Art. 11(5))	Controller and processor liability unaffected (Recital 80); the representative can be addressed in enforcement
Named where	Label, instructions for use, device registration	Privacy notice under Arts. 13 and 14
Failure to appoint	The device may not lawfully be placed on the Union market	Infringement under Art. 83(4)(a): up to EUR 10 million or 2% of turnover

Read across the rows and the incompatibility is structural. The MDR representative’s duties in Art. 11(3) run to the technical file, the declaration of conformity, device registration and vigilance cooperation. Art. 11(4) prohibits delegating to it the manufacturer’s own core obligations under Art. 10, and Art. 11(6) requires it to notify the competent authority and the notified body if it terminates the mandate. Nothing in Art. 11 mentions personal data at all. A regulatory-affairs firm supplying Authorised Representative services is not thereby willing, insured or competent to answer a data subject access request or take service of a supervisory authority’s inquiry.

There is even a numbering trap. MDR Art. 27 is the UDI system, and MDR Art. 11(3)© requires the Authorised Representative to verify that the manufacturer has complied with the registration obligations in MDR Arts. 27 and 29. So “our Article 27 obligations” means unique device identification to your regulatory manager and an EU data-protection appointee to your privacy counsel. Both are real; they are not the same conversation.

The practical instruction is short. Pull the MDR mandate and read its scope clause. If it does not expressly cover the Art. 27(4) GDPR functions, you have one appointment where you need two. Our detailed treatment of Art. 27 GDPR and the practical guide to selecting an EU representative cover the mandate drafting. Note also that the Art. 27(2) exemption — occasional processing, no large-scale Art. 9 data, no risk — is closed to a manufacturer handling patient data, because health data is Art. 9 special-category data.

Controller or Processor for Device Telemetry

The status question decides your contracts, your notices and who answers when a patient writes in. It is answered per purpose, not per company, and most manufacturers are both.

Processor for data processed on the instruction of the healthcare provider: readings displayed on a clinician dashboard, device configuration held on the provider’s behalf, hosted storage of a hospital’s device data. This needs an Art. 28 contract with the full Art. 28(3) content, and — because it is health data — an obligation of secrecy that satisfies Art. 9(3), not a generic confidentiality clause.

Controller for purposes you determine yourself: post-market surveillance and vigilance, product improvement, algorithm training, reliability engineering, warranty and service analytics, safety signal detection. Here you need your own Art. 6 basis and your own Art. 9(2) condition, your own privacy notice reaching the patient, and your own answer on retention. Legal obligation under Art. 6(1)© is often available for the vigilance limb because MDR imposes it directly on you; Art. 9(2)(i) is the natural pairing, given that it expressly names ensuring high standards of quality and safety of medical devices.

The failure mode is a contract that describes the manufacturer as a processor throughout while the product ships telemetry to the manufacturer’s cloud for its own analytics. A regulator reading the data flow rather than the contract will call that controllership, and the controller versus processor analysis is the document that should have been written before the DPA was signed.

Post-Market Surveillance Against Data Minimisation

MDR Art. 83 requires every manufacturer to plan, establish, document, implement, maintain and update a post-market surveillance system proportionate to the risk class and appropriate to the device, as part of its quality management system. Art. 84 governs the PMS plan, Arts. 85 and 86 the periodic reports, Art. 87 the reporting of serious incidents — immediately and not later than 15 days after awareness, reduced to 10 days for death or unanticipated serious deterioration in health and 2 days for a serious public health threat — and Art. 88 trend reporting. Technical documentation must be kept available for at least 10 years after the last device was placed on the market, 15 for implantables.

None of this displaces the GDPR. Art. 5(1)© still requires adequacy, relevance and limitation to what is necessary; Art. 5(1)(e) still requires storage limitation. The two are reconcilable and the reconciliation is a design decision:

• Identify the minimum dataset each MDR obligation actually needs. Serious incident reporting needs the incident, the device, the clinical outcome and enough context to establish causality. It does not need a continuous identified longitudinal record of every user.
• Pseudonymise at the boundary. Vigilance analysis typically works on a device or case identifier with the linking key held by the provider or held separately under strict control.
• Separate retention clocks. The MDR ten- and fifteen-year periods attach to technical documentation, not to every personal data element that fed it. Do not let a product-law retention period become the default for a patient database.
• Write the justification down. This is exactly the Art. 35(7)(b) necessity and proportionality analysis, and the health DPIA is where a manufacturer demonstrates that it collects what the MDR requires and no more.

Clinical Investigation Data

MDR Arts. 62 to 80 and Annex XV govern clinical investigations, with Art. 63 setting the informed consent requirements. The point that costs sponsors the most: consent to participate in a clinical investigation and consent as a GDPR lawful basis are separate instruments. Art. 63 consent is about the intervention and the risks. It does not by itself establish an Art. 6 basis or an Art. 9(2) condition, and an ethics committee opinion establishes neither.

Set the data-protection position expressly: your Art. 6 basis and Art. 9(2) condition for the investigation dataset, whether the sponsor and the investigating site are joint or independent controllers under Art. 26, what the site retains versus what it transfers, how withdrawal from the investigation interacts with data already collected, and the national research provisions that Art. 9(2)(j) and Art. 89(2) depend on. Retention under Annex XV runs to at least 10 years after the investigation ends, or 10 years after the last device is placed on the market, and 15 for implantables — periods that will exceed anything in your standard privacy notice unless you say so.

Where a sponsor outside the EU receives investigation data, Chapter V transfer rules apply, and the vital-interests derogation in Art. 49 is narrower than sponsors assume: it is for cases where the data subject is physically or legally incapable of giving consent, not a route for routine transfer of a trial dataset. Use standard contractual clauses with a transfer impact assessment.

SaMD Where the Vendor Never Meets the Patient

Software as a Medical Device produces the hardest allocations, because the vendor may have no relationship with the patient at all. Three recurring configurations:

Software installed on the provider’s infrastructure, no data returning to the vendor. The vendor is not a controller or processor for patient data. Its GDPR exposure is Art. 25 privacy by design and the assistance obligations built into its support contract. Support access to production is where this quietly becomes processing — time-box it, log it, and put it in the DPA.

Vendor-hosted SaMD. Processor for the clinical use, controller for its own analytics. Both roles need documenting and both need a lawful basis for their own limb.

Algorithm improvement on real-world data. The one that fails audits. Training on identifiable patient data collected for care is a further purpose, and Art. 6(4) compatibility does not stretch to it for special-category data. You need an Art. 9(2) condition in its own right — usually explicit consent or a research condition with a national legal basis — plus the Art. 89(1) safeguards. “Our DPA says we may use data to improve the service” is not a lawful basis. Where the software also embeds AI, note that a medical device follows the Annex I route of Regulation (EU) 2024/1689, whose substantive high-risk obligations apply from 2 August 2028 after the Digital Omnibus on AI approved by the Council on 29 June 2026; the deferral does not touch the Art. 5 prohibitions or the Art. 50 transparency duties. See our guide to high-risk AI systems.

Finally, national law. Art. 9(4) lets member states impose further conditions on health data — hosting certification, secrecy rules, retention — and those apply to you as much as to the hospital. The pillar guide for healthcare organisations sets out the framework your customers are working to; if you sell from outside the EU, our guide for Australian companies covers how territorial scope is established before any of this begins.

FAQ

Does our MDR Authorised Representative cover GDPR Art. 27?

No. They are separate obligations under separate regulations with different triggers, tasks and liability. Art. 11 MDR concerns placing a device on the Union market and says nothing about personal data; Art. 27 GDPR concerns processing and applies where Art. 3(2) catches you. You need both appointments, and typically two providers.

Can the same company hold both mandates?

Nothing prohibits it if the provider is genuinely willing and able to perform both, and the two mandates are separately documented with separate scopes. In practice most MDR representative firms decline the GDPR role, and a mandate written for one will not silently cover the other. Ask explicitly; do not assume from the word “representative”.

Are we a controller or a processor for device data?

Both, for different purposes. Processor for what you handle on the provider’s instruction, controller for what you do on your own account — vigilance, product improvement, analytics. Map it purpose by purpose in your Art. 30 record; a single global label will be wrong somewhere.

MDR says keep the data, GDPR says minimise it. Which wins?

Neither displaces the other, and the conflict is usually apparent rather than real. Determine the minimum dataset each MDR duty needs, pseudonymise beyond it, and keep separate retention clocks for technical documentation and for identifiable patient data. Record the reasoning in the DPIA under Art. 35(7)(b).

Is patient consent enough for using real-world data to train our algorithm?

It can be the right instrument, but it has to be explicit consent under Art. 9(2)(a), separately obtained, genuinely refusable without affecting care, and withdrawable — with a plan for what withdrawal means for a model already trained. A clause in the hospital’s data processing agreement is not patient consent and does not create an Art. 9(2) condition.