FDA Releases Foundational Digital Health Guidance

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.” 

• Medical Image: FDA generally considers the term “medical image” to include images generated by medical imaging systems for medical purposes, such as x-ray, CT, ultrasound, and MRI images. Images that were not originally acquired for medical purposes but are now being processed or analyzed for a medical purpose are also considered medical images.
• Signal: FDA interprets the term “signal” to include signals that typically require use of an IVD or a signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose. This often includes, but is not limited to, use of sensors, collection of samples or specimens, or use of radiological imaging systems. 
• Pattern: FDA interprets the term “pattern” in this context to refer to multiple, sequential, or repeated measurements of a signal or from a signal acquisition system. For example, for an electrocardiogram (ECG), an electrical signal is acquired from the body and processed to create an ECG waveform and QRS complex. For continuous glucose monitors, a photometric or electrochemical signal generated by an assay and instrument is processed to generate glucose measurements over time. These repeated measurement outputs are considered patterns.  

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:

• Include the purpose or intended use of the product, including intended HCP users and intended patient populations
• Identify the required input medical information, with plain language instructions on how the inputs should be obtained, their relevance, and data quality requirements
• Provide a plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation, including:
• Summary of the logic or methods relied upon to provide the recommendations,
• Description of the data relied upon, and
• Description of the results from any clinical studies conducted to validate the algorithm/recommendations.

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:

• Software functions that match patient-specific medical information to reference information routinely used in clinical practice to facilitate assessments of specific patients, like a software function that uses patient diagnosis and other medical information to provide an HCP with current practice treatment guidelines for common conditions such as influenza, hypertension, and hypercholesterolemia; 
• Software functions that analyze family history, prior mammogram results, and BRCA1 status from the medical record and recommend that an HCP consider increased mammography frequency or supplemental breast ultrasound for the patient;
• Software functions that analyze the type of arthritis diagnosis in a patient record and identify prioritized treatment options available for that condition; and
• Software functions that interpret daily results of a basic metabolic panel for a hospitalized patient and recommend several options for IV fluids that may be beneficial to ensure proper hydration and to prevent acidosis.

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.”