OutcomesAI (Kuldeep Singh Rajput)

OutcomesAI, Inc. submits the attached comments on CDRH’s discussion paper “Considerations for the Regulation of Generative AI-Enabled Medical Devices” (Docket No. FDA-2026-N-7874). OutcomesAI is a US-based AI-native nursing company that builds and operates generative AI-enabled software for nursing lines and nurse-patient conversation programs, including nurse triage by voice and chat on licensed Schmitt-Thompson protocols with licensed-nurse oversight, ambient documentation for nurse call centers, and conversational voice agents for virtual care, remote monitoring, and care management programs. Our comments respond to all 26 discussion questions and draw on production deployment and clinical validation experience. In summary, we support the two-axis risk framework as a screening heuristic with a structured hazard analysis beneath it; a competency-based premarket approach that evaluates the deployed system and credits supervised live deployment as clinical confirmation; separate acceptance criteria for under-escalation and over-escalation; keeping synthetic and real-world evidence separate; postmarket programs that combine automated scoring of every interaction with independent clinician review; change-control evidence scaled by impact assessment, with recurring change categories handled under a PCCP; and explicit treatment of voice as a modality and nurses as intended users. Please see the attached document for the full comments.

OutcomesAI Comments on FDA Discussion Paper on
Generative AI-Enabled Medical Devices
Introduction
Submitted by: OutcomesAI, Inc.
Docket: FDA-2026-N-7874 (Document FDA-2026-N-7874-0001)
Regarding: Considerations for the Regulation of Generative AI-Enabled Medical Devices:
Discussion Paper and Request for Feedback, August 2026
To: U.S. Food and Drug Administration, Center for Devices and Radiological Health
Date: October 20, 2026
Submitted through: regulations.gov
OutcomesAI, Inc. appreciates the opportunity to comment and supports CDRH’s direction:
an intended-use and risk-based, total product life cycle approach that evaluates the
complete deployed device rather than the foundation model in isolation, combined with
clinical confirmation, effective postmarket monitoring, and controlled updates, applied
under least burdensome principles without lowering the bar for safety-critical behavior.
Our central recommendation is to connect each clinically consequential failure pathway to
a demonstrated safeguard, a measurable acceptance criterion, and a responsible party
throughout the device life cycle. The paper already recognizes the essential principles; our
comments focus on making them operational and predictable.
OutcomesAI is a US-based AI-native nursing company. We build and operate generative AIenabled software for nursing lines and for healthcare programs that run on nurse-patient
conversations. Today that includes nurse triage by voice and chat that executes licensed
Schmitt-Thompson telephone triage protocols with licensed-nurse oversight; ambient
documentation and clinical note generation for nurse call centers; conversational voice
agents for virtual care, remote patient monitoring, chronic care management, and
transitional care programs, covering patient onboarding and offboarding, compliance and
adherence outreach, symptom check-ins, and technical support; and front-door agents that
resolve administrative requests such as scheduling, prescription refills, and insurance
questions. These products run on Glia, our clinical voice stack: speech-to-text and text-tospeech models trained on millions of real clinical telephone conversations, an orchestration
layer that combines deterministic protocol logic with large language models, and a
verification layer that checks generated outputs before they reach a nurse or patient. Other
healthcare organizations also build their own voice agents on the same stack.
Our comments draw on production experience. Our ambient documentation and note
generation is deployed in production with a national nurse triage operation that handles on
the order of 100,000 calls a month, and was evaluated by that customer on more than
2,000 real calls before go-live. Our triage engine is undergoing protocol-by-protocol clinical
validation across the full adult Schmitt-Thompson library using thousands of nursereviewed scenarios, with validated scenario sets from the protocol publisher being
incorporated. We operate the controls the paper discusses: prespecified acceptance criteria
by disposition level, independent nurse adjudication against a single reference disposition,
shadow scoring of new models before release, model version freezes with evaluation-gated
releases, validated fallback models, and clinical review of samples of real calls. We build on
third-party foundation models alongside our own and manage their versioning in
production.
That experience bears directly on several of the paper’s themes: multi-turn conversations
that move from information to action direction; care escalation where both underescalation and over-escalation carry real cost; voice as an input modality with its own
failure pathways; and change control when part of the stack is supplied by a third party.
Where our answers rest on that experience, we say so.
Nothing in this comment characterizes the regulatory status of any OutcomesAI product.
We comment on the framework the paper describes and how it would work in practice.

Summary of recommendations
Our positions, in the order of the paper’s sections:
1. Keep the two-axis framework as a screening heuristic and require a
structured hazard analysis beneath it. Activity and consequence are the right first
cut. They do not capture how an error propagates through a multi-step system, who
can detect it, how much time there is to intervene, and whether the result is
reversible. Those dimensions should be documented for every GenAI-enabled
function. (Question 1)
2. Judge directiveness by substance, not wording. Distinguish descriptive,
interpretive, and prescriptive content. An interpretation that resolves a clinically
consequential question for a specific patient is action-directing even without an
instruction, and a disclaimer does not make it less so. FDA should publish paired
examples and a rubric. (Question 2)
3. Treat patient-facing delivery as a contextual factor, not an automatic step up
in risk. Evaluate what the intended patient will infer and do, assess comprehension
and correctness separately, and credit designs that keep source facts, uncertainty,
and escalation paths visible. (Question 3)
4. Treat the generalist versus specialist question as a question of independent
evaluability. Risk rises when the user cannot check the output for that task.
Protocol-anchored designs and outputs that show their basis narrow the gap.
(Question 4)
5. Evaluate conversational devices across whole trajectories against a defined
scope. Test boundary crossing through ordinary follow-up questions and
accumulated context, not only adversarial prompts, and judge the cumulative
meaning of the exchange. (Question 5)
6. Score under-escalation and over-escalation separately, by acuity. Missed or
delayed emergency escalation is a safety-critical failure with its own acceptance
criterion. Over-escalation must always be reported so that escalating everyone
cannot pass as safe triage. (Question 6)
7. Support the competency-based approach, with the deployed system as the
unit of evaluation. Benchmarking shows capability; clinical confirmation with
intended users shows performance. Supervised live deployment and shadow
deployment should count as confirmation methods, and authorization at a
supervised activity level with a defined postmarket program should be able to
support a later move to greater autonomy. (Questions 7, 8, 11, 18)
8. Make information fidelity explicit and test robustness within each
competency. Preservation of facts, qualifications, negation, and uncertainty across
transformations deserves its own element. Robustness and subgroup performance
should be checked per competency, and voice devices should be benchmarked on
representative audio, not transcripts. (Questions 9, 17)
9. Build benchmarks from the intended use, and keep synthetic and real-world
evidence separate. Application-specific benchmarks with independent
adjudication, protected evaluation sets, and fresh cases across versions. Synthetic
results should never be pooled with real-world results to inflate sample size.
(Questions 10, 12, 13)
10. Compare against the care that actually exists. Use rubric-based clinical criteria
set in advance, choose generalist or specialist reviewers by task, and do not require
a two-arm trial solely because a device uses GenAI. (Questions 14, 15)
11. Use independent third parties proportionately, building on existing programs.
Protected datasets, adjudication, and method validation are the highest-value roles.
Mandatory external execution of every test would raise cost without raising
assurance. (Question 16)
12. Do not trade premarket assurance on safety-critical behavior for postmarket
monitoring. Postmarket reliance is appropriate for defined residual uncertainties
and for scope expansion once core performance is established, with thresholds,
review, and intervention authority specified in advance. (Question 18)
13. Monitor every interaction automatically, review samples clinically, and rebenchmark on defined triggers. Supervisory agents are useful and should be
evaluated like any other component; they are never the sole basis for assurance.
Manufacturer accountability stays whole. (Questions 19, 20, 21)
14. Scale change-control evidence by impact assessment, not by label. Any change
that can alter generated clinical output warrants a full re-run of the applicable
benchmark suite, without automatically repeating clinical confirmation or a new
submission. Recurring categories such as model version updates, prompt changes,
and clinical content updates may be suitable for an FDA-authorized PCCP where
their scope, limits, validation procedures, and impact assessment are adequately
specified. Third-party model use requires version pinning, advance notice, and a
validated fallback. (Questions 22, 23, 24)
 15. Foundation Model Master Files add limited value and must never become a
