Mayo Clinic (Micky Tripathi)

Please see the attached for Mayo Clinic’s comment letter.

SUBMITTED ELECTRONICALLY

October 19, 2026

Food and Drug Administration
Department of Health and Human Services
Attention: FDA-2026-N-7874

RE: Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion
Paper and Request for Feedback. (Docket ID Number FDA-2026-N-7874)

Dear Acting Commissioner Diamantas,

On behalf of Mayo Clinic, we want to thank you for the opportunity to share our comments
regarding FDA’s regulation of GenAI-enabled medical devices. For over 160 years, Mayo Clinic
has been committed to our mission of putting the needs of the patient first. Mayo Clinic provides
care for approximately 1.3 million patients who visit Mayo Clinic campuses from over 130
countries every year. Patients come to Mayo Clinic to receive the highest quality care at sites in
Minnesota, Arizona, Florida and Wisconsin. As the largest integrated, nonprofit, medical group
practice in the world, Mayo Clinic is dedicated to finding answers for patients through medical
care, research and education. Transforming healthcare for the future and today through
advanced, technology-enabled and patient-centered models of care, Mayo Clinic brings
together teams of specialists with a relentless and unwavering commitment to excellence. This
commitment to patient-focused collaboration and innovation continues Mayo Clinic’s rich history
of solving the most serious and complex medical challenges. Mayo Clinic is proud to be top
ranked for quality more often than any other healthcare organization.

Mayo Clinic recognizes the potential for GenAI-enabled devices to improve healthcare by
supporting clinicians, expanding access to expertise and enabling new approaches to care
delivery. A regulatory framework for these technologies should support responsible innovation
while ensuring that new capabilities are introduced with appropriate safeguards in place. We are
generally aligned with FDA’s proposed risk-based, total product lifecycle approach for the
regulation of generative AI-enabled medical devices and support a regulatory framework that
can adapt evidence and oversight to the clinical risk of the device.

Across our comments, we propose several principles that should guide implementation of that
framework. Regulatory evaluation should focus on the performance of the final configured
device within its intended clinical workflow. Human oversight should be recognized as a
meaningful risk mitigation only when users have the information, time, competency and
authority necessary to identify errors and intervene before harm occurs. As GenAI becomes
more capable of supporting or augmenting clinical judgment, FDA should also preserve a clear
distinction between evaluating the competency of a medical device and credentialing a
healthcare professional. Device competency should remain tied to the specific clinical task and
intended use, while clinicians retain responsibility for professional judgment within the scope of
their role and the human-AI workflow. Premarket benchmarking should be tied to the specific
clinical task and complemented by clinical confirmation that reflects representative users,
populations and workflows, while postmarket monitoring should function as an active
governance process that can identify emerging risks and trigger timely corrective action. As
GenAI systems assume greater autonomy or authority to take consequential actions, FDA
should correspondingly increase expectations for evidence, safeguards, monitoring, reversibility
and accountability.

With these overarching principles in mind, Mayo Clinic offers the following responses to a
selection of the questions posed by FDA.

Section IV: Considerations for the Assessment of Risk for GenAI-Enabled Devices
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 (i.e., to primary source materials), that
should be represented in a risk framework, please describe and provide examples of how they
should be represented.

Mayo Clinic supports FDA’s proposed risk-based approach, including consideration of both the
nature of device activity and the clinical consequence of relying on an incorrect output. These
two dimensions provide a useful foundation for assessing risk but may not fully characterize risk
in actual clinical use on their own. We do not recommend adding additional risk dimensions,
however, we recommend that FDA more clearly define what each of the two dimensions
encompasses, so that additional risk-related sub-factors are captured within the two-axis
framework. For example, device activity should reflect what the function does and how well its
output can be controlled and checked. Relevant sub-factors include:

• The nature of the output, including whether it is descriptive, predictive or prescriptive and
whether it reflects existing clinician capabilities that can be independently verified
against a clinician baseline. Outputs that can be meaningfully evaluated against existing
clinical knowledge or capabilities weigh in favor of a lower risk tier when meaningful
clinician oversight is demonstrably effective. In contrast, outputs that introduce new
information, weigh in favor of a higher risk tier.
• The degree of autonomy, including whether human approval is required, a human veto is
available or an action without a gate.
• Verifiability of the output, including whether it links to primary source material and can be
checked within the workflow.
• Error detectability, including whether an incorrect output can be readily identified by the
clinician within the clinical workflow.
• The effectiveness of human oversight, including user competency, the ability to override
and design features that mitigate automation bias.
Clinical consequence should reflect the seriousness and likelihood of harm if the output is wrong
in the context where the device is used. Relevant sub-factors include:

• The severity of the condition and the applicability of the output to the patient population.
• Time pressure and time to harm.
• Reversibility of the resulting action.
• The availability and reliability of downstream safeguards, such as independent review
and confirmatory testing.
• Workflow dependence including the extent to which clinicians must rely on the output
rather than independent information.

System-level factors such as data integrity, cybersecurity and interaction complexity affect the
likelihood of failure but are best addressed through system-level controls (e.g., security review,
change control and monitoring) evaluated alongside the risk tier rather than as additional risk
dimensions. FDA should distinguish between inherent risk, contextual modifiers, risk controls
and residual risk. The two-axis framework should establish inherent risk, contextual modifiers
should characterize how intended use conditions affect the likelihood or consequence of harm
and safeguards should receive risk-mitigating credit only when their effectiveness has been
demonstrated. Residual risk and remaining uncertainty should determine the corresponding
evidence, monitoring and change control requirements.

