Edge Compliance

We welcome CDRH’s timely and open engagement on GenAI-enabled devices and respond to the 26 discussion questions in the attached document.

Our core message is that hallucination is inevitable whatever a product’s intended use, so a common safety baseline should apply to all GenAI that can give health advice. Above that baseline, regulation should scale to intended use and risk through existing pathways, with a stronger post-market focus and international alignment. Done well, and with HCPs equipped to use it, GenAI can close long-standing care gaps, notably in women’s health, rather than deepen them.

Edge Compliance is a Zurich-based regulatory consultancy specialized in the boundary between medtech and wellness across international frameworks. Our clients are predominantly women’s health startups based worldwide, many with the U.S. as a key target market.

Advising on the claims and guardrails of GenAI health products is an area where we increasingly support clients. Our comments draw on that boundary work, on the necessary alignment with other regulatory frameworks and on learnings from use cases in women’s health, where data gaps, stigma and delayed diagnosis weigh heavily on the benefit-risk balance. We see validated, transparent GenAI as a real opportunity to close some of those gaps.

We make the eight key points below, elaborated in the attached file both as an executive summary and detailed question-by-question response.

1. All GenAI that can give health advice should meet a standards-based safety baseline, judged by what it can do rather than by its claims
2. Regulatory classification should be driven by consequence and actionability for the intended use alone, while hallucination, misuse and detection latency should inform risk management and design
3. Existing wellness, enforcement discretion and Non-Device CDS mechanisms remain broadly fit to decide the regulatory pathway, though not whether the baseline applies; they need reconsideration and clarification for GenAI
4. Competency-based evaluation already has many parallels between devices and HCPs; ethical guardrails, staged releases and a re-benchmarking schedule would align them further
5. GenAI can close care gaps or, if not benchmarked and validated, deepen them, most of all in women’s health and for minorities
6. Building HCPs’ competence in and involvement with GenAI is a priority and a shared responsibility of manufacturers and government
7. The nature of probabilistic software requires a stronger postmarket focus for testing and usability, as long as premarket evidence is proportionate to the device’s risk level
8. Foundation model safety information should be harmonized across regulators, with master files complemented by public summary safety cards

​

Hardturmstrasse 161, Zurich, Switzerland ​
edgecompliance.co

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

We welcome CDRH's timely and open engagement on GenAI-enabled devices and respond to the
26 discussion questions in the Annex to this submission.

Our core message is that hallucination is inevitable whatever a product’s intended use, so a
common safety baseline should apply to all GenAI that can give health advice. Above that baseline,
regulation should scale to intended use and risk through existing pathways, with a stronger
postmarket focus and international alignment. Done well, and with HCPs equipped to use it,
GenAI can close long-standing care gaps, notably in women’s health, rather than deepen them.

Edge Compliance is a Zurich-based regulatory consultancy specialized in the boundary between
medtech and wellness across international frameworks. Our clients are predominantly women’s
health startups based worldwide, many with the U.S. as a key target market.

Advising on the claims and guardrails of GenAI health products is an area where we increasingly
support clients. Our comments draw on that boundary work, on the necessary alignment with
other regulatory frameworks and on learnings from use cases in women's health, where data gaps,
stigma and delayed diagnosis weigh heavily on the benefit-risk balance. We see validated,
transparent GenAI as a real opportunity to close some of those gaps.

We make eight points, elaborated below in summary and detailed question-by-question in the
Annex.

1. All GenAI that can give health advice should meet a standards-based
safety baseline, judged by what it can do rather than by its claims

Hallucination is inevitable whatever a product's intended use. A GenAI tool supporting conception
and one supporting contraception differ greatly in risk, yet both can drift into diagnosing other
conditions, giving emergency advice or advising pregnant women and other vulnerable users.
General-purpose and wellness GenAI already give directional health advice at scale, including
features that explain users' own medical records, images and test results, while staying outside
device oversight through their claims.

We therefore propose a standards-based baseline for any GenAI that can give health advice,
judged by what it can do rather than by what it claims. It should cover scope and refusals,
including over- and under-escalation; behavior over long conversations, where drift and
sycophancy grow; misuse, security and the privacy of intimate data, which is critical in
reproductive health; and transparency about being AI, its sources and its limitations.

Just as the General Wellness guidance already expects validated values from wellness wearables,
any health GenAI should be expected, as good practice, to hold evidence of safety benchmarking
even when it does not qualify as a device. The development of a GenAI safety standard would help
standardize practice in the market and give manufacturers the opportunity to self-declare
conformity, as with other standards. Such a standard could be developed through consensus
standards bodies and recognized by FDA, referenced in FDA's wellness and enforcement discretion
policies as a factor in assessing low risk, and coordinated with the Federal Trade Commission,
which oversees health claims and, through its Health Breach Notification Rule, breaches of health
data held by apps outside HIPAA.

2. Regulatory classification should be driven by consequence and
actionability for the intended use alone, while hallucination, misuse and
detection latency should inform risk management and design

As with all medical devices, intended use should drive regulatory classification. We support the
FDA’s proposal of a two-axis framework based on consequence and actionability and provide
further details on how this could be applied in practice, taking existing FDA guidance into
account.

We propose activity levels that are not tied to directiveness or whether the user is a patient or HCP,
but rather based on what GenAI is designed to do, with clear boundaries on whether it qualifies as
a device. As such we introduce the concepts of:
●​ Contextual GenAI: explains a person's own health data against cited literature for
discussion with an HCP. Aligns to Wellness Policy, for Limited risks only.
●​ Assistant GenAI: supports an HCP who can verify the output. Aligns to Non-Device CDS
where all four criteria are met, otherwise a device.

Combinations would map to regulatory pathways indicatively as follows:

Severe Low Risk*​ High Risk​ High Risk​ High Risk​
n/a Non-Device CDS Class II / III Class III Class III
/ Enf. discretion
Moderate Low Risk​ Moderate Risk​ Moderate Risk​ High Risk​
n/a Non-Device CDS Class II Class II Class III
/ Enf. discretion
Limited Low Risk​ Low Risk​ Low Risk​ Low Risk​ Moderate Risk​
Wellness Non-Device CDS Class I / II Class I / II Class II
/ Enf. discretion
Conseq. \ Contextual Assistant Diagnostic Therapeutic Agentic
Activity
*Non-Device CDS if all four criteria met; otherwise per Diagnostic column.

We believe that GenAI should be assumed to hallucinate with certainty, in the same way IEC
62304 assumes software will fail . In line with this analogy, failure modes should inform risk
management and design, but not classification; otherwise almost every product would fall into the
highest class.

Mitigation does not change the class but sets minimum expectations within it, favoring controls
that are independent of the generative component: hardware limits and deterministic software first,
then guardrails and runtime QC models, then information for safety. Detection latency, the time
before a failure becomes visible, should shape both these controls and the clinical evidence strategy.
Federal Trade Commission. Health Breach Notification Rule, 16 CFR Part 318, as amended in 2024.
IEC 62304:2006+AMD1:2015, Medical device software: Software life cycle processes, clause 4.3
For agentic devices, we see the highest risk at device interfaces, typically APIs or MCP servers
through which an agent reads device data or sends commands. APIs are often regulated as separate
software functions, and in some cases as independent device functions, as with the data APIs of
connected CGMs , or an arrhythmia analysis device accessed only through its API by third-party
software . GenAI APIs and MCP servers could be treated in a similar fashion, with high-risk
devices requiring human authorization before any irreversible action, halt and rollback measures,
and tamper-evident logs (Q26).

3. Existing wellness, enforcement discretion and Non-Device CDS
mechanisms remain broadly fit to decide the regulatory pathway,
though not whether the baseline applies; they need reconsideration
and clarification for GenAI

The General Wellness policy, FDA's enforcement discretion for device software functions and the
Non-Device CDS criteria predate GenAI, yet they remain broadly fit to decide the regulatory
pathway of GenAI.