prerequisite. If pursued, focus on version identity, support commitments, and
change notification. (Question 25)
16. Evaluate agentic devices under the same framework, on the complete action
sequence. Acceptance criteria should cover right patient, authorized scope,
completion, reversibility, and human checkpoints before high-consequence actions.
(Question 26)

Responses to the discussion questions
Responses follow the numbering in Appendix B of the discussion paper and address all 26
questions. Each response states our position first, then the reasoning and, where relevant,
what we have observed in deployment. Clinical examples are illustrative and do not
determine whether a particular software function meets the statutory device definition.
Bracketed numbers refer to the References at the end of this document.
Section IV: Assessment of risk
Question 1: Does the two-axis framework capture the relevant dimensions? What
should be added?
The activity and consequence axes are a sound first cut and should be retained for initial
screening. They are not sufficient on their own. We recommend that FDA require, beneath
the two-axis placement, a structured account of hazards, propagation, safeguards, residual
risk, and supporting evidence for each GenAI-enabled function.
The reason is that GenAI-enabled functions are pipelines, and the final output’s activity and
consequence do not reveal where an error entered or how it grew. A clinical assistant that
synthesizes record data and guidelines into a recommendation may convert “not
documented” into “absent,” drop a qualification, or apply a guideline to an incorrectly
inferred patient characteristic. Each later step then builds on the error and produces a
recommendation that looks well supported. In a voice triage call the same thing happens
one layer earlier: a misrecognized temperature, medication name, or negation enters
through speech recognition, passes through protocol selection, and ends as a disposition.
The final function, “advises the caller to see a clinician within 24 hours,” sits in the same
cell of the framework whether the error came from the language model or from the
microphone. The framework should therefore ask whether the system preserves clinically
important facts, qualifications, and uncertainty across its intermediate transformations,
and how a failure at each stage changes the likelihood of downstream harm.
We support the four additional dimensions the paper names. Reversibility, downstream
safeguards, time pressure, and traceability all matter, and we would represent them,
together with propagation, as follows:

Dimension What the sponsor should establish
Clinical influence What can the function change, recommend, delay, omit, or cause
and authority someone to believe?
Dimension What the sponsor should establish
Hazards and What harmful situations can arise, and how severe could the
consequences resulting harm be?
Likelihood and How often do those situations arise, in which populations and
exposure conditions, and across how many uses?
Propagation How can an error or unsafe action travel through other software,
people, and workflows?
Detection and Who or what can recognize the problem, with what information, and
intervention with what authority to act?
Time and Can intervention occur before harm, and how costly or difficult is
recoverability recovery?
Traceability Can the user or reviewer see the basis for the output (the source
facts, the protocol or guideline applied, the positive findings) well
enough to check it?
Evidence and How well have these claims been demonstrated, and what remains
uncertainty unknown?

