MDR Submission for SaMD
Get your Software as a Medical Device through EU MDR initial submission with confidence—supported by concise context from the US QMSR (ISO 13485–aligned). This practical guide shows what to prepare, how to structure technical documentation (Annex II/III), and what Notified Bodies expect, so you can move efficiently toward CE marking.
Quick Checklist — What You’ll Do First
- Confirm device qualification and classify SaMD per Rule 11 (Annex VIII).
- Implement or align your ISO 13485 QMS to MDR Article 10(9) scope.
- Build your Annex II/III technical documentation with a clear, searchable index.
- Map GSPRs (Annex I) to evidence with a GSPR Matrix.
- Engage a suitable Notified Body and prepare for QMS + Technical Doc assessment.
Executive Summary
- Classification drives the route: Most clinical SaMD fall in Class IIa+ under Rule 11; higher risk increases scrutiny.
- QMS is foundational: MDR Article 10(9) expects a comprehensive QMS; ISO 13485 alignment also supports US QMSR.
- Technical File is the core: Annex II/III requires device description, design/production, GSPR mapping, risk, V&V, clinical evaluation, and PMS plans.
- NB assessment is rigorous: Expect QMS audit and deep review of software validation, cybersecurity, usability, and clinical evidence.
- Timelines vary: Plan conservatively; documentation quality and early NB engagement reduce delays.
Regulatory Framework Overview
In the EU, SaMD falls under MDR 2017/745. Classification uses Annex VIII—Rule 11 for software—placing most clinical decision-support software at least in Class IIa. Manufacturers must implement a QMS covering design control, risk management, clinical evaluation, PMS, and vigilance as outlined in Article 10(9). The submission centers on technical documentation per Annex II/III and third-party assessment by a Notified Body for Class IIa and above. In the US, FDA requires a premarket submission (e.g., 510(k)/De Novo/PMA) and a compliant QMS; the QMSR aligns closely with ISO 13485, so MDR-ready systems typically map well to US expectations.
Step-by-Step Approach to MDR Submission for SaMD
- Qualify & Classify (Annex VIII, Rule 11)Concept Stage
- Confirm medical purpose and intended use; document the classification rationale.
- Identify class (I/IIa/IIb/III) based on impact on diagnosis/therapy and potential harm if failure occurs.
- Output: Qualification memo, Rule 11 rationale, initial regulatory plan.
- Establish/Align ISO 13485 QMS (Article 10(9))3–6+ months
- Implement procedures for design control (IEC 62304), risk management (ISO 14971), usability (IEC 62366), cybersecurity, PMS, vigilance, UDI.
- Run internal audit and management review before NB engagement.
- Output: Quality Manual, SOPs, training, audit records, design history framework.
- Build Technical Documentation (Annex II/III)2–4+ months
- Device description & intended purpose; labeling/IFU; design & manufacturing (incl. software build/distribution).
- GSPR matrix; Risk Management File; software V&V (unit/integration/system), usability & cybersecurity evidence.
- Clinical Evaluation (Article 61, Annex XIV) and PMS/PMCF plans.
- Output: Searchable Technical File with index and cross-references.
- Regulatory Roles & Readiness1–2 months
- Designate PRRC; appoint EU Authorized Representative if outside EU; obtain SRN via registration as applicable.
- Select Notified Body with software scope; finalize application package and timelines.
- Output: NB application, AR/PRRC evidence, readiness checklist.
- NB Conformity Assessment (Annex IX route typical)6–12+ months
- QMS audit (stage 1/2) and technical documentation review; respond to questions and NCs promptly.
- Focus areas: software validation completeness, cybersecurity controls, clinical evidence sufficiency, traceability.
- Output: CE certificate upon successful review.
- Declaration & CE Marking (Annex IV)
- Issue the EU Declaration of Conformity; apply CE marking per class rules; finalize registration steps.
- Output: Signed DoC; CE mark placement in UI/docs; release package archived.
Evidence Pack (Annex II/III Technical Documentation)
| Evidence Type | Description / Purpose | Preparation Notes |
|---|---|---|
| Device Description & Intended Purpose | Plain-language description, intended use, target users/patients, classification rationale (Rule 11). | Include versioning/model info; ensure claims match labeling, risk, and clinical evaluation. |
| Labeling & IFU | All user-facing information and required content per Annex I Section 23. | Cover installation, operating environment, warnings, residual risks; prepare translations as needed. |
| Design & Manufacturing (incl. Software Build) | Architecture, algorithms, development lifecycle; build, packaging, distribution; supplier sites. | Trace third-party components; maintain a software bill of materials; align to IEC 62304. |
| GSPR Matrix (Annex I) | Requirement-to-evidence mapping for all applicable safety/performance clauses. | Reference exact documents/sections; justify “not applicable” items clearly. |
| Risk Management File | Plan, analysis, controls, residual risk, benefit-risk conclusion (Article 10(2), Annex I). | Cover software-specific hazards, cybersecurity, usability; verify each control via test evidence. |
| Software V&V | Verification and validation results across unit/integration/system; usability & cybersecurity evidence. | Provide traceability matrix from requirements to tests; summarize outcomes and anomalies. |
| Clinical Evaluation (Article 61, Annex XIV) | Plan and report showing clinical safety/performance via literature, studies, or justified rationale. | Align claims with intended purpose; define PMCF if evidence gaps remain. |
| PMS / PMCF Plans (Annex III / Annex XIV Part B) | Lifecycle monitoring and evidence generation approach post-market. | Define data sources, trending, responsibilities, and reporting cadence; align with risk profile. |
| Declaration of Conformity (Annex IV) | Legal attestation of conformity, issued at certification. | Prepare a draft; ensure consistency with scope, standards applied, and certificate details. |
Real-World Style Examples (Non-Identifying)
- Decision Support SaMD (Class IIa): Team tightened intended purpose wording to avoid over-claiming therapy. GSPR matrix exposed a gap in cybersecurity hardening; added pen-test and SBOM. NB questions dropped by half in the next round.
- Imaging Analysis SaMD (Class IIb): Early traceability mapping revealed untested edge cases. A focused validation sprint closed the gap; clinical evaluation linked performance metrics to intended use, reducing NB follow-ups.
FAQ (Concise)
Do we need a Notified Body for SaMD?
Yes for Class IIa/IIb/III under Rule 11; Class I may be self-certified if criteria are truly met.
Is ISO 13485 mandatory?
MDR requires a comprehensive QMS (Article 10(9)); ISO 13485 is the de-facto route and aligns with US QMSR.
How detailed should software validation be?
Provide requirement-level traceability, objective test evidence, usability and cybersecurity coverage, and clear outcomes.
Can this dossier support US FDA?
Yes. Reformat for FDA expectations; core evidence (risk, V&V, clinical) is reusable.
Bottom Line
Successful MDR submission for SaMD hinges on accurate classification, a robust ISO 13485 QMS, and a clean, cross-referenced Annex II/III Technical File. When evidence is consistent and traceable—and NB questions are anticipated—approvals move faster. Build once, validate thoroughly, and leverage the same backbone for the US under QMSR.