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:

• Clinical Decision Support Software (Final CDS Guidance) (finalizing the 2019 draft (Draft CDS Guidance));
• Policy for Device Software Functions and Mobile Medical Applications (Software Functions and MMA Policy) (superseding the 2019 final version); and
• Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices (MDDS Guidance) (updating the 2019 final version).¹

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.²

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.”³ 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.”⁴ 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.⁵

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.⁶

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).⁷ 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.⁸ 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.”⁹ 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.”¹⁰ 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.”¹¹ FDA included examples of software functions that use patterns such as the following:

• For Next Generation Sequencing (NGS), a fluorescent signal on tagged DNA is processed by modification or transformation into base pairs and sequences. Genetic sequences, including datasets of sequence variants that differ from reference sequences and datasets, are filtered to represent disease-associated variations (such as variant call format files or VCFs); and
• For continuous glucose monitors (CGM), a photometric or electrochemical signal generated by an assay and instrument is processed to generate repeated glucose measurements over time, which is considered a pattern.

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.”¹² 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.”¹³ 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:

• “medical information about a patient” means “the type of 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.”
• “other medical information” means “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.”

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.¹⁴ 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.¹⁵ Further, a “more continuous sampling of the same information (e.g., continuous glucose monitor readings) is a pattern/signal.”¹⁶

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.”¹⁷ 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.”¹⁸

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

• Provides condition-, disease-, and/or patient-specific information and options to an HCP to enhance, inform and/or influence a health care decision;
• Does not provide a specific preventative, diagnostic, or treatment output or directive;
• Is not intended to support time-critical decision-making; and
• Is not intended to replace or direct the HCP’s judgment.

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.¹⁹ 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):

• 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 input medical information, with plain language instructions on how the inputs should be obtained, their relevance and data quality requirements.
• The software or labeling provide 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 (e.g., meta-analysis of clinical studies);
  • A description of the data relied upon so that an HCP can assess whether the data is representative of their patient population and assess if best practices were followed; and
  • A description of the results from clinical studies conducted to validate the algorithm/recommendations.
• The software output provides the HCP user with relevant patient-specific information and other knowns/unknowns for consideration (e.g., missing, corrupted or unexpected input data values) that will enable the HCP to independently review the basis for the recommendations and apply their judgment when making the final decision.

FDA emphasizes that information provided to HCPs should: (1) be based on inputs that do not omit material information; (2) describe the quality and robustness of the datasets or clinical studies; and (3) describe how the logic was applied to a specific patient (e.g., matching of patient-level data to criteria in practice guidelines). FDA notes that its recommendations are based on experience evaluating CDS and software functions that are non-device CDS, but that sponsors may use alternative approaches to provide information as long as it enables HCPs to independently review the basis for software recommendations. Perhaps providing a roadmap to how developers of more complex tools may document that their CDS meets Criterion 4, FDA notes that, in some cases, “developers may need to perform usability testing to evaluate if their implementation meets Criterion 4.”²⁰ Consistent with this read, in the October 18 Webinar, FDA emphasized that the Final CDS Guidance more clearly than ever before makes clear that even the most complex machine learning technologies can meet the Cures Act criteria for exclusion from the device definition, and that the Final CDS Guidance provides a roadmap for developers to potentially market such products as non-device CDS.

Changes to the Software Functions and MMA Policy and MDDS Guidance

FDA revised the 2019 Software Functions and MMA Policy, which clarifies the types of software functions, including mobile medical application software functions, that FDA intends to actively regulate to ensure consistency with the Final CDS Guidance as well as to last year’s final rule, entitled “Medical Devices; Medical Device Classification Regulations To Conform to Medical Software Provisions in the 21st Century Cures Act” (Device Classification Final Rule),²¹ which amended certain FDA device classification regulations to conform to the statutory changes implemented in the Cures Act (e.g., removing statutorily exempt software functions from the classification regulations). The three categories of software functions that constitute device functions FDA intends to actively regulate remain the same. Notably, consistent with the Final CDS Guidance, the Software Functions and MMA Policy now explicitly states that software functions performing patient-specific analyses and providing patient-specific recommendations to users that are not HCPs are devices and revised examples of CDS software functions that are not devices to explicitly include certain non-device CDS criteria (e.g., enabling the HCP to independently review the basis for the information).