One caution on downstream safeguards. Supervision by a healthcare professional should
move a function left on the activity axis only when the supervision is real: the reviewer sees
the basis for the output, has the time to check it, and has the authority to override it. A
nurse who receives a disposition with the protocol and the positive findings attached can
evaluate it in seconds. A nurse who receives a fluent paragraph with no visible basis
cannot, and in a high-volume workflow will not. The framework should credit supervision
in proportion to what the design actually makes checkable.
These dimensions should supplement the diagram rather than be collapsed into an
unvalidated composite score. Severity, probability, and uncertainty should remain
distinguishable: the absence of effective review raises the probability that an error reaches
a patient without changing the severity of the resulting injury. FDA should provide a
worked example that links an input error to an unsafe output, a downstream decision, and
patient harm, with the evidence required at each control point, consistent with established
medical device risk management principles [3].
Question 2: How should the spectrum between non-directive and action-directing
information be handled?
We support assessing directiveness along a continuum, based on the substantive meaning
and context of an output rather than on particular words or disclaimers. We suggest
distinguishing three types of content:
• Descriptive information: what was reported, observed, or documented.
• Interpretive information: what those facts might mean.
• Prescriptive information: what action should follow.
Prescriptive content should generally be considered action-directing. Suggestions,
recommendations, prioritized actions, and instructions all direct users to some degree,
even when expressed through tentative wording such as “consider” or “may wish to.”
Recommendations to defer care, continue without further assessment, or take no action
should be assessed on the same basis as recommendations to initiate an intervention.
Interpretive content warrants particular attention because it directs action implicitly.
Explaining a term in a clinical report does not endorse a course of action. Interpreting
patient-specific findings as showing that further assessment is unnecessary does, even
without an explicit instruction. In triage, “your symptoms do not meet the criteria for
emergency care” is phrased as interpretation and functions as a disposition. We
recommend that FDA assess whether an interpretation merely aids understanding or
effectively selects, endorses, or excludes a clinical course of action. Relevant characteristics
include the patient-specific nature of the conclusion, the degree of certainty expressed,
whether material alternatives remain open, and whether the output supplies a conclusion
that ordinarily determines the next step in the intended workflow. No single characteristic
should be decisive. Personalization alone does not establish directiveness, and tentative
wording does not establish its absence.
Descriptive content should be assessed separately, for fidelity and completeness.
Summarization, translation, or reformatting can preserve source meaning without
becoming action-directing, and an inaccurate summary can materially affect care without
endorsing any action. Converting “not documented” into “absent” creates an unsupported
factual assertion whose risk a directive versus non-directive label does not capture.
Unmodified source material should not automatically be considered non-directive either:
selective presentation or placement in response to a clinical question can function as a
recommendation.
Traceability helps only when the cited source actually supports the statement and applies
to the patient and context. A citation attached to an unsupported inference is more
dangerous than no citation, because it lends the inference authority.
For functions intended solely to describe or summarize, manufacturers should establish
boundaries against introducing new patient-specific clinical conclusions. For functions
intended to interpret, manufacturers should specify the permitted scope of interpretation
and evaluate whether generated outputs cross into implicit action direction. This matters
more for GenAI than for conventional software because outputs vary in their degree of
interpretation across otherwise comparable inputs.
To give manufacturers predictability, we recommend that FDA publish paired examples
using the same source information and clinical context, showing the transitions from
faithful description to interpretation and from interpretation to implicit and then explicit
action direction, with a rubric explaining which characteristics change the conclusion and
how they interact with the consequence axis.
This rubric should inform risk assessment while preserving the separate analysis of device
status and applicable statutory exclusions, including the criteria addressed in FDA’s clinical
decision support software guidance [2].
Question 3: Patient-facing versus HCP-facing delivery of clinical information.
We recommend that patient-facing delivery be treated as a contextual factor in risk
assessment rather than an automatic basis for assigning higher risk. The assessment
should consider the clinical judgment required of the recipient, the likely use of the
information, and the consequences of misunderstanding or of reliance on an incorrect
output. Patient capability should be assessed for the particular task, not inferred from the
absence of professional credentials.
A useful distinction is whether a function communicates existing information, generates a
new patient-specific interpretation, or recommends an action. Faithful explanation of an
existing report or a clinician-approved plan supports patient understanding and
participation. When a system moves from explaining information to interpreting what it
means for an individual, it may implicitly resolve a clinical question, for example by
suggesting that a finding is unimportant.
Directiveness and audience together still do not determine risk. A patient assistant may
explain how to position a blood pressure cuff or how to take a newly prescribed medication
according to the clinician’s instructions. Both are actionable instructions. An error in cuff
positioning produces an inaccurate reading; an error in a dose or schedule can lead directly
to harmful medication use. The assessment should consider the specific device or
medication, the consequence of an incorrect instruction, and the opportunities to detect
and correct the error before harm, recognizing that a measurement error becomes
consequential when the reading informs treatment.
The assessment should examine both what the output states and what the intended patient
is likely to infer from it: whether the patient can distinguish documented findings from
generated interpretation; whether uncertainty and missing information remain visible;
whether the presentation implies authority beyond the evidence; and whether the
interaction may change care-seeking, adherence, or other consequential behavior.
Safeguards should be matched to the function. For explanatory functions: preserve
qualifications and uncertainty, distinguish source information from generated
interpretation, and maintain boundaries against unsupported patient-specific conclusions.
For action-directing functions: establish that the patient understands the action, its timing,
its limitations, and the circumstances requiring further help. Where human escalation is a
necessary safety control, its availability and timely completion should be demonstrated, not
assumed. In our AI-assisted triage design, three controls carry most of the weight:
dispositions are computed from protocol logic rather than generated freely; emergency
handling is a fixed safety floor that configuration cannot remove; and the caller can reach a
licensed nurse at any point. We would encourage FDA to recognize controls of this kind as
risk modifiers when they are demonstrated.
Patient comprehension and output correctness should be evaluated separately. A patient
may understand an incorrect recommendation perfectly. Comprehension checks cannot
substitute for evidence of clinical accuracy, and safe use should not depend on patients
detecting errors that require professional expertise to recognize. By the same logic, a
clinician-facing configuration should not automatically receive credit for effective review
without considering the task and the use setting.
Evaluation should include representative intended users and relevant variation in
language, health literacy, accessibility needs, and circumstances of use, and should assess
understanding and resulting decisions rather than readability or satisfaction alone. FDA
should also recognize the benefits of improved access, comprehension, and participation,
and provide examples showing when patient-facing delivery changes risk and when
appropriate design supports safe use.
Question 4: Generalist versus specialist HCP-facing functions.
We recommend treating this as a question of independent evaluability rather than of
credentials. Risk rises when the intended user cannot check the output for the task at hand,
and that depends on three things: what the output asks the user to judge, whether the
output exposes its basis, and whether the user’s role and training cover that judgment.
Most GenAI-enabled nursing software has nurses, not physicians, as the intended HCP user,
and the paper’s framing should accommodate that. A registered nurse working a triage line
can independently evaluate a protocol-based disposition when the protocol, the questions
asked, and the positive findings are visible, because evaluating exactly that is the nurse’s
trained task. The same nurse cannot independently evaluate a free-text differential
diagnosis in a specialist domain, and neither can a generalist physician in many cases. The
intended user should therefore be defined by role and task competence, and the risk
assessment should ask whether the output stays within what that role can verify.
Three device characteristics mitigate the risk when outputs reach a user without the
relevant specialist knowledge. First, scope limits: the function declines or redirects
requests for specialist interpretation it is not intended to provide, and is tested for underrefusal as well as over-refusal. Second, traceability: the output shows the guideline or
protocol applied, the inputs relied on, and the findings that drove the conclusion, so that a
non-specialist can at least check the inputs and recognize when they are wrong. Third,
routing: where the clinically correct response is specialist review, the function’s output is
an escalation to that review with the relevant information attached, not a substitute for it.
Where these characteristics are present and demonstrated, we do not believe the
generalist versus specialist distinction should by itself raise the risk tier.
Question 5: Multi-turn conversational devices and emergent behavior.
We recommend assessing multi-turn conversational devices against a clearly defined
intended use that states whether patient-specific interpretation and action-directing
recommendations are within scope, and then evaluating complete conversational
trajectories rather than individual turns. In triage the migration from information to action
direction is not an anomaly, it is the workflow: a call begins with open questions and ends
with a disposition. The intended use should be characterized as that trajectory, including
the user behaviors the device must handle along the way.
Where action direction is within scope, evaluation should cover the full progression and its
risks. Where it is outside scope, evaluation should establish whether the device
consistently declines or redirects, or whether system-level controls detect the boundary
crossing and hand off or terminate the interaction before inappropriate advice reaches the
user. Testing should assess how readily these safeguards are bypassed through ordinary
follow-up questions, persistent requests, indirect prompting, and accumulated context, not
only explicit adversarial attempts. The assessment should consider both individual
responses and the cumulative meaning of the conversation.
In our scenario testing, four conversational behaviors reliably change dispositions and
therefore need deliberate coverage: the caller minimizing symptoms after an initial
disclosure; a second complaint introduced late in the call; “I don’t know” answers to
protocol questions; and conflicting information across turns. A test set for conversational
devices should include these deliberately and should score the outcome of the whole call.
Where a human handoff is the safety control, the measure is not only whether handoff
occurs but how long it takes from the moment the trigger appears.
Acceptance criteria should address encounter-level failures, the time to recognize a
boundary crossing, and completion of any required handoff. For evolving presentations, the
evaluation should identify when sufficient information for escalation first became available
and score delay from that point. A later correction should not erase an earlier
consequential failure from the evaluation. Repeated generations and alternative
conversation paths should be assessed to characterize variability; a single successful
exchange does not establish reliable behavior. Representative encounter performance and
targeted stress-test results should be reported separately, with clear denominators.
Question 6: Under-escalation and over-escalation in care escalation functions.
We recommend evaluating under-escalation and over-escalation separately, with trade-offs
determined by clinical acuity rather than by a single overall accuracy metric.
For presentations requiring emergency services or emergency department care, the
primary objective is preventing missed or delayed escalation. Under-escalation of an
emergent presentation should be a safety-critical failure with its own prespecified
acceptance criterion at or near zero, reported with confidence intervals and with time-toescalation. Strong average performance across lower-acuity cases must not offset failures
in emergency recognition. Evaluation should also distinguish the direction of each miss: a
disposition one level more urgent than the reference is a cost; one level less urgent is a
hazard. Reporting the full distribution of outputs against the reference by acuity level, in
effect a confusion matrix across dispositions, makes both visible at once. This is how we
score our own triage engine against single nurse-adjudicated reference dispositions, and it
is the measure that has driven the most useful corrections.
Observing zero failures in a study does not establish a zero failure rate. Manufacturers
should prespecify the tolerated failure bound, the statistical confidence, and the sample
size in relation to clinical consequence. As a statistical illustration only, zero failures in 300
independent, representative emergency encounters gives a one-sided 95% upper binomial
bound of approximately 1% on the failure probability; this is not a proposed clinical
threshold, and repeated outputs from the same encounter cannot be counted as
independent encounters. Delayed and reversed escalations should be reported alongside
missed ones.
For lower-acuity presentations, evaluation should balance under-triage and over-triage
according to their consequences. Excessive escalation consumes clinical resources,
increases patient anxiety, exposes patients to unnecessary visits and testing, and erodes
trust in a way that reduces appropriate care-seeking later. This balance does not imply
equal weighting: acceptable trade-offs should reflect the consequence of delayed care, the
opportunity for reassessment, and the intended care setting.
Manufacturers should therefore prespecify clinically justified acceptance criteria by acuity
level and report the distribution of errors across care levels. Over-triage should remain
visible even in emergency-focused evaluation, so that routinely escalating every caller
cannot be presented as adequate performance. Where a comparator is needed, the
documented performance of the existing triage process on the same protocols is the right
one; human telephone triage has its own measured under- and over-triage rates, and the
device should be judged against that reality rather than against perfection.
Where no common numerical measure across the two directions of error is defensible,
separate clinical constraints should be used rather than a single weighted score. FDA
should provide examples of how such criteria can be justified for distinct care settings.
Section V: Competency-based premarket evaluation
Question 7: Is the competency-based approach a useful and appropriate framework?
Yes. We support a competency-based approach that combines device benchmarking with
clinical confirmation, and we particularly support the paper’s choice to evaluate the final
user-facing device as configured for deployment rather than the foundation model in
isolation. In our experience the same language model behaves differently once it sits
behind speech recognition, protocol logic, retrieval, and guardrails, and only the assembled
system’s behavior is meaningful for safety.
Benchmarking should establish whether the complete device demonstrates the capabilities
its intended use requires. It should not alone be considered sufficient evidence of realworld performance. Clinical confirmation should include testing with actual intended users,
patients, healthcare professionals, or both, in representative settings and with appropriate
participant protections, and should assess performance under realistic variation in user
behavior, communication, workflow, and operating conditions. The design and extent of
confirmation should be proportionate to intended use and risk, with predefined acceptance
criteria for safety and effectiveness.
Question 8: Using the two-axis framework to set the level of evidence.
We recommend using the activity and consequence axes to set the floor for evidence
requirements, then adjusting for information fidelity, implicit or explicit action direction,
error propagation, and the demonstrated effectiveness of safeguards.
These dimensions should determine which competencies are assessed, the test conditions,
the acceptance criteria, and the extent of clinical confirmation. Functions that summarize
or transform information should demonstrate preservation of clinically important facts,
qualifications, and uncertainty. Functions that interpret or recommend should additionally
demonstrate that their conclusions are clinically supported and stay within scope. Where
errors can propagate across processing stages or downstream workflows, evaluation
should establish their effect on the complete system.
Manufacturers should map each material hazard to the applicable competency, test
conditions, endpoint, acceptance criterion, clinical confirmation method, and postmarket
measure. FDA should provide a reusable template for that mapping; it would do more for
consistency across sponsors and reviewers than narrative guidance alone.
As an illustration of how the axes would translate in practice: an HCP-supervised triage
support function with moderate consequences would be benchmarked on safety-critical
recognition and escalation, scope adherence, calibration, clinical knowledge, information
gathering, communication, and robustness and subgroup performance, with clinical
confirmation through supervised live use and independent nurse adjudication of real calls.
A fully autonomous patient-facing escalation function with severe consequences would add
emergency-case criteria at or near zero under-escalation, audio-level robustness testing,
and prospective confirmation before unsupervised use. The two axes set which of these
apply; the fidelity, propagation, and safeguard evidence adjusts how much.
The required strength of evidence should reflect the severity and likelihood of harm, the
uncertainty in those estimates, and the opportunity to detect and correct failures before
harm. Greater consequences, limited recoverability, or unproven safeguards warrant more
demanding testing and stronger statistical assurance. Claimed safeguards should reduce
evidence requirements only where their effectiveness has been demonstrated, including
resistance to foreseeable conversational pathways that bypass them. Safety-critical
outcomes should carry separate acceptance criteria so that strong average performance
cannot conceal consequential failures.
Question 9: Adequacy of the benchmarking structure; missing, redundant, or
miscategorized elements; external standards.
We broadly support the proposed elements and do not recommend expanding the category
structure. We recommend four refinements.
First, make information fidelity explicit within Clinical Proficiency, either as its own
element or as a named component of E.2: preservation of clinically important facts,
qualifications, negation, attribution, and uncertainty across transformations; avoidance of
unsupported additions or omissions; and accurate use of source information. Evaluation
should also examine how fidelity failures propagate into subsequent interpretation or
recommendation. This is the failure mode we watch most closely in note generation and
summarization, and it is currently implicit at best.
Second, assess robustness (R.1) and subgroup performance (R.2) within each applicable
competency rather than only as separate aggregate measures. Acceptable overall
performance can conceal unreliable safety-critical behavior under particular input
conditions or in particular populations. Overlapping elements can share test scenarios
while retaining distinct acceptance criteria where clinically necessary. For voice devices,
R.1 should explicitly include acoustic and telephony variation: background noise, line
quality, accents and dialects, speech rate, interruptions, and the speech recognition errors
these produce. Testing a voice device on clean transcripts measures a device that does not
exist.
Third, we support the time-to-escalation testing already described in S.1 and recommend a
prespecified scored endpoint measured from the first qualifying finding, with clinically
justified acceptance criteria.
Fourth, S.3 should distinguish well-worded uncertainty from reliable uncertainty
assessment. Where a device supplies a numerical confidence or an abstention score, its
relationship to actual performance should be evaluated empirically for the claimed task
and population. Fluent expressions of caution do not establish calibration. E.4 should keep
user understanding as an outcome separate from clinical correctness.
On external standards: existing standards for risk management, software life cycle
processes, and usability engineering provide supporting structure and should be
referenced, but they do not substitute for device-specific clinical performance benchmarks
or real-world confirmation. For functions built on published clinical content, such as nurse
triage protocols, the content itself is the most useful external reference: it defines the
questions, thresholds, and dispositions against which outputs can be scored, and its
authors maintain validated scenario sets that can anchor benchmarking.
FDA should distinguish recognized process standards, such as ISO 14971 for risk
management [3], from validated performance benchmarks. The former structure the work;
only the latter demonstrate the device.
Question 10: Benchmark validity, contamination, and the role of sponsor-developed
benchmarks.
Benchmark selection and development should begin with the device’s intended use, patient
population, clinical tasks, and deployment setting. Public benchmarks may provide
supplementary evidence but rarely represent the specific clinical context, and their
contamination status cannot be verified. Manufacturers should develop application-specific
benchmarks, in collaboration with relevant clinical authorities, professional societies, or
qualified independent clinical experts where available, that map test scenarios and scoring
criteria to the competencies and failure modes relevant to the intended use.
Sponsor-developed benchmarks can be credible if their governance is. The practices we
would expect FDA to look for, and that we follow in our own program: separation of
development cases from protected evaluation cases; documented contamination checks for
any model trained on data from the deployment environment, including splits that keep
evaluation speakers or sites disjoint from training; adjudication of reference answers by
clinicians independent of the development team; and use of externally authored cases
where they exist, such as scenario sets built by the authors of the clinical protocols the
device executes.
Where a third-party model’s training data are unknown, the sponsor should state that
limitation and rely on complementary controls, such as evaluation cases created after the
model’s training cutoff or held privately, rather than claim that contamination has been
excluded. Where automated judges score outputs, their agreement and error detection
should be validated against qualified clinical review, particularly for serious errors and
relevant subgroups; a judge that shares the device’s blind spots produces misleading
agreement. Benchmark selection, exclusions, and unsuccessful evaluations relevant to
safety should be documented to limit selective reporting.
Real-world performance should then provide the central basis for the submission,
supported by benchmark evidence. Manufacturers should examine whether benchmark
results predict the clinical behaviors and failures observed in practice, rather than
assuming that strong benchmark performance establishes clinical validity. Analysis should
include representative samples of real encounters and targeted investigation of outliers,
failures, and subgroup differences. Cases used to improve the system should not later be
presented as independent validation, and post hoc analyses should be distinguished from
the prespecified assessment.
Protection against optimization to the test should extend across device versions.
Repeatedly using the same evaluation results to select updates erodes the benchmark’s
independence. Manufacturers should retain stable regression tests while periodically
introducing fresh, independently governed evaluation cases, with frequency and extent
justified by risk and development practice.
Question 11: Selecting and justifying a clinical confirmation approach.
The confirmation method should be selected according to intended use, risk, and the
performance claims requiring validation, not by requiring one study design for every
device. Clinical confirmation should include substantial testing with actual intended users
in representative settings, with appropriate participant protections.
FDA should explain which uncertainties each confirmation approach can and cannot
resolve, rather than ranking designs only by patient exposure. Retrospective evaluation
and shadow deployment assess output quality on real inputs; they cannot show how users
respond to outputs they never see. Standardized patient interactions test rare scenarios
under controlled conditions but need justification as proxies for actual care.
We recommend clarifying when the clinician adjudication approach already described in
Section V.C.1 can provide sufficient confirmation, and explicitly addressing supervised live
deployment.
The first is structured, independent clinical adjudication of real-user interactions, which
can be sufficient where the relevant safety and performance endpoints can be reliably
assessed from interaction records and supporting clinical information. Qualified reviewers
evaluate encounters against predefined criteria, with documented independence and
procedures for resolving disagreement. Depending on risk and scale, review may cover
every interaction or a justified representative sample, supplemented by targeted review of
safety-critical cases.
The second is supervised live deployment, in which the device operates in the real
workflow and every output is reviewed by the intended healthcare professional before it
affects care. This generates real inputs, real user behavior, and a clinician decision on every
output, and it is how clinical software is in fact introduced into nursing workflows. It
should count as clinical confirmation for the supervised configuration and, with
independent adjudication of the accumulated record, as evidence toward a less supervised
one. Shadow deployment provides complementary evidence about output quality on real
inputs, and we use it routinely before promoting a new model to primary. It cannot
establish user response or the safety of a less supervised configuration.
The evaluation population should reflect the anticipated distribution of real-world inputs,
stratified by the frequency of presentations in the deployment setting, while ensuring
adequate coverage of uncommon but consequential scenarios and relevant subgroups.
Where safety or effectiveness depends on patient comprehension, subsequent actions,
workflow completion, or clinical outcomes, adjudication should be supplemented by direct
measurement of those endpoints.
For each approach, the reference criteria, sampling, adjudicator qualifications,
disagreement resolution, and handling of missing outcomes should be prespecified. Data
collected in other countries or settings should be assessed for differences in clinical
practice, language, access pathways, and population, with relevance, reliability, and
transferability justified consistent with FDA’s real-world evidence framework for devices
[4].
Retrospective evaluation alone is insufficient for any function whose output changes the
patient’s next action without a healthcare professional in between, and for escalation
functions in general, because the consequential behaviors depend on the live interaction.
Prospective or comparative studies should be used where material uncertainties cannot be
resolved by the methods above.
Question 12: Statistically meaningful measurement, synthetic inputs, and combining
evidence.
Statistically meaningful measurement begins with predefined clinical endpoints,
acceptance criteria, and an evaluation population representative of the intended use.
Sample sizes should support adequate precision for the outcomes that matter, including
safety-critical failures and relevant subgroups. For escalation functions this has a practical
consequence: demonstrating a near-zero under-escalation rate on emergent presentations
with a useful confidence interval requires a large number of emergent cases, which are rare
in the natural call mix. Sponsors should enrich for them deliberately and report stratumlevel estimates rather than a pooled accuracy. Analyses should account for dependence
among repeated outputs, conversational turns, and encounters from the same patient or
site, and should report confidence intervals alongside point estimates.
Statistical planning should also define the estimand: what performance is being estimated,
for which population, using which device version and endpoint; and the unit of analysis,
denominator, reference standard, and treatment of missing data, refusals, aborted
encounters, and unsuccessful handoffs. In-scope failures should not disappear because the
device declined to answer or the call dropped. Representative samples estimate
performance under the expected case mix; enriched samples characterize rare hazards but
do not estimate their population frequency. Both should be reported, with any weighting
back to the target population justified.
Synthetic inputs support development and targeted testing, including uncommon scenarios
and known failure modes. They should not replace real-world clinical confirmation. Real
interactions contain combinations of ambiguity, incomplete information, abbreviations,
variable formatting, and unexpected user behavior that generated cases do not reproduce,
and adding such features artificially does not establish equivalence.
We recommend reporting synthetic benchmark results separately from performance
measured in real-world testing. Synthetic cases should not be added to the real-world
sample to imply greater statistical certainty, and performance on synthetic data should not
be assumed to estimate real-world performance.
Combining benchmark and clinical confirmation evidence into a single estimate should
require a clearly defined common endpoint and target population, justification of
differences in sampling and input distributions, and evidence that the combination is valid.
Where these conditions cannot be shown, the evidence should remain separate, with realworld results as the primary estimate of clinical performance and synthetic testing as
supplementary evidence about specific capabilities or failure modes.
Where evidence is combined, component results and sensitivity analyses should be
reported so that the effect of borrowing information is visible.
Question 13: Where synthetic data is well suited or inadequate, and safeguards
against shared blind spots.
Synthetic data should have a limited, supplementary role, best suited to narrowly defined
tasks where expected behavior can be independently assessed against a reliable reference.
It is well suited to fidelity testing of transformation functions. In generating clinical notes
from transcripts, controlled input variations can test whether the system preserves facts,
negation, attribution, and uncertainty without introducing unsupported content,
complementing evaluation on authentic conversations. It is also useful for stress testing
rare high-acuity presentations that are underrepresented in live data, provided the cases
are authored or reviewed by clinicians.
It is inadequate where success depends on realistic patient behavior, evolving interactions,
atypical presentations, or complex clinical judgment. For voice devices it is inadequate at
the audio level: synthesized speech does not reproduce the accents, hesitations,
overlapping talk, and line conditions of real callers, and a speech model that performs well
on synthesized audio can fail on the population it will serve. Synthetic cases should not be
assumed to represent underrepresented populations merely because they carry selected
demographic or linguistic features, and they should not replace real-world evidence for
those populations.
Safeguards should include clinically justified generation methods, independent expert
review, explicit documentation of generated or modified features, and comparison with
protected real-world evaluation data. Where models of the same class as the device
generate the inputs, manufacturers should investigate shared blind spots and should never
allow the same model family to generate the case, produce the reference answer, and judge
the output. Apparent success on synthetic cases should be confirmed against independently
collected real-world examples before broader conclusions are drawn.
Question 14: Comparators and acceptance criteria for open-ended outputs.
For open-ended outputs we recommend evaluating against predefined, clinically
meaningful criteria rather than requiring agreement with a single clinician-generated
answer. Multiple responses may be acceptable, and differences in length, wording, or
comprehensiveness should not themselves determine quality. A “median clinician”
comparator is difficult to interpret without a clearly defined clinician population, task, and
setting; a standard-of-care comparator grounded in guidelines or protocols is usually more
defensible.
Qualified clinical experts should establish task-specific rubrics informed by applicable
guidelines and accepted practice, identifying required information, acceptable alternatives,
clinically consequential omissions, unsupported interpretations, harmful
recommendations, and communication requirements. Acceptance thresholds should be
clinically justified and set before evaluation. Safety-critical failures should have separate
criteria and should not be offset by strong performance elsewhere.
Where the task has a bounded answer, the reference should be bounded too. In triage,
reviewers may weigh several candidate dispositions for a scenario but should agree on one
reference disposition, and the device is scored against that single reference. Accepting any
“reasonable” disposition as a pass hides under-triage, because the same scenario would
pass at two different acuity levels.
Multiple independent reviewers should assess an appropriately designed sample using the
same criteria. Reviewer expertise should match the task: specialists where specialist
judgment is needed, and intended users, including nurses, where practical usability and the
user’s own evaluation of the output matter. Calibration, agreement, and adjudication
procedures should be documented while preserving legitimate clinical variation.
Structured ratings reduce the burden of asking clinicians to generate complete alternative
answers. Where output sources are compared, origin should be masked where feasible.
Evaluation should reflect how the device is used and the benefit claimed. For cliniciansupport devices, assessment should include performance in the intended human-AI
workflow. Where the primary benefit is efficiency, the objective is to demonstrate that
benefit while maintaining clinically acceptable safety and performance, not necessarily
improved clinical outcomes. Comparisons of clinicians with and without the device should
be used where needed to substantiate claims or resolve material uncertainties. A noninferiority approach may be appropriate with clinically justified margins and adequate
precision; absence of a statistically significant difference does not establish equivalence.
For autonomous functions, performance should be assessed without assuming that
clinician review will catch errors before harm.
Evaluation of the human-AI workflow should include automation bias, review time, missed
errors, and the verification burden the device introduces. A tool that saves time only
because its outputs are trusted uncritically has not demonstrated a benefit.
Question 15: Assessing performance relative to the care that would occur without
the device.
We support evaluating devices against the care or workflow reasonably expected in their
absence where this provides a clinically relevant comparison. The comparator should
reflect documented existing practice, including access limitations, delays, and the measured
error rates of the existing process, rather than an artificially weak alternative chosen to
favor the device or a standard of perfection no current process meets. For a triage function,
the relevant comparator is the documented performance of the existing nurse line, or,
where there is none after hours, the absence of any triage at all.
The need for a comparative study should depend on intended use, claimed benefit, risk, and
the uncertainties requiring resolution. Where performance can be adequately established
through real-world testing and independent clinical adjudication against predefined
criteria, a two-arm clinical trial should not be required solely because the device uses
GenAI.
Controlled comparisons become more important when claims concern changes in clinician
performance, care delivery, or patient outcomes that cannot be reliably attributed to the
device through standalone evaluation. Randomized trials may be appropriate where
stronger causal evidence is necessary. Crossover designs and well-designed concurrent
observational comparisons may be justified where they adequately address bias and
confounding.
FDA should provide examples of when comparative evidence is necessary and what
alternative designs are acceptable. The objective should be the least burdensome design
capable of resolving material safety and effectiveness uncertainties, while maintaining
clinical acceptance criteria regardless of the quality of existing care.
Poor baseline access may affect the benefit-risk assessment, but it should not excuse
avoidable, clinically unacceptable device errors. Both absolute clinical acceptability and
incremental benefit should remain visible in the evaluation.
Question 16: Role of independent third parties.
We support building on established third-party mechanisms, including the ASCA and MDDT
programs, rather than creating a separate system for GenAI-enabled devices. Independent
parties add the most value by maintaining protected evaluation datasets, validating
assessment methods, adjudicating clinical outputs, and independently verifying important
performance claims. Clinical content authors and professional societies are natural sources
of validated scenario sets and reference criteria.
A new GenAI assessment should not be presumed covered by an existing accreditation or
qualification. FDA should explain how a third-party finding would be used in review and
how a disagreement between the third party and the sponsor would be resolved.
Qualifications should match the clinical domain and the evaluation task, including relevant
clinical expertise and competence in assessing AI performance. Independence should be
demonstrated through separation from device and underlying-model development,
disclosure and management of conflicts of interest, and controls against evaluation-data
leakage or selective reporting. External organizational status alone is not evidence of
independence.
Third-party involvement should be proportionate to risk and to the judgment involved.
Independent clinical review is particularly valuable for open-ended outputs. Requiring
external execution of every internal test or every minor-change assessment would add cost
and delay without adding assurance, and would fall hardest on smaller developers, which is
where much of the innovation in this category is happening.
FDA should support transparent qualification criteria, multiple qualified providers, and
acceptance of equivalent scientifically justified methods. Third-party assessments should
inform regulatory review while leaving the manufacturer accountable for the complete
device.
Question 17: Application to other model architectures.
The competency-based framework should apply across underlying architectures.
Benchmark selection should follow the device’s intended use, clinical functions, and risks,
not whether it uses a text-only, multimodal, speech, or other model.
Common competency categories do not imply identical test methods or datasets.
Evaluation should cover the input modalities, interactions, and operating conditions the
deployed device encounters. Voice-based functions should be tested on representative
audio under realistic telephony conditions, and the speech recognition component should
be evaluated on the errors that matter clinically, such as medication names, numbers and
units, and negations, rather than on a generic word error rate. Multimodal functions should
be evaluated for errors arising from the interpretation and integration of different
information sources, including missing or conflicting inputs. Where a device predicts future
clinical states or simulates the consequences of actions, evaluation should address accuracy
over the clinically relevant horizon, the reliability of expressed uncertainty, and whether
errors accumulate across simulated steps. Clinically plausible generated trajectories do not
by themselves establish predictive validity.
Voice evaluation should also cover speaker attribution on calls with more than one speaker
and the communication delays that affect conversational behavior. Multimodal evaluation
should include mismatched patients or time points across sources. Modality-specific
failures should be reported on their own rather than absorbed into an aggregate score.
We recommend retaining the common framework and adding modality- and functionspecific testing considerations that address relevant failure modes and component
interactions, without requiring evaluation of model capabilities outside the device’s
intended use. Performance of the complete deployed system should remain the basis for
assessment.

