Pathway for Patient Health (Marla A. Phillips, Lacey Harbour)

See attached file(s)

Pathway for Patient Health
https://www.pathway4ph.org/

October 19, 2026

Submitted electronically via Regulations.gov

Re: Docket No. FDA-2026-N-7874; Considerations for the Regulation of Generative AIEnabled Medical Devices: Discussion Paper and Request for Feedback

Dear Dr. Tarver and Dr. Abramson,

On behalf of Pathway for Patient Health (Pathway), we appreciate the opportunity to provide
comments on FDA’s discussion paper, Considerations for the Regulation of Generative AIEnabled Medical Devices. We thank the Center for Devices and Radiological Health and its
Digital Health Center of Excellence for inviting stakeholder input as the Agency considers how
regulatory approaches can address the capabilities, risks, and evolving uses of generative AI in
medical devices.

We share FDA’s commitment to protecting patients while enabling beneficial innovation. This
discussion offers an important opportunity to consider how risk assessment, premarket
evaluation, and postmarket monitoring can work together to support the safety and
effectiveness of GenAI-enabled devices throughout the total product life cycle. We welcome
the opportunity to contribute practical perspectives from our community to help inform clear,
scientifically grounded, and implementable regulatory approaches.

About Pathway for Patient Health

Pathway is a mission-driven organization dedicated to improving patient health through
collaboration across the life sciences, medical devices sectors and more. Pathway brings
together industry leaders and subject matter experts to address shared challenges in product
quality, regulatory science, and emerging technologies. Through its Chief Quality Officer
Forum, collaborative initiatives, and educational programs, Pathway connects strategic
leadership with practical work to strengthen products, processes, and systems that patients
depend upon.

Our community builds on a longstanding history of collaboration among industry, academia,
and regulators that began at Xavier University under Dr. Marla Phillips. Its AI initiative
originated at Xavier in 2017 and subsequently became one of FDA’s earliest Collaborative
Communities. The initiative continued under the Association of Food and Drug Officials and
the Regulatory Affairs Professionals Society through the AFDO/RAPS Healthcare Products
Collaborative and AI–Global Health Initiative starting in 2022. In 2025, this work transitioned to
the Pathway Collaborative Community, returning to Dr. Phillips’ leadership and continuing its
focus on addressing shared challenges through multidisciplinary collaboration.

T: 513-238-4338 • Marla.Phillips@pathway4ph.org • www.Pathway4PH.org
Today, the Pathway Collaborative Community advances work in AI and digital technologies,
human factors, postmarket innovation, quality operations, and quality science research. Its
working groups bring together expertise across organizational and professional boundaries to
develop practical frameworks, recommendations, educational resources, and research.
Activities relevant to this discussion include good machine learning practices, AI governance
and assurance, human–AI interactions, and the use of AI in postmarket surveillance.

Pathway is responding because the questions raised in this discussion paper intersect directly
with the challenges our community is working to address: how to establish appropriate
evidence of performance, preserve meaningful human oversight, manage changes and
dependencies, and translate postmarket experience into timely action. Our collaborative
model allows us to examine these issues across disciplines and across the product life cycle,
including the relationships among manufacturers, technology suppliers, healthcare
organizations, and users.

Through the comments that follow, we seek to help FDA identify approaches that protect
patients, establish clear accountability, and support consistent implementation as GenAI
technologies and their clinical applications evolve. We also hope to identify areas where
continued collaboration, research, and development of shared methods can help close
evidence and implementation gaps.

Our responses to FDA’s discussion questions are provided in the appendices to this
submission, organized by the corresponding sections and question numbers in the discussion
paper. These responses present Pathway Response Team’s feedback and recommendations,
with supporting rationale and examples where applicable, to facilitate FDA’s review.
Pathway Response Team
Keyhan Afaghi Director, Clinical Quality Assurance Corcept Therapeutics
Kayla Britt Founder and Principal Consultant Britt Biocomputing
Attrayee Chakraborty Senior Quality Systems Engineer
Stan Chen Student WGU, ex-SAP
Tram Dang Senior Manager, Quality and Regulatory Compliance Teal Health
Reena Harjai VP, PV Inovio
Michael Iglesias Digital Health & Companion Diagnostics Merck
Bre Jacobs CEO & Managing Partner Brena Global
Ujjwal Jain Director, Software Quality Illumina Inc
Kent Joshi CEO and President AgiLaunchIT
Mandar Karhade CEO & Founder Citingale
Shelly LaPointe Quality Systems Director Advanced AI (Stealth Startup)
Janine Medina CEO & Executive Director Biohacking Village
Siva Nagireddy Sr. Director Digital Quality Glaukos
Thi Nguyen Founder, Consultant Habit 2 Mindset LLC
Gourav Pandey R&D Quality Lead Takeda
Gilbert Pinzon Manager, Quality Assurance Gilead Science
Rajha Rajamurthi Quality Manager - Digital Products Baxter International
Ashkon Rasooli Founder EnGenius Solutions
Swetha Ravichandiran Regulatory Consultant Syneos Health
Anjlee Ruparel Graduate University of York
Priya Setty Self Representing
Malligari Shashidhar Quality Analyst Novartis
Seema Sodhi Self Representing
Hari Subramanian Director, IT Compliance and Testing Services Otsuka Pharmaceuticals
Rebecca Walters Principal Regulatory Consultant Kaleidoscope Innovation

Affiliations for identification only; views do not represent employers.

Marla A. Phillips, Ph.D. Lacey Harbour RAC, MB(ASCP)CM
CEO and President VP, Quality & Regulatory Advancement
Pathway for Patient Health Pathway for Patient Health
513-238-4338 Lacey.Harbour@Pathway4PH.org
Marla.Phillips@Pathway4PH.org www.Pathway4PH.org
www.Pathway4PH.org
 Appendix 1

Section IV: Considerations for the Assessment of Risk for GenAI Enabled Devices

Q1) 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.

The two-axis framework, organized around device activity and the consequence of relying on
an incorrect output, is a good starting point but Pathway believes is insufficient alone. We
recommend retaining the two axes and incorporating formal risk modifiers that inform a
device’s placement and overall risk assessment: reversibility, time pressure, downstream
safeguards (including deterministic and non-AI checks, and hard limits), output traceability
and grounding in verifiable sources, patient vulnerability, error detectability, breadth of
intended use, frequency of exposure, and demonstrated effectiveness of human oversight.
These modifiers should reflect the actual deployment context and the effectiveness of
implemented safeguards rather than relying solely on a static matrix position or the nominal
presence of human review. Human oversight should be credited as a risk control only to the
extent its effectiveness is demonstrated, and the same evidence should guard against overreliance that can erode oversight over time. Detectability warrants particular attention. A
fluent, confident but incorrect output gives the user no signal that anything is wrong, so a
silent failure should be treated as higher risk than an overtly incorrect one of similar content.
Detectability determines whether any second look occurs; reversibility, time pressure,
safeguards and traceability determine whether an error can still be caught and corrected
afterward. As device activity moves from non-directive to action-directing to action-taking, the
opportunity for a user to detect and correct an incorrect output narrows, and for action-taking
functions the risk assessment should consider the harm of the action itself rather than
assume human review. Sponsors should prespecify failure types, such as an unauthorized
irreversible action or a missed emergency escalation, that count as automatic failures
regardless of aggregate performance. Traceability has two forms that should both be reflected:
traceability of outputs to verifiable clinical sources and guidelines, and traceability of outputs
and device configurations through the design history and quality management system records.
Only the first form reduces the likelihood that an incorrect output reaches and harms a
patient. Configuration traceability supports investigation, change control, and reconstruction,
and should be credited as an assurance control rather than as a clinical risk modifier (see Q9).
The proposed figure below reflects this distinction.
Figure 1 recommendation:

Q2) 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?

Directiveness should be assessed by how strongly an output steers the intended user toward
action or inaction, rather than by particular words alone. FDA’s discussion paper (Section IV,
p. 7) illustrates the continuum between “non-directive” and “action-directing” information
with four example outputs for a patient whose blood pressure remains above the treatment
goal while taking lisinopril, a common blood-pressure medication. FDA’s progression
combines two dimensions that can vary independently: how ready the output is to act on, and
how closely it is tied to the user’s own circumstances. Pathway suggests that FDA formalize
this progression into a named directiveness ladder, so that manufacturers share a common
vocabulary when classifying their own functions during design, and that the two dimensions be
scored separately on the “Action readiness” and “Specificity and personalization” rows of the
mock rubric below:
Step (rubric score) What the output does FDA example
States general “lisinopril dosages are sometimes
0 — General
information that applies increased when blood pressure remains
information
to anyone above the treatment goal”
Connects general
1 — Connection to the “in situations similar to this, clinicians
practice to the user’s
user’s circumstances often increase the lisinopril dosage”
situation
Endorses a specific “I recommend increasing the lisinopril
2 — Endorsement
action dosage”
Gives an executable
3 — Specific “increase the lisinopril from 10 mg to 20
instruction, including
instruction mg daily”
dose