Just as they indicate the need for validation data for certain wellness examples, we believe these
guidelines should set out baseline safety conformity as expected good practice and a factor in
assessing low risk, rather than fully excluding such products from consideration.

We ask that FDA's future GenAI guidance set out clear interfaces with these three regulatory
instruments, in particular:

●​ whether informational, non-diagnostic patient-facing GenAI, which helps people
understand their own records and test results and prepare for their HCP, could rely on the
General Wellness policy or existing enforcement discretion, even where it processes data
types (such as IVD results or medical images) that would exclude an HCP-facing function
from Non-Device CDS under Criterion 1. Because the CDS criteria apply only to
HCP-facing functions, these patient-facing tools need their own clear position.
●​ how Criterion 4 of the Non-Device CDS criteria would apply to generative output, for
example whether traceable citations, disclosure of inputs and documented limitations let an
HCP independently review its basis. As the CDS criteria are set in statute (section
520(o)(1)(E) of the FD&C Act), we believe FDA's interpretation of them in guidance could
address GenAI without legislative change.

Exact wording cannot be controlled in GenAI, but instructions containing terms, sentence
construction, and tone to be avoided can be fed as input to guide its communication style. We
would welcome GenAI copy guidance from the FDA to inform the Wellness/Non-Device CDS
boundary, similar to the guidance that exists for the borderline between cosmetics and drugs. This
would help to standardize and de-risk those products that navigate the edge between wellness and
medtech, and ultimately lower surveillance burden for FDA.
FDA. 510(k) K201328, Dexcom G6 Continuous Glucose Monitoring System, cleared July 15, 2021
(Dexcom Partner Web APIs); see also K213919 and K231081 (Dexcom G7).
FDA. 510(k) K254255, S-Patch CardioAI (Wellysis), cleared September 2026; for further examples,
see Innolitics, September 2026 AI/ML FDA Clearances.
4. Competency-based evaluation already has many parallels between
devices and HCPs; ethical guardrails, staged releases and a
re-benchmarking schedule would align them further

Benchmarking followed by clinical confirmation mirrors how clinicians are examined and licensed:
intended use works as a scope of practice, and authorization as a license. Digital health can even
do better on feedback, since built-in reporting gives visibility of outcomes (a feedback loop) that
clinicians in small practices rarely have.

Three additions would align devices and clinicians further:
●​ Ethical guardrails: a code of conduct akin to the Hippocratic Oath (do no harm, stay
within competence, escalate when uncertain), embedded in an independent Rule-Based
Reward Model (RBRM) rather than left to the AI provider's defaults.
●​ Staged releases: many health innovators already move from wellness minimal viable
products (MVPs) to medical claims as evidence builds; standardizing staged deployment of
GenAI (e.g. shadow deployment, then supervised deployment, before full autonomous
deployment) would mirror the increasing responsibility given to HCPs in training with a
supervisor “in the loop”.
●​ Re-benchmarking schedule: periodic and event-triggered reassessment, treated similarly
to traditional software regression testing and mirroring retraining or “re-licensing” of
HCPs for major updates to their scope or methods of practice.

We recommend that the type and level of evidence required for evaluation should stay
proportionate and sponsor-led. The sponsor should justify its confirmation method and
comparator, with more stringent controls such as independent third-party testing and sequestered
test sets reserved for devices at the high-risk end.

5. GenAI can close care gaps or, if not benchmarked and validated,
deepen them, most of all in women’s health and for minorities
GenAI learns from or gets validated against the clinical literature and medical system as it is, with
its areas of strength and its systematic weak points. Taking an angle on women’s health
demonstrates how this can exacerbate bias and amplify health inequality, if not balanced carefully
by design.

From 1977 until 1993, FDA guidance excluded women of childbearing potential from early clinical
research. Still today, the physiological variability and hormonal changes that occur across
women’s menstrual cycles and life stages are not fully understood, and their effects and interactions
with health conditions and treatment remain under-researched and underfunded. Women’s
participation in clinical trials is often conditional on using highly effective contraception, frequently
hormonal, for the duration of the study. This protects them from potentially harmful
pregnancy-related effects but may limit how far results represent the wider real-world population.
FDA. General Considerations for the Clinical Evaluation of Drugs (1977); reversed by FDA. Guideline
for the Study and Evaluation of Gender Differences in the Clinical Evaluation of Drugs, 58 Fed. Reg.
39406 (July 22, 1993).
ICH. M3(R2) Nonclinical Safety Studies for the Conduct of Human Clinical Trials and Marketing
Authorization for Pharmaceuticals (2009), section 11.3 (Women of childbearing potential).
Data gaps extend from female-specific conditions to general conditions that affect women
disproportionately or differently . Models built on this evidence can score well on average and still
fail women, particularly across reproductive states, from fertility treatment to pregnancy, loss and
perimenopause.

Clinician decisions can be a weak reference too: in pre-eclampsia cases, point-of-care decisions
are often highly subjective because necessary blood biomarker results are either not available
locally or arrive late, and benchmarking against such decisions would reproduce today's gaps.

Validated GenAI can close some of these gaps. Endometriosis takes multiple HCP referrals and on
average 10 years to diagnose in the U.S., outdated medical advice surrounding mastitis persists
despite updated guidelines, and women increasingly make major reproductive decisions, such as
egg freezing or contraception, with little individualized information. Reproductive health issues
tend to carry a high level of social stigma, fear of privacy breach (or even enforcement) and general
lack of awareness, aspects where the digital interface, if secure, can bring enormous benefit and
self-agency, also in areas where HCP access for reproductive advice is limited (so-called
“contraceptive deserts” affect 19 million women in the U.S. ).

Benchmarks should therefore test across reproductive states and report performance by sex and
subgroup, be built with patient and professional associations, and use synthetic data only where it
does not repeat women’s historical underrepresentation. FDA’s Real-World Evidence guidance is
also helpful for GenAI: it accepts registry, health-record and claims data without always requiring
identifiable patient-level data, broadening representation while protecting privacy.

6. Building HCPs' competence in and involvement with GenAI is a
priority and a shared responsibility of manufacturers and government

HCP review is often assumed as a reliable control. In practice, clinicians have little time per patient,
are not always updated on latest research and guidelines and have limited AI training. Confident
GenAI output can lead a non-specialist to overreach beyond their area of decision-making. Yet, in
the absence of such assistance, the same professional may also make mistakes.

In practice, care is often split across specialties with the patient as the only link between them, and
validated GenAI can help HCPs see the patient more holistically and understand the necessary
inputs and interactions with other specialist areas.

In the era of GenAI, raising HCP competence should be a shared responsibility of manufacturers
and government. Manufacturers should involve HCPs from the intended user groups as part of
design and validation; they should label the intended user clearly; they should test and train them
beyond ease of use, including how to detect and report incorrect behavior and how to integrate
GenAI into their clinical workflows. Professional associations should be engaged throughout.
Our experience of clinical GenAI workflows in China, such as at Renji Hospital in Shanghai , is
instructive: AI-trained staff lead adoption, clinical teams build their own benchmarking assets and
World Economic Forum, Closing the Women’s Health Gap: A $1 Trillion Opportunity to Improve
Lives and Economies (2024).
McKinsey Health Institute, A Blueprint to Close the Women’s Health Gap: How to Improve Lives and
Economies for All (2025).
Power to Decide. Contraceptive access gaps. https://powertodecide.org/contraceptive-access-gaps
Renji Hospital, Shanghai Jiao Tong University School of Medicine, visited through the FemTech
Weekend Shanghai Summit program
validate products, and GenAI supports medical history-taking, scribing and quality checks before,
during and after consultations.

7. The nature of probabilistic software requires a stronger postmarket
focus for testing and usability, as long as premarket evidence is
proportionate to the device's risk level

