Medical Alley

Please find attached comments by the Medical Alley Artificial Intelligence Task Force.

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

Introduction

Medical Alley is an association comprised of over 800 member organizations that represent
the entire healthcare ecosystem. Medical Alley includes many medical device
manufacturers, from leading multi-national companies to start ups. The companies
interact daily with FDA CDRH in the regulation of medical devices. Medical Alley also
includes pharmaceutical and biotech manufacturers, healthcare providers, payers,
research and academic institutions, investors and entrepreneurs.

Medical Alley is optimistic about the potential of Artificial Intelligence (AI) to improve
healthcare. Medical Alley has established a Task Force to contribute to the rapidly
developing policies, at both the federal and state levels, pertaining to AI. The multidisciplinary members of the Task Force have adopted an overall approach to AI,
summarized by the principle of “do no harm.”

Medical Alley would like to thank CDRH for publishing this paper, Considerations for the
Regulation of Generative AI-Enabled Medical Devices. We appreciate the opportunity to
provide comments on these considerations. Our comments are formatted below to include
the CDRH questions numbered consecutively as they are in the paper. The CDRH
questions are repeated in bold font, followed by Medical Alley’s comments.

CDRH Question 1.

Does the two-axis risk framework, organized around device activity and the
consequence of relying on an incorrect output, appropriately capture the dimensions
most relevant to the risk of a GenAI-enabled software function?

