Quick Answer: Clinical decision support (CDS) software is exempt from FDA device regulation only if it meets all four criteria in Section 520(o)(1)(E) of the FD&C Act, added by the 21st Century Cures Act in 2016 [1]. Those four criteria have not changed. What changed is FDA's final guidance interpreting them: a revised version issued 6 January 2026, and reissued with a minor correction on 29 January 2026, replacing the September 2022 guidance [1, 4]. The single biggest addition is a new enforcement discretion policy. Software that fails Criterion 3 only because it gives one specific, clinically appropriate recommendation, instead of a menu of options, can still be treated as non-device CDS if it meets the other three criteria. FDA also sharpened its definitions of "signal" and "pattern" under Criterion 1, and clarified that CDS aimed at patients or caregivers, rather than clinicians, is always a device, regardless of how the four criteria apply.

The four criteria have not moved. Read them carefully anyway.

Section 3060(a) of the 21st Century Cures Act, enacted December 2016, added Section 520(o) to the FD&C Act, carving five categories of software function out of the device definition [1]. Clinical decision support is one of them. A CDS software function is excluded from FDA's device definition, and FDA calls this "Non-Device CDS," only if it meets all four of these criteria at once:

  1. It does not acquire, process, or analyze a medical image, an IVD signal, or a pattern or signal from a signal acquisition system.
  2. It displays, analyzes, or prints medical information about a patient, or other medical information such as clinical guidelines or peer-reviewed studies.
  3. It supports or provides recommendations to a healthcare professional about prevention, diagnosis, or treatment, without directing or replacing their judgment.
  4. It enables the HCP to independently review the basis for the recommendation, so they don't rely on it primarily to make the clinical decision themselves.

Miss any one of the four, and the software is a device, full stop [1].

Criterion What it requires Typical reason software fails it
1. Inputs No medical image, IVD signal, or pattern from a signal acquisition system Analyzing a continuous or repeated measurement, not a discrete one
2. Data type Displays, analyzes, or prints medical information, not raw signals Confusing a single lab value (information) with a monitored stream (a pattern)
3. Recommendation type Supports an HCP's judgment; doesn't direct it Giving one specific directive instead of options to weigh — see the new exception below
4. Transparency HCP can independently review the basis for the recommendation Not disclosing inputs, validation data, or methodology in plain language

Best for: a manufacturer's first pass at classifying a software function before a formal 513(g) or Q-Submission. It isn't a substitute for working through FDA's own worked examples against your specific function.

FDA's own guidance is explicit that Criterion 1 and Criterion 2 work as a pair: Criterion 1 describes the inputs that keep software regulated, Criterion 2 describes the inputs that don't. A software function analyzing a raw ECG waveform to detect arrhythmias fails Criterion 1 immediately, because it's processing a signal. A software function reading an HCP's own written interpretation of that ECG ("the patient shows signs of atrial fibrillation") and suggesting treatment options is working with medical information, not a signal, and clears the first hurdle.

What actually changed: a new escape hatch for single-answer software

This is the part worth building product decisions around.

Under the 2022 guidance, if your software gave a clinician one specific recommendation, rather than a list of options to weigh, it failed Criterion 3 outright, because it was "directing" rather than "supporting" a decision. The January 2026 guidance adds a real exception: if the software fails Criterion 3 only because it gives a single, clinically appropriate output, and it meets every other criterion, FDA intends to exercise enforcement discretion. In practice, that means FDA does not intend to enforce device requirements against it.

FDA's own guidance gives seven worked examples of exactly where this line falls, each paired with a near-identical variant that doesn't qualify [1]. Two are worth sitting with.

The cardiovascular risk example

A software function that predicts cardiovascular risk from a patient's weight, smoking history, blood pressure, and BNP lab results, for an HCP to consider, qualifies for enforcement discretion even if it gives one number rather than a range of options. Add genomic data as an input with no established relevance to the recommendation, and it now fails Criteria 1 and 2 instead, landing squarely back under FDA oversight [1, 3]. Change nothing except the time horizon, from general risk to "risk in the next 24 hours," and it now fails Criterion 4, because FDA doesn't consider a clinician to have enough time to independently review a time-critical recommendation.

