SaMD vs SiMD: Software as a Medical Device under FDA and EU MDR

TL;DR

Software as a Medical Device (SaMD) is software that performs a medical purpose without being part of a hardware medical device. Software in a Medical Device (SiMD) is software that drives or is embedded in a hardware device. The international definition comes from the International Medical Device Regulators Forum (IMDRF). It defines SaMD as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." ¹

The distinction decides how software is classified and submitted. In the EU, SaMD is classified in its own right, mostly under MDR Rule 11. Software that drives a device takes the class of that device. In the US, FDA authorizes device software functions through 510(k), De Novo or PMA. FDA's list of AI-enabled devices shows the pattern. Of the 1,614 devices on the list, 96.2% reached the market through 510(k). The number authorized per year grew from 18 in 2016 to 335 in 2025. ²

2026 brought several changes. FDA revised its clinical decision support and general wellness guidance in January and its cybersecurity guidance in February. The EU moved the AI Act's high-risk obligations for AI-enabled medical devices to 2 August 2028. This guide explains the definitions, how to tell whether software is a device at all, how FDA and the EU classify it, what goes into a submission, and how other major markets treat it.

SaMD, SiMD and MDSW: what each term means

SaMD is a defined term. SiMD is a descriptive label without a binding legal definition. The EU uses a third term, MDSW, that covers both.

IMDRF is explicit about the boundary: "Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device." It also says "mobile apps that meet the definition above are considered SaMD." FDA's 2022 policy on device software functions states that they "may include 'Software as a Medical Device (SaMD)' and 'Software in a Medical Device (SiMD).'" ³

In the EU, MDCG 2019-11 Rev.1 replaces "standalone software" with MDSW and notes that the old term "is no longer used in the context of the Medical Device Regulations." The MDR's implementing rule 3.3 sets the class consequence: "Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right." ^{4 5}

Australia's TGA describes SiMD in the most practical terms. Such software is "usually supplied preinstalled with the hardware device," and "SiMD is regulated as part of the device it is installed in." ⁶

First question: is the software a medical device at all?

Much health software is not a device. The intended purpose, and in the US five statutory exclusions, decide it.

In the US, section 520(o) of the FD&C Act, added by the 21st Century Cures Act, excludes five kinds of software function from the device definition:

• administrative support;
• maintaining or encouraging a healthy lifestyle, unrelated to disease;
• electronic patient records, unless the function interprets or analyzes them;
• transferring, storing, converting or displaying data, unless it interprets or analyzes that data;
• certain clinical decision support (CDS). ⁷

The CDS exclusion applies only when the software does not analyze medical images or signals. It must display or analyze medical information, support a health care professional's recommendation, and let that professional independently review the basis for it.

FDA revised two key policies in January 2026:

• Clinical decision support. The guidance was reissued on 6 January 2026 and corrected on 29 January 2026. Software that gives a specific diagnostic or treatment directive fails the third criterion. Where only one option is clinically appropriate and the software otherwise meets the criteria, FDA intends to exercise enforcement discretion. Software that gives recommendations to patients or caregivers, rather than to health care professionals, remains a device. ⁸
• General wellness. The revised policy of 6 January 2026 says FDA "may consider certain products that use non-invasive sensing" to estimate physiologic parameters, such as blood pressure, oxygen saturation or glucose, to be general wellness products. That applies only under conditions. The product must be non-invasive, must not substitute for an FDA-authorized device and must not give outputs that prompt specific clinical action. ⁹

In the EU, MDCG 2019-11 Rev.1 sets out a decision path. Software for "general purposes, even when used in a healthcare setting," or for "life-style and well-being purposes" is not a device under MDR recital 19. Software that creates or modifies medical information for an individual patient usually is. The June 2025 revision adds emphasis on a clearly written intended purpose and on modular software, where only some modules qualify.

How SaMD is risk-classified

IMDRF's framework is the common language. Each regulator then converts it into its own legal classes.

The IMDRF framework in N12 ranks SaMD by two factors. The first is the state of the healthcare situation: critical, serious or non-serious. The second is the significance of the information to the healthcare decision: treat or diagnose, drive clinical management, or inform clinical management. ¹⁰

IMDRF warns that this "is not a regulatory classification." In January 2025 it published N81, which supplements N12 with software-specific risk considerations for all medical device software, including software that is part of hardware. ¹¹

EU MDR Rule 11 turns the same logic into law:

"Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: — death or an irreversible deterioration of a person's state of health, in which case it is in class III; or — a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I."

MDCG 2019-11 Rev.1 includes an illustrative table that maps IMDRF categories to MDR classes. Excluding Class I, critical situations map to Class III (treat or diagnose), IIb (drive) and IIa (inform). Serious situations map to IIb, IIa and IIa, and non-serious ones to IIa throughout. Because of Rule 11, most decision-support SaMD in the EU needs a notified body. The European Commission's December 2025 proposal to revise the MDR and IVDR would rewrite Rule 11 around the IMDRF matrix. That proposal is still pending, so the current Rule 11 applies. ¹² For the full EU class system, see our EU MDR classification guide.

In the US, software is classified like any other device: by product code and classification regulation. Most SaMD sits in Class II. Radiological image processing software (product code QIH, 21 CFR 892.2050) and radiological computer-assisted triage and notification software (QAS, 21 CFR 892.2080) are typical. Our FDA classification guide explains how to find the right code.

What the US market data show

AI-enabled software is the fastest-growing slice of FDA's device authorizations, and nearly all of it goes through 510(k).