If there are additional dimensions—such as the reversibility of a resulting action, the
availability of downstream safeguards, the time pressure of the deployment setting, or
the traceability of the output (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.

Page 1 of 23
Medical Alley Response to Question 1.

A two-axis framework is, indeed, a reasonable format from which to approach the
regulation of GanAI-enabled software functions. We support such a framework because it
is similar to the two-axis concepts that are the foundation of a risk-based regulatory
approach, and as detailed in ISO 14971 Medical devices—Application of risk management
to medical devices.

Figure 1. The two-axis framework proposed in the current CDRH proposal.

The two-axis framework proposed in the CDRH paper, see Figure 1, above, identifies
important considerations but places excessive weight on the consequences of individual
outputs from systems whose outputs are inherently stochastic, context-dependent, and
capable of changing over time.

As a result, substantially different outcomes may arise from products occupying the same
point within the proposed framework. Additionally, the same product may “move" within
the framework based upon user interaction or deployment context. The discussion
document acknowledges this challenge.

Utilizing the distinction between an underlying foundation model and the device-level
software, orchestration, tools, permissions, and controls through which that model is
deployed leads to a more durable two-dimensional framework.

Page 2 of 23
Figure 2. Recommended alternative two-axis framework.

We recommend an alternative framework, see Figure 2, above, in which the primary
classification focuses on characteristics that are designed, manufactured, and objectively
ascertainable:

• X-axis (horizontal) - Autonomy: the degree of autonomy with which the system may
exercise that capability
• Y-axis (vertical) - Capabilities: the scope of action the GenAI-enabled system is
capable and authorized to perform

Risk Modifiers: Clinical consequence, reversibility, time sensitivity, traceability, and
downstream safeguards would remain relevant, but would function as modifiers
determining the controls and evidence appropriate to a capability class rather than as
primary classification dimensions.

Change Control: Changes over time should be addressed through established medicaldevice change-control principles rather than incorporated as an additional dimension of
classification. This approach is consistent with the broader device-regulatory principle that
added or modified capabilities are managed through lifecycle controls rather than by
continuously redefining the product’s original risk classification.

Capability Definitions:

Inform: Retrieves, summarizes, explains, translates, or presents information without
generating an individualized clinical judgment or recommended action.

Page 3 of 23
Assess/Recommend: Interprets patient-specific information and generates an
individualized assessment, prediction, prioritization, or recommended course of action.

Initiate: Triggers or begins a clinically meaningful action or workflow through an external
system or tool.

Execute/Control: Directly implements, completes, modifies, or controls a clinically
meaningful action, therapy, or device state.

Autonomy Definitions:

Human-Directed: A human initiates each material exercise of the device capability.

Human Review/Approval Required: The device may generate an output or proposed
action, but a human must review or approve it before it is communicated or produces a
clinically meaningful effect.

Human-on-the-Loop: The device may exercise its permitted capability without prior
approval, but a human actively supervises and can meaningfully intervene or override.

Autonomous: The device may select and exercise permitted capabilities without
contemporaneous human approval or supervision.

These definitions reduce reliance on dynamic conversational context as a primary
classification mechanism and instead ground classification in discrete,
programmable, and auditable device functions.

GenAI devices explicitly create the context for actions by ingesting individually identifiable
and protected health information (PHI), device data, etc. and using it to formulate a
response or responses. While large language model (LLM) input/output can vary, the
agentic orchestration layers and tools are defined just like any other medical device
software, creating clear and auditable classifications.

For multi-turn capabilities, the GenAI software must also be explicitly built to handle this.
If multi-run is bounded by “Inform” capabilities, the GenAI device can be tested against this
irrespective of the context. If they support multi-turn and build in Initiate capabilities, the
classifiers become more important to understanding the patient risk when coupled with
the autonomy axis.

Manufacturers could then clearly understand, design and document:

1. The highest Capability level the system is designed and authorized to exercise
2. The technical controls that enforce that boundary
3. The autonomy level at which that capability operates
4. The conditions under which the system must refuse, defer, or escalate

Page 4 of 23
Subsequent Answers to questions in the document rely on this framework, but can be
applied independently in many cases.

CDRH Question 2.

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

Medical Alley Response to Question 2.

Medical Alley recommends that CDRH should replace a subjective continuum of linguistic
directiveness with objective classification of functional capability. Wording,
personalization, specificity, and conversational context may provide evidence of the
capability being exercised, but they should not themselves define the regulatory category.
Please refer Figure 2, above, to illustrate the following examples.

Example 1 — Identical Capability and Autonomy, different language.

• Consider an FDA-regulated GenAI-enabled device software function intended to
analyze patient-specific physiologic and clinical data and generate a medicationdosing recommendation for review by a healthcare professional.
• The device concludes either: “I recommend increasing the dose,” or “A clinician may
wish to consider increasing the dose.”
• Under an output-focused framework, the second statement may appear less
directive because of its wording.
• Under our framework, both occupy the same classification: Capability = Assess /
Recommend; Autonomy = Human Approval Required.
• The regulated function has not changed—the device is performing patient-specific
clinical analysis and generating a treatment recommendation, and a clinician must
approve any resulting action. FDA itself recognizes that directiveness cannot reliably
turn on words such as “recommend,” “should,” or “consider.”

Page 5 of 23
Example 2 — Same clinical problem, different Capability and Autonomy.

• Consider two FDA-regulated GenAI-enabled device software functions that interpret
physiologic signals.
• Device A analyzes those signals and presents a clinical assessment to a healthcare
professional, who determines whether any treatment should occur. Its
classification is Capability = Assess/Recommend; Autonomy = Human Decision
Required.
• Device B analyzes the same signals and is technically authorized to initiate or
modify therapy through a connected medical device without prior human approval.
Its classification is Capability = Execute/Control; Autonomy = Autonomous or
Human-on-the-Loop, depending on the actual supervisory architecture.
• FDA recognizes both the special risks of measurement and signal-processing
functions whose outputs may not be independently verifiable and the greater risk
associated with action-taking functions.

In both cases, capability-based classification produces a more durable and auditable
result because it classifies the engineered function rather than attempting to infer
regulatory significance from variable language or conversational context.

CDRH Question 3.

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?

Medical Alley Response to Question 3.

We recommend that CDRH evaluate patient-facing GenAI-enabled devices according to
three principles.

Principle 1: Patient-facing use should not itself create a presumption of higher risk.
This principle would move away from the traditional regulatory approach to direct-toconsumer or over-the-counter products or advertising, yet this may be one area where a
different approach is warranted by GenAI. Whether a device is used by a patient or a
healthcare professional is relevant, but it should not displace the primary classification

Page 6 of 23
based on Capability and Autonomy. The more important questions are what the device is
authorized to do, how independently it may do it, and whether the intended user can
reasonably identify or recover from an erroneous output. FDA itself recognizes both the
potential limitations of patient users and the benefits of improved access, engagement,
and patient empowerment.

Principle 2: Patient-facing GenAI should be evaluated against the care pathway that
exists today, not against an idealized standard of perfect human communication.
Patients today receive clinical information through brief office visits, discharge
instructions, medication counseling, portal messages, call centers, and follow-up
communications that vary in timing, consistency, accessibility, language, and healthliteracy fit. Responsibility for accurate communication, patient education, informed
decision-making, and appropriate escalation already exist within those care pathways.
GenAI does not create those obligations anew; it may provide a more consistent and
accessible means of carrying them out—for example, by reinforcing clinician-approved
instructions, explaining terminology, adapting information to a patient’s literacy level or
preferred language, and identifying when a question should be referred back to a
healthcare professional. Accordingly, FDA should evaluate patient-facing GenAI not against
an unattainable standard of perfect communication, but against the safety, effectiveness,
and accessibility of the care pathway likely to exist in its absence.

Principle 3: Patient-facing deployment can proceed incrementally rather than
requiring an immediate shift to high-autonomy clinical decision-making.
Bounded Inform capabilities such as explaining clinician-approved instructions,
summarizing medical information, translating clinical content, or reinforcing an
established care plan can be evaluated and deployed under existing accountability
structures. As a device advances into Assess/Recommend, Initiate, or Execute/Control
capabilities, or operates with greater autonomy, the evidentiary burden and safeguards
should increase accordingly.

This approach preserves the legitimate concern that patients may be less able than trained
clinicians to detect subtle errors, while avoiding the assumption that direct access to
GenAI is inherently unsafe. User expertise should therefore operate as a risk modifier,
particularly where error detectability is low or downstream consequences are significant,
rather than as a categorical barrier to patient-facing deployment.

The FDA’s own proposed benchmarking framework is compatible with this approach
because it already contemplates testing for scope maintenance, uncertainty
communication, escalation, health literacy, user comprehension, and automation bias.

Page 7 of 23
CDRH Question 4.

CDRH seeks input on whether and how the distinction between generalist and
specialist physicians might inform the assessment of risk for HCP-facing GenAIenabled 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?

Medical Alley Response to Question 4.

Medical Alley recommends that CDRH should not treat generalist versus specialist status
as a separate risk category unless existing mechanisms for intended-user specification,
labeling, training, credentialing, and professional scope prove inadequate. The
manufacturer should validate the device for its intended user population; professional
scope-of-practice and credentialing requirements should continue to operate through their
existing authorities.

Under Medical Alley’s proposed Capability × Autonomy framework (refer to the response to
Question 1, above), a GenAI-enabled device would be classified by what it is built and
authorized to do and how independently it may act. The manufacturer would then specify
the intended user population and the training, supervision, labeling, or escalation
requirements necessary for safe use. FDA already recognizes that specialist knowledge
may affect a user’s ability to independently evaluate an output.

A GenAI device intended for use by a generalist should therefore be validated for that user
population, just as other medical devices are. If specialist expertise is required for safe use,
that should be reflected in the device’s intended use and associated controls.

CDRH Question 5.

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

Medical Alley Response to Question 5.

Medical Alley recommends that a multi-turn conversation should not be treated as a
separate source of regulatory ambiguity. If a GenAI-enabled device is capable of
progressing from Inform to Assess/Recommend, Initiate, or Execute/Control over the

Page 8 of 23
course of an interaction, see Figure 2, above) that capability is part of the deployed
system’s architecture and should be reflected in its primary Capability classification. The
Autonomy axis then captures how independently the device may exercise that capability.

