FDA Changes Direction in Final CDS Guidance

FDA Also Issues Report on Software Pre-Cert Pilot, Leaving Unanswered Questions on Future of Software Regulation

Key Points

• The Final Guidance does not address the FDA’s risk-based enforcement discretion policy for CDS functions that may meet the definition of a device, but for which the FDA does not intend to enforce compliance with certain requirements of the FDCA.
• The Final Guidance significantly narrows the agency’s interpretation of the CDS exemption criteria compared to its previous 2019 Draft Guidance, meaning that various types of software functions previously considered eligible to meet the CDS exemption no longer qualify for exemption under this Final Guidance.
• The FDA excludes from the CDS software exemption those software functions that are intended to support time-critical decision-making.

Background

On September 28, 2022, the Food and Drug Administration (FDA) released the final version of its policy on Clinical Decision Support (CDS) software (“Final Guidance”).¹ The FDA previously released a draft version of this policy on September 27, 2019 (“Draft Guidance”), which we wrote about here, following the passage of an exemption for qualifying CDS as part of the 21st Century Cures Act of 2016 (“Cures”), which we summarized here.² This 2019 draft was itself a revision to an earlier draft guidance that FDA published in 2017, which we wrote about here.

CDS Exemption Criteria under 21st Century Cures Act

Under the software exemption in Cures, certain CDS software functions are excluded from the statutory definition of “device” if such function is:

1. Not intended to “acquire, process, or analyze a medical image or a signal from an in vitro diagnostic [IVD] device or a pattern or signal from a signal acquisition system.”
2. Intended for “displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines).”
3. Intended for “supporting or providing recommendations to a health care professional [HCP] about prevention, diagnosis, or treatment of a disease or condition.” and
4. Intended for “enabling such [HCP] to independently review the basis for such recommendations that such software presents so that it is not the intent that such [HCP] rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”³

Key Aspects of the Final Guidance

The Final Guidance significantly departs from the revised Draft Guidance in several important respects. These changes are likely to continue to be dissected, and we expect there will be additional commentary shared with the FDA. We provide below a summary of some of the key highlights of the Final Guidance.

Enforcement Discretion Policy for Device CDS

The Draft Guidance provided the FDA’s interpretation of the criteria for the statutory exemption; it also identified functions that might meet the statutory definition of a device, but for which FDA did not intend to enforce compliance with applicable requirements of the Food, Drug and Cosmetic Act (FDCA). The FDA proposed to adopt a risk-based approach, based on two key factors from the International Medical Device Regulators Forum (IMDRF) Framework for Risk Categorization and Corresponding Considerations relating to software as a medical device (SaMD): (1) the significance of the information provided by software to a health care decision and (2) the state of the patient’s health.⁴ Under this policy, the FDA planned to exercise enforcement discretion for CDS devices that informed clinical management for “non-serious situations or conditions.” These include, for example, software that provides recommendations of potential allergens based on location-specific electronic health records, environmental conditions and patient-reported outcomes to provide a HCP with options for different diagnoses.⁵

The Final Guidance fails to mention this policy of enforcement discretion, leaving unclear whether the FDA continues to take that approach. Moreover, it abandons reference to the IMDRF Framework—it only focuses on clarifying whether CDS functions meet the exemption or not. In doing so, the Final Guidance also offers a much narrower interpretation of the exemption criteria.

Narrower Interpretation of CDS Exemption

Criterion 1 – Signals

The first statutory criterion is framed in the negative: an exempt CDS software function may not “acquire, process, or analyze a medical image or a signal from an [IVD] or a pattern or signal from a signal acquisition system.” The term “signal acquisition system” in particular created confusion, as it was neither defined in Cures nor defined or used elsewhere in the FDCA. In the Final Guidance, the FDA categorizes types of data inputs used in devices as either falling into Criterion 1 (i.e., signal from a signal acquisition system) or Criterion 2 (i.e., medical information) and provides greater granularity of the agency’s interpretation of these terms. If the data described in Criterion 1 (i.e., medical image or signal from an IVD or a pattern/signal from a signal acquisition system) is used as an input, then the software function remains a “device.”⁶

