On September 27, 2022, FDA released a final guidance document titled Clinical Decision Support Software, Guidance for Industry and Food and Drug Administration Staff (“Final Guidance”), which focuses on clarifying the categories of clinical decision support (CDS) software functions that are excluded from the definition of a medical device under the criteria listed in section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act (FD&C Act).

This guidance finalizes the draft Clinical Decision Support Software guidance issued on September 27, 2019 (“Draft Guidance”). Given the growing use and reliance upon CDS in health care practice and delivery, this Final Guidance is particularly relevant for both software developers and health care systems and providers.

Key Takeaways

The Final Guidance is a significant rewrite of the Draft Guidance. Most notably, it removed FDA’s risk-based enforcement discretion policy. Under the Draft Guidance, FDA categorized CDS software functions into three categories: (1) those that do not meet the definition of a device as amended by the Cures Act; (2) those that “may” meet the definition of a device but for which, based on FDA’s current understanding of the risks of these devices, FDA intends to exercise enforcement discretion; and (3) those that meet the definition of a device and on which FDA intends to focus its regulatory oversight. The Final Guidance removes “Category 2” and eliminates enforcement discretion.

Additionally, the Final Guidance contains several additional departures from the Draft Guidance, including:

• The Final Guidance is narrower than the Draft Guidance, the scope does not include decision support technology used by patients and caregivers.

• Removal of any reference or discussion regarding applying the International Medical Device Regulators Forum standards.

• Provides more context for terms such as: medical image, signal, signal acquisition system, pattern, medical information about a patient.

• Explains Criterion 3 citing additional factors such as time-critical-decision-making and providing recommendations versus directives.

• Provides concrete examples of information needed for health care providers (“HCPs”) to independently review the basis for the software function’s recommendations.

Background

FDA regulates any product that meets the definition of a medical device as set out in section 201(h) of the FD&C Act, including software that is intended to provide decision support to HCPs, caregivers, or patients for the diagnosis, mitigation, treatment, or prevention of diseases or other conditions. The 21st Century Cures Act (“Cures Act”), signed into law on December 13, 2016, amended the definition of “device” in the FD&C Act to exclude certain software functions. This exclusion encompasses CDS software that satisfy four criteria, all of which are restated in the Final Guidance.

Simply, the Cures Act amended the FD&C Act by identifying those software functions that do NOT qualify as a medical device. Six years later, we have more clarity from the FDA around its regulation of CDS. But is it enough?

Final Guidance Summary

The FDA will not regulate CDS software functions as medical devices if they meet all four specific criteria of the Cures Act listed below. The Final Guidance provides FDA’s interpretation of how a specific CDS software functionality would meet, or fail to meet, the statutory criteria specified in 520(o)(1)(E). Below are the key elements described in the Final Guidance:

Criterion 1: 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.

This criterion has predominantly remained unchanged from the Draft Guidance. This criterion includes software that uses: (1) a medical image (e.g. CT, x-ray, ultrasound, MRI), (2) signals from in-vitro diagnostics, and (3) patterns or signals from a signal acquisition system (e.g. signal from the body used to create an electrocardiogram waveform). It does not include activity monitors or signal acquisition systems that have always been outside the definition of a device because they are marketed for purposes not identified in the device definition such as a retinal image analysis intended to secure access to a facility.

Criterion 2: 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).

This criterion describes types of data inputs that may be a Non-Device CDS function provided the software also meets the other criteria. This data includes “medical information about a patient” or “other medical information”. The Final Guidance defines “medical information about a patient” as the type of information that is typically 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 type of information exchange can include data from Criterion 1. FDA interprets “other medical information” to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is similarly independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.

Criterion 3: Is intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition.

FDA interprets Criterion 3 to refer to software that provides condition, disease, and/or patient specific recommendations to an HCP to enhance, inform, and/or influence a health care decision but is not intended to replace or direct the HCP’s judgment. Past guidance documents have struggled to articulate the distinction between software functions that support HCP decisionmaking versus software functions that replace or direct the judgment of the HCP via a specific recommended action. This Final Guidance states that supportive HCP decision making includes functions that present recommendations based on an analysis of patient-specific information to an HCP, who may then incorporate this information into their decision-making about the care of a patient, along with other information and factors of which the HCP is aware.

In contrast, FDA considers software that provides a specific preventive, diagnostic, or treatment output or directive or that addresses a time-critical decision as “failing” Criterion 3. The Final Guidance, however, does not further define a “time-critical decision.” This is important because software that gives clinicians options, but in a “time-critical” window, may not meet this criterion.

Importantly, the FDA specifically noted that it considers software functions that provide information that a specific patient “may exhibit signs” of a disease or condition or identifies a risk probability or risk score for a specific disease or condition as providing a specific preventive, diagnostic, or treatment output. Therefore, such software functions would not satisfy Criterion 3 and are considered medical devices subject to FDA’s regulatory authority

Criterion 4: Is 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.

This criterion requires that HCPs be able to independently review and verify the basis for the software’s recommendations. For the first time, FDA provides specific examples of what information may be required to allow HCPs to independently verify the recommendation. Primarily FDA recommends that:

• The software or labeling include the purpose or intended use of the product, including the intended HCP user and intended patient population.

• The software or labeling identify the required medical information to be input with plain language on how the inputs should be obtained, their relevance, and data quality requirements.

• The software or labeling should provide a plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation. This may include the summary of the logic or methods relied upon, a description of the data relied upon and the specific patient population, and a description of the results from clinical studies conducted to validate the algorithm/recommendation so an HCP can assess potential performance and limitations of the software.

• The software output provides the HCP user with relevant patient-specific information and other knowns/unknowns for consideration.

FDA provides several pages of examples of software functions that fail the four listed criterion and are, therefore, products that qualify as medical devices. Many of these examples are new additions from the Draft Guidance and will require careful review.

Closing Thoughts

• Many software products under FDA’s enforcement discretion under the Draft Guidance, and thus not regulated by FDA, may now be subject to FDA oversight. By eliminating the risk-based analysis from the Draft Guidance, many of the “grey area” devices that were not subject to FDA oversight via enforcement discretion are now subject to FDA’s medical device requirements.

• FDA has scheduled a webinar on October 18, 2022, for interested stakeholders to discuss the Final Guidance and to answer any questions.