Accordingly, intended use should be characterized by the device’s full permitted capability
envelope across a conversation, not by the apparent function of any individual turn. Multiturn behavior should then be tested to confirm that the system remains within its
authorized boundaries and appropriately refuses, defers, or escalates when those
boundaries are reached. FDA itself identifies this concern, noting that conversational
systems may migrate from informational to action-directing behavior over realistic
interaction trajectories.

CDRH Question 6.

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

Medical Alley Response to Question 6.

Medical Alley recommends that escalation should not be treated as an independent risk
category. It is a manifestation of the device’s Capability and Autonomy (see Figure 2,
above). Whether the system may recommend, initiate, or execute escalation determines its
capability class; how independently it may do so determines its autonomy class. Underescalation and over-escalation should then be evaluated as performance errors within that
bounded function, with acceptable thresholds informed by clinical consequence and time
sensitivity.

CDRH Question 7.

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?

Page 9 of 23
Medical Alley Response to Question 7.

We support competency-based evaluation in principle with modifications.

A competency-based approach is well suited to GenAI because exhaustive testing of every
possible input and output is neither practical nor necessary. However, competencies
should be defined according to the device’s Capability and Autonomy classification, (see
Figure 2, above) rather than through a generalized GenAI competency framework.

An Inform device should demonstrate different competencies than an Execute/Control
device. Likewise, a device requiring human approval should not face the same competency
requirements as one operating autonomously.

