Software as Medical Device (SaMD)

Overview

The US Food and Drug Administration (FDA) acknowledges the International Medical Device Regulators Form (IMDRF) definition of software as a medical device (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.

To be put simply, software intended to be used alone i.e., able to fulfill a medical purpose on its own is SaMD. This definition is agnostic to operating location of the hardware (e.g., on local hardware, remote servers, or in ‘the cloud’).

It is important to understand the distinction between SaMD and software in a medical device (SiMD). SiMD is software intended to be used in combination with a hardware medical device to enable the hardware medical device to achieve its medical purpose. SiMD is regulated as a component of the medical device to which it belongs. Examples of SiMD include the software or firmware that allow pacemakers, radiology monitors, or CT scanners to operate.

Example Scenario

A manufacturer produced a digital thermometer and a corresponding smartphone application that connects to the thermometer and is capable of detecting fever via Bluetooth. The function of the thermometer is to measure body temperature. The firmware inside of the thermometer is considered SiMD. The companion app has a different medical function, it detects fever, and would be regulated as SaMD if intended for direct patient engagement.

Regulatory Classification of Clinical Decision Support

Software to inform clinical management is not SaMD. If a healthcare professional is able to independently review and understand the basis of the software recommendation and the software does not perform signal or image acquisition, processing, or analysis. In the United States, the above thermometer example is not considered SaMD if the target audience is healthcare professionals, as healthcare professionals independently know the definition of fever.

Clinical decision support (CDS) has been a hot topic for SaMD. It has been rumored [Citation needed] that Epic Systems rebranded one of their CDS tools, BestPractice Advisories, to OurPractice Advisories (OPAs) to avoid potential regulation, especially as many CDS tools are independently built by customers and not externally validated for external use.

In the US, the FDA determination of CDS being SaMD is dependent on the target audience (healthcare provider vs others), if the user is able to independently review the information, and the state of the healthcare situation. Healthcare situations are defined as non-serious, serious, or critical; with higher severities more likely to require oversight. If the intended user is a patient or caregiver/non-healthcare professional, the CDS is SaMD.

In 2022 the FDA published their "final guidance"on CDS . This more technical definition of CDS that does not meet criteria for SaMD if the CDS tool meets all 4 of the following criteria:

1. not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system
2. intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines)
3. intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition
4. intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient

The final guidance also provides examples of when software in a CDS role would meet the threshold for SaMD. Specifically, when the purpose of the software is not merely supporting or providing recommendations to a healthcare provider but directing and substituting their judgement. Examples include situations where software provides:

• Specific preventative, diagnostic, or treatment course
• Specific follow-up directive
• Time-critical alarms or alerts intended to trigger potential clinical intervention to assure patient safety
• Treatment plans for a specific patient’s disease or condition

Digital Health Policy Navigator

There is significant nuance to these guidances. The FDA has created a web-based algorithm to help informaticians assess if their CDS tool is a medical device and requires oversight, the Digital Health Policy Navigator

Regulatory Classification of Artificial Intelligence and Machine Learning

Machine learning (ML) and artificial intelligence (AI) are categorically defined by the FDA as medical devices and require approval through the medical device pathway. Given the dynamic nature of ML and AI, the FDA has a guidance describing a path for development that accommodates interval updates to these systems. The manufacturers are able to create a Predetermined Change Control Plan (PCCP) in the marketing submission that allows the manufacturer to describe future modifications to the system that would not constitute a significant change and would not require interval FDA approval.

PCCP is required to include detailed description of the specific, planned device modifications, the methodology to develop, validate, and implement the modifications to ensure continued safety and efficacy of the device, and an assessment of risks and benefits of planned modifications, as well as risk mitigations.

The FDA also offers suggestions on how to develop good machine learning practice through 10 guiding principles that meet the unique nature of AI/ML. The FDA continues to develop its position on AI/ML and more guidances are anticipated as the agency continues to work with manufacturers on additional devices.

References

Submitted by Matthew Greenwood