What Is Clinical Decision Support Software?
Clinical decision support (CDS) software analyzes patient-specific data and surfaces information, alerts, or recommendations to a clinician at the point of care — without making the diagnosis or treatment decision itself. Whether your CDS tool ends up FDA-regulated as a medical device or exempt from that regulation turns on a specific four-part test, not on whether your pitch deck uses the word "AI" or "clinical."
Quick Answer: CDS is any software that gives a clinician patient-specific information to inform, not replace, a clinical decision — drug-interaction alerts, sepsis early-warning scores, diagnostic suggestion tools, and in-context reference lookups are all CDS. Under U.S. law, CDS that meets four specific criteria — including showing its basis so a clinician can independently judge the recommendation — is generally exempt from FDA device regulation. Miss even one criterion and you're more likely building a regulated device. Which side your specific software lands on is a determination for regulatory counsel, not a blog post.
How CDS works: inputs, logic, and the clinician in the loop
CDS software runs on three linked parts: patient-specific inputs drawn from the record or entered at the point of care, a logic layer that turns those inputs into something clinically meaningful, and an output surfaced to a clinician who still makes the call. Remove any one part and it stops being CDS — a tool with no patient-specific input is a generic reference, and a tool with no human decision step at the end is something else entirely, usually a more heavily regulated one.
The inputs are whatever the software can see: lab results, vitals, medication lists, problem lists, allergies, and increasingly patient-reported data pulled from the electronic health record (EHR) or entered manually. The logic layer is what turns those inputs into a signal — this can be a simple rules engine ("if potassium is above this threshold and the patient is on this drug class, flag it"), a scoring algorithm that weights several inputs into a composite risk number, or a machine-learning model trained to recognize a pattern across many cases. The output is where CDS earns its name: it supports a decision rather than making one, which is the thread that ties every example below together.
In practice, CDS shows up in a handful of recurring forms:
- Point-of-care alerts — drug-drug interaction warnings, allergy alerts, and duplicate-order flags that interrupt a workflow at the moment they're relevant
- Risk and diagnostic scoring tools — early-warning scores or differential-diagnosis suggestion lists that rank possibilities without asserting one
- Order sets and care-pathway prompts — standardized order bundles a clinician can accept, edit, or reject once a condition is suspected
- Reference and knowledge lookups — drug monographs or guideline excerpts surfaced in context instead of requiring a separate search
- Dosing and calculation support — renal dosing adjustments or infusion-rate calculators that do the arithmetic a clinician would otherwise do by hand
A growing share of new CDS tools run on machine-learning models instead of hand-coded rules, and that shift changes how you generate evidence a skeptical clinician will actually trust. Our guide on how to validate a clinical AI tool with skeptical doctors covers the workflow and evidence discipline that applies once your CDS logic is a trained model rather than a transparent rulebook.
Device vs. non-device CDS: the four-part test
Whether your CDS software is exempt from FDA device regulation depends on meeting all four criteria that Congress wrote into the definition of a device under the 21st Century Cures Act, which FDA has since clarified in guidance specific to clinical decision support. Fail even one criterion and your software is more likely to be regulated as a device — potentially at a meaningfully higher risk class, depending on the clinical claim you're making.
The table below states the general shape of each criterion, in plain language, alongside an illustrative example on each side.
| Criterion | What it generally requires | Tends to meet it | Tends to fail it |
|---|---|---|---|
| 1. No signal or image acquisition/analysis | The software doesn't acquire, process, or analyze a medical image, an in vitro diagnostic signal, or a pattern from a signal-acquisition device | Reasoning over structured EHR fields — labs, vitals, medication lists | Analyzing a radiology image or an ECG waveform directly |
| 2. Displays information normally shared between clinicians | The software shows, analyzes, or prints information already of a kind normally communicated between healthcare providers, or between a provider and a patient | Surfacing an existing lab trend beside a relevant guideline excerpt | Deriving an entirely new physiological measurement from raw sensor data |
| 3. Recommendation, not a directive | The output is something a clinician weighs, not a specific diagnosis or treatment the software asserts as the answer | "Consider evaluating for sepsis — these criteria are met" | "Patient has sepsis," or an instruction the system acts on without a clinician step |
| 4. Clinician can independently review the basis | The software exposes enough of its reasoning that a clinician can exercise independent judgment instead of relying on the recommendation alone | Showing which inputs and thresholds triggered the alert | An opaque score with no visible basis — a common failure mode for black-box models |
Two design choices sink most borderline CDS products against this test: hiding the reasoning behind an opaque model score, and phrasing an output as a directive instead of something to weigh. Both are product decisions your team makes early, often for good UX reasons — a single confident number is a cleaner interface than a list of contributing factors — and both happen to be the exact decisions this test scrutinizes. For the general reasoning FDA applies to decide whether any piece of software counts as a device at all, CDS or otherwise, see is my app a medical device.
Treat this table as orientation, not a determination. The criteria are fact-specific, guidance evolves, and a feature you add later — even one that feels minor, like starting to ingest a waveform your system previously ignored — can move a tool from one side of the line to the other. Confirm your actual status with regulatory counsel before you plan a validation timeline or a fundraising narrative around an assumed answer.
A sepsis alert walked through the criteria
The same clinical goal can land on either side of the device line depending entirely on how you build it, not on what problem you're solving. Consider two hypothetical versions of a sepsis early-warning tool aimed at the identical use case: flagging patients who may be developing sepsis before it becomes obvious on rounds.
Version A reasons over vitals and labs already sitting in the EHR — no image or waveform acquisition. It surfaces a trend chart alongside the specific criteria that triggered the flag ("temperature, heart rate, and white count each crossed threshold X at time Y"), phrases its output as "consider evaluating for sepsis," and stops there — a clinician decides whether to act, and nothing auto-orders. Run it against the four-part test and it plausibly clears all four: no signal acquisition, it displays information of a kind clinicians already share with each other, it recommends rather than asserts, and the basis is fully visible.
Version B pursues the same clinical goal differently. It ingests a continuous waveform directly from a bedside monitor, feeds it into a model that outputs a single number — "87% probability of sepsis in the next six hours" — with no visible breakdown of which inputs drove that score, and auto-populates a stat lactate order and an antibiotic order pending only a one-click confirmation. That design fails at least three of the four criteria: it acquires and analyzes a signal, it functions closer to a directive than a recommendation, and the basis for the number is invisible to the clinician relying on it.
Nothing about the underlying clinical mission changed between the two versions — only architecture and interface choices did. That's the practical lesson: the engineering and UX decisions your team makes in the first few sprints are, in a CDS product, also regulatory decisions, whether or not anyone frames them that way at the time. (Both versions above are illustrative hypotheticals, not a description of any real cleared or regulated product.)
When CDS status matters for validation
Your device-versus-non-device conclusion changes nearly everything downstream in how you validate and sell the product, which is why it belongs early in your process rather than as a question you answer once a hospital's legal team asks it.
- Evidence burden. A non-device CDS tool can often validate on usability and clinical-adoption evidence alone. A device-classified tool adds a formal regulatory evidence program on top of that — see the staged sequence in how to validate a medical device startup idea for how that evidence work fits alongside clinical-need and reimbursement validation.
- Fundraising narrative. Investors who've seen digital-health deals before will ask about your regulatory pathway early, and "we haven't looked into it" reads very differently than a scoped, counsel-confirmed answer.
- Procurement and security review. A hospital's value-analysis committee, IT security, and compliance teams ask different questions and move at different speeds depending on whether they're onboarding a device or a workflow tool.
- Trust and liability framing. How you describe accuracy, and how much clinicians are expected to independently verify your output, is itself shaped by which side of the line you're on — which is exactly the trust-building discipline covered in how to validate a clinical AI tool with skeptical doctors.
This is one instance of a broader discipline that applies whether or not FDA is involved at all: prove the riskiest assumption first, cheaply, before you build around an answer you assumed rather than tested. For that general validation framework, see our complete guide to startup idea validation.
Key Takeaways
- CDS informs a decision; it doesn't make one. The moment your software's output functions as a directive a clinician simply executes, it has stepped outside the category.
- The device line is a four-part test, not a vibe check. Signal/image acquisition, information type, recommendation-versus-directive framing, and basis transparency all have to hold together.
- Design choices are regulatory choices. Hiding a model's reasoning behind a single confident score, or auto-acting on an output, are the two most common ways a CDS tool crosses into device territory.
- Identical clinical goals can land on either side of the line. The sepsis-alert comparison shows the same mission producing different regulatory outcomes purely from architecture and interface decisions.
- Your status changes your validation plan, not just your legal risk. Evidence burden, fundraising narrative, procurement review, and how you frame trust with clinicians all shift depending on the answer.
- This is fact-specific — confirm with counsel. Treat any general explanation, including this one, as orientation for the questions to ask, not a determination for your specific product.
Frequently Asked Questions
Is clinical decision support software regulated by the FDA?
Sometimes. CDS that meets all four criteria in FDA's non-device CDS guidance — no signal or image analysis, displaying information already normally shared between clinicians, recommending rather than directing, and showing its basis — is generally exempt from device regulation. CDS that fails any one criterion is more likely to be regulated, and the specific determination depends on your exact software.
What's the difference between CDS and a clinical decision support system (CDSS)?
Nothing substantive — "CDS" and "CDSS" are typically used interchangeably to describe the same category of software: tools that give clinicians patient-specific information or recommendations at the point of care. Some vendors use "CDSS" specifically for larger, integrated platforms and "CDS" for a single feature, but there's no formal regulatory distinction between the two terms.
Can CDS software use AI or machine learning?
Yes. Many current CDS tools use machine-learning models instead of hand-coded rules to generate their recommendations. Using AI doesn't automatically change device status one way or the other — the same four-part test applies — but AI models more often struggle with the "basis" criterion, since an opaque model score is harder to make transparent than a simple threshold rule.
Does CDS software need FDA clearance before a hospital will buy it?
Only if it's classified as a device. Non-device CDS can typically be sold and adopted without FDA clearance, though hospitals will still run their own security, integration, and clinical-validity review before purchasing. Device-classified CDS generally needs to clear the applicable regulatory pathway first — selling before then risks both the deal and your standing with the health system.