Because the ladder steps combine both dimensions, a function’s ladder step should be read
from its scores on those two rows rather than scored a second time. The remaining rubric
dimensions are scored separately and recorded together as a profile, not summed into a
single score. Specificity and personalization should be treated as directiveness modifiers
independent of word choice. A general statement about a drug class is less directive than the
same statement narrowed to the user’s own dose, laboratory values or history, even when the
sentence structure and verbs such as “consider” or “recommend” are unchanged. Consistent
with the discussion paper’s caution that a “talk to your doctor” statement may not make an
otherwise directive output less directive, softening language should not reduce the
directiveness of personalized, action-oriented content. Beyond wording and personalization,
relevant modifiers include action readiness (the extent to which the output supplies an
executable plan); narrowing or ranking of available choices; repeated endorsement or
persuasive reinforcement across a conversation; visual prominence and default selections;
the friction between receiving advice and acting on it; and cues implying clinical authority or
certainty. For example, reassurance that discourages care-seeking may be highly directive
even when phrased as information, while a qualified explanation of reasonable options may
preserve meaningful user choice.

FDA should distinguish boilerplate disclaimers from decision-relevant communication of
uncertainty. A generic disclaimer should not offset content that otherwise directs action.
Specific limitations communicated prominently at the point of decision, with appropriate next
steps, may mitigate risk when testing demonstrates that intended users understand and
respond appropriately to them.

To support consistent and predictable assessments, FDA should provide structured rubrics
and publish worked examples along the directiveness ladder for a small number of common
domains, such as medication dosing, symptom triage and chronic disease management, so
that smaller sponsors in particular can classify their functions during design and not discover
the classification during review. Examples could address both action and inaction, conflicting
presentation cues, and increasing directiveness across multiple turns, and identify the
evidence needed to credit mitigating features.
Mock rubric for consideration:

3 — Direct
0 — Minimal 1 — Some 2 — Strong instruction or
Modifier
steering steering steering strong
constraint
Supplies an
Explains a
Describes executable plan,
concept Recommends a
Action readiness possible next including dose,
without a next specific next step.
steps. timing, or
step.
sequence.
Presents Presents one
Highlights an Strongly favors one
reasonable course as
Narrowing of option while option or
options necessary or
choices retaining dismisses
without rules out seeking
alternatives. alternatives.
favoring one. care.
Pressures the
user or overrides
Provides
Offers a Repeatedly hesitation
Persuasive information
rationale for an endorses the same through repeated
reinforcement without
option. course. reassurance or
persuasion.
emotional
appeals.
Options and
A recommended An action is
limitations One option
Presentation and action dominates; preselected or
receive receives greater
defaults qualifications are presented as the
comparable prominence.
less visible. expected choice.
prominence.
Enables
immediate
No action
Links to general Prefills an action execution with
Proximity to action mechanism is
resources. for user review. little opportunity
provided.
for independent
review.*
Offers a
Implies verified
qualified,
Clearly diagnosis,
general
distinguishes Presents a professional
interpretation
Authority cues education definitive clinical approval, or
and states what
from clinical conclusion. certainty that has
remains for a
judgment. not been
clinician to
established.
decide.
Specificity and General Information Applied to the Applied to the
personalization information tailored to a user’s own stated user’s specific
(scale reflects category of users circumstances, dose, laboratory
 3 — Direct
0 — Minimal 1 — Some 2 — Strong instruction or
Modifier
steering steering steering strong
constraint
degree of tailoring that applies to or conditions, such as their values or history,
rather than anyone. such as adults symptoms or producing an
steering) with current individualized
hypertension. medication. instruction.
*Immediate execution may cross into action-taking and should trigger assessment of the
device’s functionality, rather than simply a higher informational-directiveness score.

Next step, the following matrix assesses whether safeguards reduce the risk associated with
directive outputs. Credit should depend on evidence that intended users notice, understand,
and respond appropriately to each safeguard in the actual workflow. The presence of a
safeguard alone should not automatically lower the directiveness rating or offset other risk
factors.

Safeguard Evidence needed to credit mitigation
Decision-relevant Users understand what is uncertain and how that uncertainty
uncertainty affects the next step.
Limitations appear alongside the recommendation, and users
Prominent limitations
notice and understand them.
Users recognize that alternatives remain available and understand
Meaningful alternatives
when they apply.
Questions identify missing or contradictory information before
Confirmation questions
advice becomes actionable.
Escalation is triggered appropriately and users can complete the
Clinical handoff
intended handoff.

For final interpretation, record the profile across modifiers rather than summing them into a
single score. A strong directive feature should trigger closer assessment even if other features
score low. Then consider clinical consequence, intended users, deployment context, and
demonstrated safeguards. Test both individual outputs and complete conversational
trajectories.
Q3) 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?

Patient-facing functions can present greater risk when users lack the domain knowledge to
independently evaluate personalized clinical advice. However, patient access alone should
not automatically result in a higher risk classification or underestimate patient capability.
Rather, patient-facing use should be treated as a risk modifier that raises evidence
expectations, because lay users may be less able to detect erroneous outputs. Pediatric
intended use warrants its own risk consideration and age-banded testing, not only standard
demographic subgroup analysis, because developmental stage and not age alone changes
what safe, understandable guidance looks like. Where developmental stage changes what
guidance is safe or understandable, for example for medication use, mental health, or when to
involve a parent or caregiver, a tool that gives materially identical guidance to a 13-year-old
and a 17-year-old is not adequately protective. Geriatric users likewise warrant human factors
engineering and age-appropriate testing. FDA should recognize demonstrated risk reduction
from safeguards including plain-language uncertainty communication tailored to intended
users’ health literacy, traceability to reliable sources, confirmation questions, predefined
escalation rules and handoff to a healthcare professional, limits on high-risk
recommendations, and usability testing across representative health-literacy levels. Risk
assessment should consider the effectiveness of these safeguards alongside the potential
benefits of improved access, engagement, and patient empowerment.

Mitigation should rest on objectively testable output-design features, not on a blanket
classification of a function as patient-facing. Examples include a reading level calibrated to
the intended users’ health literacy; presentation of alternatives and not a single directive path;
and a default toward escalation, or routing to an accountable clinical channel, whenever
patient-reported information is ambiguous or incomplete. These features should be evaluated
through the existing benchmarking elements, in particular S.3 (calibration, uncertainty
communication, and clinical deferral) and E.4 (communication quality and user
comprehension), and not through a separate risk-tier judgment based solely on whether the
user is a patient or a healthcare professional. Dynamically generated patient-facing content
should be held to a standard no lower than that applied to well-designed pre-written patient
education materials. Risk mitigation should not depend on patients being able to identify
clinically incorrect outputs. FDA should consider complementary device-enforced controls,
decision-relevant communication, and effective escalation pathways, with safeguards
proportionate to the consequence of an incorrect output.

Device characteristics that may mitigate risk include a clearly bounded and validated clinical
scope; controls that prevent recommendations outside that scope; checks for essential,
missing, or contradictory patient information; and verified safety rules or deterministic limits
where appropriate. These controls should remain effective across multi-turn conversations,
including when users request greater certainty, resist escalation, or attempt to obtain advice
outside the device’s intended use. To achieve this with the use of generative models,
independent deterministic controls can enforce safety and intended-use boundaries. Rather
than relying solely on model instructions, these controls can restrict permissible outputs, tool
permissions, action sequences, and transitions between informational and action-taking
behavior; apply verified safety rules and hard limits; and require professional review before
defined high-consequence actions. Controls should operate before an output reaches the
patient or an action is executed. Sponsors should demonstrate that the controls resist bypass
across foreseeable interaction and attack pathways, document residual vulnerabilities, and
verify that control failures trigger a defined safe response. Patient confirmation of an output
should not be treated as verification of its clinical correctness.

Output features should distinguish established information from inference, general education
from personalized advice, and uncertainty about the patient’s circumstances from uncertainty
in the underlying clinical evidence. Limitations should explain what cannot be concluded and
how that affects the next step, rather than relying on confidence scores or generic disclaimers.
Recommendations should state their relevant assumptions and identify circumstances that
would change the advice. Source traceability may support informed participation, but a
citation should not be treated as proof that the source is current, applicable to the patient, or
correctly interpreted by the device.

Escalation safeguards should specify when professional review is necessary, how that review
can be accessed, and what happens if it is unavailable. Where timely handoff is part of the
risk-control strategy, sponsors should demonstrate that it works in the intended deployment
setting. A recommendation to “consult a professional” should not receive the same riskreduction credit as a functioning handoff that conveys relevant information and supports
timely review.

These protections should preserve patient agency and recognize differences in health literacy,
language, accessibility needs, and experience managing a condition. Interfaces may adapt
explanations and support to those needs, but safety-critical protections should not be relaxed
solely because a patient expresses confidence or familiarity. Patients should be able to
correct inputs, ask for explanations, and access appropriate professional support without
being subjected to unnecessary blanket restrictions.

Sponsors should evaluate both comprehension and behavior through representative usability
and human-AI interaction testing. Testing should include plausible incorrect outputs,
misleading reassurance, missing information, conflicting advice, and multi-turn interactions
to determine whether safeguards prevent inappropriate reliance, delayed care, or unsafe
action. Risk-reduction credit should reflect demonstrated protection when patients cannot
independently assess clinical accuracy, not merely their ability to understand the device’s
wording.

Cybersecurity safeguards should protect the information and controls on which patients rely.
Sponsors should evaluate whether malicious or compromised user inputs, retrieved content,
or tool outputs can redirect the device, generate misleading clinical advice, or bypass
intended-use boundaries and escalation rules. Relevant protections include integrity and
provenance controls for clinical sources, retrieval content, and patient data; separation of
untrusted content from executable instructions; least-privilege tool access; and protection of
deterministic safety controls against unauthorized modification or bypass. When compromise
is detected or the integrity of safety-critical information cannot be established, the device
should follow a defined, clinically appropriate response, such as withholding an affected
recommendation or action and providing an alternative route to care. Patients should not be
expected to identify prompt injection, poisoned sources, or other cybersecurity failures
themselves. Because patient interactions may generate data that flows into clinical records or
downstream uses such as research and model improvement, sponsors should also address
unintended or erroneous patient-generated inputs through data validation, provenance
tagging, and records of how the data were created.

