ConvaTec

There’s a lot of software-related activity happening at FDA, with the recent formation of FDA’s Digital Health Center of Excellence, and the release of an “Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) Action Plan”  in January 2021. Here’s a primer on what SAMD is, what SAMD is not, and how to navigate the changing regulatory landscape in this area.

First, it’s helpful to categorize what SaMD is not. Section 3060 of the Cures Act created a function-specific definition, and as such, the functions excluded from the device definition under section 520(o) of the FD&C Act are independent of the platform on which they might run. The functions that are excluded are:  

(A) for administrative support of a health care facility…

(B) for maintaining or encouraging a healthy lifestyle…

(C) to serve as electronic patient records…

(D) for transferring, storing, converting formats, or displaying … data and results, findings by a health care professional…and general background information… unless such function is intended to interpret or analyze…data, results, and findings…

Many Standalone Software Functions are Not Medical Devices, or FDA Does Not Intend to Enforce Requirements. FDA has provided a number of examples of the types of software functions that fall into these categories in a general wellness guidance document. While general wellness claims are not specific to software products, four illustrative examples of general wellness software functions are included in FDA’s guidance document. The guidance also clarifies, in a non-software example, that how products are regulated by FDA is based on intended use (and the same is true for software products): 

"While general wellness claims are not specific to software products, four illustrative examples of general wellness software functions are included in FDA’s guidance document"

Illustrative Example 6: A product is intended to mechanically exfoliate the face, hands, and feet to make the skin smoother and softer. The product cannot be used in a manner that penetrates or pierces the skin. This claim relates to self-esteem and does not refer to a specific disease or medical condition, and thus is a general wellness claim. In addition, the product is noninvasive as it does not penetrate the stratum corneum and the technology for exfoliating the face does not pose a risk to the safety of users and other persons if specific regulatory controls are not applied. Therefore, this product meets both factors for a low- risk general wellness product.

Note: However, if the product is intended to exfoliate the skin in order to enhance the delivery of a topically applied product containing one or more active pharmaceutical ingredients through the stratum corneum, the product would be invasive. Therefore, the product would not be a low- risk general wellness product.

Second, it’s useful to consider the description from the International Medical Device Regulators Forum (IMDRF), provided in the Final Document: Software as a Medical Device (SaMD), and incorporated into a FDA guidance document:

“A SaMD can best be described as software that utilizes an algorithm (logic, set of rules, or model) that operates on data input (digitized content) to produce an output that is intended for medical purposes as defined by the SaMD manufacturer. The risks and benefits posed by SaMD outputs are largely related to the risk of inaccurate or incorrect output of the SaMD, which may impact the clinical management of a patient.”

This IMDRF document establishes a framework, discusses how to evaluate and validate SaMD, and lays out a “Pathway for Continuous Learning Leveraging Real World Performance Data.”

In line with the framework outlined in this IMDRF document, FDA announced a pilot for the Digital Health Software Pre-Certification Program in 2017 and selected 9 pilot program participants.  This pilot has been focused on and limited to SaMD. FDA has stated their vision for the program to “help 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.”

FDA’s Guidance Document on Policy for Device Software Functions and Mobile Medical Applications provides a nice high-level overview of software regulatory history and highlights the functions that are the focus of FDA regulatory oversight, and also provides helpful examples. The three key areas to be aware of are:

1. Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.

2. Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors or by including functionalities similar to those of currently regulated medical devices.

3. Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations. These types of functions are similar to or perform the same function as those types of software devices that have been previously cleared or approved.

FDA’s Guidance Document on Clinical Decision Support Software describes the regulatory history of SaMD, and consistent with the IMDRF Framework, FDA intends to apply a risk-based policy for Clinical Decision Support (CDS) software functions. With that said, “FDA encourages developers of CDS software functions that are not medical devices or are medical devices for which at this time FDA [is exercising enforcement discretion] to implement a quality system consistent with IMDRF’s Software as a Medical Device (SaMD): Application of Quality Management System and to apply good cyber hygiene, such as through software design and cyber vigilance, consistent with applicable FDA guidance.”

Finally, FDA has specifically included SaMD in the scope of their guidance document on Deciding When to Submit a 510(k) for a Software Change to an Existing Device, and the flowchart on page 10 of this guidance is particularly useful (be sure to consider it in conjunction with the accompanying text). Helpful examples are also provided by FDA, specifically for cybersecurity considerations and an example of a software algorithm modification. 

It is typical for software in the health space to initially focus on general wellness or other low- risk software functions and then develop into software as a medical device with the addition of new software functions. Starting with the end in mind, and knowing how each additional software function affects regulatory considerations, enables design of an effective regulatory strategy to match or improve on software development plans, or even navigate the largely uncharted waters of artificial intelligence and machine learning- based software as a medical device.

David Pudwill is a former FDA Reviewer in the Center for Devices and Radiological Health

DISCLAIMER: The views and opinions expressed in this article are mine alone, and do not necessarily reflect the official policy or position of any company, FDA, or any other entity.