Software as a medical device (SaMD) is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The definition comes from the International Medical Device Regulators Forum (IMDRF), whose SaMD Working Group, chaired by FDA, agreed it in IMDRF/SaMD WG/N10FINAL:2013. FDA reproduces it on its SaMD page.
The definition is shared internationally, but it is not a legal category. Whether a piece of software is regulated, and how strictly, is decided by the MDR in the EU and by the FD&C Act in the US. This article explains what the term means, how it relates to the EU and US terms, which software is and is not SaMD, and which documents frame the lifecycle once software qualifies.
The IMDRF definition and three types of software
FDA's SaMD page quotes the IMDRF definition: software "intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device". Two parts of that sentence do the work. The software must have a medical purpose, and it must achieve that purpose on its own, not as part of a hardware device.
FDA uses the IMDRF work to separate three types of software related to medical devices:
| Type | What it is | Example |
|---|---|---|
| Software as a medical device (SaMD) | Software with a medical purpose that is not part of a hardware medical device | Computer-aided detection software that performs image post-processing to help detect breast cancer |
| Software in a medical device | Software that is part of a hardware medical device, sometimes called embedded software or firmware | Software that drives the motors and the pumping of medication in an infusion pump |
| Software used in the manufacture or maintenance of a medical device | Software that supports production or servicing, without a medical purpose of its own | Software that monitors x-ray tube performance to anticipate the need for replacement |
Source: FDA: Software as a Medical Device and FDA: What are examples of SaMD?
The platform does not decide the category. SaMD can run on a phone, a desktop, a cloud server or even inside a hardware device, as long as the hardware is not needed for the software to achieve its medical purpose. Nor does the technology: AI and non-AI software are assessed in the same way.
SaMD, MDSW and device software function
Regulators on each side of the Atlantic use their own terms, and they overlap without being identical.
| Term | Used by | Meaning |
|---|---|---|
| SaMD | IMDRF; FDA digital health materials | Stand-alone software with a medical purpose |
| Medical device software (MDSW) | MDCG 2019-11 Rev.1 (EU) | Software intended for a medical purpose under the MDR or IVDR, whether it is independent or drives or influences a hardware device |
| Device software function | FDA policy on device software functions | A software function that meets the device definition in section 201(h) of the FD&C Act |
The MDR itself does not use the term SaMD. It lists software among the products that can be a medical device in Article 2(1), and MDCG guidance uses MDSW, which is wider than SaMD because it also covers software that drives or influences a device. FDA assesses functions rather than whole products, so one app can contain a device software function and several functions that are not devices.
In practice, SaMD is the international vocabulary, MDSW is the EU qualification term and device software function is the US unit of assessment. A technical file or submission should use the term of the jurisdiction it is written for.
What is and is not SaMD
FDA's examples page gives the clearest boundary. The following are SaMD:
software that allows a smartphone to view images from an MRI device for diagnostic purposes;
computer-aided detection software that post-processes images to help detect breast cancer;
treatment planning software that supplies information used in a linear accelerator;
software with a medical purpose running on a general-purpose platform, such as software that uses the accelerometer of a consumer device to diagnose a condition;
software connected to a hardware device but not needed by that device to achieve its intended medical purpose.
The following are not SaMD:
embedded software, firmware or micro-code that drives or controls a hardware device, such as closed-loop control in a pacemaker;
software required by a hardware device to perform its intended use, even if it is sold separately;
software that relies on device data but has no medical purpose, such as software that encrypts data for transmission;
software for clinical communication and workflow, such as patient registration, scheduling and video calling;
software that monitors device performance for servicing, or analyses laboratory quality control data.
Source: FDA: What are examples of SaMD?
"Not SaMD" does not mean "not regulated". Embedded software is regulated as part of the hardware device it belongs to. And software outside the SaMD definition can still fall under other legislation, such as data protection or the AI Act.
Intended purpose decides qualification
The same code can be a medical device or not, depending on what the manufacturer claims it does. Qualification is therefore the first step, before any discussion of class or route.
In the EU, MDCG 2019-11 Rev.1 sets out a decision process for MDSW. The core question is whether the software performs an action on data, beyond storage, archival, communication or simple search, for the benefit of individual patients and for one of the medical purposes in Article 2(1) MDR. If it qualifies, Annex VIII applies. Software that drives or influences the use of a device takes the class of that device, and independent software is classified in its own right (Annex VIII, Section 3.3). Most stand-alone software is then classified under Rule 11, which we cover in our guide to medical device classifications for software and AI.
In the US, the starting point is the device definition in section 201(h) of the FD&C Act. Section 520(o), added by section 3060(a) of the 21st Century Cures Act of 13 December 2016, excludes certain software functions from that definition. One of those exclusions covers clinical decision support software that meets all four criteria in section 520(o)(1)(E). FDA explains how it interprets those criteria in its Clinical Decision Support Software guidance, revised in January 2026. Like all FDA guidance, it sets out the agency's current thinking and is not binding law.
The two systems can reach different answers for the same software, so qualification has to be done separately for each market.
IMDRF risk frameworks
IMDRF has published two documents that help manufacturers describe software risk:
N12 (2014), Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations, combines the significance of the information the software provides (to treat or diagnose, drive clinical management or inform clinical management) with the state of the healthcare situation (critical, serious or non-serious) to give four categories, I to IV.
N81 FINAL:2025, Characterization Considerations for Medical Device Software and Software-Specific Risk, published in January 2025, encourages accurate descriptions of medical device software, including intended use statements, and offers a general approach to characterising software-specific risk. It complements N12 rather than replacing it.
Neither document is legislation. They are useful for writing a clear intended purpose and a consistent risk narrative, but the EU class still follows the MDR and the US class still follows FDA's classification system.
Lifecycle documents for SaMD
Once software qualifies, the same set of controls applies throughout its life. The main reference documents are:
| Area | Reference |
|---|---|
| Software lifecycle | IEC 62304, Medical device software – Software life cycle processes |
| Risk management | ISO 14971, Medical devices – Application of risk management to medical devices |
| Health software product safety | IEC 82304-1, Health software – Part 1: General requirements for product safety |
| Security in the product lifecycle | IEC 81001-5-1, Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle |
| Clinical evaluation (EU) | MDCG 2020-1, guidance on clinical evaluation and performance evaluation of medical device software |
| Clinical evaluation (US) | FDA guidance Software as a Medical Device (SaMD): Clinical Evaluation, based on IMDRF's clinical evaluation document |
In the EU, Annex I, Section 17 of the MDR adds software-specific safety and performance requirements, including development according to the state of the art, information security, verification and validation. How these documents fit into a technical file is covered in our article on SaMD technical documentation.
AI-enabled SaMD
AI does not change whether software is SaMD; the intended purpose does. It can add a second layer of regulation. Under the AI Act, an AI system that is a medical device, or a safety component of one, and that needs third-party conformity assessment under the MDR or IVDR is high-risk under Article 6(1) and Annex I. Following Regulation (EU) 2026/1744, the high-risk requirements apply to these systems from 2 August 2028. MDCG 2025-6 answers common questions on how the MDR, IVDR and AI Act interact, and our article on EU AI Act requirements for medical devices covers the detail.
A hypothetical example
Hypothetical example: two apps use the same photos of skin lesions.
The first app lets patients store the photos for their own records. It stores and displays images without acting on them for a medical purpose, so on that claim it is unlikely to qualify as MDSW under MDCG 2019-11 Rev.1. If the claims drift towards tracking changes or flagging lesions, the qualification has to be done again.
The second app analyses the photos and indicates the likelihood of melanoma to a dermatologist. It acts on data for a diagnostic purpose for individual patients, so in the EU it qualifies as MDSW and is classified under Rule 11, where the class depends on the impact of the decisions it informs. In the US, the manufacturer assesses it against section 201(h) and checks whether it meets all four Non-Device CDS criteria in section 520(o)(1)(E), using FDA's CDS guidance. Because the app analyses medical images, the first criterion is the obvious point to examine.
The code may share a camera module and a database, but the regulatory answer is driven by the claims.
Conclusion
SaMD is an internationally agreed term for stand-alone software with a medical purpose. It helps regulators and manufacturers talk about the same thing, but the legal answer always comes from the MDR in the EU and the FD&C Act in the US. Start with the intended purpose, qualify the software separately for each market, and only then decide the class, the route and the lifecycle evidence.
If you need help qualifying your software or planning the route to market, our software as a medical device consulting team can support you, or contact MedQAIR.
Frequently asked questions
What is the definition of software as a medical device?
IMDRF defines SaMD as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device (IMDRF/SaMD WG/N10FINAL:2013). FDA uses the same definition.
What is the difference between SaMD and software in a medical device?
SaMD achieves its medical purpose on its own. Software in a medical device is part of a hardware device, such as firmware that controls an infusion pump, and is regulated as part of that device.
Is SaMD the same as MDSW?
No. SaMD is the IMDRF term. MDSW is the term used in MDCG 2019-11 Rev.1 and is wider, because it also includes software that drives or influences a hardware device.
Is all health software a medical device?
No. Software qualifies only when its intended purpose meets the medical device definition, in Article 2(1) MDR or section 201(h) of the FD&C Act. Scheduling, registration and communication software are examples FDA gives of software that is not SaMD.
Does FDA regulate clinical decision support software?
It depends on the function. CDS software that meets all four criteria in section 520(o)(1)(E) is excluded from the device definition. FDA's CDS guidance, revised in January 2026, explains how it interprets those criteria.
Does the AI Act apply to SaMD?
It can. AI-enabled SaMD that needs third-party conformity assessment under the MDR or IVDR is high-risk under the AI Act, with the high-risk requirements applying from 2 August 2028.
