The FDA released an update to the Clinical Decision Support Software (CDS software) guidance yesterday (January 6, 2026) in what was a surprise move to virtually all in the FDA regulatory space. To put some historical context on the long evolution of the this guidance, which began as a glimmer in the eye with the 2016 passage of the 21st Century Cures Act, a draft was published in 2019, much to the delight of industry with new potential opportunities to operate a clinical decision software as a non-regulated product (aka Non-Device CDS software). This draft went through the typical public comment period, and after much anticipation, the final guidance landed in September 2022 with a resounding degree of shock to industry. The September 2022 final added much more stringent rules and requirements, without a comment period, that were anathema to many in the software space, particularly for those in the AI industry. This created a scenario that many regulatory professionals found extremely challenging to meet the requirements for their employers and customers, creating an impediment to AI development for those adhering to meeting all four of the required CDS software criteria.
This new final CDS software guidance will create breathing room and opportunity, particularly for the AI industry that has developed products at a rapid clip and is growing exponentially everyday. While this does constitute a landscape shift, it doesn’t remove all of the restrictions that were found to be onerous from the September 2022 version. It is worth noting that this was published without any warning or period of public comment, signaling that other final guidances may be updated in the future without a public comment period, which technically could include this CDS software guidance once again.
It is a continuing requirement that to be considered Non-Device CDS software and not subject to FDA regulation, one must meet all four the CDS software criterion and the criteria themselves remain unchanged. There is no opportunity to meet a few but not all of the criteria, but this analysis will explore what has changed in a positive direction for developers of CDS software products.
Criterion 1 still requires that Non-Device CDS software functions do not acquire, process, or analyze images, signals from an in vitro diagnostic device (IVD), or patterns or signals from a signal acquisition system. The criterion 1 definition of a signal in “A signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose…” saw the addition of “(e.g., through continuous, near-continuous, or otherwise streaming measurement).” This suggests a signal acquisition system may be Non-Device CDS software as long as the frequency of signal acquisition isn’t continuous or near-continuous, however the term “otherwise streaming measurement” is less well defined. This was further supported in added language regarding the definition of a pattern which states “…discrete, episodic, or intermittent point-in-time physiological measurements (e.g., routine vital signs obtained at discrete clinical encounters) generally do not, by themselves, constitute a pattern.”
These additions in total create major opportunities that didn’t previously exist in any concrete sense, in that signal spot checking or less than “near-continuous or otherwise streaming,” as well as pattern analysis that is “discrete, episodic, or intermittent point-in-time physiological measurements” can now be considered Non-Device CDS software per Criterion 1.
Criterion 2 also still requires that Non-Device CDS software functions display, analyze, or print medical information about a patient or other medical information. The FDA interpretation of medical information about a patient expanded to “…used in, or that relates to, the clinical care of the patient, including patient-specific information. Such information is that which may generally be communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision. Whether particular information is commonly discussed in a clinical conversation is not, by itself, determinative of whether it is “medical information about a patient” under Criterion 2, provided the information’s relevance to patient care is supported by well-understood and accepted sources and can be appropriately understood in context.” This change to “…information’s relevance to patient care is supported by well-understood and accepted sources and can be appropriately understood in context” is important, because previously the guidance said “…relevance of the information to the clinical decision being made is well understood and accepted.” The shift is subtle but substantial, in that with the new guidance, as long as one properly grounds their output information such that it can be deemed as “supported by well-understood and accepted sources,” as well as critically “appropriately understood in context,” gives AI developers a great deal of flexibility to ground their outputs in sources and provide appropriate context.
The definition of aforementioned “accepted sources” added “Generally, the kinds of information that are from “well-understood and accepted sources” are those that reflect knowledge and practices that are widely recognized and accepted within the medical or scientific community that are supported by scientific evidence, including peer-reviewed literature, clinical guidelines, or authoritative consensus documents. These can include information from sources such as medical textbooks or reference information developed by accredited medical institutions, government agencies, and professional organizations.” Lastly, text was added that states “…FDA interprets other medical information to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is similarly independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.” Both of these additions help more clearly define what source material can be used by AI models to generate their outputs but still meet Criterion 2 Non-Device CDS software requirements.
Criterion 3 still requires that Non-Device CDS software functions support or provide recommendations to a HCP about prevention, diagnosis, or treatment of a disease or condition. Despite the use of “recommendations” above, a major update landed with the addition of “If only one option is clinically appropriate and the software function otherwise meets all criteria under section 520(o)(1)(E), FDA intends to exercise enforcement discretion (meaning that FDA does not intend to enforce requirements under the FD&C Act) for such functions.” The impact of this change cannot be overstated, as Non-Device CDS software is now allowed to give a single recommendation, as opposed to giving multiple recommendations that a HCP then has to pick the most likely candidate from.
Due to the significance of this change, the FDA added numerous examples to illustrate scenarios where a single recommendation would be consistent with Non-Device CDS software, and where such situations would be subject to FDA authority. These examples are extremely helpful to give industry a clearer path to what is allowable under this single recommendation paradigm and seven of them are described below:
“A software function that predicts risk of future cardiovascular events for an HCP to consider based on a patient’s weight, current and historical smoking status, blood pressure, and brain natriuretic peptide (BNP) in vitro diagnostic (IVD) test results.
- However, a software function with the same functionality, but also utilizes variant genomic data as an input that does not have established relevance to the diagnostic recommendation, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.
- However, a software function with the same functionality, but predicts risk of a cardiovascular event in the next 24 hours, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
“A software function that creates a recommended treatment plan, including possible medication(s), for patients diagnosed with cognitive impairment for an HCP to consider based on the patient’s diagnosis related to cognitive impairment as well as potential comorbidities, age, sex, and patient preferences, and that should be reviewed, revised, and finalized by an HCP.
- However, a software function with the same functionality, but also analyzes positron emission tomography (PET) scan images, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
“A software function that recommends a specific FDA-approved antibiotic agent for an HCP to consider based on the patient’s symptoms, recent hospitalizations, and previous antibiotic exposure.
- However, a software function with the same functionality, but also analyzes spectroscopy data to diagnose bacterial infections, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
“A software function that analyzes a radiologist’s clinical findings of an image to generate a proposed summary of the clinical findings for a patient’s radiology or pathology report, including a specific diagnostic recommendation based on clinical guidelines that should be reviewed, revised, and finalized by an HCP
- However, a software function with the same functionality, but also analyzes the image to generate the clinical findings and/or make measurements, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.
- However, a software function with the same functionality, but utilizes information that cannot be verified and validated to be from well-understood and accepted sources to generate a specific diagnostic recommendation, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
“A software function that provides an HCP with a differential diagnosis based on a patient’s symptoms, vital signs, and laboratory values, and that, depending on the clinical context, may present either multiple diagnostic considerations or a single clinically appropriate diagnostic recommendation when alternative diagnoses are highly improbable. The output is intended to support clinical reasoning and to be reviewed, revised, and finalized by the HCP.
- However, a software function that establishes a definitive diagnosis based on analysis of medical images, waveform data, or other signal-level inputs would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
“A software function that classifies patients with chronic low back pain into a single recommended appropriate clinical care pathway (e.g., conservative management or referral to a surgical spine specialist) based on patient history, symptom duration, and documented clinical findings, where the recommendation is intended to be reviewed and acted upon by an HCP.
- However, a software function that provides care pathway recommendations for patients with acute back pain due to trauma or other emergent conditions, where immediate clinical intervention may be required, would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
“A software function that estimates 90-day and 1-year postoperative mortality and complication risk following lung transplantation based on patient-specific clinical characteristics and published clinical evidence, where the output is intended to support pre-transplant planning and shared decision-making and is reviewed by an HCP.
- However, a software function that predicts intraoperative or in-hospital mortality based on near real-time physiologic measurements and is intended to guide immediate escalation of care would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.
- However, a software function that incorporates medical images, genomic data, or other data sources that are not well-understood and accepted for the stated clinical use would not fall under this example. Such a software function is a device software function that would remain the focus of FDA’s oversight.”
These examples give a lot of opportunity to a broad range of hospital, office and outpatient clinic based care for CDS software in a more focused and utilitarian manner. Numerous locations in criterion 3 deleted statements related to “time-critical” attached to alerts, decisions or decision-making, however Criterion 3 still retains the text that states “Software functions that provide the following outputs may also be considered “supporting or providing recommendations to an HCP” and would meet Criterion 3, as long as they were not intended to support time-critical decision-making and/or replace or direct the HCP’s judgment.” It is notable that the first and last examples above of single recommendation situations mentioned time factors in relation to care and how that may be subject to FDA’s oversight. As such, it is clear that time-critical decision-making is still an exclusion from non-device CDS for Criterion 3 and time-critical decision-making products are subject to FDA’s regulatory oversight. Examples of the time-critical impact are expanded upon in the examples given for regulated devices in Sections V(b) Examples of Non-Device CDS Software Functions and V(c) Device Software Functions of the guidance.
Lastly, Criterion 4 still requires Non-Device CDS software functions provide sufficient information about the basis for the recommendations to the HCP user, so that the user does not rely primarily on any of the recommendations to make a clinical decision about an individual patient. Labeling requirements were softened with the addition that “…A summary of the general approach…AI/ML techniques), at a level of detail appropriate for the intended user and use environment, which could include, for example, the logic or methods relied upon” simply needs to be “sufficient for the intended HCP user to understand the basis of the recommendation.” Furthermore the labeling requirements saw an addition that to provide adequate background information “about underlying sources in plain language. Information that enables an HCP to independently review the basis of provided recommendations is presented in a manner that promotes usability and avoids information overload, including prioritizing the most decision-relevant information and making additional detail available as appropriate.” Taken in conjunction, these additions to the guidance give a great deal of leeway to the AI industry to describe how their system functions to the “level appropriate for the intended user,” with a clear preference for “clear language” that “promotes usability and avoids information overload” and only “making additional detail available as appropriate.”
CDS software companies have been given great opportunities with this new guidance. With greater definitions and clarity as to what is allowable, the freedom to operate for the AI industry in particular has never been greater to create Non-Device CDS software, which is critical as speed to deployment is rapidly accelerating. Newer technologies now have clearer paths on development requirements starting from the ground up, and existing companies who are currently selling CDS software products would be well served in lining up their technologies appropriately per this guidance to ensure they are non subject to FDA oversight. This certainly bodes for a year of great technological change, and with this new CDS Software guidance and the new final General Wellness guidance also recently released, the FDA appears ready and willing to be a partner to the expansion of CDS software to aid both HCPs and their patients. This position was crystalized by FDA Commissioner Dr. Marty Makary, who was interviewed in reference to this CDS software guidance release and stated “…if something is simply providing information, like ChatGPT or Google, we’re not going to outrun that lion, we’re not going to go in there and say, well there is one result that is inaccurate so we’re going to shut that down. We have to promote these products and at the same time guard against major safety concerns.”
