Healix AI, Inc. (Ricardo Hamilton, MD)

See attached file(s)

Formal Public Comment to the United States Food and Drug
Administration (FDA)

Agency: United States Food and Drug Administration (FDA), United States Department of Health and Human
Services (HHS)
Center: Center for Devices and Radiological Health (CDRH), Digital Health Center of Excellence (DHCoE)
Subject: Premarket Considerations, Lifecycle Management, and Predetermined Change Control Plans (PCCPs)
for Generative Artificial Intelligence (GenAI)-Enabled Medical Devices and Clinical Conversational Systems
Date: October 19, 2026
Submitted by: Ricardo Hamilton, Doctor of Medicine (MD) — Founder and Medical Director, Healix AI, Inc.
(HealixAI LLC) | Internal Medicine (California Medical License; Individual National Provider Identifier [NPI]:
1912131558) | 1069 Bent Drive, Campbell, California 95008 | Email: ricardohamiltonmd@healixai.com |
Website Uniform Resource Locator (URL): https://app.healixai.com

1. Clinical Perspective from Practice

I am submitting this comment as a board-certified internal medicine physician in California and as the
founder of Healix AI, Inc. Over the past several years, my team and I have built and deployed real-time
clinical voice software, Electronic Health Record (EHR) integrations using the Substitutable Medical
Applications, Reusable Technologies on Fast Healthcare Interoperability Resources (SMART on FHIR)
standard, and Clinical Decision Support (CDS) tools serving Medicare and Veteran patients. I want to
share a practical perspective from the exam room and the engineering bench on how the Food and Drug
Administration (FDA) and its Center for Devices and Radiological Health (CDRH) can regulate Artificial
Intelligence (AI) and Generative Artificial Intelligence (GenAI) in software that interacts directly with
patients and clinicians, including Software as a Medical Device (SaMD).

Right now, regulators and clinicians face a real tension. Traditional device rules were written for static
code that does not change once cleared. If we apply those static rules to modern neural networks,
developers are forced to choose between two bad options. Either they freeze a medical model in place and
file months of paperwork every time they fix a clinical blind spot, or they avoid the device pathway
altogether and release consumer chatbots with no clinical guardrails. Neither outcome protects patients.

We can solve this problem if FDA guidance focuses on four practical rules: separating conversational
models from hard-coded clinical safety checks, requiring live literature and drug-registry lookups
whenever a tool discusses medical management, using Predetermined Change Control Plans (PCCPs)
under Section 515C of the Federal Food, Drug, and Cosmetic Act (FD&C Act) for routine model updates,
and protecting the statutory safe harbor for physician-supervised Non-Device Clinical Decision Support
(CDS) under Section 520(o)(1)(E) of the FD&C Act.

2. Separating the Conversational Model from Hard-Coded Safety Rules

Large Language Models (LLMs) and Speech-to-Speech (S2S) voice models are remarkably good at
listening to patients, speaking naturally across languages, and picking up subtle context. They are not
reliable enough to handle medical emergencies on their own. Because these models generate responses
based on probabilities, a small change in how a patient phrases a symptom can occasionally change the
model's output.

For that reason, FDA guidance should draw a firm line between the conversational interface and the acute
triage logic. Any conversational medical system should be required to run an independent, rule-based
software safety layer—essentially a deterministic sidecar—outside the neural network itself.

When a patient describes an acute red flag, such as crushing chest pressure, sudden shortness of breath,
one-sided leg swelling, signs of sepsis, or thoughts of self-harm, the neural network should not get a vote
on how to handle the escalation. A hard-coded software rule should step in immediately to connect
emergency 911 services or page the covering physician. In our own production system at HealixAI, this
deterministic safety gate runs in under 15 milliseconds (ms) before the conversational model can soften,
delay, or misread an emergency. Premarket review should test whether these hard-coded clinical safety
rules hold up every time, regardless of how a user phrases the input.

3. When to Allow Conversational Fluency and When to Require Live Evidence
Grounding

One of the hardest problems in conversational medical software is preventing a model from sounding
confident while stating a wrong drug dose or an outdated clinical threshold. At the same time, forcing a
live voice system to search a medical database before saying "Good morning, how has your breathing
been today?" would add awkward delays without making the patient any safer.

