Associazione Tendenze Salute Sanità - AT2S

Docket No. FDA-2026-N-7874. Comment of Associazione Tendenze Salute e Sanità (AT2S), Verona, Italy, on "Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback". The full comment is attached as a PDF. It has two parts: Part A, the comment of AT2S through its Centro Studi AI-Native Digital Health (seven themes covering Questions 1-3, 5-11, 14-15 and 18-26), and Part B, the contribution of the expert patients of AT2S’s Network (Questions 1-6, 15, 21 and 26). Contact: centrostudi@tendenzesalutesanita.org

Docket No. FDA-2026-N-7874 — AT2S

Docket No. FDA-2026-N-7874

Comment on “Considerations for the Regulation of Generative
AI-Enabled Medical Devices: Discussion Paper and Request for
Feedback”
Submitted by Associazione Tendenze Salute e Sanità (AT2S)
through its Centro Studi AI-Native Digital Health (AI-Native Digital Health Study Center)
Verona, Italy — centrostudi@tendenzesalutesanita.org
October 2026

Structure of this submission
Part A — Comment of AT2S (seven themes covering Questions 1–3, 5–11, 14–15 and 18–26)
Part B — Contribution of the expert patients of AT2S’s Network (Questions 1–6, 15, 21 and 26)
 Docket No. FDA-2026-N-7874 — AT2S

PART A — COMMENT OF AT2S
1. Introduction
Associazione Tendenze Salute e Sanità (AT2S) is a non-profit association based in Italy, established in 2026 in
ideal continuity with Fondazione Tendenze Salute e Sanità ETS (formerly “Fondazione Smith Kline”),
established in Italy in 1979 and recognized in 1982 by the President of the Republic (Presidential Decree of 9
September 1982, no. 917), which has worked on health and healthcare policy and on technological
innovation. AT2S takes part in this consultation on the Discussion Paper “Considerations for the Regulation of
Generative AI-Enabled Medical Devices” through its Centro Studi AI-Native Digital Health (the Study Center).
AT2S contributes two sources of experience. The first is that of the expert patients of the Association’s
Network “Pazienti Esperti in Tecnologie Digitali per la Salute” (Expert Patients in Digital Health Technologies
Network), who have discussed the positions expressed in this Part A and share them, and who provide their
own contribution in Part B. Throughout this document, experience with patients is that of the Network only.
The second is the experience that the Study Center draws from the development of two prototype
applications for patients, owned by daVi Digital Medicine S.r.l. (daVi), a Participating Entity of the Association:
one for sleep wellness (Health & Wellness category), whose intended use is to improve sleep quality and not
to treat insomnia, and one for arterial hypertension (Care Support Products category). Both are built on a
third-party foundation model. They are proofs of concept: they are not authorized, are not marketed as
medical devices and have no clinical validation. Because daVi participates in the Association, AT2S has access
to a development experience that other associations do not have: our contribution is therefore not only
theoretical but also experiential. The developers of these prototypes are in the position that the Discussion
Paper describes: they inherit responsibility for the behavior of a model they do not control.
The Study Center has also developed a five-stage validation framework for AI-Native applications, which we
use as an operational example.
Declaration of interests. The signatory is a physician, President of the Association and one of the clinicians of
the Study Center team; he is also one of the co-founders of daVi, the company that owns the prototypes cited.
daVi supports the Association free of charge as a Participating Entity: it is not a member and has no vote in the
General Assembly; under the Statute it is entitled to one dedicated seat on the Board of Directors, which is
currently vacant. The Association and the company are distinct entities. Some proposals below, notably on the
wellness exclusion (Theme 1), could affect products such as the prototypes cited.
Context. To our knowledge, FDA has not publicly identified any authorized device as using generative AI. FDA’s
list of AI-enabled devices (last updated 4 September 2026; consulted on 18 October 2026) does not tag
devices that incorporate foundation models; FDA states that it will explore methods to do so. On 23 December
2025 FDA granted 510(k) clearance to a device with a conversational service (K253281, UpDoc), which its
manufacturer publicly presents as incorporating patient-facing language models. FDA’s documentation,
however, describes a clinical core that calculates insulin instructions from parameters defined by the clinician,
with a predetermined change control plan (PCCP) requiring that the dosing logic remain deterministic, and
does not characterize the device as based on generative AI. In our reading, what FDA evaluated is the
deterministic clinical function; we therefore do not treat it as a precedent for generative components, and we
cite it only as an architectural example (a conversational service on a deterministic clinical core) (Themes 4
and 5).
Scope. The Discussion Paper invites responses to the questions without any obligation of completeness. We
have examined all 26 questions. We respond through seven themes covering Questions 1, 2, 3, 5, 6, 7, 8, 9, 10,
11, 14, 15, 18, 19, 20, 21, 22, 23, 24, 25 and 26, choosing the topics on which we have direct experience: the
patient’s point of view, and AI-Native applications for wellness, care support and therapy. AT2S does not
comment on Questions 12, 13, 16 and 17, nor on Question 4, which is addressed from the patient’s
perspective in Part B.
 Docket No. FDA-2026-N-7874 — AT2S

