FDA’s decision support revision handed hospitals a classification question

The week

On January 6, 2026, the Food and Drug Administration issued revised final versions of two digital health guidance documents, and Commissioner Marty Makary promoted them in a video and at the Consumer Electronics Show, the giant annual technology fair in Las Vegas, as a push for innovation in AI and wearables. It was unusual fanfare for a regulatory document.

A guidance document is FDA’s written explanation of how it reads the law and how it intends to act. It is not a regulation and does not bind anyone, but companies and hospitals treat it as the practical rulebook. Normally FDA publishes a draft first and invites public comment. This time it issued the revised versions as final, without a draft or comment period.

The first document, the Clinical Decision Support Software guidance, replaced the 2022 version. Clinical decision support, or CDS, is software that helps clinicians make decisions: flagging a possible drug interaction, suggesting a diagnosis to consider, or recommending a next step based on guidelines. Some of it counts as a medical device under federal law and needs FDA review; some does not.

The key change: FDA said it would exercise enforcement discretion for software that gives a single recommendation where only one is clinically appropriate, if the other non-device criteria are met. “Enforcement discretion” means the agency is choosing not to enforce its device rules against a category of product, even if the product might technically qualify as a device. The criteria still exclude software that analyzes medical images or signals, such as scans or heart tracings, and software for time-critical decisions, where there is no time for a clinician to check the reasoning.

The second document, the revised General Wellness guidance, replaced the 2019 version. It covers products meant to support healthy living rather than to diagnose or treat disease, the territory of fitness trackers and smartwatches. It said some non-invasive products that estimate measures such as blood pressure or oxygen saturation, the level of oxygen in the blood, can be wellness products, if intended solely for wellness rather than for diagnosing or treating disease.

Taken together, the two documents widened the space in which health software and wearables could reach clinicians and patients without FDA review. What they did not do, despite the AI framing, was say much about AI specifically.

The headlines called it deregulation. A close reading supports a narrower description. FDA did not change its interpretation of the statute that separates device software from non-device decision support. It extended enforcement discretion, which is a policy choice not to act and can be withdrawn. The line in the law stayed where it was; FDA said it would look away from more products near that line.

Several law firms noted that the CDS guidance says almost nothing about AI specifically, despite how it was announced. Nothing in it explains how a generative model, the kind of AI that writes fluent text in response to a question, meets the criteria, or how FDA views clinician-facing chatbots.

That gap matters to health systems, because they buy and deploy these tools. Before January, many relied on a simple signal: a cleared product had been reviewed, and an unreviewed one was either low-risk support or a vendor problem. After January, more products sit in a gray zone where the vendor’s regulatory position is an assertion. A hospital deploying a decision support tool now has three questions to answer. Which category is the tool in? Do the conditions for that category hold in its own workflow? And what could later move the tool across the line?

From drug alerts to single recommendations

Decision support has been around a long time. For decades, hospital systems have warned a pharmacist about a dangerous drug combination or reminded a physician that a patient is due for a screening. What has changed is the sophistication of the tools and the number of vendors selling them.

Most decision support works inside the electronic health record, the digital chart where clinicians document care and place orders. The software reads information from the chart, such as lab results, vital signs, medications and diagnoses, applies some logic to it, and shows the clinician something: an alert, a score, a suggested order, a draft note. The logic might be a simple rule drawn from a published guideline (“if potassium is above this level, warn”), a statistical model trained on past patients, or, increasingly, an AI model.

Federal law draws a line between decision support that is a medical device and decision support that is not. Broadly, software stays on the non-device side if it does not analyze medical images or signals, if it supports rather than replaces a clinician’s judgment, and if the clinician can independently review the basis for its recommendation instead of simply relying on it. A reference book that explains its reasoning is not a device; an instrument that reads a patient’s heart rhythm and announces a diagnosis is.

The January change concerned software that offers one recommendation rather than a list of options. Previously, offering a single answer tended to push software toward the device side, on the theory that it steered the clinician too strongly. Now, where only one recommendation is clinically appropriate, FDA said it would not act, provided the other criteria are met.

The wellness guidance is the consumer mirror image. A smartwatch that estimates blood pressure “for wellness” can stay outside FDA review, even though the same reading, used to diagnose hypertension, would put it inside. The device is identical; the stated purpose decides its category.

Which category the tool is in

A decision support product can be a cleared device, a device FDA has chosen not to regulate actively, or software that is not a device at all. Each carries different evidence. A cleared device comes with a summary of the data FDA reviewed. A tool under enforcement discretion comes with whatever the vendor chooses to share. The categories also carry different exposure if something goes wrong.

