FDA’s Final Clinical Decision Support Guidance: The Good News and the (Really) Bad News

On September 28, 2022, the U.S. Food & Drug Administration (“FDA” or the “Agency”) published the long-awaited final guidance, “Clinical Decision Support Software” (the “Final CDS Guidance”).¹See generally U.S. Food & Drug Admin., Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff (Sept. 2022) (hereinafter “Final CDS Guidance”).  The Final CDS Guidance supersedes the most recent draft guidance on the same topic that FDA issued in September 2019 (the “Draft CDS Guidance”).²See generally U.S. Food & Drug Admin., Clinical Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff (Sept. 2019) (hereinafter “Draft CDS Guidance”); U.S. Food & Drug Admin., Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff (Dec. 2017).  The final guidance provides FDA’s most current thinking on the types of software functions that are (1) Non-Device CDS software functions, which are not subject to FDA jurisdiction, versus (2) device software functions, which are.  The bottom line is that the CDS Final Guidance brings with it some good news and some bad news – but the bad news is pretty bad. 

First, the good news.  We were delighted to see FDA back away from its confusing attempt to mash-up the risk framework in the International Medical Device Regulators Forum (“IMDRF”) framework with the U.S. law that governs devices – namely, the device provisions in the Food, Drug, and Cosmetic Act (“FDCA”) and FDA’s regulations.  In our view, the previous mash-up was a misfit – a square peg being forced into a round hole.  In addition, as discussed in more detail below, the Final CDS Guidance clarifies some issues that were previously unclear, for example, whether CDS software that provides a risk probability or risk score for a certain disease or condition is Non-Device CDS or a device software function.  According to the Final CDS Guidance, it is a device software function (but see discussion in Section I, below).  The Final CDS Guidance is also more internally consistent than the Draft CDS Guidance, and the examples in the final guidance are more illustrative and intellectually rigorous.  For instance, the examples of device software functions, in the final version of the guidance, clearly explain which specific factors of the 4-factor Non-Device CDS test (in Section 520(o)(1)(E) of the FDCA) are not met – for each hypothetical product.

Now, the (really) bad news.  The Final CDS Guidance makes clear that FDA believes that it has jurisdiction over CDS software that – based on a plain language read of the statute – is carved out of the definition of “device” by Section 520(o)(1)(E) of the FDCA.  In other words, FDA clearly intends to regulate software that Congress explicitly removed from FDA’s jurisdiction.  In our view, the Draft CDS Guidance had similar issues, but the Final CDS Guidance makes the problem worse – in a manner that disincentivizes innovation.  We believe the two largest transgressions are as follows:

(1) The Final CDS Guidance Adds Conditions to the Third Factor of the 4-Factor Non-Device CDS Test That Are Found Nowhere in the Statutory Language. The third factor of the statutory test is whether the software at issue 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.”³21 U.S.C. § 360j(o)(1)(E)(ii).

As described below, the Final CDS Guidance suggests that FDA considers this factor to be met only if the following four sub-factors are met:  (a) the software provides a health care professional (“HCP”) with condition-, disease-, and/or patient-specific recommendations that enhance, inform, and/or influence health care decision-making; (b) the software does not provide a specific preventive, diagnostic, or treatment output or directive; (c) the software is not intended to support time-critical decision-making; and (d) the software is not intended to substitute, replace, or direct the HCP’s judgment.  The guidance also makes clear that software that provides a risk probability or risk score related to an individual’s propensity to have a disease or condition, will fail subfactor (b).  

The practical consequences of these sub-factors are that software will fail the third factor of the test if it (among other things): (a) provides a risk probability or risk score related to an individual’s propensity to have a disease or condition; (b) provides a recommendation that is time-critical; or (c) provides one recommended option, rather than more than one.⁴See Final CDS Guidance, at 11–12.  This result confirms that FDA’s new sub-factors are not consistent with the statutory language.  The statutory text is clear that the third factor of the test is met if the software simply “support[s]” or “provide[s]” “recommendations” to an HCP about the prevention, diagnosis, or treatment of a disease or condition.

We thought that the Draft CDS Guidance was aggressive on this issue (and crossed the line), in that it sought to split hairs by distinguishing recommendations that “inform” HCP decision-making and recommendations that “drive” HCP decision-making.⁵See generally Draft CDS Guidance.  The statutory language makes no such distinction, either.  But the Final CDS Guidance is worse in that it essentially retains the “inform” versus “drive” distinction (although the distinction now appears to be between “inform” and “direct”), and it adds extra-statutory conditions into the analysis.

(2) The Final CDS Guidance Could Be Interpreted as Giving the Second Factor of the 4-Factor Non-Device CDS Test Teeth That Are Found Nowhere in the Statutory Language. The second factor of the statutory test is whether the software at issue 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).”⁶21 U.S.C. § 360j(o)(1)(E)(i).

