First FDA-Cleared AI Agent and LLM Enabled Device Confirmed

 June 25, 2026
SHARE ON

AI/MLNewsRegulatorySoftware

UpDoc chronology: clinical study lineage, public LLM claims, patents, FDA clearance, device listing, funding, and launch framing.

On June 25, 2026, UpDoc announced what it framed as the first FDA-cleared clinical AI platform built for real-time patient care delivery and intelligent care coordination. The company's release said the product uses patient-facing large language models, has $18 million in seed financing to date, and is entering initial deployments at major health systems.

FDA's public 510(k) database shows that K253281 cleared on December 23, 2025. AccessGUDID identifies the device as UpDoc V1.0, a prescription software medical device for insulin management in adults with type 2 diabetes. In other words, the public FDA record points first to a bounded insulin-management SaMD, not a general-purpose AI doctor.

It is not yet clear if this press release is talking about the same device or a new one. It is possible the K253281 is the same device that is subject of the press release. It is also possible a new 510(k) was cleared that adds new LLM functionality.

The important story is not that FDA cleared an autonomous LLM physician. It is that FDA appears comfortable with a protocolized clinical workflow that uses AI conversation around a deterministic core. UpDoc may feel agentic to patients because it can converse, gather structured health information, coordinate follow-up, and deliver physician-governed interventions between visits. But the strongest public evidence still points to clinical decisions operating inside healthcare-provider-set limits, with the LLM layer wrapped around a narrower regulated function. This is likely the reason FDA allowed this technological jump as a 510(k) rather than a De Novo. This is a pretty narrow and well-risk-controlled use case as far as agentic AI goes.

The Chronology 🔗

The UpDoc story appears to have built in layers: a Stanford clinical study, public LLM claims, patents describing conversational medication workflows, FDA clearance, device listing, financing, and then a broader agentic-AI launch.

The clinical root is MIVA, a Stanford randomized trial registered as NCT05081011. ClinicalTrials.gov lists the study start as March 24, 2021, completion as December 1, 2022, and results first posted on January 2, 2024. The related JAMA Network Open paper is dated December 1, 2023 and studied voice-based conversational AI for basal insulin prescription management.

UpDoc then went public in January 2024. Its launch release described a clinician-directed conversational AI platform for medication prescriptions and chronic disease. Healthcare IT News reported that the technology used multiple LLMs, including GPT-4 through Azure OpenAI, Google Cloud MedLM, and Vertex AI models. That was the first public jump from voice-based insulin titration research to an LLM-enabled remote patient intervention company narrative.

The patent record adds the workflow layer. US12251242B1, published March 18, 2025, describes a voice-based system for type 2 diabetes management in which practitioner inputs configure clinical algorithms and conversational prompts. WO2025090951A1, published May 1, 2025, and US20250331781A1, published October 30, 2025, broaden the medication-management framing. US12470655B1, published November 11, 2025, describes telephone voice data driving an application protocol. These patents do not prove the exact cleared product implementation, but they match the working read: conversation and structured capture around protocolized action.

FDA received K253281 on September 29, 2025 and cleared it on December 23, 2025. GUDID then shows an UpDoc record published January 13, 2026, with commercial distribution status listed and device identifier 00860015223906.

The commercial rollout became public in June 2026. On June 2, the American Diabetes Association announced a strategic investment in UpDoc. On June 25, UpDoc announced FDA clearance, $18 million in seed financing to date, EHR integration, and initial deployments, naming Cleveland Clinic, Allegheny Health Network, and UCSF Health. The accessible WSJ preview described the product as AI that can interact with patients and adjust medication doses within clinician-set parameters. That aligns with the core timeline rather than changing it.

What FDA Actually Cleared 🔗

FDA cleared UpDoc under K253281 on December 23, 2025. The public FDA record supports a narrower claim than the launch language around a broad clinical AI platform: UpDoc is a prescription SaMD for medication management in adults 18 and older with type 2 diabetes, centered on insulin treatment plan instructions.

The regulatory classification is specific but has one caveat. FDA's 510(k), openFDA, and product-code records list product code NDC, device name "calculator, drug dose," regulation number 21 CFR 868.1890, Class II, and a substantially equivalent decision. FDA's current product-code page calls NDC a drug-dose calculator, while the eCFR title attached to 868.1890 is "Predictive pulmonary-function value calculator." The safest phrasing is therefore: FDA product code NDC / drug-dose calculator, mapped in FDA databases to 21 CFR 868.1890.