Section VI: Postmarket monitoring and modifications
Question 18: Accepting greater premarket uncertainty in exchange for postmarket
monitoring.
We do not support accepting greater premarket uncertainty about safety-critical behavior
because GenAI evolves quickly or because evaluation delays commercialization. Premarket
evidence should establish safety and effectiveness for the intended use, including realworld confirmation proportionate to risk. Faster paths to market should come from
efficient evaluation methods and controlled update pathways, not from reduced assurance.
Greater reliance on postmarket evidence is appropriate in two situations. The first is a
clearly specified residual uncertainty where core performance is established, the expected
clinical benefit justifies earlier access, and the remaining risk can be controlled. The
sponsor should identify precisely which uncertainty is being deferred and show that the
monitoring program can resolve it within a defined time. The second is scope expansion: a
device authorized at a supervised activity level, with a defined monitoring program and
prespecified criteria, should be able to use the accumulated real-world record,
independently adjudicated, to support a later move to a less supervised configuration or a
broader population. This staged path matches how clinical software is actually adopted and
rewards sponsors who generate evidence in use.
Each deferred question should have a defined endpoint, a reliable means of observing
outcomes, an adequate sample, a deadline, and a decision rule, and the manufacturer
should show that detection and corrective action can occur within the time available before
serious harm. Staged expansion helps only where the restrictions on the initial
configuration are enforceable in the deployment.
A monitoring program that justifies either should include access to relevant outcomes,
representative data collection, predefined performance thresholds, timely independent
review, and clear authority and responsibility to restrict, suspend, or correct use.
Monitoring must be linked to intervention; detecting a problem after irreversible harm
provides limited protection.
This approach would be inappropriate where the unresolved uncertainty concerns safetycritical performance and failures could cause serious harm before detection, or where the
relevant outcomes cannot be reliably observed.
A monitoring plan cannot compensate for inaccessible outcome data or ineffective
intervention. FDA should specify what happens when the planned evidence is not obtained
or a threshold is crossed, including restriction, suspension, or further study.
Question 19: Approaches to postmarket performance evaluation, cadence, and
triggers.
We support combining sample-based clinician review, periodic re-benchmarking, and
performance degradation monitoring, and we recommend adding a fourth layer:
automated scoring of every interaction against the device’s quality and safety rubric. At
production volumes, a fixed-percentage clinician sample quickly exceeds what any review
team can read. Automated scoring of all interactions directs clinician attention to the cases
most likely to matter and gives degradation monitoring a continuous signal. It does not
replace clinician review; representative review of unflagged interactions remains
necessary to measure what the automated layer misses.
Qualified clinical review of real-world interactions should remain central, using predefined
criteria and representative sampling, supplemented by targeted review of safety-critical
cases, suspected failures, and relevant subgroups.
Denominators and sampling probabilities should be preserved so that targeted case finding
does not distort population estimates. Input drift can prompt investigation but is not itself
a validated measure of clinical performance. Missing outcomes should be measured and
investigated rather than treated as successes.
Devices should provide an accessible mechanism for patients and healthcare professionals
to report suspected errors, misleading outputs, workflow failures, and near misses. Users
should not need to establish that a technical malfunction occurred before reporting a
concern. Manufacturers should collect, investigate, and analyze these reports, identify
patterns, and implement corrective actions, with reportable events submitted to FDA
within applicable requirements. Absence of user reports is not evidence that performance
remains acceptable.
Monitoring should preserve enough information to reconstruct the affected interaction and
the device configuration that produced it, including model versions, prompts, and clinical
content versions, with appropriate privacy protections. Sampling frequency and
reassessment cadence should reflect clinical risk, usage volume, and the time available to
detect and address harm. Significant changes to models, prompts, clinical content, or
deployment conditions, as well as emerging safety signals, should trigger additional
assessment. Monitoring should be linked to predefined response thresholds and
responsibilities, including when to expand review, restrict functionality, roll back, or
suspend use.
Applicable event-reporting obligations should remain separate from voluntary
performance monitoring; one does not discharge the other.
Question 20: Machine-based supervisory agents.
Machine-based supervisory systems can support postmarket monitoring by screening
interactions, detecting potential safety or scope violations, and selecting cases for clinical
review. We are building such a system for triage call auditing and consider it valuable.
Where these systems rely on GenAI they carry their own performance limitations and
should not be presumed reliable because they operate as a supervisory layer.
Their evaluation should address missed failures, false alarms, performance across relevant
populations and interaction types, and the possibility of correlated errors with the device
being monitored, including failures that originate in information or assumptions shared
with the primary system. A supervisor built on the same model family as the device, or on
the same transcript the device misheard, will share its blind spots.
The combined system’s residual failure rate, review workload, and response time should be
measured under expected usage, including high-volume and degraded conditions. Where
the supervisor blocks or delays outputs, harm from unnecessary blocking or delayed
assistance counts against it.
We recommend using such systems as a supplement to independent clinical review and
user reporting, never as the sole basis for assurance. Representative review of unflagged
interactions is necessary to measure what the supervisor misses. Supervisory systems
should themselves be under version control, validated after relevant changes, and assessed
on an ongoing basis, with defined procedures when monitoring becomes unavailable or
unreliable. If a supervisory system blocks outputs or changes clinical actions in real time, it
is part of the device and should be evaluated as such.
Question 21: Roles of clinicians, institutions, societies, and standards bodies.
Clinicians and qualified independent reviewers should contribute through structured
review of real-world interactions, identification of clinically consequential errors, and
adjudication of uncertain cases. Healthcare institutions should support appropriate access
to relevant data, reporting of incidents and workflow failures, and implementation of
agreed operational safeguards. Professional societies and standards bodies can support
consistency through clinical reference criteria, reviewer qualifications, standardized
reporting terminology, and assessment methods. Patients and other users should have
accessible reporting channels without being expected to diagnose technical failures.
The manufacturer should remain accountable for the monitoring program as a whole: data
collection, signal analysis, investigation, corrective action, and regulatory reporting.
Responsibilities, data access, and escalation procedures should be agreed explicitly with
participating organizations. External review and institutional participation should
strengthen manufacturer oversight, not transfer responsibility to individual clinicians or
rely on voluntary reporting as the only detection mechanism.
FDA should encourage practical ways to aggregate signals across deployments while
protecting patient information. If a deployment partner cannot provide the data or
implement a safeguard on which safe operation depends, the manufacturer should reassess
the conditions of use rather than treat the contractual allocation of responsibility as
sufficient control.
Question 22: Scaling re-evaluation to the modification, and categories of change.
For GenAI-enabled devices the scope of a modification’s effects is hard to predict from the
apparent size or location of the change. An update to a foundation model, a prompt, a
retrieval process, or a guardrail can change clinical behavior well beyond the component
modified. Limited regression testing is therefore difficult to justify, and rerunning the full
applicable benchmark suite is appropriate for any change capable of affecting generated
clinical output.
Full re-benchmarking should be distinguished from repeating the clinical confirmation
program or filing a new submission. Additional clinical evidence should address the
uncertainties the change introduces, including changes in user interaction, clinical
interpretation, or workflow. Passing the existing benchmark does not establish that new
failure modes are absent; testing should also address hazards specific to the modification.
FDA should keep three decisions separate: the scope of regression and new-hazard testing;
the need for additional clinical confirmation; and whether the applicable regulatory
pathway requires a new submission. Passing benchmarks does not itself determine the
pathway.
We suggest three categories, decided by impact assessment rather than by label:
1. Changes demonstrably isolated from clinical behavior, such as user interface
adjustments, telephony or EHR connectivity, logging, and infrastructure, managed
within the quality management system with targeted verification.
2. Changes that can alter generated clinical output but not the intended use, such as
model version updates, prompt revisions, retrieval or guardrail changes, decoding
parameters, and clinical content updates, managed under a PCCP where the
category and its validation procedure were prespecified, with a full re-run of the
applicable benchmark suite and documented impact assessment before release.
3. Changes to intended use, intended user, scope, or level of autonomy, which require
premarket review.
Clinical content updates deserve explicit mention. Published triage protocols are revised on
a regular cycle, and a revision may move a threshold, for example the temperature at which
a presentation escalates. The kind of change is entirely predictable even though its content
is not, and it is exactly what a PCCP should cover: a prespecified procedure to ingest the
revision, re-benchmark the affected protocols against reference scenarios, and release
under version control.
FDA should clarify how manufacturers can use predefined validation procedures,
acceptance criteria, independent review where appropriate, and controlled
implementation under a PCCP or other change-control mechanism, and should provide
worked examples. The framework should let manufacturers perform comprehensive
regression testing without automatically repeating all original evidence generation and
regulatory review.
The categories above are candidates for FDA’s consideration under its existing PCCP
guidance [5] and software modification guidance [6], not assertions that every such change
is currently eligible. Changes outside an authorized plan remain subject to the otherwise
applicable modification framework.
Question 23: Change control when modifications cannot be fully prespecified.
Where a modification cannot be adequately specified and bounded in advance, we
recommend a process for assessing the concrete proposed change once development and
evaluation are complete. A general commitment to pass existing benchmarks should not
substitute for defining the change and assessing its clinical effects.
FDA should clarify how manufacturers can reuse previously accepted evaluation methods,
acceptance criteria, and relevant clinical evidence when submitting a proposed
modification for review. Additional evidence should address changed functionality, newly
introduced hazards, and uncertainties that comparison with the authorized device cannot
resolve. This preserves the distinction between changes covered by an authorized PCCP
and changes assessed under the otherwise applicable modification framework, while
enabling focused review of a developed update without reopening the original evaluation.
For devices designed to adapt during use, the change-control approach should specify what
may adapt, the permitted limits, controls on incoming data, monitoring, and recovery
behavior, with adaptation outside those limits triggering reassessment. An authorized
PCCP should remain distinguishable from a general quality-system process or a promise of
satisfactory postmarket performance.
Question 24: Third-party foundation model changes.
Manufacturers should maintain control over the foundation model configuration used in
the deployed device. Supplier arrangements should support identifiable, pinned model
versions; advance notification of changes and deprecations; adequate transition periods;
and continued access to a validated version where feasible. Supplier changes to safety
policies, content filters, or other services that affect model behavior should receive the
same treatment as model changes.
Safety-policy, refusal, routing, and service changes can alter behavior even when the
model’s public name is unchanged, and should be treated as model changes for changecontrol purposes.
Before adopting an updated model, manufacturers should assess its impact and rerun the
full applicable benchmark suite, supplemented by tests for newly introduced failure modes,
with additional clinical confirmation where benchmark comparison cannot resolve a
material uncertainty. Supplier performance claims and improvements on general-purpose
benchmarks do not substitute for validation of the complete device. Regulatory handling
should follow the applicable change-control pathway, including an authorized PCCP where
the modification is covered.
The technical controls we apply, and that we believe FDA should expect, are: pinned model
versions with a configuration record for every deployment; a model freeze between
validations, with release gated on the evaluation suite; shadow scoring of a candidate
model on live traffic before promotion; a validated fallback model that takes over
automatically on timeout or failure; and per-call confidence and hallucination guardrails
that flag anomalous outputs for review. Behavioral checks help detect change but are not
proof that the underlying model is unchanged.
Where an unplanned change occurs or a validated version becomes unavailable, predefined
procedures should limit exposure through the validated fallback, rollback where available,
or suspension of affected functions. FDA should clarify acceptable approaches where
suppliers cannot provide sufficient version stability or change transparency. Manufacturer
accountability for safety and effectiveness should remain unchanged regardless of who
initiated the model change.
A fallback model requires its own validation evidence and cannot be assumed
interchangeable with the primary. Where adequate stability, transparency, or response
capability cannot be obtained from a supplier, the manufacturer’s risk controls and
conditions of use should reflect that limitation.

