FDA's 2026 Clinical Decision Support Guidance Didn't Bless Generative AI

FDA's 2026 clinical decision support guidance is silent on generative AI. What changed, and how to build LLM CDS clinicians can independently review.

The changes that matter to an engineer:

• Single recommendations. FDA now intends to exercise enforcement discretion when "only one option is clinically appropriate" and the function otherwise meets all four criteria (Ketryx quoting the guidance). That is not "single outputs are fine now." Covington points out that FDA's reading of the statute didn't change, and the guidance never defines how you decide that only one option is clinically appropriate.
• Risk scores. The 2026 revision removed the 2022 language saying a risk score or risk probability disqualifies software from non-device CDS (Ropes & Gray).
• Time-critical and automation bias moved into criterion 4, the independent-review test.
• Generative AI isn't addressed. The announcement was framed around AI, but the guidance text is silent on it, as the 2022 version was, and says nothing about clinician-facing chatbots.

Enforcement discretion is also not clearance, not a safety finding, and not permanent (MedAI Directory).

If anything the test got sharper, because automation bias now sits inside criterion 4.

Is AI clinical decision support a medical device?

FDA judges software by the role its output plays, not by how the output is generated. A rules engine, a regression model and an LLM all get the same lens. So stop asking whether "AI CDS" is a device. Read the four criteria as requirements on your system:

1. No patterns or signals in. FDA treats repeated measurements, such as CGM readings over time, ECG waveforms or VCF variant files, as patterns. Point-in-time vitals from a visit generally aren't (CITI). If you pipe a 14-day glucose trace into the context window, you've changed your regulatory posture with one retrieval decision. Control what the model sees, not just what it says.
2. Medical information only. That means chart data plus well-understood sources such as guidelines, peer-reviewed literature and FDA labeling (National Law Review). My read: a model answering from its own weights, rather than from cited chart data or accepted sources, is hard to square with that.
3. Recommendations to a clinician. CDS aimed at patients or caregivers is a device. Keep the audience an HCP.
4. The clinician can independently review the basis. The rest of this post is about criterion 4.

How to meet FDA's independent review criterion (criterion 4)

FDA recommends that outputs flag missing or unusual inputs and show the patient-specific factors that were used (CITI). That is a UI and data-flow requirement.

In eSpiral, residents didn't believe the assistant was using this patient's chart. I had to explain it out loud. So we added a chip on the chat that says "Using this patient's N conditions, YYYY–YYYY." Now the basis is visible before anyone reads a word of output. It has to be on the screen, not in the architecture diagram.

Citations work the same way. A claim tied to a specific Observation with a date can be reviewed. A claim with no source can't, so the system says so and refuses to write it. If you're relying on the model to "explain itself" instead, interpretability won't save you yet. Grounding every claim in a source will.

Silent LLM failures in clinical decision support

The scariest outputs we saw were plumbing failures, not hallucinated diagnoses.

• A provider returned an empty response, and our app rendered "this chart doesn't have enough data" for a full chart. That's a false clinical statement, not a missing one.
• Answers cut off by the token limit got pasted into the EHR looking complete.
• A local model silently truncated prompts to the last 4,096 tokens. The problem list and allergies were gone, and the output was confident and wrong.
• eClinicalWorks once returned success on a write that had failed. We showed "Written to eClinicalWorks" when nothing was written.

A clinician can't check the basis of an output that silently lost its inputs. We fixed the flow, not the prompt. Every provider path now treats empty, truncated or reasoning-only output as an error the clinician sees, and write receipts come from what the EHR actually confirms. The shape of the gate:

function canWrite(run: Run): Decision {
  if (run.output.status !== "complete")      // empty, truncated, reasoning-only
    return block("Model output incomplete. Not written.");
  if (run.claims.some(c => c.citations.length === 0))
    return block("No citations found — verify");
  if (run.review?.runId !== run.id)          // review resets every run
    return block("Review required");
  return allow();
}
// Show "Written" only when the EHR confirms the write.

Three checks, all on the write path. The review check deserves the most care. A checkbox that stays checked across runs is automation bias you designed in: the clinician reviewed yesterday's output, and today's goes through on the same tick. Tie each approval to a run ID, reset it on every regeneration, and make it a precondition of the write, not a suggestion in the UI. I wrote more about why silent failures are worse than loud ones.

Are time-critical AI alerts a medical device?

FDA says software for critical, time-sensitive decisions generally fails criterion 4, because clinicians don't have time to review the basis. Its device examples include stroke and sepsis alarms, and outputs that direct immediate intervention (CITI). The guidance doesn't define "time-critical."

My rule: if the feature only works when the clinician acts before they could reasonably check the sources, it's not non-device CDS. Put LLM output where there is time to read it, such as chart prep, note review and research. Don't put it in an interruptive alert in an urgent workflow. Pick that boundary in the product spec, not after launch.

Confidence scores and risk scores after 2026

This is where I reversed myself. At first I refused to build confidence scores, because LLM self-confidence isn't calibrated. Two weeks later we built them anyway, because clinicians wanted a signal. The same write-path discovery pushed this one. They're labeled "model self-assessment, not a calibrated probability." If the model doesn't give one, the UI shows "unknown," never a made-up number.

The 2026 guidance dropped the language that disqualified risk scores. That doesn't make an uncalibrated number honest. A labeled self-assessment is something a clinician can weigh. A bare "87%" invites them to rely on it, which is the opposite of what criterion 4 asks for. If you want a real probability, you need real validation. Calibrate against labeled data before you show one.

CDS Hooks cards and audit logs that show the software's role

If you deliver through CDS Hooks, the card format already gives you most of what criterion 4 needs. In the 2.0 spec, a card carries a short summary, an indicator and a source. Use them to state facts, cite sources and say what the software is:

{
  "summary": "3 chart findings relevant to diabetes follow-up",
  "indicator": "info",
  "source": { "label": "AI-drafted summary. Clinician review required." },
  "detail": "- A1c 8.2% (06/14/2026) [Observation/a1c-0614]\n- Self-assessment: unknown",
  "links": [{ "label": "View cited chart data", "url": "https://app.example.com/runs/123", "type": "absolute" }]
}

The spec also defines a feedback endpoint that reports whether each card was accepted or overridden, with a timestamp. Wire it up. Then log what your side knows: the inputs actually sent (after any truncation), model and prompt version, every claim with its citations, the reviewer and run ID, and the EHR's confirmation. That record shows the software drafted, the clinician decided, and the write happened only after review. If someone asks what role your software played, answer with that log, not a diagram.

The generative AI question is still open

On August 18, 2026, CDRH released a discussion paper on generative AI-enabled medical devices. It doesn't propose a separate evidence standard for generative AI, and it asks whether agentic systems need extra oversight. Comments are due October 19, 2026 under docket FDA-2026-N-7874. If you ship LLM features to clinicians, read it and comment. The people writing these rules need to hear from engineers who have watched a "success" response hide a failed write.