FDA should use this contextualized assessment to determine the level and type of regulatory
controls necessary to provide reasonable assurance of safety and effectiveness, including
appropriate evidence, safeguards, monitoring and change controls. This approach would
provide a clearer pathway from the initial two-axis assessment to the regulatory expectations
applicable to the device.

Risk should reflect the function and impact of the GenAI system within the clinical workflow. An
advisory, independently verifiable and reversible output presents a different risk than an
autonomous action that is difficult to verify, irreversible or capable of causing harm before
someone can intervene. Human oversight should receive risk-mitigating credit only when its
effectiveness has been demonstrated under representative conditions. Intended users should
be able to recognize consequential errors, understand material uncertainty, verify or challenge
the output, interrupt or override inappropriate action and intervene within the available time.
Evaluation should measure the specific function attributed to oversight, including error detection,
override, escalation and time to intervention. Aggregate human-AI team performance alone may
not establish that the control is effective.

We recommend that FDA define a small number of risk tiers, each with clear examples and
expectations, rather than relying only on the continuous spectrum. The final risk classification
should guide requirements across the product lifecycle. Higher-risk functions should require
stronger evidence, safeguards, monitoring and controls for changes and failures. In addition,
this approach could provide greater clarity for autonomous or clinically critical functions that may
require additional independent safeguards and the highest level of evidence and oversight.
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?

Mayo Clinic recommends that FDA consider who is using the GenAI tool and whether they can
understand and evaluate its output, rather than treating all patient-facing GenAI as high risk.
Patient-facing tools can improve access, engagement and understanding and the framework
should preserve those benefits while accounting for differences in expertise and opportunities
for independent verification. Risk should also account for whether a clinician or other qualified
professional is expected to mediate the interaction before the patient acts on the output.

The classification of the device risk level should increase as outputs become more
personalized, time-sensitive, clinically directive and likely to influence patient action. Relevant
considerations include the severity and reversibility of harm if the output is incorrect, whether
the basis and limitations of the output are understandable and whether an opportunity exists for
clinical review before harm could occur. Educational or explanatory content should be
distinguished from individualized recommendations, medication instructions or other outputs
that a patient may reasonably act on without independent clinical review. The clinical
consequence of incorrect output should remain central to this assessment. Patient-facing
functions that provide treatment or other action-directing recommendations should generally
require greater evidence and stronger safeguards than functions designed primarily to explain
or contextualize information.

Relevant safeguards may include clear output verifiability, understandable explanations of
uncertainty and limitations, prompts to seek clinician input when appropriate, mechanisms to
identify urgent or high-risk situations and design features that reduce the likelihood that
informational content is interpreted as direct clinical instruction. For patient-facing functions,
safeguards could also limit the device from independently suggesting therapeutic options, such
as available medications for a condition, unless the user explicitly requests that information.
Safeguards should also address plain-language communication and accessibility across
differing levels of health literacy, disability and language needs. FDA should also maintain
consistency with human factors testing expectations for traditional device software functions
when evaluating patient-facing GenAI-enabled devices with testing that reflects the intended
users and use environment. For higher-risk functions, evaluation should include testing for
hallucinations, unsafe recommendations, safe refusal and appropriate escalation in urgent or
crisis scenarios.

FDA should also avoid equating lack of professional training with inability to meaningfully
engage with clinical information. Patient-facing status alone should not determine risk. Instead,
FDA should consider what the function does, the consequence if the output is incorrect, whether
the patient is likely to act on the information without further review, whether the information is
otherwise readily accessible to the patient outside of the device and whether the device
provides sufficient context, limitations and pathways for verification or clinician involvement. This
approach would account for differences in domain expertise without unnecessarily restricting
patient access to useful clinical information. For patient-facing GenAI-enabled devices, FDA
should also consider post-deployment monitoring as discussed in question 19 for unintended
behavioral effects, such as inappropriate utilization or delayed care because safety depends not
only on whether an output is accurate but also on how patients respond to it in practice.

4. CDRH seeks input on whether and how the distinction between generalist and specialist
physicians might inform the assessment of risk for HCP-facing GenAI-enabled functions. Under
what circumstances, if any, might risk be affected when an HCP who lacks the relevant clinical
specialist knowledge receives information that falls within a specialist area of practice? What
device characteristics or safeguards might mitigate such risks?

Mayo Clinic recommends that FDA assess risk based on the relationship between the
complexity of the task and the competency of the intended user, rather than relying on whether
the intended user is a generalist or specialist. A generalist may be able to safely use a GenAI
tool for some specialist-related tasks if the information is understandable, verifiable and
appropriate to the clinician’s training, role and ability to independently assess the output.

Risk may be higher when the GenAI function provides highly specialized information that the
receiving clinician cannot independently evaluate or challenge. This is especially important
when the output directly influences diagnosis, treatment, medication decisions or other highconsequence actions. In those situations, the tool may begin to substitute for specialist
judgment rather than simply support the clinician. Where a device performs a subspecialty
function, its performance should be evaluated against a standard appropriate to that
subspecialty, even if the intended user is a generalist.

GenAI can also expand access to specialist knowledge, particularly in settings where specialists
are not readily available. Use by a generalist should not automatically be considered higher risk.
FDA should instead focus on the specific task, intended workflow and whether the clinician can
recognize errors, understand limitations, verify the output and know when specialist input is
needed.