Finally, for patient-facing functions used in the home, risk assessment should address the
connected digital ecosystem on which the function depends, including consumer networks,
connected medical devices, caregiver interfaces, cloud services, and clinical monitoring or
escalation services. Safeguards should verify patient identity and data attribution, identify
stale or unreliable measurements, control caregiver and third-party permissions, and prevent
compromised integrations from altering clinical information or safety controls. Sponsors
should define clinically appropriate operation during connectivity, power, or service failures
and distinguish successful transmission of an alert from confirmed receipt and timely
response. Where professional handoff is a risk control, its availability and fallback
arrangements should be demonstrated in the intended home-care setting. Evaluation should
include representative household conditions, shared-device use, caregiver involvement,
accessibility needs, and interruptions, without requiring patients to diagnose technical or
cybersecurity failures themselves.

Q4) 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?

Risk assessment should consider whether the intended healthcare professional has the
clinical knowledge needed to independently evaluate specialist-domain outputs. The relevant
question is not the professional title of the intended user but whether that user, in that
context, has enough domain knowledge to catch a specialty specific error, omission or
contradiction before it affects a patient. A generalist with substantial experience in an area
may catch errors that a true novice would miss. Pathway therefore recommends that FDA
frame the underlying safeguard as the user’s demonstrated ability to evaluate the output
independently, drawing on the independent review criterion in section 520(o)(1)(E) of the FD&C
Act, and that it name independent professional review of the basis for an output, prior to
reliance, as the defining lower-risk design pattern. Define expected user competencies and
benchmark, with both generalist and specialist users, whether the device recognizes when an
output exceeds the intended user’s verification capabilities, clearly communicates its
limitations, prompts appropriate consultation or referral, and limits autonomous execution
where necessary. Demonstrated functional safeguards and appropriate labeling should
support safe use while preserving the potential benefits of specialist insights in generalist care
settings.
Mitigating device characteristics might include a validated scope matched to intended user
roles, clear separation of educational information from patient-specific recommendations,
checks for missing or contradictory clinical information when data is accessible, and
presentation of relevant patient findings, applicable source evidence, assumptions, and
limitations alongside the output. Verified safety rules or independent deterministic controls
may provide additional protection by detecting defined contraindications, blocking actions
outside the device’s validated scope, and enforcing review checkpoints without relying solely
on the generative model’s instructions.

For decisions requiring specialist judgment, the device could identify predefined conditions for
consultation, support transfer of relevant clinical information, and limit action until the
required review occurs. These controls should support, rather than supplant, clinical
judgment. Medical device manufacturers do not practice medicine, and device controls
should not prevent physicians from exercising their professional judgment. Manufacturers
nonetheless remain accountable for device safety and should address reasonably foreseeable
use outside the intended use, including off-label use, through risk analysis, residual-risk
evaluation, and labeling. Labeling and documented HCP training should explain the device
boundaries.

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

Risk should be assessed across complete, realistic conversational trajectories rather than
isolated turns, because individually acceptable outputs may cumulatively steer a user toward
clinical action or inaction. FDA should require, and not merely permit, testing of complete
conversations as a distinctly scored behavior across the relevant benchmarking elements,
including S.1 (safety-critical recognition and escalation), S.2 (scope maintenance and
boundary adherence), E.2 (information gathering and clinical analysis), and R.1 (robustness,
including degradation across long conversations), each with its own prespecified acceptance
criteria, for any conversational device and for any function that is action-directing or actiontaking. The discussion paper currently describes multi-turn testing as one of several methods
that relevant testing “may include.” Risk can build gradually across a conversation, for
example in a mental health screening or intake conversation that begins with a general
screening question and moves turn by turn toward more serious content without any single
alarming message, so testing individual exchanges alone will not detect it. Evaluation should
include context loss, missing or contradictory information, repeated requests, attempts to
subvert safeguards, emotional pressure, paraphrasing, and consistency of advice across the
exchange.

The device’s intended use should be characterized through a defined behavioral envelope
specifying permissible conversational states, prohibited transitions, and mandatory
healthcare-professional deferral or handoff points. To make the behavioral envelope testable,
sponsors should define and test a finite, prespecified set of conversational trajectory
envelopes: bounded arcs that describe how far a conversation may escalate in directiveness
before the device must stop and hand off to a person or a predefined safety response.
Expressed in the directiveness ladder discussed in Q2, an envelope states the highest step the
device may reach on its own and the conditions that require a handoff before it goes further.
This converts an open-ended question about emergent intended use into a testable, auditable
design control. These boundaries should identify when the conversation moves from general
information to personalized advice or action-directing behavior, with controls that prevent
unauthorized transitions and maintain the boundaries throughout the interaction.

Mock intended use statement:

Home Recovery Conversation Assistant

The Home Recovery Conversation Assistant is intended for use by adult patients and their
designated caregivers following specified outpatient procedures to explain clinician-approved
discharge instructions and support communication with the treating care team through multiturn conversations.

The device may clarify instructions, collect patient-reported symptoms, ask predefined followup questions, and identify reports that meet validated escalation criteria. It may direct users to
contact the care team or seek urgent assistance according to clinician-approved escalation
protocols. These action-directing outputs are limited to escalation and do not include
diagnosis or treatment selection.

The device is not intended to independently diagnose complications, change medication
doses, initiate treatment, or override discharge instructions. Within its conversational
envelope, outputs may reach step 3 of the directiveness ladder (specific instruction) only for
clinician-approved escalation instructions, such as contacting the care team or seeking urgent
assistance; all other outputs remain at or below step 1 (connection to the user’s
circumstances).

The device does not replace emergency services or provide continuous clinical monitoring.
Associated design requirements and labeling (not part of the intended use statement):
Requests for diagnosis, medication changes, or individualized treatment decisions trigger a
scope limitation and clinical handoff, and the device remains within this scope throughout an
exchange.
The device does not provide reassurance that negates an escalation criterion met earlier in the
conversation unless the relevant information has been explicitly clarified and the validated
protocol permits that change.
Labeling informs patients whether messages are monitored by the care team, and the device
does not instruct users to wait for a response when the escalation protocol calls for immediate
assistance.
Q6) 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?

Manufacturers should evaluate under-escalation and over-escalation separately, reporting
each error rate with confidence intervals, severity-weighted analyses, delayed and
unnecessary escalation, and subgroup performance at clinically relevant decision thresholds.
These errors should not be collapsed into a single accuracy measure or assigned a universal
weighting ratio. Where escalation is a safety control, evaluation should distinguish an alert
generated, an alert delivered, receipt acknowledged, and clinically appropriate action
completed within the specified time, and sponsors should define the fallback action when
acknowledgment or response is absent.

Thresholds and acceptable trade-offs should be prespecified before confirmatory validation
and clinically justified for the intended use, population, care setting, and level of clinical
oversight, based on a benefit-risk assessment of the severity, likelihood, urgency, and
reversibility of potential harm, time to intervention, available safeguards, consequences of
delayed care, and the harms and downstream burden associated with unnecessary
escalation, and supported by clinical input, risk analysis, and representative testing. Sponsors
should state which direction of error the system was designed to favor and justify that choice
against the clinical context and the response capacity of the receiving system. Escalation
should also not be treated as a binary choice between emergency escalation and no action.
Routing a concerning finding to an accountable clinical channel, such as a care team with a
defined obligation to follow up, carries a materially different error-cost profile from either
emergency escalation or no action, and FDA should recognize it as a distinct response
category. Under-escalation should receive greater weight for life-threatening conditions, while
over-escalation should retain explicit acceptance criteria. Performance in one direction
should not compensate for an unacceptable safety-critical error rate in the other. Use-related
risk analysis should link foreseeable use errors in responding to escalation outputs, in either
direction, to hazardous situations and clinical harms, favoring design mitigations over labeling
and informing human factors validation and postmarket surveillance.

The same principles should extend beyond care-seeking to under-intervention and overintervention, including missed necessary care and unnecessary testing, treatment, or referral.
 Appendix 2

Section V: A Competency Based Approach for Premarket Evaluation of GenAI Enabled
Devices

Q7) 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?

Pathway agrees that device benchmarking followed by clinical confirmation is a useful and
appropriate framework for evaluating GenAI-enabled devices, provided it complements
established risk based software verification and validation, usability, cybersecurity, clinical
evaluation, risk management, and quality-system controls. Pathway recommends that FDA
state explicitly that device benchmarking corresponds to design and development verification,
and clinical confirmation corresponds to design and development validation, under the
Quality Management System Regulation (21 CFR Part 820, which incorporates ISO
13485:2016, clause 7.3). This would make clear that the competency-based approach is an
extension of existing design controls and not a parallel compliance track requiring duplicate
infrastructure.

Benchmarking should address the final deployed device configuration and intended use
(including the underlying model, prompts, retrieval sources, guardrails, tools, orchestration,
user interface, and deployment conditions) rather than the model(s) alone. Clinical
confirmation could establish that benchmark performance translates into safe and effective
performance for the intended use and include intended-use-specific clinical-benefit
endpoints, with the type and rigor of evidence proportionate to risk.

