The question every healthtech AI feature has to answer
Before a clinical AI feature ships, someone has to answer a question that engineering teams routinely discover too late: is this a medical device? If it is, it needs an FDA pathway — premarket notification, De Novo, or approval — before it touches a patient workflow. If it is not, it ships like any other software. The difference is months of timeline and a fundamentally different engineering process.
The boundary is not drawn by how sophisticated your model is. It is drawn by four criteria in Section 520(o)(1)(E) of the Food, Drug, and Cosmetic Act, added by the 21st Century Cures Act, and interpreted by FDA's clinical decision support guidance — most recently updated in January 2026.
The four criteria, in plain engineering terms
A CDS function stays outside device regulation only if all four hold. First: it must not acquire, process, or analyze a medical image or a signal from an in-vitro diagnostic or signal-acquisition system. Feed a model raw ECG waveforms or radiology images and you are out on criterion one, whatever else you do. Second: it displays or analyzes medical information — patient data, clinical guidelines, peer-reviewed literature. Third: it supports or provides recommendations to a healthcare professional; it does not replace their judgment or address a patient directly. Fourth — the one architects control — it must enable the clinician to independently review the basis for the recommendation, so they are not relying primarily on the software's say-so.
The January 2026 guidance update matters here: FDA clarified that software offering a single recommendation, rather than a ranked list of options, can still qualify — as long as the clinician can see and evaluate the reasoning. That removed a long-standing ambiguity that pushed teams toward artificial "here are three options" interfaces.
Criterion four is an architecture requirement
Three of the four criteria are settled by product scope. The fourth is settled by system design. "Independently review the basis" means the recommendation must ship with its reasoning: the patient data it drew on, the guideline or evidence it applied, and the logic connecting them — in language a clinician can evaluate against their own judgment.
For an LLM-backed feature, this rules out the naked chat answer. The architecture needs retrieval provenance (which sources fed the response), evidence surfacing in the UI (the actual excerpts, not just citations), and plain-language reasoning. These are the same properties a well-built RAG pipeline already has — which is why a privacy-first RAG architecture and a Non-Device CDS posture tend to be the same design, arrived at from two different directions.
A black box fails the exemption by construction. Explainability is not a nice-to-have here — it is the regulatory boundary.
When you cross the line — and when you should choose to
Sometimes the product genuinely needs to be a device: analyzing images, processing device signals, or driving decisions in settings where the clinician cannot practically review the basis. That is not a failure — it is a different roadmap, with a regulatory pathway, a quality system, and (for AI functions) lifecycle obligations that reach into your MLOps design.
The architectural mistake is drifting across the line unknowingly: a "summarization" feature that quietly starts interpreting lab signal data, or a UI change that buries the evidence panel until nobody reviews the basis in practice. Treat the four criteria as invariants in your design reviews — write them into the feature spec, and flag any change that touches inputs (images, signals) or the review surface.
Frequently asked questions
Does using an LLM automatically make my clinical software a medical device?
No. The exemption turns on what the software does — its inputs and how the clinician can review its reasoning — not the model class. An LLM feature that analyzes medical text and shows its basis can qualify; any software analyzing medical images or device signals cannot, regardless of model.
What changed in FDA's January 2026 CDS guidance?
FDA clarified that single-recommendation CDS can qualify for the Non-Device exemption when the clinician can independently review the basis, and reaffirmed that AI/ML software processing medical images, IVD signals, or signal-acquisition data is regulated as Software as a Medical Device.
Who decides whether our feature meets the criteria?
Ultimately your regulatory counsel — but the determination depends on architectural facts: what data the system ingests, what it surfaces to the clinician, and whether the reasoning is reviewable. Engineering decides those facts, which is why architects need to know the criteria.