MDD to EU MDR transition: complete checklist for medical software

The transition deadlines — and why they are already urgent

Two years of transition deadline extensions gave many MDD-certified companies a false sense of security. There are no further extensions coming for most device classes. The calendar is clear: Class IIb implantable devices and Class III must be fully MDR-certified by 31 December 2027. Everything else — Class IIb non-implantable, Class IIa, and up-classified Class I — by 31 December 2028.

But here is the urgency problem: even with a 2028 deadline, factoring in 12–18 months for Notified Body review and 6–12 months in the NB intake queue, companies targeting the 2028 deadline need to submit their MDR technical file to a Notified Body no later than Q1 2027 to have reasonable confidence of receiving their certificate before the deadline. That is now less than 12 months away.

What MDR transition actually means — the honest version

Many companies approach MDD-to-MDR transition expecting to do a documentation update — add a few sections, reformat some files, and submit to an NB. This expectation is wrong and leads to very expensive surprises when NBs return their files with lists of major non-conformities.

MDR transition is a full recertification project. The technical file structure is different, the clinical evidence requirements are dramatically higher, the post-market obligations are new, and the QMS requirements have expanded. For most SaMD, the honest truth is that you are building a new MDR technical file that may incorporate some content from the old MDD documentation.

The MDD-to-MDR transition checklist for software

Technical Documentation (Annex II)

• Rewrite device description to include intended purpose, intended users, patient population, contraindications, and clinical context in the specificity MDR requires
• Update software documentation section: IEC 62304 compliance evidence (software classification, architecture, V&V evidence, SOUP list) — MDR expects significantly more detail than MDD
• Rebuild the GSPR checklist from EU MDR Annex I — mapping to MDR GSPRs, not MDD Essential Requirements. For each GSPR, document how conformity is demonstrated and which standard/document is the evidence
• Update risk management file to ISO 14971:2019 format — including the updated risk/benefit terminology and the requirement to demonstrate acceptable residual risk after controls
• Update usability engineering documentation to IEC 62366-1:2015
• Add cybersecurity documentation per MDCG 2019-16 — this was not required under MDD
• Update labelling and Instructions for Use to EU MDR Annex I Section 23 requirements

Clinical Evaluation (Annex III)

• Write a Clinical Evaluation Plan (CEP) per MDCG 2020-1 — this did not exist under MDD
• Conduct a systematic literature search with documented methodology — not just a summary of supporting papers
• Evaluate clinical data for your specific software against your intended use — performance claims must be substantiated
• Produce a full CER per MDCG 2020-1 structure with benefit-risk conclusion
• Write a Post-Market Clinical Follow-up (PMCF) plan — required under MDR, did not exist under MDD
• Write a PSUR template — the first PSUR is due 12 months after certification for Class IIa

Quality Management System

• Update QMS to cover MDR Article 10 post-market obligations — including the specific data to be collected, analysis frequency, and reporting thresholds
• Implement complaint handling and vigilance reporting procedures aligned with MDR Article 87 and MDCG 2023-3
• Add PSUR preparation process to QMS
• Update EUDAMED registration process — from 28 May 2026 this is mandatory (see separate guide)
• Review Authorised Representative agreement for MDR compliance

Notified Body Engagement

• Confirm your current NB is MDR-designated (check NANDO database)
• If not, identify and engage a designated NB — this takes time
• Apply for NB intake as early as possible — do not wait until the technical file is complete before engaging the NB
• Prepare for an MDR conformity assessment under Annex IX (QMS + technical documentation review) or Annex XI

Significant changes — the hidden transition risk

Under MDCG 2020-3, if you make a "significant change" to a MDD-certified device before your MDR certificate is in place, you lose the right to use the MDD transition provisions. The device must be MDR-certified immediately — not by the 2027/2028 deadline.

For SaMD, significant changes that trigger this requirement include: changes to the intended use or indications, new clinical claims, major algorithm changes affecting clinical output, substantial changes to the software architecture, and security-related changes that affect device functionality. This creates a difficult dilemma for software companies: you cannot stop developing your product, but certain changes trigger premature MDR requirements.

The solution is rigorous change control during the transition period. Every change must be evaluated against MDCG 2020-3's criteria before implementation. This is not optional — it is a QMS obligation that your internal audit process should be checking.