Methodological premise. We always distinguish what has been built, what has been tested and what is only a
design objective. No quantitative threshold of our framework is today a measured result, except those
expressly reported with their method. We ask FDA to treat this distinction as a requirement for sponsors’
documentation.

2. Seven themes

Theme 1 Risk to the patient
Questions 1, 2 and 3
The two-axis framework (what the device does; what consequence an erroneous output has) captures the
core of the risk. For conversational applications aimed at patients we find it incomplete in six respects, which
we propose to bring into the risk framework itself and not only among the elements of evaluation.
Six dimensions to add (Question 1)
(1) Reversibility: advice that is easy to undo (repeating a measurement) differs from advice whose
consequences are hard to correct (changing a habit linked to a therapy); today this remains implicit in the
consequence axis. (2) Detectability of error: generative AI errors are plausible; if neither the user nor a
clinician notices them, the risk is higher for the same severity. (3) Vulnerability of the user at that moment: the
same answer weighs differently on someone with occasional insomnia and on someone with a mood disorder.
(4) Cumulative and relational effects over time: dependence, a false therapeutic alliance and the system’s
tendency to agree with the user, which emerge across sessions and not in a single response (De Freitas and
Cohen, Nature Medicine 2024; American Psychological Association health advisory, 2025). (5) Exposure to
unannounced changes of the third-party model (Theme 4). (6) Coverage of languages and populations: safety
demonstrated in one language does not carry over to others.
From information to direction (Question 2)
Directiveness is not a fixed property of a message: it depends on tone, specificity, personalization and the
moment in the conversation. We ask sponsors to describe where each function sits between information and
direction, and why. This is a design hypothesis, not a measured finding. The boundary with therapy is clear in
terms of intended use: an application that uses some elements of the cognitive-behavioral approach, without
delivering a formal and complete module, remains within wellness; a complete module of cognitive
behavioral therapy for insomnia would be a medical intervention delivered by software, that is, a digital
therapeutic (ISO/TR 11147:2023).
Why risk changes for the patient (Question 3)
The risk does not arise from the user being a patient, but from the absence of mechanisms that compensate
for the asymmetry of knowledge. The prototypes of the Participating Entity daVi incorporate such
mechanisms by design: a safety control that does not depend on the user’s clinical understanding, answers
anchored to curated scientific sources with verified citations, and clinical supervision of the content upstream.
Presuming that patients cannot judge for themselves would be the opposite error: protection should help
them understand, not replace their judgment.
Wellness and the boundary of medical devices
By definition, software for wellness purposes is not a medical device. In the European Union, Regulation (EU)
2017/745 (recital 19) says so: software for general purposes, even when used in a healthcare setting, or
software intended for life-style and well-being purposes, is not a medical device. In the United States, section
520(o)(1)(B) of the Federal Food, Drug, and Cosmetic Act (added by the 21st Century Cures Act in 2016)
excludes from the definition of device software functions intended for maintaining or encouraging a healthy
lifestyle and unrelated to the diagnosis, cure, mitigation, prevention or treatment of a disease or condition,
and FDA’s General Wellness guidance (reissued on 6 January 2026) includes sleep among its examples of
general wellness uses. The Discussion Paper concerns medical devices, and we do not discuss its perimeter.
 Docket No. FDA-2026-N-7874 — AT2S

But this exclusion was defined before generative AI, for software with fixed content and functions. Firstgeneration deterministic wellness applications could have a well-defined perimeter: their content and
functions were fixed, and their intended use could be verified by inspecting them. A conversational AI-native
wellness application can, in principle and in practice, range beyond wellness. It is hard to build a knowledge
base, or any other boundary on knowledge, limited to wellness alone, because the conversation is driven by
the user, who can bring symptoms, diagnoses and therapies into it. Intended use is then no longer guaranteed
by the design of the application. Users can be expected to bring such content into the conversation: this is
foreseeable use.
As long as there is no medical diagnosis we are in the realm of wellness, and we do not ask that these
applications be regulated as devices. We ask FDA to assess whether the exclusion requires at least a fresh
reconsideration, distinguishing intended use from foreseeable use. The same reflection applies to the
European framework.
Proposals to FDA
• Add reversibility, detectability of error, user vulnerability, cumulative effects, exposure to third-party
model changes, and language and population coverage to the risk framework.
• Ask sponsors to place each function on the information-to-direction spectrum.
• Reconsider the exclusion of generative AI wellness applications, taking into account foreseeable use and
not only declared use.

