Guide
Software as a Medical Device (SaMD): A Practical Readiness Guide
Software as a Medical Device (SaMD) — software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device — is regulated as a device by FDA, the EU under MDR/IVDR, the UK MHRA, Health Canada, TGA, and PMDA. The IMDRF SaMD working group's framework (N10 / N12 / N23 / N41) supplies the shared vocabulary regulators use: SaMD categorisation by significance of information + healthcare situation, quality management, clinical evaluation, and risk categorisation. This guide is for product managers, regulatory leads, and software engineering managers shipping SaMD or planning to. It walks through what counts as SaMD (and what is wellness software that does not), the lifecycle expectations under IEC 62304, the AI/ML-specific obligations including FDA's Predetermined Change Control Plan guidance, cybersecurity under FDA's 2023 final guidance and EU MDR Annex I §17, and a 120-day readiness path that materially shortens time to first submission.
Start free trial Free trial, no credit card, onboard in days, not months.
Is your software actually SaMD?
Three tests, in order. First, intended use: does the software claim to diagnose, treat, monitor, predict, or prevent a disease or condition? Marketing claims are part of intended use — a wellness app that advertises arrhythmia detection has just become a device. Second, IMDRF N10 scope: SaMD must not be part of a hardware device (software embedded in an infusion pump is software in a medical device — SiMD — not SaMD). Third, jurisdiction-specific carve-outs: FDA's 21st Century Cures Act §3060 exempts certain Clinical Decision Support software where the clinician can independently review the basis for the recommendation; EU MDR has no such exemption and treats most CDS as a device. A 30-minute classification decision saves 12 months of misallocated engineering effort.
IMDRF categorisation and FDA risk category
IMDRF N12 categorises SaMD by two axes: significance of information to the healthcare decision (inform / drive / treat-or-diagnose) and the state of the healthcare situation (non-serious / serious / critical). The matrix yields Categories I to IV. FDA aligns its premarket review depth to this categorisation; EU MDR uses Rule 11 of Annex VIII (the SaMD rule) to derive Class IIa, IIb, or III. The category drives almost every other decision — clinical evaluation depth, post-market surveillance frequency, change-control rigor, cybersecurity testing extent. Manufacturers who pick a category early and document the rationale find every downstream artefact halves in scoping time.
IEC 62304 lifecycle: software safety class A / B / C
IEC 62304 is the lifecycle standard FDA, EU notified bodies, and Health Canada all expect. It defines three software safety classes — A (no injury possible), B (non-serious injury possible), C (death or serious injury possible) — driven by the hazard analysis under ISO 14971. The class determines which lifecycle processes are mandatory: planning, requirements, architectural design, detailed design (B and C), implementation, integration testing (B and C), system testing, release, and the SOUP (Software of Unknown Provenance) controls. Most SaMD ends up Class B or C; Class A is rare and usually wrong. The 62304:2006 + Amd.1:2015 version is the currently harmonised one; the 2025 revision adds explicit AI/ML lifecycle clauses but is not yet harmonised.
AI/ML SaMD and the Predetermined Change Control Plan
Adaptive AI models present a regulatory problem: under traditional submission rules, every meaningful model change requires a new submission. FDA's December 2024 final guidance on Predetermined Change Control Plans (PCCP) solves this by letting manufacturers pre-specify the types of modifications they intend to make post-clearance, the methodology used to make them, and the impact assessment — bundled into the original submission. Approved PCCPs let manufacturers update models within the pre-specified envelope without resubmission. The Modification Protocol section is where most PCCPs fail review: it must be specific enough to be evaluable but flexible enough to be worth submitting. EU MDR has no PCCP equivalent yet; the EU AI Act adds high-risk AI obligations on top of MDR.
Cybersecurity: FDA 2023 final guidance and EU MDR Annex I §17
FDA's September 2023 final guidance on cybersecurity in medical devices makes cybersecurity a premarket gating issue: a Secure Product Development Framework (SPDF), a Software Bill of Materials (SBOM) at component level, threat modelling, security risk assessment, and a vulnerability management plan are all required submission content. EU MDR Annex I §17.2 + §17.4 require equivalent (slightly different vocabulary) controls. The SBOM format expectations have hardened on CycloneDX or SPDX; PDF lists are no longer accepted. Post-market: a coordinated vulnerability disclosure policy is now expected for FDA and is required for the EU under the Cyber Resilience Act when it phases in for connected products in 2027.
Clinical evaluation and real-world performance monitoring
SaMD clinical evaluation under IMDRF N41 has three components: valid clinical association (the link between the SaMD output and the clinical condition is scientifically valid), analytical validation (the SaMD correctly processes input to produce accurate output), and clinical validation (the SaMD output achieves the intended purpose in the target population). EU MDR additionally requires post-market clinical follow-up (PMCF) plans and a periodic safety update report (PSUR) cadence by class. For AI/ML SaMD, real-world performance monitoring (RWPM) is becoming the standard expectation — monitoring model drift, subpopulation performance, and adverse event signal in production.
A 120-day SaMD readiness path
Days 1 to 20: classify under IMDRF N12 and the relevant jurisdiction rules; lock the intended use statement; complete the SaMD-vs-wellness decision per market. Days 21 to 50: set up the IEC 62304 lifecycle, the ISO 14971 risk file, the cybersecurity SPDF, and the SBOM tooling; document the SOUP inventory. Days 51 to 80: complete the design history file, the cybersecurity threat model and security risk assessment, the analytical validation, and the clinical evaluation plan. Days 81 to 110: run the verification and validation; assemble the submission (eSTAR for FDA, technical documentation for EU); for AI/ML, draft the PCCP. Days 111 to 120: internal regulatory review, pre-submission meeting if used (FDA Q-Sub or EU notified body informal review), submission preparation.
Where this lives in V5 Ultimate
The clauses above aren't theoretical — every one maps to a shipped module and an industry profile. Jump to the parts of the product that turn this guide into evidence on a Monday morning.
Modules that do the work
Quality management
ISO 13485 + IEC 62304 lifecycle for SaMD products.
Document control
Design history file, SBOM, and cybersecurity SPDF under change control.
Audits & CAPA
Post-market surveillance and real-world performance monitoring.
Compliance self-assessment
IMDRF categorisation and Rule 11 classification with rationale.
Industries this hits hardest
Frequently asked
Is my wellness app SaMD?
It depends on the claims. If you claim to diagnose, treat, monitor, predict, or prevent a disease or condition, it is SaMD regardless of the wellness positioning. FDA's General Wellness guidance carves out low-risk wellness claims (general fitness, relaxation, weight management) but any condition-specific claim — arrhythmia detection, depression screening, blood-glucose prediction — pulls the app into device territory.
Do I need IEC 62304 if I have ISO 13485?
Yes. ISO 13485 is the QMS standard for all medical devices; IEC 62304 is the software-specific lifecycle standard. For SaMD, both apply: 13485 governs how you run the organisation, 62304 governs how you build the software. Notified bodies and FDA reviewers expect both to be in place and to cross-reference each other (the design control SOPs under 13485 reference the 62304 lifecycle processes).
Does FDA's PCCP guidance apply outside AI/ML?
Technically yes — the PCCP framework can be applied to any software change protocol — but in practice the guidance is written for and reviewed against AI/ML use cases. For deterministic SaMD, FDA's older 'Deciding When to Submit a 510(k) for a Software Change' guidance is usually the better tool.
What is a Software Bill of Materials (SBOM) and is it really required?
An SBOM is a machine-readable list of every software component in your product — direct dependencies, transitive dependencies, version, supplier, known vulnerabilities. FDA's 2023 cybersecurity guidance requires one in premarket submissions and recommends CycloneDX or SPDX format. EU MDR Annex I §17.2 requires equivalent disclosure. PDFs and spreadsheets no longer meet the expectation.
See it on your shop floor.
Free trial, no credit card, onboard in days, not months.
Related reading
Editorial·Reviewed against the V5 marketing knowledge base. Spot something off? .