As digital technology continues to reshape healthcare, the line between hardware and software in medical devices has blurred. From embedded firmware to AI-powered diagnostics, software now plays a role in nearly every type of smart or connected medical device.
If you’re designing or developing a software-enabled medical device, understanding the distinction between these two categories can help you determine which standards apply and how to plan your product development and submission strategy accordingly.
Defining SaMD and SiMD
Software as a Medical Device (SaMD) refers to standalone software that performs a medical function without needing to be part of a hardware medical device.
Why? The software itself meets the FDA’s definition of a medical device under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act).
By contrast, Software in a Medical Device (SiMD) refers to software that is embedded within or necessary for the operation of a physical medical device.
How do I tell the difference?
To determine whether your product is SaMD or SiMD, regulators typically ask two fundamental questions drawn from FDA and IMDRF guidance:
1. Does the software meet the definition of a medical device?
In other words, is it intended to diagnose, treat, prevent, or mitigate disease, or to affect the structure or function of the body? If yes, it may fall under device regulation.
2. Can the software function independently of a physical device?
If the answer is yes, it’s likely SaMD. If it’s required for the operation of a specific piece of hardware, it’s SiMD.
This framework is widely used by regulatory professionals, even though it’s not codified in FDA law. It reflects how agencies evaluate intended use, functionality, and system dependencies.
Why the difference matters
The distinction between SaMD and SiMD has direct implications for:
- Regulatory submission pathways (510(k), De Novo, PMA, etc.)
- Testing and validation requirements
- Postmarket monitoring and change control
- Cybersecurity and data integrity expectations
SaMD tends to move faster through development cycles, leveraging cloud-based infrastructure and continuous updates. That flexibility also means regulators expect robust processes for risk management, cybersecurity, and real-world performance monitoring.
SiMD, by contrast, is validated as part of the overall device design and typically undergoes full system-level verification to ensure the software and hardware operate safely together.
Here’s where it can get complicated
Imagine you’re developing an intravenous (IV) pump that delivers different medications through interchangeable cartridges. The device’s physical hardware drives the pump mechanism and serves as the main interface for clinicians and patients.
The software controlling the pump’s operation would be classified as SiMD, since it can’t function independently of the hardware and its risk to patients all pertains to the same device function. Potentially, you’d pursue a 510(k) submission on this device and its embedded software.
However, a separate software application that manages the drug library, calculates doses, and tracks patient data could be regulated independently as SaMD if it operates apart from the pump’s hardware and control systems even if later integrated with a pump system. Then, you would pursue another 510(k) submission for this software component.
Applicable standards
Both SaMD and SiMD are subject to rigorous quality and safety expectations — but the applicable standards and validation processes differ slightly. The following includes a list of FDA consensus standards most commonly used in development of either type of product.
- IEC 62304 defines the software lifecycle requirements for both SaMD and SiMD.
- ISO 13485 and 21 CFR Part 820 establish overall quality system and design control expectations.
- ISO 14971 provides an risk management framework for medical devices including those which are standalone or embedded
- IEC 82304-1 applies specifically to standalone health software (SaMD).
- IEC 60601-1 applies to software used in medical electrical equipment (SiMD).
Artificial Intelligence (AI)
AI-driven software features have their own regulatory challenges for manufacturers because machine-learning elements can make changes in the device performance to improve patient outcomes. Managing changes so they do not cause the device to depart from the original approved or cleared submission requires planning and FDA coordination.
For AI-driven software, the FDA offers guidance. The FDA’s 2025 draft guidance, “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations” addresses lifecycle management and submission recommendations. Their guidance, “Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions”, helps to define an approach by which manufacturers can maintain the ability to modify AI functionality on a released product while maintaining the safety and efficacy requirements of a cleared or approved device..
Confused by the regulatory rules around medical device software? We can help.
Gilero helps medical device manufacturers design connected systems that are safe, scalable, and regulatory-ready. Whether you’re embedding intelligence into hardware or creating standalone digital health tools, our team can help you bridge the gap between innovation and compliance.
We provide everything under one roof, from software engineering for medical devices to full-scale commercial manufacturing.
About the Author
Jim Fentress brings to Gilero more than 20 years of disposable medical device experience, with a strong foundation in device design, manufacturing, process development, validation, and experiment design. In his role as Director of Research & Development and Regulatory Policy at Gilero, Jim focuses on novel product development with new technologies, materials, or requirements. Jim also acts as a technical consultant on traditional development products providing guidance for design verification and validation testing, test method development, regulatory submissions, and regulatory body correspondence. Jim holds a degree in Biomedical Engineering from Rensselaer Polytechnic Institute.