Theme 2 Conversation and escalation
Questions 5 and 6
The trajectory (Question 5)
In conversational applications, risk is a property of the trajectory, not of the single message. We propose that
intended use be defined per session and per pathway, and that multi-turn trajectories written by clinicians be
tested, including those that slide gradually toward direction. The validation performed so far on the
prototypes concerns single inputs, not long conversations.
Two errors that must not be merged (Question 6)
False alarms and missed alerts must be measured and reported separately. They cannot be merged into a
single balance figure, because they are not commensurable and the acceptable trade-off depends on context.
In a sleep wellness application, frequent false alarms have a real cost: the user feels judged, stops trusting the
messages and abandons the application, and abandonment is already the central problem of first-generation
digital applications. A missed alert has the opposite cost, potentially very serious. In an application for an
already diagnosed clinical condition the balance would be different.
The design choice and what we know
The OR combination of the two levels of the prototypes’ safety control is an explicit choice in favor of
sensitivity: it raises the probability of flagging a real risk, at the price of possibly more false alarms. We do not
report the rates of the single level, because in isolation they would be misleading: a level that looks for literal
matches cannot detect paraphrases, while a semantic one may confuse common hyperbole. What we report
is the method: the two errors measured separately, by level and by linguistic category, with known limits
declared. The trade-off of the complete system has not yet been measured.
Measuring missed cases in the real world
After marketing, false alarms are visible (the user reports or ignores them); missed cases are not. Estimating
them requires clinical sample review of the conversations that were not flagged. We propose that this review
be a monitoring requirement for escalation functions.
 Docket No. FDA-2026-N-7874 — AT2S

Graduated responses
The cost of a false alarm depends on what follows. We propose a graduated escalation, starting with a
verification question and moving to urgent indications only when needed: it reduces the cost of excess errors
without reducing sensitivity.
Proposals to FDA
• Define intended use per session and per pathway, and test multi-turn trajectories written by clinicians.
• Ask for both types of error to be reported, by clinical context and linguistic category, and for thresholds
to be justified, including with the input of end users.
• Ask for clinical sample review of non-flagged conversations as part of postmarket monitoring.
• Encourage graduated escalation, with its rules declared.

Theme 3 How to evaluate generative AI devices
Questions 7, 8, 9, 10, 11, 14 and 15
An approach inspired by the evaluation of clinicians (Question 7)
We agree with the competency-based approach. Clinicians are not evaluated by testing every scenario, but
through examinations, supervised practice with increasing autonomy, and continuing re-evaluation: this is the
logic that the Study Center’s five-stage framework applies to AI-Native applications. Stage 0 (certification of
the safety of the architecture before any exposure of people) corresponds to the examination; Stages 1 to 3 to
the supervised training with increasing autonomy; Stage 4 to continuing re-evaluation. We also share the
choice to evaluate the final device, as configured, and not the model alone: safety controls are part of the
device.
Four additions
(1) Version-bound qualification. A clinician does not change on their own; a model does: qualification should
refer to a version and be reconsidered when it changes (Theme 4). (2) A declared scope of practice, including
the conditions in which the device must stop and hand over to a person. (3) Expert patients as standardized
patients. In medical education, structured clinical examinations are conducted with simulated patients:
expert patients can write realistic scenarios and judge the device’s communication (comprehensibility,
empathy, the risk of over-trusting a fluent AI), which is one of the evaluation elements proposed by FDA. (4)
Hazard analysis as a complement: starting from possible harms (a missed crisis, a false reassurance)
complements competency testing, because the failures of generative AI (confabulation, manipulation) are not
those of an examination. Finally, the sponsor remains responsible: the consequences that are professional
and legal for a clinician must have an equivalent for whoever places the device on the market.
Proportionality of evidence (Questions 8 and 11)
The level of evidence should grow with the position on the two axes, with a minimum safety threshold for the
architecture that applies to all profiles. Proportionality has two dimensions: the type of confirmation and the
strength of the claim to be supported. The second is less discussed. As to the type of confirmation, the
framework proposes a stepwise pathway: feasibility and safety in small samples (Stage 1), an adaptive efficacy
study with the model version locked (Stage 2), a pragmatic study in real conditions with periodic clinical
review (Stage 3), continuing surveillance (Stage 4), all preceded by certification of the safety of the
architecture (Stage 0). Intensity grows with the risk category according to the Digital Therapeutics Alliance
classification of digital health technologies (Guidance to Industry, 2023), from Health & Wellness to Care
Support and digital therapeutics: for contained-risk applications, benchmarks and real-world monitoring
suffice; for those that act on an existing clinical condition, a prospective study is needed. This is a structural
proposal, not a result: neither of the two prototypes has yet passed Stage 1.
The strength of the claim and the sample size
The first test of the prototypes’ safety control teaches a lesson. With 64 cases one cannot support a falsenegative rate below 0.1%, which is the objective of Stage 0. If no error is observed in n positive cases, the 95%
upper bound on the error rate is about 3/n: to support 0.1%, about 3,000 positive cases without errors are
 Docket No. FDA-2026-N-7874 — AT2S