The clinician-credentialing analogy should apply only to the premarket evaluation
methodology. Demonstrating competency before market entry must not diminish
manufacturer accountability for ongoing performance monitoring, change control, or other
postmarket obligations. The analogy also has a structural limit. As cited in the discussion
paper, a clinician who fails faces professional, legal, and reputational consequences, and is
periodically reassessed, whereas a device has no direct equivalent of losing a license. Design
verification and validation are repeated when the design changes but have no built-in periodic
renewal. FDA should therefore explain what follows when a device that met the premarket
competency standard later fails in the field, and how its competency will be rechecked over
time, for example through the postmarket re-benchmarking and reassessment discussed
under Q19 with accountability remaining with the manufacturer.

Q8) 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?

The two-axis framework should anchor risk-based evidence tiers within the competencybased approach, supplemented by contextual modifiers (as previously discussed). Evidence
requirements should increase with greater device autonomy and more severe consequences
of incorrect outputs, and should account for limited error detectability, ineffective human
oversight, time criticality, irreversibility, and breadth of intended use. This is consistent with
the ISO 14971 risk management process and with ISO/TS 24971-2:2026 for machine-learningenabled devices, although that specification does not itself cover large language models or
generative AI, which is a standards gap FDA could help close.

Higher-risk tiers should require broader challenge testing, stronger subgroup analyses, more
clinically representative confirmation, tighter acceptance limits for safety-critical failures, and
independent adjudication where warranted. Lower-risk functions may justify more focused
evidence when their scope is bounded and safeguards are demonstrably effective. Planned
postmarket monitoring should complement, rather than automatically reduce, the premarket
evidence needed.

Worked examples from FDA linking axis placement and modifiers to expected benchmarking
coverage, clinical-confirmation methods, and acceptance criteria would be of great benefit to
industry. This would help sponsors predict the evidentiary requirements while allowing
justified tailoring to the device’s intended use and deployment context.

Q9) 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?

The proposed benchmarking structure provides a useful foundation for evaluating clinical
knowledge, analytic capabilities, safety behavior, communication, and generalizability.
However, benchmarking alone should not be treated as sufficient evidence of safety and
effectiveness; it should be linked to clinical confirmation and evaluation of the complete
deployed configuration.

We recommend that FDA explicitly integrate data and source provenance; factual and
configuration traceability; retrieval currency; cybersecurity and prompt-injection resistance;
privacy; interoperability; human factors and automation bias; multilingual performance; and
failure recovery and rollback. Testing should assess whether cited sources actually support
the output and apply to the clinical context, whether missing or corrupted inputs are handled
safely, and whether safety boundaries remain effective across multi-turn conversations and
tool interactions.

Several of these topics already appear within the proposed elements and should be
strengthened rather than duplicated. For example, prompt injection is addressed under scope
maintenance and agentic competencies, but should also be evaluated as a system-level
cybersecurity concern across input, retrieval, and tool pathways. Communication quality
should include demonstrated user comprehension and appropriate reliance, while
generalizability should distinguish clinically acceptable output variation from variation in
safety-critical behavior. Configuration traceability and rollback are supporting assurance
controls whose effectiveness should be verified, rather than treated as measures of clinical
proficiency.
FDA could leverage relevant provisions of ISO 14971 for risk management, IEC 62304 for
software lifecycle controls, IEC 62366-1 for usability engineering, ISO 13485 for quality-system
controls, ANSI/AAMI/IEC 81001-5-1 for health-software security activities, and AAMI CR34971
and ISO/TS 24971-2:2026 for applying risk management to machine-learning systems, noting
that ISO/TS 24971-2:2026 does not apply to devices employing large language models or
generative AI, which is a gap in current standards. A mapping of benchmark elements to
applicable standards and existing processes would help identify GenAI-specific gaps, avoid
redundant testing, and clarify that compliance with a standard does not itself establish
adequate clinical performance.

Q10) 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?

Sponsors should demonstrate, rather than assume, that benchmark performance predicts
safe and effective behavior for the device’s intended use. Evaluate the complete deployed
system (including the model, harness, and human interaction where applicable) over repeated
runs in representative clinical workflows. Testing should reflect the intended population, input
distribution, deployment conditions, and foreseeable misuse. Characterize run-to-run
variability, prespecify clinically justified acceptance criteria, and establish concordance
between benchmark results and clinically representative performance, including safetycritical failures rather than aggregate accuracy alone.

Construct-validity evidence should show that the benchmark measures the clinical
capabilities it claims to assess. Supporting evidence should include content coverage aligned
with intended tasks and hazards, data provenance, contamination controls, difficulty analysis,
subgroup coverage, and reproducibility. Where feasible, demonstrate that the benchmark
distinguishes configurations known to differ meaningfully in clinical performance. High scores
on knowledge-based or exam-style tests alone should not establish real-world validity.
Sponsor-developed benchmarks should form part of the evaluation suite because they can
address intended-use-specific tasks and failure modes that public benchmarks miss. To
reduce optimization to the test, sponsors should separate development and evaluation
assets, use controlled or sequestered test sets, document benchmark-selection decisions,
and apply independent review where warranted by risk. Independent review may be performed
by a qualified internal assessment function that is organizationally separate from the
development team, with documented separation of duties, protected evaluation data, and
conflict-of-interest controls, or by an external party where risk warrants. Sequestration may
likewise be demonstrated through third-party custody or through versioned, hash-identified
evaluation datasets with restricted access maintained under the sponsor’s quality
management system. Neither sponsor ownership nor public availability should substitute for
evidence of validity.

Using benchmark results as a proxy for evaluating future updates should require established
concordance for the intended context of use and a controlled, versioned benchmark baseline.
When contamination, saturation, or changing clinical practice necessitates benchmark
replacement, documented bridging should preserve comparability with the authorized
baseline and confirm continued clinical relevance.

Evaluation should also address reward hacking, in which optimization improves the measured
score without improving, and potentially degrading, the underlying clinical behavior. Sponsors
should test whether a device exploits scoring shortcuts, produces answers that satisfy an
automated judge while remaining clinically incorrect, or suppresses uncertainty to receive a
higher score. For a locked device, this risk arises during development, for example when a
model, its prompts, or its retrieval configuration are tuned against a benchmark, or when the
same automated judge is used in both development and evaluation. Safeguards should
include evaluation cases withheld from development, clinically grounded scoring rubrics,
checks for disagreement between automated scores and expert assessment, and separate
acceptance limits for safety-critical failures. Benchmark gains should receive credit only when
they reflect improved performance on the intended clinical tasks. This reflects Goodhart’s
Law, commonly paraphrased as, “When a measure becomes a target, it ceases to be a good
measure.”

For agentic or tool-using devices, and for devices that adapt during use, evaluation controls
should also address tampering with the evidence used to judge performance, which may arise
from the system itself without developer intent. Reward-input tampering occurs when the
system fabricates observations or results that never occurred, or alters, replaces, or omits
source records, logs, or measurements. Reward-function tampering occurs when scoring
logic, reference answers, or acceptance criteria are modified. Authoritative evaluation
evidence and scoring criteria should be protected from modification by the evaluated system,
directly or through connected tools and delegated agents, through read-only access, separate
credentials, least-privilege tools, deterministic authorization checks, separation of duties,
integrity checks, and independently retained, versioned audit trails. Actual observations and
execution outcomes should be captured independently of model-generated claims, with
generated inferences and synthetic data clearly distinguished from verified records, and
testing should verify that these restrictions remain effective against indirect attempts to
influence the evaluator.

Sponsors should enforce separation between the evaluated system and the evidence used to
judge it. Authoritative source records, reference answers, scoring logic, and acceptance
criteria should be protected from model-initiated modification through read-only access,
separate credentials, least-privilege tools, and deterministic authorization checks. Actual
observations and execution outcomes should be captured independently of model-generated
claims, with generated inferences and synthetic data clearly distinguished from verified
records. Protected audit trails, versioning, and integrity checks should support detection and
investigation of unauthorized changes. Testing should verify that these restrictions remain
effective through connected tools, delegated agents, and indirect attempts to influence the
evaluator.

Q11) 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?

Sponsors should select and justify clinical-confirmation methods according to the device’s
intended use, autonomy, potential consequences of error, residual uncertainty after
benchmarking, and whether errors can be detected and corrected before affecting care. The
justification should identify which uncertainties require clinical confirmation and explain how
the selected methods resolve them.

A risk-proportionate approach may combine retrospective testing, shadow deployment,
standardized-user studies, independent clinical adjudication, and prospective studies. These
methods provide different evidence and should not be treated as interchangeable.
Retrospective testing may support bounded functions but cannot fully establish how users
respond to outputs; shadow deployment can assess performance on live inputs without
directing care but cannot establish the effects of acting on recommendations. Highconsequence autonomous functions, difficult-to-reverse actions, and functions whose safety
depends on human-AI interaction should not rely solely on retrospective or synthetic
evidence.

Confirmation should reflect the anticipated distribution of real-world inputs, including clinical
prevalence, severity, comorbidities, missing or contradictory information, language, user
characteristics, workflow, and deployment setting. Common-use cases should be
represented alongside deliberate enrichment for rare safety-critical scenarios, with results
reported separately where enrichment changes the distribution. Performance should also be
assessed across clinically relevant subgroups and sites rather than inferred from aggregate
results.

