Software becomes a regulated medical device based on what it is intended to do, not on how it is built or what it is called. The 21st Century Cures Act amended the Federal Food, Drug, and Cosmetic Act in 2016 to carve certain clinical decision support functions out of the device definition, and the carve-out is conjunctive: software has to satisfy every one of the four criteria in section 520(o)(1)(E) to fall outside FDA’s device authority, and failing any single one puts it back inside. That is the practical test, and it is why the question cannot be answered from a feature list. Two products with near-identical screens can land on opposite sides of the line because one displays information for a clinician to evaluate independently and the other issues a specific directive the clinician is expected to follow. If you are scoping a build, this determination belongs in week one — it changes the budget, the timeline and the documentation burden more than any technical decision you will make.
Why “Are We a Medical Device?” Is the Wrong First Question
Teams usually ask it as a yes/no about the product. It is not a property of the product. It is a property of the intended use — what you claim the software does, who you claim it does it for, and what you expect the user to do with the output. Marketing copy is evidence of intended use. So are sales conversations, so is the user manual, and so is what your onboarding flow tells a clinician to do next.
That has a consequence most engineering teams find uncomfortable: a product can move across the line without a line of code changing. Tighten the marketing claim from “surfaces relevant lab trends” to “identifies patients at risk of sepsis” and you have potentially changed the regulatory status of a system whose behaviour is identical. This is why the determination has to be made jointly by whoever owns the product claim and whoever owns the build, and why it cannot be delegated entirely to either.
The Cures Act Carve-Out, and Why It’s Narrower Than People Think
Section 3060(a) of the 21st Century Cures Act, enacted 13 December 2016, amended section 520 of the FD&C Act to exclude certain software functions — including certain decision support functions — from the definition of a device. FDA’s Clinical Decision Support Software guidance sets out the agency’s thinking on which functions those are.
The structure matters more than any individual criterion. There are four Non-Device CDS criteria in section 520(o)(1)(E), and software must meet all four to sit outside the device definition. This is not a scoring exercise where three out of four is a pass. One of them, to give the shape of it, turns on whether the software is intended to acquire, process or analyse a medical image or a signal from an in vitro diagnostic device — software that does is not eligible for the exclusion at all, regardless of how it presents its output.
Read the criteria in the guidance itself before relying on them. We are deliberately not reproducing all four here, because the exact wording carries the meaning and a paraphrase in a blog post is not a basis for a regulatory decision. The current final guidance was issued in January 2026, and FDA held a public Town Hall on it on 11 March 2026. A great deal of the content you will find on this topic still cites the September 2022 version — check the date on anything you read, including advice from a development vendor.
The Distinction That Decides Most Cases
Across the guidance, one theme does more work than any other: whether the clinician can independently review the basis for the software’s output, or whether they are expected to rely on it.
| Points away from device status | Points toward device status | |
|---|---|---|
| Output | Information the clinician weighs | A specific directive to follow |
| Basis | Inputs and logic are visible and reviewable | Opaque — a score with no inspectable reasoning |
| Urgency | Time to consider and cross-check | Time-critical, discourages independent review |
| Inputs | Discrete data the clinician could examine | Medical images or IVD signals |
| User | Healthcare professional | Patient or lay caregiver |
The right-hand column is not a list of forbidden features. Plenty of successful products live entirely in it — they are simply regulated products, built and documented accordingly. The mistake is landing in the right-hand column while planning and budgeting as though you were in the left.
Where This Bites in a Build
Three places, in the order teams usually hit them.
The estimate. A regulated product carries design controls, a documented risk management process, verification and validation evidence, and a submission pathway. That is not a percentage uplift on a conventional software budget; it is a different budget with different line items and a different calendar. A firm that quotes your project without having asked what the regulatory status is has quoted the wrong project — which is one of the questions worth asking before you sign anything, and a theme we go into more broadly in how to actually evaluate a HIPAA-compliant development company.
The AI feature. This is where it is currently biting hardest. A model that produces a risk score is much harder to fit inside the independent-review criterion than a rules engine whose logic a clinician can read, precisely because the reasoning is not inspectable in the same way. That does not make it impossible, and it does not make the feature a bad idea — but “we added a predictive model in a sprint” is a sentence that can change a product’s regulatory status, and it should trigger a re-check rather than a release note.
The pivot. Products drift. A tool that summarised data for clinicians adds a nudge; a documentation aid starts suggesting codes; an analytics dashboard begins flagging patients. Each change is small and none of them feels like a regulatory event. The determination made at kickoff has a shelf life, and somebody needs to own re-checking it.
What This Is Not
Two clarifications that save a lot of confusion:
- This is separate from HIPAA. Device status and PHI obligations are different regimes answering different questions. Software can be a regulated device and not touch PHI; it can handle PHI heavily and not be a device. Most healthcare products need to answer both questions independently — the HIPAA side is covered in what actually makes an app HIPAA compliant.
- This is separate from EHR certification. ONC certification criteria for health IT are a different framework again, with their own requirements. Being certified says nothing about device status, and vice versa.
How to Actually Get an Answer
Write down the intended use statement first — one or two sentences saying what the software does, for whom, and what the user is expected to do with the output. Be honest rather than conservative; the statement you would actually put in front of a buyer is the one that matters, not a hedged version drafted to pass a test.
Then take that statement, and the four criteria as written in the current guidance, to someone qualified to give a regulatory opinion. That is a regulatory consultant or an FDA-experienced attorney — not your development partner, and not a blog post. What a good development partner should do is raise the question early, build in a way that does not foreclose the regulated path, and document decisions as though they may need to be explained later. What they should not do is tell you the answer.
Next Steps
If you are early enough that the intended use is still being written, that is the best possible time to have this conversation — the cost of designing for a regulated path is a fraction of the cost of retrofitting one. If you are already building and the question has never come up, it is worth an hour now rather than a discovery during due diligence.
We build clinical software on both sides of this line and scope it accordingly — see healthcare app development for how we work, or talk to our team about where your product sits. We will tell you when you need a regulatory opinion rather than a developer’s guess, which is more often than most vendors will admit.