needed. The calculation holds for independent cases, and these are not: they have a single author and a single
language, and they reflect the formulations of that author and of the scales from which they derive.
Correlated cases are worth less than independent ones, so the real bound is worse than the calculated one.
We declare this as a limit of this first test and propose it as a criterion for submissions.
What is measured and who validates it (Questions 9 and 10)
We point out a possible gap: for devices with unstructured conversational input, the accuracy of extracting
clinical data from speech is a competency distinct from the analytical capabilities applied to the output. In the
prototypes it is implemented, with qualitative tests but without a formal statistical benchmark. A benchmark
built by the sponsor has value only with independent external validation: the test cases of the prototypes are
internal, and we declare so. We point to VERA-MH (Bentley et al., JMIR AI 2026) as an example of a published
benchmark validated with clinicians.
The comparator (Questions 14 and 15)
For contained-risk applications aimed at patients, the most realistic comparator is not an ideal specialist
consultation: between one visit and the next, the alternative is the near-total absence of structured support.
Real-world use of first-generation mental health applications is consistent with this: in an analysis of 93
applications, median retention at 30 days was 3.3% (Baumel et al., JMIR 2019). We propose usual care,
without structured digital support, as an admissible comparator: not a lower bar, but the honest
counterfactual against which to measure real benefit.
The context of use changes the evidence
In a global study of a monitoring application in multiple sclerosis (Oh et al., Scientific Reports 2024), during the
first 16 weeks 71.7% of participants with multiple sclerosis in the Danish cohort, which followed a supervised
research protocol, were persistent users, against 20.6% in the other countries; Figure 4 of the study shows a
collapse of persistence after the end of the protocol. We ask that studies of patient-facing applications declare
the level of supervision and report use also after it ends.
Proposals to FDA
• Tie qualification to a version of the model, with new evaluation when it changes.
• Ask sponsors to declare their scope of practice and the conditions for handover to a person.
• Include expert patients, as standardized patients, in the evaluation of the communication of patientfacing devices.
• Complement competency testing with a hazard analysis.
• Associate every performance claim with the sample size that supports it, with the calculation method,
and declare the independence, number of authors, languages and populations of the test cases.
• Limit the claim to what the sample supports (“no error observed in n cases”, not “rate below x”).
• Recognize usual care, without structured digital support, as an admissible comparator for contained-risk
applications.
• Ask that studies declare the level of supervision and report use also after it ends.

Theme 4 The third-party model and change control
Questions 19, 22, 23, 24 and 25
The Study Center responds with the experience of developing prototypes built on a third-party foundation
model. Developers do not control when and how the model is updated, but they inherit the consequences on
the behavior of the application. Today there is no documented process of detection and re-evaluation for a
sponsor in this position. It is the most concrete vulnerability we have identified.
The first tool is design (Question 24)
Components that depend on the model are separated from those that do not. The prototypes’ safety control
has a deterministic level, which a model update cannot change, and a level based on the model itself, which is
a function invoked by the model. If the model changes, both the answer and the control that oversees it may
 Docket No. FDA-2026-N-7874 — AT2S

