MDR classification and assessment
The Medical Device Regulation (EU) 2017/745 applies according to a device’s intended medical purpose and classification. Article 52 and Annexes IX–XI set the assessment procedures; the MDR should not be described using a generic A/B+D module table. Ordinary Class I devices can use manufacturer declaration, while sterile, measuring and reusable surgical Class I devices require notified-body involvement for the specified aspects. Higher classes require the applicable notified-body procedure. Article 10(9) requires a quality management system; ISO 13485 certification is not a universal standalone statutory obligation. Article 15 defines the person responsible for regulatory compliance (PRRC), with special arrangements for micro and small enterprises.
Software, cybersecurity and transition
Annex VIII Rule 11 generally places decision-support software in Class IIa, increasing to IIb where decisions may cause serious deterioration or surgery and III where they may cause death or irreversible deterioration. Physiological monitoring is generally IIa, rising to IIb for vital parameters whose variations could create immediate danger; other software is Class I under this rule. Apply all relevant classification rules and the actual intended purpose. Annex I, section 17 addresses software lifecycle, information security and protection against unauthorised access. Standards and MDCG guidance help implementation but do not replace the MDR requirements. Legacy-device transition under Article 120 is conditional and category-specific; 2027/2028 dates are not a blanket exemption.
Products subject to MDR or IVDR are excluded from CRA under Article 2(2). Assess medical-device cybersecurity under the relevant medical-device framework; do not claim that the same device automatically needs both MDR and CRA assessment.
Practical checklist
- Identify the product, intended use, market and applicable legal scope.
- Record the exact legal provisions, dates and applicable standard editions, including restrictions.
- Select the permitted assessment route and document the evidence needed.
- Link risk assessment, tests, product versions and declarations in the technical documentation.
- Assign responsibility for changes, support and responses to authorities.
This checklist supports planning; the applicable legal requirements determine the final assessment.