Clara Health (Niraj Patel)

I’m submitting a revised version of Clara Health’s comments on Docket FDA-2026-N-7874. This updates our October 8, 2026 submission, tracking number mv0-27zm-wo6t. Please treat the attached revised document as our complete comment and use it in place of the earlier attachment.

Thank you for the opportunity to contribute.
Niraj Patel, DO, MBA
Medical Director, Clara Health

Comments for Clara Health on the FDA’s
Considerations for the Regulation of Generative
AI-Enabled Medical Devices: Discussion Paper and
Request for Feedback
Docket No. FDA-2026-N-7874

Introduction
For a paying passenger in San Francisco, a Waymo ride once required a safety driver in the
vehicle. In August 2023, California authorized the company to charge for rides without one. A
responsibility that had required a person behind the wheel could now be carried out by the
system within the limits of its authorization (California Public Utilities Commission).

That transition involved much more than making the car better at driving. California established
separate permissions for testing with a safety driver, testing without one, and deployment.
Commercial passenger service required additional authorization and a passenger safety plan.
There was a way to move forward, with specific requirements at each stage (California DMV).
Alongside those regulatory requirements, Waymo developed its own process for deciding
whether the system was ready for particular operating conditions and for reassessing it when
the software, vehicle, or environment changed (Waymo).

We believe healthcare is approaching a similar transition in responsibility. Over the next
four to five years, we expect AI to perform a substantial share of defined clinical tasks
with greater independence. Some of those tasks may be performed more reliably than
they are in routine practice today. The implications extend well beyond producing a
better answer to a medical question.

For a patient managing several long-term conditions, care could continue between
appointments without depending on that patient to initiate every interaction. With the patient’s
permission, a system could review a new result against years of records, recognize an overdue
safety check, and ask the questions needed to determine the next step. The system could
complete routine work within its approved scope. A change that required a clinician’s judgment
would reach that clinician with the relevant history already assembled. The service would then
check whether the patient received the recommended care.
For a daughter helping her mother manage several medications, that could mean fewer
evenings spent calling offices, comparing instructions, and trying to determine who is
supposed to act next. Her mother’s care team would already be following the issue.

We believe the level of attention now associated with a well-staffed concierge practice could
become affordable to far more families. That is the scale of the opportunity we want this
framework to accommodate.

At Clara Health, we are developing and evaluating AI within clinician-led longitudinal primary
care with that future in mind. Our current approach keeps licensed clinicians responsible for
clinical decisions. Our work focuses on the details that determine whether that care can be
provided safely: whether the system received the right information, whether it recognizes
when a case has become more serious, and whether its recommendation leads to an
appropriate handoff. A system that performs a routine task well but fails to recognize the
patient who does not belong in that routine pathway is not ready to act independently.

That is also where the comparison with driving has limits. A patient can disclose one new
symptom that changes the entire clinical picture. The boundaries are harder to recognize than
the edge of a service area. Demonstrating that a system can recognize those boundaries is
essential, but it does not follow that every function should permanently require the same level
of supervision.

While these questions are being worked out, patients are already making their own decisions
about using AI. West Health-Gallup research found that some people use it because they
cannot access or afford a clinician, and some report deciding against a healthcare visit after
receiving AI-generated information or advice (Raynes and Maese). The survey does not
establish whether those decisions were medically appropriate, but it does show that these
tools are influencing care-seeking outside clinical encounters.

We are concerned that a slow or unclear route for clinically evaluated systems will leave more
of this use outside services that can review recommendations and take responsibility for
follow-up. The cost of delay therefore deserves consideration alongside the risks of
deployment. A patient who cannot obtain care has an immediate problem; uncertainty about
the regulatory framework does not remove it.

The FDA’s discussion paper already recognizes different levels of independence and proposes
evaluating the deployed device through benchmarking and clinical confirmation. We want to
help make the next steps clear for clinical teams: what a function must demonstrate before
supervised use, what additional evidence would support less review, and when performance
requires greater supervision or suspension.
 Developers should have to establish that a function is ready for the responsibility they are
requesting. They should also be able to see a clear route from that evidence to permitted
clinical use. The answers that follow describe how we believe that route can work.

Scope of this comment
For readability, we use “developer” for the party the discussion paper generally refers to as the
“sponsor.” The questions below are reproduced from the FDA’s discussion paper. This
comment does not seek a determination concerning the regulatory status of any particular
current Clara function.

We also ask the FDA to clarify how its framework applies when AI is used within a clinician-led
medical group. Worked examples should distinguish functions subject to device oversight from
those that meet existing software exclusions, and explain how federal requirements interact
with state oversight of clinical practice. Clinician involvement alone does not determine device
status. Its effect on risk should depend on whether the review and follow-up arrangements
actually prevent harm.

Overview of Clara’s Comments

Section Questions​ Central recommendation
addressed

Assessment of risk 1, 2, 3, 5, 6 Keep the framework usable while accounting for
clinical context, effective safeguards,
conversational behavior, and both directions of
escalation error.

Competency-based evaluation 7, 9, 10, 11, 14, 15 Evaluate defined clinical functions and the
complete deployed workflow. Distinguish clinical
appropriateness from improvement over the
care patients would otherwise receive.

Postmarket monitoring and change 18, 19, 22, 24 Use ongoing evidence to detect deterioration
control and determine when responsibilities can change.
Distinguish changes requiring internal testing
from those requiring FDA notification or review.

