When is clinical decision support software a regulated device? FDA's four-criteria test and where the line has moved

Clinical decision support (CDS) software sits on a statutory fault line. Section 3060 of the 21st Century Cures Act amended the FD&C Act to add section 520(o)(1)(E), which carves certain CDS functions out of the device definition. Everything turns on a four-part test: software that satisfies all four criteria is non-device CDS and falls outside FDA's device authority; software that fails any one of them meets the device definition under section 201(h) and is regulated accordingly ⁹⁰⁹⁸. FDA's Clinical Decision Support Software guidance, issued in final form and most recently updated in January 2026, is the operative document interpreting that test ⁵¹⁸⁷.

The four-criteria test

FDA's guidance frames the exclusion as four cumulative criteria drawn directly from section 520(o)(1)(E). A software function is non-device CDS only if it is ⁵³:

1. "not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system" ⁵³
2. "intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines)" ⁵³
3. "intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition" ⁵³
4. "intended for the purpose of enabling such health care professional to independently review the basis for such recommendations ... so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient" ⁵³

All four must be met. In practice, the first and fourth criteria do most of the sorting: Criterion 1 pulls in any software that touches an image, an IVD signal, or a signal-acquisition pattern, and Criterion 4 pulls in any software whose recommendation the clinician cannot meaningfully second-guess.

How FDA applies the test: device CDS versus non-device CDS

The guidance works largely through worked examples. The recurring pattern is that a recommendation built on human-readable medical information, with its basis exposed to the clinician, stays outside the device definition, while the same function tips into device territory the moment it ingests signal- or image-level data or presents a conclusion the clinician must take on trust.

Examples FDA treats as non-device CDS include ^722111524:

• Evidence-based clinician order sets tailored to a condition or clinician preference ²²
• Matching a patient's records to reference material such as clinical practice guidelines ²²
• A prioritized list of FDA-approved chemotherapeutic agents that shows the basis for the prioritization and the supporting studies ⁷
• Software that analyzes a COPD patient's age and average daily steps to offer follow-up options, with the basis explained so the clinician can independently review it ⁷
• Drug-drug interaction and drug-allergy contraindication alerts that let the clinician review the basis ²⁴
• Presenting a blood pressure result, an ECG report summary, a radiology summary, or a lab result as medical information, provided the other criteria are met ¹⁵

Examples FDA treats as device functions include ⁷⁹¹¹³⁴:

• Software that uses a patient's CT or MR image sets to create an individualized radiation therapy treatment plan ⁷
• A cardiovascular risk predictor that relies on variant genomic data not established for the recommendation ⁹
• A differential-diagnosis tool that crosses into establishing a definitive diagnosis from medical images, waveforms, or other signal-level inputs ¹¹
• A postoperative risk estimator that instead predicts intraoperative or in-hospital mortality from near real-time physiologic measurements ¹¹
• Software that acquires or processes physiological signals for active patient monitoring, processes uterine contraction and fetal heart rate data, or processes images for diagnostic review ⁴
• Software that controls or changes the settings of another device such as an infusion pump, CT or X-ray machine, or implantable stimulator ⁴

The through-line: signals and images (Criterion 1) plus recommendations the clinician cannot independently verify (Criterion 4) are what convert "support" into a regulated device.

Where the policy line has moved

Three developments in the current guidance are worth flagging for anyone benchmarking against older enforcement examples.

Criterion 4 is now a disclosure standard, not a slogan. The final guidance operationalizes "independently review the basis" into a concrete set of expectations: the software should convey its purpose and intended use, the intended clinician-user and patient population, the input data and its quality requirements, a plain-language description of the algorithm and its validation, and the relevant patient-specific information plus known limitations ^6147626. Where the clinician cannot see enough of the underlying basis, FDA treats the function as a device ⁸⁸. This is a more demanding, checklist-style bar than the risk-tiered treatment of independent review in the older IMDRF Software as a Medical Device framework ⁷⁰⁷¹.

Time-critical use was treated as disqualifying, then softened by a January 2026 correction. The final guidance took the position that software intended for a "critical, time-sensitive task or decision" does not meet Criterion 4, on the theory that the clinician has no realistic opportunity to review the basis before acting, so such functions are devices ⁶⁸⁴. FDA then issued a minor correction to pages 13-14 of the guidance in January 2026 to delete the time-critical decision-making reference, aligning with a January 6, 2026 update ⁸⁷. RA teams relying on the "time-critical equals device" heuristic should read the current text rather than earlier drafts or secondary summaries.

IMDRF risk categorization was retained, not abandoned. Despite the shift away from the 2019 draft's risk-based structure, the final guidance still points readers to the IMDRF risk-categorization framework for additional considerations ^6757714. The IMDRF principles remain part of FDA's policy backdrop rather than a discarded approach.

