A look at the convergence of hardware-centric medical devices with software-driven solutions
We are at a crossroads of technological and medical change. In recent years, there has been a wonderful convergence: both traditional medical device manufacturers and technology giants are harnessing the power of software to create breakthrough medical products. This convergence has not only broadened our horizons in patient and user care, but it has also raised compelling questions about how we define medical devices.
As software continues to advance, we are seeing the lines between traditional hardware-centric medical devices and software-driven solutions blurring. Software for Medical Devices (SiMD) and Software for Medical Devices (SaMD) have emerged. Both areas, while closely related, are distinct categories within the rapidly evolving field of medical technology.
At the same time, there is a global trend of people becoming increasingly health-conscious and wanting deeper and easier access to their vital signs, health status and overall well-being. Wearables and apps that provide sleep metrics, heart rate variability and fitness monitoring are no longer a luxury or niche product; they have become a necessity for many and most. The desire for deeper insights into personal health data, coupled with the rapid advancement of software technology, has only exacerbated the blurring of lines. Understanding the difference between SiMD and SaM is here.
SaMD and SiMD
The International Medical Device Regulatory Forum (IMDRF) defines software that is a medical device as “software that is used for one or more medical purposes but is not part of a hardware medical device.” While this definition seems to clarify things, there may still be confusion about what constitutes a SaMD product, as apps can be integrated with, but not be part of, a hardware device. Take, for example, a wearable device used in a physical therapy clinic. The device itself contains some firmware that can be used on its own and adapted to the needs of the patient; however, the company decided to offer a companion software application that would allow therapists to better view patient data from the device, as well as session data collected while the patient is wearing the device – to upload the data, all that is required is to connect the device to a computer that has the companion application launched.
A few years ago, this app wouldn’t have been considered part of a medical device by regulators; today, however, it has become the quintessential example of SaMD. In fact, in the practical example above, the medical device manufacturer would need to make two different submissions to the regulator, one specifically for the wearable device and the other for the companion app. While both submissions may have the same risk classification, the regulator will review each of these products separately; the wearable device contains firmware that allows it to operate without an app (SiMD’s example), while the app’s visualisation features allow it to operate without an app (SiMD’s example).
These examples illustrate the importance of multiple domains when evaluating a product:
1.What is the software responsible for doing?
2.Is the software installed on a device, cloud-based, or both?
3.What are the statements about the software’s capabilities?
4.What impact does the software (intentionally or unintentionally) have on patients and clinicians?
5.How will changing the software affect the way it is used or interpreted?