ARTICLE
29 September 2022

Developers Take Note: FDA Issues Clinical Decision Support Software Final Guidance

FL
Foley & Lardner

Contributor

Foley & Lardner LLP looks beyond the law to focus on the constantly evolving demands facing our clients and their industries. With over 1,100 lawyers in 24 offices across the United States, Mexico, Europe and Asia, Foley approaches client service by first understanding our clients’ priorities, objectives and challenges. We work hard to understand our clients’ issues and forge long-term relationships with them to help achieve successful outcomes and solve their legal issues through practical business advice and cutting-edge legal insight. Our clients view us as trusted business advisors because we understand that great legal service is only valuable if it is relevant, practical and beneficial to their businesses.
On September 27, 2022, the Food and Drug Administration (FDA) issued its much anticipated final guidance for industry and FDA Staff, Clinical Decision Support Software.
United States Food, Drugs, Healthcare, Life Sciences

On September 27, 2022, the Food and Drug Administration (FDA) issued its much anticipated final guidance for industry and FDA Staff, Clinical Decision Support Software. This guidance follows the draft Clinical Decision Support Software guidance issued on September 27, 2019. The final guidance is particularly important as developers seek clarity regarding the regulatory status of software functions that utilize algorithms to either support or provide clinical decisions for use by health care providers (HCPs). While the draft guidance opined upon clinical decision support software (CDS) intended for use by patients are caregivers, the final guidance noted that FDA's existing digital health policies continue to apply to such software functions such that software functions that support or provide recommendations to patients or caregivers – not HCPs – meet the definition of a device.

FDA regulates software that meets the definition of a device in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), which includes software intended to support HCP decision-making regarding the diagnosis, treatment, prevention, cure, or mitigation of diseases or other conditions, otherwise known as CDA. In its guidance, FDA clarifies types of CDS software functions that are excluded from the definition of a medical device by meeting all four of the criteria articulated in section 520(o)(1)(E) of the FD&C Act, which requires that the device is:

  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 (Criterion 1);
  2. intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (e.g., peer-reviewed clinical studies and clinical practice guidelines) (Criterion 2);
  3. intended for the purpose of supporting or providing recommendations to an HPC about prevention, diagnosis, or treatment of a disease or condition (Criterion 3); and
  4. intended for the purpose of enabling such HCPs to independently review the basis for such recommendations that such software presents so that it is not the intent that such HCPs rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient (Criterion 4).

Criterion 1

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 because they acquire, process, or analyze. Such devices are subject to FDA regulation and oversight. Note, however, that activity monitors or other signal acquisition systems that measure physiological parameters that are not specifically intended or marketed for a purpose identified in the device definition are not medical devices.

Criterion 2

Software functions intended to display, analyze, or print7medical information about a patient or other medical information (e.g., peer-reviewed clinical studies or clinical practice guidelines) meet Criterion 2 and are not medical devices subject to FDA regulation and oversight.

FDA explains that Criterion 1 and Criterion 2 describe the types of data inputs used in devices (Criterion 1) and the types of data inputs used in Non-Device CDS (Criterion 2).

Criterion 3

FDA 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 (e.g., drug-drug interaction and drug-allergy contraindication notifications to avert adverse drug events) but is not intended to replace or direct an HCP's judgment and does not include in time-critical decision-making or a specific preventive, diagnostic or treatment output or directive. Criterion 3 software functions present recommendations based on an analysis of patient-specific information to an HCP, who may then incorporate this information into their decision-making about the care of a patient, along with other information and factors of which the HCP is aware. In contrast, software that provides a specific preventive, diagnostic, or treatment output or directive or that addresses a time-critical decision would be a medical device regulated by FDA and subject to FDA oversight.

FDA notes that two aspects of software functionality may affect whether a software function is being used to support or provide recommendations to an HCP: (1) the level of software automation, and (2) the time-critical nature of the HCP's decision making. Automation bias may occur if software provides an HCP with a single, specific, selected output or solution as opposed to a list of options or complete information for the HCP's consideration.

Criterion 4

Under criterion 4, the software 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. FDA explains that regardless of the complexity of the software and whether or not it is proprietary, the software output or labeling should provide adequate background information in plain language on the input(s), algorithm logic or methods, datasets, and validation. Additionally, relevant sources should be identified and available to and understandable by the HCP user.

The final guidance released by FDA includes several examples of device and non-device CDS, which should be carefully reviewed by developers when inking an FDA regulatory strategy.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

Mondaq uses cookies on this website. By using our website you agree to our use of cookies as set out in our Privacy Policy.

Learn More