The antibiotic recommendation example

A software function recommending a specific FDA-approved antibiotic based on symptoms, hospitalization history, and prior antibiotic exposure also qualifies. The same function, if it also analyzes spectroscopy data to diagnose the infection itself, fails Criterion 1, because now it's processing a signal, not just recommending based on existing medical information.

The pattern across all seven examples: the enforcement discretion policy is genuinely new ground, but it's narrow. It rescues software that only stumbles on the "one answer versus many" distinction. It does nothing for software that fails on inputs, on time-criticality, or on transparency.

The transparency requirement is where most CDS actually fails

Criterion 4 is where FDA's guidance gets the most specific, and it's the criterion most digital health products fail even when everything else about them looks compliant.

FDA's own guidance includes an instructive example: software trained on 100,000 cases across ten clinical sites, with a defined outcome metric, providing an HCP a list of mammography follow-up options. That sounds like a well-validated product. FDA still classifies it as a device, because the software doesn't disclose to the HCP which specific input data it used from the patient's record, doesn't describe the independence or distribution of its training and validation datasets, and doesn't explain which variables actually drove the specific recommendation. A well-trained model that doesn't show its work fails Criterion 4 regardless of how good the underlying model is [1].

To satisfy Criterion 4, FDA recommends the software or its labeling disclose, in plain language: the intended use, user, and patient population; the specific input data required and how to obtain it; a plain-language description of how the recommendation was developed and validated, including, FDA specifically notes, "meta-analysis of clinical studies, expert panel, statistical modeling, AI/ML techniques" [1]; a description of the underlying data so an HCP can judge whether it represents their own patient population; and validation results specific enough for an HCP to gauge performance limitations.

FDA also weighs two things directly when judging Criterion 4: how automated the software is, and how time-critical the HCP's decision is. The guidance names automation bias explicitly, the tendency to over-rely on an automated suggestion, and notes it gets worse under time pressure specifically because there isn't time to review the basis for a recommendation properly [1]. That's why a software function can meet every other criterion and still fail Criterion 4 purely because of how fast a decision has to be made.

Where this leaves AI-enabled and LLM-based CDS

FDA's guidance explicitly lists "AI/ML techniques" as one of the methodologies a non-device CDS tool can use, provided it's disclosed in plain language under Criterion 4. The exemption was never about the underlying technology. It's about whether the HCP can independently understand and review the basis for what the software is telling them.

At FDA's March 2026 town hall on this guidance, an FDA reviewer was asked directly how Criterion 4 applies to large language models. The answer: an LLM-enabled function can meet Criterion 4 if it sufficiently enables an HCP to independently review the basis for its recommendations, using the same software and labeling approach as any other CDS tool 3]. Nothing in the guidance treats LLM output as inherently more or less exempt than a rules-based system. The bar is the same disclosure standard applied to any CDS software, and for [AI/ML-enabled functions generally, that disclosure burden tends to be the harder one to clear precisely because the underlying reasoning is less inherently explainable than a fixed clinical rule.

What stays regulated, no matter what

FDA's guidance is direct on two points that the enforcement discretion policy does not touch.

Patient- and caregiver-facing CDS

The guidance states this without qualification: "software functions that support or provide recommendations to patients or caregivers – not HCPs – meet the definition of a device" [1]. If your product talks to the patient directly, none of the Criterion 3 analysis above applies to it.

Alarms and alerts for life-threatening conditions

A software function that analyzes patient data to detect stroke or sepsis risk and fires an alert to an HCP fails Criteria 3 and 4 together, because an alarm is inherently a specific, time-critical directive, not a reviewable recommendation [1]. The same logic catches most continuous monitoring software: functions analyzing patterns from wearables, continuous glucose monitors, or pulse oximetry to flag deterioration consistently fail on Criterion 1, because they're processing a pattern, and again on Criteria 3 and 4, because the output drives immediate action.

How to actually check where your software lands