change: this is a common-mode failure. For this reason the model-independent level is not a duplicate: it is the
part that does not move when the model moves. A similar pattern appears in the documentation of K253281:
a clinical core that the model cannot modify and a change control plan that constrains it (its PCCP requires
keeping the dosing logic deterministic). We suggest indicating this pattern as good practice for devices built on
third-party models.
How to detect a change: three channels, not mutually exclusive
(a) Informational or contractual. Today there is no duty of notification toward the sponsor. Model providers
communicate on their own initiative, through general channels, and sometimes announce safety measures
for health uses: useful signals, but voluntary, unilateral and not addressed to sponsors. (b) Technical. After
every observed version change, or at set intervals, a fixed set of test cases written by clinicians on the safety
functions is repeated and the result compared with the reference. It works under two conditions: that a
reference result exists and that one knows when the model has changed. The second is not a given: a model
may be updated without the identifier used to call it changing. (c) Behavioral. Statistical monitoring of output
indicators (frequency of activation of the safety control, refusal rate, length and structure of responses,
frequency of source citation), with preset limits that trigger a re-evaluation. This is the only channel that does
not depend on the provider’s cooperation and that can notice an unannounced change: we regard it as a
requirement, not an option.
How to respond, and how to classify modifications (Questions 19, 22 and 23)
The response must be decided beforehand: who evaluates, within what time, with which tests, and which
thresholds lead to limiting or suspending the function. We propose classifying modifications in four groups by
impact on safety: curated scientific content (ordinary quality system, with clinician review); non-clinical
configuration (quality system with regression tests); safety thresholds and criteria (formal review or PCCP,
with new validation); changes of the model by third parties (detection and new benchmarking). The extent of
new benchmarking grows with the proximity of the modification to the safety functions. The cadence of reevaluation should be driven by events (a version change, a drift threshold exceeded, a signal of harm), with a
baseline calendar, for us quarterly. A PCCP presupposes foreseeable modifications, but updates of a thirdparty model are not: for these devices the PCCP should describe the surveillance process (how a change is
detected, which tests are run, which thresholds suspend use, who decides) and not the content of the
modification. In clinical studies we propose locking the model version for the whole duration.
Foundation Model Device Master Files (Question 25)
The prototypes of daVi are built on a third-party foundation model: the Study Center is interested in this
mechanism and willing to support it with the provider. We recognize the problem that FDA itself raises:
participation depends on the provider’s willingness, over which the sponsor has no leverage. A voluntary
program is useful, but cannot be the only mechanism. To be useful to a sponsor it should contain at least:
stable version identifiers; a calendar of updates and retirement of versions; advance notice of changes, with a
minimum to be defined; known changes of behavior between versions; a summary of the safety evaluations
performed for sensitive health uses, with method and limits; and a statement on whether a model can be
updated without changing its identifier. A practical incentive is the possibility of referring to a single file in
many submissions, instead of handling repeated bilateral requests; another is for FDA to indicate that
referencing an up-to-date master file simplifies review. As complements: minimum contractual notification
clauses, with a model proposed by the agency; an independent body certifying versions of models for health
uses, of NIST type (Ong et al., npj Digital Medicine 2026); and, for models that do not participate, higher
scrutiny for sponsors who use them for critical functions.
What exists and what does not
What exists is the separation between model-dependent and model-independent components, and a first set
of test cases, built by a clinician from validated scales, so far run on the deterministic level only. What does not
yet exist is a reference result for the model-based level or a complete cycle of detection and re-evaluation. At
present, the prototypes call the model through an alias and not through a locked version. Version locking,
quarterly review and drift thresholds are design objectives, not yet put to the test.
 Docket No. FDA-2026-N-7874 — AT2S

Proposals to FDA
• Ask sponsors to declare the identity of the model, the version policy (version locked or not), how they
learn of updates, and which criteria trigger a new test.
• Ask for the architecture to distinguish model-dependent from model-independent components, and to
indicate which critical safety controls remain independent.
• Indicate as good practice the pattern “clinical core that the model cannot modify, plus a PCCP that
constrains it”.
• Consider behavioral monitoring, with predefined thresholds, a requirement for devices built on thirdparty models.
• Recognize that a PCCP can have as its object a surveillance process, when the content of the
modifications depends on third parties.
• Define a minimum content for master files and notification clauses, and ask for transparency on updates
without a change of identifier.
• Do not make the voluntary program the only mechanism: maintain the sponsor’s obligations.

Theme 5 Agentic systems and supervision
Questions 20 and 26
We do not claim that the prototypes are agentic devices in the sense of Section VII.B (planning and
autonomous sequences of actions), and we do not claim agentic capability as their distinguishing feature.
Agentic proactivity is for us a frontier under exploration, not an adopted feature, and we consider it a category
of risk to be governed, as FDA proposes. The prototypes use a limited number of predefined functions and do
not autonomously plan sequences of actions. Even a limited number of predefined functions raises, however,
the question of when human control is needed.
Additional considerations and acceptance criteria (Question 26)
We respond with six points. (1) Inventory of actions: the sponsor declares which actions the device can
perform without user input and which tools it uses, and classifies them by consequence, reversibility and need
for human confirmation. (2) Control points: for high-consequence actions, a control that can be demonstrated
separately and is independent of the generative model. (3) Failures: a safe default behavior when a tool or a
control does not respond. (4) Manipulation: resistance to hidden instructions in user inputs, retrieved content
and tool outputs. (5) Postmarket: a log of the actions performed and of escalation outcomes, with sample
review. (6) With less human review downstream, more supervision upstream is needed: curation of content
and validation of protocols.
What has been built in the prototypes
First, the safety control. In the text pathway it has two levels in OR logic: a deterministic level, with no
dependence on AI models, and a model-based level. If either flags, the input is routed to a predefined
escalation pathway. The control is a structural property of the routing, not a monitoring layer added
afterwards. Second, human supervision as a design choice: the clinician defines the clinical content (risk
phrases, criteria, thresholds) before it is technically transposed, and curates the knowledge base. Software
development is assisted by AI programming tools; by rule, clinical content always comes from the clinician and
is never generated by the tool.
How the control is being validated, and with what limits
We propose the method as a precedent, more than the numbers. Test cases written by the clinician from four
validated scales (Beck Hopelessness Scale, Beck Scale for Suicide Ideation, Nurses’ Global Assessment of
Suicide Risk, Columbia-Suicide Severity Rating Scale). Testing separately by level, because a level that looks for
literal matches does not recognize paraphrases by construction, and a single overall figure would hide this
fact. Results broken down by linguistic category: direct expressions, indirect ones, everyday hyperbole,
negations. A distinction between a known and diagnosed limit and an anomaly. No claim beyond the data. The
limits are significant: the cases are few, are single utterances, have a single author and a single language, were
 Docket No. FDA-2026-N-7874 — AT2S