Importantly, in the Draft CDS Guidance, the second factor did not typically create hurdles or issues.  As a general matter, most software that would be worthy of an analysis under the Non-Device CDS test in Section 520(o)(1)(E) of the FDCA would display or analyze medical information.  But FDA, in its Final CDS Guidance, may be introducing hurdles that are not found in the statutory language.

In the Final CDS Guidance, FDA interprets the term “medical information about a patient” to refer only to information that is well-understood and accepted as being relevant to clinical decision-making.⁷Final CDS Guidance, at 9–10.  On the one hand, this interpretation could suggest that software that displays patient-specific medical information based on proprietary algorithms fails this prong.  But on the other, FDA’s definition of “other medical information” could be read to encompass such patient-specific recommendations output from a proprietary algorithm.  This ambiguity, and worries of disadvantageous FDA interpretation, could stymie innovation – which is the opposite of what Congress intended in 2016, when it exempted certain types of software from regulation as a device, as part of the 21^st Century Cures Act.

FDA’s approach in its Final CDS Guidance is so different from its approach in the draft guidance, that the final does not appear to be a logical outgrowth of the draft.  Thus, it is surprising that the Agency decided to issue this as a “final” guidance, rather than as another revised draft. 

But, more fundamentally, we are troubled that the final guidance goes well beyond the language of the statute, and that it effectively establishes new rules.  We believe that there are good arguments for a challenge under the Administrative Procedure Act (“APA”).  We hope that industry will consider doing just that, and we note that King & Spalding has been successful in these types of lawsuits previously.

Section I, below, provides a summary of the Final CDS Guidance, and Section II summarizes the key takeaways.

I. Summary of the Final CDS Guidance

Section 520(o)(1)(E) of the FDCA carves out certain types of CDS software from the FDCA’s definition of “device” in Section 201(h) of the FDCA.⁸21 U.S.C. § 321(h).  FDA refers to a software function that meets the 4-factor test below (such that it is not encompassed by the FDCA’s definition of “device,” and therefore, not subject to FDA’s jurisdiction) as Non-Device CDS software.  A software function that fails any one of the factors in the 4-factor test below (and meets the definition of “device” in Section 201(h)), however, is subject to FDA’s jurisdiction (unless it falls within another statutory exemption).  FDA refers to those software functions as device software functions.

The four factors of the Non-Device CDS test are as follows:

(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;⁹See id. § 360j(o)(1)(E).

(2) Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information;¹⁰See id. § 360j(o)(1)(E)(i).

(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;¹¹See id. § 360j(o)(1)(E)(ii). and

(4) 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.¹²See id. § 360j(o)(1)(E)(iii).

FDA’s current thinking on each of these factors, based on the Final CDS Guidance, is briefly summarized below. 

Factor (or Criterion) 1

FDA explains that CDS software functions may meet Factor 1 if they do not:  (a) use a medical image, a signal from an IVD, or a pattern or signal from a signal acquisition system as a type of data input to acquire, process, or analyze; or (b) assess or interpret the clinical implications or clinical relevance of a medical image, signal, or pattern.¹³Final CDS Guidance, at 7–8.  

FDA provides several examples of CDS software functions that fail Factor 1, as follows:

• “Software functions that process or analyze a medical image, such as enhancement, manipulation, making measurements, identifying normal/abnormal structures, determining size/shape/location of a suspected nodule, or functions within computer aided diagnostics (CADx) or computer aided detection (CADe) systems, do not meet [Factor] 1.”
  
  
• “Software functions that process or analyze an ECG waveform or QRS complex, such as measuring repeated complexes, measuring variation from baseline, or detecting heart rate, arrhythmias, or structural abnormalities, do not meet [Factor] 1.”
  
  
• “Software functions that process or analyze the genetic sequence or patterns from an NGS analyzer to identify genetic variants or mutations or their clinical implications or relevance do not meet [Factor] 1.”
  
  
• “Software functions that process or analyze an electrochemical or photometric response generated by an assay and instrument to generate a clinical test result, such as determining a potassium level, do not meet [Factor] 1.”¹⁴Id. at 8.

As a general matter, the examples in the Final CDS Guidance regarding the first factor are much more detailed and illustrative than those in the Draft CDS Guidance.

Factor (or Criterion) 2

In the Final CDS Guidance, FDA provides its interpretations of two terms in the second factor of the test – namely, “medical information about a patient” and “other medical information.”  FDA considers “medical information about a patient” to mean patient-specific 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.”¹⁵Id. at 9.  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.”¹⁶Id.

As discussed above, this section of the guidance could be interpreted to give the second factor of the test teeth found nowhere in the statutory language.  FDA is interpreting the term “medical information about a patient” to refer only to information that is well-understood and accepted as being relevant to clinical decision-making.  This arguably suggests that software that displays patient-specific medical information based on proprietary algorithms fails this prong.  Although there is a reasonable counterargument that such information would fall under the definition of “other medical information,” this ambiguity and the related potential for a more conservative interpretation is likely to stymie innovation – which is the opposite of what Congress intended in 2016, when it carved certain types of software out of the FDCA’s definition of “device,” as part of the 21^st Century Cures Act.¹⁷See 21st Century Cures Act, § 3060(a).  Notably, this interpretation of “medical information about a patient” is wholly new, and it is a significant departure from the Draft CDS Guidance.

Factor (or Criterion) 3

As discussed, software meets the third factor of the test if it 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.”¹⁸ Final CDS Guidance, at 6; see 21 U.S.C. § 360j(o)(1)(E)(ii). FDA considers the third factor of the test to be met only when CDS software functions meet the following, additional conditions:  

(a) the software provides an HCP with condition-, disease-, and/or patient-specific recommendations that enhance, inform, and/or influence health care decision-making;

(b) the software does not provide a specific preventive, diagnostic, or treatment output or directive;

(c) the software is not intended to support time-critical decision-making; and

(d) the software is not intended to substitute, replace, or direct the HCP’s judgment.¹⁹Final CDS Guidance, at 11–12.

Notably, with regard to condition (b), the Final CDS Guidance states that CDS software functions that could meet the third factor include those that provide an HCP with a list of preventive, diagnostic or treatment options (prioritized or not) or a list of next-step options for the HCP’s consideration.²⁰Id. at 12.  However, FDA views “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 as providing a specific preventive, diagnostic, or treatment output,” such that it does not meet condition (b), and therefore does not satisfy the third factor of the Non-Device CDS test.²¹Id. at 12–13 (emphasis added).  

The Draft CDS Guidance was less clear on this issue and arguably inconsistent.  On the one hand, the draft guidance suggested that software intended to “aid in diagnosis by analyzing risk information to help predict risk of a disease or condition as an aid to making a definitive diagnosis” failed the third factor of the test.²²Draft CDS Guidance, at 14.  But, on the other hand, the Draft CDS Guidance contained the following example of Non-Device CDS software versus a Device CDS software – which appears to contradict that principle:

“Machine learning algorithm, for which the logic and inputs are not explained, that identifies hospitalized, type 1 diabetic patients at increased risk of postoperative cardiovascular events. This software is a Device CDS function, because the HCP is not expected to be able to independently evaluate the basis for the software’s recommendations. FDA intends to focus its regulatory oversight on this software, because it is intended to inform clinical management for a critical situation or condition.

Note: If the HCP could evaluate the basis for the software’s recommendations, because the logic and data inputs for the machine learning algorithm and criteria for risk of cardiovascular events were explained and available to the HCP, then this software would be considered Non-Device CDS.”²³Id. at 23.

In any event, despite FDA’s clear opposition to software that explicitly provides a patient-specific “risk probability” or a “risk score” in the Final CDS Guidance, the guidance lists the following examples of Non-Device CDS software functions:

• “Software function that analyzes family history, prior mammogram results, and BRCA1 status from the medical record and recommends that an HCP consider increased mammography frequency or supplemental breast ultrasound for the patient.”²⁴Final CDS Guidance, at 18.
  
  
• “Software function that analyzes a patient’s age, sex, gender, and radiologist’s report for findings of low bone density and micro cervical fractures in order to provide an HCP with a list of follow-up options for consideration, such as performance of periodic bone-densitometry scans, nonpharmacological management (e.g., weight-bearing exercise), or referral of the patient to a specialist.”²⁵Id.

These examples suggest that, under the Final CDS Guidance, software can be Non-Device CDS if it implicitly identifies individuals at high risk for certain conditions and provides a number of follow-up options to the HCP, but software will be regulated as a device if it explicitly identifies an individual as being at high risk for a certain disease by providing a risk probability or a risk score.  This distinction should be duly noted.

Significantly, in the Final CDS Guidance, FDA also expresses concern about “automation bias” – which it describes as the propensity of an HCP to accept a CDS software function’s specific recommendation as the best course of action, without accounting for other available sources of information to inform their decision-making.²⁶Id. at 11–12.  FDA also takes the position that time-critical decision-making also raises risk with respect to CDS software because automation bias may be increased in such situations.²⁷Id. at 11. 

Reading this together, it appears that FDA believes that software fails FDA’s newly created additional conditions (listed at the start of this section) and, consequently, the third statutory factor, if it (among other things):  (a) provides a risk probability or risk score related to an individual’s propensity to have a disease or condition; (b) provides recommendations that are time-critical; or (c) provides one recommended option, rather than more than one.  As discussed, FDA’s additional conditions are not rooted in the statutory language. To the contrary, the statutory text is clear that the third factor of the test is met if the software “support[s]” or “provide[s]” “recommendations” to an HCP about the prevention, diagnosis, or treatment of a disease or condition.²⁸See 21 U.S.C. § 360j(o)(1)(E)(ii).

The Draft CDS Guidance was also aggressive on this issue and sought to split hairs by distinguishing recommendations that “inform” HCP decision-making and recommendations that “drive” HCP decision-making – even though the statutory language makes no such distinction.  But the Final CDS Guidance is worse in that it essentially retains the “inform” versus “drive” distinction (although the distinction now appears to be between “inform” and “direct”), and it adds extra-statutory conditions into the analysis.

Factor (or Criterion) 4

To satisfy the fourth factor, CDS software functions should be designed to permit the HCP to independently review the basis of the software’s recommendations and to use their own judgment to make clinical decisions for individual patients, rather than relying primarily on the CDS software functions’ recommendations.²⁹Final CDS Guidance, at 13.  FDA expects that:  (a) the software output or labeling provide adequate background information in plain language on the input(s), algorithm logic or methods, datasets, and validation; (b) the software output or labeling identify relevant, available, and understandable sources for the intended HCP user; and (c) the recommendation be based on information that could be independently understood by the intended HCP user.³⁰Id. at 14.  FDA adds that patient-specific information could be useful to show how the logic was applied to the patient and ultimately help the HCP understand the basis of the recommendations.³¹Id. at 14–15.  Without elaboration, though, FDA also states that, “[i]n some cases, developers may need to perform usability testing to evaluate if their implementation meets Criterion 4.”³²Id. at 15.

As a general matter, this section of the Final CDS Guidance is much clearer and provides better examples than the Draft CDS Guidance.  However, the labeling disclosures required to satisfy this factor may prove onerous and result in revealing the “secret sauce” of proprietary algorithms underlying CDS software.  In the Final CDS Guidance, FDA gives an example of hypothetical CDS software that provides a list of follow-up options after a patient’s mammogram.  FDA’s hypothetical software does not meet the definition of Non-Device CDS because it fails Factor 4 by not providing “specific details on the independence of the development and validation datasets, such as the distribution of cases from different sites, breast density, ethnicity, or other important factors.”³³Id. at 25. 

On the other hand, FDA provides an example of a hypothetical software function that provides a list of follow-up options for a patient with COPD based on their number of steps walked per day and that would qualify as Non-Device CDS.  This hypothetical software function provides “[a] plain language summary . . . to the HCP describing how the algorithm is analyzing patient age and steps walked to assess activity and any validation studies . . . .”³⁴Id. at 20.  Thus, it is clear that software developers will have to reveal a certain level of detailed information about what is very likely be a proprietary process of developing, training, and using their algorithms.  What level of detail will satisfy FDA remains to be seen.  We expect that this labeling requirement could result in some Non-Device CDS developers feeling that they have no choice but to follow a more burdensome and expensive premarket submission process that would include better protections for their trade secrets and other intellectual property. 

II. Key Takeaways

The key takeaways from the Final CDS Guidance are as follows:

• The Final CDS Guidance adds conditions to the third factor of the Non-Device CDS test that are found nowhere in Section 520(o)(1)(E) of FDCA.
  
  
• The Final CDS Guidance could be interpreted to suggest that the second factor of the 4-factor Non-Device CDS test has teeth that are found nowhere in Section 520(o)(1)(E) of FDCA.
  
  
• The Final CDS Guidance indicates that software that explicitly provides patient-specific risk probability or risk scores for a certain disease or condition fails the third factor of the 4-factor test. But, at the same time, the final guidance includes examples of Non-Device CDS software that implicitly identify specific patients at high risk for a particular disease or condition and provide an HCP with a number of follow-up options.
  
  
• The Final CDS Guidance provides more examples and context as to how to apply Factors 1 and 4 of the 4-factor test, than the Draft CDS Guidance.
  
  
• Complying with FDA’s labeling requirements to satisfy Factor 4 may require firms to reveal details about the training and operation of proprietary algorithms.
  
  
• The Final CDS Guidance inexplicably states that in “some cases” usability testing may be necessary to establish compliance with the fourth factor.

Given that the Final CDS Guidance goes well beyond the language of the statute, and that it effectively establishes new rules, there may be strong arguments for a challenge under the APA.  We hope that industry will consider doing just that, and again, we note that King & Spalding has been successful in these types of lawsuits previously.

*     *     *

King & Spalding LLP regularly counsels digital health, medical device, and pharmaceutical companies on all issues related to digital health products that include software functions.  Please let us know if you have any questions or concerns regarding this final guidance, or if we can be of any assistance in navigating the rapidly changing digital health landscape.