FDA's guidance runs 32 examples of non-device CDS and 32 examples of device software side by side, which is the closest thing to a testable rubric this guidance offers [1]. The practical process:

  1. Identify the input. If it's a medical image, an IVD signal, or a repeated pattern from a monitoring device, you're already a device under Criterion 1, and nothing downstream matters.
  2. Confirm the output is a recommendation, not a directive. A list, a prioritized list, or a set of next-step options for the HCP to weigh generally clears Criterion 3. A single output can still clear it, but only under the new enforcement discretion policy, and only if nothing else fails.
  3. Check the time horizon. If the clinical decision has to happen in minutes, not the course of an appointment, Criterion 4 is very difficult to satisfy regardless of what the software discloses.
  4. Audit your own transparency. Can an HCP see your inputs, your validation data's representativeness, and the specific basis for this patient's recommendation, not just the model's aggregate performance? If not, you likely fail Criterion 4 even with a good product.
  5. Confirm your audience is HCPs, not patients. This one has no exceptions.

If the answer is genuinely unclear after that walk-through, FDA recommends a 513(g) request for a formal device determination, or a Q-Submission meeting to discuss the analysis directly with the Digital Health Center of Excellence before you build around an assumption. Getting a wrong answer on this question is expensive in both directions: build a full quality system and 510(k) submission for something that was actually exempt, or ship a device-classified product without one and face it later as an enforcement problem rather than a design decision. Working out where your specific software function lands against FDA's own 64 examples, rather than reasoning from the general principle alone, is exactly the kind of classification judgment worth getting a second opinion on early. If your product does turn out to be a device software function, the SaMD clearance pathway from there is where Complizen's Superagent platform picks up the work, mapping your specific software function against FDA's own classification database and prior clearances rather than a general rule of thumb.

Common mistakes

Assuming a single-output recommendation is automatically exempt now. The enforcement discretion policy only rescues software that fails Criterion 3 alone. Fail any other criterion and it doesn't apply.

Treating "AI-powered" as a reason for extra scrutiny or automatic exemption. Neither is true. FDA applies the identical four-criteria test regardless of the underlying method, including AI/ML.

Building a well-validated model and assuming validation alone satisfies Criterion 4. FDA's own mammography example shows a rigorously trained model still failing because the validation details weren't disclosed to the HCP, not because the model was weak.

Assuming patient-facing versions of an HCP tool inherit the same exemption. They don't. Patient- and caregiver-facing CDS is categorically a device.

Skipping the time-criticality check. A recommendation can satisfy every other criterion and still fail Criterion 4 purely because the clinical decision has to happen too fast for genuine independent review.

Frequently asked questions

Is clinical decision support software regulated by FDA? Only if it fails to meet all four criteria in Section 520(o)(1)(E) of the FD&C Act. Software meeting all four is "Non-Device CDS" and falls outside FDA's device definition. Software failing even one criterion is regulated as a device.

What changed in FDA's January 2026 CDS guidance? The four statutory criteria are unchanged. FDA added a new enforcement discretion policy for software that fails Criterion 3 solely because it provides one clinically appropriate recommendation instead of a list of options. FDA also clarified its definitions of "signal" and "pattern" under Criterion 1 and moved the time-critical consideration from Criterion 3 to Criterion 4 specifically.

Why was the January 2026 guidance reissued on January 29? FDA's own guidance history table describes it as a minor correction on pages 13 and 14, removing a reference to time-critical decision-making that needed to align with the January 6 update moving that consideration to Criterion 4. It is not a substantive policy change from the January 6 version.

Does the enforcement discretion policy mean my single-answer CDS tool is exempt? Only if it fails Criterion 3 for that reason alone and meets the other three criteria. If it also processes a signal or image, or if the recommendation is time-critical, the enforcement discretion policy doesn't apply and the software remains a device.

Is AI-enabled or LLM-based CDS treated differently under this guidance? No. FDA applies the same four criteria regardless of methodology, and explicitly lists AI/ML techniques as an acceptable basis for a non-device CDS recommendation, provided the methodology is disclosed in plain language under Criterion 4. FDA has confirmed directly that an LLM-enabled function can meet Criterion 4 if it sufficiently enables independent review.

Is CDS intended for patients, rather than doctors, exempt from FDA regulation? No. FDA's guidance states plainly that software supporting or providing recommendations to patients or caregivers, rather than HCPs, meets the definition of a device regardless of how it performs against the other criteria.