Agentic AI 26 Test complete action sequences. Allow greater
independence only where the function’s
reliability, boundaries, and safeguards have been
demonstrated.
I. Assessment of risk
Question 1:

Does the two-axis risk framework, organized around device activity and the
consequence of relying on an incorrect output, appropriately capture the dimensions
most relevant to the risk of a GenAI-enabled software function? If there are additional
dimensions—such as the reversibility of a resulting action, the availability of
downstream safeguards, the time pressure of the deployment setting, or the
traceability of the output—that should be represented in a risk framework, please
describe and provide examples of how they should be represented.

Response:

Keep the two primary axes and use a short set of clinical risk modifiers to account for
differences they do not capture.

What a function does and the harm that could follow an incorrect output are fundamental
considerations. But functions with similar activity and consequences may carry different risks
depending on: the information available, the likelihood that an error will be recognized, and the
safeguards that can prevent harm.

We recommend the following modifiers:

Risk modifier What the assessment should establish

Context Whether the system received the information needed for the task,
completeness and where that information came from, whether it is current, and
provenance whether important information is missing or conflicting.

Detectability of Whether the intended user or another safeguard is likely to
error recognize an incorrect output before it affects care.

Reversibility and Whether an action can be corrected and how quickly an error
time to harm could cause harm.

Downstream Whether clinician review, a rule-based check, or another control
safeguards can reliably prevent the error from reaching the patient.

Clinical ambiguity How much uncertainty remains and whether there is time to
and time pressure gather more information or obtain additional review.
These modifiers should guide the evidence and safeguards required for a function. A safeguard
should not reduce the assessed risk merely because it exists on a workflow diagram. Its
effectiveness should be demonstrated under expected conditions of use.

A medication question illustrates why clinical context matters. A system may have the medical
knowledge needed to answer a medication question but still fail because it received an
outdated medication list or did not receive a relevant laboratory result.

We find it useful to distinguish context delivery failure, where necessary information was not
supplied; context reasoning failure, where available information was interpreted incorrectly;
context communication failure, where the conclusion was appropriate but the recipient
misunderstood it; and context workflow failure, where the expected action or follow-up did not
occur.

These categories can overlap. They help identify what needs correcting instead of treating
every failure as a model error. Developers should document the information each function
requires, how it is obtained, and what happens when it is unavailable or unreliable.

Question 2:

CDRH seeks input on how to account for the spectrum of GenAI-enabled informational
functions that vary in the degree to which they direct a user to a particular action—that
is, between “non-directive” and “action-directing.” What characteristics of an
output—such as its wording, specificity, personalization, or context—could be
considered as modifiers of the risk associated with an informational function, after
accounting for the device’s overall functionality and intended use? What additional
information would provide manufacturers with sufficient clarity and predictability
around risk assessment for informational functions while recognizing that directiveness
may exist along a continuum rather than as a binary distinction?

Response:
​
Assess directiveness by the action a reasonable user would understand the output to
recommend, rather than by particular words.

A personalized instruction does not become general education because it includes “consider,”
“may,” or “talk to your doctor.” The assessment should examine the substance of the
recommendation and the conversation in which it appears.
Specificity, personalization, immediacy, and strength of endorsement are useful indicators. An
output naming a drug and dose for this patient carries different implications from general
information about treatment options. A timeframe or clear preference for one option can
further increase its directiveness.

The clinical consequence and downstream effect should then inform the associated risk. An
output that explains an option differs from one that initiates an order or another clinical
workflow.

The accumulated conversation also matters. After discussing a patient’s symptoms,
medications, and laboratory results, an otherwise general-looking statement may reasonably
be understood as advice for that individual.

For predictability, we recommend worked examples along the continuum the FDA describes:

General information → contextualized information → individualized recommendation →
individualized instruction.

Executing the instruction should be assessed as an additional action-taking capability.

Developers should state the highest level of direction their function is designed to provide and
demonstrate that it stays within that limit across realistic conversations. Worked examples
would give developers a clear target and discourage wording changes that leave the actual
advice unchanged.

Question 3:

CDRH seeks input on whether and when a GenAI-enabled function that results in
delivery of clinical information to patients, as opposed to HCPs, could present different
or higher risks, while also recognizing the potential benefits associated with improved
patient empowerment, engagement, and access to clinical information. What device
characteristics, output features, or safeguards might mitigate risks that could arise
when a user lacks the domain knowledge to independently evaluate an output, without
unnecessarily underestimating patient capability?
Response:

Patient-facing delivery should affect the risk assessment, but it should not determine the risk
category by itself.
The FDA appropriately recognizes both the possibility that patients may have difficulty
identifying an incorrect clinical output and the benefits of improved access to understandable
clinical information.

The assessment should consider the consequence of the information, how personalized and
directive it is, whether important inputs have been confirmed, and whether the patient is
expected to act before clinician review. It should also establish how uncertainty is
communicated and whether human help is available when needed.

We recommend safeguards that patients can actually recognize and use.

Confirm the facts that determine the recommendation. Medication identity, dose, timing, and
other safety-critical information should be confirmed when they materially affect the next step.

Make the action and urgency understandable. Patients should know what is recommended,
why, what remains uncertain, and when to act. “Follow up” is insufficient when timing matters.

