In December 2021, we wrote that Clinical Decision Support (CDS) software was set to become a priority for the FDA in 2022. Nine months later, the FDA officially released final guidance on clinical decision support software, which in their words, “clarifies the scope of FDA’s oversight of clinical decision support software intended for health care professionals (HCPs) as devices.”

Close up of hand touching smartwatch with health app on the screen, gadget for fitness active lifestyle.

This final guidance follows and is intended to clarify the draft guidance on CDS software issued previously (September 2019), which left unanswered many questions about how software developers and industry stakeholders could determine if their CDS software qualified as a medical device. The overarching question for stakeholders is whether their existing CDS software – or software in the development phase – is considered a medical device subject to FDA oversight and regulation. The answer depends on whether the software qualifies for exclusion as “Non-Device CDS.”   

The FDA’s final guidance brings full circle a process that essentially began in 2016 when Congress enacted Section 3060 of the 21st Century Cures Act in an effort to narrow the FDA’s ability to regulate some types of software as devices. Section 3060 established  four criteria (detailed below) that CDS software must meet if it is to be excluded from the definition of a device. Below, we briefly review some key FDA interpretations of each of the four criteria.

Key Takeaway

Quandary Peak’s review of FDA’s final guidance leads us to believe we could see meaningful expansion of the amount of CDSS qualifying as a medical device, which could subject many current and future CDS software applications to FDA oversight.

Because the FDA’s final guidance appears to broaden the definition of CDS software as a medical device, many expect industry stakeholders to push back on this guidance in the coming months and perhaps years, making the case that substantial changes from the 2019 draft guidance were issued without public comment. Congress could even weigh in, given that broader oversight of CDS software could run counter to the 21st Century Cures Act’s goals of boosting innovation and technological advancement in health care.

The Guidance in Summary

Developers and stakeholders in the digital health industry must focus on what is in the “CDS Final Guidance” to understand  the FDA’s approach for evaluating CDS software functions. Per the FDA, “in order for a software function to be excluded from the device definition by this provision, it must meet all four criteria [found in Section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act]. Stated simply, these criteria describe the types of CDS that are not regulated as devices.” 

The FDA has provided a graphical overview of their guidance and the regulatory approach to CDS software functions:

Below, we list each of the four Criterion while offering a brief overview of FDA’s interpretation of each per the final guidance. If a software product meets all four criteria, it is what the FDA terms “Non-Device CDS,” excluding it from the type of regulation and oversight that the FDA would impose on medical devices.

The Four Criteria

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

Put simply, if the type of data described in Criterion 1 is used as an input by an HCP, then the software function would be classified as a medical device. Examples of medical images are x-rays, ultrasounds, or a magnetic resonance imaging (MRI) to view any part of the body or images acquired for a medical purpose. If a software function acquires a signal, pattern, or medical image, assesses this data, or interprets its clinical implications or relevance, the software function is considered a device. 

Here are two examples taken directly from the FDA’s final guidance, both of which would fail Criterion 1 and would therefore be classified as a device:

  1. Software functions that process or analyze a medical image, such as enhancement, manipulation, making measurements, identifying normal/abnormal structures, determining size/shape/location of a suspected nodule, or functions within computer aided diagnostics (CADx) or computer aided detection (CADe) systems.
  2. Software functions that process or analyze an ECG waveform or QRS complex, such as measuring repeated complexes, measuring variation from baseline, or detecting heart rate, arrhythmias, or structural abnormalities.

Criterion 2: Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information

Criterion 1 describes the types of data inputs used in devices, whereas Criterion 2 describes the types of inputs used in Non-Device CDS.

FDA interprets Criterion 2 to “include software functions that display, analyze, or print patient-specific information, such as demographic information, symptoms, certain test results, patient discharge summaries, and/or other medical information (such as clinical practice guidelines, peer-reviewed clinical studies, textbooks, approved drug or medical device labeling, and government agency recommendations).”

The FDA considers “medical information about a patient” to be the type of information normally communicated between doctor and patient in clinical conversations. This means the Non-Device CDS software is producing information whose relevance is “well understood and accepted,” per the FDA. “Other medical information” includes the type of information that is readily available to HCPs, such as peer-reviewed clinical studies and clinical practice guidelines.

