Clinical decision support (CDS) software analyzes patient information and provides healthcare professionals with recommendations for prevention, diagnosis, or treatment. Whether FDA regulates it as a medical device depends on four criteria in section 520(o)(1)(E) of the FD&C Act: software that meets all four is “non-device CDS” and falls outside FDA device oversight, while software that fails any one is a device.
FDA explains how it applies those criteria in its Clinical Decision Support Software guidance, revised in January 2026. The revision kept the four criteria but changed how FDA treats single recommendations, risk scores, and time-critical decisions. This guide covers what CDS software is, how to test your product against the criteria, and examples of devices and non-devices from the guidance.
Is your CDS software a device? The four criteria
Criterion | What the statute requires | How FDA reads it in 2026 | Fails when the software… |
|---|---|---|---|
1. Input | Does not acquire, process, or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system | Discrete, point-in-time measurements “generally do not, by themselves, constitute a pattern.” Continuous glucose monitor readings are “a pattern/signal” | Analyzes images, ECG waveforms, CGM streams, or other continuous signals |
2. Information | Displays, analyzes, or prints medical information about a patient or other medical information | Relevance must be supported by “well-understood and accepted sources.” Whether information is commonly discussed in a clinical conversation “is not, by itself, determinative” | Relies on inputs whose clinical meaning is not established, such as genomic variants of unknown relevance |
3. Recommendation | Supports or provides recommendations to a healthcare professional | Software that gives a specific output still fails, but FDA “intends to exercise enforcement discretion” when only one option is clinically appropriate, and the other criteria are met | Directs a specific action, or gives recommendations to patients or caregivers |
4. Independent review | Enables the healthcare professional to independently review the basis for the recommendation, so they do not rely primarily on it | FDA “does not consider software functions intended for a critical, time-sensitive task or decision to meet Criterion 4” | Supports urgent decisions, or hides the logic and data behind its output |
Two points are easy to miss. First, enforcement discretion does not make software non-device; it is still a device, and the FDA simply does not intend to enforce device requirements on it. Second, the criteria apply only to software for healthcare professionals. Software that gives recommendations to patients or caregivers does not qualify as non-device CDS.
Device and non-device CDS examples
The 2026 guidance includes 47 examples. These show where the lines fall:
Software function | FDA’s view | Why |
|---|---|---|
Reminds clinicians to order a hemoglobin A1C test for patients with diabetes | Non-device | Uses medical information, supports a clinician, and the basis is reviewable |
Analyzes blood glucose lab results and a prediabetes diagnosis from the record, then lists next-step options for the clinician | Non-device | Discrete lab results are medical information, not a pattern |
Generates a proposed summary of the clinical findings for a radiology or pathology report, without analyzing the image | Non-device | Works from the clinician’s findings, not the image |
Recommends a specific FDA-approved antibiotic for a clinician to consider, when only one option is clinically appropriate | Enforcement discretion | Specific output, but only one appropriate option |
Predicts a patient’s risk of future cardiovascular events for a clinician to consider | Enforcement discretion | Risk estimate that supports, rather than directs, a non-urgent decision |
Predicts a cardiovascular event in the next 24 hours | Device | Time-critical |
Analyzes CGM readings every 30 minutes to detect potential hypoglycemia and notify the clinician | Device | Analyzes a pattern, and supports a time-critical decision |
Calculates a bolus insulin dose for a patient from carbohydrate intake, pre-meal glucose, and planned activity | Device | Intended for the patient, not a clinician, and time-critical |
Analyzes a medical image to flag a finding | Device | Analyzes an image |
CDS for diabetes and insulin dosing
Diabetes software is where the criteria bite hardest because most of it relies on sensor data or supports rapid decision-making.
- CGM data is a pattern. Software that analyzes CGM readings fails Criterion 1, however simple the analysis. The guidance’s hypoglycemia example fails Criteria 1 and 2, as well as Criteria 3 and 4, because it provides a specific diagnostic output and supports a time-critical decision.
- A single glucose value is medical information. FDA says “a single, discrete test or measurement result,” such as a blood glucose lab result, is medical information. Clinician software that works from discrete lab results can be non-device CDS.
- Bolus calculators for patients are devices. A patient-facing insulin dose calculator fails Criterion 3 because it is not intended for clinicians, and fails Criterion 4 because insulin decisions are time-critical. Insulin dose calculators are usually cleared through a 510(k) under product code NDC, and CGM-informed calculators under product code QRX.
- Dosing algorithms that command a pump are not CDS at all. They are interoperable automated glycemic controllers, regulated under 21 CFR 862.1356.
For how FDA regulates each of these functions, including AID algorithms and glucose prediction, see our guide to AI in diabetes devices.
If your CDS software is a device
Failing a criterion does not mean a long or uncertain path. Many CDS device functions are Class II and reach the market through a 510(k) or a De Novo request. What changes is how you build:
- Quality system. Development follows FDA’s Quality Management System Regulation (21 CFR Part 820), which has incorporated ISO 13485 since February 2, 2026.
- Software lifecycle and risk. Plan for IEC 62304 software lifecycle processes and ISO 14971 risk management from the first requirement.
- Submission documentation. Prepare software documentation at the Basic or Enhanced level FDA expects for device software functions.
- AI and model updates. If the CDS uses a machine learning model you plan to retrain, consider a predetermined change control plan (PCCP) so planned updates do not each need a new submission.
Make the call early. Adding a single-device function, such as a CGM-based alert, late in development can affect your documentation level and timeline. Our guide to SaMD regulatory pathways walks through the options.
Frequently asked questions
Is clinical decision support software FDA-regulated?
It depends on what the software does. Under section 520(o)(1)(E) of the FD&C Act, CDS software is excluded from the device definition only if it meets all four criteria: it does not analyze medical images or signals, it uses medical information, it supports a healthcare professional’s recommendation, and it lets that professional independently review the basis. Software that fails any criterion is a device.
Which is an example of clinical decision support software?
Common examples include drug interaction alerts, reminders to order screening tests such as an A1C for patients with diabetes, order sets based on clinical guidelines, and risk calculators. Under FDA’s 2026 guidance, a reminder to order an A1C test is non-device CDS, while software that analyzes CGM readings to detect hypoglycemia is a device.
What changed in the FDA’s 2026 CDS guidance?
The January 2026 guidance keeps the four criteria but changes how FDA applies them. FDA intends to exercise enforcement discretion for software that provides a specific recommendation when only one option is clinically appropriate, and for some risk-prediction tools. Time-critical decisions are now addressed under Criterion 4, and FDA clarified that discrete, point-in-time measurements are generally not a pattern.
What is non-device CDS?
Non-device CDS is clinical decision support software that meets all four criteria in section 520(o)(1)(E) of the FD&C Act, so it is not a medical device. It supports a healthcare professional’s decision-making with well-established medical information and allows the professional to review the basis for each recommendation.
Can patient-facing software be non-device CDS?
No. The non-device CDS criteria apply only to software that supports healthcare professionals. Software that gives recommendations directly to patients or caregivers, such as an insulin bolus calculator in a patient app, is a device under FDA’s guidance, though FDA may apply other policies, such as its general wellness or enforcement discretion policies, to some low-risk functions.
Does the 2026 CDS guidance cover AI?
Only in passing. The guidance applies the same four criteria to AI-based CDS, and it mentions statistical modeling and AI/ML techniques as methods a developer should disclose so clinicians can review the basis for a recommendation. It does not set AI-specific rules. FDA addresses AI-enabled devices in separate guidance, including its final guidance on predetermined change control plans.
When is CDS software considered a medical device?
CDS software is a device when it fails any of the four criteria: for example, when it analyzes images or continuous signals such as CGM data, gives recommendations to patients rather than clinicians, or supports time-critical decisions that a clinician cannot realistically review.