Make review status clear. The interface should distinguish general education, an AI-generated
recommendation awaiting review, and guidance reviewed by a clinician.

Provide a working route to human care. When a request exceeds the system’s scope, the
response should identify the next step and initiate a handoff where the service provides one.
For consequential recommendations, the workflow should support confirmation of receipt,
understanding, and follow-through when feasible, without delaying urgent care.

An uncompleted recommendation should prompt investigation, but it should not automatically
be classified as an AI defect. The cause may be unclear instructions, a failed handoff, an access
barrier, or an informed patient decision.

Disclaimers cannot substitute for these safeguards. The assessment should establish whether
the intended user can understand the recommendation, recognize its limits, and obtain care
when needed.

Question 5:

For multi-turn conversational GenAI-enabled devices that may migrate from providing
“non-directive” information to “action-directing” information over the course of an
exchange, how should risk be assessed across realistic conversational trajectories? How
 could the intended use of such a device be characterized when its behavior is emergent
across a conversation?

Response:

Evaluate the full clinical conversation, including how recommendations change as new
information emerges.

A conversation can begin with a routine concern and later reveal information that changes the
clinical picture. The system must recognize that change, reconsider its earlier conclusion, and
adjust the next step.

Evaluation should include conversations in which information is incomplete, disclosed gradually,
contradicted, corrected, or described in different ways. It should test whether the system asks
necessary questions, reconciles conflicting statements, avoids settling too early on a benign
explanation, and incorporates relevant earlier information.

Testing should also examine whether the system maintains an appropriate escalation when the
patient minimizes symptoms or resists care. A recommendation should change when the
clinical facts change—not merely because the user repeatedly requests reassurance.

Longer conversations should test whether the system remains within scope, responds
consistently to equivalent wording, and completes an appropriate handoff. Where applicable,
testing should also assess whether important new information reaches the longitudinal record.

Open-ended conversation does not make intended use impossible to define. Developers
should specify the clinical functions permitted during the encounter, the information the
system may use, the maximum level of recommendation or action it may provide, the
circumstances requiring clinician review, and the permitted outcomes of the conversation.

Those boundaries remain testable even when the exact wording cannot be predicted.

Question 6:

For GenAI-enabled care escalation functions, CDRH is considering how the evaluation
may account for both under-escalation and over-escalation. How could manufacturers
characterize and weigh these two directions of error, given that they may not be
commensurable and that acceptable trade-offs may vary by clinical context?
Response:

Under-escalation and over-escalation should be reported separately. A single accuracy score
can hide clinically important differences between these errors.

Under-escalation is particularly concerning when it delays treatment for a serious or
time-sensitive condition. Evaluation should characterize the missed condition, the appropriate
urgency, the delay introduced, whether another safeguard could detect the error, and whether
the patient had another realistic opportunity to seek care.

We recommend separating the error itself from the clinical consequence that reasonably could
follow. Actual harm should also be recorded separately. A serious error should not be classified
as minor solely because a clinician happened to catch it, but the effectiveness of that
safeguard should still be recognized.

Over-escalation should be characterized by the difference between the recommended and
appropriate level of care, its frequency, and the resulting testing, treatment, and burden.
Repeated unnecessary warnings may also weaken trust in future appropriate warnings—a
concern recognized in the FDA’s discussion paper.

Developers should define the acceptable trade-off before testing. The plan should identify
safety-critical under-escalation, acceptable precautionary escalation for that context, how
error severity is assessed, and what findings require correction or increased supervision.

The assessment should include timing and handoff quality. A correct recommendation
delivered only after an avoidable delay may still be unsafe. Where the service provides a
handoff, the developer should assess whether the patient and receiving clinician received the
necessary information.

Competent escalation requires recognizing patients who need more urgent care without
routinely sending lower-risk patients to an unnecessarily intensive setting. The
acceptable balance should be justified for the clinical situation being evaluated.
II. Competency-based evaluation
Question 7:

Is the competency-based approach described above—that is, device benchmarking
followed by clinical confirmation—a useful and appropriate framework for evaluating
GenAI-enabled devices?

Response:

Yes, provided the competency is defined specifically enough to test and the evaluation covers
the deployed workflow as well as its individual functions.

We support the FDA’s recognition that exhaustive input-output testing is not a practical basis
for evaluating open-ended clinical systems. Its proposed combination of benchmarking and
clinical confirmation addresses different kinds of uncertainty.

A broad claim such as “clinical reasoning” is not a sufficiently clear testing target. A more useful
competency would describe recognition and escalation of concerning symptoms in adults
using asynchronous primary care, with specified access to clinical records and defined
clinician-review requirements. For that use, evaluation should establish what reaches the
patient before review, which clinician is responsible for the decision, how quickly review occurs,
and how the service handles a patient who needs immediate care.

The description should establish the function, population, setting, available information,
permitted outputs or actions, level of oversight, and consequences of failure.

Each function should be evaluated according to what it does. The deployed configuration must
also be tested, including the model, instructions, clinical information, retrieval methods, rules,
tools, interface, clinician-review process, and handoff arrangements. Passing separate
component tests does not establish that those components work safely together.

Benchmarking tests expected and difficult situations under controlled, repeatable conditions,
including uncommon but important cases. Clinical confirmation determines whether those
capabilities hold with actual users, incomplete information, and real workflow constraints.
Together, these methods can establish whether a function is ready for its proposed level of
supervision. A change in responsibilities would require evidence addressing the additional
uncertainty that change introduces.

