Clinical decision support software after the FDA's 2026 guidance: designing a recommendation a clinician can check

Clinician-facing clinical decision support software stays outside FDA device regulation only if it meets four criteria, and the fourth is about what the clinician can see: they must be able to independently review the basis for a recommendation. The FDA's Clinical Decision Support Software guidance, issued on 29 January 2026, keeps those criteria and lets a tool give a single recommendation where only one option is clinically appropriate.

That review is decided on the screen: which inputs are shown, how the logic is applied to this patient, what is missing, and what the clinician does when they disagree.

This article is about that screen. We write as product designers, so treat it as design guidance: whether a given function is a device is a legal and regulatory question, and your legal and regulatory owners decide it.

What the 2026 guidance says

The FDA first issued this revision on 6 January 2026. The current document is dated 29 January 2026 and supersedes it; its history table describes the later version as a minor correction that deletes a reference to time-critical decision-making on two pages.

The four criteria come from section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act, added by the 21st Century Cures Act. In plain words, a software function is not a device if it:

1. does not acquire, process or analyse a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system (an ECG waveform, continuous glucose readings, sequencing data);
2. displays, analyses or prints medical information about a patient, or other medical information such as clinical guidelines and peer-reviewed studies;
3. supports or provides recommendations to a healthcare professional about prevention, diagnosis or treatment; and
4. enables that professional to independently review the basis for those recommendations, so that they do not rely primarily on them for a decision about an individual patient.

All four must hold. Under criterion 3, the FDA reads a "specific preventive, diagnostic or treatment output or directive" as a failure. What is new is the carve-out: "if only one option is clinically appropriate" and the function otherwise meets all four criteria, the FDA intends to exercise enforcement discretion. Its examples include a function that recommends one FDA-approved antibiotic based on symptoms, recent hospitalisations and previous antibiotic exposure, and one that places a patient with chronic low back pain on a single care pathway, each left for the clinician to consider or review.

Two limits remain. The guidance covers only tools for healthcare professionals: software that gives recommendations to patients or caregivers meets the device definition. And the FDA still does not consider a function intended for "a critical, time-sensitive task or decision" to meet criterion 4. We cover both below.

Our healthcare UX guide takes the broad view of designing for clinicians, patients and regulators; this page stays on the recommendation itself.

Why criterion 4 reads like a screen specification

The FDA lists four things it recommends a tool or its labelling provide to meet criterion 4:

• Intended use: the purpose, the intended clinician and the intended patient population.
• Inputs: the medical information the tool needs, with plain-language instructions on how it should be obtained, why it matters and what data quality it requires.
• Basis: a plain-language description of how the algorithm was developed and validated, covering the general approach (an expert panel, a meta-analysis, statistical modelling, machine learning), the data it relied on, so a clinician can judge whether their patient is represented, and the validation results, including where performance is untested or variable.
• The output itself: relevant patient-specific information and the "knowns/unknowns", such as missing, corrupted or unexpected input values.

It then adds two sentences a designer would recognise. The information should be presented "in a manner that promotes usability and avoids information overload", putting the most decision-relevant information first and making more detail available as needed. And developers "may need to perform usability testing" to show the criterion is met.

The guidance also gives a worked failure. Its example 31 is a tool that suggests follow-up options after a mammogram, trained on 100,000 cases from 10 sites, labelled with its purpose and users, and not time-critical. It still fails criterion 4 for three reasons: the clinician cannot see which information from the record or the radiologist's report it used; details of the development and validation data (site mix, breast density, ethnicity) are not available; and nothing shows which variables drove the recommendation. Every one of those is something a screen either shows or hides.

The argument we test in the rest of this page is simple. A recommendation a clinician cannot check is one they will either ignore or follow blindly. The research on both failure modes, which we come to below, supports it, with one caveat: showing your working only helps if the working is something the clinician can actually check.

The anatomy of a recommendation screen

We split a recommendation into five parts. The order matters: the clinician should meet the inputs and the basis before, or alongside, the recommendation, not behind a click they may never make.

