If you're developing medical device software, one of the first questions you need to answer is deceptively simple: is your software a medical device on its own, or does it exist to power a hardware device? The answer determines how your software is categorized, and that categorization has real implications for how you develop, document, and regulate your product.

The two categories at the center of this question are SaMD (Software as a Medical Device) and SiMD (Software in a Medical Device). Understanding the distinction between them is foundational to everything that follows in your regulatory journey.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

What Is SaMD?

SaMD stands for Software as a Medical Device. The International Medical Device Regulators Forum (IMDRF) defines it as "software intended for one or more medical purposes that perform those purposes without being part of a hardware medical device." The FDA uses nearly identical language, defining SaMD as software that meets the definition of a device under section 201(h) of the FD&C Act and is intended to be used for one or more medical purposes without being part of a hardware device.

The key phrase in both definitions is "without being part of a hardware medical device." For software to qualify as SaMD, it must be capable of standing alone, meaning it performs its medical purpose independently, without relying on or being embedded in a physical device.

Some practical examples of SaMD include software that allows a mobile device to display MRI or X-ray images for diagnostic purposes, an application that processes images to assist in detecting breast cancer, or software that uses a smartphone's accelerometer to diagnose a medical condition.

What Is SiMD?

SiMD, or Software in a Medical Device, is the counterpart to SaMD. This is software that exists to run, control, or power a hardware medical device. It does not perform its medical function independently. Its purpose is to enable the hardware to do what it does.

Common examples include the software that controls the inflation and deflation of a blood pressure cuff, software that manages insulin delivery in an insulin pump, or software that handles closed-loop control in a pacemaker. You may also hear SiMD referred to as embedded software, firmware, or microcode. All of these terms describe software that lives inside and serves a hardware device.

If the hardware couldn't function as intended without the software, that software is almost certainly SiMD.

The core distinction

The line between SaMD and SiMD comes down to one question: does the software perform its medical purpose independently of hardware, or does it exist to drive hardware?

The IMDRF offers some useful clarifying points on this. First, SaMD is capable of running on general-purpose, non-medical computing platforms. Second, software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device. Third, the phrase "without being part of" means the software is not necessary for a hardware medical device to achieve its intended medical purpose. If a hardware device cannot achieve its medical purpose without the software, the software is SiMD. If the software can perform its medical purpose on a general-purpose platform (a smartphone, a tablet, or a web browser) it is more likely to be SaMD.

It is also worth noting that a single product can contain both SiMD and SaMD. A wearable cardiac monitor, for example, might include firmware (SiMD) that runs the hardware sensors, while also connecting to a separate software application (SaMD) that analyzes the data and provides a diagnosis. The two types of software are distinct, even when they work together.

Why the distinction matters

Getting this classification right is not just a matter of regulatory terminology. The classification can shape how you approach your entire development process.

Both SaMD and SiMD are regulated as medical devices, and both must comply with applicable regulations such as FDA's Quality Management System Regulation (QMSR), EU MDR or EU IVDR, and the software lifecycle standard IEC 62304. Neither is exempt from quality management requirements. However, there are nuances in how these requirements apply, particularly around risk classification and the documentation required for regulatory submissions.

For SaMD, the IMDRF has developed a specific framework for risk categorization based on the significance of the information the software provides and the seriousness of the condition it is intended to address. This framework is particularly useful for companies navigating EU MDR requirements, where Rule 11 of Annex VIII establishes the classification criteria for medical device software. Our breakdown of MDCG 2019-11 is a good place to start if you're working through EU classification.

For SiMD, the risk and classification analysis tends to be more closely tied to the hardware device it supports. The software's safety class under IEC 62304 will reflect the severity of injury that a failure could cause, but that analysis happens in the context of the overall device.

How to determine which category your software falls into

Start with your intended use. Ask what your software is meant to do, and whether it performs that function on its own or in service of a hardware device.

If your software can run on a general-purpose platform and directly serves a medical purpose, like diagnosing, treating, monitoring, or preventing a condition, without being part of a hardware device, it is likely SaMD. If it is embedded in a hardware device and exists to make that hardware function, it is SiMD.

When in doubt, review FDA's Policy for Device Software Functions and Mobile Medical Applications, which provides clear guidance on what the agency considers a device software function and what it does not regulate as such. For the EU, MDCG 2019-11 and MDCG 2021-24 provide a good framework for qualification and classification of medical device software.

And if you're still uncertain, the most reliable path is to contact FDA directly or consult with a qualified regulatory professional.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

How Greenlight Guru Supports SaMD and SiMD Teams

Whether you're building SaMD or SiMD, navigating the regulatory landscape while keeping your development on track is a serious challenge. Greenlight Guru is purpose-built for medical device teams, which means we understand the unique dynamics of software development in this industry.

Greenlight Guru connects your design controls, risk management, and software release management in one system, so you can maintain IEC 62304 traceability without the overhead of managing it across disconnected tools. It also bridges the gap between your development work and your quality management system, giving QA and R&D teams a shared source of truth from the first line of code through postmarket surveillance.

To see how we support software development in medtech, get your free demo of Greenlight Guru today.