The FDA clarifies that the term “medical image” includes those images generated by use of medical imaging systems (e.g., CT, x-ray, ultrasound, magnetic resonance imaging (MRI)) to view body parts, and images acquired for a medical purpose (e.g., pathology). For the first time, the FDA adds that images that were not originally acquired for a medical purpose, but that are being processed or analyzed for a medical purpose, are considered medical images.⁷

The agency also expands on its interpretation of the term “pattern.” The FDA explains that “pattern” refers to “multiple, sequential, or repeated measurements of a signal or from a signal acquisition system,” such as an electrical signal from the body being processed to create an electrocardiogram (ECG) waveform.⁸

The FDA considers software functions that assess or interpret the clinical implications or clinical relevance of a signal, pattern, or medical image to be software functions that do not meet Criterion 1, meaning that they do not qualify as CDS because they “acquire, process, or analyze.” For example, the FDA reasons that a software function that analyzes the genetic sequence or pattern from a next-generation sequencing (NGS) analyzer to identify genetic variants or mutations or their clinical implications does not meet Criterion 1.⁹ Among other questions raised by the new discussion of Criterion 1 are the conditions under which an exempt CDS may analyze device data that originated from a medical device (including in IVD), as opposed to analyzing a pattern or signal emanating directly from a device potentially in raw waveform or otherwise not converted into a measurement.

Criterion 2 – Medical Information

Consistent with the Draft Guidance, if “medical information about a patient” or “other medical information,” such as peer-reviewed clinical studies and clinical practice guidelines, are used as an input, the software function meets this criterion for non-device status.

The FDA adds that “medical information about a patient” would be the type of information that normally is communicated between HCPs in a clinical conversation or between an HCP and a patient in the context of a clinical decision. This term “includes” data/results from devices (including IVD tests) when used in a manner consistent with FDA-required labeling and when Criterion 1 is met.¹⁰ The FDA further defines “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. Although this definition appears to set a new and rigorous standard for the type of medical information that would serve as an input for a non-device CDS, arguably other types of information could suffice because of the FDA’s use of the word “include” in the description. Nevertheless, the types of data sources listed do convey the FDA’s expectations and could signal that the FDA intends to narrow the information that an exempt CDS may consider.

The FDA also explains that it will take into account sampling frequency when determining if given information is considered a signal/pattern under Criterion 1 or medical information under Criterion 2. For example, “a discrete test or measurement result that is clinically meaningful (e.g., a blood glucose lab test result) is medical information, while a more continuous sampling of the same information (e.g., continuous glucose monitor readings) is a pattern/signal.”¹¹ If a software function is intended to acquire, process or analyze such a pattern/signal, it fails Criterion 1 and potentially remains a device. The agency did not previously identify sampling frequency as a factor in evaluating Criteria 1 and 2, and the FDA thereby introduces a subjective element that newly juxtaposes Criterion 1 against Criterion 2. The FDA does acknowledge that there is a continuum between a single sample and a continuous sample.

Criterion 3 – Supporting or Providing Recommendations to an HCP

The FDA continues to interpret 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.¹² However, the FDA adds new considerations that result in a narrower interpretation for what functions meet the criterion.

Specifically, the FDA now interprets Criterion 3 to describe 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 preventive, diagnostic or treatment output or directive.
• Is not intended to support time-critical decision-making.
• Is not intended to replace or direct the HCP’s judgment.¹³

In particular, the consideration of whether the software is intended to support time-critical decision-making introduces a new limitation to this criterion.

