FDA Issues Final Guidance on Clinical Decision Support Software

On September 28, 2022, the Food and Drug Administration (FDA) issued Clinical Decision Support Software final guidance. The guidance clarifies the agency’s scope of oversight and regulation of clinical decision support software based on the definition of a device in the Federal Food, Drug, and Cosmetic Act (FD&C Act). It also describes the criteria used to assess whether software functions do not meet the definition of a device.

Clarifying Types of Clinical Decision Support Software

Clinical decision support software (CDS), such as software that is designed to provide diagnostic support, clinical guidelines, and alerts to health care professionals and patients, may be categorized as a regulated device, under the FD&C Act, section 201(h).

However, the 21^st Century Cures Act carved out an exception for software that does not meet the definition of “device” and is therefore outside FDA’s regulatory authority. The new guidance describes FDA’s regulatory approach to CDS software functions and clarifies when CDS software functions do not meet the definition of a device under the FD&C Act, section 520(o)(1)(E) by reviewing the four non-device criteria. Also, the FDA advises that its existing digital health policies, including guidance regarding enforcement discretion, continue to apply to those clinical decision support software functions that do meet the definition of a device.

The final guidance not only responds to comments received from the 2019 publication of the FDA’s Draft Guidance on Clinical Decision Support Software (found here), but also narrows its scope to focus largely on the CDS software functions that do not meet the FD&C Act’s definition of a device. While the 2019 draft guidance discussed such non-device CDS software, it also: (1) explained the FDA’s approach to software that may technically meet the definition of a device but may not require FDA oversight because of the risk analysis outlined in the International Medical Device Regulators Forum (IMDRF) final document; (2) included an explanation of software that does meet the device definition and will likely be the subject of oversight, whether it is CDS or not; and (3) broadly considered health care professionals (HCPs), patients, and caregivers, in contrast to the final guidance, which focuses largely on software used by HCPs.

Defining Non-Device Clinical Decision Support Software

The FDA explains that if CDS software meets all of the following criteria under section 520(o)(1)(E) of the FD&C Act, it is excluded from the definition of a device and is therefore not regulated as a device by the FDA:

1. It is 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;
2. It is 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);
3. It is intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
4. It is intended for the purpose of 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.

The FDA interprets each of the four non-device criteria in detail and shares multiple examples for clarification.

Criterion 1

First, for criterion 1, the FDA explains that if software functions use input data such as medical images or signals from in vitro diagnostic devices (IVDs) or patterns or signals from signal acquisition systems, such products continue to be regulated as devices.

• Medical images include images produced by medical imaging systems such as ultrasounds, x-rays, and more. The definition covers software functions that ultimately use medical images for medical purposes even if the images were not originally intended for such purposes.
• Signals that either require the use of an IVD or signal acquisition system for medical purposes are also included in the device definition. Examples include electrocardiogram (ECG) leads used with software to generate signals, specimen samples studied using software such as digital pathology, and more.  
• Patterns include multiple, sequential, or repeated measurements of a signal. For example, assays and instruments that produce signals for continuous glucose monitors (CGMs) generate patterns in the form of repeated glucose measurements.

Importantly, software functions that interpret the clinical relevance of medical images, signals, or patterns do not satisfy criterion 1 because they still acquire, process, and analyze the same input data described above. Thus, they are within the definition of device according to the FDA. However, some activity monitors or other signal acquisition systems that measure physiological parameters are not specifically intended or marketed for a purpose identified in the device definition (i.e., for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease) and are not medical devices.

Criterion 2

Next, the FDA interprets criterion 2 as excluding software functions from the definition of device if they are intended to use medical information, such as patient medical information, peer-reviewed clinical studies, and clinical practice guidelines, as input data, as long as the software also meets the other three criteria described here.

• Medical information about the patient includes information used to inform clinical decision making between HCPs or between HCPs and patients.
• Other medical information means information that is “independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.”