Question 9:

Would a benchmarking structure such as the one described above be likely to provide
adequate evidence of clinical knowledge, analytic capabilities, safety behavior,
communication, and generalizability to support a reasonable assurance of safety and
effectiveness? Are there elements that are missing, redundant, or inappropriately
categorized? Are there externally developed standards that could be leveraged?

Response:

We recommend strengthening the existing elements by making context integrity,
human-AI workflow performance, and care completion more explicit.

These concepts overlap with the FDA’s existing elements, particularly information gathering,
communication, safety, and agentic competencies. They should strengthen those elements
rather than create duplicative requirements.

Context integrity. Testing should establish whether the system received required information,
recognized important omissions, distinguished current from historical information, reconciled
conflicting sources, and preserved source attribution. It should also determine whether
relevant information was actually used rather than overlooked within a long record.
Unconfirmed patient-entered information should not silently become an established clinical
fact.

Human-AI workflow performance. Where clinician review is a safeguard, evaluation should
examine whether the clinician can locate the supporting information, recognize uncertainty,
and meaningfully review the recommendation under expected workload. It should assess
appropriate acceptance and correction—not simply approval rates.

In particular, testing should identify whether clinicians are repeatedly fixing the same AI
mistake, even though the final reviewed care appears appropriate. Those corrections show
that the review is catching the error. They also reveal a persistent defect that could reach
patients if review becomes less reliable.

Clinical process effectiveness and care completion. Evaluation should follow a clinically
important issue from recognition to appropriate follow-up. For a service intended to support
care between visits, testing should show whether unresolved work is identified and routed to
the right person, including when a patient does not respond or a handoff fails. It should also
establish whether the relevant information remains available to the clinician responsible for the
next step.

Simulated testing can assess how the device handles these situations. Whether the
recommended care actually occurs should be assessed during clinical confirmation and
ongoing monitoring, with attention to the reasons care was not completed.

We do not see a need for substantial reorganization of the proposed categories. Existing
human-factors and usability methods should be used where applicable. The FDA’s
human-factors guidance already addresses safe use by intended users in intended
environments and provides a useful starting point for assessing interfaces and reviewing
workflows (U.S. Food and Drug Administration).

Question 10:

CDRH recognizes that publicly available benchmarking assets may be subject to data
contamination, saturation, and limited real-world representativeness. How should a
sponsor establish that performance on a given benchmark predicts safe and effective
real-world behavior for the device’s intended use? What evidence should support the
construct validity of a benchmark used to gate device evaluation, and what role should
sponsor-developed benchmarks play given potential concerns around independence
and optimization to the test?
Response:

A high benchmark score does not establish that a device will perform safely in clinical use.
Developers should show what the benchmark measures and how its results relate to the
intended use.

Construct validity means that the benchmark measures the claimed competency. A test of
medical knowledge does not, by itself, establish that a system can gather a history, recognize
missing information, or complete a safe handoff.

Clinical validity requires sound scoring. Criteria should reflect accepted clinical practice, with a
defined process for judging open-ended responses and resolving legitimate disagreement.

Real-world relevance requires cases that reflect the expected information quality,
conversational behavior, workflow, and clinical conditions, including incomplete or conflicting
information.

Predictive validity concerns whether benchmark performance carries into clinical use.
Developers should compare benchmark findings with clinical confirmation and later
monitoring. Where that relationship has not yet been established, the uncertainty should be
stated rather than presenting the benchmark as a validated predictor.

Developer-created benchmarks are important because external datasets may not match a
particular clinical function. Concerns about bias should be addressed through evaluation
design, rather than by automatically favoring public datasets.

We recommend standardized external benchmarks where they support meaningful
comparison, function-specific developer benchmarks, and clinical confirmation. Credibility
should be strengthened through separation of development and evaluation data, protected
test sets, versioned records, prespecified scoring, and independent clinical adjudication where
appropriate.

Repeated use of the same cases can eventually encourage optimization to the test. Developers
should retain known failures for regression testing while also introducing fresh, independently
selected cases.

If benchmark scores improve while real-world performance does not, the developer should
reassess whether the benchmark is measuring the right capability. Findings from monitoring
should inform both the device and the tests used to evaluate it.
Question 11:

CDRH is considering that clinical confirmation for a GenAI-enabled device might not
require a prospective clinical study in every case, and has described above a range of
approaches of increasing rigor and patient exposure. How might a sponsor select and
justify a confirmation approach tailored to a device’s intended use and proportionate to
the device’s risk profile? Are there device types or risk profiles for which one or more of
these approaches would be insufficient or inappropriate? How might the anticipated
distribution of real-world inputs be taken into consideration? Are there other methods
of clinical confirmation that might help inform the evaluation of GenAI-enabled
devices?

Response:

Clinical confirmation should address the clinically important uncertainty remaining after
benchmarking. The consequence of failure and the function’s independence should guide the
choice of method, rather than a fixed ladder of study designs.

Developers should explain what remains unanswered and why the chosen approach can
answer it reliably.

The following are possible starting points, not automatic requirements:

Function Possible confirmation approach

Lower-consequence informational Retrospective real-world inputs, standardized
function interactions, and independent clinical review.

Personalized or action-directing Retrospective evaluation combined with
function with limited or moderate standardized patients or shadow deployment.
consequences