Probabilistic software cannot be fully characterized before deployment. Much regression testing
can only happen in production, and even leading engineering teams are still working out how to
best test, deploy and revert GenAI code. Continuous automated evaluation pipelines (i.e. evals)
should become a core expectation across premarket benchmarking and postmarket monitoring.

We support accepting greater premarket uncertainty, as FDA's TEMPO pilot already does,
provided premarket evidence is proportionate to the device's risk level. For lower-risk devices this
means baseline benchmarking, tested user feedback channels, real-world follow-up and supplier
controls on model providers. Where the first sign of failure would be serious irreversible harm,
prospective clinical evidence remains necessary.

In our view, model changes should be scaled to their impact in terms of required QARA steps:

Change Evidence Route
New version or snapshot of the Re-benchmarking PCCP
same model
Model update within the same Re-benchmarking PCCP
family but different tiers
Different model provider Re-benchmarking plus data New submission or PCCP
privacy review
Different model size or type New test and validation protocol New submission

Benchmarking protocol Depends on safety impact New submission with revised
PCCP, or letter to file if not
safety-impacting

PCCPs can be model-agnostic, specifying performance criteria rather than named models.
Precedent exists where FDA cleared mobile apps with multiple wearable integrations based on
acceptance criteria rather than wearable providers (e.g. for digital contraception K241006).
Swappable models should be an architecture expectation, so that devices are not hard-wired to
one model and a validated alternative is ready whenever a model changes or is retired under a
provider’s deprecation notice.

8. Foundation model safety information should be harmonized across
regulators, with master files complemented by public summary safety
cards

Voluntary, confidential master files are useful, but they rely on model developers with little
incentive to disclose, and they risk a fragmented global system if different regulators ask for
different content or cadence. So much of society now builds on these models that developers
should be encouraged to publish summary safety cards, covering scope limitations and safety
refusals, hallucination risk and general accuracy. A master file should support, not shift, the
sponsor's responsibility for the device.

Other regulators are converging in this direction.

The UK's National Commission into the Regulation of AI in Healthcare has proposed an opt-in
master file, dependency reporting and staged authorizations.

Australia's TGA has reviewed 12 AI clinical scribes and, although none of the suppliers identified
them as medical devices, preliminarily found that 8 included functions likely to meet the device
definition: transcribing and summarizing consultations generally falls outside regulation, but
suggesting diagnoses, recommending investigations or influencing treatment can change this, as can
marketing claims, and a “not intended for diagnosis” disclaimer does not override actual
functionality.

In the EU, the AI Act already requires providers of general-purpose AI (GPAI) models to share
technical information with downstream developers and to publish a summary of their training
content, obligations that have applied since August 2025. Aligning FDA's framework with these
initiatives and with IMDRF work would let manufacturers build one evidence package for several
markets.

FDA should also clarify whether manufacturers' own small, specialized, local models will be
treated differently from large, general-purpose, hosted models. We ask FDA to consider whether
their use could be incentivized for better control of behavior, privacy and security.
TGA. Review of AI-powered digital scribes. October 2026.
Edge Compliance contributors

Giulia Paggiola, Matan Eylon, Steph Rowan, Arturo Sanchez-Lopez, Aurelio Ogliari
We also thank our clients who kindly provided input and feedback to this document.
​
For any questions or enquiries, please contact hello@edgecompliance.co
 Annex: Question-by-question comments

Q# Topic Edge comment

IV. Risk

1 Two-axis framework The risk framework does not sufficiently account for how GenAI capability will develop and be adopted further, across both
consumer health and medical applications. Also, by limiting the scope of this guidance to “devices” it does not clarify the
boundary and interaction of this guidance with the General Wellness Policy and corresponding enforcement discretion
mechanisms. Wellness GenAI already overlaps functionally with the left half of the spectrum, and agentic and
hardware-coupled GenAI will soon be common in consumer health. As with wearables, where a non-medical data source
provides input to medical devices, we see a coming boom in non-medical GenAI attached either up- or downstream to
medical devices, and being kept outside of the device definition. A classification based on what the GenAI says, and to whom,
will not stand the test of time and will discourage manufacturers from making GenAI a formal part of the device. In our view,
GenAI that only reads and explains a device's outputs without being able to change them or interpret them diagnostically
should be allowed to remain wellness, provided the manufacturer benchmarks it for compatibility, accuracy, hallucination
and misuse.

We support the two-axis framework as long as risk is classified in the context of intended use only. A GenAI that helps users
conceive and one that supports insulin dosing have very different risk profiles, yet a similar chance of hallucinating in
unintended directions, for example: diagnosing other conditions, suggesting alternative treatment, giving emergency advice,
or advising vulnerable users such as pregnant women, children or patients with serious comorbidities. Such errors are serious
in every case and would push every product up both axes, so counting them would not discriminate between devices. As with
foreseeable misuse, they belong in risk management, design and testing, not in classification. A GenAI adjunct to a conception
app should therefore be classified within conception (low-risk proceptive, under enforcement discretion ) rather than digital
contraception (Class II), even though it could foreseeably drift that way and this must be controlled.

We propose further definition to the axes:

●​ Consequence, limited to harms tied to the intended use rather than to hallucination:
○​ Limited (low-risk, common, transient conditions and effects),
FDA. Intent to Exempt Certain Unclassified Medical Devices from Premarket Notification Requirements. Guidance, June 2026
Q# Topic Edge comment

○​ Moderate (all other conditions and consequences)
○​ Severe (life-threatening or irreversible conditions, including emergencies).
●​ Activity, based on the actionability of the output, with an explicit wellness / non-device CDS boundary:
○​ Contextual: explains a consumer's health data (including from devices or IVD tests) against scientific and
medical literature for information and education, also framing likely possibilities for discussion with an HCP.
Users must be able to confirm the original data and sources. In line with the General Wellness guidance ,
outputs should be framed around supporting a healthy lifestyle, including living well with a chronic condition.
Risks associated with the GenAI’s intended use should be “Limited” only.
​
—--------------- Wellness boundary------------------

○​ Assistant: supports an HCP with diagnostic or prognostic work that the HCP can perform, trace or confirm
independently, for example as an ambient scribe, medical history aggregator, clinical research summarizer,
feedback on a doctor’s report in the context of similar cases, etc. Some Assistant functions will meet all four
Non-Device CDS criteria and fall outside the device definition. Others will not, and are devices under
enforcement discretion or Diagnostic/Therapeutic devices. The baseline applies in all cases. Whether a
function is Non-Device CDS depends on four criteria, not on the severity of the condition, so the matrix
shows where Assistant functions fall across the severity spectrum.
​
----- Non-Device CDS / enforcement discretion boundary------

○​ Diagnostic: generates a distinct diagnostic or prognostic output from device data. An HCP prescribes testing
or treatment but may not be able to verify the output first.
○​ Therapeutic: generates a treatment indication the patient can act on without an HCP gate, for example
increasing or stopping a prescription.
○​ Agentic: takes therapeutic action or controls a physical device autonomously (e.g. electrical energy, drug
dose).