The practical step is to make regulatory status an intake requirement, a box that must be filled before any tool enters the hospital. A vendor should state in writing which category it claims, which criteria it relies on, and why. For a single-recommendation tool, it should explain why only one recommendation is clinically appropriate, a judgment the guidance leaves undefined. The clinical informatics or AI governance committee, the group of clinicians, informatics specialists and administrators that approves technology touching patient care, then records the claim and its own assessment. Counsel should advise where the claim looks thin.

Consumer wearables need the same discipline from the other direction. Under the wellness guidance, a watch reporting blood pressure may be a wellness product, not a validated diagnostic device. When patients share those readings, or remote monitoring programs pull them into the chart, the record should label their source. Clinicians should not have to guess whether a value came from a cleared cuff or a wrist sensor. A blood pressure number in the chart looks authoritative regardless of where it came from; the label is what tells a clinician how much weight to give it.

Whether the conditions hold in your workflow

Non-device status depends partly on how the software is used, as well as how it is built. The central condition is that a clinician can independently review the basis for a recommendation, rather than rely on it. The revised guidance put more weight on usability: the information should be relevant to the decision and not bury the clinician.

A vendor can design for this. Only the hospital can make it true. If the explanation sits three clicks away, if clinic schedules leave no time to read it, or if the tool runs in a setting the vendor did not intend, the condition may fail locally. Busy clinicians, reasonably, take the path of least resistance; if the reasoning is hard to reach, they will not reach for it.

The time-critical exclusion is the sharpest case. A sepsis or deterioration tool marketed for routine review can drift into emergency use through local configuration and alert routing. Sepsis is the body’s dangerous overreaction to infection, where hours matter; a deterioration tool watches for patients getting worse. Both are exactly the kind of tool where a clinician may have no time to study the reasoning before acting. If a hospital routes such an alert straight to a rapid response team at 2 a.m., the decision it supports may have become time-critical, whatever the vendor’s brochure says.

When acceptance is near total

Suppose a hospital buys a tool which reads the chart and suggests the single most appropriate follow-up test for certain abnormal lab results. The vendor says it falls under enforcement discretion. At go-live, the informatics team checks three things: whether the physician can see, on the same screen, which lab values and which guideline drove the suggestion; how often physicians opened that explanation in the first month; and whether anyone configured the tool to fire in the emergency department, where decisions are faster. The team finds acceptance rates near total and the explanation rarely opened. That does not prove a problem, but it prompts a conversation with clinical leaders about whether the tool is being reviewed or simply followed.

Go-live testing should therefore cover the workflow as well as accuracy: whether a clinician can see the inputs and the reasoning where the decision is made, how often clinicians open that explanation, and whether the tool is firing in units where decisions are time-critical. Override and acceptance rates belong on the list too. Very high acceptance can signal reliance rather than review, which undercuts the condition the tool’s status depends on.

These checks also produce evidence a hospital may need later. If a patient is harmed and the tool’s role is questioned, the record should show that clinicians could see its basis, that the tool ran where it was meant to, and that someone was watching. Medical staff peer review and incident reporting processes should capture whether a decision support tool was involved, so that pattern review is possible across cases rather than one complaint at a time.

What can move a tool across the line

A tool’s category is not fixed at purchase. Vendors update models, add data sources and extend features, often through automatic software updates the hospital barely notices. A documentation assistant that drafts a report from a radiologist’s findings may sit under enforcement discretion. The same product, updated to analyze the image itself, would not. A recommendation drawn from published guidelines differs from one drawn from a proprietary model trained on undisclosed data.

Without an FDA submission as a forcing function, the hospital is the party most likely to notice such a change, and only if its contract requires notice. Agreements for decision support should require advance notice of material changes to inputs, models, intended use or regulatory position. They should also give the hospital access to performance data and cooperation in safety reviews. Internally, each tool needs a named clinical owner and a version record, so a change triggers re-review rather than passing silently into production.

Proportion keeps this workable. A drafting aid that a clinician edits line by line does not need the scrutiny of a tool that suggests a dose. A short risk tier, based on the consequence of a wrong output and how easily a clinician would catch it, lets a governance committee spend its time on the tools that warrant it.

How governance works in practice

Inside a well-run health system, a single tool passes through six stages.

Request. A department chair, a nursing leader or a vendor proposes a tool. The proposal goes to the governance committee rather than straight to purchasing, so nothing arrives in the chart through a side door.

Intake. The vendor completes a standard form: what the tool does, what data it uses, who it is meant for, which regulatory category it claims and on what criteria, and what evidence of performance exists. The committee assigns a risk tier and decides how deep the review needs to be.

Contract. Purchasing and legal use a standard template that includes notice of material changes, access to performance data and cooperation in safety reviews. These terms are much easier to secure before signature than after.

