Software is now involved in everything from remote patient monitoring and diagnostic imaging to clinical decision support and AI-assisted disease detection. But not every healthcare app or software platform is a medical device.
When software has an intended medical purpose and performs that purpose independently of a hardware medical device, it may qualify as Software as a Medical Device (SaMD). Once it falls within a jurisdiction’s definition of a medical device, its intended use, risk, clinical evidence, cybersecurity, quality system and lifecycle changes can all influence the regulatory pathway.
For developers and medical device manufacturers, understanding the SaMD regulatory framework early in development can prevent classification problems, evidence gaps and costly redesign later.
Need Regulatory Support for Your SaMD Product?
Navigate global Software as a Medical Device requirements with DDReg Pharma's expert support for SaMD classification, regulatory strategy, technical documentation, submissions, registration, and post-market compliance.
Explore Medical Device Regulatory Services →What is Software as a Medical Device?
The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device.
SaMD can operate on smartphones, tablets, general-purpose computers, cloud infrastructure, or other computing environments.
Examples can include software that:
- analyses physiological signals to support diagnosis
- processes medical images to identify clinically relevant findings
- provides patient-specific information used in treatment decisions
- performs a medical function using data received from another device.
FDA also recognises SaMD as one category of device software functions. Importantly, a software product must still meet the US statutory definition of a medical device before FDA device requirements apply. This means that a wellness app and software used to diagnose a serious medical condition may look similar technically while having very different regulatory consequences.
Some Examples of Software as a Medical Device (SaMD)?
There are many examples of SaMD, but we have given you a few to help you understand it more easily. Check out the table.
| SaMD category | Example |
|---|---|
| Diagnostic software | Software that analyses medical images to identify potential abnormalities |
| Clinical decision support | Software that analyses patient-specific data and provides information to support diagnosis or treatment decisions |
| Patient monitoring | Software that analyses physiological data to monitor a patient’s condition |
| Medical image analysis | Software that processes CT, MRI, X-ray or other medical images to identify clinically relevant findings |
| Treatment support | Software that provides patient-specific information used to support treatment decisions |
| Remote monitoring | Software that receives and analyses data from connected medical devices or wearable sensors for a medical purpose |
| Predictive/AI-enabled software | AI/ML software that analyses clinical data to identify patterns or predict clinically relevant outcomes |
SaMD vs Software in a Medical Device (SiMD)
One of the most common areas of confusion is the difference between Software as a Medical Device and Software in a Medical Device (SiMD).
SaMD | Software in a Medical Device |
Performs its medical purpose independently of hardware | Forms part of, drives or controls a hardware medical device |
May run on smartphones, computers or cloud platforms | Usually integrated into or necessary for the hardware device |
Example: software analysing ECG data to assist diagnosis | Example: software controlling medication delivery in an infusion pump |
Regulated according to the software’s intended medical purpose and applicable jurisdictional framework | Generally regulated as part of the hardware medical device |
FDA explains that software that drives or controls a hardware medical device is not SaMD. Software can also run on medical-device hardware and still qualify as SaMD when it is not part of that hardware device’s intended medical function. The distinction is therefore based primarily on intended purpose and functional relationship with the hardware, not simply where the software is installed.
How is SaMD Classified?
There is no single global SaMD classification that automatically applies in every country. This is an important point because the IMDRF risk categorisation framework and legally binding national or regional device classifications serve different purposes.
IMDRF Risk Categorisation
IMDRF’s SaMD framework considers two key dimensions:
- The significance of the information provided by the software — whether it informs clinical management, drives clinical management, or is used to treat or diagnose.
- The seriousness of the healthcare situation or condition — whether it is non-serious, serious or critical.
These factors lead to IMDRF SaMD risk categories ranging from Category I to Category IV, with Category IV representing the highest potential impact. However, these IMDRF categories should not be confused with FDA Class I, II and III devices.
FDA SaMD Classification
In the US, once a software function meets the device definition, FDA classification follows the broader medical-device regulatory system.
Depending on the intended use, risk and applicable classification regulation, the device may fall into Class I, Class II or Class III, with the corresponding regulatory controls and potentially a 510(k), De Novo or PMA pathway. FDA’s regulatory approach is function-specific rather than based simply on whether software runs on a smartphone, computer, or another platform.
EU MDR/IVDR Software Classification
In the EU, medical device software is qualified and classified under the MDR or IVDR, depending on its intended purpose.
For MDR software, Rule 11 is particularly important. Software providing information used for diagnostic or therapeutic decisions is generally Class IIa but can move to Class IIb or III depending on the potential consequences of those decisions. Software monitoring certain vital physiological parameters can also fall into Class IIb. The Medical Device Coordination Group updated its software qualification and classification guidance, MDCG 2019-11 Rev.1, in June 2025. This is why manufacturers should determine classification separately for every target market rather than assuming one global classification will transfer automatically.
Planning to Launch Your SaMD in the USA?
Navigate FDA requirements for Software as a Medical Device with DDReg Pharma's support for device classification, 510(k), De Novo and PMA pathways, technical documentation, FDA submissions, and post-market compliance.
Explore USA Medical Device Regulatory Services →What Are the Main SaMD Regulatory Requirements?
Exact SaMD regulatory requirements depend on jurisdiction, intended use and device classification. Nevertheless, several areas commonly need to be addressed across the development lifecycle.
The manufacturer should have a clearly defined intended medical purpose because this drives qualification, classification, clinical evidence and regulatory labeling. Risk management should consider not only software failure but also the potential clinical consequences of an incorrect, delayed or misleading output.
Software verification and validation should demonstrate that the product performs consistently according to its specifications and intended use. Clinical evaluation should establish whether the software’s output is clinically meaningful and whether the available evidence supports its intended medical purpose.
IMDRF’s SaMD clinical-evaluation framework remains an important reference for this area. Other considerations can include usability, data integrity, cybersecurity, privacy, interoperability, technical documentation, post-market surveillance and controlled software updates.
Need a Regulatory Strategy for Your SaMD?
Develop a clear regulatory pathway for your software with DDReg Pharma's support for classification, regulatory gap assessment, market strategy, submission planning, and authority interactions.
Explore Regulatory Strategy Services →SaMD Regulatory Framework
There is considerable international alignment around the principles of software safety and risk management plans, but software as a medical device regulation remains jurisdiction-specific.
How Is SaMD Regulated in the United States?
FDA regulates device software functions that fall within the medical-device definition and are subject to applicable regulatory controls.
An important 2026 development was FDA’s updated Clinical Decision Support Software final guidance, issued in January 2026. It clarifies which CDS software functions may fall outside the statutory medical-device definition and which remain device software functions subject to FDA policies.
This is particularly relevant because calling software “clinical decision support” does not by itself determine whether it is regulated.
How Is SaMD Regulated in the European Union?
The EU MDR and IVDR govern medical device software according to intended purpose, qualification, classification, and applicable conformity-assessment requirements.
MDCG 2019-11 Rev.1 provides updated guidance for applying those rules to software under both regulations.
How Is SaMD Regulated in the IMDRF?
IMDRF provides internationally recognised concepts covering SaMD definitions, risk categorisation, quality management, clinical evaluation and medical-device-software risk characterisation.
In January 2025, IMDRF published updated guidance on medical device software and software-specific risk characterisation, reflecting the increasingly diverse software landscape.
These documents support international convergence, but they do not replace legally applicable requirements in individual jurisdictions.
What Is the SaMD Product Development Lifecycle?
Successful SaMD development should connect regulatory strategy with software development from the beginning. The process starts with defining the intended medical purpose. That determines whether the software is likely to qualify as a medical device and helps establish the appropriate classification.
From there, teams can map applicable markets and regulatory pathways before finalising product architecture. Development then needs to integrate quality management, software lifecycle controls, risk management, cybersecurity, and usability rather than addressing them independently at the end.
Verification and validation should demonstrate that the software performs as intended, while clinical evaluation establishes whether the resulting output is sufficiently supported for its claimed medical purpose. Once the product reaches the market, the lifecycle continues. Complaints, cybersecurity vulnerabilities, real-world performance, adverse events and software modifications may all require ongoing assessment.
This lifecycle approach has become particularly important for AI-enabled software, where the product may evolve more frequently than a conventional hardware medical device.
What Changed for SaMD Regulation in 2026?
A particularly important change took effect in the United States on February 2, 2026. FDA’s Quality Management System Regulation (QMSR) replaced the previous Quality System Regulation framework within 21 CFR Part 820 and incorporates ISO 13485:2016 by reference.
The change aligns FDA’s device quality-management requirements more closely with international medical-device QMS principles and applies to manufacturers within its scope, including applicable manufacturers of regulated device software.
For SaMD developers, quality management should therefore be integrated into development rather than treated as documentation prepared only before regulatory submission.
| 2026 development | Authority | Why it matters |
|---|---|---|
| QMSR effective | FDA | Changes US device QMS framework |
| CDS guidance update | FDA | Clarifies scope of certain CDS software |
| Cybersecurity guidance | FDA | Strengthens lifecycle cybersecurity expectations |
| MDCG 2019-11 Rev.1 | EU | Updated software qualification/classification guidance |
| PCCP principles | IMDRF | Supports international convergence around planned software changes |
Common Challenges in SaMD Regulatory Compliance
- Determining Whether the Software Is Actually a Medical Device – Not every healthcare application qualifies as SaMD. Administrative software, certain general wellness functions and some clinical decision-support functions may fall outside the medical-device definition or within specific FDA policies. Classification should therefore begin with intended purpose, not with the technology used to build the software.
- Different Classification Systems Across Markets – A product may be assessed under IMDRF principles, FDA device classifications and EU MDR/IVDR rules at the same time. These frameworks are related, but they are not interchangeable. Using one market’s classification as the automatic answer for another can lead to an incorrect regulatory strategy.
- Cybersecurity – Cybersecurity remains a major regulatory consideration because SaMD may process sensitive health information, connect with healthcare infrastructure or influence clinical decisions. FDA issued updated final guidance on Cybersecurity in Medical Devices in February 2026. The guidance addresses cybersecurity design, labeling and recommended premarket documentation and also discusses requirements under section 524B of the FD&C Act for cyber devices. Cybersecurity therefore needs to be considered throughout the device lifecycle rather than treated only as an IT issue.
- Interoperability – SaMD frequently exchanges information with electronic health records, wearables, diagnostic equipment, cloud platforms or other medical devices. The manufacturer needs to understand what happens when data are incomplete, delayed, incompatible or incorrectly transferred, particularly where those failures could affect clinical decisions.
- Managing Frequent Software and AI Updates – Traditional medical devices may remain relatively stable between major product changes. Software can evolve much faster. For AI-enabled devices, FDA’s final guidance on Predetermined Change Control Plans (PCCPs) allows manufacturers, where applicable, to prospectively describe planned AI-enabled device software modifications and the methodology used to develop, validate and implement them as part of a marketing submission.
This creates a more structured approach to certain anticipated changes, but it does not mean manufacturers can modify regulated software without appropriate controls.
Planning to Market Your SaMD in Europe?
Navigate EU MDR requirements for software medical devices with DDReg Pharma's support for classification, technical documentation, clinical evaluation, conformity assessment, CE Marking, and post-market compliance.
Explore EU Medical Device Regulatory Services →Future Opportunities and Outlook in Software as a Medical Device (SaMD)
The future of Software as a Medical Device (SaMD) is increasingly connected to artificial intelligence, machine learning, remote monitoring, wearable technologies and interoperable health systems.
AI-enabled software can analyse increasingly complex datasets, identify patterns and support earlier or more personalised clinical decisions. Wearables and connected devices can extend monitoring outside traditional clinical environments, while cloud-based platforms can make medical software accessible across broader healthcare networks.
Regulators are also adapting to the fact that some software is designed to change over time. One of the most significant developments in 2026 came from IMDRF, which published its final Essential Principles and Content of Predetermined Change Control Plans document on August 6, 2026.
The framework supports greater international consistency in how planned device modifications may be described and controlled. This does not create one globally binding PCCP pathway. Individual regulators still determine how these principles are implemented within their own legal systems.
The direction, however, is becoming clearer: SaMD regulation is moving further toward total product lifecycle management rather than viewing market authorisation as the end of regulatory oversight.
For developers, that means future competitiveness will depend not only on building innovative software, but on demonstrating that the product can remain safe, clinically reliable, cybersecure and controlled as it evolves.
How DDReg Supports SaMD Regulatory Strategy
DDReg supports regulatory services for medical device and digital-health companies across the regulatory lifecycle, including device classification, regulatory strategy, technical documentation, quality management systems, eCTD regulatory submissions and post-market compliance.
For SaMD medical device developers, early regulatory assessment can help determine whether the software falls within the medical-device framework, establish the appropriate classification and identify the evidence and documentation expected in each target market.
DDReg’s medical device regulatory services also support country-specific market-entry strategies, such as the USA, European Union and many more, as well as risk assessments and lifecycle compliance across global markets.
Conclusion
Software as a Medical Device is changing how healthcare is delivered, but rapid innovation does not remove the need for regulatory discipline. The most important step is establishing exactly what the software is intended to do.
From there, manufacturers can determine whether it qualifies as a medical device, how it should be classified and which regulatory, clinical, quality and cybersecurity requirements apply.
The SaMD regulatory framework is becoming more sophisticated as AI, connected devices and adaptive software become increasingly common. Developments such as FDA’s 2026 QMSR and cybersecurity updates, revised EU software guidance and new IMDRF PCCP principles demonstrate how quickly the regulatory environment is evolving. Successful SaMD development therefore requires more than innovative software. It requires a lifecycle strategy that connects intended purpose, classification, clinical evidence, quality, cybersecurity, regulatory approval and controlled post-market change.
Frequently Asked Questions
Software as a Medical Device (SaMD) is software intended to perform one or more medical purposes without being part of a hardware medical device. It may analyse medical data, support diagnosis, monitor health conditions or provide information used in treatment decisions. Whether software qualifies as SaMD depends primarily on its intended medical purpose and the applicable regulatory framework.
There is no single global SaMD classification system. IMDRF uses a risk categorisation framework based on the seriousness of the healthcare situation and how the software output influences clinical management.
Individual regulators then apply their own classification rules. In the US, regulated medical device software may fall into FDA Class I, II or III, while in the EU, medical device software is classified under the MDR or IVDR, with MDR Rule 11 particularly relevant to many software products.
SaMD regulatory requirements vary according to the intended purpose, device risk and target market. Common considerations include quality management, software verification and validation, risk management, clinical evaluation, usability, cybersecurity, technical documentation, labeling, post-market surveillance and controlled management of software changes.
Higher-risk software generally requires stronger evidence and regulatory oversight.
In the US, FDA regulates software functions that meet the statutory definition of a medical device and are subject to applicable device requirements. Depending on classification, a product may follow a 510(k), De Novo or Premarket Approval pathway.
In the EU, medical device software is regulated under the MDR or IVDR according to its intended purpose and classification. Manufacturers may need appropriate conformity assessment, technical documentation, clinical evaluation, quality-system controls and post-market surveillance before and after market entry.