Existing boundary setting guidance documents predate GenAI and do not reflect how GenAI is already used, including
consumer features that explain users’ own medical records and test results as well as some HCP-facing GenAI functions.
These are:
●​ General Wellness policy,
FDA. General Wellness: Policy for Low Risk Devices. Guidance, January 2026.
FDA. General Wellness: Policy for Low Risk Devices. Guidance, January 2026.
Q# Topic Edge comment
●​ FDA’s enforcement discretion for device software functions, and
●​ statutory Non-Device CDS criteria.
In our view, these boundaries should determine the regulatory pathway, not whether a function should meet a safety baseline:
the benchmarking described in Q8 should apply to all health GenAI. We ask that FDA’s future GenAI guidance set out how it
interacts with these policies, in particular:
●​ Whether informational, non-diagnostic patient-facing GenAI (our Contextual level), which helps people understand
their health and records and prepare for their HCP, can rely on the General Wellness policy and/or enforcement
discretion for Device Software Functions and Mobile Medical Applications. Because the CDS criteria apply only to
HCP-facing functions, this cannot be settled through Criterion 1 and needs its own position, including where such
tools process IVD results or medical images.
●​ Whether Criteria 1 and 2 of the CDS guidance, which make a determination based on the type of data input, are
appropriate discriminators of Device/Non-Device in the case of GenAI. We believe the input category should not be a
determining factor. As these criteria are set in statute (section 520(o)(1)(E) of the FD&C Act), we believe FDA's
interpretation in guidance of terms such as “medical information” and “pattern or signal” could address this for
GenAI inputs, such as uploaded laboratory reports, without legislative change.
●​ How Criterion 4 of the CDS guidance applies to HCP-facing generative output, for example whether traceable
citations, disclosure of inputs and documented limitations let an HCP independently review its basis. This decides
which Assistant-level functions are non-device CDS and which are devices. The baseline applies to both,
complementing HCP verification rather than being replaced by it.

As in IEC 62304, the class should be set from the intended use before AI/software controls are considered, and assuming they
will fail. The mitigation strategy is nonetheless central to each device's assessment, covering risks both within and beyond the
intended use. Detection latency, the time before a failure becomes visible to the user, HCP or manufacturer, should shape
both the choice of controls and the clinical evidence strategy. In order of preference, from most to least independent of the
generative component and consistent with the risk control options in ISO 14971 (not all apply to every device):

●​ Hardware controls, e.g. components that limit power, current or dose supply.
●​ Software controls, e.g. deterministic algorithms, structured logic gates, programmatic guardrails and alerts, a separate
UI.
●​ AI controls, e.g. guardrails in system instructions and runtime QC or classifier models that block unsafe outputs.
Adversarial testing verifies these controls but is not a control in itself.
●​ Information for safety, e.g. disclaimers, in-product notices and user training. Real-world monitoring of over- and
FDA. Policy for Device Software Functions and Mobile Medical Applications. Guidance, September 2022.
FDA. Clinical Decision Support Software. Guidance, January 2026.
Q# Topic Edge comment

under-escalation feeds CAPA rather than preventing harm in the individual case.

Combinations of consequence and activity should map indicatively to regulatory pathways as follows:

Severe Low Risk*​ High Risk​ High Risk​ High Risk​
n/a Non-Device CDS Class II / III Class III Class III
/ Enf. discretion
Moderate Low Risk​ Moderate Risk​ Moderate Risk​ High Risk​
n/a Non-Device CDS Class II Class II Class III
/ Enf. discretion
Limited Low Risk​ Low Risk​ Low Risk​ Low Risk​ Moderate Risk​
Wellness Non-Device CDS Class I / II Class I / II Class II
/ Enf. discretion
Consequence \ Contextual Assistant Diagnostic Therapeutic Agentic
Activity
*Non-Device CDS if all 4 criteria met; otherwise per Diagnostic column.

Mitigation does not change the class, but each class carries minimum expectations; where they are not met, additional
evidence should be required:
●​ Wellness and Non-Device CDS: baseline benchmarking, disclaimers and user feedback channels.
●​ Low-risk device: verified protective measures around the generative component, such as guardrails and runtime QC
models.
●​ Moderate-risk device: deterministic software controls on safety-relevant outputs, independent of the generative
component.
●​ High-risk device: independent third-party testing, and controls the generative component cannot bypass, including
hardware limits where the device acts physically.

GenAI benchmarking standards should apply irrespective of risk level or intended use. Wellness products should test against
them and self-declare conformity, as wearable manufacturers do for electrical safety regardless of device status. For GenAI
that can give health advice, meeting the baseline should form part of FDA's low-risk assessment, judged by what the product
Q# Topic Edge comment

can do rather than by its claims (see Q8). Any GenAI that can write to a medical function, for example by changing its
settings or inputs, should take the classification of that function. We also propose a public FDA database for GenAI, covering
wellness and devices, so anyone can see what a tool is allowed to do and which conformity it claims.

We disagree that GenAI-enabled IVDs are inherently higher risk than complex non-IVD outputs. They should be placed on
the same axes, with the same mitigation expectations.

2 Directiveness 1) Wording and claims are among the hardest things to control in GenAI health products, and an area where we increasingly
continuum support clients. Guidance exists for the cosmetic-drug borderline, but nothing comparable for the wellness-diagnostic one.
FDA should issue GenAI copy guidance that developers can use directly as model instructions, with examples and rules of
thumb for each claim type:
●​ medical claims (diagnostic, prognostic, clinical outcome),
●​ health claims (general improvement),
●​ accuracy claims (computational and clinical fidelity, confidence, significance)
●​ educational claims (improving the user's understanding).
Wording guidance would complement, not replace, assessment of an output's functional effect.
​
2) Personalization and specificity are becoming ubiquitous, so regulating on that basis is neither realistic nor useful.

3) Reliable production systems should rarely, if ever, rely purely on LLMs. Inputs normally pass through a pipeline that
transforms, classifies and validates them, with deterministic rule engines, logic gates and guardrails upstream and downstream
of the generative component. The options range from rule engines (fully predictable, no hallucination), through classical ML
(no hallucination, but misclassification and overfitting) and small, specialized language models (fewer hallucinations, more
predictable), to general LLMs and reasoning models (flexible but prone to hallucination and sycophancy). In healthcare,
engineers should choose the most deterministic option that fits each step and use an LLM only where the others don't fit or are
too complex to configure, not as a catch-all. This is also the architecture of UpDoc (K253281), cleared via 510(k) as a
drug-dose calculator, with a conversational LLM layer around provider-configured, deterministic insulin logic and an
authorized PCCP.

3 Patient-facing vs Following FDA's reasoning, a wellness GenAI could rank above an HCP-supervised action-directing tool, which contradicts
HCP-facing the logic of the two-axis framework proposed by FDA. We disagree with this as a general principle. All health GenAI,
patient- or HCP-facing, wellness or device, should meet the same safety baseline: explicit science-backed references,
FDA. Is It a Cosmetic, a Drug, or Both? (Or Is It Soap?).
FDA. 510(k) K253281, UpDoc (Updoc, Inc.), cleared December 23, 2025, with authorized PCCP.
Q# Topic Edge comment

disclaimers, and computational and benchmarking validation (see Q8-10).

HCPs are in principle better placed to interpret an output, but in practice this is an unreliable control. They have little time per
patient and limited AI training, and many senior doctors may be less familiar with the technology's limits than a younger
layperson who uses it routinely. Leveling up HCP training should be the sponsor's responsibility, together with involving HCPs
in design and validation and engaging professional associations.

As FDA acknowledges, access to information has real benefits, and in several therapeutic areas gatekept information combined
with inconsistent or outdated HCP knowledge causes persistent harm. According to the Endometriosis Foundation of
America , endometriosis affects an estimated 200 million women and people with a uterus worldwide and more than 1 in 10
in the U.S., takes on average 10 years to diagnose in the U.S., and is often misdiagnosed several times along the way.
Patient-facing GenAI can also counter outdated clinical practice. Updated guidelines treat mastitis primarily as an
inflammatory condition, managed with cold compresses and NSAIDs, yet heat, deep tissue massage and hyper-pumping are
still widely recommended and can escalate inflammation into infection and abscess . In such pathways, scientifically validated
GenAI is more likely to benefit patients and HCPs than to harm them.

4 Generalist vs specialist In practice, HCPs routinely rely on methods beyond their expertise, such as genomics, and cannot assure the quality of labs or
HCPs devices themselves; they rely on regulatory approval and labeling to know what is trustworthy. Specialized GenAI output for
non-specialists should rest on the same basis: evidence of usability by the intended user, suitable training data and clinical
validation. Appropriate safeguards are:
●​ HCPs from the relevant user category involved in design and validation, including training and usability testing, with
those categories disclosed, representative and inclusive.
●​ Labeling that identifies the intended user, including whether generalist or specialist.
●​ Specific notices by design (system instructions, disclaimers) where output may foreseeably fall outside the user's
expertise.

