Regulatory glossary

Software as a Medical Device (SaMD): Definition and Regulation

Software as a Medical Device is software intended for a medical purpose that performs that purpose without being part of a hardware medical device. The definition is IMDRF's and FDA uses it.

The phrase "without being part of" is doing the work. An app that reads an image and flags a likely finding is SaMD. The firmware controlling an infusion pump is not, because it is part of the pump. That second category is usually called software in a medical device (SiMD), or embedded software, and it is regulated as part of the device it lives in.

What makes software a device at all

Intended use, not technology. If the software is intended to diagnose, treat, cure, mitigate or prevent disease, it meets the device definition regardless of how it is built. A wellness app that does none of those things is not a device, and a large language model that does is.

The IMDRF risk categories

SaMD risk is framed on two axes, which together give four categories:

The state of the healthcare situation: critical, serious, or non-serious.

What the information does: treat or diagnose, drive clinical management, or inform clinical management.

Category IV carries the highest risk and the heaviest evidence expectations. Category I the least. The framework is not itself binding in the US, but it underpins how the risk conversation is had, and it maps closely onto the regulatory class you end up in.

The useful discipline is that both axes are about the clinical decision, not about the software. Two products with identical code sit in different categories if one informs and the other diagnoses.

Clinical decision support, and what is carved out

Not all clinical software is regulated. Section 3060 of the 21st Century Cures Act amended the FD&C Act to exclude certain clinical decision support software from the device definition.

The carve-out turns on whether the clinician can independently review the basis for the software's recommendation. Software that displays or analyses medical information to support a recommendation, and that enables the healthcare professional to understand and evaluate the reasoning rather than relying primarily on it, falls outside the definition.

Software that does not allow that independent review, or that is intended to acquire, process or analyse a medical image or a signal from a diagnostic device, remains a device.

This is where most AI products land in an uncomfortable place. A model that cannot explain its basis is, almost by construction, one the clinician has to rely on primarily. The transparency of the output is a regulatory variable, not only a product one.

What FDA expects now

A premarket submission. Most SaMD reaches market via 510(k) with a predicate, or De Novo where none exists, or PMA for the highest risk.

Software lifecycle process. IEC 62304 is the recognised standard, and the level of documentation scales with the software safety class.

Risk management under ISO 14971, applied to the software and to its clinical use, not only to failure modes in the code.

Cybersecurity. Since section 524B was added in 2022, a premarket submission for a cyber device must include a plan to monitor and address vulnerabilities, a process for providing updates, and a software bill of materials. This is a statutory requirement, not guidance, and submissions have been refused for omitting it.

A change control plan, if the model learns. FDA's Predetermined Change Control Plan mechanism lets a sponsor pre-authorise specified modifications to an AI-enabled device, so that retraining within the agreed envelope does not require a new submission. Without one, a meaningful model change is a new submission.

Where SaMD submissions go wrong

• Intended use written for marketing. The intended use statement determines the category, the predicate and the evidence. Broad claims bought cheaply in the brochure are expensive in the submission.
• Assuming a wellness exemption. The line is what the software claims to do, and product copy is evidence of intent.
• Treating the CDS carve-out as a design decision made later. It depends on whether the output can be independently reviewed, which is an architecture question.
• Cybersecurity documentation assembled at the end. A software bill of materials is generated from how you build, not written afterwards.
• No plan for model updates. Shipping an adaptive model without a predetermined change control plan means every meaningful update is a regulatory event.