Clinician-supervised action-taking Shadow deployment, review of real cases, and
function prospective observation where uncertainty
remains about the actual workflow.
 Highly consequential or Staged prospective evaluation and, where
substantially autonomous function appropriate, a controlled clinical study.

Prospective evidence becomes more important when the system independently initiates
consequential actions, depends heavily on user behavior, produces errors that are difficult to
detect, or takes actions that are difficult to reverse. It is also important when the intended
population is heterogeneous or retrospective evidence leaves substantial uncertainty.

The limits of each method should be stated. Shadow deployment cannot fully establish how
users respond to visible recommendations. Retrospective records may not show whether a
conversational system would have elicited missing information. Standardized interactions may
not capture the full range of actual patient behavior.

Developers should describe the expected case mix, information quality, user behavior, and
settings. Common presentations should be represented, while uncommon high-consequence
situations may require deliberate additional testing. Results from those different case groups
should remain distinguishable.

Synthetic cases can supplement evaluation where real cases are scarce. They should not be the
sole basis for concluding that a system performs adequately in a population or failure mode the
synthetic cases may not represent.

Question 14:

For open-ended device outputs, how should performance comparators and
acceptance criteria be selected? When a panel of qualified clinicians serves as the
comparator, how should the applicable standard—for example, the standard of care
versus the performance of a median clinician in practice—be defined and justified?
Should generalist or specialist physicians be used as a performance standard? When
should human-AI team performance, rather than the device operating alone, serve as
the basis for evaluation?

Response:

The comparator should follow the intended use. A separate clinical reference should establish
whether the care is acceptable.
These comparisons answer different questions: whether an output is clinically appropriate and
whether the proposed system improves the care process it is intended to change.

Intended use Primary comparison Additional assessment

AI assists a clinician Clinician-plus-AI versus Device performance before
who retains decision representative unaided clinical clinician correction and the
authority care. effect of review.

AI independently AI alone versus the applicable Exceptions, downstream
performs a defined clinical reference and alternative safeguards, and residual
function care pathway. serious risks.

AI helps a generalist Generalist-plus-AI versus Specialist review of clinical
with a unaided generalist care or the appropriateness.
specialist-domain documented specialty-access
question pathway.

AI supports follow-up The AI-enabled workflow versus Timeliness, completion,
or care-gap closure existing care. unnecessary care, and
relevant patient outcomes.

Human-AI performance

For a clinician-supervised function, team performance is essential because that is the deployed
intervention. Research on human-AI collaboration shows that combining the two does not
invariably outperform the stronger component (Vaccaro et al.). That supports evaluating the
benefit of review rather than assuming it. It does not establish that autonomous clinical care is
generally superior.

Where feasible and appropriate, evaluation should distinguish clinician performance without AI,
device performance before clinician correction, and the combined workflow. Device-alone
assessment can occur retrospectively or in simulation; it does not require exposing patients to
unapproved autonomous care.

The review process should show whether clinicians correct errors, overlook them, or change
appropriate recommendations. It should also reflect realistic review time and workload.

Recognizing greater capability
A request to reduce clinician review should be evaluated against the performance of the
proposed workflow with less review. Good outcomes under close supervision do not establish
that the same function would remain safe after a review step is removed, particularly when
clinicians are repeatedly correcting a known error.

The framework should also allow a developer to demonstrate that a different oversight
arrangement provides better care. The comparison should assess serious errors and missed
exceptions, along with whether clinician review corrects mistakes, changes appropriate
recommendations, or delays necessary care. The clinical scope and remaining safeguards
should be explicit so that a finding about one task is not mistaken for evidence supporting
broader autonomous practice.

For open-ended outputs, acceptance criteria should allow clinically reasonable alternatives
rather than demand identical wording. Qualified clinicians should establish the applicable
standard, with specialist input where the domain requires it. Criteria should assess
appropriateness, completeness, prioritization, uncertainty, and safety, with serious errors
considered separately from minor differences.

The evidence should establish which oversight arrangement works for the particular function.

Question 15:

Are there ways in which performance might be assessed relative to the care,
technology, or course of action likely to occur in the absence of the device, rather than
to the comparators described in this section? What approaches might be used to
identify and justify a comparator such as unaided clinical judgment, delayed specialist
review, or no intervention?

Response:

Yes. For many functions, the care pathway likely to occur without the device is the most
meaningful comparison for measuring clinical benefit.

For longitudinal care, matching an expert’s answer to a perfectly organized case may tell us less
than whether the system identifies and addresses an important issue in the records and
workflow actually available.
A developer claiming benefit from better chart review, specialty access, or follow-up should
document those conditions in the intended setting. It should not assume that every clinician
has unlimited review time, but it should not manufacture an artificially weak comparison either.

For example, a follow-up function could be evaluated against documented completion rates
under the existing workflow. A specialist-support function could be compared with the actual
generalist and referral pathway. A longitudinal synthesis function could be compared with
representative chart review using the information and resources normally available.

The comparator should be selected in advance and justified using observational workflow data,
representative historical care patterns, shadow deployment, concurrent controls, matched
cohorts, or randomized studies when appropriate. Delayed care or no intervention should be
used only when evidence shows that it is the realistic alternative.

Expert review and real-world comparison should complement each other. Expert review
establishes whether care is clinically appropriate; the real-world comparison establishes
whether the system improves what patients otherwise receive. Inadequate usual care should
not become permission for unsafe device performance.