Notably, for the FDA, the distinction between a device and a non-device may come down to the frequency of any given measurement. As the FDA clarifies, one blood glucose lab test is considered medical information under criterion 2, while repeated measures from a continuous glucose monitor constitute a pattern or signal under criterion 1.

Criterion 3

Criterion 3 excludes software from the device definition if it provides patient-specific recommendations to be interpreted by an HCP without explicitly directing the professional’s judgment. Examples of software functions that are intended to support or provide recommendations to an HCP about the “prevention, diagnosis, or treatment of a disease or condition,” include drug formulary guidelines, evidence-based clinical order sets for an HCP, clinical guidelines, reminders for preventative care, and patient data reports such as discharge papers.

The FDA uses two key characteristics to assess whether software is truly used to support an HCP: (1) the level of software automation, and (2) the time-sensitive nature of the HCP’s decision making. High levels of these two characteristics suggest that the software is more likely to replace the HCP’s judgment instead of supporting it, possibly making the HCP more susceptible to automation bias. Specifically, criterion 3 includes software that:

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

The specificity of information provided by the software, such as the provision of a specific treatment course, plays a critical role in the FDA’s assessment of criterion 3. The more specific the software’s output is, the more likely the FDA will find that it replaces rather than supports the HCP’s decision making. Software that provides risk probability of a health condition is also interpreted as providing too specific an output and fails criterion 3. Additionally, software that provides recommendations to patients and caregivers instead of health care professionals is also classified as a device.

Criterion 4

Finally, in order to meet criterion 4, the software must enable the HCP to independently review the basis of its recommendations. The FDA advises that overall, the software product or its labeling should provide the basis for its findings in plain language so that the HCP may independently evaluate the basis of recommendations. Also, similar analysis of time sensitivity in decision making used in criterion 3 applies to criterion 4.

More specifically, the FDA recommends taking the following measures to meet the fourth criterion:

1. The software or labeling include the purpose or intended use of the product, including the intended HCP user and intended patient population.
2. 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.
3. 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 to provide the recommendations (e.g., meta-analysis of clinical studies, expert panel, statistical modeling, AI/ML techniques);
   • A description of the data relied upon so that an HCP can assess whether the data is representative of their patient population (e.g., relevant sub-groups, disease conditions, collection sites, sex, gender, ethnicity) and assess if best practices were followed (e.g., independent development and validation datasets); and
   • A description of the results from clinical studies conducted to validate the algorithm/recommendations so that an HCP can assess the potential performance and limitations when applied to their patients (e.g., sub-populations with untested or highly variable algorithm performance).
4. 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.

Takeaways

The FDA’s longstanding oversight of software that meets the definition of a device continues to apply to a subset of clinical decision support software. However, the final issued guidance clarifies the FDA’s interpretation of statutory criteria used to determine that a software function does not meet the definition of a device. The guidance extensively describes the FDA’s interpretative approach, contains a number of factors and considerations that will contribute to a determination as to whether CDS software is a device subject to FDA oversight or not, and contains numerous examples of device and non-device CDS based on the section 520(o)(1)(E)(iii) criteria.

In addition to regulatory engagement and compliance, there are other practical, business, and legal implications of designing, selling, and using CDS software. For example,

• Will CDS software designers, sellers and users become targets of traditional product liability litigation?
• If so, will courts will permit these products and their designers, sellers, and / or users to be subject to states’ traditional strict products liability regimes and associated defenses?
• Can entities in the supply chain for CDS software use contractual provisions such as indemnification to plan for the allocation of liability before a lawsuit is filed? 

As entities are considering this complex regulatory positioning and other relevant guidance regarding FDA oversight and enforcement discretion related to CDS and other software, we are available to advise on how FDA may view a particular product and the steps needed for compliance. We are also following the developing landscape for liability and litigation related to CDS software, and are available to advise entities on how to navigate these issues.