FDA Releases Significantly Revised Final Clinical Decision Support Software Guidance and Related Changes

On September 28, 2022, the US Food and Drug Administration (FDA or Agency) released a string of long-awaited revised and finalized guidance documents addressing various digital health topics which are intended to fulfill 21st Century Cures Act (Cures Act) requirements. Specifically, FDA issued the following revised and finalized guidance documents:

Overall, FDA has narrowed the scope of FDA enforcement discretion for patient-focused decision support software (meaning, FDA appears to have shifted more of the onus to developers to engage with the Agency, rather than giving guidance on criteria which could exempt their products from review or approval). FDA also provides clearer examples of the types of software functions which are subject to regulation as medical devices. 2

This Advisory provides a summary of the major updates and revisions outlined by FDA in the guidance documents and concludes with potential considerations for industry.

Changes to the Clinical Decision Support Software Guidance

Narrowing of Enforcement Discretion Policies

Significantly, the Final CDS Guidance no longer includes an enforcement discretion policy for any patient or caregiver device clinical decision support (CDS) functions; the scope of the Final CDS Guidance applies only to CDS software “intended for health care professionals (HCPs) as devices.” 3 Although FDA has long maintained that the Cures Act exemption for non-device CDS software functions is limited to CDS functions intended for HCPs, the Draft CDS Guidance described an enforcement discretion policy for certain low-risk device CDS functions for patients and caregivers and provided examples of such patient CDS falling within the scope of the policy. In removing the prior references to CDS for patients or caregivers, FDA noted that software functions “that support or provide recommendations to patients or caregivers—not HCPs—meet the definition of a device.” 4 Rather than addressing them within the Final CDS Guidance, FDA explained that FDA’s other “digital health policies [will] continue to apply to software functions that meet the definition of device, including those that are intended for use by patients or caregivers,” referring to FDA’s Software Functions and MMA Policy, Software as Medical Device (SaMD) Guidance, MDDS Guidance, and General Wellness Guidance. 5

The policy implications of this editorial choice could be significant, as many developers understood the Draft CDS Guidance as articulating the boundaries of a permissible patient-directed CDS software in terms that are specific to the particulars of software functions, as opposed to other enforcement direction patient or caregiver device types set forth in the General Wellness Guidance or the Software Functions and MMA Policy. We assume FDA will take the position that the enforcement discretion policy present in the Draft CDS Guidance did not create or confer any benefits on product developers, and that FDA’s removal of the discussion of enforcement discretion for low risk, physician judgment-informing CDS functions does not signal a change in enforcement posture. However, developers of low risk patient CDS software tools who relied in good faith on the draft position may now face heightened FDA scrutiny. Absent additional FDA clarification (perhaps in forthcoming teleconferences to “roll out” the final guidances or potential updates to the 2019 General Wellness Guidance), it is hard to conclude otherwise.

Further, FDA has removed reference to an enforcement discretion policy for low risk device CDS functions intended for HCPs. As proposed in the Draft CDS Guidance, this policy would have applied to certain CDS functions for HCPs that meet the statutory definition of a “device” (because they fail to meet certain of the Cures Act criteria for an exempt CDS function) but that FDA viewed as posing a low risk to users (e.g., software functions intended to inform an HCP’s management of a non-serious disease or condition even if the HCP is not able to independently evaluate the basis for the recommendation). This change could be a policy reaction to concerns about the accuracy and performance of CDS systems integrated into physician electronic health record (EHR) systems. 6

It is important to note that FDA has not ended its enforcement discretion policy for low risk device CDS software functions altogether—the boundaries of the policy have just become more nebulous. For example, FDA notes that “some decision support software functions may be identified in other guidance documents as software functions . . . [that] FDA does not intend at this time to enforce compliance with applicable device requirements” (e.g., premarket clearance or approval). 7 In other words, the Final CDS Guidance itself is not the sole policy for industry to address whether software functions are devices, subject to enforcement discretion or statutorily exempt. As such, the Final CDS Guidance focuses primarily on describing “CDS software functions that do not meet the device definition (Non-Device CDS)” based on the four Cures Act criteria. 8 Developers must carefully read all three guidance documents together to determine whether there is a reasonable basis to market their products without FDA registration, review and/or approval.

In an October 18, 2022 webinar discussing the Final CDS Guidance (“October 18 Webinar”), FDA officials confirmed that the Final CDS Guidance does not include any enforcement discretion policies described in the Draft Guidance, noting that the focus of the Final CDS Guidance is on statutory criteria for non-device CDS. FDA explained that while software that provides recommendations to patients or caregivers remains in the definition of a device, enforcement discretion polices in other FDA guidances could apply to certain device CDS functions. For example, the Agency suggested that certain CDS software tools could fall within the enforcement discretion policy for software functions that “help patients (i.e., users) self-manage their disease or conditions without providing specific treatment or treatment suggestions” (in the Software Functions and MMA Policy). Unfortunately, the question-and-answer portion of the webinar did little to clarify the ambiguity around enforcement discretion. Notwithstanding the deletion of the patient CDS enforcement discretion discussion, the Agency suggested that there are no products that previously were not devices which now become devices due to the Final CDS Guidance. FDA also stated that some firms may elect to revise their products to fit within the non-device CDS definition, while others may elect to work with the Agency to pursue marketing their products as devices. As in the Final CDS Guidance, FDA emphasized the value of developers engaging with the Agency to get feedback on product regulatory status. Thus, the webinar discussion further suggests that developers marketing products solely in reliance on the language in the prior Draft Guidance enforcement policy could now face regulatory scrutiny.

