Does analyzing a medical image make my software a device?

Generally yes. Software intended to acquire, process, or analyze a medical image, or a signal from an in vitro diagnostic device or a signal acquisition system, fails the first clinical decision support criterion and falls inside the device definition, even if it also displays guidelines and supports a clinician. That is why image-triage and waveform-analysis products are usually regulated devices. This tool flags that case, but the actual classification of your product turns on its full intended use and is the FDA's to determine.

What is the difference between attesting and rendering a decision?

Rendering a decision means producing the clinical output itself: generating a diagnosis, computing a risk score, ranking options, or recommending a course of action 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 on clean data, without ever touching or changing the clinical output. A tool that renders sits inside the decision and can be pulled toward device regulation. A tool that attests sits beside the decision and stays non-device. It is the practical form of the fourth criterion.

Is RankShieldMD a medical device?

No. RankShieldMD attests that a clinical-AI decision was genuine; it never makes, scores, ranks, or recommends a clinical decision, and it never analyzes a medical image or signal. Because it renders no clinical output, there is nothing for a clinician to rely on primarily, so it stays non-device by design. It is PHI-free by construction and works on digests, identities, and metadata only. It produces evidence that supports a vendor's compliance record; it does not make anyone compliant, and it does not declare its own classification, which is ultimately the FDA's to determine.

Interactive tool // FDA CDS decision

Is my clinical AI a medical device?

Your clinical AI is likely a medical device when it produces, scores, or drives a clinical decision, or analyzes a medical image or signal. It is likely non-device when it only supports a clinician who can independently review its basis, or when it merely attests that a decision was genuine. Walk the FDA clinical decision support four criteria below for a non-device or device-likely reading. The FDA decides, based on intended use.

Run the decision tool → Read the four criteria

Non-device by designAttest, not renderFDA CDS 4 criteriaGuidance, not advice

The decision tool

Walk the four FDA clinical decision support criteria.

Answer one question per criterion. As you go, the reading updates. All four criteria must be met for software to be non-device clinical decision support, and analyzing a medical image or signal is on its own enough to make software a device.

Is your clinical AI a medical device? 0 of 4 answered

Criterion 1 Medical images and signals

Does your software acquire, process, or analyze a medical image, or a signal from an in vitro diagnostic device or a signal acquisition system (for example, ECG waveforms or the pixels of a scan)?

Criterion 2 Medical information

Does it display, analyze, or print medical information about a patient, or other medical information such as peer-reviewed studies and clinical guidelines?

Criterion 3 Who receives the output

Who is the output intended for?

Criterion 4 Independent review

What does the software actually output, and can the clinician review its basis?

Answer the four questions above.

Each answer maps to one FDA clinical decision support criterion. The reading appears here once all four are set.

Educational guidance that mirrors the structure of the FDA clinical decision support criteria. It is not legal, clinical, or regulatory advice, and it is not an FDA determination. Real classification turns on the full intended use of your specific software and is ultimately the FDA's to decide.

The four criteria

What are the four FDA 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, elaborated in the FDA's Clinical Decision Support Software guidance. The criteria are cumulative, not a menu: failing any one, most often by analyzing a signal or by producing an output the clinician relies on primarily, pulls the software back inside the device definition.

Criterion	What it asks	Fails when
1. Images and signals	Not intended to acquire, process, or analyze a medical image or a signal from an IVD or signal acquisition system.	It analyzes scan pixels, ECG waveforms, or other physiological signals.
2. Medical information	Displays, analyzes, or prints medical information about a patient, or guidelines and studies.	It produces a new clinical measurement rather than presenting information.
3. Supports a professional	Intended to support or provide recommendations to a health care professional.	It is aimed at patients or caregivers directly.
4. Independent review	Lets the professional review the basis of the recommendation and not rely on it primarily.	The basis is opaque, or the output drives the decision.

The line

Why does the fourth criterion decide most cases?

The fourth criterion, independent review, is where most software either clears the bar or falls below it, because it is written around the clinician's relationship to the output.

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.

There is a cleaner way to sit outside the decision entirely, and it is the design RankShieldMD uses. A tool that renders no clinical output has nothing for a clinician to review or rely on, so the fourth criterion never engages. It attests rather than renders: it proves, after the fact, that a decision came from an approved, un-tampered model on clean data, and it never generates, scores, ranks, or recommends anything clinical. That keeps it non-device by design, and PHI-free by construction, because it works on digests, identities, and metadata, never on the clinical content of a decision.

Reading the result

What should I do with a non-device or device-likely reading?

