cliexa (Katherine Mulready)

See attached file(s)

October 13, 2026

Dockets Management Staff (HFA - 305)
Food and Drug Administration
5630 Fishers Lane, Rm. 1061
Rockville, MD 20852

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

To the Digital Health Center of Excellence:
cliexa appreciates the opportunity to comment on CDRH’s discussion paper. cliexa is a Denver - based
developer of clinical reasoning software for healthcare organizations. Working with generative AI every day,
we see both sides of the questions CDRH raises: what generative AI makes possible, and how that capability
must be bounded before anyone relies on it.
Our comments are meant to help CDRH turn its two - axis framework into criteria that developers can design
to and reviewers can apply consistently. They address policy questions only and are not a characterization of
the regulatory status of any particular p roduct.

Summary of recommendations
1. Assess risk by how well a function is bounded, not by how open - ended it is (Q1, Q7, Q8). Grounding
in source records, deterministic constraints on outputs and explicit scope limits should count as risk
moderators, and should be demonstrated through benchmarking, not just asserted.
2. Treat directiveness as a continuum and define its modifiers (Q2, Q3, Q5): specificity, personalization,
recipient, reversibility, traceability and downstream safeguards. Evaluate each rung by what happens
when the output is wrong.
3. Recognize verifiable traceability as a distinct risk moderator (Q1), with defined properties and
measured performance.
4. Give credit for deterministic constraint layers in hybrid architectures, and separate rules - library
updates from model changes in change control and PCCPs (Q22, Q23).
5. Support voluntary Foundation Model MAFs , paired with version pinning, triggered re - benchmarking
and vendor update - notification commitments (Q24, Q25).
6. Measure under - and over - escalation separately , with deferral to a human treated as its own outcome
(Q5, Q6, Q15).
7. Use existing independent evaluation programs as supporting evidence, without a new mandatory
certification layer that would price out smaller developers (Q16).
8. Confirm that agentic execution does not change whether a function is a device function (Section
VII.B, Q26). Administrative, documentation, care coordination and qualifying clinical decision support
functions that are outside device oversight today should stay outside when an agent performs them.
9. Build a postmarket system designed for generative AI (Q18 to Q21). Pair greater reliance on
postmarket evidence with monitoring stratified by deployment setting, clinician edits as a
performance signal, periodic sponsor reports, and supervisory checks that are independent and
validated against human review.

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 1
1. Risk should follow how well a function is bounded (Q1, Q7, Q8)
FDA’s software framework was built for closed - ended software. Such software is like a train on fixed tracks:
every route can be inspected before departure. Generative AI is closer to an off - road vehicle, and the paper
rightly notes that evaluation methods “developed for software with bounded inputs and fixed outputs may
not be appropriate.” But the safety question for an off - road vehicle is not whether it can leave the pavement.
It is whether it carries a map, knows whe re the edges are, and stops when it reaches one. Off - road with a
map and guardrails is a different risk profile from off - road without them.
We recommend that CDRH treat boundedness as an explicit consideration in the two - axis framework,
assessed through three mechanisms:
• Grounding. Outputs are generated from, and linked to, identified source material: the patient record, a
specified guideline or protocol, or a defined knowledge base. They do not rely only on the model’s
parametric knowledge.
• Deterministic constraints. Rules that operate independently of the generative model check or limit its
outputs, for example dose ranges, required escalation triggers, contraindication checks or mandatory
fields. They block or route outputs that fall outside defined limits.
• Explicit scope limits. The function recognizes inputs outside its intended use and defers or refuses
rather than improvising. This maps directly to benchmarking element S.2 (scope maintenance and
boundary adherence).
Boundedness should move a function down the consequences axis only to the extent it is demonstrated:
through S.2 testing, adversarial out - of - scope inputs, and measured rates of unsupported output. Treated
this way, boundedness gives sponsors a design targe t and gives reviewers a testable claim. It also answers
Q8. The more a sponsor can demonstrate that a function is bounded, the more weight structured
benchmarking can carry, and the less the clinical - confirmation burden needs to scale with the theoretical
breadth of the model’s output.

2. Directiveness is a continuum, and consequences scale it (Q2, Q3, Q5)
We agree that directiveness turns on substance and context rather than particular words, and that a “talk to
your doctor” disclaimer should not by itself lower risk. The most useful question at each point on the
continuum is: what happens when the output is wrong, and what stands between the error and the
patient? Applied to the paper’s lisinopril example:

Rung Example output If the output is wrong What moderates the risk

General “Lisinopril dosages are Harm requires a further Grounding to a cited
information sometimes increased when independent decision by a guideline. Low specificity.
blood pressure remains clinician or patient. The error is
above the treatment goal.” generic and easy to check
against standard references.