The predicate was Hygieia's d-Nav System (K181916). That predicate calculated the next insulin dose for adults with type 2 diabetes and used HCP-prescribed insulin instructions plus glucose data to recommend dosing. UpDoc's 510(k) summary says the two devices share the same intended use: software systems that determine the next insulin dose recommendation to aid insulin management.

The intended-use language keeps the clinical boundary tight. UpDoc provides patients with insulin treatment plan instructions based on an HCP-specified treatment plan. Patients can log blood glucose, meals, symptoms, and adherence manually, through voice or text, or via connected glucose data. Providers configure the patient-specific treatment plan, including insulin type, starting and maximum doses, adjustment algorithm, glucose targets, and safety protocols. FDA's review repeats the key control point: insulin instructions are computed in the cloud-based application from healthcare-provider-defined treatment parameters.

Performance evidence also supports a software-boundary story. The 510(k) summary says UpDoc relied on non-clinical testing: software testing under IEC 62304 and FDA software guidance, cybersecurity testing, and human factors testing. It then states that no clinical testing was performed. The PCCP is the strongest change-control evidence: FDA's decision summary says authorized changes must maintain deterministic insulin dosing logic and cannot alter core clinical decision-making.

How The Agent Probably Works 🔗

The public evidence points to an LLM/conversational layer handing structured facts to provider-configured clinical decision support.

The best public reading of UpDoc is not "LLM doctor." It is conversation on the outside, structured data in the middle, and protocolized clinical decision support on the inside.

The FDA decision summary names a patient mobile app, a provider web portal, and a cloud-based application made of a Conversation Service (UpDoc Agent) and a Clinical Service. The same document says healthcare providers configure dosing instructions, algorithms, glucose targets, and safety protocols, and that insulin instructions are computed based on provider-defined treatment parameters.

The patent evidence points in the same direction. US12251242B1 describes configuring a large language model with agenda prompts, intents, and slot values. But its medication-initiation and titration examples put the dose logic in a clinical algorithm: patient voice interactions collect glucose and medication logs, then the algorithm evaluates thresholds, adherence, hypoglycemia events, and dose changes before driving the conversational agent to speak the result. Broader medication-management patents add structured health information, diagnostic frameworks, rules engines, and application protocols.

A likely dataflow looks like this:

patient voice/text/device data
  -> ASR/NLU/LLM conversation layer
  -> intents, slots, structured health facts, confirmations
  -> schema and safety checks
  -> provider-configured clinical service / insulin protocol
  -> bounded action: titrate, hold, remind, escalate, document
  -> conversational output / app UI / provider portal

This can still be agentic in the product sense. The system may monitor, ask follow-up questions, coordinate workflows, prepare documentation, and pull data from fixed integrations such as glucometers, CGMs, EHR/EMR systems, provider databases, speech services, and, in patent claims, pharmacy or other workflow APIs. But the evidence supports fixed tools and services, not an LLM freely choosing arbitrary tools, browsing, diagnosing, and replanning treatment strategy.

The safety problem changes accordingly. If the clinical engine is deterministic, the highest-risk LLM boundary is not "Will the model invent an insulin dose?" It is "Will the model extract and route the right facts?" A misunderstood meal, missed hypoglycemia symptom, wrong unit, incorrect adherence value, or overconfident free-text summary can corrupt a downstream deterministic engine. The engineering burden shifts toward confirmation flows, schema validation, unit normalization, audit trails, exception handling, and escalation when patient input is ambiguous or outside protocol.

The LLM Questions FDA Does Not Answer Publicly 🔗

The public 2024 reporting said UpDoc used multiple LLM providers, including GPT-4 through Azure OpenAI, Google Cloud MedLM, and Vertex AI. The FDA public record, however, does not identify a foundation model, prompt stack, temperature, top-p, model version, runtime orchestration pattern, validation harness, or prompt/configuration management system.

Those unknowns are central for the next wave of clinical AI teams. Are prompts, policies, schemas, and model versions controlled as software configuration items? Are temperature, top-p, and tool-calling settings fixed and validated? Does deterministic application code mediate every clinical action, or can the LLM invoke fixed tools directly? How are model, prompt, integration, and schema changes handled under QMS and PCCP/change-control records?

