Datamint knowledge base

When Does Your AI Algorithm Become a Medical Device?

The SaMD definition, the Clinical Decision Support exemption (and why imaging AI almost always fails it), and the key question of intended use that determines regulatory status.

The Short Answer

Is your AI algorithm is intended to detect, diagnose, classify, or guide treatment for a disease or medical condition? If so, congratulations! You are building a medical device. It doesn’t matter that it’s “just software.”, it doesn’t matter that it runs in the cloud, and it doesn’t matter that a physician still makes the final call. In the eyes of the FDA, software alone can be a medical device, and if your work touches clinical decision-making in any meaningful way, it almost certainly is one.

This concept has a name: Software as a Medical Device (SaMD). If the core function of your SaMD is implemented by a trained machine learning model, you’re in the more specific category of AI/ML-based SaMD — sometimes called a Machine Learning Medical Device (MLMD).

As of early 2026, the FDA has authorized over 1,450 AI/ML-enabled medical devices. Roughly 80-85% of them are imaging-based (about 73% classed as Radiology and the rest endoscopy, photo based, microscopy, and other methods involving pictures). In the past few years MLMD has gone from a niche area where the FDA was just starting to form opinions about required evidence, to a mainstream category with firm documentation and evidence requirements.

What Makes Software a “Medical Device”?

The FDA defines a medical device as any instrument, apparatus, machine, or software intended to diagnose, cure, treat, prevent, or mitigate a disease or condition. The critical word in that sentence, and the one that determines your entire regulatory future, is intended.

Your algorithm is a medical device if it is intended to:

  • Detect or flag abnormalities in medical images (radiology, pathology, ophthalmology, dermatology, etc. If it’s a picture or a video, it counts)
  • Diagnose or classify a disease or condition
  • Predict clinical outcomes (disease progression, treatment response, risk stratification)
  • Guide treatment decisions based on patient data

What’s not on that list is the technology you used to build it. The FDA does not care whether you used a convolutional neural network, a transformer, a random forest, or a super clever series of if-then statements in Visual Basic. What matters is what the software is for. A statistics based regression that detects diabetic retinopathy and a deep learning model that detects diabetic retinopathy face the same regulatory question. The answer to that question lives in one place: the intended use statement.

Intended Use: The Most Important Sentence You Will Write

The intended use statement is a precise, written description of what your device does, who it’s for, and the clinical context in which it operates. The name might make it sound like a formality, or a summarization of what the algorithm is useful for: like the “best paired with” line on a bottle of wine. That’s wrong, it’s extremely important. This single statement determines:

A broader intended use means your algorithm can positively affect more people, but it also means more regulatory burden. A narrower intended use is easier to clear but limits your market. This is a strategic decision that you’re probably best off working with regulatory professional early in development. A few hours of consultation time should be enough, so it doesn’t need to break the bank.

Example: “AI-based software that autonomously screens retinal images for diabetic retinopathy” is a very different regulatory proposition than “AI-based software that assists ophthalmologists in measuring retinal fluid volumes from OCT scans.” Same general technology, same organ but vastly different regulatory paths and evidence requirements.

The CDS Exemption: The Escape Hatch That Probably Doesn’t Fit

At some point during your regulatory awakening, someone (possibly a co-founder, maybe an investor, possibly your own hopeful inner voice) will say: “But isn’t this just Clinical Decision Support? Doesn’t that mean it’s exempt?”

It’s a reasonable question. Section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act does exempt certain Clinical Decision Support (CDS) software from device regulation. To qualify, your software must meet all four of the following criteria:

  1. Not intended to acquire, process, or analyze a medical image
  2. Displays the basis for its recommendations so the clinician can independently review the underlying information
  3. Is not intended to replace clinical judgment
  4. Is intended for use by a qualified healthcare professional

In 2025, 80% of MLMD FDA applications were image-based algorithms. If your algorithm processes X-rays, CT scans, MRIs, ultrasound images, pathology slides, OCT scans, fundus photographs, dermoscopic images, microscopy images, or any other medical imaging modality — the CDS exemption does not apply.

This is not a gray area for imaging AI, and it trips up a remarkable number of teams who spend months building under the assumption that they’re exempt, only to discover they’ve been developing a regulated medical device without the quality management infrastructure or software lifecycle documentation that regulators expect. That’s an expensive epiphany when it comes, and a bad day indeed. The documentation requirements are much easier to satisfy if you build them into your process from the start. Attempting to reconstruct them after the fact is one of the most common and most costly mistakes in medical AI development.

When CDS Might Apply

There is one architecturally interesting scenario worth knowing about. Suppose your (non-CDS) cleared imaging AI produces numerical outputs like fluid volumes, biomarker measurements, thickness values. A separate software layer that takes those numbers (not the images) and presents them alongside published clinical guidelines might qualify for CDS exemption, because it operates on numerical data rather than images.

This two-layer architecture has some strategic implications:

  • Layer 1: Image analysis algorithm (regulated medical device, requires clearance)
  • Layer 2: Clinical reporting dashboard that contextualizes Layer 1’s outputs against guidelines (potentially CDS-exempt)

