FDA Issues Final Guidance on Clinical Decision Support Software and Software as a Medical Device: Key Takeaways and What it Means for Digital Health Companies

On September 27, 2022, the U.S. Food and Drug Administration (“FDA”) released the final version of its guidance to industry stakeholders for Clinical Decision Support software (“CDS Guidance”). The CDS Guidance incorporates significant clarifications and changes from the previous draft guidance that the FDA released in 2019 in response to legislative changes under the 21st Century Cures Act amending the definition of a “device” to exclude certain software functions. Its stated purpose is to:

  1. Describe FDA’s regulatory approach to Clinical Decision Support (“CDS”) software functions;

  2. Clarify FDA’s interpretation of Section 520(o)(1)(E) of the Food, Drug, and Cosmetic Act (“Section 520”) that excludes certain software functions from the definition of a medical device; and

  3. Specify and provide examples of the types of CDS software functions that are NOT medical devices (“Non-Device CDS”) under this interpretation.

This post provides an overview of some of the key takeaways contained in the CDS Guidance, with an eye toward what these updates mean for digital health companies that incorporate CDS into their platforms. So, let’s dive in.

Background

The FDA regulates software that meets the definition of a medical device – known as Software as a Medical Device or “SaMD” – as set forth in Section 201(h) of the Food, Drug & Cosmetic Act (“FD&C Act”). This includes any software that is intended by its manufacturer for use in the diagnosis, treatment, prevention, cure, or mitigation of a disease or medical condition, or that is otherwise intended to affect the structure or function of a body. CDS is a subset of software that is intended to provide decision support for the diagnosis, treatment, prevention, cure, or mitigation of diseases or other conditions, and which may or may not be regulated as SaMD depending on the specifics of a particular CDS software’s functionality.

The 21st Century Cures Act, which was signed into law in December 2016, amended Section 520 of the FD&C Act, which excludes certain CDS software from the definition of a medical device. Under Section 520, CDS software becomes Non-Device CDS if the software is: 

  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;

  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; and

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

Key Takeaways from the CDS Guidance

Focus on Non-Device CDS Analysis

The previous draft guidance released in 2019 touched on four different categories of software functions: (1) Non-Device CDS functions, (2) CDS functions that qualify as a medical device but fall under FDA’s enforcement discretion, (3) CDS functions that qualify as a medical device and are subject to FDA oversight, and (4) non-CDS functions that qualify as a medical device and are subject to FDA oversight. In contrast, this CDS Guidance streamlines the discussion by focusing solely on the criteria for software functions to be categorized as Non-Device CDS.

This approach brings increased clarity to the Non-Device CDS analysis, but may leave some digital health companies wondering what impact this change will have on FDA’s regulatory enforcement policies for the other previously identified categories of software functions. The CDS Guidance makes clear that “FDA’s existing digital health policies continue to apply to software functions that meet the definition of a device, including those that are intended for use by patients or caregivers.” Additionally, software functions that are identified in other guidance documents as falling within FDA’s enforcement discretion – meaning FDA does not intend to enforce compliance with the requirements of the FD&C Act on these products due to their low risk level – will remain within FDA’s enforcement discretion.

It is worth noting that the focus on Non-Device CDS in this CDS Guidance does NOT alter FDA’s existing enforcement policies for SaMD, and the Guidance should assist digital health companies in determining more accurately where their specific product falls within the existing FDA regulatory framework.

Additional Definitions and Examples of Non-Device CDS Functionality

With this CDS Guidance, one of FDA’s main goals is to increase the clarity of its interpretation of the Non-Device CDS criteria under Section 520. To this end, FDA added several definitions, explanations, and examples of its interpretation of key terms contained within these criteria, including:

  • Medical Image;

  • Signal;

  • Pattern;

  • Medical Information about a Patient; and

  • Other Medical Information

FDA also provided additional information on how certain functions may interact to affect the classification of a software function. For example, data sampling frequency may affect the categorization of data as either single instance/infrequent “medical information about a patient” or repeated/continuous “pattern” data. 

