- Why Us
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.
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.
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
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.
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.
In that same breath, this new digital area also demands a purpose-built QMS software be utilized by SaMD companies and function beyond the basic documentation and audit preparation capabilities of general-purpose tools.
With Greenlight Guru’s QMS software, you can connect every component of a project and demonstrate closed-loop traceability automatically from within the software. You can even predict the impact of changes made during product design or subsequent software updates. Ready to get in sync? Get your free demo of Greenlight Guru today!
Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software
Wade Schroeder is a Medical Device Guru at Greenlight Guru with a noticeable enjoyment of medical device product development processes. As an electrical engineer by trade, he began his career developing medical exam procedure chairs and later designing IVD devices. He has been a risk management enthusiast since the...