Risk-benefit considerations:
Confident GenAI output may lead a non-specialist to believe they know enough to act outside their expertise. Yet wider access
to specialist knowledge that supports and updates HCP practice is positive, and does not in itself expand a non-specialist's
decision-making power. The extra risk arises when the design controls and clinical claims behind an approval cannot be
trusted. Today many conditions are missed because specialists work in silos, with the patient, the least informed person in the
chain, as the only link between them. Validated GenAI can help HCPs look at the patient more holistically and encourage
cross-discipline collaboration. More broadly, the HCP's role must evolve: understanding AI, contributing to its design,
Endometriosis Foundation of America
Academy of Breastfeeding Medicine. Clinical Protocol #36.
Q# Topic Edge comment

integrating it into workflows, watching for drift and reporting issues should become core professional skills, driven by
sponsors, academia and professional societies.

5 Multi-turn Multi-turn conversations increase hallucination and sycophancy, and the risk of user and AI confabulating into delusional
conversations spirals sometimes described as "AI psychosis". The risk is greater in volume for lay users and wellness tools, but it has also led
highly educated professionals to believe they had made original discoveries, which could be acutely dangerous in a clinical
21,22
setting . The number of turns is a proxy for three underlying problems: context window saturation, where older instructions
and guardrails are pushed out or diluted; accumulated noise, which makes off-topic drift and safety breaches more likely; and
attention drift, where long inputs dilute the weight of the original instructions. Each needs its own strategy, such as compacting
the context or resetting the session once a set share of the window is used, pinning the system prompt, and pre-classifying
inputs.

Basic benchmarking of both wellness and devices should therefore include at minimum:
1) Time or number of turns in a chat, as a proxy.
2) Recognition of limits: testing whether the tool notices when users push it beyond its limits and stops rather than fabricating.
Studies suggest models can recognize this but often continue to give the user a sense of value and progress . Where
manufacturers fine-tune their own models, device-specific safeguards can be built in, for example a rule-based reward model
(RBRM) tailored to the device, its intended use and clinical rules, trained on adversarial datasets that penalize agreement with
unverified claims and reward recognition of operational limits. Targeted fine-tuning has reduced sycophantic compliance with
illogical medical requests while maintaining responsiveness to valid prompts .
3) Postmarket observability geared to probabilistic software, beyond uptime, security, bugs and usage. As risk rises, capturing
full execution traces of the model's intermediate reasoning, not only its final output, becomes a key requirement, showing
where models drift, become sycophantic or hallucinate. This does not require keeping users' conversations as records: checks
can be automated on pre-anonymized data, retaining only aggregate results. This matters especially in reproductive health,
where conversations can be intimate and highly sensitive; data privacy and retention terms with model platforms belong in
supplier evaluation and contracts (Q9, Q24).
4) Safety harnesses that enforce security boundaries, control access to tools and govern actions, with context and state
management that persists state safely without drifting into unsafe states.
Morrin et al., Artificial intelligence-associated delusions and large language models: risks, mechanisms of delusion co-creation, and safeguarding strategies.
Lancet Psychiatry. 2026; 13(6): 522-530.
Flathers et al., Beyond artificial intelligence psychosis: a functional typology of large language model-associated psychotic phenomena. Lancet Digit Health.
2026; 8(4): 100974.
Sharma et al. Towards Understanding Sycophancy in Language Models. arXiv:2310.13548, 2023.
Chen S et al., When helpfulness backfires: LLMs and the risk of false medical information due to sycophantic behavior. npj Digit Med. 2025; 8(1): 605.
Q# Topic Edge comment

6 Care escalation We recommend a basic benchmarking standard for all GenAI intended or effectively used for triage, covering over- and
under-escalation and refusal of advice beyond the intended use. Acceptance levels for unintended behavior should be set in the
risk management file on a risk-benefit basis, at 0% for the most severe cases. Exceedances in testing or postmarket monitoring
would be non-conformities subject to trend analysis, and approval should depend on acceptable levels being met and
maintained, as approved or defined in the PCCP. Under- and over-escalation should be reported separately rather than as one
combined score.

Risk-benefit considerations:
Mis-escalation already happens in healthcare without GenAI, and any tool should show measurable benefit against that
baseline. Medical-grade symptom checkers escalate more conservatively than patients searching the internet and align more
closely with clinical assessment , whereas general-purpose LLMs, widely misused for triage, both over-triage minor cases and
2627
under-triage emergencies . This supports benchmarking every health GenAI against mis-escalation, whatever its class.
Two further points apply.
●​ Under-escalation carries the higher risk of harm, while over-escalation mainly carries institutional cost, whose
acceptability depends on income, insurance, location and access. Some over-escalation is a deliberate precaution in
both digital tools and traditional care; in pregnancy, for example, a higher rate is generally accepted. And
over-escalation is gated by the first clinical interaction, so it rarely burdens later levels of care unless warranted.
●​ Health self-advocacy is a major challenge for women and minorities, with long-term costs in missed early detection
and prevention. The discussion paper seems to assume proactive individuals who seek care unnecessarily and promptly
receive referrals and tests. For many health issues, and for women in particular, the reality is limited awareness of the
problem, taboos and the normalization of women's pain, concern about out-of-pocket costs, dismissed symptoms,
and a lack of diagnostic and therapeutic pathways beyond symptomatic treatment.

7 Competency-based We consider the approach useful, though less novel than it may appear, as it mirrors how devices are already authorized and
approach monitored, i.e. intended use as a defined scope of practice and authorization as a licensure framework. Arguably, devices are
subject to more transparent surveillance and problem reporting than human professionals.

If considered across a GenAI device lifecycle, the competency-based approach would unfold as follows:
●​ Pre-market:
○​ Benchmarking of GenAI, similar to medical practice exams.
Morse et al., Use characteristics and triage acuity of a digital symptom checker in a large integrated health system: Population-based descriptive study. J Med
Internet Res. 2020; 22(11): e20549.
Hack et al., Evaluating large language models for specialist referral triage in primary care: a quantitative study using otolaryngology scenarios. Fam Pract.
2025; 42(6).
Brodeur et al., Performance of a large language model on the reasoning tasks of a physician. Science. 2026; 392: 524-527.
Q# Topic Edge comment

○​ Clinical confirmation of GenAI, similar to licensing examination.
○​ Ethical goal setting of GenAI, similar to doctors taking the Hippocratic Oath. This could be operationalized as
a code of conduct for medical GenAI (e.g. do no harm, stay within competence, escalate when uncertain).
Shaping a similar code of conduct and embedding it into an independent Rule-Based Reward Model (RBRM)
for GenAI devices would standardize practice, and make it less dependent on the default Reward Model from
the AI provider.
●​ Post-market:
○​ Staged expansion of responsibility with human-in-the-loop is similar to senior HCP supervision and career
progression.
○​ Benchmarking of GenAI, similar to recurrent medical training. This should be treated as regression testing and
before and after a change has been deployed in order to verify the consistency of the system.
○​ Clinical confirmation of GenAI, similar to “relicensing”, only required for major updates to practice or scope,
i.e. for a GenAI beyond the scope of an approved PCCP.
○​ Effective feedback-gathering mechanisms should be a fundamental part of GenAI design. In comparison,
human clinicians especially in small/private clinical settings often have limited visibility of the outcome of their
clinical decisions or feedback on their performance.
○​ Accountability, this should be considered as effectively delivered through product liability for 510(k), De Novo
and non-device products, not only FDA enforcement. In a similar way doctors subscribe to professional
liability insurance. We are already seeing court cases against allegedly inaccurate wellness wearables that
include AI advisors. In general, QMS and Design Controls are instruments for GenAI manufacturers to assure
accountability as well as mitigating liability.

