When Clinical Decision Support 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 21^st 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:

• Criterion One:
  • 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.”
  • FDA indicates that if a software function uses or interpret clinical relevance of input data such as medical images, signals, or patterns, those software will continue to be regulated as medical devices. FDA provides additional examples of their interpretation of each type of input data. FDA also clarifies that activity monitors or other signal acquisition systems that measure physiological parameters not specifically intended for the purpose of a device may not fall under the definition of a medical device.
  • If data described in Criterion 1 is used as an input, it is then a device software function. FDA clarifies that medical images are those that are generated by medical imaging systems or are processed for a medical purpose.
• Criterion Two:
  • Intended for “displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines).”
  • FDA further clarifies Criterion 2 in the final guidance to mean that medical information is well understood and accepted, such as information that is exchanged between HCPs or between an HCP and patient in the context of a clinical decision and continues to include results from device or test results.
• Criterion Three:
  • Intended for “supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition.”
• FDA elucidates in the final guidance that level of software automation and the time-critical nature of the HCP’s decision will be considered by FDA in determining if the software functionality meets Criterion 3. These two factors help determine whether a software function is informing vs. driving clinical decisions. Making this distinction was a point of contention with the draft guidance. ‘Informing’ would mean the software provides treatment/diagnostic options or aggregates information for the HCP who then uses his/her expertise to make a recommendation. ‘Driving’ would indicate the HCPs reliance on the software in making recommendations or taking actions to treat or diagnose the patient. NOTE: If a software tool were to drive a clinical decision, it would not fall under the definition of CDS.
• Criterion Four:
  • Intended for “enabling such HCP to independently review the basis for such recommendations that such software presents so that it is not the intent that such HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”
  • The emphasis is placed on the HCP to be able to independently review the basis for their recommendations. All software inputs, outputs, algorithm logic, and labeling should be clear and understandable by the HCP in forming the basis of their recommendation. FDA stresses in the final guidance that any relevant patient-specific information that an HCP independently reviews in making a treatment recommendation, so essentially they are not relying on the output of the software primarily, but rather his/her own judgement, would be a non-device software function.

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 21^st 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.