Does an alert or alarm function qualify as non-device CDS? Generally no. Alerts for life-threatening conditions typically fail Criteria 3 and 4 together, because an alarm functions as a specific, time-critical directive rather than a reviewable recommendation an HCP has time to independently assess.

What does Criterion 4 actually require me to disclose? Plain-language descriptions of your intended use and user, your required inputs, how your recommendation was developed and validated (including the methodology, whether AI/ML or otherwise), how representative your underlying data is of the HCP's own patient population, and enough validation detail for an HCP to judge the recommendation's limitations for their specific patient.

How do I get FDA's own read on whether my software is exempt? FDA recommends either a 513(g) request for a formal device classification determination, or a Q-Submission meeting with the Digital Health Center of Excellence to discuss your specific software function against the criteria before committing to a regulatory strategy.

Does this guidance affect FDA's General Wellness policy too? FDA issued a revised General Wellness guidance on the same day, January 6, 2026 [6, 7], covering low-risk products that make no disease-specific claims. It's a related but separate exemption pathway from CDS, aimed at consumer wellness products rather than clinician-facing decision support.

Key takeaways

The four criteria are unchanged; FDA's interpretation of them moved. Read the January 2026 guidance as sharpened boundaries and new examples, not new law.

The single new mechanism is enforcement discretion for one-answer software. It's real, and it's narrow: it only rescues a Criterion 3 failure, and only when nothing else about the software fails.

Transparency, not model quality, is what Criterion 4 actually tests. FDA's own example shows a well-validated tool still classified as a device because the validation specifics weren't disclosed to the clinician.

AI and LLM methodology gets no special exemption and no special penalty. The same four-criteria test applies; the disclosure burden under Criterion 4 is simply harder to satisfy for less inherently explainable methods.

Patient-facing CDS and time-critical alerts stay regulated categorically. Neither the new guidance nor the enforcement discretion policy changes that.

Complizen helps international medical device manufacturers reach FDA 510(k) clearance, combining a software platform for in-house regulatory teams with full-service consultancy for teams without in-house FDA expertise.

If your software's exemption status genuinely isn't clear after working through FDA's own criteria, that classification call is worth getting right before you build a regulatory strategy around an assumption. Complizen's free Gap Assessment maps your specific software function against FDA's classification framework in writing, including a recommended pathway if clearance turns out to be required. Request your Gap Assessment →

References

  1. FDA — Clinical Decision Support Software, Guidance for Industry and Food and Drug Administration Staff (final guidance, issued 6 January 2026, reissued 29 January 2026). https://www.fda.gov/media/109618/download
  2. FDA — Clinical Decision Support Software (guidance document search page, confirming Final status and issuing offices). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
  3. FDA — CDRH Town Hall: Clinical Decision Support Software, Final Guidance (transcript, 11 March 2026). https://www.fda.gov/media/191560/download
  4. Federal Register — Clinical Decision Support Software; Guidance for Industry and Food and Drug Administration Staff; Availability (original 2022 final guidance notice, docket FDA-2017-D-6569). https://www.federalregister.gov/documents/2022/09/28/2022-20993/clinical-decision-support-software-guidance-for-industry-and-food-and-drug-administration-staff
  5. Covington & Burling — 5 Key Takeaways from FDA's Revised Clinical Decision Support (CDS) Software Guidance (secondary source; legal analysis). https://www.cov.com/news-and-insights/insights/2026/01/5-key-takeaways-from-fdas-revised-clinical-decision-support-cds-software-guidance
  6. Arnold & Porter — FDA "Cuts Red Tape" on Clinical Decision Support Software and Wearable Products for General Wellness (secondary source; legal analysis, covering the same-day General Wellness update). https://www.arnoldporter.com/en/perspectives/advisories/2026/01/fda-cuts-red-tape-on-clinical-decision-support-software
  7. FDA — General Wellness: Policy for Low Risk Devices, Guidance for Industry and Food and Drug Administration Staff (final guidance, issued 6 January 2026, superseding the 27 September 2019 version). https://www.fda.gov/media/90652/download