Inputs. The FDA's worked examples are specific here. A tool listing treatment options for end-stage renal disease "indicates whether any expected input medical information from the medical record was missing". A tool for patients with COPD shows the patient's age and average daily steps, the date of the measurement and how the steps were collected. Design the input list so a wrong value is easy to spot (units, dates, the source system) and, where the workflow allows, so the clinician can correct it and see the recommendation recompute.

Basis. The guidance names the forms it has in mind: matching patient data to criteria in a practice guideline, comparing against a reference or normal database, or a prioritised schema. For guideline logic, show the criteria row by row with this patient's value against each, and name the guideline with its version or date. For a model, the clinician needs the general approach in one line and the key variables for this result, with a second layer for the development and validation data. The FDA's example 32, a ranked list of depression treatments that fails criterion 4, shows what that second layer must hold: the studies relied on, and which of them most closely match this patient. For drug-interaction alerts, the guidance suggests a direct link to an up-to-date source such as DailyMed.

Recommendation. Write it so the words match what the function actually does. If the tool is in effect telling the clinician what to do, a softer verb does not change that; the FDA's generative-AI discussion paper, covered below, makes the same point.

Uncertainty and gaps. "Knowns and unknowns" is the FDA's phrase, and it belongs on the first screen. The COPD example lists the number of days with missing step data and high day-to-day variability as limits to consider. Population fit is the other half: if this patient sits in a subgroup the validation did not cover, say so beside the recommendation, not in the labelling alone.

Override and record. Disagreeing should take one step, with a short list of coded reasons and an optional note. The HL7 CDS Hooks specification gives EHR-embedded tools a ready shape for this: each card carries a summary of under 140 characters, an indicator of info, warning or critical, a required source, optional override reasons, and feedback that reports whether a suggestion was accepted or overridden. Keep the inputs, the logic version, the recommendation and the decision together, so a later review can see what the clinician saw. Our work on human-in-the-loop review steps covers decision records in more depth, and our page on the clinician's review step for AI scribes covers the different job of checking a drafted note.

When to show one recommendation and when to show options

A list remains the default pattern: the guidance says a list of options, a prioritised list, or a list of next steps can satisfy criterion 3. The single recommendation is now available, but only where one option is clinically appropriate, and that is a clinical judgement, not a layout choice.

Three rules follow for the design team:

• Let the clinical owners decide when the single state applies. The FDA's differential-diagnosis example presents "either multiple diagnostic considerations or a single clinically appropriate diagnostic recommendation when alternative diagnoses are highly improbable". Design both states of the same component, and have the rule for switching between them written down by the people accountable for it.
• Show why the alternatives fell away. A single recommendation is easier to check when the screen says what was ruled out and on what basis, for example an allergy or a contraindication drawn from the inputs.
• Never collapse a ranked list to its top item for tidiness. If several options are clinically reasonable, a one-item screen misstates what the tool knows.

The counter-examples matter as much. In the guidance, the same cardiovascular risk tool stays outside oversight when it predicts future events and becomes a device when it predicts an event in the next 24 hours; the same back-pain pathway tool becomes a device for acute pain from trauma.

Time-critical use

The FDA's reasoning is that in a time-critical decision a clinician "is unlikely to have sufficient time" to review the basis, and that automation bias increases when action is urgent. Its device examples include functions that detect stroke or sepsis and raise an alarm, that flag patient deterioration from hourly pulse oximetry, and that triage a stroke patient for transfer.

For design, this means that adding more explanation does not change where a time-critical tool sits: that boundary is set by intended use, and your regulatory owners decide it. What design can do is make the intended use visible and keep the product honest to it. If a tool is meant for planning, such as the guidance's example of 90-day and one-year risk after lung transplantation, avoid patterns that pull it into the urgent moment: interruptive pop-ups, alarm styling, or placement in the acute order flow. If research shows clinicians reaching for it in urgent situations, raise that with the people who own the intended use.

The two central risks: automation bias and alert fatigue