Such distinctions may seem small and are easy to overlook, but they will be critical for many digital health software platforms, as the proper categorization of the data being analyzed may impact the overall software function’s categorization as either a device or Non-Device CDS.

“Supporting or Providing Recommendations to a Health Care Professional”

The third criterion listed above for a Non-Device CDS under Section 520 is that the software function is intended to support or provide recommendations to a health care professional (“HCP”) about prevention, diagnosis, or treatment of a disease or condition. The CDS Guidance clarifies that the FDA interprets this criterion to refer to software functions that provide condition-, disease-, and/or patient-specific recommendations to an HCP in order to enhance, inform, and/or influence a health care decision, but that is NOT intended to replace or direct the HCP’s judgment. Such software functions are in contrast to those that provide a specific preventive, diagnostic, or treatment output or directive, especially in time-critical decision-making situations. While the former are more likely to be classified as Non-Device CDS, the latter are more likely to be classified as devices.

At the core of FDA’s interpretation of this criterion is the requirement for HCPs to be able to make independent health care decisions. Two of the factors that will affect whether a software function is being used to support or provide recommendations to an HCP are: (1) the level of automation, and (2) the time-critical nature of the HCP’s decision-making. As each of these factors increases, the ability of the HCP to make a truly independent health care decision will decrease, and the software function will pull away from the realm of Non-Device CDS and push further into the realm of devices.

Independent Review by HCP of Basis for Software’s Recommendations

FDA also provided additional clarification on how a software function, regardless of its complexity, can be intended for the purpose of enabling an HCP to independently review the basis for the software function’s recommendations, such that the recommendations are not primarily relied upon by the HCP.

To achieve this, several recommendations were provided on the types and level of information that the software or labeling of Non-Device CDS must provide to the HCP, including:

  • The purpose or intended use of the product, and the intended user group or population;

  • The required input medical information, with accompanying plain language instructions and explanations;

  • A plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation (including a summary of the logic or methods relied upon, the data relied upon, and the results from clinical studies conducted to validate the software's algorithm or recommendations); and

  • Software outputs that provide the HCP user with both relevant patient-specific information and the information about the knowns/unknowns that will enable the HCP to independently review the basis for the software’s recommendations.

For digital health companies, the decision of which and how much information to share with an HCP is an important one. Sharing the data relied upon by the software, and the results of validating clinical studies, are critical to show the effectiveness of the software function and build trust with HCPs. However, some digital health companies may be less excited to share information about the underlying logic and methods relied upon in their proprietary algorithms and tools. The recommendations provided within the CDS Guidance provide additional clarification to help digital health companies providing Non-Device CDS software ensure that HCPs have the information they need to make independent health care decisions. 

Applying the Final CDS Guidance to Your Product

As with any analysis involving a potential medical device, the devil is in the details when it comes to determining whether a particular CDS software product IS or IS NOT a device.  The accurate classification of digital health software can have a significant impact on both a product’s regulatory pathway and its possible reimbursement opportunities. For example, in 2022, CMS announced a new reimbursement opportunity for some SaMD platforms that support Remote Therapeutic Monitoring (“RTM”), and the proposed 2023 Medicare Physician Fee Schedule makes several adjustments to these RTM codes. These RTM codes require use of a device, which of course includes SaMD, but does NOT include Non-Device CDS software.

As such, it is critical for any digital health company or developer of an SaMD product to ensure they have a clear and accurate understanding of where their software function falls within FDA’s regulatory framework. While this final CDS guidance provides additional guidelines and clarifications that will assist with this classification, the application of these guidelines should be carefully reviewed and applied on a specific case-by-case basis.

Nixon Gwilt Law assists digital health and device companies in navigating the regulatory landscape necessary to bring these products to market. We take an integrated approach to a company’s FDA regulatory strategy, its reimbursement and revenue model, and its overall business strategy. If you are interested in working with NGL to develop your regulatory and reimbursement strategy, contact us to learn more!