The FDA expresses concern that “automation bias”—the propensity of humans to over-rely on a suggestion from an automated system—can cause errors, especially when the software provides the user with a single output, as opposed to a list of options with additional information. Decision-making that is urgent presents similar risks and, in the FDA’s view, may not allow an HCP time to independently review the basis for the recommendations presented by the software (under Criterion 4, discussed below). Examples of non-device CDS software functions include software that provide evidence-based clinician order sets for an HCP to choose from, tailored for a particular condition, disease or clinician preference, and drug-drug interaction notifications to avert adverse drug events.

Examples of software that fail Criterion 3 include software that provide:

• Time-critical alarms intended to trigger potential clinical intervention to assure patient safety or provides a treatment plan for a specific patient’s disease or condition.
• Information that a specific patient “may exhibit signs” of a disease or condition.
• A risk probability or risk score for a specific disease or condition.¹⁴

Although the FDA hinted that a software function that determines a patient’s treatment, or provides a “definitive diagnosis of a patient’s disease,” would not meet Criterion 3 in the Draft Guidance,¹⁵the FDA goes a step further in the Final Guidance by stating that even a software function that provides a risk score would fail.

Criterion 4 – Independent Review

Section 520(o)(1)(E)(iii) states that an exempt CDS function must be intended to enable HCPs to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, to make clinical decisions for individual patients.

Again, here, the FDA provides a narrower and more detailed interpretation of this criterion compared to the Draft Guidance. The agency outlines specific software and labeling recommendations to meet this criterion, but acknowledges that sponsors may use alternative approaches to enable the HCP to independently review the basis for such recommendations. Like in Criterion 3, the FDA does not consider software functions intended for a critical, time-sensitive task or decision to meet Criterion 4, because an HCP is unlikely to have sufficient time to independently review the basis of recommendations. The FDA emphasizes that software output or labeling provide a plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation, even if proprietary, and that relevant sources should be identified and available to the intended user.¹⁶

Omission of Patient Decision Support

The FDA previously announced a policy of enforcement discretion for certain CDS devices for patients or caregivers, sometimes referred to as patient decision support.¹⁷The Final Guidance states that software functions that support or provide recommendations to patients or caregivers meet the definition of a device, without qualification.¹⁸ The FDA expresses an intention to be consistent with existing policies in the regulation of CDS intended for non-HCPs, and may update existing policies with additional examples. It is unclear if the FDA intends to abandon its proposed approach of enforcement discretion toward software functions that provide recommendations to patients/caregivers, and whether additional guidance is forthcoming.

Other Software Regulation Updates

Shortly before the Final Guidance issued, on September 26, 2022, the FDA issued a report concluding its Software Precertification (Pre-Cert) Pilot Program.¹⁹ The FDA reported that a future approach to regulating SaMD could build on features of the current regulatory system, where a Quality Management System and other general or special controls, as applicable, provide a reasonable assurance of safety and effectiveness for certain low to moderate risk devices. Although organizational appraisals would be insufficient to replace clinical performance and cybersecurity reviews for all moderate-risk devices, this future approach could integrate a robust organizational appraisal process of devices for all risk levels that would enable streamlined reviews. The agency concluded that new legislative authority is necessary for the FDA to adopt such a flexible, risk-based approach to regulating SaMD.²⁰

Notably, a legislative proposal included in the Senate’s version of the user fee reauthorization package would have authorized the FDA to grant device sponsors a “predetermined change control plan” to make certain specified changes to a cleared or approved device, subject to the methods described in the plan and without changing the device’s intended use. Although this was not included in the final user fee reauthorization signed into law, it reportedly remains under discussion for potential passage in future legislation. This concept, while modest in comparison to the full Pre-Cert concept (and which was not limited to software devices), would have facilitated the advance validation of changes to software devices and served as an incremental step towards modernizing the regulation of SaMD.

On the same day the Final Guidance issued, the FDA also made minor updates to the agency’s Guidance on Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices (MDDS) to conform to classification regulations in Cures and the FDA’s implementing regulations.²¹

