The rapid evolution of medical technology has brought with it a host of innovative devices designed to enhance patient care, improve diagnostics, and streamline treatment processes.
As software advancements continue, the line between traditional hardware-centric medical devices and software-driven solutions becomes increasingly blurred. Enter the domains of Software in a Medical Device (SiMD), referring to software that is integral to the functioning of a physical medical device, and Software as a Medical Device (SaMD), which operates independently to perform medical functions. These two, while closely linked, serve as distinctive categories in the medical technology landscape.
Software as a Medical Device (SaMD)
Software as a medical device is defined by the International Medical Device Regulators Forum (IMDRF) as:
“software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Although this definition offers guidance on what falls under the term SaMD, it’s possible there could still be confusion regarding what constitutes a SaMD product, as applications can integrate with hardware devices without being part of them.
Examples Include:
- An app that calculates appropriate insulin dosage based on a person’s blood glucose levels.
- Software that draws data from other digital devices to determine risk factors associated with epileptic seizures
- Software that uses artificial intelligence to look at MRI images to identify anomalies missed by other diagnostic tools (like an electrocardiogram)
Software in a Medical Device (SiMD)
According to the US Food and Drug Administration (FDA), SiMD refers to software that is incorporated into a medical device to control its performance or provide specific functions. SiMD is also known as embedded software, firmware, or microcode. Unlike SaMD, SiMD can’t function independently, and is instead 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 Include:
- Software embedded in a pacemaker, or defibrillator that monitors heart rhythm, calculates responses, and delivers electrical impulses
- Software that powers infusion pumps, glucose meters, and smart pens
- A mobile application that is the primary interface for reading continuous waveform data from an implanted or wearable EKG loop monitor
MDR in Focus: How it applies to SaMD and SiMD
SaMD
SaMD is classified under the MDR using a risk-based approach, aligning with its potential impact on patient health and safety. Risk classification is determined based on the level of risk posed to patients, similar to traditional medical devices. SaMD must undergo a conformity assessment in accordance with its risk classification. Higher-risk SaMD oftent require Notified Body (NB) involvement for certification, whereas lower-risk software (e.g., Class I) may only require self-certification.
SaMD classification follows MDR Annex VIII, Rule 11:
- Class I: Low-risk software, such as apps for general health tracking.
- Class IIa: Medium-risk software that supports decision-making for non-critical conditions.
- Class IIb: Higher-risk software, such as diagnostic tools that influence significant treatment decisions.
- Class III: High-risk software used in critical or life-threatening situations, such as applications for surgical planning or cancer treatment.
SiMD
SiMD classification differs from SaMD and is typically evaluated within the regulatory framework of the overall medical device it accompanies. As a result, its risk classification is influenced by the combined risk of both the software and the device’s hardware. Consequently, SiMD must undergo a conformity assessment of the entire device. This means that even if the software alone is low risk, it must still meet the same regulatory scrutiny as the physical device, which may require NB involvement depending on the device classification.
Despite their differences, Both SaMD and SiMD require rigorous clinical evaluation, risk management, and post-market monitoring, but the MDR treats them distinctly based on how they are used in medical practice.
Unpacking the Divide: SaMD vs. SiMD
Overall, there are a few differences in the safety and efficacy standards that apply to SaMD and SiMD. Compliance around IEC 62304 (which outlines requirements for the safe design and maintenance of medical device software throughout its lifecycle), IEC 62366 (which focuses on usability engineering to ensure medical devices are safe and effective for users), and ISO 14971 (which provides a framework for identifying, evaluating, and mitigating risks associated with medical devices) are the same.
For example, 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.
Navigating the Nuances: Final Takeaways on SaMD vs. SiMD
The rise of SaMD and SiMD highlights a significant shift in healthcare toward more personalised, accessible, and data-driven care. It reflects the remarkable progress in integrating technology with health while underscoring the critical responsibility to ensure these innovations prioritise patient safety.
Ultimately, as we continue to explore the evolving landscape of SaMD and SiMD, understanding their complexities and distinctions is more important than ever. As the boundaries between software and medical devices become increasingly intertwined, our focus must remain steadfast on developing safe, effective, and forward-thinking solutions that enhance patient outcomes.
