Is Your Clinical Decision Support Software a Medical Device? Final Guidance Details FDA’s Latest Thinking

On September 28, 2022, the U.S. Food and Drug Administration (“FDA”) issued its long-awaited final guidance on Clinical Decision Support (“CDS”) software (the “CDS Final Guidance”), significantly amending the interpretive framework for CDS software regulation it had proposed in a revised draft guidance issued on September 27, 2019. In parallel, FDA issued a revised final version of its Policy for Device Software Functions and Mobile Medical Applications to align with the changes introduced in the CDS Final Guidance¹.

The CDS Final Guidance abandons the draft guidance’s proposed adoption of the risk-based categorization scheme for software as a medical device from the International Medical Device Regulators Forum (“IMDRF”), which had been a source of significant confusion.  It also omits discussion of CDS software intended for patients or caregivers and now refers industry to other FDA guidance documents for analysis of patient-directed decision support tools.

Most significantly, the CDS Final Guidance incorporates substantial changes to FDA’s approach to analyzing whether CDS software is excluded from the statutory definition of “device.”  In particular, the CDS Final Guidance introduces new, narrow interpretations of the statutory terms “medical information about a patient” and “other medical information” and asserts for the first time that software providing a “specific preventive, diagnostic or treatment output or directive” or that supports “time-critical decision-making” categorically fails to satisfy the statute’s device exclusion criteria.  These new provisions seemingly broaden the scope of software that FDA considers subject to medical device regulation and will likely prove controversial.

More helpfully for software developers, the final guidance includes specific recommendations on how a CDS software product can disclose the “basis for the recommendations” it presents to health care providers.

This Alert summarizes the statutory background for the CDS Final Guidance, the key changes from the 2019 draft, and the implications for software developers and other stakeholders in the digital health industry.

I. CDS Regulation and the 21st Century Cures Act

FDA has long considered software intended for medical diagnosis or treatment, including CDS software, as meeting the definition of a medical “device” in the Federal Food, Drug, and Cosmetic Act (“FDCA”).  In 2016, Congress narrowed the scope of software potentially subject to FDA regulation by enacting Section 3060 of the 21st Century Cures Act, which amended Section 520(o) of the FDCA to exclude certain medical software functions, including certain CDS software, from the definition of a device. Pursuant to Section 520(o)(1)(E) of the FDCA, CDS software is excluded from the definition of a device if it meets all four of the following criteria:

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 (Criterion 1);
2. Is intended to display, analyze, or print medical information about a patient or other medical information, like clinical practice guidelines (Criterion 2);
3. Is intended to support or provide recommendations to an HCP about prevention, diagnosis, or treatment of a disease or condition (Criterion 3); and
4. Is intended to enable HCPs to independently review the basis for the software’s recommendations so HCPs do not primarily rely on the recommendations when making a clinical diagnosis or treatment decision (Criterion 4).

II. Key Elements of the CDS Final Guidance

A. Interpretation of Device Exclusion Criteria

The CDS Final Guidance focuses on explaining how FDA interprets the statutory criteria that exclude a software product from the definition of a medical device, which FDA has termed “Non-Device CDS.”  We summarize below key elements of the analysis of software under the CDS Final Guidance and changes from the 2019 draft guidance.

Criterion 1: FDA’s interpretation of Criterion 1 in the CDS Final Guidance is largely consistent with its approach in the 2019 draft guidance.  Any software that uses a medical image (e.g., CT, MRI, or X-ray image), a signal from an in vitro diagnostic (“IVD”) as an input, or a pattern/signal from a signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose (e.g., an electrocardiogram) would fail Criterion 1 and therefore be classified as a device. The most significant updates to the guidance addressing this criterion are the addition of a definition of the term “pattern” (defined as multiple, sequential, or repeated measurements of a signal or from a signal acquisition system) and inclusion of some additional examples.

