I used to think software was the easy bit: fewer moulds, no cleanroom, just code. Five years into MDR audits handling Class IIa/IIb SaMD, I’ll admit I was naïve. Software behaves differently from hardware — it updates daily, depends on third‑party services, and its “performance” is often measured in uptime and false‑positive rates rather than tensile strength. The regulations recognise software (see Article 2), but there’s a gap between the written law, the guidance documents, and what notified bodies actually ask for. Naja — exactly the part that keeps my change control queue busy.
Below are the practical deficits I see, how they bite in audits, and the minimum I now include in every Technical File.
The main mismatch: lifecycle vs. snapshot
Regulation is written in snapshots: a device is assessed at a point in time. Software rarely is. Continuous delivery, cloud dependencies, and AI/ML models mean the product in the market can diverge from the product in the Technical File quickly.
In practice this means:
- Notified bodies require clarity on the “state” that was assessed — build numbers, configuration, and the exact data sets used for validation.
- They will ask for a documented, repeatable update process (change control, regression testing, risk re‑assessment) that shows how new releases remain within the assessed “safety envelope.”
- They expect traceability from requirements to tests to deployed versions; a PDF labelled “version 3.1” without traceability is insufficient.
Standards you should be using: IEC 62304 for software lifecycle, ISO 14971 for risk management, and ISO 13485 for QMS. IMDRF guidance on SaMD is useful as interpretation, but it is not harmonised law — to be fair, that’s where a lot of ambiguity sits.
Clinical/performance evidence is different for SaMD
Clinical evaluation for software isn’t always clinical trials. For many SaMDs, performance evidence comes from:
- analytical validation (does the algorithm do what it claims on controlled data),
- clinical performance (does it help in the intended clinical pathway), and
- real‑world performance (post‑market).
Notified bodies increasingly push for real‑world performance and actively want post‑market measures (PMCF/PMPF) designed into the plan. In practice this means:
- Be explicit about the intended use and the clinical claim (even small wording changes matter).
- Include datasets used for validation (demographics, sources, exclusions) and justify their relevance.
- Have a PMCF/real‑world evidence plan with performance metrics and thresholds that trigger corrective action.
Per Annex I, demonstrate you considered foreseeable misuse and software behaviour in those scenarios.
Cybersecurity and third‑party dependencies
Annex I §17.2 forced us to stop pretending security is optional. For SaMD, “security” is functionality: a denial of service or data leak can be a patient‑safety issue.
What auditors look for:
- Threat modelling and mitigations tied into the risk management file (ISO 14971 + cybersecurity controls).
- Supplier assessments for third‑party libraries, cloud providers, and APIs.
- Patch management and a defined emergency update/recall procedure.
If you rely on a cloud service, show your acceptance criteria for that provider, SLA monitoring, and contingency plans when the provider changes their terms.
The update problem: regulated continuous delivery
Notified bodies differ wildly on how they accept updates. Some want a hard freeze and a new conformity assessment for anything non‑trivial; others accept a robust change‑control workflow.
My checklist for updates that I present to NB reviewers:
- Change classification: what is a minor change vs. significant change (tie to risk and intended use).
- Regression test matrix linked to risk items.
- Release artefacts: build digest, deployed configuration, and a rollback plan.
- Post‑release monitoring plan and exit criteria.
For transparency, I map changes to risk controls and CAPAs in a connected workflow. That makes review and audit much faster — and keeps CAPA cascades automated rather than manual. Automated CAPAs or AI‑assisted CAPA suggestions help triage, but the root cause analysis must remain human‑reviewable and traceable.
Practical content I now include in every SaMD Technical File
A Technical File that survives an MDR inspection for software usually contains:
- Exact build and test baselines (hashes, build numbers, dataset snapshots).
- Software architecture with component boundaries and third‑party dependency list.
- Risk management file with software‑specific hazards and cybersecurity threats.
- Validation reports (unit, integration, system, clinical/performance) with pass/fail criteria.
- Post‑market surveillance plan focused on performance metrics and alert thresholds.
- Change management policy and a history of implemented changes with impact analysis.
If it helps: I use the document register to cross‑link requirements → tests → risk controls → released builds. Traceability is not an optional nicety; it’s audit fuel.
Where tooling matters (short)
You don’t get this right on spreadsheets. Critical capabilities:
- Change impact analysis (which requirements and tests are affected by a change).
- Traceable linking across artifacts (requirements/tests/risk/issue/CAPA).
- PMCF/PSUR workflow support so post‑market signals feed back into development.
- Reviewability: show who approved what and when.
A connected workflow reduces review time and keeps CAPA‑driven risk assessment coherent. To be fair, some eQMS demos still focus on electronic forms rather than live traceability — ask for the Change Impact Mapping tab.
Final thought
SaMD sits between software engineering practice and device regulation. The gap isn’t just legal language — it’s lifecycle thinking. Bridging it needs explicit artefacts, reproducible releases, and a QMS that connects development, risk, and post‑market feedback.
How are you showing a notified body that your continuous delivery model stays safe and within the assessed state — a strict version freeze, or a living, traceable change‑control workflow?
Top comments (0)