Aidoc

See attached file(s)

October 19 , 2026

Re Docket No. FDA-2026-N-7874

Subject: Considerations for the Regulation of Generative AI-Enabled Medical Devices:
Discussion Paper and Request for Feedback

Dear FDA Digital Health Center of Excellence:

Aidoc appreciates the opportunity to comment on FDA/CDRH's Considerations for the
Regulation of Generative Al-Enabled Medical Devices discussion paper. As a pioneer in clinical
AI and a developer of FDA-cleared, multi-indication, foundation model–based software
deployed in health systems across the United States, Aidoc has extensive experience bringing
AI-enabled devices through FDA regulatory process, integrating them into clinical workflows,
and monitoring their performance in real-world use. We are also developing additional
generative AI devices, and we bring that combined perspective to this discussion.
We believe the need for clinical AI is real and urgent based on present U.S. diagnostic error
totals; generative AI can be designed to address challenges. Diagnostic errors across categories,
are estimated to contribute to nearly 370,000 deaths and 430,000 serious disabilities annually in
the United States (Newman-Toker et al., BMJ Quality & Safety, 2024), and clinician shortages
continue to strain access to timely care, particularly in rural and underserved communities.
Specifically, we are at an inflection point with our Generative AI technology given its broad
function can address real-world clinical needs. Devices can draft, summarize, and communicate
across a clinical encounter, extending AI from specific, narrow tasks to broader and more
holistic clinical evaluations. Clear, fit-for-purpose regulatory expectations will shape both how
quickly patients benefit and how far clinicians can trust these tools impacting adoption pace.
Our comments are in two parts:
-​ Part A presnts our general perspective;
-​ Part B includes comments related to specific sections of the FDA discussion paper where
we have something to add.
Please note, we do not address every question. Our experience is primarily in medical imaging,
so many of our examples come from that domain, although the principles may apply more
broadly.
Part A: General Perspective
Fit generative AI into existing device regulation wherever possible. The existing medical
device framework already provides many of the mechanisms needed for most generative
functions: intended use, risk-based classification, special controls, quality system requirements,
the Multiple Function Device Products policy, and Predetermined Change Control Plans
(PCCPs). We believe new expectations should address novel GenAI-related gaps within existing
frameworks rather than create a parallel regime wherever possible.
Start general, and become specific over time. Generative AI tools can vary widely in function,
users, risk, and safeguards. For example, a patient-facing conversational tool that can be used to
ask questions about their specific scan and a draft set of preliminary findings that must be
reviewed by a radiologist before signature on their final report, may share the same underlying
foundational model architecture, but they differ tremendously in how the information and output
are used and how errors are caught and communicated. No single set of requirements will fit
both because they differ in underlying intended use and design controls, even though both
methods are possible within the same foundational model. We encourage CDRH to begin with
general, risk-based principles and to develop more specific guidance for categories of devices, or
specific-regulations, as experience accumulates.
Regulate the intended use, not the technology. Oversight should follow a product's device
functions and their outputs. Devices built on foundation models that produce structured, bounded
outputs directly aligned with existing regulatory pathway purposes, should not be drawn into
broad GenAI-specific requirements simply because of their architecture. Functions that do not
meet the definition of a medical device should remain subject to appropriate manufacturer
oversight, including risk management and quality controls, without necessarily being subject to
device-specific regulation. Where a function introduces a new medical intended use beyond
established regulatory pathways, it should be assessed on its own merits to determine the
appropriate regulatory approach
Generative AI with clinical impact outside device oversight needs governance too. In our
view, the greatest risk today lies outside the current medical device framework. Only a portion of
the generative AI functionality (i.e., device Clinical Decision Support (CDS)) used in clinical
care is regulated as a medical device. The vast possibilities of non-device CDS, create unique
risks. For example, a general-purpose chatbot that a clinician asks how to help select a
clinically-aligned imaging study, , or a tool that drafts the final summarized assessment and plan
of a clinical note, can shape care but may have limited regulatory expectations. Not every such
tool should be a medical device, but tools with real clinical impact should still be subject to
appropriate governance. A consistent, risk-based approach aligned with the clinical decision
support criteria, would help ensure patient protection is driven by clinical impact rather than
regulatory classification alone. Therefore, we recommend that the FDA’s Clinical Decision
Support Guidance be updated with numerous GenAI specific examples to ensure regulatory
expectations remain clear.
Support to CDRH’s competency-based approach: In line with FDA’s competency-based
approach, not every variation in output should necessarily require individual validation, provided
that the relevant clinical domains are adequately evaluated. CDRH's competency-based approach
draws on how clinicians are credentialed. Clinicians are not tested on every case, every patient
class or demographic, or every clinical scenario they will see. Instead, competence is established
on representative domain-based evaluations, as confirmed in supervised practice, and then
maintained through ongoing credentialing and evaluation metrics, such as peer review of a
portion of studies, and through escalation when something falls outside their expertise.
GenAI-enabled devices should be held to the same logic: evaluated on domain-level functions
across cases from representative intended use settings, and then compared with real-world
clinician performance if appropriate for the claim, and then have its performance monitored over
time for samples of interest, rather than expected to validate every possible output scenario in
advance.
Proportionate evidence. Evidence should be proportionate to risk. Bench testing, including
automated evaluation tools to assess the real-world data, should be used wherever possible. From
there, clinical confirmation focused evaluations should be reserved for assessing the open
domain-level questions that standard bench testing cannot answer. Real-world data should
remain the primary basis for evaluation, with synthetic data as a per case justified supplement.
Clear roles. We believe effective AI oversight requires a clear allocation of responsibilities:
product validation and monitoring should remain within the manufacturer’s quality system,
under FDA oversight, while healthcare organizations and clinicians remain responsible for local
implementation, governance, and clinical decision-making. Manufacturer transparency regarding
product performance, including changes over time and relevant limitations, is essential to
enabling healthcare organizations to make informed decisions about local adoption and use.
Third-party validation or certification should remain voluntary and should not gate, condition, or
substitute for FDA review.
Predictable change control. We recommend that change-control requirements focus on
modifications that may materially affect a device’s safety or effectiveness, rather than routine
customization or changes without clinical significance. The extent of re-evaluation should be
proportional to the potential clinical impact, with FDA clarifying which changes can be managed
within the quality system, covered by a PCCP, or require new premarket review.