This is the article's credibility point: the LLM story is real, but the public evidence leaves the regulated decision boundary in traditional software.

Not An Autonomous AI Physician 🔗

UpDoc is important partly because it does not look like the sci-fi version of an autonomous AI physician. In the broadest version of "agentic AI physician," the system would interpret an open-ended clinical goal, gather context, reason diagnostically, choose tools, decide treatment strategy, monitor results, and replan over time. That is the regulatory cliff edge.

An UpDoc-like workflow appears to make a smaller and more practical claim. The clinician defines the treatment plan and parameters. The system asks questions, gathers glucose and symptom information, structures the data, runs bounded insulin-management logic, and then communicates the result or escalates when the case leaves the protocol. The agentic feel comes from continuity: the software can keep checking in, responding, reminding, and coordinating between visits. The clinical authority appears to sit behind the structured-data boundary.

That is still commercially meaningful. UpDoc may become one of the clearest early public examples of an FDA-cleared, patient-facing AI-agent-style clinical workflow. That can create credibility with health systems, investors, and strategic partners. But it should not be described as permanent exclusivity or proof that FDA has cleared autonomous LLM physicians. Other teams with a narrow intended use, a suitable predicate, disciplined QMS, and strong verification package may be able to pursue similar 510(k) strategies.

The first-mover window may therefore be real but fragile. The defensible advantage is not "we have an LLM." It is workflow depth, clinical evidence, integration into provider operations, validated safety boundaries, and the ability to update the product without breaking the cleared decision architecture.

Product Code / Special Controls Analysis 🔗

UpDoc’s clearance sits in a practical but slightly awkward FDA bucket: product code NDC, “calculator, drug dose,” classified under 21 CFR 868.1890, “Predictive pulmonary-function value calculator.” FDA’s public K253281 page lists the device classification name as “Calculator, Drug Dose,” product code NDC, regulation number 868.1890, Class II, and notes that a PCCP was authorized. The FDA product-code page for NDC likewise identifies the device as a drug-dose calculator, reviewed through 510(k), with premarket review in OHT7/DCTD.

The important regulatory point is that 868.1890 is not a modern AI-specific classification regulation. The eCFR text is sparse: it identifies the device type as a calculator used to calculate values from empirical equations and classifies it as Class II “performance standards.” It does not enumerate a detailed list of special controls like many newer De Novo-created regulations do.

That makes the classification useful for LLM products only in a bounded way. The apparent regulatory pattern is not “FDA cleared an LLM to practice medicine.” It is closer to: FDA cleared a drug-dose calculator / medication-management SaMD where voice or text interaction can collect inputs, but the clinical action is constrained by provider-defined treatment parameters and validated software logic. In the K253281 review summary, UpDoc’s patient app logs blood glucose, meal, symptom, and adherence data, including voice/text interactions; the provider portal configures patient-specific insulin plans; and insulin instructions are computed in the cloud based on healthcare-provider-defined treatment parameters.

The broader product-code lesson is that 868.1890 already contains several calculator-style software product codes beyond classic pulmonary-function calculators. FDA’s product classification database shows NDC for drug-dose calculators, PHY for sparse-sample PK profile and dosing software, and PDT for burn-resuscitation decision-support software under the same regulation family. That suggests the category can accommodate software that calculates treatment-relevant outputs from structured inputs, especially where the output is bounded by an algorithm, protocol, model, or clinician-configured plan.

For LLM-enabled products, the best-fit archetypes would be:

  • Medication dose calculators where the LLM captures patient-reported data, asks clarification questions, and formats the answer, while dosing math remains validated code.
  • PK / precision-dosing tools where the LLM helps collect context or explain recommendations, but the PK model and dosing calculation remain locked and testable.
  • Protocolized titration tools where the LLM routes symptoms or adherence facts into predefined rules.
  • Care-plan adherence agents where the LLM supports reminders, logging, education, and escalation, but does not independently choose therapy.

The weaker-fit or higher-risk archetypes are different: open-ended diagnosis, autonomous therapy selection, triage without fixed escalation criteria, or an agent that can revise the clinical algorithm at runtime. Those would likely raise different safety questions and may need a different product code, more clinical evidence, or a De Novo-style control