Additional methods may include multi-reader, multi-case studies where appropriate;
simulated-use studies of complete conversational or agentic workflows; and staged clinical
deployment with predefined monitoring, stopping, and rollback criteria. The combined
evidence should establish clinically relevant performance of the deployed device and, where
applicable, the human-AI team.

Q12) 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?

Sponsors should account for variability in both the input population and the device’s
probabilistic outputs. Prespecify clinically meaningful endpoints, acceptance thresholds,
sample-size rationale, repeated-run designs, subgroup analyses, missing-data handling, and
multiplicity controls. Repeated outputs from the same case should not be treated as
independent patient observations. Acceptance criteria should use confidence bounds
appropriate to the endpoint, for example, a lower confidence bound above a minimum
performance threshold or an upper confidence bound below a maximum failure rate. Rare
severe failures should have separate acceptance criteria and should not be obscured by
favorable aggregate performance.

When synthetic inputs supplement real patient data, sponsors should characterize
differences in clinical prevalence, severity, comorbidities, subgroup representation, language,
missingness, and other factors affecting performance. Report synthetic and real-patient
results separately unless comparability is demonstrated. Any weighting or adjustment used to
estimate real-world performance should be justified against the intended-use population, with
sensitivity analyses addressing distribution differences and uncertainty. Synthetic cases may
strengthen challenge testing but should not be counted as equivalent real-patient
observations without supporting evidence.

Combining benchmarking and clinical-confirmation evidence into a single performance
estimate should be exceptional and prespecified. It should require compatible endpoints and
scoring methods, sufficiently comparable populations and conditions, the same defined
device configuration, demonstrated concordance, and accounting for overlapping cases or
other dependencies. Benchmark performance should independently meet a minimum
acceptance threshold so that pooling cannot conceal underperformance. Where statistical
borrowing is used, its contribution should decrease when evidence sources disagree.
Sponsors should retain separate source-specific results and demonstrate that the combined
estimate remains clinically interpretable.

Q13) 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?

Synthetic data is particularly useful as supplemental evidence for controlled stress testing,
rare safety-critical scenarios, boundary conditions, missing or contradictory inputs, and early
development. It can help test defined behaviors such as escalation, scope adherence, toolfailure recovery, and robustness to input variation. However, generating a plausible scenario
does not establish that it accurately represents real-world clinical presentation or frequency.
Synthetic data is less suitable for establishing performance where evaluation depends on
subtle patient language, complex comorbidities, longitudinal clinical relationships, real-world
imaging characteristics, or populations poorly represented in the generator’s source data. It
should not serve as the primary evidence of clinical performance for high-risk outcomes or
underrepresented subgroups.

To reduce shared blind spots between the generator and the device under evaluation,
sponsors should document generation methods, model versions, source data, and
assumptions; validate clinical plausibility and subgroup fidelity against independent realworld data; and use qualified clinical reviewers rather than relying solely on another model’s
judgment. Using a different model family may reduce shared errors but should not be treated
as proof of independence or representativeness.
Sponsors should deliberately include cases that challenge known weaknesses of both the
generator and the evaluated device, retain real-patient evaluation sets not used in generation
or development, and report synthetic and real-world results separately. For underrepresented
populations, synthetic augmentation should supplement efforts to obtain representative real
data, not substitute for evidence that the device performs safely and effectively in those
populations.

Q14) 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?

Comparators and acceptance criteria should match the device’s intended clinical task,
claims, users, and deployment workflow. For open-ended outputs, use prespecified, clinically
grounded scoring rubrics that recognize multiple acceptable responses while separately
assessing factual correctness, completeness, appropriate uncertainty, escalation, and safetycritical errors. Objective reference standards should be used where available; aggregate
accuracy should not conceal unacceptable critical failures.

When a qualified clinical panel provides the reference, sponsors should define its expertise,
applicable clinical guidance, adjudication procedures, and handling of disagreement or
legitimate variation in practice. The standard of care should inform clinical acceptability, while
observed clinician performance may provide a comparator for assessing the device’s
incremental contribution. Performance of a median clinician should not automatically define
an acceptable safety threshold.

Specialist expertise should establish the reference where the task requires specialist
judgment. Generalist users should participate where they represent the intended users. These
roles should be distinguished: a specialist panel may establish clinical correctness while
generalists evaluate how safely the device supports their actual decisions.

Human-AI team performance should be a primary basis for evaluation when safety and
effectiveness depend on users interpreting, verifying, or acting on device outputs. Where
appropriate, compare human alone, AI alone, and human-AI together to establish the pairing’s
incremental benefit and identify automation bias or interaction-related harm. For autonomous
functions, evaluate the device’s independent performance and complete action sequence
without crediting human review that is absent from the intended workflow.
Q15) 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?

Comparing performance with the care pathway likely to occur without the device can
demonstrate clinically meaningful benefit that an idealized reference alone may not capture.
Appropriate comparators may include unaided clinical judgment, existing technology, current
workflows, delayed specialist review, or no intervention where ethically appropriate. The
choice should be tied to the device’s placement in the two-axis framework. A comparator
based on the care likely to occur without the device may be appropriate where access to
standard care is limited, including for some higher-consequence functions, because these
settings are often where a device’s potential benefit is greatest. As consequence increases,
however, outperforming constrained usual care should not be sufficient on its own: higherconsequence functions should also meet prespecified absolute safety and performance
thresholds grounded in the clinical standard of care. Any device relying on a counterfactual
comparator should still demonstrate a reliable escalation pathway to real care when a
situation exceeds what it can safely handle.

Sponsors should identify and prospectively justify the comparator using evidence from the
intended deployment setting, such as workflow mapping, usual-care records, referral
patterns, specialist availability, and time to assessment or treatment. The comparison should
reflect the same patient population, clinical circumstances, and relevant access constraints,
with differences accounted for in the study design and analysis.

Endpoints should capture the device’s effect on the care pathway, including clinical
outcomes, time to appropriate care, missed or unnecessary interventions, and patient or
clinician burden. The comparator should represent likely practice rather than be selected to
favor the device. Improvement over constrained usual care should not, by itself, establish
acceptable safety; the device should also meet prespecified clinical and safety criteria. Nointervention comparisons should not require withholding indicated care.

Q16) 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?

Qualified independent third parties should contribute selectively where they strengthen
evaluation integrity, including provision of sequestered datasets representative of the
intended-use population, specialist adjudication, reproducibility testing, and clinical
confirmation of high-consequence functions. Independent participation need not extend to
every development or assessment activity, and it should not transfer responsibility for device
safety and effectiveness away from the manufacturer.
Qualifications should be specific to the assessment performed and include relevant clinical or
technical competence, validated evaluation methods, data-integrity controls, confidentiality
protections, and documented independence. Conflict-of-interest criteria should address
financial relationships and prior involvement in developing the device, benchmark, or
submission strategy. A party should not independently adjudicate work it helped design.
Appropriate accreditation may support competence for activities within its scope, but should
not substitute for task-specific qualifications.

Third-party involvement may be impractical for proprietary development activities, rapidly
changing configurations, or evaluations requiring extensive access to sensitive patient data or
deployment-specific workflows. FDA should distinguish these activities from final
independent assessment and define any high-consequence circumstances in which
independent adjudication is necessary. In those circumstances, independence would be
required, but use of an external third party should remain voluntary: an equivalent sponsor-run
pathway should be available that demonstrates comparable evaluation integrity, including
independence from the development team. For this purpose, independence should mean
independence from the development team, not necessarily from the sponsoring organization,
and third-party custody should be one way, not the only way, to demonstrate sequestration.
Pathway recommends that FDA consider, following the pilots described below, a formal
accreditation program for independent AI benchmarking and evaluation bodies, modeled on
the existing ASCA program, with published minimum qualification and independence criteria
and a public registry of accredited evaluators and of available benchmark datasets, listing
each dataset’s scope and access terms, open to sponsors of all sizes. Listing a sequestered
dataset should not make its contents public; access should remain controlled to preserve
sequestration and limit contamination (see Q10). Third-party roles should be focused on
maintaining sequestered evaluation datasets, independent expert adjudication,
reproducibility testing, and, where warranted, clinical confirmation of high-consequence
functions, and third-party determinations should inform and not substitute for FDA’s own
review.

Program safeguards should include transparent qualification criteria, predictable timelines
and fees, protection of confidential information, and sufficient evaluator capacity. Pilots
should assess interlaboratory reproducibility before results support consensus standards or a
potential standards-based accreditation pathway. Pooled or subsidized adjudication panels
could improve access for smaller sponsors without lowering evidentiary expectations.

Q17) 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?

The competency-based approach can apply across model architectures when requirements
are defined at the device-system level and evidence is tailored to the architecture’s failure
modes. However, text-oriented benchmarks and final-answer accuracy alone may be
insufficient for multimodal vision-language models or generative and predictive world models.
For multimodal devices, evaluation should establish that the device appropriately uses each
clinically relevant modality rather than reaching a correct answer through textual clues or
other shortcuts. Modality ablation and perturbation testing should assess behavior when
images, text, or other inputs are removed, corrupted, contradictory, or misaligned. Testing
should cover acquisition and preprocessing pipelines, input provenance, cross-modal
consistency, and modality-specific subgroup performance. A taxonomy of cross-modal errors
would support consistent evaluation and investigation. Clinical confirmation for visionlanguage devices should use relevant multi-reader, multi-case approaches where
appropriate.