Safeguards should reflect the competency required for the task and may include clear intendeduse information, output verifiability, communication of uncertainty, prompts for specialist
consultation and testing with representative users. For higher risk functions, specialist review or
confirmation may also be appropriate. Any risk reduction attributed to human review should be
supported by evidence that users can identify important errors and escalate appropriately. Mayo
Clinic recommends that FDA assess risk based on the competency needed for the specific task
and how the clinician and AI interact in practice with professional title serving as only one part of
that assessment.
Section V: A Competency-Based Approach for Premarket Evaluation of GenAI-Enabled Devices
7. Is the competency-based approach described above, i.e., device benchmarking followed by
clinical confirmation, a useful and appropriate framework for evaluating GenAI-enabled devices?

Mayo Clinic supports the general structure of a competency-based approach that combines
device benchmarking with clinical confirmation. The analogy to how clinicians demonstrate
competency may provide a useful organizing framework for evaluating whether a Gen-AI
enabled device can perform defined clinical tasks, but it should not be extended to equate
demonstrated device performance with physician licensure or credentialing. Licensure or
credentialing apply to human professionals who exercise clinical judgment across a scope of
practice and are accountable for that judgment; evaluation of a medical device should remain
tied to its specific intended use, performance and conditions of use.

A competency-based framework may nevertheless be useful for GenAI-enabled devices
because their inputs and outputs may be broad, open-ended and variable, making exhaustive
premarket testing impractical. Benchmarking can provide a structured means of establishing
whether a device demonstrates the capabilities necessary for its intended use under controlled
conditions, supplemented by clinical confirmation of performance in the relevant context of use.
FDA should define competency at the level of the specific clinical task and the final configured
device. A single GenAI system may perform multiple functions with materially different clinical
consequences and competency requirements and evaluation should therefore be tied to each
device function’s intended population, user, setting, workflow and clinical context. Where a
device performs multiple materially different clinical functions, separate competency
expectations may be appropriate for those functions.

Mayo Clinic also believes benchmarking should be understood as the first stage of evaluation
rather than a substitute for evidence generated under clinically representative conditions. We
emphasize the importance of progressing from controlled testing into real clinical environments,
including shadow deployment, because static or retrospective benchmarks may not capture
workflow effects, user interaction, uncommon failure modes and the variability inherent to
GenAI. Benchmarking itself should be sufficiently narrow and claim-specific to remain
interpretable and should account for reproducibility across repeated runs and reasonable
variations in input.

Mayo Clinic also encourages FDA to clarify how the competency-based approach fits within
existing device software evaluation requirements. FDA should specify how benchmarking and
clinical confirmation relate to verification and validation, human factors and existing clinical
evidence expectations, including when evidence generated under those processes may satisfy
competency-based elements. The framework should also identify the circumstances in which
GenAI-specific evidence is warranted based on the characteristics and risks of the device. Clear
alignment across these requirements would support a more coherent evidence framework,
reduce unnecessary duplication and help sponsors understand the full evidentiary package
expected for premarket review. The nature and rigor of the overall evidence package should
remain proportionate to the device’s intended use and risk.
8. How might the two-axis risk framework described in Section IV be considered within the
competency-based approach described above to help determine the level of evidence needed
for a premarket submission?

Within the staged approach described above, FDA should use the risk characterization
described in response to Question 1 to determine the scope, rigor and clinical relevance of the
evidence needed for each device function. As those risks increase, FDA should require more
demanding benchmarking conditions, prespecified acceptance criteria that address clinically
consequential errors and clinical confirmation that more closely reflects the intended population,
users, workflow and deployment environment. Mayo Clinic’s experience supports calibrating
evidence requirements to the specific function and consequence of error: a readily verifiable
measurement may warrant a substantially different level of clinical evidence than a function
requiring medical judgment or directing a consequential clinical action. For example, a lowerrisk, clinician-reviewed function with readily detectable and reversible errors may be supported
by intended-use specific benchmarking and representative retrospective evaluation, while a
highly autonomous or clinically critical function may require testing across challenging use
conditions, independent adjudication and prospective or otherwise deployment-representative
clinical confirmation studies. The appropriate evidentiary burden should therefore reflect what
the device does in the clinical environment, the consequences if it is wrong and the degree of
competency required for the task.

The two-axis risk framework should, however, serve as a starting point. Other factors can
materially affect whether incorrect output is likely to translate into harm, such as the nature and
independent verifiability of the output, reversibility, time to potential harm, intended-user
expertise and the availability of effective downstream safeguards. In particular, FDA should
distinguish between outputs that augment capabilities already available to clinicians and outputs
that introduce novel clinical information or inferences that clinicians cannot independently verify.

A device that performs a measurement, identifies a finding, or otherwise makes an existing
clinical task more efficient may present lower incremental risk when a representative user can
independently confirm the result and meaningful oversight is demonstrably effective. By
contrast, outputs such as predictions of future disease risk or trajectory may warrant greater
evidentiary rigor when the information cannot be independently reproduced or checked by the
clinician before it influences care. FDA should first determine the inherent risk using the two-axis
framework, then apply relevant contextual risk modifiers and evaluate whether proposed
safeguards meaningfully reduce that risk in the intended use environment. FDA should
distinguish between factors that modify inherent risk and safeguards that mitigate that risk after
the intended use environment is considered.

Where a sponsor relies on a safeguard to support a lower evidentiary burden, FDA should
expect evidence that the safeguard functions as intended. For example, if clinician oversight is
relied upon as a risk control, the sponsor should demonstrate that representative users can
identify consequential errors, understand relevant uncertainty, verify or challenge outputs and
intervene within the available time. The remaining risk should then determine the applicable
benchmarking elements, test conditions and acceptance criteria, as well as the extent of clinical
confirmation required.

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?