The FDA defines automation bias as "the propensity of humans to over-rely on a suggestion from an automated system", leading to errors of commission (following incorrect advice) or omission (failing to act because nothing prompted it). Alert fatigue is its mirror: so many prompts that clinicians stop reading them. Both are measured.

On alert fatigue, a study of outpatient prescribing by Nanji and colleagues in JAMIA (2014) reviewed 157,483 medication alerts on 2,004,069 orders. Clinicians overrode 52.6% of them. In a reviewed subset of overrides, about half were judged appropriate, ranging from 12% for renal recommendations to 92% for allergy alerts. Clinicians were right to dismiss many alerts and wrong to dismiss others. The study did not test screen design, but when an alert cannot show why it fired, the clinician is left to sort signal from noise alone.

On automation bias, a randomised vignette study by Jabbour and colleagues in JAMA (2023) asked 457 hospitalist physicians, nurse practitioners and physician assistants to diagnose the cause of acute respiratory failure. Baseline accuracy was 73.0%. A standard AI model raised it by 2.9 percentage points; a systematically biased model lowered it by 11.3 points. Explanations helped with the standard model, but with the biased model they brought only a non-significant improvement. Those explanations were heat maps over the chest radiograph. The authors report that the biased model's heat maps showed it looking at irrelevant features, and clinicians still did not recover their accuracy. That is the caveat to our argument: the basis has to be expressed in terms a clinician can test against what they know, such as inputs, criteria and the patient's own values.

Generative AI recommendations: the August 2026 discussion paper

On 18 August 2026 the FDA published Considerations for the Regulation of Generative AI-Enabled Medical Devices, a discussion paper and request for feedback. It says plainly that it is not draft or final guidance and does not propose policy; comments closed on 19 October 2026. It is still useful to a design team, because it shows how the FDA's device centre is thinking.

It sketches a possible two-axis view of risk: what the function does, from non-directive information through action-directing to acting with or without clinician supervision, against the consequence of relying on a wrong output. It treats "non-directive" and "action-directing" as a continuum, with a lisinopril example running from general information ("dosages are sometimes increased") to a specific instruction ("increase the lisinopril from 10 mg to 20 mg daily"). It says the degree of direction may depend on the substance and context of the output, "not solely on whether it uses words such as 'recommend,' 'should,' or 'consider.'" Among its proposed evaluation elements it names automation bias arising from "the device's fluency or perceived authority", and for agentic systems, compliance with human-oversight checkpoints before irreversible or high-consequence actions.

For a recommendation screen built on a language model, the design consequences are concrete: generated prose sits beside the structured inputs and cited sources, never in place of them; the wording is reviewed for how directive it really is; and any step that writes an order or a diagnosis to the record waits for the clinician.

A pre-release clinician test list

The guidance says developers may need usability testing to show criterion 4 is met. Before release, we would run these tasks with the intended clinicians, in a setting close to their real one:

1. Name the inputs. Without help, can the clinician say which values the recommendation used and where each came from?
2. Find the gap. With one expected input removed, does the clinician notice, and does the screen say so?
3. Catch a wrong recommendation. Seed cases where the tool is wrong, as the JAMA study did with its biased model, and record how often clinicians catch them and what they looked at.
4. Spot a population mismatch. Present a patient outside the validated population and check the clinician sees it before deciding.
5. Explain the basis back. Ask the clinician to say, in their own words, why the tool suggested what it did. If they cannot, the basis is not reviewable.
6. Read the wording. Ask whether the recommendation reads as information, advice or an instruction, and compare the answer with the intended use.
7. Override and recover. Decline the recommendation with a reason, then find that decision again in the record.
8. Run at realistic pace. Test with the interruptions and time pressure of the real setting, and note any case where clinicians would act without opening the basis.
9. Check the single state. Where the tool shows one recommendation, confirm clinicians can see what was ruled out and why.

When we design clinician-facing tools, we meet the client's clinical safety and privacy leads first, and medical device classification stays with their clinical safety, privacy and regulatory specialists, as our healthtech expertise page sets out. These tests give those leads evidence from real clinicians, which is what both the FDA's usability language and the research above ask for.