Section VII: Other topics
Question 25: Voluntary Foundation Model Master Files.
We see limited incremental value in broad Foundation Model Master Files where the
manufacturer already provides sufficient evidence of the complete device’s safety and
effectiveness. Foundation models change rapidly, a device may use several models for
different subtasks, and clinical behavior depends on prompts, retrieval, orchestration,
safeguards, and workflow integration. Model-level documentation therefore says little
about how the deployed device performs.
If pursued, the program should remain voluntary and focus on information that materially
supports device review or life cycle control: identifiable model versions, known safetyrelevant limitations, change histories, version-support and deprecation commitments, and
incident notification arrangements. FDA should state what specific uncertainty such a file
resolves and how it would reduce duplicative review. Maintaining extensive files for
rapidly changing models would otherwise impose effort without corresponding benefit.
Useful content would also include evaluation provenance, the behavioral constraints and
guardrails built into the model, and the mechanism by which updates are communicated to
referencing manufacturers. We support FDA piloting the program and testing its practical
value before expanding documentation expectations.
For devices using multiple models, any referenced information should correspond to the
versions and functions actually used, with evaluation of the complete system remaining
central. A master file should neither imply authorization of the underlying model nor
substitute for device-specific validation.
Manufacturers must retain alternative ways to provide adequate evidence when a supplier
does not maintain a master file: supplier documentation, contractual commitments,
configuration records, and device-level evaluation. Participation could be encouraged
through confidentiality protections and a demonstrated reduction in repetitive information
requests, but access to a supplier master file should never become a prerequisite for review
where adequate evidence can be provided otherwise. Developers who train their own
models for part of the stack, as we do for speech, should be able to document those models
directly in the submission.
Question 26: Agentic GenAI-enabled devices.
Agentic devices should be assessed within the same intended-use and risk-based
framework as other GenAI-enabled devices. Multi-step reasoning, tool use, or autonomy
should not by themselves determine regulatory burden; their significance depends on the
clinical actions permitted and the consequences of failure.
Evaluation should, however, explicitly address the failure pathways that executing actions
across systems introduces. Relevant considerations include whether actions affect the
correct patient, remain within authorized scope, complete as intended, and are accurately
represented back to the user. Testing should cover partial execution, tool failures, duplicate
actions after retries, conflicting or stale information across systems, and the ability to stop
or recover safely when a workflow cannot be completed. Identity verification before any
action on a record, and idempotent execution so that a retried step cannot book two
appointments or refill a prescription twice, are design requirements rather than nice-tohaves.
Prompt-injection testing should include instructions embedded in retrieved records and
tool outputs, because those inputs can redirect clinical actions. Audit records should allow
reconstruction of actual inputs, outputs, actions, and configuration; a generated
explanation of the agent’s reasoning is not a reliable execution record. Reversibility should
be demonstrated where claimed: cancelling an order does not reverse an intervention
already performed.
Acceptance criteria should address the safety and effectiveness of the complete action
sequence, including intermediate states, rather than only the correctness of the final
response or of individual tool calls. Human oversight checkpoints before irreversible or
high-consequence actions should be prespecified and tested for bypass. Real-world
confirmation should be supplemented by targeted testing of consequential failure
scenarios that occur rarely in routine use.
Change-control and postmarket monitoring principles should extend to tool permissions,
interfaces, orchestration logic, and external dependencies, since a change to any of these
can change what the agent does. We recommend clarifying how the common framework
applies to these functions rather than establishing separate requirements based on an
“agentic” designation.