The competency framework should therefore answer three questions:

1. Can the device reliably perform its authorized capability?
2. Can it remain within that capability boundary?
3. Can it safely operate at its authorized level of autonomy?

Clinical confirmation should supplement benchmarking where needed, with rigor
proportionate to the downstream risk classifiers. FDA itself proposes benchmarking
followed by clinical confirmation rather than exhaustive scenario testing.

CDRH Question 8.

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?

Medical Alley Response to Question 8.

We recommend that CDRH use Capability × Autonomy, rather than the proposed activity ×
consequence framework, to establish the baseline evidentiary requirement. This is
explained in more detail in our response to Question 1, above.

Evidence requirements should increase as:

• Capability progresses from Inform -> Assess/Recommend -> Initiate =>
Execute/Control; and
• Autonomy increases from human-directed operation toward autonomous
execution.

Clinical consequence and the other classifiers should then modify the depth and rigor of
evidence required within that class.

Page 10 of 23
This creates a predictable relationship: Higher capability + greater autonomy + more
consequential modifiers = greater evidentiary burden.

Importantly, consequence remains highly relevant; it simply does not need to serve as a
primary classification axis.

CDRH Question 9.

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, 17 redundant, or
inappropriately categorized? Are there externally developed standards that could be
leveraged?

Medical Alley Response to Question 9.

FDA's proposed categories provide a useful starting point.

Medical Alley recommends, however, that the benchmarking elements should be explicitly
mapped to the device's Capability and Autonomy class rather than applied as a broad
checklist. This is explained in more detail in our response to Question 1, above.

For example:

• Inform: accuracy, source fidelity, comprehension, boundary adherence.
• Assess/Recommend: clinical reasoning, calibration, uncertainty, appropriate
recommendations.
• Initiate: all of the above plus correct workflow initiation, authorization checks, and
escalation.
• Execute/Control: all of the above plus safe action execution, tool reliability, failsafe behavior, and human intervention controls.

Similarly, autonomy should determine how extensively FDA tests independent decisionmaking, supervision mechanisms, override functions, and failure recovery. The benchmark
should test the competency necessary to exercise the authorized capability, not generic
model intelligence.

Page 11 of 23
CDRH Question 10.

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?

Medical Alley Response to Question 10.

Medical Alley recommends that performance on a generic public benchmark should not
itself demonstrate safety or effectiveness. FDA correctly identifies contamination,
saturation, and lack of real-world representativeness as limitations of public benchmarks.
Sponsor-developed benchmarks should remain permissible, particularly for specialized
devices, but should be accompanied by transparent methodology and independent
validation where risk warrants it.

The relevant question is whether the benchmark validly tests the deployed device's defined
capabilities under representative operating conditions.

Sponsors should therefore demonstrate that benchmark assets:

• Test the actual authorized capability envelope
• Reflect intended users and deployment settings
• Include clinically meaningful edge cases and failure conditions
• Test boundary adherence and refusal behavior
• Are sufficiently independent from training data
• Remain representative of real-world use

CDRH Question 11.

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?

Page 12 of 23
Are there other methods of clinical confirmation that might help inform the evaluation
of GenAI-enabled devices?

Medical Alley Response to Question 11.

Medical Alley recommends that clinical confirmation should be proportionate to
Capability, Autonomy, and the downstream classifiers. The FDA's proposed range is
appropriate. That said, the framework should avoid requiring a prospective clinical trial
merely because a device contains GenAI. Instead, the appropriate evidentiary method
should follow the device's actual capability and patient exposure to harm.

CDRH Question 12.

12. How should sponsors achieve statistically meaningful performance measurement
for GenAI-enabled devices? Where synthetically generated inputs supplement real
patient data, how should sponsors account for differences between the synthetic and
real-world distributions when estimating performance, and under what conditions, if
any, is it appropriate to combine benchmarking evidence and clinical confirmation
evidence to support a single performance estimate?

