# Non-Device by Design: The FDA Clinical Decision Support Line | RankShieldMD

> The FDA clinical-decision-support criteria separate a regulated device from software that supports it. How attesting a decision, rather than rendering it, keeps a security layer non-device. PHI-free.

URL: https://rankshieldmd.com/resources/non-device-fda-cds-line/

**Non-device by design: staying on the right side of the FDA clinical decision support line .**

The FDA clinical-decision-support criteria separate a regulated device from software that only supports the decision. The line is the fourth criterion, and it is the line RankShieldMD is built to stay behind.

WHERE THE LINE IS

## The FDA clinical decision support line, in one paragraph.

Under the FDA's clinical-decision-support criteria, software becomes a regulated device when it produces or drives the clinical decision, the fourth criterion. Software that attests a decision was genuine, rather than making it, stays non-device. The criteria live in section 520(o)(1)(E) of the FD&C Act and are elaborated in the FDA's Clinical Decision Support Software guidance, which sets out the four tests a software function must meet to fall outside the device definition.[1] The critical one, the fourth, asks whether a health care professional can independently review the basis of the software's recommendation without relying primarily on it. When the software instead produces, scores, ranks, or drives the clinical output the practitioner acts on, it is inside the decision and it is a device. This is the exact line a new class of AI-integrity and attestation tooling has to respect. RankShieldMD respects it by construction: it attests a clinical-AI decision, meaning it proves the decision came from an approved, un-tampered model on clean data, and it never makes, scores, ranks, or recommends the decision itself. It works on digests, identities, and metadata, never on protected health information, so it stays non-device and PHI-free by design.

One honest note runs through everything below: classification turns on intended use and is ultimately the FDA's determination, not something a vendor declares. RankShieldMD produces evidence that supports compliance; it does not make anyone compliant, and it does not classify itself.

## What are the four FDA non-device clinical decision support criteria?

A software function is non-device clinical decision support when it meets all four criteria in section 520(o)(1)(E) of the FD&C Act, and software meeting all four is non-device CDS.

The FDA clinical decision support non-device analysis rests on four tests, each of which must be satisfied at once.[1] The first is that the software is not 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. The second is that it is intended to display, analyze, or print medical information about a patient or other medical information such as peer-reviewed clinical studies and practice guidelines. The third is that it is intended to support or provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition. The fourth is that it is intended to enable that professional to independently review the basis of the recommendation, so the professional does not rely primarily on the software when making a clinical decision. A software function that meets all four criteria is non-device clinical decision support and falls outside FDA device regulation. The criteria are cumulative, not a menu, so failing any single one, most often by analyzing a signal or by producing an output the clinician relies on primarily, pulls the function back inside the device definition. RankShieldMD sits comfortably inside all four, because it never analyzes a clinical signal and never issues a recommendation for anyone to rely on. It attests; it does not advise. And because classification turns on intended use, that placement is a design decision, not a label RankShieldMD applies to itself, since the determination is ultimately the FDA's.

## What does the fourth CDS criterion actually mean?

The fourth criterion, independent review, means the practitioner can independently review the basis of the recommendation and does not rely primarily on the software; when software produces or drives the decision, it becomes a device.

The fourth criterion is where most software either clears the bar or falls below it, and it is written around the clinician's relationship to the output.[1] For a function to remain non-device, a health care professional has to be able to independently review the basis of any recommendation the software offers, understanding the inputs, the logic, and the sources well enough to reach the same conclusion on their own. The professional must not rely primarily on the software to make the clinical decision. The practical test is one of dependence. If a competent clinician could look at the underlying information and independently arrive at the recommendation, the software is a support tool. If the clinician would reasonably defer to the software, treating its output as the answer, the software is producing or driving the decision, and at that point it becomes a regulated device. Two things commonly break the fourth criterion: opacity, where the basis of the recommendation cannot be reviewed, and time-critical or high-complexity outputs, where independent review is not realistic in the moment. RankShieldMD avoids the fourth criterion entirely by having no clinical recommendation for a clinician to review or rely on. Its output is an attestation, a verifiable statement that a decision came from an approved, un-tampered model running on clean data, produced after the fact. There is nothing clinical for a practitioner to defer to, so the question of primary reliance never arises. Classification still turns on intended use, and that determination remains the FDA's.

## What is the difference between attesting a decision and rendering one?

Rendering produces, scores, or recommends the clinical output; attesting proves, after the fact, that a decision was genuine, from an un-tampered model on clean data, and never touches the clinical output.

