How Do I Know if My Software is a Medical Device?

As our world becomes ever more digitized, software has begun to infiltrate every minute of our day. We wake to the alarm on our iPhones, tell Alexa to turn on the coffee and turn off the heat, ride a computer-monitored elevator to our temperature-controlled office. Later, after appeasing our Google Fitness Assistants with an online Peloton spin class and eating our DoorDash dinner, we relax with a glass of wine while mindlessly flicking through Netflix, or repeatedly swiping right in hopes of finding the perfect romantic partner. It’s hard to think of a single daily activity that doesn’t involve software in one form or another, as our phones and tablets and monitoring devices become the fingers that we digitally extend into the online abyss.

These technological advancements have become integrated into our healthcare as well, with a growing number of digital platforms supporting medical and non-medical functions. Software has controlled the motors and sensors and robotic arms of our medical devices for years, but now the ongoing evolution of algorithms, artificial intelligence (AI) and machine learning has spawned smart devices that can capture and transmit EKGs, interpret imaging results, and even preliminarily diagnose any number of medical conditions. It’s a brave new world out there, with new technologies and algorithms introduced every day that further digitize the way we manage our health.

But as a medical device manufacturer trying to bring a new and connected product to market, how do you know if your software is the medical device, as opposed to a means of simply controlling movement and storing data? As with any other regulated device, the answer lies in the guidance documents.

How FDA Defines SaMD

Despite its almost universal acceptance, software as a medical device (SaMD) is not always clearly defined, making it difficult for manufacturers to know whether their software qualifies. The FDA is uncharacteristically concise in their definition of SaMD, defining it only as “software that is a medical device on its own” – no real help there. Fortunately, the International Medical Device Regulators Forum (IMDRF) offers a bit more detail, describing it as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”

Chaired by the FDA, the IMDRF is a worldwide group of regulators working together to coordinate the regulation of medical devices across jurisdictions. The IMDRF has a variety of working groups focusing on a wide range of medical device topics, including unique device identifiers (UDI), adverse event terminology, regulatory review practices, and product submissions. These working groups develop guidance documents that are reviewed and finalized by the members, who then formally adopt and integrate the guidances into their existing regulations.

In 2013, no doubt seeing the AI writing on the wall, IMDRF established the SaMD working group to develop a framework for the use of software in and as medical devices. Their first task was to issue a guidance to more clearly define software as a medical device (which FDA has incorporated into the clear examples listed on their website):

• A medical device, including in-vitro diagnostic (IVD) medical devices
• Capable of running on general purpose (non-medical purpose) computing platforms
• May be used in combination with other products, including medical devices
• May be interfaced with other medical devices, including hardware medical devices and other SaMD, as well as general purpose software
• Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device
• Mobile apps that meet the definition above are considered SaMD
• “without being part of” means software not necessary for a hardware medical device to achieve its intended medical purpose

Somewhat clearer than mud, but still a potential challenge for manufacturers unfamiliar with the terminology associated with SaMD. Perhaps sensing the potential for industry confusion, the IMDRF also released guidance documents on risk categorization, quality management systems and clinical evaluation of software as a medical device to address some of the regulatory concerns and give manufacturers a blueprint for compliance.

Faced with a growing number of questions regarding SaMD and challenged by the many innovative software and app-driven technologies coming to market, the FDA in 2020 established the Digital Health Center of Excellence (DHCE) within the Center for Devices and Radiologic Health (CDRH). DHCE’s stated purpose is to “empower stakeholders to advance health care by fostering responsible and high-quality digital health innovation.” The center wants to modernize digital health policies and regulatory strategies while supporting the advancement of technology such as mobile health devices, wearables, and SaMD. Most importantly, DHCE will coordinate work across the FDA to ensure the uniform application of policies and consistent regulatory oversight, and to create tools to help stakeholders navigate the regulatory challenges presented by software as a medical device.

MDR’s Take on Software as a Medical Device

Not to be outdone, the European Commission established an equally murky regulatory landscape with the new Medical Device Regulation (MDR), which has its own set of definitions, classifications, and rules for software as a medical device.

Article 2 of the new regulation defines a medical device as “any instrument, apparatus or appliance or software intended by the manufacturer to be used alone or in combination for humans for medical purposes, including:

• Diagnosis, prevention, monitoring, prediction, prognosis or 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 vitroexamination 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.”

More simply put, the classification of software as a medical device depends on its intended use. If a manufacturer includes a clear medical purpose in the intended use statement – such as interpreting heart rhythms, analyzing skin moles, or alleviating seasonal depression – then that software qualifies as a medical device. Software for more general lifestyle and well-being purposes does not, provided the manufacturer makes no therapeutic or diagnostic promotional claims. Likewise, an application that allows the user to take pictures of a rash to be shared with their physician does not qualify as a medical device if the app performs no action on those images other than storage.

Perhaps the biggest change that MDR ushers in for software as a medical device is up-classification to a new risk category. This is a big blow to manufacturers of Class I software, as it means a lot more regulatory oversight than was previously mandated for software, including the potential for notified body involvement.

Annex VIII of MDR lists the medical device classification rules, one of which is specific to software. Rule 11 clearly states that “software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes” will be up classified under the new regulation. There are now five software classifications – Class I, Im, IIa, IIb and III – with specific definitions for each outlined in rules 9, 10, and 11.

To say the rules are complex would be an understatement. Here are some examples of how the new MDR rules determine software device classification from a 2019 Regulatory Affairs Professional Society (RAPS) article:

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health, in which case it is in Class III or a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as Class IIb. Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb. All other software is classified as Class I. As an example, software used to monitor heart rates or any other physiological parameters during a routine checkup is classified as Class IIa. However, if the monitoring aims at vital physiological parameters, and where those parameters could result in immediate danger to the patient, the classification is elevated to Class IIb.”

The Road Ahead

Clearly, the digitization of patient diagnosis, monitoring, and treatment – indeed all modern-day healthcare – is here to stay. Software as a medical device is a fluid and evolving concept, and one that will continue to change as new technologies, applications, and medical indications for software are developed. The challenges for manufacturers trying to pilot their products through the convoluted regulatory landscape and onto market will only increase, leading them to weather eye on the horizon, adjusting course as new requirements emerge. But the reward is a product that can meet the demands of today’s healthcare systems – and consumers.