The Builder Playbook 🔗

For teams commercializing AI-agent medical-device workflows, the lesson is practical:

  • Unless you would like to go down a De Novo path, stick to a structured procedural core surrounded by an agentic conversational shell.
  • Pick one narrow regulated function before designing the agent.
  • Identify the predicate, classification, and special controls early.
  • Keep LLM outputs away from final clinical decision authority unless you can validate and control that role.
  • Convert free-form conversation into structured fields with schema checks, confirmations, and audit logs.
  • Put deterministic clinical logic behind the structured-data boundary.
  • Define escalation, lock-out, contraindication, and "insufficient information" paths.
  • Treat prompts, models, tools, thresholds, and policies as controlled software artifacts.
  • Build PCCP and change-control strategy before launch, not after scale.
  • Validate extraction, human factors, cybersecurity, and workflow safety with evidence matched to the intended use.

For prepared teams, the timeline may be measured in months rather than years after the evidence package is ready; FDA clearance timing is never guaranteed. The market advantage UpDoc gets from being early is real, but probably not permanent.

The close is not that FDA is ready for a robot physician. It is better than that for near-term builders: FDA may be willing to clear patient-facing AI workflows when the messy language layer is separated from the clinical decision engine, the intended use is narrow, and the safety case is engineered like software rather than promised like magic.

FDA Evidence Panel 🔗

Below are some relevant excerpts from the 510(k) summaries that will be helpful for those that are looking to submit a FDA application in the agentic AI space.

Highlighted screenshots:

K253281 summary p.4: intended use and healthcare-provider-defined treatment parameters.

K253281 summary p.4: intended use / HCP-defined treatment parameters.

K253281 summary p.6: FDA public summary names the Conversation Service (UpDoc Agent) and Clinical Service.

K253281 summary p.6: Conversation Service (UpDoc Agent) and Clinical Service.

K181916 predicate summary p.3: d-Nav provides the next insulin-dose recommendation for adults with type 2 diabetes.

K181916 predicate summary p.3: d-Nav provides the next insulin-dose recommendation for adults with type 2 diabetes.

K253281 summary p.15: non-clinical testing, no clinical testing, and bounded PCCP change categories.

K253281 summary p.15: no clinical testing and bounded PCCP categories.

K253281 decision summary p.6: PCCP changes must preserve deterministic insulin dosing logic and core clinical decision-making.

K253281 decision summary p.6: deterministic insulin dosing logic, exact data handling, and auditability.

Sources 🔗

SHARE ON

The first-mover window on agentic AI devices is still open.

Innolitics builds and clears medical imaging, AI/ML, and SaMD products end to end from algorithm R&D through 510(k) clearance and beyond. We help you scope the intended use, pick the predicate, and get you past the FDA hurdle all under one roof.

Recent case study

We Delivered an AI Regulatory Strategy On Time and On Budget

FDA regulatory strategy and Pre-Submission for an AI platform converting 2D MRI to 3D joint models. Delivered on time and budget

OrthoVentions logo

We Mapped the Fastest Path to FDA Clearance for AI/ML SaMD

Existing EU data. Strategy designed to get to U.S. market with minimal extra effort.

AUMI ai logo

We Architected Neosoma's Fast Lane to FDA: A Modular Strategy Built for Rapid Repeat Clearances

We isolated Neosoma's new CNN for FDA review, won clearance in 3 months, and built a framework for every product after.

Neosoma logo

We Secured a Breakthrough Device Designation for a ECG Foundation Model

Reframed regulatory strategy after FDA pushback. BDD granted in ~3 months.

Trusted by

  • nvidia
  • Enlitic
  • OXOS
  • NSI
  • Butterfly Network
  • Transonic
  • AI Metrics
  • RadUnity
  • Prenuvo
  • Echo IQ
  • Envisionit
  • Smile Dx
  • Indica Labs
  • Magnetic Insight
  • Neosoma
  • BodyCheck
  • University of Alabama
  • Mary Bird Perkins
  • PhotoniCare

Our FDA Clearances

Let's Talk

Every great partnership starts with a conversation. Fill out the form below for a discovery call, and an Innolitics team member will contact you soon.