Criterion 2: The CDS Final Guidance includes significant changes to FDA’s interpretation of this criterion.  As an initial matter, FDA explains that Criteria 1 and 2, taken together, describe the types of data inputs used in device CDS (Criterion 1) and non-device CDS (Criterion 2). Software that fails on Criterion 1 (i.e., is intended to acquire, process, or analyze a medical image or a signal) would necessarily fail on Criterion 2.

FDA explains that “medical information about a patient” refers to the type of information typically communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision, meaning the relevance of the information to the decision-making is “well understood and accepted.” FDA interprets “other medical information” to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.

Notably, FDA’s narrow interpretation of medical information in Criterion 2 would exclude potentially relevant information that is not yet “well understood and accepted,” limiting the type of inputs that can be used by non-device CDS software functions. The statute contains no such limitation on what constitutes “medical information,” and while adopting some parameters—e.g., that the information be truthful, non-misleading, and clinically relevant—would no doubt protect patients, FDA’s interpretation is arguably inconsistent with a common-sense, plain meaning interpretation of the statutory language and therefore narrower than what Congress intended.

Criterion 3: For the third criterion, FDA abandoned the IMDRF framework from its 2019 CDS draft guidance and the key principle that software could be classified on the basis of whether it “drives” or “informs” clinical management. FDA adopts a new interpretation in the Final Guidance, asserting that software must satisfy the following four conditions to qualify as non-device CDS:

1. It provides condition-, disease-, and/or patient-specific information and options to an HCP to enhance, inform and/or influence a health care decision;
2. It does not provide a specific preventive, diagnostic, or treatment output or directive;
3. It is not intended to support time-critical decision-making; and
4. It is not intended to replace or direct the HCP’s judgment.

The exclusion of CDS that provides a “specific” output or that supports time-critical decision-making, in particular, is new and seemingly could narrow the scope of CDS that FDA does not consider to be a medical device.  For example, based on the principle that software providing a “specific” output does not satisfy Criterion 3, FDA asserts that software that provides 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 would fail under the third criterion. Under the 2019 draft guidance, however, such functionality could have qualified—depending on the circumstances—as either non-device CDS or CDS subject to FDA enforcement discretion.

FDA’s rationale for these new conditions turns on the concept of automation bias (i.e., the tendency for over-reliance on an automated system). According to FDA, automation bias is more likely to occur if the software provides a single, specific output rather than a list of options or complete information for the HCP’s consideration. Similarly, time-critical decision-making results in automation bias because the user does not have sufficient time to adequately consider other information. Therefore, the greater the software automation and time-critical nature of the decision-making, the more likely the HCP will be to accept the identified software output as the best course of action and less likely to seek additional information to inform decision-making.

While FDA’s new interpretation of Criterion 3 may be something of an improvement on the IMDRF’s ambiguous “inform/drive” distinction previously advanced by the agency, we anticipate that the changes to FDA’s interpretation of Criterion 3 will be controversial.  The statutory reference to software that “supports or provides recommendations” to HCPs is subject to differing interpretations, and it is unclear why CDS software output that provides a risk score for a specific disease to support an HCP’s decision-making, for example, should not fit this criterion.  FDA’s new position has the potential to result in more software being subject to FDA’s jurisdiction. We expect the changes may prompt many companies currently developing or marketing CDS under the rationale that it is not a device or subject to enforcement discretion to reassess their software under the revised CDS Final Guidance.

Criterion 4: In response to comments on the 2019 draft guidance raising questions about the type of information needed to satisfy the transparency requirement in Criterion 4, the CDS Final Guidance includes several tangible recommendations on satisfying this criterion. In particular, FDA recommends that software or labeling do the following:

1. Include the purpose or intended use of the product, including the intended HCP user and patient population;
2. Identify the required medical inputs with plain language instructions on how the inputs should be obtained, their relevance, and data quality requirements;
3. Provide a plain language description of the underlying algorithm development and validation that forms the basis for CDS implementation, which would include a summary of the logic or methods used, the underlying data relied upon, and the results from clinical studies used to validate the algorithm/recommendations; and
4. Provide, in the software output, patient-specific information and other knowns/unknowns, such as corrupted or missing data, to enable the HCP to independently review the basis for the recommendations and apply their own judgment.

In another new addition to the CDS Final Guidance, FDA opines that in some cases, usability testing may be necessary to determine whether implementation of CDS software meets the fourth criterion.  Overall, while the CDS Final Guidance provides additional clarity on what FDA considers to satisfy Criterion 4, FDA’s recommendations are likely to be burdensome to implement.  Companies currently marketing CDS that wish to follow FDA’s guidance may need to make substantial updates to the information shared by the software and associated labeling.

B. Narrowed Focus on Software Intended for HCPs

The CDS Final Guidance streamlines the 2019 draft guidance by focusing its scope on CDS intended for HCPs, eliminating the discussion of patient/caregiver-directed CDS that existed in the previous guidance. These patient/caregiver-directed tools are also referred to as patient decision support (“PDS”). Instead, PDS must be analyzed under FDA’s other digital health policies, including FDA’s Policy for Device Software Functions and Mobile Medical Applications; Software as a Medical Device (SaMD): Clinical Evaluation; Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communication Devices; and General Wellness: Policy for Low Risk Devices. FDA noted that it would update these existing policies as appropriate with additional examples as CDS for non-HCPs continues to evolve.

C. Additional Examples of Device and Non-Device CDS

Following a discussion of the four criteria, the Final CDS Guidance offers specific examples to help developers understand and apply FDA’s guidance, including new examples geared specifically toward clarifying FDA’s interpretation of the fourth criterion. Additionally, FDA provides over 30 examples of device software functions for which FDA intends to exercise regulatory oversight, many of which are new additions from the draft guidance. For example, FDA states that a software function that analyzes glucose measurements from a continuous glucose monitor every 30 minutes and notifies the patient’s HCP of potential hypoglycemia is a device function because it analyzes a pattern (failing Criterion 1), is not intended to display, analyze, or print medical information (failing Criterion 2), and provides a specific diagnostic output and supports time-critical decision-making (failing Criterion 3).

Another example FDA provides of device CDS is software that identifies patients with a possible diagnosis of opioid addiction based on analysis of patient-specific medical information, family history, prescription patterns, and geographical data. According to FDA, this example does not meet Criterion 3 because it provides a specific diagnostic or treatment output or directive.  This example is notable because FDA included the same example in its 2019 Draft Guidance with the added context that the algorithm inputs are not explained, and FDA categorized it as device CDS only because it failed on transparency Criterion 4. This example underscores the narrowing of software functions that qualify as non-device CDS under Criterion 3 in the CDS Final Guidance.

III. Implications for Software Developers and Other Digital Health Stakeholders

Overall, FDA’s CDS Final Guidance represents a substantial change from the 2019 draft guidance and likely a meaningful expansion of software functions FDA considers to fall within its regulatory jurisdiction. Several of the changes will likely come as a surprise to industry and other stakeholders and raise the question why such a substantial revision was not issued as another revised draft guidance for public comment.

Further, FDA’s approach in the CDS Final Guidance could stifle innovation and investment in novel CDS tools, in tension with 21st Century Cures Act’s goal of encouraging the development of new and beneficial digital health technologies. We expect that the guidance will be controversial and that industry will seek to challenge aspects of FDA’s policy, including, in particular, FDA’s arguably extrastatutory narrowing of Criterion 3.  Likewise, given the goals of the 21st Century Cures Act, FDA may also receive questions from Congress about the positions taken in the CDS Final Guidance.

Ropes & Gray will continue to monitor developments relating to digital health. If you have any questions regarding this Alert, please contact any member of Ropes & Gray’s FDA regulatory practice or your usual Ropes & Gray advisor.