For a function intended to support care between visits, the comparison should examine
whether a clinically important issue was identified and resolved, how long that took, and how
much work remained for the patient or caregiver. It should also capture unnecessary tests or
contacts generated by the system. Identifying more possible care needs is not enough to
establish benefit. The developer should show that those needs were clinically appropriate to
pursue and that the resulting workflow improved care. Where improved access or lower cost is
part of the claimed benefit, those outcomes should be measured in the intended setting.
These measures would allow the FDA to recognize improvements that diagnostic agreement
alone would miss, while still requiring evidence that the care provided was appropriate.

III. Postmarket monitoring and change control
Question 18:

CDRH is considering whether it may be appropriate to accept greater premarket
uncertainty regarding a GenAI-enabled device’s benefit-risk profile through greater
reliance on postmarket monitoring. Under what conditions might such an approach be
appropriate, and what characteristics of a monitoring program would need to be in
place to justify reduced premarket evidence? Are there device types or risk profiles for
which this approach would not be appropriate?
Response:

Greater reliance on postmarket monitoring can be appropriate when the remaining uncertainty
is defined, the risk can be controlled, and problems can be detected in time to act. Basic safety
questions should be answered before patients are exposed.

Some questions are best answered during actual use: variation in conversations, changing case
mix, clinician override behavior, patient comprehension, longitudinal follow-through, and
performance after modification.

A developer should specify which uncertainties remain and how monitoring will address them.
The program should identify the cases being monitored, the data collected, the review process,
the thresholds for intervention, and who is responsible for acting. It should also show that
important outcomes can be observed promptly enough for monitoring to be useful.

Greater postmarket reliance may be appropriate for a bounded function with effective
supervision, traceable outputs and actions, reversible consequences, staged deployment, and
the ability to suspend the function or restore additional review.

It is less appropriate when an error could cause severe harm before detection, the action is
difficult to reverse, the system cannot be reliably stopped, or fundamental effectiveness
remains uncertain. Rare catastrophic failures require attention before deployment; waiting for
them to occur is not an adequate monitoring strategy.

Conditions for changing supervision

Before postmarket evidence is used to support less clinician review, the developer should
specify the function and patient population involved, which decisions would proceed without
prior approval, and which situations would still require a clinician. The evaluation should address
the safeguards that would be removed or changed. The monitoring plan should identify the
questions that remain unanswered, how they will be investigated, and the findings that would
justify continuing, restricting, or stopping the proposed use. Responsibility for acting on those
findings should be assigned before deployment.

Evidence from supervised use can identify functions worth evaluating with greater
independence. It should not be treated as proof that the same performance will persist after
clinician correction is removed. Any reduction in required oversight should follow the applicable
regulatory process, with a workable means of restoring review or suspending the function if
performance deteriorates.

Question 19:

Please comment on the potential approaches to postmarket performance evaluation,
including periodic re-benchmarking, sample-based clinician review, and performance
degradation monitoring. What additional approaches should CDRH consider, and how
should the cadence and triggering events for reassessment be determined?

Response:

We support all three approaches. Monitoring should examine the clinical function, the
human-AI interaction, and what ultimately happens in care. The FDA should also distinguish
internal reassessment from external reporting or review.

Function performance should include clinical appropriateness, safety-critical recognition and
escalation, scope adherence, and performance on difficult or previously failed cases. Prior
failures should remain in regression testing, alongside fresh cases that help detect new
problems.

Human-AI interaction should include approval and modification patterns, the clinical
significance of disagreement, review time and delays, repeatedly dismissed alerts, recurring AI
errors corrected by clinicians, and errors introduced after appropriate AI recommendations.
Sampling should account for different clinicians, sites, and workload conditions.

Monitoring results should distinguish system versions and levels of supervision. Performance
when a clinician reviews every case should be reported separately from performance under
exception-based review, including which errors were caught before action and which reached
the patient. This would help determine whether a change in responsibilities altered the safety of
the care process.

Care-path outcomes should include completed and failed handoffs, unresolved cases, repeat
contact, delayed follow-up, unnecessary or duplicate care, relevant urgent-care use, patient
confusion, near misses, and harmful incidents. These findings should be investigated rather
than automatically attributed to the AI.

Scheduled review should reflect consequence, independence, case volume, stability, and the
ability of other safeguards to detect harm. A stable track record may justify a different
cadence. An absence of reported problems means little, however, if monitoring is incomplete.
Internal testing and FDA reporting

Changes to the model, prompts, clinical information sources, rules, tools, review workflow, or
interface should receive a documented assessment of their potential clinical effect. Clinically
meaningful changes should trigger proportionate testing. Safety signals, population shifts, and
unexpected increases in disagreement or escalation should also prompt reassessment.

That does not mean every prompt adjustment should generate a separate FDA submission.

We recommend clear distinctions among changes that can be managed through documented
internal testing, changes requiring FDA notification or review, and incidents carrying separate
reporting obligations. Treating these as the same obligation could slow routine safety
improvements or encourage developers to defer beneficial updates.

For routine changes, the FDA could consider standardized periodic summaries describing the
change, affected function, testing, findings, and corrective action. Voluntary sharing of
appropriately protected aggregate findings could help identify which changes most often
affect safety.

These summaries would give the FDA useful evidence without requiring submission of every
experiment or prompt revision.

