FDA Clinical Decision Support Software vs. EU’s Medical Device Regulation

In follow-up to our colleagues recent post about the newly implemented Medical Device Regulation (“MDR”) in the European Union, this post will discuss some of the similarities between FDA’s Clinical Decision Support (“CDS”) Software Draft Guidance (together the “CDS Draft Guidance”) and the MDR. 

While still in draft form, we note that FDA has signaled its intent to finalize the CDS Draft Guidance in 2021.

Statutory Framework

Under the current CDS Draft Guidance, FDA first bases its approach to CDS on criteria set forth in the 21st Century Cures Act (the “Cures Act”). Excluded from the definition of a “device” under the Cures Act are software functions that met all four of the following criteria:

(1) not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern signal from a signal acquisition system;

(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);

(3) not 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) 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.

Notably, these criteria do not include software functions intended for a patient or caregiver; rather, these criteria apply only to those software functions for “health care professionals.” Accordingly, software device manufacturers must analyze all software functions utilized by patients and caregivers carefully using the CDS Draft Guidance to determine whether FDA will either exercise its oversight focus, requiring the software to receive FDA approval as a device, or its enforcement discretion.  

IMDRF Framework

FDA’s CDS Draft Guidance also relies on the International Medical Device Regulators Forum (“IMDRF”) Framework for Software as a Medical Device (“SaMD”) in approaching its interpretation of the criteria from the statue that would exclude a software from the definition of a medical device. The MDR also utilized this IMDRF framework for SaMD. IMDRF focuses on two factors, which are critical to the analysis of SaMD: (1) whether the user uses the information provided by a SaMD to treat or diagnose, to drive clinical management, or to inform clinical management; and (2) whether the patient’s healthcare situation or condition is critical, serious, or non-serious.

The CDS Draft Guidance utilizes the IMDRF framework, and includes a variation of the classification used under Rule 11 by the European Commission’s Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745-MDR and Regulation (EU) 2017/746-IVDR, to similarly categorize different types of SaMD.

FDA uses the risk-categorizations described above to apply a risk-based policy to its regulation of Device CDS functions.

Other Components of the CDS Draft Guidance

In addition to the above framework from IMDRF, the CDS Draft Guidance also focuses on whether the intended user is a healthcare provider or a patient or caregiver and whether the user can independently review the basis for the recommendation from the software.  

This focus on user-type and independent review, rooted in the Cures Act language, is a departure from the IMDRF (and the MDR’s) framework, which focuses more upon the intended use of the software and the medical conditions the software covers. 

As you can see in the table below, FDA has a demonstrated interest in those software functions where the intended user is a patient or caregiver, particularly when the device is informing clinical management for serious or critical healthcare situations or conditions. Similarly, when the intended user is a healthcare provider, FDA does not consider the software to be a device so long as the healthcare provider can independently review the basis for the recommendation.

Combining the IMDRF Framework with FDA’s focus on the user-type and whether the user can independently review the basis for the recommendation, results in the following table:

Examples

The CDS Draft Guidance provides a number of examples where FDA works through its framework. These examples walk through the IMDRF framework while considering the intended user and whether the user can independently review the recommendation from the SaMD.

Non-Device CDS

FDA considers the following software to not be a device: software that compares patient signs, symptoms, or results with available practice guidelines (institutions-based or academic/clinical society-based) to recommend condition-specific diagnostic tests, investigations, or therapy to healthcare providers. In this example, the software uses practice guidelines as the basis for the recommendation and provides such guidelines to the healthcare provider to review, such that the health care provider does not rely primarily on the software’s recommendation.

Enforcement Discretion

FDA plans to utilize its enforcement discretion on software that assist a patient in identifying an over-the-counter cold or allergy medication to consider purchasing based on symptoms. In this example, the software would include appropriate warnings about products with overlapping ingredients. This software is device CDS because it is intended for a patient; however, FDA does not intend to enforce compliance because the software is intended to provide options to patients for the treatment of a non-serious situation or condition and because the patient can independently review the basis for the software’s recommendations.

Oversight Focus

FDA plans to focus its regulatory oversight on device CDS functions intended for patients, where the software is informing clinical management of serious or critical conditions. For example, FDA intends to regulate the following as device CDS: a software function that recommends when the parent or caregiver of pediatric patients with cystic fibrosis should take a child to the emergency room by aggregating information based on patient-specific symptoms and care guidelines. This software is device CDS because a caregiver uses the software and the software informs clinical management for a critical situation or condition, particularly because of the fragility of the target population.   

Conclusion

Recognizing that companies with global offerings face a complexity of issues, companies should seek to leverage similarities amongst the regulatory classification of SaMD and CDS. However, companies should simultaneously be acutely attuned to the critical differences in how those frameworks are applied by the applicable regulatory bodies. There is a need for attention to these issues, particularly with the upcoming finalization of the CDS guidance in FY2021 by FDA and the MDR coming into effect on May 26, 2021.