The regulatory landscape for clinical decision support (“CDS”) software is shifting. On January 29, 2026, the FDA issued the guidance on CDS software (“Revised Guidelines”) that changed how certain risk factors in healthcare software are regulated. Understanding these new rules is critical for anyone developing tools that support clinical decision-making.
Is Clinical Decision Support Software subject to regulation as a Medical Device?
A software function is a medical device if it performs a medical device function. Section 201 of the Food and Drug Control Act (“FD&C Act”) recognises software functions that support diagnosis, cure, mitigation, treatment or prevention of disease as medical device functions. However, certain software functions are excluded from the definition of ‘device’ under section 520(o) of the FD&C Act, of which CDS is one subset.
Software functions that meet all of the following four criteria are excluded from classification as regulated devices:
- Does not intend to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system (“Criterion 1”). This relates to the permitted input data for non- device CDS. The Revised Guidelines clarified that if a software takes a single, discrete physiological measurement, this would not constitute a pattern and therefore not be considered a device. This clarification broadens the scope of non-device CDS by permitting software that relies on intermittent or point-in-time physiological measurements, provided the software is not intended to monitor a vital parameter.
- Intended for the purpose of displaying, analysing, or printing medical information about a patient or other medical information. This relates to the nature of the software’s output. The Revised Guidelines clarify that “medical information about a patient” includes patient-specific information used in clinical care. Software that displays, analyses, or prints such information may qualify as CDS, provided the remaining criteria are satisfied. This clarification confirms that software may process and analyse patient-specific clinical information while remaining within the CDS exclusion, provided the remaining criteria are satisfied.
- Intended for the purpose of providing recommendations to a health care professional (“HCP“) rather than providing a specific output or directive that replaces HCP’s judgment (“Criterion 3”). The Revised Guidelines introduce an enforcement discretion policy for software functions that provide a single recommendation where it represents the only clinically appropriate option. This recognises that certain CDS tools may generate a single recommendation without necessarily replacing the independent judgment of the HCP, provided the remaining criteria are met.
- Criterion 4 focuses on the ability of the HCP to independently review the basis of a recommendation (“Criterion 4”). To satisfy this requirement, the Revised Guidelines emphasise that developers should provide the most decision-relevant information to intended users, tailored to their role and presented in a manner that can be independently understood.
The Revised Guidelines further discuss that software functions supporting time-critical decisions are not device functions per se, but are considered a risk to independent review by the HCP. This is because HCPs are more susceptible to automation bias when they lack the time to adequately review the basis of recommendations, causing the software function to fail Criterion 4. For example, if a software analyses patient-specific information to detect strokes and generates an alarm and notifies the HCP, this is a time-critical function that fails to facilitate independent review. The Revised Guidelines strengthen the guardrails of transparency and accountability in clinical decision-making. Where software functions use AI, the risk of a ‘black box’ emerges. This means that the logic and methods being used by the software function are unknown to users. The revised Criterion 4 addresses this by requiring the software to facilitate independent review, in the manner described, for the software to be classified as not a device. Developers of AI-enabled medical software often work with a healthcare & life sciences law firm to address evolving regulatory and compliance requirements.
Are software functions providing recommendations to patients and caregivers considered medical devices?
The Revised Guidelines, aligned with the Policy for Device Software Functions and Mobile Medical Application, recognise software functions that provide recommendations to patients, caregivers, or other users who are not HCPs, as medical devices. Software functions that monitor patients, interpret signals or analyse patient-specific information to detect time-critical or serious medical conditions, and alert the HCP, are considered device functions. The FDA’s treatment of patient-facing recommendations also highlights the importance of distinguishing regulated medical software from products intended solely to support general health and wellness. This distinction is reflected in the FDA’s General Wellness Policy.
Distinguishing Clinical Decision Support from General Wellness Software
The Revised Guidelines also highlight the distinction between CDS software and products falling within the FDA’s General Wellness Policy. While both categories may fall outside active medical device regulation, they do so for different reasons. CDS software is used in clinical contexts and may provide recommendations relating to patient care, provided that healthcare professionals retain the ability to independently review and evaluate the basis of those recommendations. In contrast, General Wellness Products are intended for non-clinical purposes, such as promoting healthy lifestyles or maintaining general well-being. These products may track metrics such as sleep, exercise, weight, or heart rate, and may utilise AI-driven features, provided they do not diagnose, treat, mitigate, cure, or prevent a specific disease. Software that transitions from general wellness management to disease-specific recommendations may be classified as a medical device. These distinctions are particularly important for developers, as they provide insight into the factors that the FDA considers when determining whether a software function falls within or outside device regulation.
Key Takeaways
The 2026 revisions to the regulatory guidance on non- device software provide clarity on the classification of software functions based on the risks posed by them. This highlights the importance of the developer’s ability to explain the core design of their products to the intended user and increase transparency. The key risk factors that change regulatory treatment of s software are as follows:
(a) Intended use and medical Intent of the software;
(b) Intends to support time-critical situations or for severe conditions;
(c) The degree to which the software influences clinical decision making, that is, whether it treats or diagnoses, drives clinical decisions or informs clinical decisions;
(d) The potential harm to patients, caregivers and other users if the device does not function as intended;
(e) Facilitation of Transparency and review by an HCP.
The Revised Guidelines offer flexibility in applying the CDS qualifying criteria regarding permissible inputs (single point physiological measures) and permissible circumstances for single recommendation outputs. However, they retain focus on preserving independent clinical judgment. By placing responsibility on software developers to facilitate meaningful human review, the FDA requires developers to embed human oversight into the design of AI-enabled healthcare tools, an area where best technology lawyers can provide strategic legal guidance.
Authors: Shantanu Mukherjee, Maitreyi Ramdas