Question 22:

CDRH envisions that a manufacturer’s premarket competency-based assessment might
serve as a baseline against which post-deployment modifications could be
re-evaluated. How might the extent of re-benchmarking or other evidence be scaled to
the nature and expected impact of a given modification? For example, are there
categories of change that might not significantly affect safety or effectiveness of a
GenAI-enabled device, or might be appropriately managed within a sponsor’s quality
management system versus requiring FDA premarket review and authorization before
implementation? Are there categories of changes that might be appropriate for
inclusion in a PCCP?

Response:
The amount of reassessment should reflect the potential clinical effect of the change,
regardless of how small the change appears in the code.

A short wording change could affect urgency or patient understanding. An infrastructure
change might leave clinical behavior unchanged or alter reliability and timing in ways that
matter. Its category should follow the impact assessment rather than the engineering label.

Expected clinical impact Proposed response

Minimal Document the change and verify that relevant behavior,
information, timing, and safeguards remain unchanged.

Localized Test the affected function, adjacent safety behaviors, and
realistic user interactions.

Broad or safety-relevant Conduct broader re-benchmarking and determine whether
renewed clinical confirmation is needed.

Changed intended use or Assess the need for expanded evidence and FDA review
independence rather than treating the change as routine maintenance.

Reducing clinician review should be evaluated as a change in the clinical workflow even when
the model and prompts remain unchanged. The assessment should identify which clinician
checks would no longer occur and what evidence supports the safety of the proposed
arrangement.

The premarket assessment can serve as the reference point, but testing should also account
for newly identified failures and intended-use conditions. Repeatedly passing the original cases
should not be the only measure of continued safety.

A Predetermined Change Control Plan, or PCCP, can make foreseeable updates more
predictable. The FDA’s existing approach allows an authorized plan to describe planned
modifications, their development and validation methods, and their impact assessment,
without an additional marketing submission for each covered modification.

For GenAI, we recommend exploring plans organized around bounded categories of change
where the exact future version is unknown. The plan should specify what may change, what
must remain constant, the required evaluation, acceptance criteria, monitoring, and rollback
conditions.
A defined testing protocol should not be treated as permission for any future modification.
Expanded clinical scope or reduced oversight should receive explicit consideration. The plan
should make routine updates manageable while stating which changes fall outside the
authorization.

Question 24:

For devices built on third-party foundation models, changes to the underlying model
may be initiated by the third-party model developer rather than the device
manufacturer. How can a manufacturer detect, evaluate, and respond to such changes
in a timely manner? What mechanisms—for example, contractual, technical, or through
a PCCP—could provide reasonable assurance that third-party developer-initiated
changes do not compromise the safety or effectiveness of the device?

Response:

The clinical developer should remain responsible for the final system’s performance, even when
it does not control the underlying model. The FDA should also make clear what information and
controls developers need from model providers to meet that responsibility.

The same clarity is needed when software and clinical care are supplied by different
organizations and offered under a partner’s brand. The parties should document who controls
the deployed configuration, approves clinical protocols, investigates failures, and can suspend
use. Patients should be able to identify the medical group responsible for their care. These
arrangements should preserve the manufacturer’s obligations for the device and the medical
group’s responsibility for care.

We recommend three complementary safeguards:

Contractual safeguards: Developers should seek model-version identification, advance notice
of material changes, safety-relevant release notes, incident notification, and reasonable
deprecation timelines. Where possible, prior versions should remain available long enough to
evaluate and manage a transition. Relevant changes include refusal behavior, output
formatting, tool use, and other behavior on which the clinical application depends.

Technical safeguards: Developers should maintain a versioned record of the complete
deployed configuration, use version pinning where available, test updated models against
protected clinical cases, and monitor unexpected changes in output or behavior. Major
transitions may warrant shadow testing or staged release within the permitted use. Behavioral
monitoring can help detect change, but it cannot guarantee detection of every unannounced
update.

Operational safeguards: Developers should define who approves changes, what testing is
required, how post-release performance is reviewed, and what triggers suspension, additional
clinician oversight, or rollback. A fallback plan must account for the possibility that the older
model will no longer be available.

Small clinical developers may have limited bargaining power with large model providers. Clear
FDA expectations about version information, change notice, and transition support could
therefore help make responsible deployment more practical.

A PCCP may address anticipated categories of model updates, but it cannot remove
uncertainty about changes outside its scope. When an unexpected provider change threatens
a validated function, the developer should protect patients first and follow the applicable
review and reporting process.

IV. Agentic AI
Question 26:

Are there additional considerations that inform the premarket and postmarket
evaluation of agentic GenAI-enabled devices, beyond those applicable to non-agentic
GenAI-enabled devices? How should the elevated risk associated with autonomous
multi-step action, tool use, and reduced opportunity for human review be reflected in
acceptance criteria and oversight?

Response:

Agentic risk depends on what actions the system can execute, how those actions combine,
and whether an error can be prevented or corrected before harm occurs.

A system that retrieves information has different responsibilities from one that changes
treatment. Evaluation should therefore define the available tools, permitted actions, review
checkpoints, and limits on execution—not simply describe the system as “agentic.”

Complete workflows must be tested. Individually correct steps can still produce an unsafe
result if the system uses outdated information, misinterprets a tool response, repeats an action,
or continues after a prerequisite fails.