Treat the reading as a way to organize your questions, not as a conclusion. Classification turns on the full intended use of your specific software and is ultimately the FDA's to determine.

A device-likely reading is a prompt to look closely at the criterion that failed. If it is the first, the image and signal criterion, your product is probably a regulated device and the right next step is a regulatory pathway, usually with counsel and a formal submission. If it is the fourth, ask whether the output can be made transparent enough for genuine independent review, or whether the product truly drives the decision. A non-device reading is not a clearance. It means the software appears, on these four questions, to fall outside the device definition as clinical decision support, and it should be documented and pressure-tested against your actual intended use, marketing claims, and how clinicians use it in practice. RankShieldMD produces evidence that supports these determinations. It does not make them, it does not make anyone compliant, and it never declares its own classification.

Honest by design

What we are careful never to claim.

Guidance, not a determination

This tool mirrors the structure of the FDA clinical decision support criteria. It is not legal, clinical, or regulatory advice, and it is not an FDA determination. Classification is the FDA's call, based on intended use.

It attests, it never renders

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

Evidence, not compliance, and no PHI

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

References

References.

[1] FDA, Clinical Decision Support Software, guidance for industry and FDA staff, and FD&C Act §520(o)(1)(E) as added by the 21st Century Cures Act. fda.gov/regulatory-information/…/clinical-decision-support-software

Educational guidance only, not legal, clinical, or regulatory advice, and not an FDA determination. RankShieldMD produces evidence that supports compliance; it does not make anyone compliant and does not classify itself.

Answer engine

Is my clinical AI a medical device? Questions, answered.

Straight answers about verifiable healthcare AI. Tap a question, or type your own.

Jamie Kloncz, founderverified human ✓

Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it.

Is my clinical AI a medical device?: Your clinical AI is likely a regulated medical device when it produces, scores, ranks, or drives a clinical decision, or when it acquires, processes, or analyzes a medical image or a physiological signal. It is likely non-device clinical decision support when it only supports a health care professional who can independently review the basis of its output, or when it merely attests that a decision made elsewhere was genuine and never renders a clinical result. Classification turns on intended use under the FDA's clinical decision support criteria, and the determination is ultimately the FDA's, not the vendor's.
What are the four FDA clinical decision support criteria?: They come from section 520(o)(1)(E) of the FD&C Act and the FDA's Clinical Decision Support Software guidance. First, the software does not acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a signal acquisition system. Second, it displays, analyzes, or prints medical information about a patient or other medical information such as clinical guidelines. Third, it supports or provides recommendations to a health care professional. Fourth, it lets that professional independently review the basis of the recommendation, so they do not rely primarily on the software. Software that meets all four is non-device clinical decision support.
Does analyzing a medical image make my software a device?: Generally yes. Software intended to acquire, process, or analyze a medical image, or a signal from an in vitro diagnostic device or a signal acquisition system, fails the first clinical decision support criterion and falls inside the device definition, even if it also displays guidelines and supports a clinician. That is why image-triage and waveform-analysis products are usually regulated devices. This tool flags that case, but the actual classification of your product turns on its full intended use and is the FDA's to determine.
What is the difference between attesting and rendering a decision?: Rendering a decision means producing the clinical output itself: generating a diagnosis, computing a risk score, ranking options, or recommending a course of action 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 on clean data, without ever touching or changing the clinical output. A tool that renders sits inside the decision and can be pulled toward device regulation. A tool that attests sits beside the decision and stays non-device. It is the practical form of the fourth criterion.
Is RankShieldMD a medical device?: No. RankShieldMD attests that a clinical-AI decision was genuine; it never makes, scores, ranks, or recommends a clinical decision, and it never analyzes a medical image or signal. Because it renders no clinical output, there is nothing for a clinician to rely on primarily, so it stays non-device by design. It is PHI-free by construction and works on digests, identities, and metadata only. It produces evidence that supports a vendor's compliance record; it does not make anyone compliant, and it does not declare its own classification, which is ultimately the FDA's to determine.
Does this tool give me a regulatory determination?: No. This tool is educational guidance that mirrors the structure of the FDA's clinical decision support criteria. It is not legal, clinical, or regulatory advice, and it is not an FDA determination. Real classification turns on the full intended use of your specific software and is decided by the FDA, often with counsel and a formal submission. Use the reading here to organize your thinking and your questions, not as a conclusion you can rely on.

Early access

Prove a decision was genuine without becoming a device.

Bring a clinical-AI product or a fleet. We will 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 early access → See the FDA CDS page