Mostly about building products, healthcare tech, and lessons learned along the way.
Loading articles
FDA's 2026 Clinical Decision Support Guidance Didn't Bless Generative AI | Clint Johnson
FDA's 2026 Clinical Decision Support Guidance Didn't Bless Generative AI
FDA's January 2026 clinical decision support guidance does not create a special lane for generative AI. It widens what you may output. The criterion 4 test from 2022 is unchanged. Can the clinician independently review the basis for the recommendation, so they don't rely primarily on the software? If your system can't prove that, the new permissions don't help you.
The mistake I still see builders make is treating "the clinician can review it" as a UI claim. It's a system property. Review only means something if three things hold. The basis is on screen next to the recommendation. The output can't silently be empty or truncated. The write path can't run without the review.
I build clinician-facing AI: MedScrub, MedHook, eSpiral. The design choice I'd point to in MedScrub is one sentence we put in front of every skill. It tells the model it is:
a clinical research assistant, NOT the treating clinician… State facts plainly and let the physician decide: write 'A1c 8.2% (06/14/2026)', never 'A1c above target.'
"Above target" is a judgment with a hidden threshold. "8.2% on 6/14" is something a physician can check in two seconds. One is a directive. The other is a reviewable fact.
The sentence alone isn't enough. We found the guardrails had been written into the skill configs but weren't enforced on the main write path. A rule that only exists in a JSON file is a slide, not a control. That pushed us to two enforced rails. First, every claim has to cite the chart data it came from. No citation means the UI shows "No citations found — verify" and the EHR write is blocked. Second, nothing goes into the EHR until the physician ticks "I've reviewed this output." That box resets on every run.
What FDA's 2026 clinical decision support guidance changed
FDA issued the updated final guidance on January 6, 2026 and re-issued it on January 29, according to FDA's own town hall transcript. It replaces the September 2022 version and is nonbinding.
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.
I help teams ship AI in production — audits, consulting, custom agents, and eval systems. Start with an AI Audit (from $5k) for an honest read on what to build.
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:
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.
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.
Recommendations to a clinician. CDS aimed at patients or caregivers is a device. Keep the audience an HCP.
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:
functioncanWrite(run: Run): Decision {if(run.output.status !=="complete")// empty, truncated, reasoning-onlyreturnblock("Model output incomplete. Not written.");if(run.claims.some(c => c.citations.length ===0))returnblock("No citations found — verify");if(run.review?.runId !== run.id)// review resets every runreturnblock("Review required");returnallow();}// 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:
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.