Within this framework, Mayo Clinic believes FDA’s proposed benchmarking domains provide a
useful structure for establishing baseline capability. We do not see a need to eliminate or
materially reorganize the proposed domains; rather, several cross-cutting elements warrant
more explicit treatment. Benchmarking should evaluate whether the configured device can
perform the specific clinical task it claims to perform, including clinically relevant failure modes
and boundary conditions. We recommend using representative benchmark sets that include inscope and out-of-scope tasks, scenarios requiring safe refusal and measures of task success,
hallucination, grounding, citation accuracy and retrieval performance. Because GenAI outputs
may vary across repeated runs and semantically equivalent inputs, benchmarking should also
evaluate the consistency of safety-critical behavior across repeated testing and reasonable
input perturbations.

We would retain FDA’s proposed categories but expand them to more explicitly address several
cross-cutting dimensions, including uncertainty recognition and appropriate deferral, human AI
interaction, robustness across repeated and varied inputs and configuration and trajectory
integrity. Where human oversight is relied upon as a safeguard, benchmarking should directly
test whether intended users can recognize consequential errors and intervene appropriately and
in time. Overall human-AI team accuracy alone may not demonstrate that this safeguard is
effective; relevant measures should be tailored to the task and the specific form of oversight
being relied upon, such as error-detection, appropriate override or deferral and time to
intervention. For conversational and agentic systems, benchmarking should also assess multiturn behavior, tool use, persistent state, cybersecurity and cumulative effects across an
interaction. Benchmarking programs should also be designed to evolve as new failure modes
emerge, because static tests may become increasingly susceptible to optimization or “teaching
to the test.” Externally developed standards and benchmark assets may be useful where they
are clinically relevant and fit for the intended use and could provide a common methodological
foundation. Device-specific testing should remain necessary where required to address the
clinical claim, population, workflow and risk profile.

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?
Mayo Clinic believes benchmark validity should be established by demonstrating a clear,
prospectively defined relationship between the benchmark and the specific clinical claim it is
intended to evaluate. Sponsors should define what the evaluation is intended to establish, for
whom, under what conditions and with what degree of certainty, including the relevant
population, setting, outcomes, acceptance thresholds, consequential errors, subgroup
performance, stochastic variability and version-specific configuration. Benchmarking should
remain focused on the clinical task and broad benchmark performance should not be assumed
to establish safe and effective performance for narrower clinical use. FDA should expect
sponsors to explain why success on the selected benchmark is reasonably predictive of
performance on the intended clinical task.

Public and sponsor-developed benchmarks each have limitations that should be addressed
explicitly. Static or widely available tests may become susceptible to saturation, optimization or
“teaching to the test” and benchmark assets should therefore evolve as new failure modes are
identified. Sponsor-developed benchmarks may be appropriate where suitable external assets
do not exist, particularly for specialized intended uses, but FDA should expect prospectively
defined methods and acceptance criteria and safeguards against optimization to the test. For
higher-risk applications, sequestered or held-out evaluation data and appropriately independent
review may provide additional confidence that benchmark performance reflects genuine
capability rather than familiarity with the test. These measures should complement clinical
confirmation in representative use environments.

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?

Mayo Clinic supports FDA’s proposed continuum of clinical confirmation methods and agrees
that a prospective clinical study should not be required in every case. The sponsor should select
the confirmation approach based on the uncertainty that remains after benchmarking, the
clinical consequence if that uncertainty proves meaningful and whether the relevant risks can be
adequately evaluated without allowing unvalidated outputs to affect patient care. Retrospective
evaluation may be sufficient for some lower-risk, clinician-supervised functions or as an initial
screen before further testing, while more consequential, autonomous, patient-facing and
difficult-to-verify functions may require evidence generated prospectively in real clinical
workflows. We encourage FDA to distinguish clearly among these methods. Retrospective or
simulated testing can establish readiness for further evaluation, but may not adequately capture
workflow effects, user behavior, operational variability and other factors that emerge only in
clinical use. Where feasible, the framework should therefore favor progression into real or
clinically representative environments before broad deployment. Benchmarking and clinical
confirmation answer different scientific questions. Benchmarking establishes bounded capability
under controlled conditions. Clinical confirmation determines whether that capability persists
with the intended data pipelines, users, populations, integrations, workflows and mechanisms of
clinical action. Neither should substitute for the other when context materially affects
performance or safety.

Shadow deployment can generate evidence from real patients, users and workflows without
allowing unvalidated outputs to influence care. Where patient exposure is appropriate, staged
deployment may increase operational exposure under prespecified safeguards, monitoring,
stopping criteria, and governance oversight. The design should be justified by the intervention,
ethical considerations, risk profile and remaining uncertainty. The duration and sampling
strategy for clinical confirmation should be driven by the anticipated distribution of real-world
inputs, including the prevalence of the condition, uncommon but clinically consequential
presentations, relevant patient subgroups and foreseeable variation across sites and workflows.
A fixed testing period will therefore not be appropriate across devices. For example, a common
clinical presentation may yield adequate evidence relatively quickly, while a rare disease or
infrequent safety-critical scenario may require a longer evaluation period or complementary
methods. Standardized patient interactions and simulation may remain useful for bounded
questions, such as testing communication, escalation or human factors, but should not
substitute for evidence from representative clinical environments when real-world interaction is
central to the device’s safety and effectiveness.

13. For which clinical domains, device functions, or subpopulations is synthetic data particularly
well-suited, or particularly inadequate, as a supplement to real-world evidence? What
safeguards would mitigate the risk that synthetic data generated by models of the same class as
the device under evaluation reproduces the very performance gaps the evaluation is intended to
detect, particularly for underrepresented subgroups?

