Guide
SaMD explained: Software as a Medical Device
The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device (SaMD) as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. A diagnostic app on a phone can be SaMD; the firmware that runs an infusion pump is not — that is software in a medical device.
The basics
What decides how SaMD is regulated
Intended use drives everything
Whether software is a device depends on what it is intended to do — diagnose, treat, mitigate, monitor or inform clinical management — not on the technology it uses.
Risk categorisation
The IMDRF framework weighs the significance of the information (treat or diagnose, drive, or inform clinical management) against the state of the healthcare situation (critical, serious, non-serious). Regulators map this onto their own classes.
Core standards
IEC 62304 covers the software lifecycle, ISO 14971 risk management, IEC 62366-1 usability, and ISO 13485 the quality system. Cybersecurity expectations sit alongside these for connected software.
US pathways
Depending on risk and predicates, SaMD may reach the US market via 510(k), De Novo or PMA. Some clinical decision support software falls outside the device definition under section 520(o) of the FD&C Act.
Getting started
A practical order of work
- 1Write a precise intended use and indications statement — it determines whether the software is a device at all.
- 2Classify the software in each target market and identify the likely pathway.
- 3Set up the software lifecycle, risk file and usability engineering under your QMS.
- 4Plan verification, validation and clinical evidence proportionate to the risk category.
- 5Prepare the submission and a post-market plan for updates, complaints and cybersecurity.
Where Qevatrix fits
One record from intended use to clearance
RegulatoryOS tracks classification, pathway, submissions and clearances per product, and QualityOS holds the design controls, risk file and CAPA record that SaMD reviewers expect to see.
More guides
See all guidesDeviceOS
What is UDI?
Unique Device Identification explained: DI and PI, labelling, and database submissions.
RegulatoryOS
510(k) submission guide
How premarket notification works: predicates, substantial equivalence, and what a submission has to contain.
RegulatoryOS
Medical device classification
FDA classes and EU MDR rules explained, with how classification drives your route to market.
This guide is an orientation, not regulatory advice. Confirm the current FDA guidance, IMDRF documents and the regulations of each target market before acting.