This could help you get to market with a bit less regulatory burden, but it requires careful design and, ideally, confirmation through a Q-Submission (Pre-Submission meeting) with the FDA. We mostly bring it up here to signal that yes, we have thought about the CDS and no, it still probably doesn’t apply to you.

”But It’s Just a Research Tool”

A lot of Datamint users are purely researchers with no immediate intent to commercialize their research. Things do get a bit more nuanced in that circumstance, but it’s still worth thinking about regulation (and reading the rest of this section).

If you’re developing an AI algorithm purely for research purposes, by which we mean analyzing retrospective data, generating hypotheses, and exploring datasets, you are probably not building a medical device. The FDA regulates devices based on intended use, and if the intended use is “research only,” you’re generally outside their regulatory grasp.

However.

The moment your intended use shifts from “research” to anything that touches clinical care, even indirectly (even aspirationally!), the regulatory folks can start to notice. And the tricky part is that this mental shift often happens gradually.

  1. “We’re just building a research tool to analyze our data.”
  2. “It works really well. Let’s publish a paper.” (Still fine.)
  3. “Get some feedback from the other doctors in the clinic.” (Getting warmer.)
  4. “What if we made this available to Frank? You remember, my best man, he’s practicing in Portland, he’d love this.” (You’re building a medical device now.)
  5. “My PhD student Jane is really entrepreneurial. She should start a company around this.” (Definitely a medical device, and you should have been following IEC 62304 since step 1.)

This progression happens a lot, and isn’t a problem in itself. The issue is that most of the documentation, design controls, and risk management that regulators expect must be created contemporaneously: that is, as development happens. If you’ve been building for two years in “research mode” and then decide to pursue regulatory clearance, you’re facing months of painful, expensive retrospective documentation. Your Design History File is supposed to be a real-time record of your development process. Fabricating it after the fact doesn’t work well, and experienced FDA reviewers can spot reconstructed documentation fairly easily.

The practical advice: if there is any realistic chance your research will become a clinical product, start treating it like one early. Read about the AI development lifecycle with regulatory requirements in mind. Set up proper version control and experiment tracking. Document your data provenance and annotation protocols. Build your training, validation, and test splits correctly from the beginning. These are all good research practices anyway, the AI equivalent of a good lab notebook.

The International Picture (Briefly)

While this article focuses on the FDA, the SaMD concept is global. If you plan to market your algorithm outside the United States, you’ll encounter analogous frameworks:

  • Health Canada classifies SaMD under its own medical device licensing framework, with specific guidance for Machine Learning Medical Devices (published 2025). Canada requires MDSAP certification and has its own nuances, including a Sex- and Gender-Based Analysis Plus (SGBA+) requirement.
  • The European Union regulates SaMD under the EU Medical Device Regulation (MDR), with additional requirements coming under the EU AI Act (medical device provisions effective August 2027).
  • The UK MHRA has its own framework, which is increasingly diverging from the EU post-Brexit.

The good news: the core concepts like SaMD definition, intended use, and risk classification are broadly similar across jurisdictions. However “broadly similar” does not mean identical, and multi-market regulatory strategy requires jurisdiction-specific expertise. Section 6.11 covers this in more detail.

A Decision Framework: Is Your AI a Medical Device?

If you’re unsure whether your specific situation crosses the regulatory line, work through these questions:

1. Does your software process, analyze, or interpret medical images? If yes, it’s almost certainly a medical device. The CDS exemption does not apply. Proceed to Section 6.2: Device Classification.

2. Does your software provide diagnostic, prognostic, or treatment recommendations based on patient data (non-imaging)? If yes, it’s probably a medical device, unless it meets all four CDS exemption criteria above. Consult a regulatory professional.

3. Is your software intended only for research, with no clinical use now or in the foreseeable future? If genuinely yes, likely not a regulated device today. But read the “research tool” section above carefully, and consider building with regulatory-grade practices anyway. Future you will be grateful.

4. Does your software summarize or display data without providing clinical recommendations? This is the narrowest potential CDS exemption case. It depends heavily on the specific implementation, claims, and how clinicians will actually use it. Get a regulatory opinion.

Almost always, the safest and most cost-effective move is a Q-Submission to the FDA, which is a formal request for written guidance. The FDA will tell you, in writing, whether they consider your software a medical device and which regulatory pathway applies. This costs nothing in user fees and relatively little in preparation time, and it can save you from either (a) unnecessary regulatory investment or (b) the much worse outcome of deploying a medical device without clearance.

Key Takeaways

  • Software alone can be a medical device. The determining factor is intended use, not the technology or form factor.
  • If your AI processes medical images, the CDS exemption almost certainly does not apply. This catches many teams off guard.
  • “Intended use” is a strategic decision that determines your entire regulatory path. Define it carefully and early.
  • The line between research tool and medical device is crossed gradually, often without a deliberate decision. If commercialization is even a possibility, build with regulatory requirements in mind from the start.
  • When in doubt, ask the FDA through a Q-Submission. Getting written guidance is faster, cheaper, and more reliable than guessing.

This article is part of the AI in Clinical Research Knowledge Base. It provides orientation, not legal or regulatory advice. All regulatory strategy should be reviewed with a qualified regulatory consultant.