Part B: Responses to the discussion paper

Section IV: Risk framework
General comments. We support the two-axis framework as a heuristic. To keep regulation
predictable, CDRH should anchor it to existing classification regulations, special controls where
they apply, and the software as a medical device (SaMD) risk categorization FDA already uses,
and from there, apply it to generative functions that do not fit currently regulatory pathways.
Risk should also follow the impact on clinical management. The downstream effects associated
with the device outputs, may significantly elevate risk depending on how errors may influence
the end user. We therefore recommend that the framework explicitly consider clinically
meaningful domains and the consequences of errors within those domains. While the proposed
heuristic provides a valuable starting point, clinical risk is inherently nuanced, and more tailored
guidance for specific device categories may be needed to support consistent and proportionate
regulatory determinations.
Question 1 (additional dimensions). We recommend keeping the two axis approach while
incorporating the factors raised in Question 1 into the assessment to support a more informed
determination on where a function sits within the framework. Alongside downstream safeguards,
time pressure, and traceability, these should include the reversibility of harm and how quickly
and reliably an error is detected and communicated. The device's position within the clinical
workflow is particularly important. For example, a radiologist reviewing a set of AI generated
preliminary findings for their report before signing a report, can catch an error before the report
reaches the ordering clinician, reducing device risk. Risk assessment should be based on clearly
defined and, where feasible, quantifiable criteria that account for device design, intended users,
and workflow integration. Safeguards such as qualified-user review and AI explainability
features that link generated statements to their supporting sources may further enable effective
error detection and mitigation.Therefore, the heuristic is relevant but there should be clear
take-aways on how a manufacturer can implement specific safeguards to moderate a function's
position on axes.
Question 2 (directiveness). We agree that directiveness depends on the substance and context of
an output, not its wording, and that disclaimers alone do not reduce risk. Consistent with
established regulatory principles, risk should be assessed in the context of the device's labeled
intended use, performance claims, and workflow, with domain-level considerations incorporated
where appropriate for generative functions. This principle should apply equally to all GenAI
tools within healthcare settings.
Questions 3 and 4 (intended users). We recommend that FDA assess device risks in the context
of the intended user and clinical workflow, without unnecessarily restricting established clinical
roles. Decisions about which clinicians are authorized to make diagnostic and treatment
decisions are governed by professional licensure, scope of practice, and healthcare institution
policies, not by device clearance status alone. FDA should focus on ensuring safe use through
appropriate labeling, training, and interface safeguards, rather than presuming that use by
relevant and qualified non-specialists (per their scope of practice) is inherently higher risk.
Restrictions on intended users may be warranted in situations where specialist expertise is
required for safe use and cannot be adequately addressed through other established controls.
Given this, we suggest distinguishing two kinds of non-specialist user, because the risk and the
fitting controls differ:
Non-specialists who already interpret the information and act on it before specialist review.
Where a non-specialist already interprets information and makes clinical decisions as part of the
standard of care, a generative function that supports that decision does not necessarily introduce
new reliance or a new workflow. In these circumstances, the usual controls for assistive devices
should apply, tailored to the intended user and function. These may include labeling that
identifies the intended non-specialist user and the preliminary nature of the output, appropriate
clinician review before action, traceability of generated statements to their sources, and
evaluation of human-AI team performance against the care the user would otherwise provide.
Risk should be assessed in the context of the labeled intended use and workflow, including
relevant downstream specialist review.
Non-specialists who would not otherwise interpret the information. An emergency physician
receiving an AI-generated interpretation of a brain MRI, for example, may not routinely interpret
this type of study and may lack the expertise to independently verify all potential findings.
However, extending AI support to non-specialists can also improve care by enabling them to
make more informed and timely decisions, particularly when specialist interpretation is not
immediately available. The key distinction is whether the AI function supports a decision within
the user's existing scope of practice or enables interpretation beyond their usual expertise. Where
the latter applies, safeguards should be proportionate to the intended use and may include
limiting outputs to specific findings or bounded clinical decisions aligned with the user's scope
of practice, rather than providing a comprehensive interpretation beyond their qualifications. The
device should also support a clear statement of what was and was not evaluated (Element S.2),
communicate uncertainty in actionable terms (Element S.3), and provide appropriate user
training as a condition of use.
Escalation (and Question 6). Where escalation is part of the intended workflow, the
manufacturer should prespecify what triggers it, such as a time-sensitive finding, low confidence,
a finding outside the function's validated scope, or disagreement between the output and the
user's assessment, together with the route to the specialist and the expected timing. Design
controls and postmarket monitoring tools could also account for intended user level restrictions
and help identify any differences in reliance, escalation, or outcomes across user roles, with
appropriate mitigation through labeling, training, or design modifications where needed.