Modest But Helpful Expansion of the Definition of “Health Care Professional”

In both the Final CDS Guidance and revised Software Functions and MMA Policy, FDA has broadened its view of what constitutes an HCP to “an individual who is licensed, registered, or certified by a State, territory, or other governing body, to administer health care, including but not limited to, nurse practitioner, registered nurse, licensed practical nurse, clinical social worker, dentist, occupational therapist, pharmacist, physical therapist, physician, physician assistant, psychologist, respiratory therapist, speech-language pathologist, technologist, or any other practitioner or allied health professional.” 9 Given that the enforcement discretion policy for “direct-to-consumer” (DTC) CDS products is no longer clear, the broadening of the scope of the HCP definition is potentially helpful to developers who may have felt that the prior definition excluded many potential product users, defaulting them to the DTC category. For example, many CDS tools stand to benefit providers who may not have formal medical school training but are on the “front lines” of patient management.

Additional Examples, Clearer Analysis

Finally, the Final CDS Guidance provides additional definitions, analyses and examples of how FDA intends to apply the four Cures Act criteria for assessing whether a proposed CDS software function is exempt from the device definition. Perhaps most notably, the Final CDS Guidance provides more clarity around the end-user transparency element (Criterion 4), which often is the most difficult of the four mandatory exemption criteria for medical software developers to meet—particularly those using proprietary datasets, algorithms or artificial intelligence-driven analysis tools. Also of note are the Final CDS Guidance’s Criterion 3 clarifications that a non-device CDS software function’s outputs or recommendations should not be directive or specific to a particular treatment or diagnosis. FDA released a decision tree graphic to accompany the Final CDS Guidance that summarizes the four criteria and their application.

Discussion of Changes to FDA’s Interpretation of Each Cures Act Criteria

Criterion 1

FDA explains that when a software function is intended to acquire the type of data in Criterion 1 (e.g., medical image or signal from an in vitro diagnostic (IVD) or a pattern/signal from a signal acquisition system) for “use[] as an input, then the software function remains a device,” which FDA says it has “regulated . . . for many years.” 10 FDA clarifies that the term “medical image” includes both images generated by medical imaging systems for a medical purpose (e.g., computed tomography or magnetic resonance imaging), as well as images “not originally acquired for a medical purpose,” but that are “processed or analyzed for a medical purpose.”

While FDA’s definition of “signal” remains unchanged, FDA added the definition of “pattern” to mean the “multiple, sequential or repeated measurements of a signal or from a signal acquisition system.” 11 FDA included examples of software functions that use patterns such as the following:

FDA considers software functions to be devices when the software function “assess[es] or interpret[s] the clinical implications or clinical relevance of a signal, pattern or medical image.” 12 For example, 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, would not meet Criterion 1.

Criterion 2

FDA explains that, if a software function only uses Criterion 2 data (i.e., medical information) as an input, the software function “is not a device . . . so long as it meets the other three criteria.” 13 FDA clarified that Criterion 2 describes the types of data inputs used in non-device CDS: (1) “medical information about a patient” and (2) “other medical information.” FDA added definitions to these terms as follows:

In addition to these new definitions, the Final CDS Guidance explains that industry should consider “[s]ampling frequency” when determining if given information is considered “medical information” under Criterion 1 or a signal/pattern under Criterion 2. 14 For example, a “single, discrete test or measurement result that is clinically meaningful (e.g., a blood glucose lab test result) is medical information” while a report from a radiology study or summary information about the output of a legally marketed computer-aided diagnostic (CAD) software is not. 15 Further, a “more continuous sampling of the same information (e.g., continuous glucose monitor readings) is a pattern/signal.” 16

Criterion 3

FDA clarifies that it 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.” 17 Conversely, FDA explains that software functions that: (1) provide a “specific preventative, diagnostic or treatment output or direction” or (2) provide recommendations “in time-critical decision-making” fail Criterion 3 because such functions are not intended for the purpose of “supporting or providing recommendations.” The specificity of the direction or limited time interval may, according to FDA, make the user of the software more susceptible to “automation bias,” i.e., accepting the identified output as the best course of action without seeking any additional information to confirm that output because of limited time or the perceived strength of the recommendation. In addition to automation bias, FDA identifies the time-critical nature of the HCP decision-making as a factor to take into consideration when evaluating Criterion 3. FDA explains that time-critical decisions that require “urgent action” increase automation bias because there “is not sufficient time for the user to adequately consider other information,” including for an HCP to “independently review the basis for the recommendation.” 18

Based on these factors, FDA clarifies that Criterion 3 describes software that:

Significantly, FDA explains 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 of a specific disease or condition” would fail Criterion 3. 19 Despite the Final CDS Guidance suggesting FDA views a software function that generates a disease-specific risk score as not meeting the Cures Act criteria for a non-device CDS, in the October 18 Webinar, FDA noted that certain CDS that generate risk scores could fall within enforcement discretion policies described in other FDA digital health guidances. Specifically, the Agency referred to the enforcement discretion policy in the Software Functions and MMA Policy for software functions that perform simple calculations routinely used in clinical practice.

Criterion 4

The Final CDS Guidance provides additional clarity on how to satisfy Criterion 4’s requirement to enable HCPs to independently review the basis for the recommendations in a software function. Specifically, FDA provides the following recommendation for satisfying Criterion 4 (although the Agency acknowledges that sponsors may also use alternative approaches):