Build and configuration. The informatics team decides where the tool will appear, who will see it and when it will fire. This is the stage where a routine tool can drift into a time-critical setting, so the configuration is checked against the intended use the vendor stated.

Go-live and monitoring. The tool goes live in a limited area first. The team watches whether clinicians open the reasoning, how often they accept or override, and whether any incidents mention it. Results return to the committee at a set interval.

Change and retirement. When the vendor announces an update, the named clinical owner decides whether it is material. If it is, the tool goes back through a shortened review. When a tool stops earning its place, it is switched off deliberately and the decision is recorded.

The process does not require a large bureaucracy. In a smaller hospital, the committee may be a handful of people meeting monthly, and the intake form a single page. What matters is that every tool passes through the same steps, and that the reasoning at each step is written down somewhere it can be found later.

Where responsibility lands when FDA steps back

Four reasons put this on leaders’ desks as well as the informatics team’s.

Patient safety and liability. When FDA steps back, responsibility does not disappear; it shifts. If a tool contributes to harm, questions will be asked about how the hospital chose it, configured it and monitored it. A documented intake review and go-live testing are the hospital’s answer.

Procurement and cost. Many vendors want a place in hospital workflows. Without a consistent intake process, each purchase becomes a one-off negotiation, and contract terms on notice and performance data are lost in the rush. Building those terms into a standard template is cheaper than renegotiating later.

Clinician trust and workload. Tools that bury clinicians in alerts or explanations they cannot use add to burnout and erode trust in all decision support, including the good tools. Usability, which the revised guidance emphasized, is also a workforce issue.

Regulatory instability. Enforcement discretion can be withdrawn. A hospital that recorded why it classified each tool as it did can adapt quickly if FDA changes course; one that relied on vendor marketing cannot.

A record that survives a change of policy

The hospitals that manage this well share a few habits: a standard intake form requiring each vendor’s written regulatory claim; a governance committee that records its own view alongside the vendor’s; go-live testing that checks visibility of reasoning, setting and acceptance rates; wearable data labeled by source; contracts requiring notice of material changes; a named owner and version record for every tool; and a simple risk tier that focuses attention where consequences are greatest.

They are also honest about limits. A governance committee cannot test every tool exhaustively, and it does not need to. It needs to know which tools it has, what each one claims, who owns it and how it is behaving, and to spend its deepest scrutiny on the tools where a wrong answer would hurt a patient and might not be caught.

The usual failures mirror these: taking “not a device” from a sales deck as settled; testing accuracy but not workflow; letting local configuration move a routine tool into time-critical use; accepting automatic updates without asking what changed; and treating every tool with equal scrutiny, so the committee runs out of time before it reaches the ones that matter.

Where a hospital’s classification is weakest

• For each decision support tool we use, which regulatory category does the vendor claim, in writing, and do we agree?
• Are any tools firing in emergency or other time-critical settings their vendors did not intend?
• What are our acceptance and override rates, and what would make us concerned?
• Do our contracts require vendors to tell us before they change models, inputs, intended use or regulatory position?
• Can a clinician tell, from the chart, whether a blood pressure or oxygen reading came from a validated device or a consumer wearable?

A hospital that cannot yet answer these should start with the tools that suggest doses or fire in time-critical settings, and work outward from there.

With hindsight

The narrower reading of January 6 has held up better than the deregulatory one. Commentators such as Covington described the CDS revision as keeping most of FDA’s existing policy, and the image-analysis and time-critical limits stayed in place. The change was real: a widening of the space FDA chose not to police, with the law itself left as it was.

The documents were final guidance issued without comment, so they are nonbinding and could be revised again with little notice. That instability is itself a reason for hospitals to record why they classified each tool as they did. A classification decision written down with its reasoning can be revisited calmly if the policy shifts; one that lives only in a vendor’s marketing materials cannot.

The gap commentators flagged, that neither document addressed AI directly, was the more lasting issue. We would not assume that any later FDA work on AI resolves the gray zone soon. For now, generative models and clinician-facing chatbots sit in territory that the guidance does not describe, and hospitals deploying them are making judgments without a federal map.

Hospitals will also meet tools that blend categories, such as a drafting aid that also suggests next steps, and those judgments remain local. In the meantime, vendor statements of regulatory status have effectively become a procurement term, as much a part of the contract as price or uptime. Health systems that wrote them into contracts and intake reviews have a defensible record; those that took marketing language at face value do not.

A regulator stepping back moves work onto the organizations that buy and use the technology. The hospitals coping well are the ones that treated January 6 as a reason to strengthen their own governance, rather than as permission to relax it. That work, unlike the guidance itself, does not depend on what FDA does next.