Mayo Clinic believes the appropriateness of synthetic data will depend heavily on the clinical
use case, the purpose for which the data are being generated and the characteristics of the
population being represented. Synthetic data may be useful for supplementing evaluation where
real-world data are sparse, difficult to obtain or ethically challenging to collect and may also
support early-stage hypothesis testing, simulation or control-arm development when
appropriately validated. Experience with external and synthetic controls and retrospective trial
emulation suggests that these approaches can be valuable where traditional enrollment is
difficult, placebo assignment is problematic or investigators need an early indication of whether
a question warrants prospective study.

FDA should allow the role of synthetic data to scale with how well it has been validated for the
intended use. Synthetic data can play a larger role when it closely reflects the real patient
population, but real-world data is particularly important for rare conditions, underrepresented
groups or settings with greater clinical variation. We would also caution that highly constrained
synthetic data may become too dissimilar from the original patient population to provide useful
evidence of real-world performance.
Safeguards should be tailored to the specific clinical domain and intended use. FDA should
expect sponsors to characterize how the synthetic data were generated, the relationship
between the synthetic and target real-world distributions and the extent to which clinically
important variation is preserved. Attention should be given to whether synthetic datasets
reproduce or obscure known performance gaps across subgroups, sites, modalities, disease
severity and other clinically relevant factors. Independent comparison with real patient data
should remain important, especially when the synthetic data contributes materially to an
estimate of safety or effectiveness. Mayo Clinic also recommends caution when synthetic data
are generated using models trained on real patient data, because privacy risk and
representativeness can be in tension: constraining generation too aggressively may reduce
clinical fidelity, while generating data close to the underlying population may raise concerns
about whether patient-specific information is retained or reproduced.

For underrepresented subgroups, synthetic augmentation should not be presumed to correct an
evidence gap simply because it increases sample size. Sponsors should demonstrate that the
generating process does not merely reproduce the biases, omissions and smoothing present in
the source data or model. Mayo Clinic has seen examples in which synthetic imaging data
appeared substantially smoother than real patient data, raising concerns about whether
performance measured on those data would generalize to clinical populations. We therefore
recommend that FDA assess synthetic-data use on a case-by-case basis, with safeguards
proportionate to the role the synthetic evidence plays in the submission, the clinical
consequence of error and the availability of real-world data for confirmation. FDA should also
consider developing or recognizing consensus standards for the generation, validation and
documentation of synthetic data used as regulatory evidence, with requirements proportionate
to the role of the synthetic data and its intended evidentiary purpose.

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?

For open-ended GenAI outputs, Mayo Clinic recommends that the comparator and acceptance
criteria be anchored to the specific clinical task, intended use and role the device is expected to
play in practice. The appropriate standard should not default universally to either a generalist or
specialist physician. FDA should consider the level of clinical expertise necessary to perform the
task the device claims to support or replicate. A specialist comparator may be appropriate where
the device is intended to perform a specialty-level function or substitute for specialist expertise,
while a generalist comparator may be appropriate for functions that fall within general clinical
practice. Where an objective clinical reference standard exists, that standard may be more
appropriate than clinician performance alone. Acceptance criteria should similarly be tied to the
current standard of practice and to clinically meaningful performance thresholds for the intended
use. Sponsors should also explain why the selected comparator reflects the care or expertise
the device is intended to support, replace or improve upon.

When the intended use is clinician-supervised decision support, Mayo Clinic believes the
clinically relevant unit of evaluation may be the performance of the clinician and AI together
rather than the AI operating in isolation. This is particularly important for open-ended outputs,
where the value and safety of the system may depend on how the clinician interprets, verifies,
modifies and rejects the output within the workflow. Real world performance depends not only
on model accuracy but also clinician interaction and workflow integration.

Human-AI team performance should therefore be assessed where the authorized use assumes
meaningful clinician review, while device-alone performance remains important where the
system acts autonomously or where clinicians cannot realistically detect and correct
consequential errors before they affect care. Where human review is relied upon as a risk
mitigation, the FDA should expect evidence that intended users can recognize and correct
important errors. This distinction also helps avoid treating a broad, general-purpose model as
equivalent to a purpose-built and validated system for a specific clinical function simply because
both can generate a plausible response.

16. Should independent third parties be involved in some or all aspects of a competency-based
approach, including device benchmarking and clinical confirmation? If so, in what ways might
qualified, independent third-party participation contribute to this approach, and what
qualifications and independence criteria should apply? Are there aspects of the assessment for
which third-party involvement would be impractical or inadvisable? What safeguards or program
design features would be critical to prevent third-party participation from limiting competition or
preventing innovation?

Mayo Clinic supports a targeted, risk-based role for independent third parties in the assessment
of GenAI-enabled devices, including circumstances in which FDA may rely on third-party
assessments rather than CDRH’s independently reviewing all the underlying benchmarking or
clinical confirmation data. Such an approach could expand access to specialized expertise,
testing infrastructure and diverse datasets while allowing FDA to focus its review on areas of
greatest clinical and regulatory significance. However, the extent to which FDA relies on a thirdparty assessment should be proportionate to the risk of the device function, the maturity and
standardization of the assessment methodology and FDA’s ability to oversee the quality and
consistency of the assessment.

