Software as a Medical Device
Healthcare is undergoing a paradigm shift as cutting-edge technology makes its way into medical devices, tele-health, and digital health solutions. Most modern medical devices are manufactured with integrated software and software in general has become a deeply rooted part of medical industries the world over.
Medical software manufacturers and manufacturers of medical devices with integrated software must carefully consider the regulatory framework and new regulatory requirements to be able to put their software on the market. While some regions have still not adopted regulations for medical device software, both the EU and the FDA have requirements for medical software and software as a medical device that rival those of traditional medical device regulations.
What is medical device software?
Medical device software is generally considered to fall into 4 classes:
- Software as a Medical Device (SaMD), which is a standalone software that has a medical function and works as a medical device in and of itself, such as insulin dosage recommendation apps or MRI scan analyzing software. SaMDs work without the need for a hardware medical device.
- Software in a Medical Device (SiMD), which is part of a medical device, such as remote control software for X-Ray machines or the software that controls pacemakers. SiMD is considered part of a hardware medical device.
- Software as an accessory to a medical device
- General software that is not a medical device by itself, such as hospital informations systems
This article will focus on Software as a Medical Device under the MDR.
Software as a Medical Device: Definitions
International Medical Device Regulators Forum (IMDRF)
The International Medical Device Regulators Forum (IMDRF) defines SaMDs as “intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” Medical purposes applicable to SaMD is further defined as any purpose falling within their general medical device definition. It is also important to note that software must be capable of running on general purpose computing platforms, such as laptops and smartphones, to be included in the SaMD definition.
European Commission
The European Commission’s Medical Device Coordination Group issued their software guidance document “Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR” in October 2019.
In it, Medical Device Software is defined as software that is “is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.” While the term Software as a Medical Device is not directly mentioned in the guidance document, it is indirectly defined as a part of Medical Device Software that “may be independent, by having its own intended medical purpose and thus meeting the definition of a medical device or in vitro diagnostic medical device on its own (i.e. alone).”
Food and Drug Administration (FDA)
The Food and Drug Administration (FDA) classifies software as a medical device as software which on its own is a medical device. The FDA continues to update its software guidance documentation; a draft guidance document titled “Content of Premarket Submission for Device Software Functions” open for comment was released on November 4th, 2021, making significant changes to the current guidance document issued in 2005.
The FDA was one of the first regulating bodies to understand that their current regulations wouldn’t suffice in the fast-paced growth of software and digital solutions.
In 2017, they established the Software Precertification Program in order to “inform the development of a future regulatory model that will provide more streamlined and efficient regulatory oversight of software-based medical devices developed by manufacturers who have demonstrated a robust culture of quality and organizational excellence, and who are committed to monitoring real-world performance of their products once they reach the U.S. market.” Also in 2017, they issued the Digital Health Innovation Action Plan to ensure that digital health products offered to Americans are high-quality, safe, and efficient. The plan is meant to protect and promote public health while pushing for digital health innovation.
SaMD under the MDR
Under the Medical Device Directive (MDD) 93/42/EEC, most medical device software was classified as Class I. However, under the updated MDR, most medical devices software will be classified as Class IIa or even Class III, which is the highest risk category. This is due to the newly added Rule 11 in Annex VIII of the MDR, which was drafted with guidance from the IMDRF.
Rule 11
Rule 11 addresses stand-alone software, i.e. SaMD, that serves diagnostic and therapeutic purposes. This is in line with the MDR’s medical device definition. According to Rule 11, any software that is used for the purpose of diagnosis, monitoring, prediction, prognosis or treatment, and which is used to make decisions with diagnosis or therapeutic purposes shall be classified as Class IIa or higher. What this means is that essentially all medical device software will be classified as Class IIa or higher.
Under the MDD, low-risk SaMDs, such as software suggesting diagnoses based on test results, sleep apnea diagnosis apps, and some apps supporting selection and dose calculations, would be considered Class I. However, under the MDR, the same devices are Class IIb, IIa, and Class III, respectively. This is because Rule 11 is based on severity (e.g. “might lead to death”) and duration (“irreversible”), not on risk. Only simple and very low-risk software, such as preventative software or monitoring software that is not used for diagnostic purposes, can now be classified as Class I.
How can you tell if your software is an SaMD under the MDR?
The classification of a software to an SaMD is based purely on its intended purpose and whether or not it falls into the medical device definition.
A medical device is defined in the MDR as:
“(A) medical device” means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
- diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
- diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
- investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
- providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations, and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means.
The following products shall also be deemed to be medical devices:
- devices for the control or support of conception,
- products specifically intended for the cleaning, disinfection or sterilisation of devices as referred to in Article 1(4) and of those referred to in the first paragraph of this point.”
Furthermore, software can be considered a medical device if it is an accessory to a medical device (or IVD), or if it is included in Annex XVI (devices without medical purpose).
Wellness and fitness applications
With the destigmatization of mental health problems and the focus on physical health, a wealth of wellness and fitness apps are becoming available in the App Store. These apps run non medical health software, such as exercise programs and tracking of bodily functions, such as menstrual cycles or feelings of wellbeing.
The MDR specifically points out that wellness and fitness applications are not considered medical device software:
“It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device…”
Challenges
Software as a medical device is constantly changing and the innovation within the sector is must faster than within tradition medical device industries. This obviously leads to different regulatory challenges than regulatory affairs specialists have previously been used to.
Perhaps the greatest challenge for SaMD manufacturers and regulatory agencies is the integration of technological advances and rapid innovation with patient safety and efficiency. Regulatory agencies are not exactly known for their speed, while medical software can be updated several times a year. How do we align the speed of innovation with the regulatory process?
Furthermore, considering the speed at which technology is currently developing, how do we ensure that our regulatory bodies are up to date with technological advances and understand the verification and validation testing for software as a medical device? It seems obvious that constant training and capacitation needs to be a regular occurrence in the lives of regulatory reviewers, but is that enough to ensure that regulatory agencies keep up with innovation?
Another regulatory challenge regarding software as a medical device is cybersecurity. We have already seen various cases where medical device software manufacturers have been hacked, have not been careful enough in regards to the privacy of their users, or have been victims of digital malware. In the current technological climate, it can be difficult to obtain the information required for medical software to work properly, while ensuring the safety and privacy of the user at the same time. Younger generations are more and more concerned with their privacy and companies who are able to address this concern while offering digital health solutions that work will be much more successful long term than companies who cannot.
As we move further into the innovation and excitement about the new opportunities offered by upcoming technologies, new challenges arise. How do we define and classify all these new devices? How do we maintain patient safety and efficiency? How do we keep up with an ever-changing technology industry and integrate it into medical devices, maintaining innovation?
Regulatory agencies and medical device software and SaMD manufacturers will have to work together to discover the solutions that can drive innovation and technological advances, while maintaining patient safety and efficiency.
Documents and guidance
