Software in a Medical Device vs. Software as a Medical Device: Understanding the Differences - Part 1

12 Dec 2023

A look at the convergence of hardware-centric medical devices and software-driven solutions

In the world of technology and healthcare, we are at a transformative crossroads. Over recent years, there's been a fascinating convergence: traditional medical device manufacturers and tech giants alike are harnessing the power of software to create groundbreaking healthcare products. This fusion is not only expanding the horizons of what we deem possible in patient and user care, but also raising compelling questions about how we define a medical device.

As software advancements continue, we witness a blurry line emerging between conventional hardware-centric medical devices and software-driven solutions. Enter the domains of Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD). These two arenas, while closely linked, serve as distinctive categories in the fast-evolving landscape of medical technology.

This is coupled with the global trend of an increasingly health-conscious populace that desires deeper and more accessible insights into their vitals, health, and overall wellness. Wearables and apps offering sleep metrics, heart rate variations, and fitness monitoring are no longer luxury or niche items; they've become necessities for many and most. This desire for greater understanding of personal health data, combined with rapid advancements in software, only intensifies the blurring lines. It is here that understanding the difference between SiMD and SaMD is paramount.

While traditional medical device firms have consistently integrated sophisticated software into their offerings, tech powerhouses are learning they cannot proceed unchecked as they advance their wearables and applications. The metamorphosis of the Apple Watch from a 'cool accessory' to a legitimate FDA-approved health monitor exemplifies this realization.

In this, the first of a two-part blog, we'll look at what the differences are between SaMD and SiMD.

SaMD vs. SiMD

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.' While this definition seems to make things clear, it's possible there would still be confusion regarding what constitutes a SaMD product as applications are able to integrate with hardware devices without being part of them. Take, for example, a wearable device to be used in physical therapy clinics. The device on itself contains some firmware that allows it to run on its own and be adjusted to fit the needs of the patient; however, the company has decided to provide a companion software application to allow therapists to better visualize their patients' data from the device and the session data collected while the patient is wearing the device – to upload the data, one must simply connect the device to a computer with the companion application launched.

Years ago, this application would not be deemed as part of the medical device to regulators; today, however, this is a prime example of SaMD. In fact, in the real-world example above, the medical device manufacturer was required to provide two different submissions to regulatory bodies, one specifically for the wearable and another for the companion application. Although it's possible both submissions could have been the same risk-classification, regulators viewed the products separately; the wearable contained firmware to allow for operation without the application (an example of SiMD) and the application visualized patient session data, which had the potential to impact how the clinician administered treatment or adjusted their PT program (an example of SaMD).

This example illustrates the criticality in multiple areas when assessing your product:

• What is the software responsible for doing?
• Is the software on-device, cloud-based, or both?
• What claims are being made regarding what the software can do?
• What impacts can the software, intended or unintended, have to the patient and the clinician?
• How will changing the software impact how it's used or interpreted?

In Part 2 of this blog, we'll take a closer look at the standards that are expected to be followed when developing medical software.