Software is central to nearly all of today’s medical devices – essential to the diagnosis, treatment and management of medical conditions. But from the FDA’s vantage, there are two types of medical device software and the difference between them comes down to a pair of small but vital words: “in” and “as.”

Software as a Medical Device (SaMD). Software in a Medical Device (SiMD).

Though many people use these terms interchangeably, they have distinct differences. For medtech innovators, determining under which category your product falls is essential to compliance.

Software as a Medical Device (SaMD)

SaMD is defined by the International Medical Device Regulators Forum (IMDRF) , of which the FDA is a member, as software intended to be used for one or more medical purposes that perform these purposes (e.g. diagnosing, monitoring or treating patients) without being part of a hardware medical device. To qualify as SaMD, the software runs on generic compute platforms.

SaMD use cases abound, and include:

Diagnostic software that analyzes medical images like X-rays, CT scans, ultrasounds or MRIs for the detection of abnormalities.

Telemedicine software that facilitates virtual doctor-patient consultations and supports remote diagnosis and treatment planning. (Note that software that facilitates virtual doctor-patient consultations or teleconferences but does not encompass diagnosis and treatment planning support is not SaMD. Same for software that simply stores patient data.)

Remote patient monitoring platforms that enable healthcare providers to monitor patients' vital signs, such as glucose levels for diabetic patients.

Pregnancy-related apps intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm.

Medication management apps that remind patients to take their medications, track adherence, and provide information about potential drug interactions. (While this is considered SaMD in the U.S. it is not in the EU.)

Software in a Medical Device (SiMD)

SiMD refers to software that is an integral component of a hardware medical device. Unlike SaMD, SiMD can’t function independently, and rather is reliant on the associated medical hardware. Since the software contributes to the device's intended purpose, any malfunction or failure could impact the safety and performance of the entire medical device.

Examples of SiMD include:

Infusion pumps with dose-calculation software that deliver controlled doses of medication, with embedded software calculating the appropriate dosage based on patient parameters.

Pacemakers and implantable cardioverter defibrillators that monitor and regulate heart rhythms through embedded software

Automated external defibrillators that include embedded software to analyze heart rhythms and deliver electric shocks to restore normal heartbeats in cases of cardiac arrest.

Digital radiography systems with image processing software that allows for better visualization of anatomical structures.

Anesthesia delivery systems that administer and monitor anesthesia levels during surgery, with embedded software ensuring precise control and patient safety.

Continuous glucose monitoring systems that measure and monitor glucose levels in diabetic patients, utilizing embedded software to provide real-time data and alerts.

Understanding the Differences

Understanding the differences between SaMD and SiMD is critical because these differences impact every aspect, from regulatory compliance to risk management to patient trust.

Regulatory Compliance

Overall, there are few differences in the safety and efficacy standards that apply to SaMD and SiMD. For instance, compliance around IEC 62304, IEC 62366 and ISO14971 is the same. For instance, both SaMD and SiMD must be classified according to IEC 62304 as far as class A, B and C software where A is low-risk software and C is high-risk software. However, SiMD also has to meet additional requirements that concern hardware, and hardware and software integration. Compliance with these regulations ensures the safety and performance of the integrated software as part of the overall medical device.

Risk Management

While of course medtech innovators need to understand the risks related to SaMD in order to assess the safety and effectiveness of the software in delivering its intended medical purpose, the bar is higher when it comes to SiMD. Failure to ensure seamless software integration may increase risks associated with the overall performance and safety of the medical device.

Development and Validation

SaMD development, validation, and verification focuses on software-specific considerations. You should follow best practices to ensure the reliability and accuracy of the medical information or functionality provided. Additionally, you need to take into consideration the platform on which the SaMD will run (e.g. smartwatch, mobile, computer). The platform’s resolution, memory, CPU, Bluetooth and other elements may greatly impact software performance. As far as SiMD, the bar is set even higher – requiring coordinated software development in sync with the development of the hardware components. Also necessary is a proven, comprehensive approach to validation and testing that takes into account the interaction between software and hardware.

Patient Safety and Trust

Clear regulations and understanding of SaMD ensure that patients can trust the safety and reliability of medical information or services provided by standalone software. While the same can be said of SiMD,  there is greater concern over the proper integration and functioning of software within a medical device. A thorough understanding of regulations ensures that software integration is seamless and does not compromise patient well-being.

SBOM Requirements for SaMD and SiMD

Though SaMD and SiMD differ in a number of ways, in the U.S. they both are subject to requirements relating to a software bill of materials (SBOM). Federally mandated since the Biden administration’s May 2021 Executive Order 14028, Improving the Nation’s Cybersecurity , an SBOM is a “nested inventory” of all the building blocks that make up a software product. It includes a list of all the open source and third-party components present in a medtech product’s codebase.

While pulling together an SBOM can be an onerous process, the effort is worthwhile (and required!) as the SBOM provides product transparency and helps organizations better understand, manage, and secure their applications. According to the National Telecommunications and Information Agency (NTIA), these are SBOM minimum required elements:

Data Fields

Document baseline information about each component that should be tracked: Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.

Automation Support

Support automation, including via automatic generation and machine-readability to allow for scaling across the software ecosystem. Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.

Practices and Processes

Define the operations of SBOM requests, generation and use including: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

You can learn more about SBOM here .

The Takeaway

Establishing a clear and nuanced understanding of the distinctions between SaMD and SiMD is necessary to ensure compliance and patient safety, and facilitate smoother market access. If you have a vision for SaMD, SiMD or a traditional medical device, ICS can help you bring it to life. And we can help you establish a robust and compliant SBOM that will support the safety and cybersecurity of your product. ICS leverages deep domain expertise, specialized tools, ISO 13485-compliant processes, and a suite of coordinated services to streamline medtech development, testing and certification. Explore our services in more detail or connect with one of our experts .