The healthcare industry has always relied on new technology to drive it forward and improve the care that patients get. From the invention of things like the magnifying glass and the stethoscope centuries ago to complex machines like CT scanners and MRI invented just a few decades ago, technology is what allows medicine to evolve, adapt, and advance. Today is no exception. Technology is growing at a rapid pace, and doctors, researchers, scientists, and computer programmers are all working together to create new technology that revolutionizes healthcare. This technology allows the professionals who use it to save lives and to help people maintain better overall health.
Medical industry software comes in several forms, and to understand what this amazing software is doing for medicine, we must understand the difference between software types. The two largest categories of medical software that are revolutionizing the industry are software as a medical device (SaMD) and Software in a medical device (SiMD). Here we will discuss the differences between the two types of software and cite examples of each type to help give you a better understanding of both categories.
Definitions:
Software in a Medical Device (SiMD):
Software in a Medical Device (SiMD) refers to software that is an integral part of a hardware medical device, essential for its operation. This software is key to the device’s primary function, playing a direct role in its performance and reliability.
Examples of SiMD
- Firmware that controls the dosage and timing settings in an infusion pump.
- Software within an ultrasound machine that processes and enhances images in real time.
- The operating system within a blood analysis device that manages tests and interprets the data.
Software as a Medical Device (SaMD):
Software as a Medical Device (SaMD) is specifically designed for medical purposes and operates independently of any physical medical device hardware. It can be deployed on various platforms like smartphones, cloud-based systems, or desktop computers.
The defining characteristic of SaMD lies in its application for diagnosing, treating, or managing health conditions, regardless of the technological platform it uses. Regulatory agencies like the FDA (U.S. Food and Drug Administration) and EMA (European Medicines Agency) have established detailed guidelines for the development and validation of SaMD, aiming to ensure its safety and efficacy.
Examples of SaMD
- Diagnostic applications that interpret imaging data to detect cancer.
- Decision support software that analyzes patient data to recommend medication dosages.
- Health monitoring apps that measure and track blood glucose levels, issuing warnings when readings are abnormal.
Below is a concise overview of their key differences across various aspects:
Functionality
- SaMD: Operates independently from any hardware, fulfilling its intended medical functions through software alone, typically on general computing platforms.
- SiMD: Integrates with other medical devices, requiring hardware to perform its functions. This software enhances or controls the hardware device’s operations.
Project Size and Complexity
- SaMD: Projects can vary in scale but often focus solely on software development that can be used across multiple platforms.
- SiMD: Typically involves larger, more complex projects as it integrates software with specific medical device hardware, often leading to advanced development challenges.
Regulatory Considerations
- SaMD: Must comply with medical device regulation standards but is scrutinized primarily for its software capabilities and the direct health impact it delivers.
- SiMD: Subject to stringent regulatory oversight not only for the software but also for how it interacts with the hardware components of the medical device.
Development and Deployment
- SaMD: Development is agile, aimed at rapid deployment across various digital platforms. Updates and iterations are more straightforward given the software-centric nature.
- SiMD: Development involves both software and hardware considerations, requiring a more integrated approach that often results in longer deployment times and complex update processes.
Risk Classification
- SaMD: Risk factors are generally evaluated based on the potential impact of the software’s decision-making on patient health.
- SiMD: Risks are assessed not just on the software’s functionality but also on its integration with hardware, which can introduce additional risk factors.
| SiMD vs SaMD | ||
|---|---|---|
| Brief comparison of Software in Medical Device (SiMD) and Software as a Medical Device (SaMD) projects | ||
| SiMD | SaMD | |
| Functionality | Enhances hardware device functions | Operates independently as software |
| Project Complexity | Involves complex, integrated components. Potentially more expensive in development | May range from small to large scale. Rather cheaper in the development |
| Development and Deployment | Requires long development and extensive integration testing | Smoother development process. Allows for quicker, more flexible updates |
| Regulatory Considerations | Subject to software and hardware regulations | Governed mainly by software regulations |
| Risk Classification | Risk assessed on software-hardware interaction | Risk based on software’s direct impact |
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 a 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.
Conclusion
Understanding the distinction between Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD) is crucial for navigating modern healthcare technology. SiMD integrates with medical hardware to enhance its functionality and involves complex development and stringent regulatory oversight. SaMD, on the other hand, operates independently as standalone software, allowing for more agile development and updates, with a focus on software-specific regulations.
Both SiMD and SaMD are essential for advancing healthcare, each addressing unique needs and leveraging technology in different ways. Recognizing these differences helps stakeholders optimize development, ensure regulatory compliance, and improve patient care.