Here are four examples taken directly from FDA’s final guidance of medical information that can be displayed, analyzed, or printed about a patient:

  1. The report from a radiology study (e.g., “a BIRADS category 4 lesion is present”) or summary information about the output of legally marketed CAD software (e.g., “twelve CAD annotations are present”). 
  2. An ECG report annotated by an HCP with a description of an abnormal heart rhythm (e.g., “the patient shows signs of Atrial Fibrillation”). 
  3. A blood pressure result (e.g., “120/80 mmHg”) from a legally marketed device. 
  4. A lab test result (e.g., “potassium level of 4.0 mmol/L or glucose level of 95 mg/dL”) in an electronic health record.

Criterion 3: Intended for the purpose of supporting or providing recommendations to an HCP about prevention, diagnosis, or treatment of a disease or condition

The key for meeting Criterion 3 is that the CDS software provides general information about a condition, disease, or a patient that is meant to support and/or enhance the HCP’s decision-making process—but not replace it. 

For example, if the CDS software gives specific treatments, diagnoses, or plans of action that replace or direct an HCP’s judgment, then that software would fail Criterion 3 and be considered a medical device. These functions include:

  • Providing a specific preventative, diagnostic, or treatment course;
  • Providing a specific follow-up directive;
  • Providing time-critical alarms or alerts intended to trigger potential clinical intervention to assure patient safety; or,
  • Providing a treatment plan for a specific patient’s disease or condition.

The use of the word “specific” is notable in the FDA’s interpretation of this criteria, and some may argue significantly expands the universe of CDS software that would now be viewed as a medical device. The FDA also “considers software that provides information that a specific patient “may exhibit signs” of a disease or condition or identifies a risk probability or risk score for a specific disease or condition as providing a specific preventive, diagnostic, or treatment output,” would not meet Non-Device CDS criteria. This potentially expansive view of CDS software as a device is likely to be a source of contention going forward.

Examples of software functions that would meet Criterion 3 and could therefore be Non-Device CDS (assuming they met all the other criteria) are as follows, per the final guidance:

  • Evidence-based clinician order sets for an HCP to choose from, tailored for a particular condition, disease, or clinician preference;
  • Matching patient-specific medical information from records or reports to reference information (e.g., clinical guidelines); and, 
  • Contextually relevant reference information about a disease or condition.

The FDA also specified that the following CDS software outputs would meet Criterion 3 assuming “they were not intended to support time-critical decision-making and/or replace or direct the HCP’s judgment”:

  • List of preventive, diagnostic or treatment options; 
  • Prioritized list of preventive, diagnostic or treatment options; 
  • List of follow-up or next-step options for consideration (e.g., after a physician office visit, hospitalization, procedure)

Criterion 4: Intended for the purpose of enabling an HCP to independently review the basis for the recommendations that such software presents so that it is not the intent that the HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient

Similar to Criterion 3, the FDA is focused on CDS software not replacing the HCP’s decision-making process, nor having the software’s outputs be the sole source of a clinical diagnosis or treatment plan. In Criterion 4, the FDA specifies that they want HCP’s to have the ability to “independently review the basis for the recommendations presented by the software so they do not rely primarily on such recommendations, but rather on their own judgment, to make clinical decisions for individual patients.” In other words, HCPs need to be able to understand how the software arrives at its output, which even includes a “plain language description of the underlying algorithm,” no matter how complex.

The FDA recommends that:

  • The software or labeling include the purpose or intended use of the product, including the intended HCP user and intended patient population.
  • 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.
  • 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);
    • 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); and,
    • 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.

The requirements in Criterion 4 may be challenging and very time-consuming for most developers and stakeholders to meet. For many, it may require additional work to provide significant amounts of information, including plain language descriptions of complex algorithms,  about the software being developed or already in use.

Conclusion

The FDA has acknowledged that rapid innovation – catalyzed in large part by the pandemic – has led to the proliferation of clinical decision support software used in healthcare settings and that the industry urgently needs a clear process for determining if their CDS software is a device or not. The CDS Final Guidance is meant to provide this clarity, but many developers and other stakeholders may take exception to what appears to be the FDA substantially broadening its view of what types of CDS software could classify as a medical device.

The summary of the FDA’s interpretations we have provided here are by no means exhaustive, and as we mentioned at the outset, they are likely to be met by challenges from the industry and perhaps even Congress in the months and years ahead. For now, however, this guidance should be accepted by developers as the final rule, which may necessitate testing or retesting your CDS software under the four criterion and the FDA’s interpretation thereof. 

Quandary Peak Research assists clients in navigating the toughest challenges in Health IT and medical device regulations. Contact us now for an evaluation of your software and for help planning next steps. We have the experience and knowledge to help you stay ahead of changing regulations and avoid risks and costs associated with non-compliance or regulatory delays.