FDA’s decision support revision handed hospitals a classification question
FDA’s January 6 guidance widened enforcement discretion for some decision support software and wellness wearables, but did not reinterpret the law or address AI directly. Health systems inherited the job of deciding where each tool sits, and keeping it there.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On January 6, 2026, FDA issued revised final versions of two digital health guidance documents, without a draft or comment period. Commissioner Marty Makary promoted them in a video and at the Consumer Electronics Show as a push for innovation in AI and wearables. The Clinical Decision Support Software guidance replaced the 2022 version. 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. Those criteria still exclude software that analyzes medical images or signals, and software for time-critical decisions. The revised General Wellness guidance replaced the 2019 version. It said some non-invasive products that estimate measures such as blood pressure or oxygen saturation can be wellness products, if intended solely for wellness and not prompting clinical action.
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. 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 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?
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 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 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.
Whether the conditions hold in your workflow
Non-device status depends partly on how the software is used, not only 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. 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.
Go-live testing should therefore cover the workflow, not only accuracy. Can a clinician see the inputs and the reasoning where the decision is made? How often do clinicians open that explanation? Is the tool firing in units where decisions are time-critical? Override and acceptance rates are worth tracking 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. 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.
With hindsight
With some distance, 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 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.
The gap commentators flagged, that neither document addressed AI directly, was the more lasting issue. FDA signaled further work on its broader software policy and on an AI framework. We would not assume that work resolves the gray zone soon. In the meantime, vendor statements of regulatory status have effectively become a procurement term. Health systems that wrote them into contracts and intake reviews have a defensible record; those that took marketing language at face value do not.