Skip to Content

When Clinical Decision Support (CDS) Software is Considered a Medical Device

Pre-Guidance History

FDA has published the long-awaited final guidance document on Clinical Decision Support (CDS) software. This guidance clarifies several key concepts for determining if CDS software is under FDA purview or not. FDA provides more examples of device and non-device CDS based on their review of software functionalities since the 21st Century Cures Act (Cures Act) was published in 2016. The final guidance is yet another example of FDA providing updates to its regulatory approach towards digital health and software as a medical device.

Guidance Background

FDA made certain distinctions following the 2016 Cures Act. Following the Cures Act was a decision that some software, based on their low risk to the end user, like some Clinical Decision Support (CDS) software, did not fall under the definition of a medical device and, therefore, outside the purview of FDA. For example, with certain CDS, a health care provider (HCP) will offer a recommendation to a patient based on the data and outputs from the software. The HCP relies on his/her expertise and reviews the output of the software for guidance and not a clinical decision, therefore, placing this software into the non-device category.

The initial 2017 and 2019 draft guidances caused a stir within the medical device industry because of the blurred lines between device and non-device classification. If a software is classified as a medical device, the software development efforts could potentially be impacted in order to meet regulatory expectations. Recently, FDA published the long-awaited final guidance document on the classification of CDS from a risk-based perspective, considering the output, reliance, and user considerations of the CDS.

The most noticeable change between the draft and the final version of the guidance is the removal of the application of the International Medical Device Regulators Forum (IMDRF) risk categorization framework. These considerations are now baked into FDA’s review of risk based on the four major criteria that were first introduced in the draft guidances. A reference to the IMDRF guidance is made to the reader for further information regarding risk categorization.

It is our assessment that what the FDA is clarifying in the final guidance is a typical part of the regulatory process – using risk management as a practice to determine risks with software functionalities, device classification, and risk mitigation. The application of risk management is used by regulatory professionals in determining the appropriate level of evidence required for regulatory filings to FDA.

The Final Guidance

The four criteria defined in Section 520(o)(1)(E) of the Food, Drug, and Cosmetic Act were initially explained by FDA in the 2017 and 2019 draft guidances. FDA’s final guidance further clarifies that, in order to be excluded from the definition of device, the software function must meet all four criteria by providing additional examples of functions where the HCP is the end user.

Certain CDS software functions are excluded from the statutory definition of medical device if the software is:

Review of the Final Guidance from Others in the Medical Device Space

Critics of the final guidance indicate FDA is countering what Congress mandated in the 21st Century Cures Act (Cures Act) by narrowing their focus on what constitutes ‘other medical information’ that can be analyzed, especially when it comes to software algorithms. Though algorithm integration into medical device systems is a new, highly technical area and not well understood by many, prior to acceptance of an algorithm the outputs of an algorithm are typically validated by real-world data to evaluate their accuracy and robustness. Sources of validation data are often peer-reviewed studies or independently conducted pre-clinical testing. These are typical sources of data, and not limited to the validation of an algorithm, therefore, it is our understanding this is not counter to the language of the Cures Act. Although integration of algorithms in medical devices is a novel area, algorithm development itself is a well-established engineering practice that utilizes the scientific method. When developed under design controls, algorithms can be appropriately verified and validated for medical device applications.

Similarly, the addition of ‘automation bias’ and ‘time-critical decision making’ has been criticized as language that doesn’t exist in the Cures Act. However, identifying the different situations where a software functionality may potentially be used, and criticality of any resulting hazardous situations is the basis for risk management – a critical component that regulatory affairs professionals review and leverage prior to submitting to the FDA. Risk management is a well-accepted process in the medical device industry and something that FDA scrutinizes with each regulatory filing. These are not new concepts that have been introduced by the final guidance.

Ultimately, Halloran approaches assessing software as a medical device (SaMD) development from a total product lifecycle (TPLC) framework as with any other potential medical device. We take into consideration the software functionalities, user considerations, and benefit-risk profile to support device classification and recommending any regulatory action. This is a typical and thorough process we follow to support our submissions to FDA. The publishing of this final guidance aligns with FDA’s continued approach of using risk-based determinations in assessing medical device technologies.

If you are developing CDS software, we encourage you to read the final guidance. We are available to discuss the challenges and opportunities for device classification that may warrant regulatory action. Don’t hesitate to contact us.