FDA also revised the 2019 MDDS Guidance to ensure consistency with the Device Classification Final Rule, as well as implement minor changes addressing comments submitted to the docket. FDA’s policy for, and definitions of, non-device medical device data systems (MDDS) and device MDDS largely remain unchanged.

Considerations for Industry

Collectively, the Final CDS Guidance and Software Functions and MMA Policy represent FDA’s evolving approach to regulating and overseeing CDS software functions based on the Cures Act exemptions and FDA’s recent experience reviewing CDS software functions. The following are important considerations for industry based on FDA’s updated guidance documents:

• FDA placed increased emphasis and clarity on ensuring that CDS software and non-device CDS rely on peer-reviewed and published clinical studies and clinical practice or treatment guidelines. This puts additional pressure on companies to ensure that such guidelines are trustworthy²² and cannot be challenged by FDA or other regulators as unduly biased towards particular outputs, such as recommendations supporting diagnostics, therapeutics or other interventions based on financial sponsorship.²³
• FDA’s revised guidance clarifies that industry should evaluate Criterion 1 and 2 together because if a software function fails Criterion 1, then evaluation of Criterion 2 is unnecessary. But FDA clarifies that even if a software function meets Criterion 1, it could fail Criterion 2 if the software function goes beyond displaying, analyzing or printing medical information, which could include a software function that uses a signal or pattern input (e.g., electrocardiogram, NGS or CAD).
• FDA’s revisions to Criterion 3 may be of particular interest to pharmaceutical manufacturers because FDA clarified that software functions will fail this criterion if they provide: (1) a specific preventative diagnostic, or treatment output or direction; or (2) recommendations “in time-critical decision-making.” FDA clarified that a software function that provides lists of preventive, diagnostic or treatment options—including “prioritized lists” based on independent clinical guidelines—would meet Criterion 3 as long as they are not intended to support time-critical decision-making and/or replace or direct the HCP’s judgment. These updates, including FDA’s concern about software functions that introduce automation bias towards a specific treatment or diagnosis, could be important for pharmaceutical manufacturers to consider given recent scrutiny of manufacturer-sponsored or influenced EHRs, CDS or order sets that make preventative treatment or diagnosis recommendations.
• FDA’s updates to Criterion 4 are instructive for industry to assess and revise software function labeling and instructions, particularly to ensure software functions are transparent and provide plain language description of underling algorithm development and validation (e.g., logic, data, clinical study results, etc.). Developers should evaluate this section of FDA’s updated guidance to incorporate applicable recommendations into internal promotional review committee procedures and review standards. Developers should also assess any CDS-related digital or social media marketing activities where space or digital formatting constraints could pose challenges (e.g., inability to provide adequate context or substantiation for social media posts about CDS software functions or non-device CDS).
• Finally, as noted above, in issuing the Final CDS Guidance, FDA did not include the enforcement discretion policy for low risk device CDS intended for patients nor the policy for low risk device CDS intended for HCPs. Consequently, companies marketing such software functions in reliance on the enforcement discretion policies described in the Draft CDS Guidance should evaluate whether the Final CDS Guidance alters the regulatory status of their products or whether enforcement discretion policies described in other FDA digital health guidances could apply. For some companies, a strategic “presubmission meeting” or other engagement with FDA may be prudent.

© Arnold & Porter Kaye Scholer LLP 2022 All Rights Reserved. This Advisory is intended to be a general summary of the law and does not constitute legal advice. You should consult with counsel to determine applicable legal requirements in a specific fact situation.