However, in two aspects HCP practice is more controlled than devices:
●​ Within the U.S. regulatory system, devices have no time-limited certification. By contrast, the EU currently requires
recertification at least every five years plus annual surveillance audits. FDA could consider annual surveillance audits,
for example building on the Medical Device Single Audit Program (MDSAP), and/or a periodic recertification schedule
inspired by, but not identical to, the EU MDR, together with more stringent postmarket surveillance requirements
aligned to the European PSURs.
●​ Medical training is followed by a gradual rollout of supervised practice and increasing responsibility, whereas a device
can be deployed with full functionality as soon as it is authorized.

On the latter point, in reality, it is common tech practice to perform staged releases, often starting from a minimally viable
product (MVP) in beta versions and gradually expanding functionality and reach. Many health innovators enter the market
Surber v. Oura, Inc., No. 3:26-cv-08686 (N.D. Cal. filed Aug. 20, 2026).
Q# Topic Edge comment

with wellness MVPs, gather real-world evidence, monitor safety, and later implement medical claims of increasing substance.
This commercial pathway is typically driven by funding limitations and business risk reduction. Effectively, this mechanism is
naturally creating a gradual roll out of responsibility similar to that of HCPs in training.
For GenAI-enabled devices this could be required in a more deliberate manner, with human-AI teams working like a junior
supervised onboarding.

The complexity arises in relation to the expansion of medical claims, whether area of practice or level of decision-making
power. This is not easily compatible with FDA's one-off authorization tied to defined claims and product codes. Companies
would either need to start with a broader De Novo and deploy with limited capacity initially, or accept multiple regulatory
submissions, potentially evolving across product codes.

If we take inspiration from the medical profession, they practice within a specialty rather than a narrow intended use. A
comparable structure for GenAI regulation may need a redefinition of product codes into wider specialties rather than
indications.

V. Premarket

8 Risk-proportionate We believe basic benchmarking (scope, refusals, fidelity and misuse) should be foundational for any health GenAI, irrespective
evidence of intended purpose or risk class. It should be expected as good practice even for non-device wellness tools, and form part of
FDA's assessment of whether a wellness product is low risk, judged by what the product can do rather than by its claims, as
the 2026 General Wellness guidance already expects validated values from wellness wearables that output physiologic
parameters, so that they stay within their intended purpose and apply appropriate refusals. This is similar to how electronic
devices must comply with electric and EMC standards regardless of an intended medical use. In our opinion, the creation of
GenAI safety benchmarking standards should be a top priority. Depending on the applicable regulatory pathway evidence of
such conformity may be held by the manufacturer and self-declared (e.g. in the case of wellness GenAI or devices under
enforcement discretion) or submitted as part of a 510(k), De Novo or PMA dossier. This would not bring wellness products
under FDA oversight or into the device definition. As with ISO 27001 for information security, claiming conformity to a
common standard creates a baseline with a measure of accountability and auditability. Without such a standard, each
manufacturer defines its own test criteria and methods, and their rigor cannot be assumed.

Position on the two-axis framework should then scale the depth of evidence required. This scaling could build on the Basic
and Enhanced documentation levels in FDA's guidance on Content of Premarket Submissions for Device Software Functions
(2023). We propose that the following controls should be a mandatory part of submissions for High Risk GenAI-enabled
devices, as defined in the matrix in Q1 (further elaborated in Q18):
1.​ Prospective clinical evidence where the first observable sign of failure would be irreversible harm
Q# Topic Edge comment

2.​ Independent third-party confirmatory testing
3.​ Staged deployment: shadow deployment then supervised deployment before full autonomous deployment
4.​ HCP training evidence
5.​ Regular surveillance audit or inspection cadence

9 Benchmarking In general, we support the proposed benchmarking elements and suggest the following additions:
elements 1) Misuse prevention. This could sit within safety, but some misuse is neither safety- nor scope-related such as cybersecurity
measures or ethical harness in the goals or metrics the GenAI is designed to achieve (e.g. “first, do no harm”, not optimizing for
efficiency).
2) Security and privacy. Baseline cybersecurity and privacy expectations for health GenAI would be valuable, also for
non-device software.
3) Disclaimers and transparency. Users should be told that they are interacting with AI, as the EU AI Act requires, and, as good
practice, that AI makes mistakes and is not for diagnosis. For high-risk AI systems, the AI Act also requires written agreements
with suppliers.
4) Training data disclosure. Basic labeling should include an indication or reference regarding the source and nature of training
data. For models that are trained on the open web, or even smaller open bodies of research, vulnerability to misinformation
should be considered. (e.g. poisoning attacks).
5) Multi-turn stability and sycophancy. Premarket benchmarking should show that escalation, refusal and calibration hold
across simulated clinical conversations of realistic length (e.g. 10, 20, 50+ turns), including adversarial pushback, and should
measure how often the system abandons correct answers under pressure. Published metrics, such as the rate at which a system
rejects illogical or misleading requests, offer a starting point. This applies to the system as deployed, not to the foundation
model's RLHF.
6) Source and citation fidelity. Where outputs cite sources, citation accuracy should be benchmarked separately from the
correctness of the claim.

Privacy considerations are paramount especially in reproductive health, where data are intimate, often subject to social shame
or judgment, and enforcement is weak. How general-purpose LLMs and foundation models integrate and process patients'
health data should be part of benchmarking. HIPAA does not apply to all such software, leaving a gap in user privacy
safeguards.

There will be different acceptance levels for different unintended behaviors. For the most risky, the level should be 0%. For
others there may be some % of acceptability. What goes above would be a non-conformity, and subject to trend analysis
otherwise.
Chen S et al., When helpfulness backfires: LLMs and the risk of false medical information due to sycophantic behavior. npj Digit Med. 2025; 8(1): 605.
Q# Topic Edge comment

10 Benchmark validity Publicly available benchmark assets/standards should not center on intended use, which belongs in clinical confirmation. They
should reflect the state of the art of the technology behind the device. Independent third parties could also develop benchmarks
for common use cases within a specialty (e.g. diabetes, fertility), which manufacturers could adopt directly as standard
instructions, guardrails and safety filters rather than each building their own. Pass levels could be set by risk category, with
manufacturers building on them for their own intended use.

Public benchmarks are especially hard to build in women's health because of the lack of data and real-world
representativeness, more so for minorities. This applies not only to women's health conditions but to general conditions that
30,31
affect women differently or disproportionately, which remain poorly understood . FDA's real-world evidence guidance
supports closing these gaps: it accepts real-world evidence from registries, electronic health records and claims data without
always requiring identifiable patient-level data, broadening the populations represented while protecting privacy, which
matters especially for reproductive health data. Involving professional and patient associations would be decisive in
countering the bias and care gaps seen in both traditional and GenAI care.

11 Clinical confirmation The choice of clinical confirmation method should rest with the manufacturer, justified case by case and ideally combining
approaches. Prospective data is not always more representative than RWE, especially where misuse or non-adherence is
common.

For interactive GenAI, retrospective clinical evaluation and shadow deployment are of limited use, because the device's
responses shape what the user says next. Prospective standardized interactions with blinded clinician adjudication are a
practical alternative, as a recent randomized evaluation of a CBT agent, rated by 22 blinded clinicians on an established
competence scale, has shown.

We also note that in certain clinical uses comparison with clinicians' decisions can be a poor reference. In pre-eclampsia, for
example, doctors must often judge at the point of care, from symptoms alone, whether a life-threatening condition may
develop within a day or two, because biomarker testing is limited and results often arrive too late . Benchmarking or training
AI against such a subjective baseline may not lead to the best results, and the same applies to other underdiagnosed conditions
or those without clear biomarkers.
World Economic Forum, Closing the Women’s Health Gap: A $1 Trillion Opportunity to Improve Lives and Economies (2024).
McKinsey Health Institute, A Blueprint to Close the Women’s Health Gap: How to Improve Lives and Economies for All (2025).
FDA. Use of Real-World Evidence to Support Regulatory Decision-Making for Medical Devices. Guidance, December 2025.
Rollwage et al., A cognitive layer architecture to support large-language model performance in psychotherapy interactions. Nature Medicine. 2026; 32:
1717-1725.
European Research Council / CORDIS. PEDPOC: Rapid diagnosis of preeclampsia at the point-of-care (2019 to 2022).
Q# Topic Edge comment