Third parties may be particularly well suited to conduct standardized benchmarking or other
assessments for which methods, performance criteria and reporting requirements can be clearly
specified. FDA could establish expectations for the methodology and evidence required and rely
on qualified third parties to conduct or validate the assessment. FDA should retain appropriate
oversight of the program and responsibility for regulatory determinations, including the ability to
conduct additional review when warranted. For higher-risk, novel or highly autonomous
functions or where assessment methods are not well established, greater direct FDA review
may be appropriate.
Clinical confirmation presents additional considerations. GenAI performance can be materially
affected by local workflow integration, configuration, user interaction and other components
layered around the underlying model, such that the same baseline capability may perform
differently across clinical environments. Health systems, sponsors or other organizations with
appropriate expertise, governance and access to the intended-use environment may therefore
be better positioned to evaluate some aspects of clinical confirmation.

Section VI: Postmarket Monitoring for GenAI-Enabled Devices
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?

A total product lifecycle approach is supported by Mayo Clinic, under which CDRH may accept a
certain degree of premarket uncertainty for select GenAI-enabled devices when the remaining
uncertainty can be effectively managed through implementation guardrails and postmarket
monitoring. This approach may be most appropriate where errors can be reasonably detected
and reversed before they result in serious harm, particularly when clinician review occurs before
the output is acted upon. Manufacturers and healthcare institutions deploying the devices
should be able to rapidly limit, pause and roll back the device if safety or performance concerns
are detected. Postmarket monitoring should complement premarket evidence and should not
substitute evidence necessary to prevent serious or irreversible harm before detection and
intervention are feasible. A minimum demonstration of safety and effectiveness in clinical
conditions should still be required.

A greater reliance on postmarket monitoring should be conditioned on a monitoring plan that is
operational when the device is deployed. Monitoring should be proportionate to the device’s risk
and intended use. Depending on the device, relevant measures may include product
performance, drift, subgroup performance, adverse events and near misses, GenAI-specific
failure modes, user behavior, workflow effects and clinical outcomes. Monitoring programs
should also include appropriate thresholds, human review and escalation processes, and clear
authority to contain, suspend or roll back the device when needed.

The program should establish predefined performance and safety thresholds, named
accountable owners, human review of significant or novel signals, governance escalation,
corrective and preventive action processes, regulatory reporting where applicable and clear
authority to contain, suspend or roll back the device. Monitoring intensity and cadence should
increase with clinical risk and autonomy, including continuous or near-real-time safety-signal
monitoring when harm could occur rapidly. Mayo Clinic has previously emphasized that real13
world monitoring should be risk-informed, integrated into institutional quality systems and
capable of linking algorithm behavior, workflow integration and patient outcomes .1

This pre-to-postmarket evidence shift would not be generally appropriate for devices where
harm could occur before a problem can be detected or corrected. It also would not be
appropriate where reliable telemetry, outcome linkage, representative real-world data, rapid
containment and adequately resourced governance are unavailable. These devices should
require stronger premarket evidence, potentially including more rigorous clinical confirmation
and independent evaluation, instead of relying predominantly on postmarket detection of
failures.

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?

Mayo Clinic supports a framework for postmarket evaluation that combines periodic
reassessments with event-triggered evaluations and treats monitoring as an ongoing quality
improvement process. Monitoring should extend beyond model-level drift, including clinical
outcomes, workflow impact, user behavior, modes of failure and changes in both the deployed
system and the clinical environment. Re-benchmarking should be dynamic and evolve over
time. New failure modes, clinician feedback and real-world safety signals should be
incorporated into future benchmarking, so reassessment reflects emerging risks.

Cadence and intensity of monitoring should be proportionate to the risk and severity of potential
harm. Reassessment should be triggered by safety signals, model updates or version changes,
changes in model settings or capabilities, other meaningful system changes, changes in clinical
use or patient populations, input or concept drift, unexpected failures, workflow changes and
evidence that performance is departing from the validated state. For devices that rely on thirdparty foundation models, upstream model changes discussed in question 24 should also be
treated as potential triggers for reassessment when they could affect the device’s clinical
performance.

The need for reassessment should depend on whether a change could meaningfully affect
clinical performance even when the technical change itself appears small. For higher-risk
devices, manufacturers and deploying institutions should establish predefined escalation criteria
and clear authority to pause or discontinue use when safety thresholds are crossed.

20. Please comment on whether the proposed approaches to postmarket monitoring can be
facilitated by machine-based supervisory agents. What considerations, including the evaluation
Mayo Clinic response to U.S. Food & Drug Admin., Request for Public Comment: Measuring and
Evaluating Artificial Intelligence-Enabled Medical Device Performance in the Real-World, Docket No.
FDA-2025-N-4203 (2025) available at https://www.regulations.gov/comment/FDA-2025-N-4203-0084.
and reliability of the supervisory agent itself, should CDRH take into account for such an
approach?

Mayo Clinic believes that machine-based supervisory agents can help facilitate postmarket
monitoring, particularly where functions benefit from continuous and high-volume surveillance in
areas such as data collection, anomaly and drift detection, monitoring system behavior,
workflow performance and identification of cases that will need further investigation. Automated
surveillance may be useful when monitoring must occur at scale, but it should be implemented
in a manner that identifies changes in technical signals with clinical performance and outcomes.
This becomes particularly important when post-deployment failures occur because of changes
in the model, data, workflow, integrations or actual use.

CDRH should not treat supervisory AI as a substitute for human and clinical oversight. The
supervisory mechanism should be separately validated for its monitoring function, with defined
performance expectations, known limitations, version and configuration controls, auditability and
clear thresholds for escalation to human review. The performance of the supervisory AI should
also be monitored over time. Machine-based monitoring should also remain connected to
clinician feedback, near misses and clinical outcomes so that failures missed by automated
surveillance can still be identified. This helps avoid creating a system in which one AI system is
relied upon to validate another without independent oversight.

