In January, FDA revised its clinical decision-support guidance to address software that gives a clinician a single clinically appropriate recommendation. One example recommends a particular antibiotic using information about the patient. The clinician reviews the recommendation and decides what to prescribe.
That sounds like a familiar division of responsibility. The software advises. The clinician decides. But that description leaves an important question unanswered: what information does the clinician have to evaluate the advice?
The revised policy preserves that question. A clinician’s authority to reject a recommendation does not, by itself, establish that the clinician can independently assess its basis.
One Recommendation Does Not Settle the Regulatory Question
FDA issued the revised final guidance on January 6 and reissued it on January 29. It describes enforcement discretion for certain functions offering one clinically appropriate recommendation when the other statutory criteria are satisfied. That is different from excluding the function from the medical-device definition.
This distinction matters for developers describing their regulatory position. A policy under which FDA does not intend to enforce device requirements is not the same as a statutory conclusion that those requirements do not apply.
The guidance is nonbinding. The underlying software exclusion comes from the 21st Century Cures Act, which added section 520(o) to the Federal Food, Drug, and Cosmetic Act. Congress excluded certain software functions from the device definition, subject to specific conditions. January’s guidance interprets those conditions and describes FDA’s enforcement approach; it did not create a general exemption for clinical AI.
The Law Asks What the Clinician Can Review
FDA reads the statutory CDS exclusion as setting four criteria. Broadly, they concern the inputs the software analyzes, its use of medical information, recommendations directed to a healthcare professional, and independent review of their basis. The exclusion does not cover analysis of medical images or specified signals and patterns. All four criteria matter.
The fourth requires that the software be intended to enable the professional to independently review the basis for its recommendations, so the professional is not intended to rely primarily on them when making an individual patient’s diagnosis or treatment decision.
This is a question about the support available for clinical judgment. A signature establishes who approved the decision. It does not establish what that person could assess before approving it.
The Basis Has to Be Useful to the Intended Clinician
In a March webinar on the guidance, CDRH staff describe information that supports independent review: the intended use and user, required inputs, a plain-language account of development and validation, and relevant patient-specific information and unknowns. FDA also emphasizes usability and avoiding information overload.
Consider a hypothetical tool that recommends a treatment. Its screen identifies the patient and displays an answer, accompanied by a general statement that a clinician must review it.
The clinician can accept or reject the answer. But the screen does not explain which patient information affected it or whether the supporting evidence applies to this patient. The instruction to review supplies no missing evidence.
Now suppose the product makes its relevant inputs and supporting evidence available in a form the intended clinician can use. It identifies a missing result and explains a limitation affecting this patient’s circumstances. The clinician has a basis for questioning the recommendation and deciding whether more information is needed.
Those hypothetical designs illustrate the difference between assigning review and enabling it. They are not FDA determinations about particular products, and neither description alone resolves all four statutory criteria.
Validation Has to Reach the Patient in Front of the Clinician
The guidance recommends describing the development data and clinical validation results so clinicians can assess population relevance and performance limitations. It also addresses missing or unexpected patient inputs. These disclosures help connect evidence about a tool to the individual decision. See FDA’s discussion of independent review.
An organization evaluating such a tool should therefore ask more than whether a validation study exists. It should examine what the study establishes for the intended use and what the clinician will know when applying the output.
For example, if evidence does not establish performance for a particular patient group, a polished recommendation does not close that gap. The practical question is whether the limitation is visible and understandable when it matters.
Time Can Limit the Review That Is Possible
FDA’s March presentation also identifies automation bias: following incorrect automated advice, or failing to act because the system gave no prompt. It considers both automation and the time available for a clinical decision when assessing independent review.
An explanation that can be examined during planned care may offer little help when immediate action is required. The existence of explanatory material does not establish that the intended user has a realistic opportunity to use it.
The distinction concerns the task, not simply the location. FDA’s CDS FAQs explain that software supporting time-critical decisions generally cannot meet the non-device CDS criteria, while useful information-retrieval software in an emergency department can still qualify. The same FAQs distinguish non-device functions from functions subject to enforcement discretion.
