November 1, 2023

A Guide to FDA Clinical Decision Support (CDS) Software Approval

Clinical decision support (CDS) software has become a critical element of healthcare delivery. It integrates with other devices and technologies to improve the quality and efficacy of healthcare by offering evidence-based information and suggestions, and alleviating some of the mental burden providers carry.

In 2016, US Congress carved out certain CDS software functionalities that should not be regulated as Software as a Medical Device (SaMD) when it signed the 21st Century Cures Act into law. While this drew a line between device and non-device CDS, that line has blurred as the US FDA attempted to articulate how it will regulate CDS software going forward. Now CDS developers are bogged down in a sea of regulation and guidance, trying to determine how to legally bring their product to market.

In this article, we’ll examine the FDA’s recommendations that determine whether your clinical decision support software qualifies as a medical device. We’ll discuss the criteria implied in the guidance and how to proceed if your software product is regulated as a medical device under the FDA.

CDS background and response from industry

Before we dig into the criteria, let’s take a brief look at how we got here. Here’s a timeline:

2016: US Congress enacted the 21st Century Cures Act. The Cures Act amended the definition of a medical device as defined in the Food, Drug, and Cosmetic Act (FD&C Act). It specified four functions that, when all were met, would exclude software from regulatory oversight.

2017: US FDA released draft guidance that articulated how FDA would interpret these criteria as they relate to clinical decision support software.

2019: Following input from industry, FDA released a revised draft guidance, which incorporated the International Medical Device Regulators Forum’s (IMDRF) Risk Categorization Framework into the FDA’s approach.

2022: FDA issued its final guidance clarifying its approach for determining whether clinical decision support (CDS) software fits the definition of a medical device: Clinical Decision Support Software. Recommendations in the guidance are a shift from the 2019 draft guidance and do not include the IMDRF’s risk categorization scheme. FDA also released revisions to two relevant final guidance documents: Policy for Device Software Functions and Mobile Medical Applications and Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.

Product manufacturers, software developers, and even providers have raised concerns about the implications of the final guidance. The consensus from many in the industry is that FDA’s interpretation of the guidance narrows the field of non-device CDS considerably, even more than Congress intended.

Some are concerned the guidance will dampen innovation in the CDS software space due to the regulatory and time burden of moving a product through the FDA clearance process. However, the FDA is concerned that as healthcare providers rely more and more on automation and decision support, the potential for patient harm increases. Software malfunctions, inaccurate or incomplete information, and automation bias are all circumstances that could put a patient at risk. With this guidance, FDA seeks to mitigate these risks.

Four criteria that excludes CDS software from FDA oversight

The guidance addresses four device functionality criteria that a CDS software product must fulfill to classify as a non-device CDS. All four criteria must be met.

Criteria 1 and 2 address allowable data inputs:

1. The software is 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. The software is 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).

FDA is taking a narrow interpretation of the first two criteria that will land many software tools in the device category, particularly in its definition of a “pattern” and “medical information.” There is also some ambiguity between the two criteria.

The guidance implies that any repeated measurement would be considered a pattern. For instance, a tool that acquires readings from a continuous blood glucose meter, would not meet Criterion 1 because the source of the data (IVD) is disallowed and the series of blood glucose levels would establish a pattern. However, Criterion 2 allows “data/results from devices (including IVD test(s)), when used in a manner consistent with the FDA-required labeling,” to be generally considered “medical information about a patient” within the meaning of Criterion 2. This interpretation could include lab test results, such as a blood glucose level, as “medical information.”

FDA’s overall definition of “medical information” raises some concerns as to how it can be interpreted and applied in a software development setting: “information that normally is, and generally can be, communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted.” This interplay between the two seems to imply that such data is allowable only within the context of a more comprehensive picture of a patient’s health.

Criteria 3 and 4 address allowable data outputs:

3. The software function is intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition.

4. The software function is intended for the purpose of enabling health care professionals to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professionals rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

While FDA allows for recommendations that are “condition-, disease-, and/or patient-specific,” they cannot be time-sensitive or singular to meet this criteria. As you can imagine, these caveats significantly narrow the field of qualifying tools and seems to limit the tools that do qualify to those that deliver lists of diagnostic or treatment options.

In its lengthy exploration of device CDS, the guidance cites numerous examples of tools that fail to meet Criteria 3 because their recommendation constitutes a single diagnosis or treatment option or because they are time-sensitive. For example, software that analyzes medical information about a patient to cue an alarm for a provider about a potential life-threatening condition, such as stroke or sepsis, would be considered a device. However, software intended to identify drug-drug interactions and or allergies intended to prevent adverse drug reactions would not be considered a device.

Time-sensitive decision support also plays into the FDA’s rationale behind Criteria 4. To meet Criteria 4, the provider must have access and ability to review the data behind the software’s recommendations, including the underlying algorithm logic or methods, datasets, and validation in “plain language” either via the labeling or the outputs. The intent is for providers to independently assess whether the recommendations are relevant to their patient and they must have time to do so before acting on the recommendation.

Criteria 4 is the most abstract and determining its application will likely be a challenge for many developers. The guidance suggests usability testing as a route to determining whether your product fulfills this criterion.

What’s next for Clinical Decision Support software regulation from FDA?

The final guidance is likely to move many software products that were assumed to be non-device CDS under the terms of the 2019 draft guidance into the device category. This means products that were placed on the market or put into development under the conclusion that they would not be marketed as a device will need to reassess their product’s functionality and/or it’s go-to-market strategy. You may also benefit from engaging with the FDA about how the final guidance impacts your product by seeking their input via the Q-Submission program. We can help you identify your next steps if you think your CDS software’s device classification is in question. We can help you evaluate your product’s functionality against the new guidance and determine your software’s status. We’ll help you prepare for a Pre-Submission meeting with the FDA, if needed. If your product is ruled a medical device, we’ll perform a thorough gap analysis and help you prepare your 510(k).

Want to learn more?

You’ve made it this far so clearly this article was of interest. Our consulting team is ready to help you with FDA software classification questions, FDA 510(k) preparation or any other FDA or EU regulatory issues.