AI has its own overlay, but the gate is still the device definition. FDA's newer AI documents do not change who is in or out of the device definition; they govern the subset of software that is already a device. The Artificial Intelligence-Enabled Device Software Functions lifecycle and marketing-submission draft guidance issued January 7, 2025 ¹¹¹, and the final Predetermined Change Control Plan guidance for AI-enabled device software functions (issued August 18, 2025; originally December 4, 2024) ⁹³, both define their scope as software functions that meet the device definition and are not excluded under section 520(o) ⁹⁰⁹⁸⁹¹. In other words, an AI-driven CDS tool is regulated as a device only if it fails the four-criteria test in the first place; the AI/PCCP framework then applies to that device ^9098109.

Recent CDS products FDA has cleared or classified as devices

Recent 510(k) clearances and De Novo classifications show the categories of CDS that FDA is treating as devices, most because they process signals or images (Criterion 1) or present risk predictions the clinician is expected to act on (Criterion 4). Predictive and diagnostic CDS is the most active area.

Device / submission	Company	Product code	Decision date	Why it is a device
Sepsis ImmunoScore (DEN230036)	Prenosis, Inc. 113	SAK 113	2024-04-02 113201	AI/ML software using EHR-derived data to predict/diagnose sepsis risk; De Novo created a new Class II classification 113203
eCARTv5 Clinical Deterioration Suite (K233253)	AgileMD, Inc. 115	QNL 115	2024-06-21 115	EHR-integrated early-warning software predicting deterioration (death or ICU transfer) in ward patients 112
Global Hypoperfusion Index Algorithm (K231038)	Edwards Lifesciences 116	QNL 116	2023-07-26 116	Predictive algorithm estimating future hemodynamic events from real-time patient data to alert clinicians 116
Tempus ECG-AF (K233549)	Tempus AI, Inc. 142	SBQ 142	2024-06-21 142	ML software analyzing 12-lead ECGs to flag near-term atrial fibrillation risk 142
Eko Foundation Analysis Software with Transformers (K251494)	Eko Health, Inc. 138	DQD 138	2025-08-12 138	CDS software analyzing heart sounds and ECGs to identify murmurs and AF/sinus rhythm 138
Talis EMR with +ACG (K233133)	Talis Clinical, LLC 124	MWI 124	2024-04-01 124	CDS that matches multi-source data to hospital protocols to generate alarms and advisories 124
RevealAI-Lung (K251769)	RevealDx 127	POK 127	2026-01-30 127	Computer-aided diagnosis software characterizing pulmonary nodules from CT data 127
EW10-EC02 Endoscopy Support Program (K230751)	FUJIFILM 136	QNP 136	2023-12-15 136	Computer-assisted reading tool detecting colonic lesions in real time during endoscopy 136

The product codes themselves map the taxonomy FDA has built for algorithm-driven decision support and triage:

• SAK (21 CFR 880.6316, Class II): software to aid in the prediction or diagnosis of sepsis, for adjunctive use, not the sole determinant of sepsis status ¹⁶¹¹⁵³. This classification was created through the Sepsis ImmunoScore De Novo ²⁰³.
• QNL (21 CFR 870.2210, Class II): medium-term adjunctive predictive cardiovascular indicator using software algorithms to predict future cardiovascular status or events, for adjunctive use, not to independently direct therapy ²⁰⁴.
• SBQ (21 CFR 870.2380, Class II): atrial fibrillation risk-prediction machine-learning notification software suggesting the likelihood of future AF for referral or follow-up ¹⁵⁴.
• QAS and QFM (21 CFR 892.2080, Class II): radiological computer-assisted triage and notification, and prioritization software for lesions, respectively (the CADt family) ¹²⁰¹²¹.
• QIH (21 CFR 892.2050, Class II): automated radiological image processing software ¹²².
• SAO (21 CFR 892.1171, Class II): radiology software for opportunistic evaluation of low bone mineral density ¹²³.

The De Novo route matters here because predictive CDS often has no suitable predicate. The Sepsis ImmunoScore authorization is the clearest recent example: rather than a 510(k), FDA used a De Novo to create a new device type and regulation (880.6316) with special controls, then set SAK as the product code for follow-on submissions ²⁰³¹¹³. Expect the same pattern for novel predictive or diagnostic CDS categories that clear the device threshold but lack an existing classification.

Practical read for regulatory teams

The exclusion is narrow and getting more precisely policed, not broader. If a CDS function touches an image, an IVD signal, or a signal-acquisition pattern, Criterion 1 alone makes it a device ⁵³⁴. If it presents a risk score or recommendation the clinician is expected to act on without being able to trace the basis, Criterion 4 does the same, and FDA's current expectations for what "the basis" must include are specific and documentable ⁶⁷⁶²⁶. The recent clearance and classification record shows FDA actively regulating predictive deterioration, sepsis, cardiovascular, and arrhythmia CDS as Class II devices, frequently via De Novo where no predicate exists ^113115116142. Teams should map each software function against the four criteria individually, confirm they are reading the current January 2026 guidance text (particularly on time-critical use) ⁸⁷, and, for AI-enabled functions that do meet the device definition, layer in the AI-DSF and PCCP frameworks ¹¹¹⁹³.