21. What roles might clinicians, healthcare institutions, professional societies, standards-setting
bodies, and other stakeholders appropriately play in postmarket monitoring, and how can these
roles be structured without diffusing manufacturer accountability?

Manufacturers should remain responsible for the safety and effectiveness of the regulated
device, including the adequacy of the postmarket monitoring program, investigation of productlevel safety signals and corrective action. Healthcare institutions can contribute information that
manufacturers may not independently observe, including local validation, deployment-level
telemetry, workflow effects, user behavior, clinical outcomes and incident detection. Clinicians
can provide in-context feedback, identify unexpected failures and near misses and help
determine the clinical significance of observed performance issues. Health systems should be
able to use existing governance structures to document ongoing oversight without creating
burdensome reporting requirements for routine internal monitoring and governance activities.

Where appropriate, professional societies and standards-setting bodies may help develop
common performance measures, monitoring practices and data standards. Other stakeholders,
including foundation-model developers, should provide information necessary to understand
material changes that could affect device performance. These contributions should be
structured through clearly assigned responsibilities, information-sharing expectations and
incident resolution pathways, while avoiding any transfer of the manufacturer’s core regulatory
accountability to clinicians or deploying institutions. Manufacturer accountability should remain
clear even as more parties contribute data, monitoring and oversight.
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?

Mayo Clinic recommends that FDA scale re-evaluation requirements according to a
modification’s plausible effect on clinical behavior and the evidence supporting the validated
state, rather than the amount of code changed. Not every software, model or configuration
change should require the same level of re-benchmarking or a new premarket submission.
Changes with little expected effect on validated performance or clinical risk may be
appropriately evaluated and managed through the manufacturer’s quality management system,
with the scope of testing proportionate to the nature and potential impact of the change.
Changes that could alter clinically relevant behavior, degree of autonomy, performance in the
intended population or the consequences of an incorrect output should trigger more extensive
evaluation. Changes to intended use or other modifications that meet applicable thresholds for a
new premarket submission should continue to follow FDA’s existing requirements.

FDA should also consider the full deployed configuration when determining whether a change is
material. Relevant modifications may include changes to the foundation-model version,
reasoning or inference settings, tool-use capabilities, orchestration, compute levels or
expansion into new clinical functions or use cases. The amount of re-benchmarking should
reflect how likely the modification is to affect previously validated performance, with more
extensive testing for changes that increase autonomy, broaden scope, reduce independent
verifiability or could have greater clinical consequences.

Foreseeable modifications may be appropriate for inclusion in a PCCP when the types of
changes, methods for evaluating them, acceptance criteria and conditions requiring further
regulatory review can be defined in advance. This could provide flexibility for lower-risk or
clinician-supervised functions to evolve without unnecessary resubmission while maintaining a
higher threshold for autonomous or otherwise potentially significant changes to safety or
effectiveness. FDA should encourage predefined reassessment triggers so manufacturers can
distinguish routine lifecycle updates from modifications that require more substantial validation
or premarket review.

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?
Mayo Clinic recommends that FDA requires device manufacturers to have procedures in place
to identify, document, assess and manage changes to the foundation model and configuration
used in the deployed device, including version history, relevant settings and other components
that could affect clinical performance. Manufacturers should have mechanisms to identify and
assess third-party model changes and obtain timely information about material updates, known
limitations, safety guardrails and changes in performance to the extent such information is made
available by the foundation model developer.

Manufacturers should also evaluate how sensitive the final device is to changes in the
underlying foundation model before deployment. Testing across different model versions or
comparable foundation models could help determine whether changes at that layer materially
affect the behavior of the final product and identify when additional validation is needed. FDA
should allow foreseeable changes to be managed through structured change-control
mechanisms, including a PCCP where appropriate with predefined testing and revalidation
triggers. As we have previously mentioned in question 19, material changes to an underlying
foundation model, including version, settings or capabilities, should serve as triggers for
reassessment and, where appropriate, re-benchmarking or revalidation of the deployed device.

Contracts with foundation-model developers should support timely notification and access to
relevant change information, while manufacturers and deploying health systems should retain
the ability to pause, restrict or roll back the device if an upstream change creates safety or
performance concerns. FDA should make clear that responsibility for demonstrating continued
safety and effectiveness remains with the device manufacturer even when the underlying
change is initiated by a third party.

Section VII: Other Topics
25. Would voluntary Foundation Model MAFs be practical for foundation model developers to
provide and to keep current, and what content might they include? Given that participation
would be voluntary and that model developers may have limited incentive to disclose safetyrelevant information, what would make such a program sufficiently useful for premarket review?
Are there alternative mechanisms CDRH should consider for obtaining information about
underlying foundation models?

Mayo Clinic believes that voluntary Foundation Model Master Files (MAFs) could be a useful
mechanism for improving CDRH's visibility into foundation models that support multiple
downstream medical devices. A well-designed MAF could reduce duplicative information
requests and provide a standardized, confidential source of safety-relevant information that
authorized device sponsors can reference during premarket review. A Foundation Model MAF
should not, however, be treated as FDA approval or certification of the foundation model itself,
nor should it substitute for evaluation of the final configured device for its intended clinical use.
The device manufacturer should remain responsible for demonstrating the safety and
effectiveness of the device as deployed.
To be useful for premarket review, an MAF should be standardized, version-specific and
maintained over time. Useful content could include model and version identity, safety-relevant
information regarding training and evaluation provenance where relevant and reasonably
available, healthcare-relevant limitations and performance evidence, known failure modes,
subgroup performance, applicable safety policies, security controls, and guardrails, version and
change history, update and incident processes and deprecation and continuity plans.
Information about training data provenance is particularly important where it is feasible to help
identify potential overlap between model-development data and downstream evaluation
datasets and to assess whether benchmark performance would be affected by previous
exposure to that data. CDRH should focus MAF expectations on information material to the
safety and effectiveness of downstream devices rather than requiring exhaustive disclosure of
model-development or training details that are not clinically relevant or reasonably available.

