When Is Clinical Decision Support a Regulated Device? The Line, Explained

The short answer

In the United States, a piece of clinical decision support software falls outside the FDA's device authority only when it meets all four criteria that Congress wrote into the 21st Century Cures Act, and the criterion that does most of the work is whether a clinician can independently review the basis of the recommendation rather than relying on it as a verdict. Software that reads a scan or an in vitro diagnostic signal, or that hands a clinician a conclusion they cannot reasonably check, sits inside the device definition and its oversight. Everything below is educational public-policy explanation, not legal advice, and a developer with a specific product should seek formal regulatory counsel.

I write this as a physician-scientist who evaluates software claims and holds formal training in medical device regulation across EU MDR, IVDR, FDA pathways, and Software as a Medical Device. My aim is to make the logic legible, not to render a ruling.

Where the line comes from

Before 2016, the definition of a medical device in the Federal Food, Drug, and Cosmetic Act was broad enough to sweep in a great deal of health software. The 21st Century Cures Act added a carve-out, at section 520(o)(1)(E), that removed a specific class of clinical decision support from the device definition. If a software function fits inside it, the FDA does not regulate it as a device. If it falls outside, it is a device and follows the same logic as any other Software as a Medical Device.

The FDA published guidance interpreting these criteria in 2022 and issued a revised final version in early 2026 that superseded it. The statutory four criteria did not change between the two. What shifted was the agency's interpretation and its willingness to exercise enforcement discretion in certain cases. So the durable thing to learn is the four-part test itself.

The four criteria, in plain terms

A software function is outside the device definition (call it non-device CDS) only if it satisfies every one of these. Missing even one puts it back inside.

One: it does not touch signals or images

The function must 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. This is a bright line. A tool that interprets an ECG waveform, reads a pathology slide, or analyzes raw output from a continuous glucose sensor is doing exactly the measurement-and-interpretation work the device framework exists to govern. Errors in reading a physiologic signal are hard to catch after the fact, so that work stays regulated regardless of how the output is presented.

Two: it displays or analyzes medical information

The function is meant to display, analyze, or print medical information about a patient, or other medical information such as peer-reviewed clinical studies and clinical practice guidelines. This criterion is about the raw material: non-device CDS draws on the ordinary information a clinician already works with, not on proprietary sensor streams.

Three: it supports a recommendation, it does not dictate one

The function provides recommendations to a health care professional about prevention, diagnosis, or treatment, rather than a specific directive output. It informs a professional who then decides. Historically the guidance read this as excluding tools that offer only a single output. The 2026 revision kept that statutory reading but added a narrow enforcement-discretion policy: where only one option is genuinely clinically appropriate, the agency has signaled it may not pursue such a function as a device. How to judge when a single recommendation is clinically appropriate is not fully spelled out, so the edge here remains uncertain.

Four: the clinician can independently review the basis

This is the criterion that carries the ethical and practical weight. The function must be intended to enable a health care professional to independently review the basis for its recommendations, so that the professional does not rely primarily on the software's output. In practice the product, or its labeling, has to explain in plain language the inputs, the logic, the sources, and the relevant validation, well enough that a competent clinician could look at a recommendation and understand why it was made. A tool that says "start drug X" while concealing the reasoning fails here. A tool that says "based on this patient's renal function and this guideline, consider X, for these stated reasons" gives the clinician something to check.

Timing matters too. Software intended for time-critical decision-making sits uneasily with this criterion, because in an emergency there is little realistic opportunity to review anything, and automation bias, the well-documented tendency to defer to a machine when time and cognitive load are high, takes over.

Why the fourth criterion matters most

There is a difference between a colleague who says "here is what I would consider, and here is my reasoning" and an oracle that emits a conclusion. The first invites scrutiny; the second invites deference. If you can see and evaluate the basis, the software is a reference that keeps a human in charge. If you cannot, it has effectively become the decision-maker that device oversight is designed to reach.

Transparency, then, is not a nicety here. The more a model's reasoning is opaque, the harder criterion four becomes to satisfy, which is one reason many complex machine-learning tools land inside the device definition. That is not a verdict on their quality; plenty of regulated software is excellent. It is a statement about where the accountability sits.

What this does and does not settle

Two cautions. First, meeting the four criteria removes a function from the device definition, but the same product may bundle several functions, each assessed on its own. A single app can hold a non-device reference feature and a regulated diagnostic feature side by side. Second, this is the United States framework. Other jurisdictions, including the EU under its medical device and in vitro diagnostic regulations, classify software using related but distinct logic, and a tool exempt in one place may be regulated in another.

If you are building or buying such a tool, treat the four criteria as a diagnostic worksheet, then bring a specific product to qualified regulatory counsel. For readers weighing any of this against their own care, this is general education about how software is regulated, not medical advice, and decisions about your health belong in a conversation with your own clinician.