For world-model devices, evaluation should address temporal and spatial reasoning,
prediction over clinically relevant time horizons, accumulation of error across simulated
trajectories, and correspondence between simulated and observed real-world behavior.
Plausible generated scenarios should not be treated as evidence of accurate prediction.
Where predictions inform actions, testing should assess the consequences of prediction
errors and the effectiveness of intervention and recovery controls.

Across architectures, sponsors should demonstrate safety and clinical proficiency of the
complete deployed configuration, including its handling of missing inputs and uncertainty.
Synthetic images and simulated trajectories should be independently assessed for real-world
fidelity, with representative clinical evidence used to confirm that benchmark performance
transfers to the intended use.
 Appendix 3

Section VI: Postmarket Monitoring for GenAI Enabled Devices

Q18) 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?

Greater reliance on postmarket monitoring may be appropriate when residual uncertainty is
explicitly characterized, essential premarket safety and effectiveness evidence is established,
and remaining questions can be resolved through monitored clinical use before unacceptable
harm occurs. The justification should identify which uncertainties are being deferred, why
postmarket evidence is suitable to resolve them, and the timeframe and criteria for doing so.

Sponsors should demonstrate versioned configuration control and output traceability; a
reproducible performance baseline; prespecified monitoring thresholds, reassessment
triggers, and acceptance criteria; staged release; and tested rollback, restriction, or safe-state
mechanisms. The monitoring program should have access to representative deployment data,
defined responsibilities and response times, and sufficient sensitivity and timeliness to detect
clinically important degradation and safety-critical failures. Plans should include
investigation, corrective action, and escalation to FDA when warranted. Monitoring feasibility
should account for deployment volume, subgroup representation, data availability, and the
time needed to detect rare events. For each deferred uncertainty, the sponsor should justify
that the combined time to detect, triage, decide, and contain a failure is compatible with the
time to potential harm, and should demonstrate these response capabilities before
deployment, including outside normal business hours where the intended use requires it.
Statistical detection capability alone does not establish that intervention will occur in time.

Reduced premarket evidence should not be justified by monitoring that is unlikely to detect a
severe failure until after harm has occurred. As a condition of accepting reduced premarket
evidence, the postmarket monitoring plan should be prespecified, reviewed at the premarket
stage, and statistically able to detect, within a defined time, the specific failure modes that the
reduced premarket evidence leaves unresolved. The monitoring program should be validated
and operational before market authorization and not merely committed to, should include a
mechanism for detecting failures independent of manufacturer or model-developer selfreport, which should be recognized as an assumption and not a given, and should include a
fleet-level component for multi-site deployments. Reliance on postmarket monitoring in place
of premarket evidence would generally be inappropriate for functions involving highconsequence autonomous actions, difficult-to-reverse harms, or a short interval between
error and injury. It would also be inappropriate where configuration changes cannot be reliably
identified, monitoring data are unavailable, or effective intervention cannot be assured.
Postmarket monitoring should resolve defined residual uncertainty, not substitute for
demonstrating essential safety before deployment. Because postmarket monitoring is
inherently reactive, sponsors should reduce risks as far as possible before deployment, with
more stringent risk controls for autonomous and agentic functions, while recognizing that
some residual uncertainty will remain for GenAI-enabled devices and may appropriately be
addressed through monitoring.

Q19) 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?

Periodic re-benchmarking, sample-based clinician review, and performance degradation
monitoring should be used as complementary approaches. Re-benchmarking supports
comparison with a controlled baseline; clinician review identifies clinically meaningful errors
and interaction problems; and ongoing monitoring can detect changes between scheduled
assessments. Additional approaches should include sentinel testing for silent supplier
changes, subgroup and deployment-site analyses, cybersecurity and data-integrity
monitoring, and review of clinical outcomes and near misses where available. Postmarket
evaluation should also track the device’s rate of silent errors (fluent, plausible outputs that are
wrong or unfaithful to their sources) over time, not accuracy alone. A well-formatted output is
not evidence that it is correct, and a model’s own rationale or chain of thought is not reliable
audit evidence.

Pathway recommends that FDA add fleet-level, common-mode failure monitoring as an
explicit postmarket evaluation approach. A confirmed safety-relevant failure at any single
deployment site should trigger an expedited review across all other deployment sites running
the same underlying model or shared dependency, within a defined short timeline that is
separate from and faster than the routine reassessment cadence. For higher-risk or widely
deployed products, sponsors should maintain a scalable common-mode failure response
plan, and material outages of shared dependencies such as cloud, identity, or foundationmodel services should be assessed for reportability under existing mechanisms, including
medical device reporting (21 CFR Part 803) and reports of corrections and removals (21 CFR
Part 806). FDA should clarify when such fleet-wide events are reportable and whether they
may be reported once at the fleet level rather than only as individual unit-level events.

Sponsors should define a minimum reassessment cadence for each risk tier, informed by
severity, autonomy, exposure volume, time to harm, configuration stability, and monitoring
sensitivity. Event-based triggers should include behavior-relevant configuration changes;
supplier change notices; failed sentinel tests; breached drift thresholds; new sites,
populations, languages, workflows, or tool integrations; complaint or adverse-event trends;
security changes affecting the AI pipeline; and updates to relevant clinical guidelines.

Reassessment should compare the identified deployed configuration with the authorized
baseline, including cumulative change rather than only differences from the immediately
preceding version. Its scope should follow a documented impact assessment and include the
safety elements S.1–S.3 as a regression set. Samples for clinical review should represent
intended use while deliberately including high-risk cases, underrepresented subgroups, and
cases flagged by monitoring. Monitoring should rest on tamper-evident, human-readable
records that allow an output and its basis to be reconstructed independently of the model,
consistent with ALCOA+ data-integrity principles, 21 CFR Part 11, and QMSR record
requirements. Content-addressable storage and similar integrity-by-design approaches are
one practical basis for such records.

Monitoring should also address changes in the human-AI relationship, including clinician
acceptance, rejection, modification, override, and independent verification of
recommendations. Increasing acceptance alone does not establish unsafe reliance, but
changes in these indicators, interpreted alongside clinical performance and workflow
evidence, may reveal that nominally supervised use is becoming more autonomous in
practice. Monitoring plans should define how such signals trigger investigation, reassessment
of safeguards, and corrective action. Plans should also define a human containment control:
an authorized ability to pause or stop the function, so that a detected failure can be contained
rather than only logged.

Q20) 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?

Machine-based supervisory agents can facilitate postmarket monitoring by screening
interactions, identifying potential safety failures, and detecting performance changes at scale.
However, the supervisor should be treated as a controlled, versioned component validated for
its specific monitoring function, rather than assumed to be reliable because it uses AI.

Evaluation should establish detection sensitivity, specificity, timeliness, and performance
across clinically relevant failure modes, subgroups, and deployment conditions. Testing
should include known failures, plausible incorrect outputs, adversarial inputs, and cases the
supervisor fails to flag. Human review should cover escalations and a risk-based sample of
non-escalations to detect false negatives and emerging blind spots. Alert burden and the
receiving team’s ability to investigate and respond should also be assessed.

Prompts, thresholds, models, retrieval sources, and tool permissions should be under change
control, with revalidation proportionate to changes that could affect monitoring performance.
A supervisory agent should be credited as satisfying a postmarket monitoring requirement only
where its independence from the monitored device has been demonstrated and documented.
Independence should be assessed through separation of control and evidence pathways,
evaluation of correlated failures, and demonstrated detection performance, including the
supervisor’s own sensitivity, specificity, and failure modes; shared model or data
dependencies should be disclosed and mitigated in proportion to risk. Absent that
demonstration, the supervisor’s output should be treated as a supplementary signal requiring
separate human-led verification and should not be credited as postmarket evidence.
Sponsors should assess common-mode failures between the supervisor and the monitored
device. A different model family or provider may reduce correlated errors but does not
establish independence by itself; deterministic checks and independently captured evidence
can provide additional protection.
The supervisor should not be able to alter authoritative monitoring records, source evidence,
or its own acceptance criteria. Plans should define clinically appropriate responses to
supervisor failure, loss of connectivity, or degraded detection, including alternative monitoring
and restrictions on device operation where necessary. Supervisory agents should support,
rather than replace, manufacturer accountability and effective human investigation.

Q21) 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?

Postmarket monitoring should involve shared activities with clearly assigned responsibilities
while preserving manufacturer accountability for device design, validated configurations,
investigation of device-related performance signals, and corrective action. Manufacturers
should define monitoring requirements, integrate signals across deployments, assess
changes, and communicate findings and necessary actions to affected users. Distributed
monitoring roles supplement and do not substitute for or diffuse the manufacturer’s ultimate
accountability for the safety determination, which should remain with a single accountable
party even where data collection or initial signal detection is distributed.

Clinicians should contribute reports of clinically significant errors, near misses, inappropriate
recommendations, and changes in reliance on device outputs. Healthcare institutions should
support local monitoring, preserve relevant configuration and interaction records, and report
performance concerns and site-initiated changes outside validated configuration ranges.
Labeling and implementation agreements should identify which items may be configured
locally, their validated limits, and when manufacturer assessment is necessary.

Foundation-model and platform providers should supply relevant change notifications and
information needed to investigate upstream failures. Professional societies can support
clinically meaningful endpoints, reporting definitions, and expert adjudication, while
standards-setting bodies can develop interoperable reporting formats and reproducible
evaluation methods. Patients and caregivers should have accessible channels for reporting
concerns and receiving feedback.