The usefulness of a voluntary program will depend on participation and maintenance. A
confidential, reusable MAF could create a meaningful incentive to participate by allowing a
foundation-model developer to provide a common set of information to FDA once and permit
authorized downstream sponsors to reference that information across multiple premarket
submissions. For the program to remain useful, however, CDRH should establish minimum
content and maintenance expectations, including version history and timely notification of
material safety-relevant changes, with sufficient information to understand what changed and its
potential implications for downstream uses.

CDRH should treat Foundation Model MAFs as one component of a broader evidence
framework. Device manufacturers should remain responsible for identifying and documenting
the foundation model, version, and material configuration incorporated into the device,
maintaining appropriate provenance and version controls and having mechanisms to be notified
of or otherwise detect meaningful upstream changes. Sponsors should assess whether such
changes affect device performance and respond through risk-proportionate regression testing,
additional validation, use restrictions, rollback or other appropriate controls. Where voluntary
MAF participation is incomplete, CDRH could supplement the program with standardized
disclosure expectations for device sponsors, structured information requests and other riskbased mechanisms for obtaining information when sufficient information about a foundationmodel dependency is unavailable.

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?

Mayo Clinic believes agentic GenAI-enabled devices warrant additional premarket and
postmarket considerations because risk arises not only from the correctness of an individual
output, but from the system’s ability to plan, sequence and execute actions over time. Agentic
capability should not, however, be treated as a risk category by itself. We recommend that
FDA’s risk-based approach should instead account for the authority actually granted to the
system, the types and clinical consequences of actions it can take, their reversibility, the
opportunity for meaningful human review before harm occurs, workflow context and patient
impact. The rigor of evaluation and oversight should scale to both the system’s degree of
functional authority and the clinical criticality of the actions it can take.

For agentic systems, premarket evaluation should assess the complete action trajectory,
including how errors may propagate or compound across successive steps. Sponsors should
clearly define the system’s authority boundaries, including what information and systems it may
read, what records or systems it may write to or modify, what orders or other actions it may
initiate or execute, which patients or populations it may act upon, and which actions require
separate human authorization. Acceptance criteria should address the tools and actions the
system is permitted to use, least-privilege access, memory and state boundaries, verification of
external tool outputs, reconstructable action logs, prompt-injection and adversarial resilience
and the cumulative clinical consequences of multi-step behavior. For irreversible or highconsequence actions, FDA should expect clearly defined human authorization checkpoints or
other safeguards commensurate with the clinical risk and manufacturers should demonstrate
that those controls function effectively under representative conditions.

We also recommend that FDA scale oversight according to action authority, irreversibility and
potential clinical consequence. Clinician involvement should only be treated as a meaningful risk
mitigation when the clinician has sufficient information, time and authority to independently
review, modify, reject and stop the system’s action before it affects patient care.

Postmarket oversight for agentic devices should likewise be risk-proportionate and oriented
toward the actions the system is authorized to take. Monitoring should capture not only model
performance, but also tool use, action sequences, overrides, failures, unexpected downstream
effects and clinical outcomes, with predefined thresholds for intervention, restriction and
suspension. Continuous or near-real-time monitoring may be appropriate where an agent can
take high-acuity, time-sensitive or otherwise consequential actions, but should not be a default
expectation for every agentic function.

Expansion of tool access, writing privileges, persistent memory, patient scope and autonomy
should be treated as a potentially material change requiring reassessment. Changes that
broaden the system’s tool-use capabilities or extend it into additional use cases should likewise
trigger re-evaluation of whether prior evidence remains adequate. Given the limited clinical
evidence for agentic systems, early deployment of higher-risk agentic systems should remain
constrained, observable and reversible until safety and clinical effectiveness are demonstrated
under representative conditions. Strong postmarket monitoring should not substitute for
adequate premarket evidence where an erroneous action could cause serious harm before it
can reasonably be detected, interrupted or reversed.

Conclusion
In conclusion, Mayo Clinic supports a risk-based, total product lifecycle approach to the
regulation of GenAI-enabled medical devices that promotes responsible innovation while
protecting patient safety. Regulatory expectations should be proportionate to clinical risk, degree
of autonomy and the effectiveness of safeguards with evaluation focused on the final configured
device within its intended clinical workflow. Premarket benchmarking and clinical confirmation
should establish task-specific competency, while postmarket monitoring and change controls
should ensure that safety and effectiveness are maintained as devices, models and clinical
environments evolve. As GenAI-enabled devices become more autonomous or capable of
consequential clinical actions, expectations for evidence, human oversight monitoring,
reversibility and accountability should increase accordingly.

Mayo Clinic appreciates FDA’s leadership in advancing the responsible regulation of GenAIenabled medical devices. We remain committed to working with FDA and the broader
healthcare community to advance these shared goals and to uphold our mission of placing the
needs of the patient first. To discuss further, please feel free to reach out to me, Micky Tripathi,
Chief AI Implementation Officer at Tripathi.Micky@mayo.edu.

Sincerely,

Micky Tripathi
Chief AI Implementation Officer
200 First Street SW
Rochester, MN 55905