FDA Regulation of AI-Based Clinical Decision Support Software

FDA Regulation of AI-Based Clinical Decision Support Software.

The 21st Century Cures Act's line through clinical decision support

Whether AI-based clinical decision support software needs FDA clearance comes down to a four-criteria statutory test, and the 2026 guidance just moved several of those lines without touching the statute itself. Section 3060(a) of the 21st Century Cures Act, enacted December 13, 2016, amended the FD&C Act to exclude certain software from the device definition, including a bounded category of CDS Radiology Business. Congress had a real problem to solve here, not a theoretical one. Treating every piece of CDS software as a device would pull in electronic health record systems, drug interaction checkers, and clinical guideline databases that no one seriously thinks need premarket clearance. Treat none of it as a device and high-risk autonomous diagnostic tools slip through with zero oversight, making calls that used to belong to a physician.

So the statute tried to draw a line, not around the technology, but around the role the software plays. CDS that supports a clinician's judgment, leaving the human in charge of the decision, sits outside device regulation; CDS that replaces that judgment sits inside it. That distinction now lives in Section 520(o)(1)(E) of the FD&C Act, the statutory home of the four-criteria test Radiology Business.

The stakes of getting this line right have grown enormously since 2016 Radiology Business Intuition Labs. FDA cleared just 6 AI and machine learning devices in 2015; by 2025 that number had reached 295, and the pace by early 2026 had climbed to roughly 30 clearances a month, up from about 21 a month in 2024 Radiology Business Intuition Labs. A statute written for a much smaller, slower market is now the load-bearing wall for an industry moving at a very different speed. It's a gating mechanism: fail any single one of the four criteria, and the software tips into device territory, full premarket obligations and all.

The four-criteria test: why all four criteria must be satisfied simultaneously

Criterion 1 sets a bright line that's easy to state and surprisingly easy to trip over in practice Radiology Business. The software cannot acquire, process, or analyze a medical image, an in vitro diagnostic signal, or a pattern or signal coming off a signal acquisition system. The word doing the most damage here is "pattern." FDA reads it to mean multiple, sequential, or repeated measurements, things like ECG waveforms, next-generation sequencing output, or a continuous glucose monitor's stream of readings over time. A single vital sign reading taken during a visit doesn't create a pattern on its own, but the moment a product starts stitching together a sequence of measurements to say something clinical about them, Criterion 1 is in play.

Criterion 2 asks what the software actually displays or analyzes, and FDA's reading of "medical information" is broad by design. It covers patient demographics, symptoms, test results, and discharge summaries, but it also covers clinical practice guidelines, peer-reviewed literature, textbooks, FDA-approved labeling, and government recommendations. Output from an IVD device can count as medical information under Criterion 2 so long as it's used the way the device's labeling says it should be, but the moment a developer starts treating a continuous stream of that output as a pattern to be interpreted, the software circles back into Criterion 1 territory. The two criteria aren't independent checkboxes; they interact.

Criterion 3 is about supporting rather than driving clinical judgment: software must be intended to support or provide recommendations to an HCP about prevention, diagnosis, or treatment, not to make the call itself. Order sets tied to clinical guidelines, drug-drug and drug-allergy interaction alerts, tools that match a patient's record against published guidelines, and ranked lists of treatment or diagnostic options are the kinds of things that typically satisfy this criterion. The limiting principle is straightforward: the software enhances, informs, or influences a decision, but it doesn't replace or direct one. Any tool built for patients or caregivers rather than clinicians fails Criteria 3 and 4 automatically, by definition, no matter how the recommendation logic works.

Criterion 4 requires that the HCP be able to independently review the basis for the recommendation so that the HCP does not rely primarily on the software's output. The 2026 guidance spells out that this disclosure requires intended use, the intended HCP user and patient population, the inputs the software needs and how their quality gets checked, a plain-language account of how the algorithm was built and validated, and the patient-specific factors that feed into its logic. And there's a structural wall FDA has built into this criterion that no amount of good design can climb over: in time-critical settings, the agency's position is that clinicians generally cannot stop to independently review anything, so tools meant for urgent decisions face a steep uphill fight regardless of how transparent they're built to be.

What the January 6, 2026 final guidance changed