Contextualized “In situations similar to this, A wrong match to the patient’s Showing which patient facts
clinicians often increase the situation lends false relevance. were matched, and their
lisinopril dosage.” The user may not see which facts source in the record.
drove the match.

Endorsement “I recommend increasing Anchoring: an accepted error HCP recipient; rationale and
the lisinopril dosage.” becomes the plan. Detection source facts shown;
depends on reviewer time and reversible action; rule - based
attention. contraindication check.

Specific “Increase the lisinopril from The error can be executed as - is, Required HCP sign - off;
instruction 10 mg to 20 mg daily.” especially if the output is deterministic dose - range

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 2
 Rung Example output If the output is wrong What moderates the risk

patient - facing. Little friction constraint; traceability;
before harm. patient - facing use treated as
higher consequence.

We suggest CDRH define a small set of risk modifiers that move a function within its band on the
framework, rather than reclassifying it outright. A bounded list makes outcomes predictable for
manufacturers:
• Specificity: whether the output is general, conditional, or names a specific action, dose or time.
• Personalization: how far the output relies on individual patient data, and whether that data is shown.
• Recipient: patient, generalist HCP or specialist HCP. For patients, the question in Q3 is whether the
user can recognize an error, not whether they are capable. Patient - facing functions can mitigate risk
with plain - language rationale, explicit uncertainty and a guar anteed path to a human.
• Reversibility and time to detection: whether a wrong action can be caught and undone before harm
(a dose titration reviewed at the next visit, for example) or cannot (a missed emergency).
• Traceability to source (Section 3 below).
• Downstream safeguards: independent checks between the output and the action, such as pharmacist
verification or order - entry rules.
For multi - turn devices (Q5), we recommend that sponsors document a directiveness ceiling : the highest
rung a function can reach across realistic conversational trajectories, established by adversarial and long -
conversation testing. The intended use should be characterized by that ceiling, not by typical behavior.
Where the ceiling exceeds the intended use, scope limits (Section 1) should be shown to hold.

3. Traceability as a risk moderator (Q1)
Of the additional dimensions CDRH lists in Q1, traceability deserves the most weight, because it directly
supports the condition the framework depends on: a user’s ability to identify an incorrect output before
relying on it. CDRH’s footnote linking measur ement functions to the independent - review criterion of section
520(o)(1)(E) makes the same point from the other direction. When users cannot see the basis for an output,
risk rises. When they can, and can check it, risk falls.
Not all claims of traceability are equal. A citation that looks valid but does not support the statement is itself
a form of confabulation. We recommend that traceability earn credit only when it has three properties:
1. Grounded at the claim level. Each clinically material assertion is linked to a specific source element (a
record entry, a guideline passage or a rule), not just to a document.
2. Verifiable in the workflow. The user can inspect the source within the time realistically available in the
deployment setting, which ties to the time - pressure dimension in Q1.
3. Measured. Benchmarking reports citation accuracy (does the source support the claim?) and the rate
of unsupported assertions, under E.1 and S.2, and postmarket monitoring tracks both.
Traceability moderates risk most for HCP - facing functions, where the user can evaluate the source. For
patient - facing functions it is still valuable but less protective by itself, and should be paired with the
safeguards noted under Q3. We would welcome CD RH naming traceability, defined this way, as a
recognized risk moderator. Doing so would also give developers a strong incentive to build systems that
show their work.

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 3
4. Hybrid deterministic and generative architectures (Q22, Q23)
Many clinical AI systems are not purely generative. They combine a generative model with deterministic
components: clinical rules libraries, guideline - derived thresholds, validated scoring instruments, and checks
on output structure and content. Where a de terministic layer constrains generative output, it is a risk control
in the ordinary sense, and we ask that CDRH say so. A sponsor that shows its constraint layer catches out -
of - bounds outputs, through testing that deliberately induces such outputs, should be able to rely on that
layer in its risk analysis and benchmarking scope.
This has a direct consequence for change control. Updating a rules library is not the same kind of change as
updating a model. Rules are explicit, inspectable and testable against a fixed regression suite. Their effects
can be fully characterized before release, which is not true of a change in model weights. We propose three
change tiers:

Change type Examples Proposed oversight

Rules - library content Incorporating a revised guideline threshold Sponsor QMS: documented source,
update within existing from a recognized source; adding a drug regression testing against the frozen
scope to an existing interaction check benchmark, release record. No new
submission.

Rules - logic change that New escalation pathway; new clinical PCCP, with prespecified modification
alters what the function domain; changed decision criteria protocol and re - benchmarking of
does affected elements.

Generative or foundation - New model version; fine - tuning; Triggered re - benchmarking against the
model change significant prompt or retrieval change premarket baseline (Section 5); PCCP or
submission according to impact.

