If your product displays patient data, flags a drug interaction, or suggests a diagnosis, you may have already built a medical device without meaning to. The Food and Drug Administration draws a specific, technical line between software that supports a clinician's judgment and software that functions as a regulated medical device, and that line moved again in January 2026 when FDA revised its clinical decision support guidance. This matters for anyone building clinical decision support tools, diagnostic algorithms, or AI-driven healthcare features: get the classification wrong and you either build an unapproved device or over-engineer a tool that never needed a submission in the first place.
This article explains what Software as a Medical Device (SaMD) means, the exact statutory test that keeps clinical decision support (CDS) software out of device regulation, what changed in FDA's January 2026 guidance, and what AI-enabled products specifically need to plan for. It assumes you already understand what CDS software does day to day; if you need that primer first, see our explainer on clinical decision support software.
What "Software as a Medical Device" Actually Means
The term comes from the International Medical Device Regulators Forum (IMDRF), a group FDA chairs alongside regulators from other countries. IMDRF defines SaMD as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. FDA has adopted this definition and distinguishes SaMD from two other categories: software that is embedded in a hardware device (the firmware running an infusion pump, for example) and software used to manufacture or maintain a device.
SaMD is a functional description, not a product category. A mobile app, a cloud service, a module inside an EHR, and a standalone diagnostic algorithm can all be SaMD if their function meets the definition. What matters is what the software is intended to do, not how it is packaged or delivered.
The Four-Part Test That Keeps CDS Software Out of Device Regulation
Not all clinical software is a medical device. The 21st Century Cures Act amended the Federal Food, Drug, and Cosmetic Act to carve out a category of "non-device CDS." Section 520(o)(1)(E) of the FD&C Act excludes a CDS function from the device definition only if it meets all four of the following criteria:
- It does not 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.
- It is intended to display, analyze, or print medical information about a patient or other medical information.
- It is intended to support or provide recommendations to a health care professional about the prevention, diagnosis, or treatment of a disease or condition.
- It is intended to let the health care professional independently review the basis for the recommendations, so that the professional does not primarily rely on the software to make a clinical decision about an individual patient.
A function has to satisfy every criterion to stay out of device regulation. Fail any one, and the function is regulated as a medical device, subject to the usual classification, premarket pathway (510(k), De Novo, or PMA depending on risk), and quality system requirements. Most products that fail do so on the first criterion (because they analyze an image or waveform directly) or the fourth (because they are built to be relied on rather than reviewed).
What Changed in FDA's January 2026 Guidance
FDA's current guidance, Clinical Decision Support Software (docket FDA-2017-D-6569), was reissued as a final guidance in January 2026, replacing the 2022 version. The statutory test above has not changed; FDA cannot rewrite a statute through guidance. What changed is how FDA interprets two of the criteria in practice.
The 2022 version read the third criterion narrowly: software that gave a specific, singular recommendation (rather than a range of options for the clinician to weigh) was generally treated as failing that criterion and falling into device regulation. The January 2026 guidance adds enforcement discretion for functions that produce a single recommendation when only one option is clinically appropriate, provided the function still meets the other three criteria. This matters for tools built around protocols or guidelines where, in a given clinical scenario, there genuinely is only one reasonable next step. FDA did not define exactly how "clinically appropriate" should be determined, which leaves some judgment to the developer and their regulatory counsel.
The guidance also moved the "time-critical decision-making" limitation. The 2022 version tied time-critical decisions to the recommendation criterion; the 2026 version ties it to the independent-review criterion instead. In practice, a function intended for time-critical decisions is treated as one where the clinician cannot meaningfully pause to review the basis for the recommendation, which pushes it toward the device side of the line regardless of the other criteria. FDA has not defined "time critical" numerically, so this is assessed case by case.
Two things did not change. Software that analyzes medical images, waveforms, or in vitro diagnostic signals is still excluded from non-device CDS under the first criterion, full stop, no enforcement discretion applies there. And the guidance still applies only to software intended for health care professionals; FDA has not extended the same framework to consumer-facing tools such as patient-directed symptom checkers or wellness apps, which are evaluated under separate policies.
Risk Categorization: Not All SaMD Is Treated the Same
Once a function is determined to be SaMD, the next question is how much regulatory scrutiny it needs. IMDRF's risk categorization framework, developed by the working group FDA chairs, sorts SaMD along two dimensions: the significance of the information the software provides to a health care decision (informing, driving, or treating/diagnosing) and the state of the health care situation or condition (non-serious, serious, or critical). Combining those two dimensions produces four risk categories, with higher categories warranting more rigorous premarket evidence and more conservative lifecycle controls.
FDA maps this conceptual framework onto its own statutory device classes (Class I, II, or III) and the applicable premarket pathway, so the IMDRF categories are a planning tool rather than a formal U.S. regulatory classification. The practical takeaway for a product team: a CDS function that only informs a clinician's general awareness carries a different regulatory weight than one whose output is used to drive a specific treatment decision in a critical situation, even if both pass the same initial non-device test.
AI and Machine Learning Add a Lifecycle Problem
If your software is SaMD and uses machine learning, classification is only the first question. Models are commonly retrained, and each update to a locked model is, from a regulatory standpoint, a modification to the device. Submitting a new premarket filing every time a model is retrained is not realistic for most teams and is not how FDA wants this handled either.
FDA's answer is the Predetermined Change Control Plan (PCCP), finalized in December 2024 for AI-enabled device software functions. A PCCP lets a manufacturer describe, in its original submission, the specific types of future modifications it anticipates (for example, retraining on an expanded dataset) along with the methodology it will use to validate and monitor each change. Changes that fall within an FDA-authorized PCCP do not require a new submission each time; changes outside the plan do. Building a PCCP into your regulatory strategy from the start avoids a cycle of resubmission every time a model is updated, but it also means your team needs to anticipate the kinds of changes you will make well before you have real-world performance data to justify them, which is a genuine planning tradeoff, not a formality.
Teams building AI-assisted features inside a CDS product, such as the ambient documentation and summarization tools covered in our piece on ambient AI clinical documentation, should treat the SaMD question and the PCCP question as two separate decisions made early, not late: first, does this function meet the non-device CDS test; second, if it is SaMD, what is the plan for handling model updates over its lifecycle.
If You End Up Building a Regulated Device
Classification as SaMD is not a dead end, it is a different project plan. A regulated device pathway brings in design controls, risk management, and a formal quality management system. As of February 2, 2026, FDA's Quality Management System Regulation (QMSR) is in effect, replacing the prior Quality System Regulation at 21 CFR Part 820 and incorporating ISO 13485:2016 by reference with a small set of FDA-specific additions. Software teams that have never built a regulated device before should plan for this early: a quality management system, design history file, and risk management process are not things you retrofit in the weeks before a 510(k) submission.
This is also where the distinction between a software vendor and a software development partner with healthcare regulatory experience matters. Our guide on choosing a healthcare software development company covers what to look for in a partner who can navigate this alongside the engineering work.
A Practical Classification Checklist
Before writing a line of code for a new clinical feature, walk it through these questions:
- Does the function acquire, process, or analyze a medical image, an in vitro diagnostic signal, or a signal acquisition pattern? If yes, it is a device function regardless of anything else.
- Is the output intended for a health care professional, or for the patient directly? The non-device CDS test only applies to HCP-facing functions.
- Does the function give the clinician the facts and reasoning needed to independently evaluate the recommendation, or is it designed to be acted on without review?
- Is the function intended for use in a time-critical decision, where there is no realistic opportunity for the clinician to pause and review?
- If the function uses a trained model, what is the plan for handling retraining and updates over the product's life: a PCCP, or a new submission each time?
Running a proposed feature through this list during product discovery, rather than after a beta version is already in clinician hands, is the difference between a deliberate regulatory strategy and a scramble.
Frequently Asked Questions
Does every clinical decision support tool need FDA clearance?
No. Software that meets all four non-device CDS criteria under FD&C Act Section 520(o)(1)(E) is excluded from the device definition and does not need premarket clearance. Many order-set tools, reference lookups, and recommendation engines that let a clinician review the underlying reasoning fall into this category.
Does the January 2026 guidance mean FDA regulates less clinical software?
It narrows one specific gap: functions that give a single recommendation when only one option is clinically appropriate now have a path to enforcement discretion that did not exist as clearly under the 2022 guidance. The underlying statutory test is unchanged, and functions that analyze images or signals, or that are meant for time-critical use without review, are still treated as device functions.
Is this guidance final legal certainty for our product?
No single piece of guidance settles a specific product's classification. FDA guidance documents describe the agency's current thinking and are not legally binding in the way a regulation is; they also leave terms like "clinically appropriate" and "time critical" undefined. A classification determination for a specific feature should involve regulatory counsel or a qualified consultant, not a general reading of the guidance alone.
If our CDS feature is SaMD, does that block us from using AI or machine learning?
No. FDA has cleared numerous AI-enabled SaMD products and has a specific mechanism, the Predetermined Change Control Plan, for managing model updates without a new submission for every retraining cycle. It does mean more upfront planning for how the model's lifecycle will be managed and documented.
Where does HIPAA fit into this?
Separately. SaMD classification is about whether FDA regulates the software's clinical function; HIPAA governs how protected health information is handled regardless of device status. A tool can be both a regulated device and subject to HIPAA's Security and Privacy Rules, and clearing one does not satisfy the other.
This article explains general regulatory concepts for planning purposes and is not legal advice. Classification decisions depend on the specific function, intended use, and labeling of your software, and should be confirmed with qualified regulatory counsel before you finalize a product or submission strategy.
Sabyrix Technologies builds healthcare software with this kind of regulatory nuance factored into the architecture from day one, not bolted on after a beta launch. If you are scoping a clinical decision support feature or an AI-assisted diagnostic tool and need the technical side mapped out early, book a strategy call or see how we approach healthcare AI development.