A responsibility matrix should specify reporting channels, notification timelines, investigation
ownership, monitoring-data access, privacy protections, and corrective-action
communication. Data-sharing and supplier agreements should make these responsibilities
operational rather than merely describe them. FDA should clarify how timely notification of
safety-relevant local changes and access to necessary field-performance data can be
assured, including when enforceable obligations may be needed. For each safety-relevant
signal, the matrix should identify the accountable decision owner, action owner, response
deadline, backup coverage, and escalation route if another party does not respond, and the
end-to-end workflow should be exercised with manufacturers, suppliers, and deployment
sites before launch and after material changes. Manufacturers should remain accountable for
reasonably foreseeable changes and events and should anticipate them through supplier
controls, risk management, and monitoring design. However, manufacturer accountability
should not presume visibility into changes or events that other parties control but do not
disclose. For this reason, manufacturer accountability should be paired with enforceable
notification and data-access obligations on suppliers and deploying organizations.
These activities should be integrated into existing clinical governance, quality, cybersecurity,
and incident-reporting processes where feasible, rather than automatically requiring
additional oversight committees.

Q22) 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?

The extent of reassessment should follow a documented impact assessment of the change’s
expected behavioral and clinical effects, rather than its technical label. A prompt, retrievalsource, or tool-permission change may be more consequential than a model update.
Assessment should consider affected functions, hazards, safeguards, deployment conditions,
and uncertainty about downstream effects.

Pathway proposes three change categories:

1. Changes with no expected effect on clinical behavior or safety controls: Manage
within the quality management system, with documented justification and
proportionate verification or regression testing. Examples may include administrative
changes or nonclinical interface text, provided their lack of effect is established rather
than assumed.

2. Behavior-relevant changes within an authorized PCCP: Apply the plan’s
prespecified impact assessment and validation methods. Re-benchmark affected
competencies and include a safety regression set covering S.1–S.3. Potential
candidates include bounded prompt revisions, retrieval updates, or specified model
updates where permitted by the plan; the change type alone does not establish
eligibility.

3. Changes outside the authorized boundaries or with potentially significant effects
on safety or effectiveness: Assess the need for FDA premarket review before
implementation. Examples include changes to intended use, autonomy, target
population, modality, or safety controls that exceed the authorized scope. FDA should
clarify these boundaries through worked examples rather than treat every change
within these categories as automatically requiring a new submission.

Reassessment should compare performance with both the preceding configuration and the
originally authorized baseline to identify cumulative drift. Sponsors should define limits and
triggers for broader reassessment or regulatory review when successive changes collectively
exceed validated boundaries. When benchmark assets are refreshed, documented bridging
should preserve comparability and clinical relevance.
Q23) How might PCCP concepts or other change-control approaches be adapted for
GenAI-enabled devices when the nature or scope of future modifications cannot be fully
prespecified?

FDA could consider a bounded PCCP approach that prespecifies permitted categories of
change, the process for evaluating them, and fixed clinical and operational limits, even when
individual future modifications cannot be fully described. Authorization should apply to
defined changes within that envelope rather than provide unrestricted permission to modify
the device.

The plan should identify affected configuration items; permitted change types; boundaries for
intended use, population, autonomy, and risk profile; controlled benchmark suites and
acceptance criteria; and a prespecified impact-assessment method. Each candidate
configuration should undergo proportionate verification and validation before release,
including safety regression testing and assessment of cumulative change against the
authorized baseline. Benchmark replacement should require documented bridging.

Deployment controls should include staged release where appropriate, defined monitoring
and stopping criteria, tested rollback or safe-state mechanisms, and traceable change
records and reporting. Continuously adaptive behavior should have defined update
boundaries and validation checkpoints rather than allow unassessed changes to enter
production.

A change outside the authorized envelope should trigger assessment of the need for a new
submission or other FDA review before implementation. Failure to meet acceptance criteria
should prevent release and prompt investigation, correction, and reassessment; it should not
automatically be treated as a reason to seek authorization for the failed configuration. For
changes that cannot be fully prespecified, FDA could consider a graduated authorization structure
in which a PCCP begins with a narrow, well-defined change scope, and expansion to a broader
scope is permitted only after monitored performance evidence demonstrates safe handling of the
narrower scope, rather than a single broad prospective authorization. Broader privileges would be
earned in stages through demonstrated performance, as in graduated licensing.

Q24) 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.

Manufacturers should treat foundation-model providers as critical suppliers under the quality
management system, with agreements addressing identified model versions, advance change
and deprecation notices, change logs, investigation support, and continuity arrangements.
Production should use an identified, pinned model snapshot where available. Pathway does
not recommend that the inability to pin a model version be treated as a design deficiency by
default. Version pinning is one control among several and does not by itself establish that
device behavior is unchanged, and many manufacturers, particularly smaller sponsors,
cannot negotiate guaranteed pinning or contractual change notice with the small number of
frontier-model providers. Responsibility for upstream change should be shared: providers are
best positioned to disclose planned changes and their timing, while manufacturers are
responsible for defining risk-based acceptance thresholds and verifying that the deployed
configuration remains within them. Supplier controls should cover behavior-relevant changes
to safety policies, routing, and serving infrastructure, not only model weights or published
version numbers.

The same controls should apply when an existing, already-qualified supplier introduces GenAI
capabilities into a component, software library, cloud service, or platform it already provides,
including AI features embedded in off-the-shelf software. Such a change should trigger
supplier requalification and a documented impact assessment using the change categories
described in Q22, rather than being treated as a routine continuation of an approved supply
relationship. Where a GenAI feature is added to a marketed device through an existing
supplier, the manufacturer should determine whether it constitutes a modification and
identify the applicable regulatory pathway before clinical use. Supplier agreements should
require advance notice before AI capabilities are introduced or enabled, allow the
manufacturer to keep them disabled until assessed, and make clear that responsibility for
evaluating and authorizing their use remains with the manufacturer, even when the supplier
controls activation.

Technical controls should establish baseline run-to-run variability and combine riskproportionate sentinel testing, output-distribution monitoring, and statistical drift detection.
Version logging alone cannot establish that the deployed service is unchanged, while stable
outputs alone cannot exclude an upstream change. Supplier information and independent
technical evidence should therefore be used together.

On notification or detection of a change, manufacturers should assess its effects on the
complete deployed configuration, affected competencies, hazards, and safeguards; conduct
targeted re-benchmarking and safety regression testing; and determine whether continued
operation remains within validated boundaries. Response plans should specify risk-based
investigation and decision timelines, escalation criteria, and tested rollback, restriction, or
safe-state options. Any fallback model should be validated as a separate configuration, and
planned migration should undergo change control.

While a suspected supplier change is under investigation, sponsors should have prespecified
who may authorize continued operation, restriction, or suspension; the evidence required for
that decision; and the maximum investigation interval justified by device risk. The plan should
be exercised for a silent update, a supplier outage, and model retirement, including cases
where the prior service cannot be restored.

A PCCP may specify permitted categories of upstream change and their verification and
validation requirements, but should not be assumed to cover unanticipated changes outside
its authorized boundaries. Where pinning or adequate supplier notice is unavailable,
manufacturers should document the limitation, justify continued reliance on the dependency,
and demonstrate compensating controls, such as continuous sentinel testing and outputdistribution monitoring, sufficient for the device’s risk profile. If adequate assurance cannot be
established, the dependency should be redesigned, the supplier changed, or deployment
restricted. FDA could also encourage foundation-model providers to offer standardized
change-notification commitments for healthcare uses, which would reduce disparities
between large and small sponsors.
 Appendix 4

Section VII: Other Topics

Q25) 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 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?

Voluntary Foundation Model Master Files could improve premarket review efficiency by
allowing developers to provide a reusable, confidential package of safety-relevant information
that multiple sponsors can reference. Their practicality and value would depend on
standardized content, version-specific records, and reliable maintenance. A general model
description should not be treated as evidence for a materially different version or serving
configuration.

Content should include an immutable model identifier and release date; architecture and
interface boundaries; relevant training-data provenance; healthcare-relevant performance
and subgroup evaluations; known limitations and failure modes; guardrails and cybersecurity
controls; version history and behavioral changes; serving-layer and safety-policy changes;
audit-log availability; change-notification commitments; and deprecation or end-of-support
dates. Limitations and undisclosed information should be explicit. Letters of authorization
should identify the versions referenced, and relevant updates should notify authorized
sponsors.

To encourage participation, FDA could establish a common information template and
reference process that reduces duplicative sponsor requests while protecting confidential
information. Nevertheless, voluntary participation will leave gaps. A MAF should supplement—
not replace—the manufacturer’s supplier qualification, validation of the complete deployed
configuration, and independent detection of upstream changes. FDA should clarify how
missing or outdated information affects the evidence needed from a sponsor.

Alternative or complementary mechanisms could include standardized independent
foundation-model assessments, structured supplier disclosures and quality agreements, and
risk-tiered runtime records identifying the model, harness, retrieval sources, tools, and
controls actually used. These records should follow data-minimization principles and provide
configuration traceability rather than presume access to hidden model reasoning. Relevant
dependencies, including hosting and serving providers, should also be addressed where they
can change device behavior.
Q26) 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?

Agentic devices require evaluation of complete action sequences, not only individual outputs
or tool calls, because errors can compound across planning, execution, and feedback. Testing
under benchmarking element A.1 should assess task decomposition, tool selection,
verification of tool outputs, cascading failures, and whether intermediate actions remain
within the device’s intended use and authorized scope.