built within the Study Center and have not been validated by independent third parties. The control has been
tested only on text inputs; the voice channel, where transcription arrives in fragments, has not been tested.
The model-based level does not yet have a safe default when the model call fails. The result of the complete
system, that is, of the two levels together, which is the one that matters for real safety, has not yet been
measured and we report no estimates. The design objective of our Stage 0, which requires verification on a
much larger number of simulated cases, has not yet been verified. Tests of resistance to hidden instructions
and of tool failures have not yet been performed.
AI-based supervisory agents (Question 20)
They can extend monitoring beyond what staff can review, but they are themselves AI systems that can err.
They must be validated with the same rigor as the system they oversee, by comparing them with clinicians’
judgment on representative cases and reporting the agreement next to that between clinicians. An
encouraging but circumscribed precedent is VERA-MH: a language-model-based evaluator reached with
clinicians an agreement comparable to that between clinicians (IRR 0.81 versus 0.77), on a narrow task,
suicide risk in chatbots; it does not transfer automatically to other domains. The most important point for a
sponsor using a third-party model is independence: if the supervisor is invoked by the same model that
generates the answers, an update can alter generation and supervision together (Theme 4). For this reason a
model-independent control for critical functions is kept alongside the AI-based supervisor. The supervisor
must be included in regression tests and drift monitoring; its errors are invisible by construction, so sample
human review of unflagged material is needed; it should flag and route to people, not take final clinical
decisions; and its decisions should be logged.
Proposals to FDA
• Require an inventory of actions with classification by consequence, reversibility and human
confirmation.
• Require, for high-consequence actions, a control demonstrated independently of the generative model
and reported by level.
• Require disaggregated reporting, with known limits and with the size, independence and language of
the test cases declared.
• Consider upstream supervision (curation of content, validation of protocols) as evidence of supervision,
not only downstream review.
• For supervisory agents: validation against clinician consensus, a declaration of independence from the
supervised system, inclusion in change control, and sample human review of unflagged material.
• Encourage external validation with independent benchmarks.

Theme 6 The role of patients in postmarket monitoring
Question 21
Regulatory responsibility remains with the sponsor and cannot be delegated. Others contribute: the clinician
curates content and reviews samples; scientific societies can provide evaluation criteria; patient associations
can provide a channel for reporting unexpected behavior from the point of view of those who use the
application, a type of signal that technical controls do not see. The Network of expert patients of the
Association has discussed this role and shares it.
Proposals to FDA
• Recognize patients and associations as a source of postmarket safety signals, keeping the sponsor’s
responsibility intact.
• Expert patients as agents of improvement, with their input integrated into postmarket surveillance
reports.
 Docket No. FDA-2026-N-7874 — AT2S

Theme 7 More weight on postmarket monitoring for contained risks
Question 18
It may be appropriate for contained-risk applications (Health & Wellness), but not for those that act on an
existing clinical condition (Care Support, digital therapeutics), where we consider certification of the safety of
the architecture before use to be non-negotiable. Postmarket monitoring compensates for premarket
uncertainty only if it is truly able to detect harm: this is why review of unflagged cases and the patients’
reporting channel matter (Themes 2 and 6).

3. Questions not commented
We do not comment on Questions 12 and 13 (statistical measurement and synthetic data), 16 (independent
third parties) and 17 (multimodal and predictive models), because we have no direct experience in these
areas and prefer not to express positions that are not well founded. Question 4 (generalist and specialist
physicians) is addressed from the patient’s perspective in Part B.

4. Conclusion
The Study Center appreciates the approach of the Discussion Paper and, in particular, the attention to the full
product life cycle, to behavior in real use and to human supervision. It offers CDRH its availability to share the
testing methodology of the prototypes, to the extent it is not confidential, and to take part in further
discussions, also with the contribution of the expert patients of the Association.

5. Signature
Associazione Tendenze Salute e Sanità (AT2S)
Verona, Italy
centrostudi@tendenzesalutesanita.org
On behalf of the Association: the President
 Docket No. FDA-2026-N-7874 — AT2S

PART B — CONTRIBUTION OF THE EXPERT PATIENTS’ NETWORK
Network “Pazienti Esperti in Tecnologie Digitali per la Salute” (Expert Patients in Digital Health Technologies
Network) of AT2S

1. Response to FDA’s request for feedback on generative AIenabled medical devices
As an Expert Patient, a caregiver and a person who lives the challenge of managing health every day, my goal
is to bring into regulation the authentic voice of those who will actually use these applications. Technology
must not replace the human relationship or treat us as passive users, but accompany us with care, empathy
and respect in the essential and often lonely space between one medical visit and the next.

