Key Differences in SaMD vs. SiMD Development
The medical device industry is overflowing with acronyms, and new ones are added every day. SaMD is a recent arrival, and its usage spawned the need for another: SiMD. The FDA defines SaMD as Software as a Medical Device. SaMD was created to define a new classification of software that the FDA regulates beyond traditional medical device software. Given the new classification, the old “software” needed an acronym to avoid confusion—thus, SiMD (Software in a Medical Device).
There are slight differences in the regulations based on the targeted market—FDA’s Software Precertification Program or the EU’s Medical Device Regulation (MDR)—but both regulatory groups recognize the SaMD/SiMD distinctions.
This article compares the two classifications and shares Gener8’s insight into successfully developing medical devices in either regulatory environment.
Classification Determination
On the surface, the difference between SaMD and SiMD lies in the relative position of the software and the device (hardware).
SiMD would previously have been described as dedicated control software. SiMD is an integral part of the device and historically treated as a subcomponent of the overall system. The software may be embedded in the device or housed in a separate console—the key point is that the system cannot function without it.
SaMD, on the other hand, is separate from the hardware or operates without a dedicated hardware component. A defining characteristic of SaMD is that its inputs can come from a variety of sources, and the software can be platform-agnostic.
While this explains the "as" vs "in" distinction, it’s important to emphasize the "MD"—medical device—part. In both cases, the software is considered a medical device.
According to the International Medical Device Regulators Forum, a medical device is defined as:
“Medical device” means any instrument, apparatus, implement, machine, appliance, implant, reagent for in vitro use, software, material, or other similar or related article, intended by the manufacturer to be used, alone or in combination, for human beings, for one or more of the specific medical purpose(s) of:
Regulatory Requirements
As medical devices, both SaMD and SiMD are subject to regulatory oversight based on their intended markets. Using an internationally recognized development process, such as IEC 62304, is recommended regardless of the software type. Certain aspects of the standard, however, take on more importance depending on whether the software is SaMD or SiMD.
Risk Management:
Both types of software must carefully assess and manage risks. SiMD risk assessments must include inherited software safety risks from the overall system, often requiring mitigations for system-level risks.
SaMD, though separate from hardware, must account for the variability in input sources, platform independence, and cloud-based environments.
Development:
SiMD typically requires tight coordination with hardware teams and detailed interface development.
SaMD, while hardware-agnostic, must address environmental variables, performance uncertainty, and evolving operating system constraints—especially in cloud-based systems.
Verification & Validation (V&V):
Both require rigorous V&V regardless of safety classification. However, SaMD often involves external data sources, making input validation more complex. It’s crucial to anticipate and adapt to changes in those sources over time.
Cybersecurity:
SaMD, being more open and flexible, often faces broader cybersecurity risks. It must consider platform-level threats, authentication methods, and data integrity. SiMD, integrated within a device, may leverage controlled OS environments and system-level mitigations, but still requires strong cybersecurity measures.
Development Processes
At a high level, the development model is the same for both SaMD and SiMD. It requires a robust, risk-based approach built on solid planning and documentation. Industry standards like IEC 62304, ISO 14971, and IEC 81001-5-1 form the backbone of this process, which includes:
Gener8 follows these standards with a tailored, flexible approach for every medical device software project. Our process is adaptable to both SiMD and SaMD product types.
Documentation Requirements
Medical device software demands comprehensive documentation to demonstrate regulatory compliance. While there is significant overlap, key distinctions exist:
Examples of SaMD and SiMD
SaMD examples include cloud-based tools and mobile health applications that operate independently from dedicated hardware. They may collect input from smartwatches, phones, or instruments like PCR readers, DNA sequencers, and EMR systems.
SiMD is less visible as “software” and more commonly the control system or UI of a medical device. It handles critical functions such as data processing, device control, and result generation—often embedded in diagnostic systems, imaging equipment, or POC devices.
Gener8 Can Be Your Expert
Gener8 has an extensive track record of successful SaMD and SiMD projects. Our SaMD experience includes cloud-based tools that process data from PCR devices, cardiac telemetry sources, and large-scale data warehouses.
On the SiMD side, we’ve developed over 100 FDA-cleared projects ranging from handheld analyzers to high-throughput lab instruments. Our technical expertise spans PCR/qPCR, spectroscopy, imaging, microfluidics, and advanced sensor technologies.
Whether it’s an early assessment, a proof-of-concept, or full-scale development, Gener8 partners with you to accelerate regulatory success and shorten time-to-market.
We offer services ranging from feasibility consultations to complete product development. Contact Gener8 to learn how we can support your next medical device software initiative.
gener8 This breakdown couldn’t be more relevant. The SaMD vs. SiMD split isn’t just technical, it changes how teams think about validation, documentation, and how they work together. We’ve seen how tweaking the approach based on software type can make all the difference in staying compliant without slowing things down.
Director of Business Development at Gener8
3moGreat article to understand Software AS a medical device vs software IN a medical device. Reach out to me if you'd have a need for development of either one.