Medical Alley Response to Question 12.

Medical Alley recommends that GenAI performance should not necessarily be reduced to a
single aggregate "accuracy" metric. Sponsors should measure performance across the
clinically meaningful competencies associated with the device's Capability class,
including relevant failure modes.

The statistical design should reflect the frequency and severity of relevant failure modes
rather than requiring identical measurement strategies across all GenAI devices. Synthetic
data can supplement real-world evidence, particularly for rare conditions or difficult-tosample scenarios, but sponsors should demonstrate that the synthetic population
reasonably represents the intended environment and does not systematically obscure
known performance gaps.

CDRH Question 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

Page 13 of 23
performance gaps the evaluation is intended to detect, particularly for
underrepresented subgroups?

Medical Alley Response to Question 13.

We believe synthetic data is particularly useful for:

• Rare clinical scenarios
• Safety-critical edge cases
• Adversarial testing
• Testing boundary conditions
• Supplementing small subgroup samples
• Systematically varying inputs that are difficult to obtain in clinical datasets

It is less appropriate as the sole evidence source where safety depends heavily on realworld human behavior, workflow interactions, demographic variation, or uncommon
patient presentations.

Particular caution is warranted when the synthetic data are generated by models related to
the device being evaluated, because the generator may reproduce the same biases or blind
spots being tested. FDA expressly raises this concern.

CDRH Question 14.

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

Medical Alley Response to Question 14.

Medical Alley recommends that the comparator should follow the intended function of the
device, not a universal "human clinician" standard. FDA itself recognizes that the
appropriate comparator may differ depending on whether the device works with a clinician
or autonomously.

Page 14 of 23
CDRH Question 15.

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

Medical Alley Response to Question 15.

Medical Alley recognizes this as an important point. FDA should evaluate not only whether
the GenAI device performs against an idealized reference standard, but whether it
improves upon or degrades the actual care pathway that would exist in its absence. The
care likely to occur in the device’s absence should be considered, where appropriate, as an
important benefit-risk comparator without displacing the applicable statutory standard for
safety and effectiveness.

CDRH Question 16.

Should independent third parties be involved in some or all aspects of a competencybased 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?

Medical Alley Response to Question 16.

Medical Alley recommends that independent third parties can provide value in many
instances identified by the FDA. However, third-party certification should not become a
universal prerequisite or a centralized gatekeeper for all GenAI-enabled devices. The need
for third-party involvement should scale with Capability, Autonomy, and risk classifiers
we’ve proposed.

Lower-capability devices may not justify significant third-party testing burdens, while highautonomy Execute/Control devices may appropriately warrant greater independent
validation. Any third-party framework should also preserve multiple qualified pathways to
avoid unnecessary barriers to competition or innovation.

Page 15 of 23
CDRH Question 17.

CDRH is exploring whether a competency-based approach could be applied to
devices that incorporate a variety of underlying model architectures, such as
multimodal vision-language models and generative or predictive world models. Are
there aspects of the described approach that might be ineffective or inapplicable to
these devices? What additional or distinct considerations might need to be
addressed?

Medical Alley Response to Question 17.

Medical Alley recommends that the proposed Capability × Autonomy framework, as
described in our response to Question 1, should apply across model architectures. We
believe that classification should attach to the deployed medical device, not to the
underlying foundation model architecture. This aligns with the FDA’s Foundational Model
Master File concept.

Foundation models should generally be treated as components of the device technology
stack, with appropriate evidence regarding provenance, limitations, performance, version
control, and material changes.

The agentic software layer which defines orchestration, tool access, permissions, and
human oversight is where the device’s Capability and Autonomy are operationalized and
should therefore be the primary basis for classification and competency evaluation.

Different model architectures may require different testing methodologies, but they should
not require different classification frameworks.

CDRH Question 18.

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

Medical Alley Response to Question 18.

Medical Alley supports appropriate premarket/postmarket balance when considering any
promising and novel product, including a GenAI device. CDRH may appropriately accept
greater premarket uncertainty where the device operates within a bounded Capability and

Page 16 of 23
Autonomy class, the consequences of failure are sufficiently mitigated, and robust
postmarket monitoring can detect degradation before material patient harm occurs.