2. Responses to FDA’s questions

Question 1 Two-axis risk assessment framework and reversibility of recommendations
FDA Discussion Paper, Section IV, Question 1
My vision as a patient. When I use a health app, I immediately perceive the difference between a “light” piece
of advice and one that can upend my day or my treatment. Risk is not only a mathematical formula: it
concerns how easy or hard it is to “go back” after following a suggestion.
Example from everyday life. If the app suggests that I drink one more glass of water, rest for half an hour or
measure my blood pressure again after a few minutes, I can do it calmly: if the advice was unnecessary, it is
corrected instantly with no consequences. But if an app suggests that I skip a tablet or change the dose of a
life-saving or continuous medicine (such as an anticoagulant, an antihypertensive or an immunosuppressant),
I cannot simply “undo” that act. If I take the wrong dose, the effect on my body is immediate, irreversible in
the short term, and the anxiety of having made a serious mistake stays with me until I manage to speak with
my doctor.
Proposal to FDA. I ask that regulation explicitly include the reversibility of the action as a key criterion for
assessing risk. Advice that is hard to undo must be treated with the highest level of protection.

Question 2 Spectrum of informational functions and degree of directiveness
FDA Discussion Paper, Section IV, Question 2
My vision as a patient. When I am anxious or vulnerable because of a sudden symptom, I do not read an app
with the detachment of a technician. The words used by the AI weigh enormously on my peace of mind.
Example from everyday life. Suppose I enter a slightly high blood pressure or glucose value into the app. If the
app writes “Values above 140/90 may indicate a hypertensive state”, I read it as useful information that helps
me understand. But if the app answers “Your value is high: you should take another tablet immediately or
have someone take you to the emergency room”, the language becomes peremptory and personalized. At
that moment, even if a small print at the bottom of the page says “This app is not a doctor”, I cannot
rationalize that disclaimer: I perceive the answer as a frightening medical order pushing me to act
immediately in the emergency services.
Proposal to FDA. Risk assessment must consider the tone, the specificity and the emotional charge of the
message. An app cannot hide behind a generic disclaimer if it then uses language that frightens or steers the
patient as if it were a prescription.
 Docket No. FDA-2026-N-7874 — AT2S

Question 3 Informational functions for patients vs. healthcare professionals
FDA Discussion Paper, Section IV, Question 3
My vision as a patient. I want to feel protected by the app I use, but I do not want to be treated as someone
unable to understand. Too often one swings from extreme bureaucratic coldness to paternalism.
Example from everyday life. When I read a report or an odd value and ask the app for explanations, I do not
want it to reply with a curt “I cannot answer, ask your doctor”, leaving me alone with my agitation, searching
chaotically for answers on the internet. I truly feel protected and respected in my abilities when the app
explains things in simple but accurate words, indicating which guidelines the information comes from,
admitting its own limits when the situation is uncertain and offering me a clear summary to show my doctor at
the next visit.
Proposal to FDA. Ensuring patient safety does not mean restricting information, but promoting
empowerment: clear answers, an explanation of uncertainty, transparent sources and an explicit clinical
deferral mechanism that invites me to contact my doctor, providing a useful summary of the conversation.

Question 4 General practitioner vs. specialist physician and impact on risk
FDA Discussion Paper, Section IV, Question 4
My vision as a patient. In the patient’s care pathway, one comes into contact with different health
professionals. An app meant to support a general practitioner on highly specialized topics presents different
risk profiles from an app designed for the patient or for the specialist.
Example from everyday life. When I see my family doctor for a complex problem linked to a rare or
specialized chronic condition, the doctor must interpret very specific symptoms and dosages. If the doctor
uses an AI app to find their bearings on a specialist therapy (for example a rheumatological or oncological
treatment plan) without specialist training in that branch, there is a risk of relying on the AI output without
grasping clinical subtleties that only a specialist would know.
Proposal to FDA. FDA should assess risk also according to the specific competencies of the end user: if the app
provides specialist-level information to a general practitioner or to a patient, context warnings and filters
(specialist-level safeguards) should be provided to avoid inappropriate therapeutic decisions.