Finally, on September 29, 2022, the U.S. Government Accountability Office (GAO) published a report on Artificial Intelligence in Health Care, in which the GAO identified a variety of machine learning (ML)-based technologies to assist in the diagnostic process. The report noted the challenges limiting development and adoption of ML in diagnostics, such as demonstrating real-world performance across diverse clinical settings and addressing regulatory gaps, such as providing clear guidance for the development of adaptive algorithms. The GAO recommends that policymakers, including the FDA, promote collaboration among developers, providers and regulators to support the design of these technologies and the development of applicable standards.²²

Next Steps for CDS Software Developers

This Final Guidance marks a considerable departure in the FDA’s approach to regulating CDS. Although the FDA added further clarity to its position, the introduction of new considerations, such as data input sampling frequency, and whether a software function is intended to support time-critical decision-making, may signal a more conservative approach rather than clarification. These changes in approach are significant enough that it is somewhat surprising the agency did not release a revised draft guidance, to provide an opportunity for comment prior to finalizing. As it stands, the Final Guidance raises the following considerations and implications:

• Developers of software tools for health care purposes should re-evaluate whether their software functions qualify as non-device CDS under this framework and document those analyses and consider whether functions require a marketing submission.
• It is unclear the extent to which the U.S. standards for regulation of software tools as medical devices will align with IMDRF principles, or with the regulatory standards in other countries that adopt the IMDRF framework.
• Software functions designed to provide decision support directly to patients now appears uncertain and potentially subject to regulation as a device.
• Based on the Final Guidance, it is unclear what type and, now, what frequency, of data analysis may be incorporated into an exempt CDS.
• The FDA did not confirm whether enforcement discretion still governs a range software-based CDS offerings—which in turn places greater importance on defining the precise contours of the statutory exemption.
• Given the FDA’s determination that additional legislative authority is required to implement the concepts evaluated in the Pre-Cert pilot for SaMD, sponsors will need to work on a case by case basis with the FDA to assess the least burdensome approach to clearance or approval for individual SaMD submissions.

Although the 2022 Guidance is final, you can submit comments any time here.²³ All written comments should be identified with: FDA-2017-D-6569.

Contact Information

If you have any questions concerning this alert, please contact:

¹ FDA, Guidance, Clinical Decision Support Software (Sept. 28, 2022) (“2022 Final Guidance”).

² FDA, Draft Guidance, Clinical Decision Support Software (Sept. 27, 2019) (“2019 Draft Guidance”).

³ FDCA § 520(o)(1)(E).

⁴ 2019 Draft Guidance at 7. IMDRF, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (Sept. 18, 2014).

⁵ 2019 Draft Guidance at 20-21.

⁶The FDA reaches this conclusion in the Guidance, but this appears to be shorthand. A function that fails to meet Criterion 1 is not CDS, but is not necessarily a device; to constitute a device, it would otherwise need to fall within the device definition in section 201(h)(1) of the FDCA.

⁷ 2022 Final Guidance at 7.

⁸Id. at 8.

⁹Id.

¹⁰Id. at 9.

¹¹Id. at 9-10 (emphasis original).

¹²Id. at 10.

¹³Id. at 11-12.

¹⁴ Id. at 12-13.

¹⁵2019 Draft Guidance at 11.

¹⁶2022 Final Guidance at 13-15.

¹⁷ 2019 Draft Guidance at 20-21.

¹⁸2022 Final Guidance at 13.

¹⁹FDA, The Software Precertification (Pre-Cert) Pilot Program: Tailored Total Product Lifecycle Approaches and Key Findings (Sept. 2022).

²⁰Id. at 12-13.

²¹FDA, Guidance, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (Sept. 28, 2022); See FDA, Medical Devices; Medical Device Classification Regulations To Conform to Medical Software Provisions in the 21st Century Cures Act, 86 Fed. Reg. 20,278 (Apr. 19, 2021); FDCA § 520(o).

²² GAO, Artificial Intelligence in Health Care: Benefits and Challenges of Machine Learning Technologies for Medical Diagnostics (Sept. 29, 2022).

²³See 21 C.F.R. § 10.115(g)(5).