The whole of this post turns on the difference between rendering a clinical decision and attesting to one, and it is worth drawing precisely.[1] To render a decision is to produce the clinical output itself: to generate a diagnosis, compute a risk score, rank treatment options, or recommend a course of action that a clinician might act on. Rendering places the software inside the clinical decision, which is exactly what the fourth CDS criterion polices, and it is the behavior that pulls a tool toward device regulation. To attest to a decision is something categorically different. It is to prove, after the decision has been made, that the decision was genuine, that it came from an approved, un-tampered model running on clean, unaltered data, and to produce that proof as verifiable evidence. Attestation never generates, scores, ranks, or recommends anything clinical. It never touches the clinical output; it makes a statement about the provenance and integrity of that output. The two live on opposite sides of the CDS line. A rendering tool sits inside the decision and can be a device. An attesting tool sits beside the decision, producing evidence about it, and stays non-device. RankShieldMD attests. It works on digests, identities, and metadata, on the fingerprint of the model and the fingerprint of the data, never on the clinical content of the decision and never on protected health information. It can prove a decision was genuine without ever seeing the patient, and without ever participating in the judgment the clinician made.

## Why is staying non-device an advantage for a security and provenance layer?

A non-device layer carries no premarket submission of its own, is faster to deploy, and does not add regulatory burden to the software-as-a-medical-device vendor it serves.

Staying non-device is not a defensive posture for an attestation and provenance layer; it is a structural advantage that shapes how the layer can be used.[1] A software function that stays on the non-device side of the CDS line carries no premarket submission of its own, no 510(k), no PMA, no De Novo request tied to the layer itself. That means it is faster to deploy, it can be rolled out across a fleet of clinical-AI products without waiting on its own clearance, and it does not extend the regulatory footprint of anything it touches. The alternative is instructive. A layer that crossed onto the device side of the line would need its own clearance pathway, and worse, it would risk entangling every software-as-a-medical-device product it attached to in that same review, because it would have become part of the clinical decision those products render. That defeats the purpose of a shared evidence layer, which is to prove decisions across many products without becoming part of any of them. Because RankShieldMD attests rather than renders, it can sit alongside many clinical-AI systems, proving their decisions genuine, without any one of them inheriting a regulatory burden from the attestation. The SaMD vendor keeps its own classification and its own submission unchanged; RankShieldMD simply adds a verifiable evidence stream beside it. It produces evidence that supports the vendor's compliance record. It does not make the vendor compliant, and it does not declare its own classification, because intended use governs classification and that determination is ultimately the FDA's.

## What would push an attestation tool across the line into being a device?

An attestation tool would cross into being a device if it began producing, scoring, ranking, or driving the clinical recommendation, or if a clinician relied primarily on its output for a diagnosis or treatment decision.

Knowing where the line is only matters if you know what would cross it, and for an attestation tool the crossing points are specific.[1] The first is a change in what the tool produces. The moment an attestation tool started generating, scoring, ranking, or driving the clinical recommendation itself, rather than merely proving an existing decision was genuine, its output would become a clinical input, and it would be inside the decision. The second is a change in how the tool is relied on. If a clinician came to rely primarily on the tool's output when making a diagnosis or treatment decision, the fourth CDS criterion would no longer be met, regardless of what the tool's makers intended, because reliance is measured at the point of care. Both crossings share the same feature: the tool's output stops being a statement about a decision and becomes a driver of one. RankShieldMD is architected so neither crossing can happen by accident. Its output is an attestation about provenance and integrity, a verifiable statement that the model and data behind a decision were genuine, and it is deliberately never framed, presented, or usable as a clinical judgment about the patient. It never suggests what a clinician should conclude or do. Because classification turns on intended use, keeping the intended use squarely on attestation, and never on clinical recommendation, is precisely what keeps the tool non-device. And even that determination is not RankShieldMD's to make: it is ultimately the FDA's.

EXPLORE THE PLATFORM

## Where to go next.

FDA CDS LINE

### The clinical decision support line, applied

How the four CDS criteria and the fourth-criterion test apply to AI-integrity tooling, and why attesting a decision keeps a security layer non-device by design.

Explore → DECISION PROVENANCE

### Proof that a decision was genuine

Cryptographic decision provenance that seals a clinical-AI decision to an externally-anchored, tamper-evident log, verifiable later, without exposing patient data.

Explore → PROVENANCE EXPLAINED

### The receipt for every AI decision

What clinical-AI decision provenance is, how a decision is sealed at decision time, and why an attesting layer stays non-device while proving the decision genuine.

Explore →

HONEST BY DESIGN

## What we are careful never to claim.

### It attests, it never renders

RankShieldMD attests that a clinical-AI decision was genuine. It never makes, scores, ranks, or recommends a clinical decision, so it stays non-device by design.

### Classification is the FDA's call

Classification turns on intended use and is ultimately the FDA's determination, not something a vendor declares. RankShieldMD does not classify itself.

### Evidence, not compliance, and no PHI

It works on digests, identities, and metadata, never on protected health information. It produces evidence that supports compliance; it does not make anyone compliant.

## References

- [1] Frontiers in Artificial Intelligence (2026). An auditable and source-verified framework for clinical AI decision support: integrating RAG with data provenance. frontiersin.org/journals/artificial-intelligence/…/frai.2026.1737532

- FDA FDA, Clinical Decision Support Software guidance and FD&C Act §520(o)(1)(E). fda.gov/regulatory-information/…/clinical-decision-support-software

Answer engine

## The FDA CDS line: questions, answered.

What are the four FDA non-device clinical decision support criteria?