Section V: Competency-based premarket evaluation
General comments. We support benchmarking followed by clinical confirmation, and CDRH's
recognition that clinical confirmation need not require a prospective study in every case.
Following the credentialing logic in Part A, evaluation should rest on representative,
risk-weighted samples with prespecified acceptance criteria at the domain-level, not on
validating every possible output. Particularly after initial marketing authorization, much of the
evidence for a generative function can come from retrospective bench testing, with clinical
confirmation focused on what bench testing cannot answer.
Questions 7, 8, 9 and 11 (structure and level of evidence). Generative report drafting in
imaging illustrates how evidence can be divided across three levels. Automated bench testing
where feasible, can be used to assess properties at scale on every case: reproducibility (the same
study processed repeatedly yields drafts with the same clinical meaning), robustness (for
example, to missing prior studies or a different order of inputs), and internal consistency
(laterality consistent throughout, measurements and units coherent, required sections present).
Expert adjudication on a representative sample establishes whether drafts are clinically truthful,
grading errors by type and clinical significance. Clinical confirmation is then a one-time
evaluation in a representative clinical environment, establishing whether the intended workflow,
including the human reviewer, keeps errors from reaching patients. The function's position on the
risk framework should determine the depth of each level (Question 8).
Question 10 (benchmarks). Manufacturer-developed benchmarks could serve as a primary
evaluation approach, with credibility supported through prespecification, sequestered internal
test sets, and FDA review. Automated evaluation tools, including model-based graders, should be
accepted where fit for purpose.
Questions 12 and 13 (synthetic data). Real-world data should remain a central basis for
evaluating performance in the intended-use setting, particularly because, as CDRH notes, data
generated by models of the same class may reproduce the gaps an evaluation is intended to
detect. Synthetic data can complement this evaluation and may be particularly valuable for stress
testing and systematically probing specific failure modes that are difficult to isolate or adequately
represent in real-world datasets. For example, perturbation testing can introduce controlled
variations in CT inputs, such as motion, artifacts and changes in contrast timing to assess
robustness and identify conditions under which performance degrades. Synthetic data may also
help explore rare presentations or underrepresented subgroups where real-world data are limited,
provided its relevance to the intended-use population is established. The appropriate balance
between real-world and synthetic data should therefore depend on the evaluation objective, with
synthetic testing used to complement, not automatically substitute for, evidence of performance
under representative clinical conditions.
Questions 14 and 15 (comparators). We support comparing performance with the care likely to
occur without the device, and evaluating human-AI team performance for assistive devices. For a
drafting function, the relevant question is how the radiologist's final report compares with and
without the AI draft, not how the AI draft alone compares with a clinician panel. In real-world
data, same case unaided/aided approaches are not practical, but broader assessment of
unaided/aided performance across different cases aligns well with real-world evidence needs.
Question 16 (third parties). We do not support third-party validation or certification bodies
whose determinations would gate, condition, or substitute for FDA review or the manufacturer’s
quality system. Our concern is not with independence but with what a certificate would
represent. A third-party testbed captures performance at a single point in time, on a dataset that
cannot reflect each site’s scanners, protocols, and case mix, and for a model version that will
change under its PCCP. A report-drafting device certified on a sequestered academic dataset may
perform differently at a community hospital with older equipment and low-dose protocols, while
the certificate continues to signal independent validation of a version no longer in use. Fixed
benchmarks also lose value with reuse, and for open-ended outputs they tend to reward similarity
to reference text rather than clinical correctness.
The practical risk is that a certificate adds a step to review without adding information FDA does
not already receive. Even if framed as voluntary, a recognized certification quickly becomes the
expected submission element, which raises cost and time for sponsors and creates a false sense of
security for users and reviewers. We would therefore ask that any third-party role be voluntary,
non-exclusive, and without authority to approve or condition market authorization.

