Four criteria keep software out of device status

A lot of software gets pitched to FDA counsel as “clinical decision support, so it's exempt” as though CDS were itself a category the agency has agreed to leave alone. The Federal Food, Drug, and Cosmetic Act doesn't grant an exemption to a category called clinical decision support. Section 520(o)(1)(E), added by the 21st Century Cures Act in 2016, exempts a software function from the device definition only when four specific conditions are all met at the same time — and a good deal of software that gets called CDS in a product deck doesn't clear all four. A team that treats “we built a CDS tool” as the end of the device-status analysis has skipped the actual test the statute runs, which asks about the function, not the label put on it.

The exemption is statute, not a guidance-level courtesy

The 21st Century Cures Act amended the Food, Drug, and Cosmetic Act in 2016 to add section 520(o)(1)(E), carving certain software functions out of the statutory definition of a device altogether. That placement matters: this isn't FDA choosing, as a matter of enforcement discretion, not to regulate a category of low-risk software — it's Congress narrowing what counts as a device in the first place, for software that meets the criteria the section lays out. FDA's guidance on the exemption, most recently revised in a final guidance FDA issued in January 2026 superseding its 2022 version, interprets and illustrates that statutory language; it doesn't create the exemption itself, and the four criteria at the center of it haven't moved across that revision.

Four criteria, and all four have to hold at once

Section 520(o)(1)(E) sets out four conditions a software function has to meet together, not in the alternative. It can't be intended to 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. It has to be intended to display, analyze, or print medical information about a patient or other medical information. It has to be intended to support or provide recommendations to a healthcare professional about preventing, diagnosing, or treating a disease or condition. And it has to be intended to let that healthcare professional independently review the basis for those recommendations, rather than relying on the software's output alone. A function that clears three of the four and stumbles on one hasn't qualified for anything — the exemption doesn't have a partial-credit version.

The image-and-signal line is the one most tools trip first

Criterion one does more gatekeeping than its position in the list suggests. Software that pulls in a medical image, a waveform, or a signal from an IVD or a signal acquisition system and does any analytical work on it is out of the exemption regardless of how transparent its reasoning is or how squarely the rest of its function fits the other three criteria. That line is what keeps most image-analysis and signal-interpretation tools — the kind of software IEC 62304's safety classification and SaMD risk categorization are built to govern once a product is already a device — on the device side of this particular boundary before any risk-based classification question even arises.

Independent review is where the harder judgment calls live

The fourth criterion is where FDA's guidance spends the most interpretive effort, because it's the hardest to check mechanically. A tool that surfaces a bare risk score or a recommendation without exposing the underlying data and logic a clinician would need to evaluate it hasn't given that clinician a real basis to review independently — it's asked for trust in the output instead. Software built to show its inputs, and to let a clinician see why a recommendation follows from them rather than just that one was generated, is aiming at what this criterion is actually testing. A vendor that treats criterion four as a labeling exercise, added after the software is built rather than designed into how it presents its output, is usually the one that ends up on the device side of the line despite intending otherwise.

Where this meets the file

A software intended-use file that asserts “non-device CDS” without walking through all four criteria by name has skipped the actual test the statute sets, not just abbreviated it. What the file should carry instead is each criterion addressed against the specific software function, with the independent-review criterion tied to a concrete description of what the interface actually shows a clinician, not just the recommendation it produces. That determination is a separate question from the risk-classification work IEC 62304 and SaMD categorization take over once a function has already landed on the device side. A 520(o)(1)(E) determination worksheet built around the statute's own four criteria is previewed in the launch catalog. If your program documents this determination differently, the shelf takes that correction directly.