Additional considerations
Five points fall outside the numbered questions and, in our view, would strengthen any
guidance that follows from this paper.
Voice is a distinct modality and should be treated as one. A growing share of GenAIenabled clinical functions will reach patients and nurses by telephone. In those devices the
speech recognition layer is a clinical component: a misheard medication, number, or
negation enters the pipeline before any language model runs and is indistinguishable
downstream from a reasoning error. Benchmarking elements should state that voice
devices are evaluated on representative audio under realistic telephony conditions, that
speech recognition is scored on clinically consequential errors rather than generic word
error rate, and that subgroup performance (R.2) covers accents, dialects, and age-related
speech. Guidance that assumes text input will be silently wrong for these devices.
“GenAI-enabled” is not the same as “GenAI-decided,” and the framework should
recognize bounded architectures. Many safe designs use generative models for what
they are good at, understanding natural language and holding a conversation, and use
deterministic, published clinical logic to decide what matters, such as a disposition
computed from protocol rules. Where technically enforced and validated, deterministic
protocol logic can constrain disposition selection. Evaluation must still address errors in
information gathering, protocol selection, input mapping, timing, and communication of the
resulting disposition. The risk assessment, benchmarking, and change-control expectations
should recognize this distinction and let sponsors show where generation is bounded and
test adherence to the bound. This gives FDA an additional, testable basis for assurance, and
it gives developers a clear design target.
Nurses are intended users, and the framework should say so. The paper’s HCP
examples are physicians. Telephone triage, virtual care, remote monitoring, and care
coordination are nurse-led workflows, and most GenAI-enabled nursing software will have
a registered nurse as its intended user, working within a defined scope and under
published protocols. Guidance should define the intended user by role and task
competence, and the evaluability analysis in our response to Question 4 should apply to
nurses on the same terms as to physicians.
Publish worked examples and a reusable assessment template. The framework’s value
will depend on how predictably it is applied. We recommend that FDA publish a small set
of worked examples that carry one device each through risk placement, benchmarking
element selection, confirmation approach, postmarket program, and change categories,
together with a reusable template that maps each hazard to its competency, test, endpoint,
acceptance criterion, confirmation method, and postmarket measure. Priority examples
should address the transition from description to action direction, emergency escalation,
meaningful human review, benchmark validity, and supplier-initiated model changes.
Telephone triage, which the paper already uses to illustrate escalation, would be a natural
first example; an ambient documentation function and an autonomous administrative
agent would cover the other common patterns.
Keep the framework achievable without mandatory intermediaries. The companies
building these systems are often small, with clinical teams that do the validation work
themselves and nurse benches that adjudicate it. A framework that requires independent
adjudication, protected evaluation sets, and transparent governance is achievable for such
a company. A framework that requires external execution of every test, or certification by a
limited set of third parties, would not be, and would consolidate the category around
incumbents without improving safety. Least burdensome principles should be applied to
the evaluation infrastructure as well as to the evidence.
Closing
OutcomesAI appreciates CDRH’s engagement with stakeholders on this topic and supports
the direction of the discussion paper. Our principal request is for worked examples and a
reusable assessment template that connect intended use, hazards, competencies, clinical
confirmation, monitoring, and change control, so that manufacturers can select
scientifically justified methods proportionate to risk and reviewers can apply them
consistently. We would welcome the opportunity to discuss any of these comments, to
share de-identified evaluation methods and results from our triage validation program, and
to contribute to worked examples for nurse-led workflows.
Respectfully submitted,
Kuldeep Singh Rajput
Founder, OutcomesAI, Inc.
kuldeep@outcomes.ai