The most consequential shift sits inside Criterion 3, which requires software to be intended to support or provide recommendations to an HCP about prevention, diagnosis, or treatment, rather than drive clinical judgment. The 2022 guidance read that criterion narrowly, requiring outputs to come as a list of options and specifically excluding software that handed a clinician one specific preventive, diagnostic, or treatment directive. Analysis from Covington & Burling states that FDA will now use enforcement discretion for a single recommendation when only one option is clinically appropriate, provided the product still satisfies every other Non-Device CDS criterion. The guidance's own example is a tool that suggests one specific FDA-approved drug for a clinician to consider, based on the patient's symptoms and history. Orrick's January 9, 2026 write-up frames this as removing a genuine friction point, since developers no longer have to engineer artificial multi-option outputs purely to dodge device classification. And FDA left a real gap here too, declining to define what "clinically appropriate" actually means, which per Covington's read leaves plenty of room for aggressive commercial interpretation by developers eager to use the new flexibility.

A second shift touches Criterion 2's scope. Treatment plan recommendations now count as "verifiable medical information" under the 2026 guidance, something the 2022 version never contemplated. That's meaningful, but it comes with a condition attached: a physician still has to review it before it goes anywhere.

A third, narrower shift concerns radiology documentation tools. Software that analyzes a radiologist's own clinical findings, not the underlying image itself, to produce a draft report summary and a specific diagnostic recommendation may now fall under enforcement discretion. The conditions are tight: the tool can't touch the underlying image, since Criterion 1 still governs that, it can't pull from anything outside well-understood and accepted sources, and it still has to clear every other Non-Device CDS criterion. Covington states this signals openness to innovation in documentation workflows shaped by generative AI.

What didn't change matters just as much as what did. Arnold & Porter's analysis makes the point directly: FDA hasn't actually revised its statutory interpretation here, it has extended enforcement discretion, which is a softer, more easily revocable tool than an actual rule change. Device oversight expectations remain fully intact for opaque models, time-critical or directive tools, and anything that substitutes for clinical judgment rather than informing it. Online AI services that offer medical image interpretation directly to consumers stay squarely within FDA's jurisdiction; nothing about the Cures Act criteria exempts them. And the automation bias concern that runs through Criterion 4 wasn't erased by any of this, even as Commissioner Makary pushed back publicly on that very concern in his CES remarks. The 2026 CDS Guidance, issued January 6, 2026, supersedes the September 28, 2022 version, and both are nonbinding but authoritative signals of FDA enforcement intent. What changed, single-recommendation flexibility (Criterion 3). What changed, treatment plan recommendations (Criterion 2 scope).

Why Criterion 4 is doing the most regulatory work in 2026

Criterion 4 is the hinge the whole Non-Device CDS framework swings on. Without it, a product could satisfy the other three criteria while still operating as a fully autonomous decision-maker, because nothing else in the statute actually forces the clinician to stay in the loop. That's what makes it the criterion worth the most scrutiny in 2026, because Criterion 4 is where FDA's theory of physician authority either holds or doesn't.

Concretely, "independently review the basis" means the software and its labeling have to surface a specific set of things: what inputs are required and how they get obtained, why they're relevant, whether the data quality holds up, whether anything's missing or anomalous, and which patient-specific factors are baked into the recommendation logic.

Then there's the problem that no amount of good labeling solves the lack of time clinicians have to review a recommendation. FDA's stated position is that tools built for urgent, time-sensitive decisions generally cannot satisfy Criterion 4, because a clinician in that setting has no time to stop and independently review anything. That's a structural limitation, not a design flaw, and it means some categories of CDS are effectively locked out of Non-Device status no matter how well they're engineered.

The deeper worry Criterion 4 is trying to address is automation bias, and it isn't speculative. A 2023 paper in JAMA by Khera, Simon, and Ross documented it as a real clinical risk, the tendency of a clinician to lean too heavily on an automated suggestion once it's in front of them. Kevin MD's analysis notes that a "glass box" in theory allows clinicians to inspect AI logic, but time-pressed physicians under workflow pressure may not exercise that review in practice, since cognitive offloading is a predictable human response, not a failure of professionalism. Commissioner Makary took a different view at CES, telling the room that FDA needs to be less paternalistic and trust clinicians more, a stance that sits in visible tension with a guidance document that still leans on automation bias as a justification.

The strain shows most clearly with modern model architectures. The guidance stays noncommittal on generative AI and large language models specifically, and that silence has teeth: when an output is probabilistic rather than rule-based, producing a plain-language account of "algorithm development and validation" that a clinician can actually verify becomes a genuinely hard problem, not a paperwork exercise. For developers, Criterion 4 compliance is not a labeling exercise, it shapes what kinds of models can plausibly support a Non-Device CDS claim at all. The automation bias problem that Criterion 4 is trying to contain.

