Blogs

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.

However, suppose a device retrieves information, organizes data, and optimizes processes 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.

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 a 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

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.

USFDA – As technology continues to advance all facets of health care, software has become an important part of all products, integrated widely into digital platforms that serve both medical and non-medical purposes.  Software, which on its own is a medical device – Software as a Medical Device – is one of three types of software related to medical devices. The other two types of software related to medical devices include software that is integral to a medical device (Software in a medical device) and software used in the manufacture or maintenance of a medical device.

Possible IMDRF Framework for Risk Categorization of Software as a Medical Device

The Software as a Medical Device risk categorization framework has four categories (I, II, III, and IV).  These categories are based on the levels of impact on the patient or public health where accurate information provided by the Software as a Medical Device 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. The Level IV category is Software as a Medical Device with the highest impact on the patient or public health and Level I is the lowest.

Software as Medical Device manufacturers can consider a quality management system for Software as a Medical Device with the following principles:

• An organizational support structure providing leadership, accountability, and governance with adequate resources to assure the safety, effectiveness, and performance of SaMD;
• A set of Software as a Medical Device lifecycle support processes that are scalable for the size of the organization and applied consistently across all realization and use processes (requirements management, design, development, verification and validation, deployment, maintenance, and decommissioning of the product); and,
• A set of realization and use processes that are scalable for the type of Software as a Medical Device and the size of the organization that take into account important elements required for assuring the safety, effectiveness, and performance of Software as a Medical Device.

When introducing a new SaMD product in the US market, must apply for clearance with the Food and Drug Administration (FDA). The governing documents you need to ensure compliance with are:

• Title 21 of the Code of Federal Regulations, and in particular:
• 21 CFR Part 11, Electronic Records, Electronic Signatures
• 21 CFR Part 820 Quality System Regulation; be able to demonstrate you’re meeting the Good Manufacturing Practice requirements (CGMP) – these were first authorised in section 520(f) of the Federal Food, Drug, and Cosmetic Act, and were later codified under part 820.

As per the European Commission’s Medical Device Coordination Group (MDCG), Medical Device Software (MDSW) is a software intended to be used, alone or in combination, for a purpose specified in the definition of a “medical device” in Article 2(1) of Medical Device Regulation (EU) 2017/745, regardless of whether the software is independent or driving or influencing the use of a device. The software must have a medical purpose on its own to qualify as a MDSW. The MDSW must fulfil the definition of a “medical device”, “software”, or “in vitro diagnostic medical device”.  The keynotes while determining a MDSW as per EU MDR include:

• MDSW may be independent, by having its own intended medical purpose and thus meeting the definition of a medical device on its own
• If the software drives or influences a (hardware) medical device and also has a medical purpose, then it is qualified as a MDSW
• Software may be qualified as MDSW regardless of its location (e.g. operating in the cloud, on a computer, mobile phone, or as an additional functionality on a hardware medical device)
• MDSW may be intended to be used by healthcare professionals or laypersons (e.g. patients or other users)

When a software is not a MDSW, but is intended by the manufacturer to be an accessory for a medical device or in vitro diagnostic medical device, they fall under the scope of the MDR.