I work on CE marking submissions and Technical Files for Class IIa/IIb devices; software keeps being the part of the dossier that makes notified bodies sit up, ask for evidence they ought to have seen already, and then ask for more. To be fair, some of the scrutiny is deserved: software moves fast, distributes widely, and can change device performance overnight. But granted, the regulatory framework and the standards that sit around it were never perfectly synchronised with modern SaMD practices. That mismatch is the regulatory gap I keep seeing in audits.
The gap in one line
Rule 11 (Annex VIII, MDR 2017/745) sets where software sits in classification; Annex II and Annex XIV set what you need in the Technical File and for clinical evaluation. In practice this means a trio of uncomfortable truths:
- classification is interpretation-heavy (notified bodies disagree on borderline uses),
- the standards (IEC 62304, ISO 14971, ISO 13485, ISO 62366-1) are necessary but not sufficient for SaMD, and
- clinical/real-world evidence expectations for software are still catching up.
I often quote IEC 62304 for lifecycle evidence and ISO 14971 for risk management during audits. That buys trust, but it doesn't stop the NB from requesting algorithm transparency, dataset provenance, or ongoing performance metrics in a way the typical Technical File doesn't present.
What notified bodies actually ask for
From three notified body cycles and multiple re-submissions, the questions repeat:
- Clear intended use and user population. SaMD that assists clinical decision-making is treated more like a high-risk device in the NB's head.
- Traceability from clinical claims to dataset evidence and test results. Where's the proof your model reliably does what you say?
- Versioning and change control for software updates, including rollback strategy.
- Post-market performance monitoring and PMCF/PMPF plans tailored to software behaviour.
- Cybersecurity threat modelling and evidence of mitigation.
- Reproducible test cases and acceptance criteria for performance metrics.
These are not speculative asks. They're almost ritualised now. Notified bodies want to see the chain from requirement → code → test → clinical evidence, which is why connected workflow and traceability matter.
Why standards don't close the loop
Standards give you frameworks: IEC 62304 for software lifecycle, ISO 14971 for risk, ISO 62366-1 for usability engineering. But they don't tell you how to present a machine-learning classifier's training and validation lifecycle, or how often you must re-evaluate performance post-deployment.
IMDRF SaMD definitions and MDCG guidance (the MDCG document on qualification and classification of software is essential reading) help with definitions and classification. Still, there is no single harmonised “SaMD kit” that covers:
- dataset representativeness and bias,
- statistical performance measures a NB will accept for clinical claim justification,
- continuous learning/update pathways consistent with CE marking.
So the Technical File ends up being a bespoke explanation for each product, with significant back-and-forth.
Practical items I build into files for SaMD
When I prepare a Technical File for SaMD, I try to be practical and pre-emptive. My checklist looks like:
- Intended use and claim hierarchy: explicit, concrete, and example-based.
- Classification rationale (Rule 11), with clear justification for why the risk profile matches IIa/IIb/III.
- Software lifecycle evidence: architecture, requirements traceability, unit/integration/system test results per IEC 62304.
- Algorithm description: deterministic vs learning; training/validation/test dataset provenance; data governance notes.
- Performance metrics: acceptance criteria, statistical methods, confusion matrices or ROC descriptions as applicable (no invented stats).
- Change control and update policy: severity-driven change categorisation, verification for each update, and a plan for emergency patches.
- PMCF/PMPF: specific post-market performance indicators, data sources, and frequency of review.
- Cybersecurity: threat model, mitigations, patch management.
- Usability: user needs mapping and formative/summative testing per ISO 62366-1.
These elements help with reviewability — an auditor can follow the logic rather than chase a dozen separate documents.
How QMS and tooling help (or hinder)
An eQMS that supports traceability across requirements, tests, risk items, and CAPAs is worth its weight in audit hours. Automated CAPAs and AI-assisted suggestions are useful for surfacing recurring issues, but the regulated output must remain reviewable and controlled assistance is essential. In practice, a native workflow integration that ties change control to software versioning, risk impact, and post-market data reduces friction at audits and speeds up notified body queries.
Beware of tools that promise magic. The notified body will want to see the rationale, not just a dashboard. Use automation to reduce manual work, not to obfuscate decisions.
The organisational fix (short)
- Engage a notified body early for borderline Rule 11 cases.
- Treat dataset curation, validation, and post-market performance as first-class QMS artefacts.
- Build a clear software update policy: many rejections come from vague patch/update language.
- Use traceable, connected workflows so audit trails are demonstrable in minutes, not days.
Closing thought
SaMD is where clinical evidence, software engineering, and QMS overlap. To close the regulatory gap you need engineers who understand risk and regulators who understand models — and both need tools that keep the story connected and reviewable.
How are you documenting model updates and post-market performance in your Technical File so the next notified body review is straightforward?
Top comments (0)