References
1. U.S. Food and Drug Administration. Considerations for the Regulation of Generative
AI-Enabled Medical Devices: Discussion Paper and Request for Feedback. August
2026. Docket FDA-2026-N-7874. https://www.regulations.gov/document/FDA2026-N-7874-0001
2. U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for
Industry and Food and Drug Administration Staff. https://www.fda.gov/regulatoryinformation/search-fda-guidance-documents/clinical-decision-support-software
3. International Organization for Standardization. ISO 14971:2019, Medical devices:
Application of risk management to medical devices.
https://www.iso.org/standard/72704.html
4. U.S. Food and Drug Administration. Use of Real-World Evidence to Support
Regulatory Decision-Making for Medical Devices: Guidance for Industry and Food
and Drug Administration Staff. https://www.fda.gov/regulatoryinformation/search-fda-guidance-documents/use-real-world-evidence-supportregulatory-decision-making-medical-devices
5. U.S. Food and Drug Administration. Marketing Submission Recommendations for a
Predetermined Change Control Plan for Artificial Intelligence-Enabled Device
Software Functions: Guidance for Industry and Food and Drug Administration Staff.
https://www.fda.gov/regulatory-information/search-fda-guidancedocuments/marketing-submission-recommendations-predetermined-changecontrol-plan-artificial-intelligence
6. U.S. Food and Drug Administration. Deciding When to Submit a 510(k) for a
Software Change to an Existing Device: Guidance for Industry and Food and Drug
Administration Staff. October 2017. https://www.fda.gov/regulatoryinformation/search-fda-guidance-documents/deciding-when-submit-510ksoftware-change-existing-device