12 Statistics In our general observation, there are limited published figures on how well doctors perform in practice, and AI could help
produce them. Expectations for performance estimates should recognize this, and that competency assessment does not
guarantee real-world performance, for doctors or for GenAI. Metrics should be defined by the manufacturer for the device
and what matters most in practice, such as accuracy or time to diagnosis, and can be measured in three arms (HCP alone,
HCP with AI, AI alone) to give an HCP baseline for comparison.

13 Synthetic data Disclosures about training data should be expected good practice for all health GenAI, wellness and devices, in labeling and
user communication, to the extent the model provider discloses it. Submissions should include a phenotypic breakdown of the
training data, showing how far synthetic data was used alongside other sources. Beyond this, synthetic data cannot usefully be
standardized and should be justified, procedurally controlled and ideally externally adjudicated case by case.

Training a capable model needs very large datasets, and buying anonymized data is often easier than synthesizing it. Synthetic
data generators should be independent of the device's own model family, so that they do not reproduce its blind spots.

Synthetic training data may be suitable, with particular care, in two cases:
1. Rare conditions, where there is hardly any real-world data.
2. Bias mitigation, where a subgroup is underrepresented, although the risk of exacerbating bias is high.

Synthetic test cases are a different matter: they can and should be created in any circumstance to test how the system handles
edge scenarios, including rare conditions.

14 Comparators for Assembling a representative panel of qualified clinicians may be difficult for certain conditions. Quality of care also varies
open-ended outputs widely by location, including within and outside the U.S., and depends on the healthcare system, clinical operations and how
doctors are trained at university. Nevertheless, HCPs should be included in the design in a way that is aligned to the intended
use and user. Depending on the use case, this could involve specialists for training data or guidelines of the diagnostic /
therapeutic functions, combined with usability engineering performed with generalists who would likely interface with the
device.

Comparisons with generalist versus specialist physicians should be a sponsor decision rationalized case-by-case. We do not
see a general framework that could apply to every GenAI-enabled device; the choice is specific to the clinical context rather
than to the nature of the GenAI function itself. The human-AI team interaction is the relevant basis, similar to a junior
supervised by a senior.

We also note that expectations of AI in the discussion paper may be, to some extent, higher than those of doctors. For
example, benchmarking is expected to cover comorbidities and concomitant therapy, an area where HCPs often fail and where
Q# Topic Edge comment

AI could account more comprehensively and holistically for medical history and interfering treatment. As discussed in our
comment to Q11, using clinicians as the reference can in some cases risk reproducing the patterns and issues of the current
healthcare system rather than improving on them.

15 Counterfactual See Q11 and Q14.
comparator

16 Independent third We find accredited, independent third parties for benchmarking or clinical confirmation compelling, in two possible forms:
parties competent service providers, as in premarket cybersecurity penetration testing, and accredited bodies running confirmatory
tests on FDA's behalf, as for electrical safety under FDA's Accreditation Scheme for Conformity Assessment (ASCA). Both
could confirm manufacturers' testing and monitoring premarket and at postmarket intervals, giving greater assurance that
results are representative. Independent third parties could also hold sequestered test sets, unseen by manufacturers, to limit
contamination and optimization to the test.

For high-risk devices, such confirmation should be mandatory premarket. Specialized bodies complementing FDA could also
run an inspection-like postmarket monitoring framework for all GenAI devices and develop standards.

17 Other architectures Some architectural choices affect robustness: swappable architecture and model routing should be manufacturing best
practice, so that applications are not hard-wired to one model; lowering model temperature where possible increases
determinism (although sampling determinism is not factual correctness), yet sampling controls such as temperature are
increasingly unavailable on frontier models , which reinforces the need for determinism outside the generative component;
and vendors should test at single-step, full-turn and multi-turn level.

VI. Postmarket

18 Premarket uncertainty Accepting greater premarket uncertainty is reasonable and inevitable for GenAI devices. FDA's TEMPO pilot already follows
this logic, allowing selected digital health devices, including a generative AI therapy agent, onto the U.S. market under
enforcement discretion while real-world evidence is gathered for a later 510(k) or De Novo. We recommend an approach
that allows low-to-moderate GenAI devices more reliance on post-market data, benchmarking and procedural controls,
while establishing further measures for high risk GenAI devices through third parties, staged releases and prospective studies.

For low- and moderate-risk devices the following conditions should support a leaner pre-market pathway in the presence of:
1) PMS monitoring mechanism and plan. Required complaint and feedback mechanisms for users (HCPs and patients) to flag
Anthropic. Claude Platform Docs: Model deprecations, API parameter deprecations.
FDA. Participants Selected for TEMPO for Digital Health Devices Pilot. August 2026.
Q# Topic Edge comment

inaccurate, misleading or unhelpful responses. These should be pre-tested in usability engineering and contribute to design
iterations.
2) RWE studies. Previously collected RWE data can be a basis for supporting clinical evidence as long as the analytical
protocol is sound. This is in line with FDA's 2025 real-world evidence guidance (see Q10). Post-market clinical follow-up
(PMCF) plans, equivalent to European requirements under MDR, should address the effectiveness of the PMS system as well
as of the device’s intended use.
3) Pre-market and recurrent benchmarking. As described in comments to Q8-9. These should include evidence of user
awareness and/or ability to understand and judge the output of GenAI. This should include a periodic minimum cadence with
event-triggered reassessment, with changes to the model, prompts, retrieval sources or tools as defined triggers.
4) Quality agreements with third-party foundation model providers. To ensure continuity of service and notification of
significant changes in advance.
5) AI development processes, literacy and provider evaluation embedded in the QMS. Similar to requirements of EU AI Act. In
the U.S., this fits within the QMSR , which has incorporated ISO 13485 since February 2026.

For High Risk devices (as defined in Q1), in addition to the above, the following conditions should be in place:
1) Prospective clinical evidence. Where detection latency means the first observable sign of failure would be irreversible harm,
postmarket monitoring cannot compensate for missing premarket evidence. Given that some behaviors can only be observed
post-deployment, a clinical study is the safest setting for studying higher risk devices.
2) Independent confirmation. An independent third party could perform or confirm benchmarking, not only premarket but
with perpetual access to the device to repeat confirmation testing routinely.
3) Staged release with growing levels of competence, see in the competency-based model in Q7.
4) HCP Training. As part of rollout, manufacturers should invest in training, regardless of ease of use, to raise general
competence in handling AI: when to report, what is acceptable and what is not, how to run internal validation in clinics, and
how to integrate these products into clinical workflows, including with other devices as they become agentic or integrate with
hardware.
5) Regular surveillance audits. Annual surveillance audits, for example building on MDSAP, and/or a periodic recertification
schedule inspired by the EU MDR (see Q7).

19 Postmarket methods See Q18 and Q20.

20 Supervisory agents We support machine-based supervisory agents for routine, high-frequency monitoring, with escalation to humans or deeper
testing at a set cadence. An open question is how the agent itself should be validated: internally against existing CSV
standards, or by independent testing similar to a specialized penetration test. A supervisory agent built on the same foundation
FDA. Medical Devices; Quality System Regulation Amendments. Final rule, 89 Fed. Reg. 7496 (Feb. 2, 2024), effective February 2, 2026.
Q# Topic Edge comment

model as the device it monitors shares its failure modes, so the independence of the monitoring model should be part of that
validation.