The most workable solution is a two-tier standard for how conversational software uses memory. For
everyday conversation—greeting a patient, asking follow-up questions, translating between languages, or
scheduling an appointment—a system should be allowed to rely on its trained language weights. That
keeps live voice conversations natural and responsive, well under 500 ms.

The moment the software moves from conversation into clinical substance, however, the rules should
change. A language model should never guess a drug dose, a renal cutoff, or a diagnostic criterion from
memory. Whenever software provides disease management information, risk stratification, or CDS, FDA
guidance should require live Retrieval-Augmented Generation (RAG) tied to published specialty
guidelines—such as those from the American College of Cardiology and American Heart Association
(ACC/AHA), the American Diabetes Association (ADA), Kidney Disease: Improving Global Outcomes
(KDIGO), the American Academy of Orthopaedic Surgeons (AAOS), and the United States Preventive
Services Task Force (USPSTF)—or peer-reviewed studies indexed in the National Library of Medicine
(NLM) PubMed and PubMed Central (PMC) databases.

The same strict rule should apply to medications. Any mention of a prescription drug, dosing adjustment,
boxed warning, or drug-drug interaction (DDI) should be checked against federal drug registries,
including NLM DailyMed, the FDA National Drug Code (NDC) Directory, and NLM RxNorm, alongside
established geriatric safety rules such as the American Geriatrics Society (AGS) Beers Criteria. Requiring
exact guideline citations and registry identifiers also serves a second purpose: it satisfies Criterion 4 of
Section 520(o)(1)(E) of the FD&C Act by giving the supervising physician the exact source material
needed to independently verify the software's reasoning.
4. Making Predetermined Change Control Plans (PCCPs) Work in Practice

Under older CDRH procedures, updating model weights or refining clinical prompts often triggers a new
Premarket Notification (510(k)) or Premarket Approval (PMA) supplement. In practice, that delay
discourages engineers from patching known edge cases quickly.

The Predetermined Change Control Plan (PCCP) pathway under Section 515C of the FD&C Act gives the
FDA the right tool to fix this. To make PCCPs usable for smaller clinical software teams as well as large
manufacturers, the Agency should lay out clear, objective rules for post-market updates. Specifically, if a
developer updates model weights or incorporates Reinforcement Learning from Clinical Feedback
(RLCF) based on verified physician corrections, they should be allowed to deploy that update under an
approved PCCP as long as it passes a standardized clinical benchmark without regression and maintains
an automatic rollback switch if real-world performance drifts.

5. Protecting Physician-Supervised Non-Device Clinical Decision Support (CDS)

Finally, I urge the Agency to keep a clear boundary between autonomous diagnostic devices and
physician-supervised clinical support tools. Across the country, primary care and specialty clinics are
using conversational software between office visits to check in on patients after hospital discharge, log
home blood pressure or blood sugar readings, track standardized patient-reported outcomes (including
symptom changes, daily function, and medication adherence), and flag care gaps for the clinical team.

When software autonomously diagnoses a condition or changes treatment without a doctor's review, it is
rightly regulated as SaMD. By contrast, when software organizes a patient's interval history, checks it
against published guidelines, and delivers a draft Subjective, Objective, Assessment, and Plan (SOAP)
note to a licensed physician for independent review and sign-off—such as during Centers for Medicare &
Medicaid Services (CMS) Chronic Care Management (CCM) or Transitional Care Management (TCM)
workflows—the physician remains the decision-maker. Keeping the Non-Device CDS safe harbor intact
under Section 520(o)(1)(E) of the FD&C Act allows community practices and safety-net clinics to adopt
modern documentation and triage tools without being priced out by device compliance costs meant for
autonomous hardware.

Thank you for the opportunity to share these observations from clinical practice and software
development. My team and I are glad to provide technical demonstrations or de-identified operational
data to CDRH and DHCoE staff as this framework takes shape.

Respectfully submitted,

Ricardo Hamilton, MD
Founder and Medical Director, Healix AI, Inc. / HealixAI LLC
Internal Medicine | Campbell, California
Email: ricardohamiltonmd@healixai.com | Website: https://app.healixai.com