On Q23, where modifications cannot be fully prespecified: we suggest PCCPs that define a performance
envelope and a change class rather than enumerating specific changes. The sponsor commits to a frozen
benchmark suite, acceptance criteria per element, and a rule that any change, of whatever origin, must clear
the suite before deployment. This keeps the premarket baseline meaningfu l without requiring sponsors to
predict the future.

5. Third -party foundation models (Q24, Q25)
We support voluntary Foundation Model MAFs . Downstream developers are already asked to account for
model behaviors they cannot fully inspect. A confidential, reviewer - accessible file would make reviews more
consistent and reduce the duplicate diligence every sponsor now performs separately. To mak e the program
useful (Q25), we suggest CDRH prioritize content that maps to device risk: characterized failure modes in
clinical contexts, safety - relevant refusal and content - policy behavior, subgroup performance on health
benchmarks, version and deprecati on policy, and update - notification commitments. A light incentive would
help. For example, a sponsor referencing a current MAF could rely on it for defined portions of its
foundation - model documentation.
For Q24, practical mechanisms already exist, and FDA can encourage them without new infrastructure:
• Version pinning. Major foundation model providers already offer dated or fixed model snapshots and
publish advance deprecation schedules (e.g., Anthropic, OpenAI and Google). Sponsors should deploy
pinned versions and document the version in use. An unannounced change to a pinned version would
then be a vendor failure, not an expected event.

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 4
 • Triggered re - benchmarking. Any change of underlying model version, whether sponsor - initiated or
forced by deprecation, triggers re - execution of the sponsor’s frozen benchmark suite before the new
version serves users, with documented acceptance against the premarket baseline.
• Behavioral canaries. A small, fixed set of sentinel prompts runs on a schedule to detect silent
behavioral drift, even where the version identifier has not changed.
• Contractual commitments. Vendor agreements should include advance notice of model changes and
deprecations, retention of prior versions for a defined transition window, and audit - log availability. A
Foundation Model MAF could record standard commitments of this kind, so each spon sor does not
have to negotiate them separately.
• Rollback. Sponsors maintain the ability to revert to the last validated configuration, or to a
deterministic fallback, if a change fails acceptance.

6. Over - and under -escalation (Q5, Q6, Q15)
We agree that both directions of error matter and that they are not commensurable. Whether a given
escalation function is a device function should continue to turn on its intended use and existing criteria,
including section 520(o)(1)(E) for HCP - facing sup port. The principles below concern how escalation
performance should be evaluated, wherever that line falls:
• Report the two errors separately; never combine them into one accuracy figure. A single accuracy
number can hide a dangerous under - escalation rate behind good performance on easy cases.
• Set asymmetric thresholds prospectively, by clinical context. For presentations where delay is
catastrophic (chest pain, suicidality, signs of sepsis), the acceptable under - escalation rate should be
near zero, with over - escalation accepted as the cost. For low - acuity presentations, persistent over -
escalation should count as a real harm: avoidable emergency department use, cost, and loss of user
trust that suppresses future care - seeking.
• Treat “defer to a human” as a third outcome, counted separately. Routing uncertain cases to a
clinician is a safety feature and should not be scored as an error in either direction. Its rate should still
be measured and bounded, because a function that defers everything provides no benefit.
• Evaluate across conversations, not single turns. Escalation - relevant information often surfaces late in
an exchange. Benchmarks should include trajectories in which red - flag symptoms emerge after an
initial benign presentation.
• Compare against the existing pathway (Q14, Q15). The realistic comparator for many escalation
functions is current practice, such as existing clinician triage pathways, or no guidance at all where
access is limited. Non - inferiority to the care the patient would otherwise receive, measured as
concordance with a clinician panel, is a workable standard and is already used in Utah’s regulatory
sandbox .

7. Independent third parties and least -burdensome evaluation (Q10, Q16)
Independent evaluation adds real value, especially sequestered test data and adjudication independent of
both sponsor and foundation - model developer. CDRH does not need to build a new layer to obtain it.
Existing mechanisms can carry much of the load: ASCA and MDDT, recognized consensus standards, and the
qualification and assurance programs already run by health systems, AI - platform operators and multi -
stakeholder consortia (e.g., the Coalition for Health AI’s model card registry and the Joint Commission –C HAI
guidance on responsible AI use).

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 5
We recommend that CDRH:
• Accept results from qualified existing programs as supporting evidence within a submission, where
their methods, independence and data provenance are documented. They should not be treated as a
substitute for FDA review.
• Not create a new mandatory certification gate. Mandatory third - party certification with high fixed
costs would fall hardest on smaller developers and academic teams, concentrating the market among
firms that can absorb the expense. That runs against the least - burdensome principle and the
competition c oncern CDRH raises in Q16.
• Set safeguards if third parties are used: published fee schedules, access to sequestered datasets on
non - discriminatory terms, conflict - of - interest rules that bar evaluators from assessing products that
compete with their own, and turnaround commitments.
• Address benchmark contamination and synthetic - data limits (Q10, Q13) by favoring sequestered or
rotating test sets held by independent parties. Sponsor - developed benchmarks should be prespecified
and locked before final tuning. Synthetic data is valuable for edge cases and underrepresented
settings, but should not be the s ole evidence of subgroup performance: generative systems can
behave differently on inputs they recognize as tests, and synthetic data can reproduce the gaps it is
meant to detect.