FDA's list of AI-enabled medical devices held 1,614 entries in its September 2026 update, with final decisions through 29 June 2026. 1,553 (96.2%) were 510(k) clearances, 40 were De Novo grants and 21 were PMA approvals. Radiology was the lead review panel for 1,230 of them (76.2%), followed by cardiovascular (154) and neurology (73). FDA notes the list "is not a comprehensive resource of AI-enabled medical devices."

A second measure comes from Pure Global's analysis of the openFDA 510(k) export. Clearances under product codes whose FDA device name includes "software" rose from 7 in 2016 to 187 in 2025, from 0.2% to 5.8% of all 510(k) clearances. In 2025, 94 of those 187 were automated radiological image processing software (QIH). ¹³ This undercounts SaMD, because many software devices sit under product codes without "software" in the name. It is still a consistent trend line.

What FDA expects in a SaMD submission

The pathway is the same as for hardware. The documentation is software-specific, and four guidances shape it.

1. Software documentation level. FDA's June 2023 guidance replaced the old "level of concern" with two documentation levels. Enhanced Documentation applies "where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury." The assessment is made before risk controls are applied. Basic Documentation applies otherwise. ¹⁴
2. Cybersecurity. Section 524B of the FD&C Act, effective 29 March 2023, applies to "cyber devices." These are devices that include software, can connect to the internet and could be vulnerable to cybersecurity threats. Submissions must include a vulnerability monitoring plan, update and patch processes, and a software bill of materials. ¹⁵ FDA's cybersecurity guidance was last revised on 3 February 2026 to align with the QMSR. ¹⁶
3. Predetermined change control plans (PCCPs). Section 515C lets FDA authorize planned future modifications in advance, so that changes made within the plan need no new submission. FDA's PCCP guidance for AI-enabled device software functions was finalized on 4 December 2024 and revised on 18 August 2025. It covers 510(k), De Novo and PMA. ¹⁷ A general PCCP guidance for all devices is still a draft from August 2024. ¹⁸
4. AI lifecycle. FDA's draft guidance of 7 January 2025 on AI-enabled device software functions sets out lifecycle and marketing-submission recommendations. These cover data management, model description, performance validation, bias, transparency and post-market monitoring. It was still a draft in October 2026. ¹⁹ FDA also requested comments by 19 October 2026 on a generative AI discussion paper. ²⁰

Under the QMSR, design and development (ISO 13485 clause 7.3) applies to every Class II and III device and to Class I devices automated with software. Software validation therefore sits inside the quality system as well as the submission. See our 21 CFR 820 to ISO 13485 crosswalk.

EU requirements beyond Rule 11

• Clinical evidence. MDCG 2020-1 asks for three components for every MDSW: valid clinical association (scientific validity), technical or analytical performance, and clinical performance. These follow IMDRF N41. ²¹
• General safety and performance requirement 17. Annex I requires software to be developed "in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation."
• The AI Act. Regulation (EU) 2024/1689 treats AI systems in medical devices that need notified body conformity assessment as high-risk. The Digital Omnibus, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026, moved those obligations to 2 August 2028. ²² MDCG 2025-6 explains how the MDR and the AI Act interact. It states that the AI Act "does not impact the risk classification of medical devices." Its reference to an August 2027 date predates the Omnibus. ²³

How other major markets treat SaMD

Sources: ²⁴, ²⁵ and ²⁶. For AI-specific market access across more than 30 countries, see our AI as a medical device research report.

The standards behind a SaMD file

• IEC 62304:2006+A1:2015 sets the software life-cycle processes and software safety classes A, B and C. Edition 2 is still a committee draft, and IEC forecasts publication in October 2028. Plan on the 2015 consolidated version. ²⁷
• IEC 82304-1:2016 covers health software products that run on general computing platforms without dedicated hardware, which is typical for SaMD. ²⁸
• IEC 81001-5-1:2021 sets security activities across the health software life cycle. ²⁹
• ISO 14971 risk management and IEC 62366-1 usability engineering apply to SaMD as to any device. Our ISO 14971 guide covers the risk file.

SaMD versus SiMD: what changes in your file

Common mistakes

• Writing the intended purpose last. Classification, clinical evidence and wellness or CDS status all follow from it. Draft it first, and keep marketing claims inside it.
• Assuming "decision support" means "not a device." In the US the four CDS criteria must all be met. In the EU, Rule 11 places most decision-support software in Class IIa or higher.
• Treating a mobile app as a lower tier. An app that meets the SaMD definition is SaMD.
• Citing the old "level of concern." FDA replaced it with Basic and Enhanced Documentation in June 2023.
• Planning for the 2027 AI Act date. The high-risk obligations for AI-enabled medical devices now apply from 2 August 2028.
• Shipping algorithm updates without a plan. Without a PCCP, a significant change usually needs a new submission.

How Pure Global helps

We determine whether software is a device and write the intended purpose. We classify the software under FDA, EU MDR Rule 11 and other systems, and prepare 510(k) and De Novo files with Basic or Enhanced documentation, cybersecurity and PCCP content. Our team also supports EU notified body submissions and registrations in more than 30 markets. See our SaMD regulation page or contact our team.

How we built the numbers

• AI-enabled devices: our count of FDA's AI-enabled medical devices list (CSV), as updated in September 2026. Decisions run to 29 June 2026, and 2026 is a partial year. Pathway shares come from the submission number prefix (K, DEN or P).
• Software-named product codes: product codes in FDA's product code file dated 12 October 2026 whose device name contains "software", matched to the openFDA 510(k) export dated 12 October 2026. Pure Global keeps both in its data lake. Counts are by calendar year of the decision.