Automated evaluation pipelines (evals) should be a core technical standard across premarket benchmarking and postmarket
monitoring. Probabilistic systems need continuous automated test suites against real data, in UAT and preferably in
production, to measure performance, probe edge cases, verify guardrails and run regression tests whenever models, prompts or
configurations change.

Standard regression testing does not translate well to LLMs, since much of it must happen after deployment. We see this as one
of the hardest shifts in modern software engineering, and even leading teams are still working out how to deploy, revert and
test. Industry standards would help consistency but would struggle to keep pace with the technology.

21 Ecosystem roles Everyone in the ecosystem needs urgent training for GenAI-enabled technology: scientists and engineers, life science leaders,
regulators, QARA professionals, HCPs, technicians, hospital staff and the public. Manufacturers and government share
responsibility for raising the competence of HCPs and the public, depending on target users. HCPs should contribute to design
and implementation, watch for drift and report issues, with professional associations engaged.

We recommend looking at foreign examples for GenAI legislative and ecosystem frameworks. Other regulators are converging
on similar answers, which makes international alignment both possible and valuable.
The UK's National Commission into the Regulation of AI in Healthcare38 has recommended staged authorizations, PCCPs
defined by boundaries rather than specific changes, an opt-in master file for general-purpose AI models, function-based
regulation, health equity across the lifecycle, and recognition and reliance pathways with trusted regulators.
Our direct experience of GenAI and agentic clinical workflows in China has shown us:
●​ clinics have AI-trained staff leading the transformation, supporting colleagues in implementing and training their own
specialized AI assistants, and acting as the first point of contact for any new technology containing GenAI;
●​ clinics develop benchmarking assets for validating GenAI internally, which for most low-risk applications is
considered equivalent to an administrative tool;
●​ GenAI is used before, during and after medical appointments to gather medical history, all patient-reported
information, medical guidelines, and outcomes of similarly treated patients from an internal database, and to use these
to quality-check the output of the LLM+clinician collaboration.
Similarly, China has been issuing horizontal legislation with respect to certain uses of GenAI, such as those that could lead to
National Commission into the Regulation of AI in Healthcare. Recommendations for a future regulatory framework. MHRA, September 2026.
Renji Hospital, Shanghai Jiao Tong University School of Medicine, visited through the FemTech Weekend Shanghai Summit program.
Q# Topic Edge comment
40,41
high-personification of interactive AI and general safety, transparency, and data governance.

22 Change categories We suggest these categories for GenAI devices:

1) New version or snapshot of the same model (e.g. a provider retiring a version and recommending its successor):
re-benchmarking only, covered by a PCCP. This is the most frequent change and is often forced by provider deprecation.
2) Model update within the same family (e.g. Claude Sonnet to Opus): re-benchmarking only, which could be covered by a
PCCP and supports contingency planning for devices that rely on one model.

3) Different model provider (e.g. ChatGPT to DeepSeek): unless pre-included in a PCCP with performance and clinical
thresholds, likely a substantial change needing resubmission, with added review of data privacy and of foreign-adversary
data-access considerations under applicable U.S. policy. Re-benchmarking here means revalidation against the approved
thresholds, with model family, provider and size determining its extent. Since swappable architecture should be standard
practice (Q17), at least one alternative model, or a range of models or specifications, should always be pre-approved in the
PCCP.

4) Different model size or type (e.g. small versus large language model): a significant change needing a new test and validation
protocol and a new submission.

5) Change to the benchmarking protocol: typically even more substantial than a model change, requiring a new submission
with a revised PCCP unless it is not safety-impacting and can be justified in a letter to file.

23 PCCP for GenAI The approach could be similar to non-device wearables being used as inputs to device software. There are multiple examples
of 510(k)-cleared PCCPs that pre-approve various wearable models and providers against a common set of acceptance
criteria and test protocol. Likewise, different foundation models and accepted behaviors could be pre-approved in a GenAI
PCCP. The specifications should be focused on the benchmarking performance metrics and other criteria (e.g. provider
requirements) and not necessarily on the exact definition of which models.

24 Third-party model Stringent supplier evaluation should be performed for AI tools critical to the device. Foundation models are, in effect,
changes off-the-shelf (OTS) software, so FDA's existing OTS software guidance provides the starting point for this evaluation. LLM
Cyberspace Administration of China. Provisions on the Administration of Anthropomorphic Interactive Artificial Intelligence Services (2026).
Cyberspace Administration of China. Interim Measures for the Management of Generative Artificial Intelligence Services (2023).
FDA. 510(k) K241006, Natural Cycles (NaturalCycles Nordic AB), cleared July 11, 2024, with a PCCP enabling use of a broader range of temperature
measuring devices for future wearable integrations.
FDA. Off-The-Shelf Software Use in Medical Devices. Guidance, August 2023.
Q# Topic Edge comment

providers should offer specific terms and conditions covering change notification and continuity, which may eventually push
the sector to develop more rigorous offerings for these categories of applications. Foundation model developers typically
guarantee a minimum notice period before a model version is retired (e.g., 60 days for Anthropic Claude, or a 6-month legacy
44,45
period for AWS Bedrock models).

PCCPs should include multiple models and potentially multiple providers that have been successfully evaluated and validated,
so that a backup model is always available in case one is unavailable or decommissioned. Devices built on hosted models
should run on a pinned, version-identified model endpoint, so the provider cannot change the model silently. A small fixed set
of probe inputs with known expected outputs, run frequently against the live endpoint, can detect unannounced changes
between scheduled re-benchmarking.

VII. Other (MAF / Agentic)

25 Foundation Model We would welcome clarity on whether FDA would regulate small models developed by individual manufacturers differently
MAFs from large, general-purpose foundation models from third parties that are not medical devices. These should arguably be
treated quite differently, and FDA could encourage and incentivize small models as much as possible for better control over
behavior changes, privacy and security.

Under the proposed MAF, foundation model providers would be responsible for submitting voluntary documentation to FDA.
This risks a non-harmonized global system that becomes unsustainable if other authorities ask for similar documentation with
different content, especially as disclosure remains voluntary. Notably, open-weight models (e.g. DeepSeek) can be inspected
more directly than proprietary hosted models, although open weights do not disclose training data.

As a large part of society is being built on these foundation models, this information at some level should be made publicly
available, at least as summary safety cards published on the developer's website and accessible to anyone, rather than disclosed
confidentially only to FDA. The UK National Commission has proposed a similar opt-in master file, alongside manufacturer
reporting of dependencies on general-purpose models, with continuity plans, and system-level monitoring of reliance on a few
providers; aligning these approaches would spare manufacturers duplicate submissions (see Q21). A master file should
support, not shift, the sponsor's responsibility for the device. Content should mirror basic benchmarking: scope and safety
refusals (e.g. emergency care, change of scope, self-harm), hallucination risk and general accuracy, covering basic
general-purpose behavior rather than intended-use-specific safety.
Anthropic. Claude Platform Docs: Model deprecations.
Amazon Web Services. Amazon Bedrock User Guide: Model lifecycle.
National Commission into the Regulation of AI in Healthcare. Recommendations for a future regulatory framework. MHRA, September 2026.
Q# Topic Edge comment

26 Agentic AI For agentic GenAI-enabled devices, the highest-risk failures could occur at the interface between devices. Interface
connections should be considered a special category, in the same way that device APIs are already regulated with defined
permitted uses, as with the data APIs of connected CGMs (see Section 2). Agentic devices should also require human
authorization before irreversible or high-consequence actions, support halt and rollback, and keep tamper-evident logs that
allow the agent's actions to be reconstructed.

Agentic workflows should be encouraged to incorporate deterministic elements as far as possible, and the risk of the
highest-risk component of the agentic system should apply to the entire system, with effective non-GenAI risk controls then
setting the mitigation expectations (Q1). This logic is similar to that of software within IEC 62304, whereby the safety risk
classification of software items is judged prior to the implementation of software risk controls but considering risk controls
other than software.