8. Agentic AI and the existing statutory lines (Section VII.B, Q26)
The paper notes that agentic systems are increasingly used for care coordination, clinical documentation,
patient outreach and workflow support, and that some or all of these may not be functions that are the
focus of device oversight. We ask CDRH to confi rm a simple principle: agentic execution does not change
whether a function is a device function. A function excluded from the device definition under section
520(o)(1), or covered by an existing enforcement - discretion policy, stays excluded or covered when an
agent performs it. It does not become a device function because the agent plans multiple ste ps, uses tools,
handles clinical data or produces clinical text. Specifically, we ask CDRH to state that the following remain
outside device oversight when performed by agentic systems:
• Administrative support , which Congress excluded in section 520(o)(1)(A): processing of claims and
billing information, analysis of historical claims data, benefit eligibility determination, appointment
scheduling, admissions, population health management and practice operations . This includes coding
support, claim preparation, prior - authorization assembly and denial management.
• Documentation: drafting, structuring and summarizing clinical documentation for clinician review and
signature, and checking whether documentation is complete and supports the services billed, where
the clinician, not the function, makes the diagnostic and treatment decisions being documented .
• Care coordination and outreach: scheduling, referral routing, reminders, information exchange at
transitions of care, and assembling records for a receiving team.
• Clinical decision support that meets section 520(o)(1)(E) , including its requirement that the HCP can
independently review the basis for a recommendation. Agentic orchestration should not by itself
defeat that exclusion.
Where the line falls should continue to be set by intended use under the existing statute and guidance,
including the Multiple Function Device Products and Clinical Decision Support Software guidances, not by a
new test specific to agentic systems. The pap er’s own example, an agent whose action sequence results in
control of another medical device, is a clear case for device oversight.
Placing these functions outside device oversight does not leave them unregulated. They remain subject to
ONC transparency requirements for certified health IT, payer and utilization - review rules, state AI - disclosure

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 6
laws (e.g., California’s requirement of disclosure and a route to a human in AI - generated patient
communications), and federal privacy and consumer - protection law.
For agentic functions that do fall within device scope (Q26), the added risk comes from chained actions and
fewer human checkpoints. We recommend evaluating: complete and reviewable action logs; reversibility of
each action; mandatory human checkpoints bef ore any irreversible clinical action; tool permissions limited to
the intended use; and benchmarking of multi - step task completion that includes recovery from tool errors.

9. A postmarket system built for generative AI (Q18 to Q21)
If CDRH accepts more premarket uncertainty, the postmarket system has to be new, not an extension of
complaint - driven reporting. We suggest it be designed around four elements:
• Scope of reliance (Q18). Greater reliance on postmarket evidence is reasonable for bounded,
traceable, HCP - facing functions with active monitoring. It is not appropriate for autonomous, high -
consequence functions or where users cannot detect errors.
• Representativeness across deployment settings. Tools should not be restricted to the populations
they were developed on, but sponsors should be expected to stratify monitoring by deployment
setting, including rural and under - resourced sites, so that underperformance in a new population is
detected rat her than averaged away.
• Signals and channels (Q19, Q21). For generative documentation, clinician edits to generated output
are a continuous, low - burden performance signal. Existing protected channels can carry safety signals
without a new voluntary network (e.g., AHRQ Patient Safety Organizations), and accreditation surveys
could potentially observe local AI governance. Spons or performance reports on a fixed cadence,
modeled on PMA periodic reporting and scaled to risk, would keep accountability with the
manufacturer.
• Supervisory agents (Q20) can extend coverage, but should be independent of the model they
supervise, periodically validated against human adjudication, and never the only check on high -
consequence outputs.

Conclusion
Our core recommendation is that CDRH focus on what most determines whether a generative system is safe
to rely on: whether it is bounded, whether its outputs can be traced and checked, and what happens when it
is wrong. Those properties can be designed, tested and monitored. We would welcome the opportunity to
discuss these comments with CDRH staff.
Respectfully submitted,

Katherine Mulready
Chief Strategy Officer

c liexa , Inc.
200 Quebec St, Bldg 600, Unit 205
Denver, CO 80230

kmulready@cliexa.com
(720) 282 - 9285

cliexa Inc. · Comment on Docket No. FDA-2026-N-7874 | Page 7