The four gaps the 2026 guidance explicitly declined to fill

FDA billed this guidance as its AI-focused update, but the document never names AI as a category, and neither did its 2022 predecessor. Arnold & Porter states that neither the 2026 CDS Final Guidance nor the 2026 General Wellness Final Guidance expressly changes FDA's current approach to AI.

Second, "clinically appropriate" remains undefined even though the entire single-recommendation flexibility discussed above hangs on that phrase. FDA extended the discretion without drawing the boundary, leaving developers to decide for themselves where the line sits, and that ambiguity invites aggressive interpretation.

Third, consumer-facing tools sit almost entirely outside this clarified framework. Symptom checkers, health chatbots, and patient decision support systems fall outside the clarified CDS framework, and the guidance does not resolve how these tools, which already shape patient expectations and clinical entry points, should be treated.

Fourth, the guidance never directly answers how a large language model is supposed to meet Criterion 4's transparency bar when its outputs are probabilistic rather than deterministic. That's not a minor omission, given how much of the current AI CDS pipeline is built on exactly that kind of model.

What comes next has been previewed, at least in outline. Commissioner Makary has described a forthcoming risk-based AI framework moving in a deregulatory direction, with more weight placed on post-marketing monitoring, and has said FDA plans to eliminate at least half of its existing software and digital health guidances, without yet specifying which ones. For planning purposes, the honest read is that the 2026 guidance resolves some real friction but isn't the final word. Developers building on generative AI foundations should expect another layer of rulemaking before this settles.

The 2026 CDS guidance's place within FDA's broader AI regulatory framework

Three separate but interconnected guidance streams now govern how AI shows up in medical devices. The January 2025 draft guidance titled "Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations" covers design, labeling, bias mitigation, cybersecurity, postmarket surveillance, and the Predetermined Change Control Plan (PCCP) for products that are regulated as devices, and it acknowledges that "AI-enabled devices span a continuum of decision-making roles".

The August 2025 final PCCP guidance, formally titled "Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions," originally issued December 4, 2024 and reissued with updates August 18, 2025, formalizes pre-authorized algorithm modification without new submissions, but PCCPs must be specific at initial submission, defining modification types, validation protocols, and performance boundaries. It lets a manufacturer pre-authorize certain algorithm modifications without filing a new submission every time the model updates, but only if the plan spells out from the start what kinds of changes are covered, how they'll be validated, and what performance boundaries can't be crossed. The January 6, 2026 CDS final guidance is the Non-Device CDS track this entire piece has walked through.

Labeling for AI and ML devices under the January 2025 guidance has to state that the device uses AI, describe its inputs, outputs, data collection, and how it interacts with other systems, report performance measures and known risks or sources of bias, and disclose PCCP monitoring and update plans where one exists. The 2025 premarket guidance calls for secure-by-design development, including threat modeling, risk assessments, update mechanisms, and a Software Bill of Materials.

Underneath all of it sits the Quality Management System Regulation. FDA issued the final rule on January 31, 2024, published in the Federal Register on February 2, 2024, amending 21 CFR Part 820 to align with international consensus standards, and it took effect February 2, 2026, applying to all device-class AI CDS. Across all three streams, the throughline is total product lifecycle thinking: clearance isn't the finish line, and ongoing algorithm monitoring, drift detection, real-world performance tracking, and managed field updates are explicit, standing expectations. For a developer whose product doesn't clear the Non-Device CDS bar, that's actually not a bad place to land. It's a demanding framework, but a defined one, with a premarket pathway, a PCCP mechanism, QMSR obligations, cybersecurity rules, and labeling requirements already mapped out, rather than a regulatory void where nobody can say what's required.

The premarket pathways for AI CDS that falls into device territory

Software that fails even one of the four criteria doesn't fall into some undefined regulatory limbo. The regulatory shift across all three streams emphasizes total product lifecycle thinking: initial clearance is not the endpoint, and ongoing algorithm monitoring, data drift detection, real-world performance tracking, and managed field updates are explicit expectations. A developer whose product does not qualify for Non-Device CDS exemption enters a framework with well-defined rules, premarket pathway, PCCP, QMSR, cybersecurity, labeling, rather than a regulatory void. The path is demanding, and it should be. Software making diagnostic or treatment calls without a clinician checking its work carries real consequences for patients, and a framework built around premarket review, defined change control, and ongoing postmarket monitoring is the appropriate response to that risk, not an obstacle standing in front of good products. Three pathways.