Postmarket monitoring should therefore complement, not replace, the initial
demonstration that the device can safely perform its authorized capability. FDA itself
contemplates whether stronger postmarket evidence could support accepting greater
premarket uncertainty.

CDRH Question 19.

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

Medical Alley Response to Question 19.

Medical Alley suggests that periodic re-benchmarking, clinician review, and degradation
monitoring are all reasonable approaches, but their purpose should be clearly defined:
confirm that the device continues to perform within the capability envelope and
competency baseline established at authorization. Cadence should be risk-proportionate
rather than uniform and reassessment should be triggered by defined events.

CDRH Question 20.

Please comment on whether the proposed approaches to postmarket monitoring can
be facilitated by machine-based supervisory agents. What considerations, including
the evaluation and reliability of the supervisory agent itself, should CDRH take into
account for such an approach?

Medical Alley Response to Question 20.

Medical Alley recognizes that machine-based supervisory agents may support post-market
monitoring, but they should not create a circular assurance structure in which one
unvalidated AI system is relied upon to establish the safety of another.

A supervisory agent should itself be validated for its defined monitoring function, with
known sensitivity, failure modes, and escalation requirements. Its use should be
proportionate to the consequence of a missed signal and should not eliminate human
oversight where clinically significant failures require judgment.

Page 17 of 23
The supervisory agent should therefore be treated as a monitoring tool within the quality
system, not as an independent substitute for manufacturer accountability.

CDRH Question 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?

Medical Alley Response to Question 21.

Medical Alley recognizes that clinicians, healthcare institutions, professional societies,
standards-setting bodies, and other stakeholders can contribute meaningful data, incident
reporting, real-world performance information, and standards development.

Those contributions should supplement, not divide, manufacturer accountability. Just as
today medical device manufacturers have responsibility under the Quality System
Regulation for establishing a monitoring program, evaluating safety signals, taking
corrective action (CAPA), satisfying reporting obligations (MDR), and determining when
additional regulatory review is warranted (510(k) and PMA/S change control), the sponsor
of a GenAI device should continue to have enforceable device obligations, not voluntary
commitments.

CDRH Question 22.

22. CDRH envisions that a manufacturer’s premarket competency-based assessment
might serve as a baseline against which post-deployment modifications could be reevaluated. 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?

Medical Alley Response to Question 22.

CDRH’s proposal to use the premarket competency assessment as the postmarket
baseline is consistent with our Medical Alley framework as explained in detail in the

Page 18 of 23
response to Question 1, above. FDA expressly contemplates re-benchmarking against the
original competency baseline following modification.

The extent of reassessment should depend on whether the modification changes:

1. Capability;
2. Autonomy;
3. Validated performance within the existing classification; or
4. Only implementation details with no material effect on safety or effectiveness.

Changes that do not alter Capability, Autonomy, or validated competency may often be
handled within the manufacturer’s quality system. Changes that expand Capability or
Autonomy should generally trigger more substantial re-evaluation because they alter the
fundamental regulatory classification.

Medical Alley is supportive of Predetermined Change Control Plans (PCCPs). Such plans
may be particularly appropriate for predictable changes that remain within an established
Capability × Autonomy envelope, such as specified model updates, recalibration, retrievalsource changes, or performance improvements that do not expand what the device is
authorized to do.

CDRH Question 23.

How might PCCP concepts or other change-control approaches be adapted for GenAIenabled devices when the nature or scope of future modifications cannot be fully
prespecified?

Medical Alley Response to Question 23. Medical Alley recommends that PCCPs need not
predict every future model modification in technical detail. They can instead define the
boundaries within which change is permitted.

For GenAI-enabled devices, a PCCP could specify:

• The Capability and Autonomy envelope that cannot be exceeded
• Categories of allowable model or software changes
• Required validation methods
• Performance thresholds
• Monitoring requirements
• Triggers requiring new FDA review

This is particularly compatible with stochastic systems because it regulates the permitted
scope of change, rather than attempting to prespecify every future implementation.

Page 19 of 23
A PCCP should cease to apply when a change materially expands Capability, Autonomy,
intended use, or the validated clinical risk profile. That preserves the existing logic of
change control rather than requiring a fundamentally new regime for GenAI.

CDRH Question 24.

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

Medical Alley Response to Question 24.