Question 5 Multi-turn conversational trajectories and changes of the AI “engine”
FDA Discussion Paper, Section IV, Question 5 (see also Section VI, Question 24)
My vision as a patient. A conversation with a digital assistant is like a continuous dialogue: it starts in general
terms and, one detail after another, one finds oneself opening up more and more. At the same time, whoever
uses the app must be able to rely on stability of behavior over time.
Example from everyday life. A conversation can start with a simple, generic question about tiredness. Answer
after answer, guided by the app’s questions, the person begins to describe daily symptoms, the medicines
they take and their fears. Without noticing at first, the conversation “slides” from a simple informational
exchange to personalized advice on which tests to take or how to change habits.
Today many health apps are built on generative AI models supplied by large third-party technology
companies. The enormous problem for us patients is that today there is no structured, public way to know in
advance when the company that makes the model is about to update or modify it, silencing certain behaviors.
This means that from one day to the next the app could answer differently to the same question.
Proposal to FDA. (1) FDA must assess the entire (multi-turn) trajectory of the conversation, with filters that
block the slide toward direct, unauthorized advice. (2) Practical solutions to intercept model changes in time.
Automatic daily tests (control prompts): the developers of the health app must send the model every day a set
of fixed, validated test questions (continuous automatic benchmarking) to check whether the answers change
suddenly before patients notice. Independent safety filter (layered architecture): insert a rule-based safety
filter that checks the AI’s outputs before they are shown on screen, blocking dangerous answers regardless of
 Docket No. FDA-2026-N-7874 — AT2S

updates to the underlying engine. Transparent notification to the user: indicate in the app, with a clear notice,
when the underlying model has undergone a significant update.

Question 6 Escalation of care and balancing of errors (under-escalation vs. over-escalation)
FDA Discussion Paper, Section IV, Question 6
My vision as a patient. Trust is fragile. If an app keeps frightening me with unjustified alarms, I end up no
longer listening to it, precisely when it could really be needed.
Example from everyday life. Of course, an app must never underestimate a serious symptom such as a dull
chest pain. But if every time I report a slight headache or a little nausea the app tells me to rush to the
emergency room or call the emergency number, alarm fatigue sets in. After two or three “false alarms” that
gave me a terrible scare and sent me on useless trips, I stop believing the app and uninstall or ignore it, risking
missing a real alarm in the future.
Proposal to FDA. Evaluation criteria must carefully balance both the risk of ignoring a danger and that of
generating continuous false alarms. A safe app must know how to reassure in measure, supporting the
person’s serenity and respecting the resources of the health service.

Question 15 Performance comparators and reference standards
FDA Discussion Paper, Section V, Question 15
My vision as a patient. When assessing whether an app is useful and safe, it makes no sense to compare it
with an ideal condition that does not exist in everyday life.
Example from everyday life. In daily life, weeks or months pass between one medical visit and the next. In
that suspended time, when on a Saturday night I have a doubt about a symptom or a reaction to a medicine,
my real alternative is not an immediate consultation with the hospital’s chief physician, but silence, loneliness,
anxiety or a confused and frightening search on forums and generic search engines. It is with this empty space
that the app must be compared.
Proposal to FDA. I ask that the main comparison criterion for assessing the effectiveness of AI be the patient’s
real condition in the absence of the tool (unaided patient context / no intervention). The aim is to understand
whether the app concretely improves quality of life and health management compared with being left alone
with one’s doubts.

Question 21 Shared responsibility of the ecosystem and postmarket monitoring
FDA Discussion Paper, Section VI, Question 21
My vision as a patient. We patients are not only “end users”, but the first witnesses of how an app works in
real life.
Example from everyday life. When an app is used every day to monitor symptoms, one notices immediately
whether, after an update, the app starts to use colder terms, misunderstands what is written in the daily diary
or gives repetitive answers. An Expert Patient or an association recognizes these nuances well before a
laboratory analysis.
Proposal to FDA. Safety monitoring after market launch must include shared responsibility. Direct and simple
listening channels must be created so that expert patients and their associations can send civic reports on
changes in behavior or usability problems of the app.

Question 26 Agentic AI systems and patient autonomy
FDA Discussion Paper, Section VII, Question 26
My vision as a patient. I am delighted if AI lightens the burden of administrative chores, but on my health and
my body the last word must always and only be mine.
 Docket No. FDA-2026-N-7874 — AT2S

Example from everyday life. I would be delighted if the app automatically put the medical visit reminder in my
phone calendar, reminded me to order medicines at the pharmacy before they run out, or prepared a draft
summary of my week to show to the doctor. But if the app decided on its own to send a formal request for a
change of therapy to my doctor, or to book a paid specialist visit without my final consent, I would feel
deprived of my freedom to decide.
Proposal to FDA. Establish a clear distinction in the autonomy of agentic systems: maximum automatic
freedom for low-risk organizational and administrative support, but a non-negotiable obligation of step-bystep human confirmation (human-in-the-loop) for any action that directly touches care and health.

3. Conclusion
I strongly support FDA’s choice to define clear and flexible rules for technologies based on generative artificial
intelligence. However, the true safety and effectiveness of these tools is measured by their ability to respect
the dignity, autonomy and emotional experience of the people who use them. Listening to the voice of expert
patients in drafting these rules is the first and most important step to ensure that technology always remains
at the service of human beings.
Signed
G.T. — Expert Patient (EUPATI)
S.G. — Expert Patient (EUPATI); Vice President, Associazione Tendenze Salute e Sanità (AT2S)
The signatories sign in their personal capacity as expert patients and are identified here by their initials; the
affiliation given is for identification only.