FDA Clinical Decision Support (CDS) Software: Non-Device vs Device Classification Guide (2026)
Complete guide to FDA's January 2026 Clinical Decision Support software guidance — the four statutory criteria for non-device CDS exclusion under Section 520(o)(1)(E), device vs non-device examples, SaMD boundary decisions, enforcement discretion positions, and practical compliance strategies for digital health companies.
FDA's 2026 CDS Guidance Redefined the Boundary Between Regulated Software and Non-Device Tools
On January 6, 2026 — and superseded by a revised version on January 29, 2026 — the FDA issued its updated final guidance on Clinical Decision Support (CDS) software. The guidance clarifies which CDS functions are excluded from the definition of a medical device under Section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), as amended by Section 3060(a) of the 21st Century Cures Act.
The 2026 update supersedes the 2022 CDS guidance and brings significant clarifications: a softened stance on software that provides a single recommendation, new examples of clinical documentation tools, expanded transparency requirements, and a refined approach to time-critical decision-making. It remains silent on consumer-facing tools and AI-specific regulation, leaving critical questions for future guidance.
This guide provides a complete walkthrough of the four statutory criteria, detailed device vs non-device examples, the practical implications of the 2026 updates, and compliance strategies for digital health companies.
Background and Legislative Framework
The 21st Century Cures Act and Section 520(o)(1)(E)
The 21st Century Cures Act, enacted on December 13, 2016, amended Section 520 of the FD&C Act to exclude certain software functions from the definition of a medical device under Section 201(h). Among these exclusions, Section 520(o)(1)(E) specifically addresses Clinical Decision Support software.
Software functions that meet all four of the following criteria are excluded from the device definition and are not subject to FDA regulation as medical devices:
| Criterion | Summary | Key Question |
|---|---|---|
| Criterion 1 | Not intended to acquire, process, or analyze medical images, IVD signals, or patterns/signals from signal acquisition systems | Does your software analyze images, IVD signals, or physiological patterns? |
| Criterion 2 | Intended to display, analyze, or print medical information about a patient or other medical information | Does your software work with discrete medical information (lab results, diagnoses, medication lists)? |
| Criterion 3 | Intended to support or provide recommendations to an HCP about prevention, diagnosis, or treatment — without replacing HCP judgment | Does your software support the clinician or direct/drive the clinical decision? |
| Criterion 4 | Enables the HCP to independently review the basis of recommendations and not rely primarily on them | Can the clinician understand why the recommendation was made and evaluate it independently? |
If any one criterion is not met, the software function is a device and is subject to FDA regulation.
The 2026 Update: What Changed
The January 2026 guidance (revised January 29, 2026) represents the most significant update since the 2022 guidance. FDA Commissioner Marty Makary framed it as intended to "cut unnecessary regulation and promote innovation." The key changes include:
| Change | 2022 Position | 2026 Position |
|---|---|---|
| Single recommendation | Providing only one treatment option was generally considered a device function | FDA will exercise enforcement discretion when a single option is clinically appropriate |
| Clinical documentation | Not explicitly addressed | Summarization and report generation for HCP review may be non-device |
| Time-critical decisions | Explicit exclusion from non-device CDS | Removed as a standalone criterion; now folded into Criterion 4 (transparency/independent review) |
| Transparency | Required but less detailed | Extensive requirements: inputs, data quality, logic description, patient-specific factors |
| Consumer/patient tools | Mentioned briefly | Silent — existing digital health policies continue to apply |
Criterion 1: The Bright Line — Images, Signals, and Patterns
Criterion 1 is the most categorical gate. If your software acquires, processes, or analyzes any of the following, it generally fails Criterion 1 and is a device:
What Fails Criterion 1
| Input Type | Examples |
|---|---|
| Medical images | CT scans, MRI, X-ray, pathology slides, dermatology images |
| IVD signals | Assay signals, PCR amplification curves, flow cytometry data |
| Physiological patterns | ECG waveforms, QRS complexes, EEG patterns |
| Signal acquisition system outputs | Continuous glucose monitor readings, pulse oximetry waveforms, blood pressure waveforms |
| Genomic data | Next-generation sequencing (NGS) variant datasets, VCF files |
The "Pattern" Concept — A Critical Pitfall
The 2026 guidance clarifies that "pattern" means multiple, sequential, or repeated measurements. This is a key distinction:
| Discrete Data Point (Generally OK) | Pattern/Signal (Generally Device) |
|---|---|
| A single blood pressure reading | Continuous blood pressure waveform |
| One lab result (glucose = 120 mg/dL) | Continuous glucose monitor readings over time |
| A discrete SpO2 measurement | Streaming pulse oximetry data |
| An ECG interpretation by a clinician | Raw ECG waveforms with QRS complexes |
The guidance provides that discrete or episodic measurements (e.g., vital signs collected at a clinical visit) are generally well understood and do not constitute "patterns." But continuous or near-continuous measurements used for medical purposes do.
What Passes Criterion 1
Software that works with the following types of "medical information" generally meets Criterion 1:
- Lab results (stored in EHR)
- Blood pressure readings (discrete measurements)
- Medication lists
- Diagnosis codes
- Clinical notes and radiology reports
- Published clinical guidelines and literature
- Patient demographic information
Criterion 2: Displaying, Analyzing, or Printing Medical Information
Criterion 2 requires that the software is intended to display, analyze, or print "medical information about a patient or other medical information."
What Counts as "Medical Information"
The 2026 guidance provides expanded examples:
| Category | Examples |
|---|---|
| Patient-specific data | Lab results, vital signs (discrete), medication history, diagnoses, demographics |
| Clinical reference data | Clinical practice guidelines, drug formularies, dosing tables |
| Processed clinical outputs | Radiology reports or summaries from legally marketed software, ECG reports annotated by clinicians |
| Published evidence | Peer-reviewed literature, systematic reviews, clinical trial results |
Key Clarification in 2026
The guidance clarifies that device outputs — including IVD test results — can be "medical information" under Criterion 2 when used consistent with FDA-required labeling. However, using continuous outputs as a pattern may trigger Criterion 1 concerns.
Criterion 3: Supporting (Not Driving) the HCP's Decision
Criterion 3 is where the 2026 update made the most significant changes. The guidance describes Non-Device CDS as software that "enhances, informs, or influences" an HCP's decision-making without "replacing or directing" the HCP's judgment.
What Passes Criterion 3
The guidance provides extensive examples of CDS functions that typically meet Criterion 3:
| Function Type | Examples |
|---|---|
| Order sets | Evidence-based clinician order sets tailored to specific conditions |
| Drug interaction alerts | Drug-drug and drug-allergy interaction warnings |
| Clinical guideline matching | Matching patient information to reference clinical guidelines |
| Medication reconciliation | Tools that compare medication lists across settings |
| Duplicate testing warnings | Alerts when redundant tests have been ordered |
| Preventive care reminders | Notifications for overdue screenings based on guidelines |
| Risk estimation | Calculating future risk based on patient factors (smoking, weight, age) |
| Clinical documentation | Summaries and proposed reports for HCP review and finalization |
| Patient data reports | Discharge papers, encounter summaries |
The 2026 Single-Recommendation Shift
In the 2022 guidance, providing a single specific recommendation was generally considered to fail Criterion 3. The 2026 update softens this position: FDA intends to exercise enforcement discretion when a CDS function provides only one recommendation if that single option is clinically appropriate.
For example, a software function that identifies that a patient is within the indicated population for a specific FDA-approved chemotherapeutic agent based on diagnosis and biopsy results would now fall under enforcement discretion rather than being actively regulated as a device.
What Fails Criterion 3
| Function Type | Why It Fails |
|---|---|
| Automated diagnosis | Replaces HCP diagnostic judgment |
| Specific treatment directive | Directs rather than supports clinical decision |
| Triage decision automation | Makes clinical triage decision without HCP review |
| Real-time critical alerts without context | Provides directive output without supporting HCP independent judgment |
Criterion 4: Transparency and Independent Review
Criterion 4 requires that the software enables the HCP to independently review the basis of the recommendation. The 2026 guidance significantly expands the transparency requirements.
What Non-Device CDS Must Provide
The FDA identifies specific transparency elements that must be available — through software output, labeling, or documentation — for HCPs to independently evaluate recommendations:
| Transparency Element | Description |
|---|---|
| Intended use | Clear description of what the software does and its purpose |
| Intended user | Identification of the qualified HCP audience |
| Intended patient population | Specific patient groups the software is designed for |
| Inputs and data requirements | What data the software uses and the quality requirements |
| Algorithm development and validation | Plain-language description of how the algorithm was built and tested |
| Patient-specific knowns and unknowns | What patient-specific information was used and what limitations exist |
| Logic description | How inputs are transformed into outputs |
| Data quality requirements | What data quality is needed for reliable outputs |
Time-Critical Decisions in 2026
The 2026 guidance removed the explicit "time-critical" exclusion from Criterion 3 and moved the concern to Criterion 4. The reasoning: in time-critical situations, the HCP has less ability to independently review the basis of recommendations, creating "automation bias" risk.
Software that predicts risk of a cardiovascular event in the next 24 hours, for example, remains a device function because Criterion 4 (independent review) cannot be met in the time-critical context.
However, merely being used in a setting where time-critical decisions occur (e.g., an emergency department) does not automatically disqualify software. Software that pulls up relevant patient information to enhance efficiency can still be Non-Device CDS even in the ED.
CDS for Patients and Caregivers: Device Territory
The guidance is clear: the Non-Device CDS exclusion applies only to software intended for use by healthcare professionals. Software that provides decision support directly to patients or caregivers is generally a device if it meets the device definition.
The FDA's existing digital health policies continue to apply to these products:
- Policy for Device Software Functions and Mobile Medical Applications
- Software as a Medical Device (SaMD): Clinical Evaluation
- General Wellness: Policy for Low Risk Devices
Device vs Non-Device CDS: Comparison Table
| Dimension | Non-Device CDS | Device CDS |
|---|---|---|
| Legal status | Excluded from device definition under Section 520(o)(1)(E) | Meets device definition under Section 201(h) |
| FDA regulation | Not regulated as a device | Subject to FDA device regulation |
| Input types | Discrete medical information | Images, IVD signals, physiological patterns |
| Output type | Recommendations for HCP review | Specific diagnostic or treatment outputs |
| User | Healthcare professionals only | May include patients and caregivers |
| Transparency | Must enable independent review | Must meet applicable device requirements |
| Premarket review | Not required | May require 510(k), De Novo, or PMA |
| Quality system | Not required (QMSR does not apply) | Must comply with QMSR (21 CFR 820) |
| Registration/listing | Not required | Required |
| Post-market reporting | Not required (under FDA device authority) | MDR, correction/removal reporting |
Practical Compliance Strategy
Step 1: Map Your Software Functions
Break down your software into individual functions and evaluate each function against all four criteria. A single software product may contain both non-device and device functions.
Step 2: Apply the Four-Criteria Test
For each function:
| Criterion | Question | If Yes | If No |
|---|---|---|---|
| 1 | Does it acquire/process/analyze images, IVD signals, or patterns? | Device | Continue to Criterion 2 |
| 2 | Does it display/analyze/print medical information? | Continue to Criterion 3 | Likely device |
| 3 | Does it support (not direct) HCP decisions? | Continue to Criterion 4 | Device (or enforcement discretion may apply) |
| 4 | Can the HCP independently review the basis? | Non-Device CDS | Device |
Step 3: Document Your Analysis
Even for Non-Device CDS, document:
- How each criterion is met
- The types of inputs used and why they qualify as "medical information"
- How the software supports (rather than replaces) clinical judgment
- The transparency elements provided to HCPs
- Any reliance on enforcement discretion positions
Step 4: Monitor Regulatory Evolution
The 2026 guidance does not address AI-specific regulation, consumer-facing tools, or how enforcement discretion will be operationalized. Companies should:
- Track FDA enforcement actions in the digital health space
- Monitor any follow-up guidance documents
- Engage with FDA through the Q-Submission program for borderline cases
- Consider whether product modifications might shift the classification
FAQ
What is Clinical Decision Support (CDS) software?
CDS software provides healthcare professionals with information and recommendations to support clinical decision-making about prevention, diagnosis, or treatment of diseases and conditions. It includes tools like order sets, drug interaction alerts, clinical guideline matching, and risk estimation calculators.
When is CDS software not a medical device?
CDS software is excluded from the device definition when it meets all four criteria in Section 520(o)(1)(E) of the FD&C Act: (1) it does not process images, IVD signals, or physiological patterns, (2) it works with medical information, (3) it supports rather than directs HCP decisions, and (4) it enables the HCP to independently review the basis of recommendations.
What changed in the 2026 CDS guidance?
The 2026 update softened the FDA's stance on single-recommendation CDS tools (now enforcement discretion rather than regulated), added clinical documentation as a potential non-device function, moved time-critical concerns from Criterion 3 to Criterion 4, and expanded transparency requirements. It was issued on January 6, 2026, and revised on January 29, 2026.
Is AI-powered CDS regulated differently?
The 2026 guidance does not create separate rules for AI-driven CDS. The same four-criteria test applies regardless of whether the underlying algorithm is rule-based, statistical, or AI/ML-based. However, AI-driven tools may face greater scrutiny under Criterion 4 (transparency and independent review) due to automation bias concerns.
Does the CDS guidance apply to patient-facing software?
No. The Non-Device CDS exclusion applies only to software intended for use by healthcare professionals. Software that provides recommendations directly to patients or caregivers is generally considered a device if it meets the device definition and is subject to existing FDA digital health policies.
What is "enforcement discretion" for CDS?
Enforcement discretion means the FDA does not intend to enforce device requirements against a particular type of product, even though it technically meets the device definition. The 2026 guidance applies enforcement discretion to CDS functions that provide a single clinically appropriate recommendation and meet all other criteria.
Does my CDS software need 510(k) clearance?
If your software function meets all four Non-Device CDS criteria, it does not need 510(k) clearance or any other premarket review. If it fails any one criterion and is a device, the pathway depends on the device classification — it may require 510(k), De Novo, or PMA, or may qualify for enforcement discretion under other FDA policies.
What is the difference between "medical information" and "signals or patterns"?
Medical information is discrete, typically static data like lab results, diagnoses, or medication lists. Signals or patterns are continuous, near-continuous, or streaming physiological measurements — such as ECG waveforms, continuous glucose monitor readings, or real-time pulse oximetry data. The distinction is critical for Criterion 1.