Software as a Medical Device: Definitions, Examples & Regulatory Framework

Software as a Medical Device (SaMD) is a technology with limitless possibilities. In the hands of talented engineers and developers, it’s an infinite toolbox that can improve the quality of life for patients and providers.

SaMDs are incredibly valuable because of the way they interact with data. Specifically, these applications are able to process huge amounts of complex data in a matter of moments. They’re also mobile, portable, cost-effective, and easier to update than the physical devices used by doctors. Lastly, much of the medical device software on the market is always connected to the internet, meaning its creators can make adjustments to devices with real-time feedback.

But, with rapid advancements, constant innovation, and the proliferation of smartphones and tablets, the SaMD landscape is changing rapidly. As a result, there are gaps in knowledge and regulatory practices on a global scale.

Here’s what you need to know about Software as a Medical Device and its role in 2021 and beyond.

BONUS RESOURCE: Click here for a 3-in-1 gap assessment tool to help you comply with SaMD requirements from EU MDR (Rule 11), IEC 62304, IMDRF.

What is Software as a Medical Device?

It’s important that we first start with a clear definition of Software as Medical Device (SaMD).

The International Medical Device Regulators Forum (IMDRF) defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." 

It is important to note the phrase “without being part of.” This means the software itself functions independently of any existing device. 

While SaMD are often used in conjunction with other devices, a piece of software does NOT meet the IMDRF definition if its intended purpose is to drive a hardware medical device.

Instead, we use the term Software in Medical Device (SiMD) to describe software that is a part of another existing device. This would include any software that powers a medical device's mechanics, remotely controls functionality, processes data, or is otherwise essential to a medical device’s operation.

Due to the nature of medical software and its potential for applications, the language in this realm can get a little murky. This is especially true for issues like regulatory oversight, classification, intended use, and operation instructions, all of which ultimately rely on precise wording.

What are Examples of Software as a Medical Device?

We know now that Software as a Medical Device is a standalone product. But, because it’s software and not a physical device, conceptualizing what those products look like can be a little abstract. 

A good rule of thumb when evaluating the potential medical device classifications of a software product is to examine how the data is output or displayed. Software as Medical Devices require non-medical devices like tablets, smartphones, smartwatches, or laptops in order to run correctly. If, however, the software controls or manipulates an actual medical device, it is not considered a SaMD.

Though this list is far from exhaustive, here are some tangible examples of Software as Medical Devices:

• Software that displays MRI and other types of medical imaging on mobile devices

• Image processing software to detect cancer

• Software that regulates an installed medical device, like a pacemaker

• BMI and body fat calculators

• Treatment software which interprets patient input data to develop a plan of action for a provider and patient

• Sleep data app that uses camera/microphone on an smartphone to transmit back to sleep lab

• Software clone of the digital mammogram machine that radiologists use to calculate breast density 

After reading this list, it may be tempting to simply label any medical-related app as a Software as a Medical Device. However, the intended use and functionality are the defining characteristics for a SaMD classification. In fact, FDA has already released materials outlining some basic functionality that excludes software from being considered a medical device. 

Examples of apps that are NOT considered a Software as a Medical Device are:

• Electronic copies of books and reference materials like medical dictionaries

• Educational tools for healthcare providers

• Online portals for patient awareness, empowerment, and education

• Automation for office-related hospital operation, such as determining billing codes, input and output of insurance info, medical accounting calculations, and doctor shift scheduling

• Generic aids or general purpose apps, such as magnifying glass, web-based video chat platform that allows patients to converse with doctors, maps that provide directions to a hospital

Regulatory Framework for Software as a Medical Device

In order to address the rapidly changing capabilities of SaMD, the IMDRF formed its Software as a Medical Device Working Group in 2013. Since then, the group has released a possible risk categorization framework for SaMD. 

This proposed regulatory framework breaks down risk level into four categories (I, II, III, and IV). Those categories are in ascending order of risk, and indicate the level of impact on patients in which the “accurate information provided by the SaMD to treat or diagnose, drive or inform clinical management is vital to avoid death, long-term disability or other serious deterioration of health, mitigating public health.” 

In simpler terms, this framework compares the significance of the information provided by the SaMD to the state of the healthcare situation or condition. 

There are multiple considerations involved in the SaMD regulatory framework. These are products that are born at the convergence of both healthcare and mobile app development, and are often used as part of a larger clinical workflow. That means even a single issue with design, implementation, usage, or functionality could cause users to make incorrect decisions, which then impact the treatment for patients.

In order to address the risks associated with development, the framework refers to IEC 62304 as a standard for lifecycle of SaMD. The standard outlines a risk-based decision model, testing requirements, and principles that drive agile quality management systems.

Another area of regulatory consideration are software changes and updates, many of which are necessary to the development of any software product. Some of these changes are more impactful than others, such as modifying a foundational algorithm, new features, or design elements that may interrupt workflow. 

This regulatory framework accounts for these key considerations and has even been championed by numerous regulatory organizations, including FDA, who used the IMDRF’s definitions, QMS, and risk-management framework as a foundation for its own publication Software as a Medical Device: Clinical Evaluation. 

Additionally, FDA has launched the Digital Health Software Precertification Program, to provide more streamlined and efficient regulatory oversight of software-based medical devices. The European Medicine Association similarly regulates software that drives or influences the use of a device; if the software is independent of any other device, it is classified as its own medical device.

BONUS RESOURCE: Click here for a 3-in-1 gap assessment tool to help you comply with SaMD requirements from EU MDR (Rule 11), IEC 62304, IMDRF.

Translate Your Software as a Medical Device Development Efforts into Regulatory Success

SaMD technology attracts some of the most exciting and innovative thinkers in the medical device industry. This is an ever-changing world we’re living in, and with governing authorities still developing their own regulatory controls, it provides new opportunities for manufacturers to shape the landscape and set the scene for the future. 

While Greenlight Guru excels in quality management, we understand the unique dynamics of software development in the medical device industry. Our QMS acts as a bridge between your development work and regulatory requirements, providing the necessary guardrails to ensure compliance without stifling innovation.

Easily translate your software development work into compliance-ready documentation, simplifying regulatory submissions and audits. Get your free demo of Greenlight Guru Quality ➔