The FDA clinical-decision-support criteria come from section 520(o)(1)(E) of the FD&C Act and the agency's CDS guidance, and they describe four tests a software function must meet to be non-device CDS.[1] First, it is not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern-recognition signal acquisition system. Second, it is intended to display, analyze, or print medical information about a patient or other medical information such as clinical guidelines. Third, it is intended to support or provide recommendations to a health care professional. Fourth, it is intended to enable that professional to independently review the basis of the recommendation, so the professional does not rely primarily on it. Software meeting all four is non-device CDS. RankShieldMD supports compliance evidence; the classification is intended use and ultimately the FDA's to determine.

What does the fourth CDS criterion actually require?

The fourth criterion, independent review, requires that the software let a health care professional independently review the basis of any recommendation, so the professional does not rely primarily on the software to make a clinical decision.[1] In practice that means the software has to expose its inputs, logic, and sources plainly enough that a competent clinician can reach the same conclusion without deferring to the tool. When software instead produces, scores, or drives the clinical decision, or when a clinician would reasonably rely on it primarily, it fails the fourth criterion and becomes a regulated device. RankShieldMD is built on the other side of this line by design. It never produces, scores, ranks, or recommends a clinical output, so there is nothing for a clinician to rely on primarily; it only attests, after the fact, that a decision was genuine. Classification remains intended use and the FDA's determination.

What is the difference between attesting a decision and rendering one?

Rendering a decision means producing the clinical output itself: generating, scoring, ranking, or recommending a diagnosis, a risk figure, or a treatment path that a clinician might act on. Attesting a decision means proving, after the fact, that a decision was genuine, that it came from an approved, un-tampered model running on clean data, without ever touching or changing the clinical output.[1] The distinction is structural, not cosmetic. A tool that renders sits inside the clinical decision and can pull its maker toward device regulation under the CDS criteria. A tool that attests sits beside the decision, producing verifiable evidence about it, and stays non-device. RankShieldMD attests. It works on digests, identities, and metadata, never on the clinical content and never on protected health information, so it proves a decision without participating in it.

Why is staying non-device an advantage for a security and provenance layer?

When an attestation and provenance layer is non-device, it carries no premarket submission of its own, so it is faster to deploy across a fleet and does not add regulatory burden to the software-as-a-medical-device vendor it serves.[1] A layer that stayed on the device side of the line would need its own clearance path and would entangle every product it touched in that same review, which defeats the purpose of a shared evidence layer. Because RankShieldMD attests rather than renders, it can sit alongside many clinical-AI products without becoming part of any one device's regulatory footprint. It produces evidence that supports the vendor's compliance record; it does not make the vendor compliant, and it does not declare its own classification. Intended use governs classification, and that determination is ultimately the FDA's.

What would push an attestation tool across the line into being a device?

An attestation tool would cross into being a regulated device if it began producing, scoring, ranking, or driving the clinical recommendation instead of merely proving one was genuine, or if a clinician came to rely primarily on its output for a diagnosis or treatment decision.[1] The moment the tool's output becomes a clinical input the practitioner acts on, the fourth CDS criterion is no longer met and the software is inside the decision. RankShieldMD is architected to never reach that point. It emits verification results about a decision, an attestation that the model and data were genuine, not a clinical judgment about the patient. It never suggests what a clinician should conclude or do. Because classification turns on intended use, keeping the intended use squarely on attestation is what keeps the tool non-device, and that call remains the FDA's.

Does a non-device attestation layer touch patient data?

No. RankShieldMD is PHI-free by construction. It works on one-way digests, verified identities, signed metadata, and model and data fingerprints, never on protected health information and never on the clinical content of a decision.[1] This matters for two reasons. First, it keeps the tool out of the clinical decision itself, which is part of what keeps it non-device under the CDS criteria. Second, it shrinks the covered entity's data footprint rather than expanding it, because there is no new store of patient data to secure. The layer can prove a clinical-AI decision was genuine, from an approved model on clean data, without ever seeing the patient. It produces evidence that supports compliance; it does not make anyone compliant, and it never renders, scores, or recommends a clinical decision.

Does RankShieldMD ever make a clinical decision?

No. RankShieldMD attests that a clinical-AI decision was genuine; it never makes, scores, ranks, or recommends a clinical decision. It is non-device by design.[1] It never participates in the diagnosis or treatment judgment, and it is deliberately built so that no clinician would rely on it primarily for a clinical decision, because it has no clinical output to rely on. It produces evidence that supports a vendor's compliance record; it does not make anyone compliant, cleared, or certified. And it does not declare its own classification: classification turns on intended use and is ultimately the FDA's determination, not something a vendor asserts. What RankShieldMD offers is a verifiable record that a decision came from an approved, un-tampered model on clean data, produced beside the decision, never inside it.

## Prove a decision was genuine without becoming a device.

Bring a clinical-AI product or a fleet. We'll show you how an attestation layer proves each decision came from an approved, un-tampered model on clean data, produced beside the decision and never inside it, so it stays non-device by design. Evidence that supports compliance, PHI-free, non-device.

Request access →See the platform