Medical Alley recommends that third-party foundation models should be treated as critical
supplier components within the regulated device system. The manufacturer should be
responsible for ensuring that upstream changes are detectable and do not silently alter the
safety or effectiveness of the deployed device. FDA specifically recognizes that foundationmodel developers may initiate changes outside the device manufacturer’s control.

Appropriate mechanisms may include:

• Contractual change-notification obligations
• Version locking where technically feasible
• Validation gates before deployment of new model versions
• Automated regression testing against the approved competency baseline
• Rollback capability
• Documented supplier qualification
• PCCPs covering predefined classes of upstream changes

If a third-party change cannot be isolated or controlled, the manufacturer should have
monitoring and technical safeguards sufficient to detect its impact promptly and suspend
or roll back affected functionality where necessary.

CDRH Question 25.

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

Page 20 of 23
limited incentive to disclose safety-relevant 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?

Medical Alley Response to Question 25.

We support voluntary Foundation Model Device Master Files as a practical way for FDA to
receive confidential information about third-party foundation models used in regulated
medical devices.

The existing MAF framework is already designed to let suppliers provide proprietary
information directly to FDA while allowing device manufacturers to reference that
information in submissions.

Participation should remain voluntary, and accountability should remain with the
regulated device manufacturer. A manufacturer that chooses to rely on a third-party
foundation model must obtain enough information, technical control, and contractual
assurance to validate and maintain the finished device within its approved Capability ×
Autonomy envelope.

Voluntary participation also creates the right market incentive. Foundation-model
providers that offer meaningful documentation, version control, known limitations,
healthcare-relevant evaluations, and reliable change notification will be easier to qualify
for regulated-device use. Providers that remain opaque will be less attractive components
of the medical-device supply chain.

CDRH should therefore define a standardized minimum content framework for
voluntary Foundation Model MAFs, including model/version identification, known
limitations, relevant evaluation data, safety controls, update policies, change-notification
commitments, and auditability. The MAF should remain one pathway but not the exclusive
pathway for satisfying supplier-information needs.

Most importantly, the MAF should not become an approval regime for foundation models
themselves. The device manufacturer should remain responsible for the final deployed
system, including competency performance, orchestration, human controls, and change
management.

Voluntary transparency should become a competitive advantage in the regulated-device
supply chain. Where a foundation-model provider remains opaque, the burden should
remain on the device manufacturer to demonstrate that it nevertheless has sufficient
information and control to support safe use, rather than converting the MAF into an
approval regime for general-purpose foundation models.

Page 21 of 23
CDRH Question 26.

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

Medical Alley Response to Question 26.

Medical Alley does not recommend a separate regulatory framework solely because a
GenAI-enabled device is agentic.

The Capability × Autonomy framework described in our response to Question 1 is intended
to characterize the device’s functional and risk profile; it is not intended to replace FDA’s
existing statutory device classification, product codes, or premarket pathways.

Under this framework, Capability defines what the device is authorized to do, while
Autonomy defines how independently it may do it. Tool access and the ability to initiate or
execute multi-step actions therefore affect the device’s Capability level, while the degree
of required human review or approval affects its Autonomy level.

Together, those characteristics define an authorized Capability × Autonomy envelope for
the device. Changes that remain within that envelope should continue to be assessed
under existing FDA change-control principles. A material expansion of Capability or
Autonomy should be treated as an important trigger for determining whether additional
FDA review or a new submission is required. The framework does not replace that existing
regulatory determination.

What may differ for an agentic device is the competency testing required within that
envelope.

Agentic devices should demonstrate that they can:

• Correctly plan and sequence multi-step actions
• Use authorized tools reliably
• Remain within defined capability boundaries throughout a workflow
• Recognize erroneous or unexpected tool outputs
• Honor required human-approval checkpoints
• Fail safely when a tool or downstream system fails
• Resist prompt injection or other inputs that could cause unauthorized actions

Page 22 of 23
FDA’s proposed criteria identify the same concerns, including planning and sequencing,
tool use, erroneous tool outputs, human-oversight checkpoints, graceful failure, and
prompt-injection resistance.

Accordingly, agentic functionality does not by itself require a new FDA device classification
framework. It should instead affect the device’s Capability and Autonomy levels, the
boundaries of its authorized operating envelope, and the testing and controls necessary to
demonstrate safe performance within that envelope.

Page 23 of 23