09/28/2022 | News release | Archived content
On September 27, 2022, the U.S. Food and Drug Administration (FDA) issued its long-awaited final clinical decision support (CDS) software function guidance. This final guidance presents a significant departure from the previous draft version issued three years prior, including updates to address concerns voiced by the industry. This guidance marks the final version of two previous iterations of this guidance-the first was released in 2017 titled "Clinical and Patient Decision Support Software" and was replaced by the draft issued on September 27, 2019.
FDA's substantially revised final guidance reflects the industry's concerns and questions voiced during the comment period of the 2019 draft guidance. The final guidance does away with the risk-based framework detailed in the 2019 draft guidance, and instead provides additional details regarding FDA's interpretation of each statutory criterion for non-device classification along with more than thirty specific demonstrative examples of device and non-device CDS functions.
Interpretation of Section 520(o)(1)(E) Criteria
In the 2022 final guidance, FDA provides additional clarification of its interpretation of each of the four criteria in Section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act. In order for a software function to be excluded from the device definition by the provision, and considered a non-device CDS function, it must meet all four criteria.
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
Software functions that are intended to acquire, process, or analyze medical images, signals from in vitro diagnostic devices (IVDs), or patterns or signals from signal acquisition systems will remain devices subject to FDA oversight. The final guidance provides additional clarification regarding the definitions of "medical image," "signal," and "pattern."
FDA considers software functions that assess or interpret the clinical relevance of a signal, pattern, or medical image to fail this first criterion because they acquire, process, or analyze the data. For example, software functions that process or analyze an electrochemical or photometric response generated by an assay and instrument to generate a clinical test result do not meet the first criterion.
2. Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information
FDA interprets "medical information about a patient" to mean the type of information that is normally communicated "between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted." This includes software functions that display, analyze, or print patient-specific information like demographic information, symptoms, test results, and/or other medical information such as peer-reviewed clinical studies or clinical practice guidelines.
In the final guidance, FDA identified sampling frequency as an important consideration in determining if information is considered "medical information" or a "signal" or "pattern." FDA considers a "single discrete test or measurement result that is clinically meaningful (e.g., a blood glucose lab test result)" to be medical information, while a more continuous sampling of the sample information (e.g., continuous glucose monitor readings) would be considered a pattern or signal. FDA clarified that it "recognizes there is a continuum between a single sample and a continuous sample" and included more detailed examples for reference.
3. Intended for the purpose of supporting or providing recommendations to an HCP about prevention, diagnosis, or treatment of a disease or condition
FDA interprets this criterion to refer to software that provides condition, disease and/or patient-specific recommendations to a health care provider (HCP) "to enhance, inform and/or influence a health care decision but is not intended to replace or direct the HCP's judgment." In the final guidance, FDA expands on this criterion, adding two factors for consideration in determining whether a software function is being used to support or provide recommendations to an HCP: (1) the level of software automation and (2) the time-critical nature of the HCP's decision-making. Both factors will be considered in determining whether a software function is being used to enhance, inform, and/or influence, or rather to substitute, replace, or direct the HCP's judgment.
In the final guidance, FDA dives into a discussion about automation bias in the context of CDS functions and the errors of commission or omission that may result if software provides an HCP user with a single, specific output or solution, especially in time-critical circumstances that require urgent action. FDA highlights instances involving time-critical decision-making and cases where software provides that a specific preventive diagnostic or treatment directive is failing this criterion because it is not intended to support or provide recommendations. Examples include software that provides a specific diagnostic or treatment course, a specific follow-up directive, or time-critical alarms and alerts intended to trigger potential clinical intervention to assure patient safety.
The focus of this criterion is the preservation of HCP decision-making and judgment. Software functions that meet this criterion are those that provide evidence-based tools and make recommendations based on analysis of patient-specific information that an HCP may incorporate into its holistic decision-making process.
4. Intended for the purpose of enabling an HCP to independently review the basis for the recommendations that the software presents, and not intended that the HCP should rely primarily on any of those recommendations to make a clinical diagnosis or treatment decision regarding an individual patient
There were many questions from stakeholders in the industry regarding this fourth criterion and the requirements for satisfying independent review. In response, the new final guidance recommends that software or labeling:
In addition, FDA recommends the software outputs provide the HCP users with relevant patient-specific information and other known/unknown factors for consideration by the HCP in applying its judgment.
In response to industry comments and questions regarding the difficulties associated with software complexity and proprietary information, FDA clarified that regardless of the complexity or proprietary nature of the software, the outputs or labeling "should provide adequate background information in plain language on the input(s), algorithm logic or methods, datasets, and validation." Relevant sources should be identified, available, and communicated in a way that is understandable to the intended users.
Device and Non-Device CDS Function Examples
The final guidance provides many specific examples of types of software that may be considered non-device CDS functions assuming they meet the requirements of the fourth criterion. These include, for example:
The final guidance also provides examples specifically intended to clarify FDA's interpretation of the fourth criterion-independent HCP review-as well as 34 separate examples of device software functions on which FDA intends to focus its regulatory oversight.
Patient/Caregiver Decision Support
The final guidance eliminates software functions that support or provide recommendations to patients or caregivers from the CDS function exclusion and will regulate that software as medical devices. FDA stated its intention to be consistent with existing policies in the regulation of CDS intended for non-HCPs and "will update existing policies, as appropriate, with additional examples as CDS for non-HCPs continues to evolve."