SaMDSoftware as a Medical Device

Software as a Medical Device (SaMD) is the IMDRF-coined term for software intended to be used for one or more medical purposes, performing those purposes without being part of a hardware medical device. The defining test is functional independence: an algorithm that scores diabetic retinopathy from a fundus image is SaMD; the firmware that runs the camera is not. The distinction matters because IMDRF, FDA, EMA, MHRA, PMDA, NMPA, Health Canada and SaMD-aware Notified Bodies all use this same definition when scoping their requirements.

Three other categories sit alongside SaMD and are routinely confused with it. Software in a Medical Device (SiMD) is firmware embedded in or controlling a hardware device — it is regulated as part of the device, not as SaMD. General-purpose software is software with no medical intended use; it is not a device at all. Software used in the manufacture or maintenance of a device is a quality-system tool under 21 CFR 820.70(i) — validated but not premarket-submitted.

IMDRF document N12 defines the risk-categorisation framework FDA's CDRH and most ex-US regulators use to scope SaMD evidence. Two axes: significance of information provided (Inform clinical management → Drive clinical management → Treat or diagnose) and state of the healthcare situation (Non-serious → Serious → Critical). The intersection lands the SaMD in Category I, II, III or IV.

FDA does not formally classify SaMD by IMDRF category — it classifies by Class I / II / III under the FD&C Act — but it uses the IMDRF framework to scope clinical-evaluation depth, software documentation level (Basic vs Enhanced), and post-market monitoring requirements. Build the IMDRF categorisation early and carry it through the design history file; reviewers expect to see it.

In the US, SaMD is regulated as a device under the FD&C Act. Most SaMD reaches market via the 510(k) Premarket Notification route as Class II, demonstrating substantial equivalence to a legally marketed predicate. Novel SaMD without a predicate uses the De Novo classification request; the highest-risk SaMD (autonomous diagnosis of life-threatening conditions) requires PMA.

The 21st Century Cures Act (2016) excluded five categories of software from the device definition — including most clinical decision-support (CDS) software that allows the clinician to independently review the basis for recommendations. The CDS exemption is narrower than it appears; SaMD that reaches a conclusion the clinician cannot independently evaluate (e.g. a deep-learning image classifier) is still a device.

Submission content follows the September 2023 final guidance on premarket submissions for device software functions. Every SaMD submission must include a software-documentation level rationale (Basic or Enhanced), the full lifecycle documentation per IEC 62304, software architecture and design documents, unit / integration / system test reports, a software bill of materials (SBOM), and cybersecurity evidence per the September 2023 cybersecurity final guidance — security risk management, architecture views, SBOM in SPDX or CycloneDX, and testing.

Under EU MDR (2017/745) Annex VIII Rule 11, software intended to provide information used to take decisions with diagnosis or therapeutic purposes is Class IIa minimum. If the decisions could cause death or irreversible deterioration of state of health, it is Class III; serious deterioration or surgical intervention pushes it to Class IIb. Only software intended to monitor physiological processes drops to Class IIa (or Class IIb for vital physiological parameters). Software intended for other purposes (e.g. logging, scheduling without clinical impact) is Class I.

Rule 11 has effectively re-classified almost every SaMD upward at the EU MDR transition. A SaMD that was Class I under MDD is now most often Class IIa or IIb, requiring a Notified Body and full technical documentation under MDR Annexes II and III. MDCG 2019-11 is the controlling guidance and should be consulted before scoping any EU SaMD submission.

IEC 62304 is the lifecycle standard. It defines software safety classes (A: no injury or damage to health is possible; B: non-serious injury is possible; C: death or serious injury is possible) and scales documentation accordingly. Class A allows abbreviated architecture and unit testing; Class C requires full architecture, detailed design, and unit testing of every software unit. SaMD in IMDRF Category III or IV typically maps to 62304 safety class C.

ISO 14971:2019 governs risk management. The SaMD-specific hazard taxonomy includes algorithmic failure (false positives, false negatives), cybersecurity exploitation, data-input pathway failures (corrupted image, wrong patient), use-related hazards (clinician over-trust, automation bias), and emergent hazards from model drift in deployed AI/ML SaMD. The risk management file must be alive — updated at every change, reviewed at every release.

IEC 62366-1 covers usability engineering. For SaMD with lay users (consumer health apps, at-home triage), FDA's expectations on summative human-factors validation are explicit: a representative user population, simulated-use environment, defined critical tasks, and a use-error rate that supports the residual-risk acceptability argument.

Adaptive AI/ML SaMD raises a regulatory paradox: the device that learns continuously is, by classical change-control logic, a new device every time it updates. FDA's Predetermined Change Control Plan (PCCP) final guidance (December 2024) resolves this for marketed devices. The PCCP, submitted with the 510(k), De Novo or PMA, defines in advance the planned modifications, the modification protocol, and the impact assessment. Modifications inside the PCCP envelope do not require a new submission.

A defensible PCCP has three parts: (1) Description of Modifications — what could change (training data, model weights, performance metrics, intended use), (2) Modification Protocol — verification, validation, performance metric thresholds, real-world performance monitoring plan, and (3) Impact Assessment — benefits, risks, and how risks are controlled. Models that retrain on real-world data must include a drift-detection and rollback mechanism.

• Treating a CDS exemption claim as obvious. The exemption is narrow and the burden is on the manufacturer to demonstrate the clinician can independently evaluate the basis.
• Skipping IMDRF risk categorisation and arguing 62304 safety class purely from the FDA Class. Reviewers want both arguments documented.
• Documentation level set to Basic when the device is IMDRF Category III. The 2023 software guidance is explicit: Enhanced is the default for SaMD that drives or treats serious or critical situations.
• SBOM absent or in a non-machine-readable format. SPDX or CycloneDX is mandatory under the 2023 cybersecurity guidance.
• PCCP scope drafted too narrowly, forcing a new submission for routine retraining — or too broadly, drawing AI requests for additional information at review.
• Post-market real-world performance monitoring plan absent. For adaptive AI/ML SaMD, FDA expects a defined plan with thresholds and escalation paths.