Software as a medical device: Here’s how the regulatory landscape is changing

When it comes to software as a medical device, the regulatory landscape is quite complex.

Nach Davé, Premier Research

Software as a medical device (SaMD) has emerged as a class of devices for collecting, processing and analyzing healthcare data to manage disease. Powered by analytics, SaMD accelerates the diagnosis and treatment of a wide range of medical conditions and is automating certain aspects of patient care, saving time and improving health outcomes. Because the technology is relatively new, however, the regulatory environment is still evolving as regulators scramble to keep pace with innovation.

Health providers are increasingly deploying SaMDs to facilitate patients’ pain management, arrhythmia management, and blood glucose monitoring. Some applications require daily use by the patient — sometimes multiple times a day — while remaining compliant with good clinical practice. The potential advantages include fewer office visits, increased frequency of patient metrics, and real-time alerts if readings from the software suggest a risk to the patient. On the other hand, the use of SaMD may result in less face-to-face contact with patients, with potential ramifications for clinical trial operations and long-term care.

Navigating a complex regulatory environment

The regulatory landscape for SaMD is quite complex, with multiple pathways and product development implications impacting the eventual regulatory determination. That complexity reflects the inherent challenges in classifying SaMD, as regulating this new class requires a basic understanding of what it is. The International Medical Device Regulators Forum (IMDRF) is a global working group comprising representatives of the U.S. Food and Drug Administration, European Medicines Agency, and other key regulators. It 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.” In other words, the software component must inform or enable a medical decision or outcome but must not principally drive a hardware device. For example, by that definition, the medical device software used to view images from a magnetic resonance imaging (MRI) scanner on one’s phone would be SaMD, but the software enabling an MRI machine to run the test would not be.

However, suppose a device retrieves information, organizes data, and optimizes processes (see the far-left column in Figure 1) or enables a closed-loop intervention without a clinical intermediary (far-right column). In that case, it is not SaMD, according to the IMDRF. That leaves a vast gray area in the middle, underscoring the importance of early discussions with regulators to reach a consensus on the most appropriate category for a specific device.

Figure 1. IMDRF Classification Paradigm for Software as a Medical Device (SaMD)

In our experience, the distinction matters because correct classification has profound implications for SaMD development and commercialization. Additionally, developers are increasingly making efficacy claims based on the use of SaMDs in clinical trials, in some cases before evaluating regulatory pathways or standards. For an SaMD with a low-risk application, a developer may assume it is a Class I medical device, implying a faster regulatory pathway and minimal scrutiny.

Bridging gaps in knowledge and regulations

Regulators in different regions have taken different views of the risks related to SaMD and are under pressure to harmonize their regulations as innovation continues at a breakneck pace. Additionally, SaMDs can be acquired online without medical oversight, and patients can use them while traveling abroad, where regulations may vary. Such gaps leave much to the interpretation of individuals with less than optimal regulatory knowledge. The challenge lies in striking an appropriate balance between encouraging innovation and ensuring patient safety.

To meet that challenge, the FDA has initiated a pilot program, the Digital Health Software Precertification Program, to provide more streamlined and efficient regulatory oversight of software-based medical devices. Another key regulation, IEC 82304-2016, delineates general health software product safety and security requirements. The EMA similarly regulates software that drives or influences the use of a device; if the software is independent of any other device, it is classified in its own right.

Seizing the opportunity

In our estimation, the current regulatory environment presents a rare opportunity for SaMD developers to shape how these products are regulated. That makes it vitally important to engage in early dialogue with regulators to ensure clarity and agreement on device classification. It is also important to follow and contribute to IMDRF decisions, as all the major regulatory bodies recognize this forum. Additionally, following design controls can enable flexibility across regulated regions and minimize any potential remediation efforts. Finally, these strategies can enable a comprehensive understanding of the appropriate regulatory pathways for SaMD and help ensure a successful market launch.

Nach Davé is VP of development strategy at Premier Research.

The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of MedicalDesignandOutsourcing.com or its employees.