What is SaMD and why does it matter for today’s medical device companies? As regulators increasingly distinguish software as a medical device (SaMD) from traditional hardware devices, developers face new opportunities—and new challenges. While many of the same regulations and quality standards apply, the pathway for creating SaMD requires a very different mindset than hardware development.
For companies entering this space, understanding what is SaMD is the first step toward building safe, compliant, and market-ready products. In this article, we’ll define what qualifies as SaMD (and what does not), share real-world examples in diabetes care, and lay the foundation for our next article, where we’ll explore the unique demands of SaMD development and strategies for navigating them successfully.
What Is SaMD?
To fully answer the question of what is SaMD, the FDA relies on the definition provided by the International Medical Device Regulators Forum (IMDRF):
Software as a medical device is any software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
To truly understand what is SaMD, it helps to break this definition into parts.
The first piece defines SaMD as software intended to be used for medical purposes. More specifically, the FDA goes on to say that this type of medical tech is used to diagnose, treat, cure, mitigate, or prevent a disease or medical condition. This is an important distinction, as many software programs used to support those with medical ailments do not touch on any of these areas and therefore are not considered medical tech or SaMD.
The second part of this definition dictates that software as a medical device must perform its intended purpose without being a part of a hardware medical device. Instead of being integrated into a device that performs medical functions, SaMD typically exists on nonmedical platforms. These can be computers, smartphones, tablets, or other general-use devices.
Most commonly, SaMD falls into the category of mobile medical devices (MMD). This type of software is meant to be used on a smartphone or connected tablet and performs the function of treating, diagnosing, curing, mitigating, or preventing a medical condition. Just as with the broader term of SaMD, what is considered MMD and what is not considered MMD is dependent on its intended function and associated risk to the person using it.
SaMD is not SiMD
When answering the question what is SaMD, one of the most important distinctions is how it differs from SiMD
Software as a medical device must exist as separate from any physical medical device. But that doesn’t mean it can’t heavily interact with these physical devices. It just must do so in a way that doesn’t interfere with the intended function of the physical device.
When software is necessary for the function of a hardware medical device, it is known as software in a medical device (SiMD). This type of software is also known as embedded software, microcode, and firmware, all of which fall into a different category from SaMD.
The important distinction between these two types of software is that SiMD drives or powers the hardware of a physical medical device. Without this software, the device could not function properly. Another form of SiMD are device accessories. Software that functions as a remote control or display for hardware is not considered SaMD. While the device could likely function to a degree without these types of accessories, their use would be limited and therefore, the software is considered part of the hardware.
Some examples of SiMD in the diabetes care world include:
- Software that powers insulin pumps, continuous glucose monitors (CGM), smart pens, and glucose meters
- Software that connects two devices, such as a CGM and pump, to allow them to interact and automatically adjusts treatment based on these interactions
- Mobile applications that connect to a single pump, CGM, or smartpen and allow the user to control the device through the app
- Mobile applications that allow for the calibration of CGMs
SaMD, on the other hand, may connect to one or multiple medical devices and intake data from them. But this software does not interact in a way that changes what that device does or how it functions. And, importantly, the device will continue to function the same with or without the connected software.
IMDRF lists several clarifying points that further restrict what qualities as SaMD:
- SaMD is software that’s capable of running on general-purpose platforms
- SaMD is software that’s not necessary for a hardware device to achieve its intended medical purpose
- SaMD may be used as a module or in combination with software and physical medical devices
- SaMD may be interfaced with both other SaMD and with physical medical devices
Examples from the Diabetes World
One of the clearest ways to explain what is SaMD is by looking at real-world diabetes care examples currently on the market. These include:
- Applications that provide treatment advice based on data received from pumps and CGMs
- Software that computes insulin dosing based on carbohydrate and blood glucose reading inputs (but does not cause the insulin pump to dose this amount automatically)
- Applications that integrate data from multiple hardware devices and help doctors make treatment decisions
- Software that combines information from biometric meters, such as heart rate and step counters, with CGM data to predict blood glucose changes
- Applications that produce information on the carbohydrate load of standardized meals and calculate insulin dosing based on given ratios
To be considered SaMD, software must meet the qualifications that exclude it from being SiMD. It must qualify as a medical device. If the software does not treat, cure, diagnose, prevent, or mitigate a medical condition or disease, then it is not SaMD.
For example, an application that predicts carb loads of certain meals but does not offer insulin dosing information, would not be considered SaMD. Similarly, an app that uploads CGM data but provides no treatment insight based on that data and does not control the CGM itself, would not be considered SaMD. These types of software are not considered medical devices at all and are therefore not regulated by the same agencies.
SaMD Development & Regulation
As we’ve seen, defining what is SaMD is only the beginning—understanding its development and regulation is equally critical.
To dig into the development and regulation of SaMD, check out Part II of this article.