Evaluation should include missing and conflicting information, tool timeouts, incorrect results,
partial completion, duplicate-action risk, changed patient instructions, loss of clinician
availability, and model or tool updates. It should also test whether retrieved material or tool
output can improperly influence subsequent actions.

The system should verify what actually happened rather than assume that a submitted request
was completed. Its sequence of decisions and actions should be traceable so failures can be
investigated.

Review before consequential actions

Where the safety of a function depends on clinician review, the system should not act before
that review occurs. A proposal to remove or reduce review should be evaluated for the specific
action and clinical circumstances, with particular attention to serious or difficult-to-reverse
harm. An earlier approval should not allow the system to proceed when new clinical information
or an unexpected tool result triggers a further review requirement.

An out-of-scope action should not proceed merely because the system pauses for
acknowledgment. It should be handed off to an appropriately authorized clinician or process.

Greater independence for a defined function

The framework should permit progression toward exception-based oversight when evidence
establishes reliable task completion, recognition of safety-critical exceptions, appropriate
handling of tool failures, scope adherence, traceability, and effective monitoring.

The system that identifies exceptions must also be tested. A reliable routine pathway is
insufficient if the system fails to recognize which patients do not belong in it.

Readiness for one task should not be taken as evidence of readiness for another. A service may
perform a validated routine function independently while continuing to require clinician
approval for a different function or a change in the patient’s circumstances. The authorization
should specify the task, patient population, permitted actions, and conditions requiring a
handoff. New capabilities should be evaluated against their own intended use rather than
assumed to be covered because they rely on the same underlying model.

Conclusion
Four or five years from now, we believe patients could reasonably expect a care service to
recognize important changes between visits and follow through without being repeatedly
prompted. A family should be able to obtain that attention without paying for a private clinician
to review every detail personally.

That level of support would also change how clinicians spend their time. A physician could
begin an encounter with the relevant history assembled and routine follow-up already
addressed, leaving more attention for the patient whose diagnosis is uncertain, whose
treatment is not working, or whose circumstances make the usual plan inappropriate.
As physicians, we should be prepared to evaluate evidence that some clinical tasks are
performed more reliably without our approval on every case. We should be just as demanding
about whether the system recognizes when a patient needs us. A favorable average score
cannot settle either question.

The useful lesson from Waymo is that these responsibilities can expand while the limits on use
remain explicit. California’s programs distinguish supervised testing from driverless operation
and place conditions on deployment (California DMV). For clinical AI, we recommend the same
discipline of making the permitted responsibility explicit: which task, for which patients, using
what information, with which safeguards. Success in one setting should not authorize use in
another.

The FDA can help define those limits now. Clinical developers need workable routes to
supervised evaluation. They need to know what evidence would justify reducing review and
what findings require them to stop. Requirements for monitoring and system updates should
make it possible to correct problems promptly while keeping the developer accountable for
the resulting care.

We are concerned that leaving those questions unsettled will disadvantage the services willing
to document their performance and investigate their failures, while patients continue to obtain
advice elsewhere. A demanding but usable regulatory pathway would give developers a reason
to bring their evidence forward and patients a better basis for deciding whom to trust.

Clara would welcome working with the FDA to test these approaches against actual clinical
cases. That work could inform practical standards for evaluating conversations, assessing the
effect of clinician review, and determining when a change in responsibility is justified.
Appropriately protected findings, including failures, could help establish what developers
should be expected to demonstrate.

For the daughter helping her mother, the benefit would be more time discussing a care
decision together, and less time reconstructing the record and finding someone to review it.
We believe that is an achievable expectation for far more families within the next four to five
years. The framework being developed now should help establish how to provide that care
safely.

Respectfully submitted,

Niraj Patel, DO, MBA.​
Medical Director
Clara Health
 Works Cited

California DMV. “California Autonomous Vehicle Regulations - California.” California DMV,

https://www.dmv.ca.gov/portal/vehicle-industry-services/autonomous-vehicles/californi

a-autonomous-vehicle-regulations/. Accessed 14 September 2026.

California Public Utilities Commission. “CPUC Approves Permits for Cruise and Waymo To

Charge Fares for Passenger Service in San Francisco.” 10 August 2023.

https://www.cpuc.ca.gov/news-and-updates/all-news/cpuc-approves-permits-for-cruis

e-and-waymo-to-charge-fares-for-passenger-service-in-sf-2023. Accessed 8

October 2026.

Raynes, Stephen, and Ellyn Maese. “Americans Turning to AI to Supplement Healthcare Visits.”

Gallup News,

https://news.gallup.com/poll/707789/americans-turning-supplement-healthcare-visits.a

spx. Accessed 11 September 2026.

U.S. Food and Drug Administration. Applying Human Factors and Usability Engineering to

Medical Devices: Guidance for Industry and Food and Drug Administration Staff. 3

August 2026. https://www.fda.gov/media/80481/download. Accessed 8 October 2026.

Vaccaro, Michelle, Abdullah Almaatouq, and Thomas Malone. “When Combinations of Humans

and AI Are Useful: A Systematic Review and Meta-analysis.” Nature Human Behaviour,

vol. 8, 2024, pp. 2293–2303. https://doi.org/10.1038/s41562-024-02024-1.

Waymo. “Safe to Deploy: How We Know The Waymo Driver Is Ready For The Road.” Waymo,

https://waymo.com/blog/2025/06/safe-to-deploy/.