Section VI: Postmarket monitoring and change control
General comments. Postmarket monitoring should complement premarket review, not replace
it. Product-level monitoring belongs within the manufacturer's quality system and existing
regulatory obligations: the manufacturer knows the model's design and limitations, controls its
updates, and can see aggregate performance across deployments, including drift or subgroup
patterns that a single site may not detect. Healthcare organizations and their clinicians retain
responsibility for clinical care and govern local use, informed by the performance information
manufacturers make available. As with clinician peer review, ongoing monitoring should rely on
sampling and targeted review rather than re-validating every output.
Question 18 (premarket uncertainty). Greater reliance on postmarket evidence is justified only
where monitoring is operational at launch, can detect clinically important failures before they
become widespread, and enables timely, effective corrective action. Importantly, sponsors should
demonstrate not only the ability to detect performance degradation, but also the availability of
actionable interventions capable of restoring acceptable performance.It should be limited to
lower-risk functions and should not substitute for premarket evidence for action-taking,
high-consequence, or irreversible functions. Generative functions whose outputs enter clinical
documentation, such as report drafting, should still require premarket evidence of performance
and safety, although not necessarily a prospective study.
Question 20 (supervisory agents). Machine-based supervisory agents may support a
manufacturer's monitoring, provided they fit for purpose, monitored for their own drift, and not
the sole safeguard.
Question 21 (roles). Roles should follow capability without diffusing responsibility.
Manufacturers provide product-level monitoring and transparency; healthcare organizations
select products, integrate them into workflows, ensure use within labeling, review the
performance information provided, determine clinical value and decide whether to expand,
restrict, or discontinue use; clinicians review outputs and make clinical decisions.
Questions 22 and 23 (change control). The bench testing that supported the device's
authorization, whether through 510(k), De Novo, or PMA, should be the baseline for evaluating
modifications and device-level performance. A PCCP should be able to prespecify the
bench-testing protocol and acceptance criteria that every change must pass, rather than
enumerate each minute change. Where an authorization covers a broad set of outputs, change
control can be organized by domain and claim, so performance is demonstrated across each
changed domain without re-testing every parameter.
Question 24 (third-party models). Useful mechanisms include pinned model versions with no
silent updates, contractual advance notice of changes, and re-benchmarking before a changed
model is deployed.

Section VII: Foundation Model Master Files and agentic systems
Question 25 (Foundation Model MAFs). We support voluntary Foundation Model MAFs,
provided participation remains optional, and recommend that the program be available equally to
manufacturers that develop their own foundation models, for reference across their own
submissions. An MAF should support, not replace, the manufacturer's own validation for its
intended use.
Question 26 (agentic systems). CDRH should apply its Multiple Function and device software
function policies consistently for any such systems. Agentic tools that coordinate workflow
around cleared devices, such as routing a flagged case to the right team, should not become
devices for that reason unless they control a device or alter device outputs. Conversely,
diagnostic functions should not fall outside oversight because they are delivered through a
workflow or agentic layer. For generative tools outside device oversight that still carry
meaningful patient safety risk, such as those that generate patient-specific diagnostic or treatment
recommendations or provide clinical advice directly to patients, HHS should consider
proportionate oversight through appropriate existing authorities. Moreover, FDA CDS guidance
should be updated with GenAI specific examples to help clarify function-based classification
determinations.
Conclusion
Generative AI can help clinicians deliver faster, more accurate care, if regulation fits the
technology to what already works, focuses on functions and clinical meaning, and governs the
generative tools that shape care today without oversight.

Aidoc thanks CDRH for its thoughtful engagement and welcomes the opportunity to continue
working with the Agency.

Sincerely,

Amalia Schreier, Chief Regulatory and Legal Officer, Aidoc
Liron Bar Yaakov, Senior RA & QA Director, Aidoc
Quentin Moore, PhD, Director Regulatory Affairs, Aidoc
Jesse M. Ehrenfeld, MD MPH, Global Chief Medical Officer, Aidoc