Tool permissions, action and transaction limits, approval checkpoints, orchestration logic,
and persistent memory should be controlled configuration items, with changes assessed
through the approach described in Q22. Least-privilege access and independently enforced
controls should prevent unauthorized actions, including attempts to bypass safeguards
through prompt injection, retrieved content, tool outputs, or delegated agents. Highconsequence or irreversible actions should have defined, validated approval checkpoints,
with human authorization where meaningful clinical judgment is required.

The deploying organization should explicitly approve an agent’s delegated scope within the
manufacturer’s validated intended use and limits, including permitted tools, actions, and
approval thresholds, so that evaluation and monitoring reflect what has actually been
delegated and how far an error can propagate before a human intervenes. Loss of supervisory
or cloud connectivity should trigger a validated, clinically appropriate fallback, which may be
continued bounded operation or a clinical handoff rather than an abrupt stop. Recovery
should reconcile completed and pending actions and prevent duplicate or unauthorized
execution.

Acceptance criteria should address unauthorized actions, missed approval checkpoints,
clinically significant sequencing errors, and failures to detect incorrect tool results (not merely
successful task completion). Testing should verify safe interruption, cancellation, recovery,
and partial-workflow behavior, including situations where an action cannot be rolled back. A
favorable overall success rate should not compensate for an unacceptable safety-critical
failure rate.

Postmarket oversight should retain configuration-linked records of planned and executed
actions, tool calls, approvals, and observed outcomes, captured independently of the agent’s
own account of its performance. Monitoring should detect changes in actual autonomy,
permission use, and failure patterns. Defined stopping criteria, intervention times, and safestate responses should account for the interval between an erroneous action and potential
harm, particularly where human review is limited or unavailable.
 Appendix 5

General Comments

Pathway supports FDA’s consideration of a risk-based, total product lifecycle approach to
GenAI-enabled medical devices. Across the discussion paper, we recommend clarifying the
unit being evaluated and controlled, integrating GenAI-specific assurance into existing quality
processes, and addressing the dependencies that determine performance after deployment.
Our question-specific recommendations are provided in the appendices.

Clarify the evaluation challenge
Pathway agrees with the discussion paper’s recognition (Sections II and V) that evaluating
every conceivable input is not feasible for GenAI-enabled devices. Exhaustive testing is also
not feasible for many existing devices, which are evaluated on representative samples. Future
guidance would benefit from distinguishing the additional challenges posed by GenAI,
including open-ended interactions, variable outputs, emergent behavior across multiple turns,
and dependencies that can change without a manufacturer-initiated software release. This
distinction would help identify where established methods remain applicable and where
additional evidence or controls are necessary.

Define the controlled device configuration
FDA should define “device configuration,” “version,” and “modification” to support consistent
evaluation, change control, and monitoring. The behavior-determining configuration may
include the foundation-model snapshot, fine-tuned weights, prompts, retrieval sources and
indexes, memory or personalization stores, guardrails, orchestration, tool permissions,
inference settings, preprocessing and postprocessing, and user interface. Changes to these
items can affect safety or effectiveness without a conventional code update or retraining
event.

Sponsors should identify released configurations and maintain traceable change records. The
benchmark suite and scoring methods used to evaluate a release should also be identified
and controlled, while remaining distinguishable from the deployed configuration itself.

Integrate with existing quality and risk processes
Future guidance should explain how the proposed framework fits established risk
management, design and software lifecycle controls, usability engineering, supplier controls,
change control, complaint handling, and corrective and preventive action. A mapping to
relevant standards and quality-system processes could identify GenAI-specific gaps without
creating duplicative assurance activities. Additional controls should address demonstrated
gaps rather than automatically require separate governance structures or oversight
committees.

Establish controlled evaluation baselines
The initial competency assessment should provide a controlled reference for evaluating
subsequent changes. Its supporting records should identify datasets, scoring rubrics,
adjudicator qualifications and evaluator versions where applicable, run conditions, repeatedrun designs, acceptance criteria, and results for the evaluated configuration.
Benchmark assets should remain controlled within each version, with documented bridging
when contamination, saturation, or changes in clinical practice necessitate replacement.
Comparisons should account for run-to-run variability and preserve a meaningful connection
to the authorized baseline rather than rely solely on point estimates or comparisons with the
immediately preceding release.

Address cybersecurity and data integrity throughout the lifecycle
Cybersecurity and data integrity should be explicit, cross-cutting considerations. Benchmark
datasets, retrieval content, memory stores, training data, and information returning from
deployment can influence both device behavior and the evidence used to assess it. Controls
should address provenance, access permissions, version identification, change logs, and
integrity verification, with distinctions between configuration assets, source records, and
generated content.

Evaluation should address prompt injection, data poisoning, tool manipulation, and
unauthorized changes to safety controls. FDA should also consider when independently
enforced deterministic checks, permission boundaries, and hard limits are appropriate to
prevent generative or agentic behavior from exceeding validated boundaries. Their
effectiveness should be demonstrated; their presence alone should not establish adequate
risk mitigation. FDA should make clear that GenAI-specific threats such as prompt injection,
retrieval poisoning, and tool manipulation are clinical hazards to be addressed in
benchmarking and clinical confirmation, and not only matters for premarket cybersecurity
review under section 524B of the FD&C Act, so that they do not fall into a gap between security
review and clinical performance evaluation.

Make adaptive behavior and deployed outputs traceable
For devices designed to adapt during use, sponsors should specify what may change, the
permitted boundaries, validation checkpoints, and conditions for promoting an adapted
configuration into clinical use. These provisions should cover changes to memory,
personalization, and retrieval content as well as model weights. The approach should
distinguish ordinary operation within validated adaptive limits from a modification requiring
further assessment.

Monitoring records should connect clinically relevant outputs and actions to the configuration
that produced them. Sponsors should retain sufficient release and configuration information
to support investigation and, where feasible, reconstruction, with retention proportionate to
risk and privacy considerations. FDA should clarify how software-version identification,
including applicable UDI production identifiers, and user notification should operate for
frequently updated GenAI configurations.

Enable monitoring across organizational boundaries
Manufacturers cannot reliably assess field performance without timely information about
deployment conditions, local changes, and safety-relevant events. Labeling, supplier
agreements, implementation arrangements, and data-sharing agreements should define
validated configuration ranges, reporting channels, notification timelines, investigation
responsibilities, and access to necessary monitoring data.
FDA should clarify how these arrangements can provide dependable visibility into changes
controlled by foundation-model providers, healthcare institutions, and other parties while
preserving manufacturer accountability. Shared monitoring should establish actionable
responsibilities and feedback pathways, rather than diffuse ownership or assume that relevant
information will be voluntarily available.

Access to real-world performance data remains a practical barrier, particularly for smaller
manufacturers. Healthcare delivery organizations are often reluctant to share device
performance information because of liability and privacy concerns, even for devices without
AI. Because effective postmarket monitoring of GenAI-enabled devices depends on this
information, we encourage FDA to work with HHS and other partners to make appropriate
data-sharing arrangements more accessible, such as business associate agreements or deidentified data-sharing agreements that clearly define what information is collected, by whom,
and for what purpose.

Such agreements should be bilateral and specific. Whether the instrument is a business
associate agreement, where the manufacturer is a business associate under HIPAA, or a data
use or de-identified data-sharing agreement, it should define the data elements exchanged;
which party collects, stores, and controls them; permitted primary and secondary uses,
including research, data aggregation, and model training or improvement; provenance and
integrity requirements; and reciprocal security and breach-notification obligations.
Manufacturers that do not need identifiable patient information should not be expected to
receive it, and where they do, the agreement should reflect the resulting legal and risk
obligations. Agreements should also address how a compromise at any party, including the
manufacturer, will be identified, communicated, and contained, because data flowing from
the patient to the manufacturer and onward into studies, aggregated datasets, and model
updates can carry the effects of a single compromise both upstream and downstream. This is
increasingly important for GenAI-enabled devices and as the home becomes a hub for
healthcare delivery, where trust in aggregated real-world data depends on every party in the
chain. Pathway would welcome the opportunity to work with FDA, HHS, and other
stakeholders on model provisions for these agreements and related quality agreements.

Support proportionate implementation without lowering the bar
Evidence expectations should be driven by device risk and intended use rather than sponsor
size. Where a GenAI-enabled function presents high risk, the same controls should apply
regardless of a sponsor’s resources. At the same time, several recommendations in this
response, including independent benchmarking, clinical confirmation, and supplier controls,
may be disproportionately burdensome for smaller sponsors. FDA could reduce this burden
without lowering evidentiary expectations by supporting publicly available, curated
benchmark datasets; partnerships with independent organizations that provide shared
evaluation resources; and publicly funded shared evaluation infrastructure. Such
infrastructure could draw lessons from ARPA-H research programs, such as UPGRADE’s highfidelity digital twins of hospital equipment for simulated vulnerability and patch evaluation and
ADVOCATE’s use of an independent external evaluation partner, with access and methods
tailored to GenAI-enabled devices, including those from small businesses.

FDA could also explore, with ARPA-H and other HHS partners, a voluntary, governmentsupported testing pathway through which small and medium-sized manufacturers could have
devices evaluated, initially for cybersecurity and potentially for GenAI-specific failure modes
and receive detailed feedback before submission. Such a pathway would help these
manufacturers understand their vulnerabilities and meet federal expectations without
depending solely on commercial testing services. It should complement, and not replace, FDA
review, the Q-Submission program, and the manufacturer’s responsibility for device safety
and effectiveness.