FDA Issues Long-Awaited Final Clinical Decision Support Software Guidance

On September 28, 2022, the US Food and Drug Administration (FDA) issued its final Clinical Decision Support Software Guidance three years after the issuance of its 2019 revised draft guidance. The final guidance refines and clarifies several key concepts for determining whether clinical decision support (CDS) software is a medical device. It also includes updated examples of device CDS and non-device CDS based on FDA’s review of proposed software solutions over the past three years.

The 21st Century Cures Act amended the Federal Food, Drug, and Cosmetic Act (FDCA) by exempting five categories of software [1], including CDS, from the definition of medical device in section 201(h). While the software exemptions provided clarity and freedom from FDA regulation for certain segments of the digital health industry, such as electronic health record vendors, the CDS provisions in section 520(o)(1)(E) introduced regulatory concepts that created interpretative challenges. Section 520(o)(1)(E) states:

The term device, as defined in section 201(h), shall not include a software function . . .

(E) unless the function is 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, for the purpose of—
(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
(ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
(iii) 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.

Many of the differences in interpretation seemed to focus on the concepts of “signal” acquisition and processing and the healthcare provider’s reliance on the software output.

FDA attempted to clarify section 520(o)(1)(E) in its 2019 draft guidance by describing a four-factor test for non-device CDS. However, many developers struggled to reconcile the four-factor test with the agency’s traditional risk-based approach for evaluating medical devices and the other software guidance documents with overlapping and sometimes contradictory interpretations of CDS functions that might exist in mobile applications or clinical software. The large volume of CDS tools on market that have similar intended uses but different regulatory classifications illustrate not only the complexity of the regulatory framework, but also that the statutory provisions and guidance are susceptible to significant differences in interpretation and application.

In the final guidance, FDA seeks to clarify and explain the criteria for device versus non-device CDS by elaborating on important elements of its original four-factor test described below.

• Criterion 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 2: 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)
• Criterion 3: intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis or treatment of a disease or condition
• Criterion 4: intended for the purpose of enabling such healthcare professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such healthcare professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

Notable takeaways from the guidance include the following:

Criterion 1

• Medical images – The term “medical images” may include images that were not originally acquired for a medical purpose. This suggests that images acquired or created on a mobile phone (e.g., a personal photo of a spot or lesion taken on a smartphone) can be considered a “medical image” if the software processes or analyzes that image for a “medical purpose.”
• Patterns and signals – The guidance clarifies that a pattern refers to “multiple, sequential, or repeated measurements” from a signal or signal acquisition system. Further software functions that “interpret the clinical implications or clinical relevance” of medical images, signals or patterns do not satisfy criteria 1 for non-device CDS. However, “activity monitors” or other software that measure physiological parameters for non-medical or non-device purposes are exempt (e.g., retinal image analysis for security purposes).

Criterion 2

• Medical information about a patient and other medical information – FDA defines patient information as “the type of information that normally is, and generally can be, communicated between HCPs [healthcare professionals] in a clinical conversation or between HCPs and patients in the context of a clinical decision . . . .” The agency also states that to satisfy criterion 2, the relevance of the information for clinical decision making must be “well understood and accepted.” Other medical information encompasses peer-review clinical studies, clinical guidelines and other information that is verified and validated for accuracy. Collectively these concepts suggest that the CDS output must be the type of information that is routinely discussed with patients, readily understood by both the patient and the HCP, and based on reliable, known or validated sources.
• Sample frequency – FDA introduces the concept of sample frequency as a key distinction between signals and patterns under criterion 1 and medical information under criterion 2. The guidance states that a single measurement (e.g., blood glucose lab test result) about a patient is “medical information” that an HCP might communicate to a patient in a clinical conversation. This would be “medical information” that satisfies criterion 2. However, software that analyzes continuous glucose monitor readings would constitute signal or pattern analysis and would not be exempt under criterion 1. While FDA acknowledges there is a continuum, the latter is more likely to fail criterion 1 because it is acquiring, processing or analyzing a medical image or signal.

Criterion 3

• Recommendations to enhance, inform or influence – FDA states that to satisfy criterion 3, the software must not be designed or deployed in a way that “replaces” or “directs” the HCP’s judgment. The terms “enhance” and “influence” appear to be new and perhaps are intended to emphasize the fact that non-device CDS is intended to supplement the HCP’s own knowledge and judgment.
• Level of software automation – The guidance describes automation bias as the “propensity of humans to over-rely on a suggestion from an automated system.” Automation bias can take the form of errors of commission (following incorrect advice) or omission (failing to act because there is no prompt to do so). The guidance suggests a direct correlation between the level of automation in the software and the increased risk of automation bias. FDA states that the risk of automation bias increases when software provides or has a single, specific, selected recommendation or output rather than a list of options or complete information to consider.
• Disease risk scores and disease risk probability outputs – Related to the issue of software automation is FDA’s concern that risk scores increase automation bias and tend to be more diagnostic and directive than lists that present a range of options. FDA expressly states that software that provides a risk probability or risk score for a specific disease or condition—or that is used to predict or detect symptoms or clinical outcomes associated with certain diseases or conditions (see examples 24 and 25 in the guidance)—or software meant to identify patients who “may exhibit signs” of a disease or condition does not satisfy criterion 3. Similarly, in situations that require urgent action, there may be insufficient time for the user to adequately consider other information. FDA’s examples in the guidance underscore the agency’s view that, to satisfy criterion 3, the output should be in the form of lists or prioritized lists of preventive, diagnostic or treatment options (e.g., FDA-cleared or approved therapies) or lists of possible next steps (e.g., additional diagnostic screenings) for the HCP to consider.
• Time-critical outputs – FDA states that a critical factor in determining the device status of CDS is whether the outputs of the software “require urgent action” or “direct” the HCP to take a specific action.” FDA is concerned that software outputs such as alarms or alerts that require or direct the HCP to act in critical situations increase the risk of so-called “automation bias.”

Criterion 4

• Labeling – FDA states that labeling and disclosures about and within the software outputs are critical to demonstrating that HCPs are not meant to rely primarily on the output of the CDS to make or inform clinical decisions. FDA seems to suggest that appropriate disclosure of the basis for the CDS output and recommendations is important for HCPs to make their own judgments. Software should clearly describe the intended use of the product, including the intended HCP and patient populations.
• Disclosures (including limitations) – Regardless of software’s complexity or whether it is proprietary, FDA states that the tool should disclose the following:

1. The input medical information (including how obtained, relevance, how data compares to relevant subsets of subjects, and data quality requirements)

2. A plain language description of underlying algorithm development and validation, including the following:

• A summary of the logic or methods
• Data (to allow the HCP to assess whether the data is representative of their patient population and if best practices were followed)
• A description of results from clinical studies conducted to validate the software (e.g., full reports of studies identified, summaries of the strength of studies, studies most closely matching patient-specific diagnosis or demographics, and key elements of the diagnosis or demographics searched for in the medical record noted)

3. Relevant patient-specific information, limitations or other information that may be relevant, such as missing, corrupted or unexpected input data values or significant variability.

FDA’s example 33 in the guidance (a software function that analyzes patient-specific medical information to provide a list of follow-up options for the HCP to consider) does not satisfy criterion 4 primarily because “input medical information is not adequately disclosed . . . from the patient’s medical record or . . . the radiologist report” and because “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, are not available,” and therefore “the HCP will not be able to assess if the results are generalizable.”

Patient CDS – FDA appears to have removed the concept that all CDS intended for patient and caregiver use are automatically considered device CDS. The term “patient CDS” first appeared in the draft guidance, but the Cures Act CDS provision only refers to HCPs and does not specifically address patients or caregivers. FDA signals that certain patient or caregiver CDS may be regulated as medical devices based on their functions, and it clarifies that manufactures and developers should review FDA’s other digital health and software policies to assess whether patient or caregiver CDS might be regulated as medical devices.

The final guidance signals that a greater number of CDS products, including many products that were previously classified as non-device CDS, will be subject to FDA’s regulatory oversight. The emphasis on automation bias and disclosures reflects the agency’s learning, surveillance and evaluation of hundreds of CDS tools since it released the draft guidance. The removal of the automatic device CDS designation for patient or caregiver CDS is more consistent with the plain language of the Cures Act and FDA’s risk-based approach to device evaluation.

For some, the final guidance may resolve lingering questions of interpretation and may contribute to more efficient decision-making regarding design, development and commercialization strategies. For others, the guidance may introduce practical challenges and new complexities. The guidance may present a particular challenge for developers and manufacturers that must now revisit prior determinations regarding the device status of their CDS tools. This is particularly true for CDS that predict risk or triage or rank order patients for additional potential diagnosis or treatment, for products used in time-sensitive diagnosis or treatment, and for developers of complex software algorithms.

Manufacturers and developers may also wrestle with how to disclose the aspects of the underlying algorithm architecture and validation that FDA deems critical for HCP independence and safety without disclosing proprietary or commercially sensitive information. FDA has stated that it will continue to update and revise its digital health guidance documents as it learns and evolves its regulatory approach. For industry, this may offer more opportunities to engage with FDA and inform the agency’s thinking on CDS and digital health regulation.

——————————
[1] (1) For administrative support of a healthcare facility; (2) for maintaining or encouraging a healthy lifestyle; (3) to serve as electronic patient records; (4) for transferring, storing, converting formats or displaying data; or (5) providing certain types of clinical decision support to a healthcare provider unless interpreting or analyzing a clinical test or other device data.