Bausch + Lomb (Manisha Narasimhan)

Bausch + Lomb | Comments on Docket No. FDA-2026-N-7874
October 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
Dear Colleagues at the Digital Health Center of Excellence:
Bausch + Lomb appreciates the opportunity to comment on CDRH’s discussion paper on generative AI-enabled medical devices. We support the paper’s risk-based approach and welcome FDA’s effort to give developers and eye care practices a clear, predictable path for bringing these tools to patients.
Founded in 1853, Bausch + Lomb is a global eye health company with a presence in nearly 100 countries. Our portfolio spans eye care products, contact lenses and lens care, ophthalmic pharmaceuticals, and surgical devices and instruments, and our work follows the full path of an eye care patient, from everyday vision correction and eye health to treatment and surgery. That breadth gives us a close view of how eye care practices work and how patients experience care. It is also why we care how new tools, including generative AI, reach patients: they must be safe, easy for practices to adopt, and clear to patients.
One of those tools is Orphia, a generative AI platform for eye care practices. Orphia deploys AI agents that talk with patients by phone at each step of their care, working within a practice’s own protocols and alongside its staff. It is brand agnostic, meaning it is not limited to Bausch + Lomb products, and it is designed with security as the foundation. Pre-operative cataract engagement is the first application, and it is just the start. Our comments reflect what we have learned in developing Orphia.
In brief, we ask FDA to apply the risk framework to each function of a product rather than the product as a whole, and to consider the risk that remains after verified safeguards. We ask FDA to publish an illustrative mapping from risk to premarket evidence, and to avoid making a prospective clinical study the default. We also ask FDA to pair risk-based monitoring with change control plans that cover updates to the underlying model.
Our responses are grouped by the themes of the discussion paper, and each heading lists the discussion questions it addresses. Where a question is not addressed, we have no comment at this time.

DRAFT for Bausch + Lomb review

Bausch + Lomb | Comments on Docket No. FDA-2026-N-7874
October 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

Dear Colleagues at the Digital Health Center of Excellence:

Bausch + Lomb appreciates the opportunity to comment on CDRH’s discussion paper on generative AIenabled medical devices. We support the paper’s risk-based approach and welcome FDA’s effort to give
developers and eye care practices a clear, predictable path for bringing these tools to patients.

Founded in 1853, Bausch + Lomb is a global eye health company with a presence in nearly 100 countries.
Our portfolio spans eye care products, contact lenses and lens care, ophthalmic pharmaceuticals, and
surgical devices and instruments, and our work follows the full path of an eye care patient, from
everyday vision correction and eye health to treatment and surgery. That breadth gives us a close view
of how eye care practices work and how patients experience care. It is also why we care how new tools,
including generative AI, reach patients: they must be safe, easy for practices to adopt, and clear to
patients.

One of those tools is Orphia, a generative AI platform for eye care practices. Orphia deploys AI agents
that talk with patients by phone at each step of their care, working within a practice’s own protocols and
alongside its staff. It is brand agnostic, meaning it is not limited to Bausch + Lomb products, and it is
designed with security as the foundation. Pre-operative cataract engagement is the first application, and
it is just the start. Our comments reflect what we have learned in developing Orphia.

In brief, we ask FDA to apply the risk framework to each function of a product rather than the product as
a whole, and to consider the risk that remains after verified safeguards. We ask FDA to publish an
illustrative mapping from risk to premarket evidence, and to avoid making a prospective clinical study
the default. We also ask FDA to pair risk-based monitoring with change control plans that cover updates
to the underlying model.

Our responses are grouped by the themes of the discussion paper, and each heading lists the discussion
questions it addresses. Where a question is not addressed, we have no comment at this time.

1. Judge risk by function, and by the safeguards that remain (Questions 1–3)
The risk framework (Question 1). We think the two-axis framework is a good foundation, and we would
keep both axes. We would apply them to each function of a product, not to the product as a whole. A
product with several separate functions holds several positions on the grid, so a low-risk education
 DRAFT for Bausch + Lomb review

function isn’t assessed at the level of the riskiest function beside it. Assessing functions separately does
not remove the need to evaluate reasonably foreseeable hazards that arise when functions interact, for
example when an education function hands a patient off to a symptom-routing function.

The framework should also consider residual risk, meaning the risk that remains once deterministic
safeguards are in place. Safeguards should earn credit when they are enforced outside the generative
model and verified in testing. Instructions in a prompt and disclaimers should not earn credit on their
own; safety-critical behavior should be enforced by deterministic, code-based guardrails that operate
independently of the model’s output. FDA should also clarify how sponsors can show that these
safeguards remain effective as model versions and clinical workflows change. Finally, clinical context
should shape the consequence axis.

Directive and non-directive functions (Question 2). We would treat this as a continuum and anchor it
with worked examples, judging directiveness on substance as the paper proposes. The examples should
show both sides of the line. Using a patient’s name, procedure date, or their surgeon’s standard
instructions to deliver general education should remain non-directive, while using a patient’s symptoms
or clinical measurements to recommend an action moves toward the action-directing end of the
continuum, where evidence should be proportionate to the consequence. Risk should also account for
who made the clinical judgment: relaying a clinician’s order or a signed protocol carries the clinician’s
judgment, not the device’s own, so evaluation can focus on whether it was captured and applied
correctly. Without examples, makers of low-risk tools will either over-restrict them or guess.

Information that goes straight to the patient (Question 3). Yes, we think risk does change, because no
clinician reviews the output before the patient acts on it. A few safeguards help: narrow scope, plain
language, conservative escalation, an easy route to a human, and a record the care team can see. Even
so, the framework should still permit patient-facing functions and set evidence by consequence.
Treating patients as unable to handle information would deny them help between visits.

2. Assess realistic conversations and weigh both kinds of escalation error (Questions 5–6)
Assess realistic conversation paths, as the paper proposes. Patients will raise symptoms in any
conversation, such as new pain, sudden vision loss, or flashes and floaters after eye surgery. A nondirective function should decline to assess them and route the patient to a clinician or a cleared
function, and that routing should be enforced outside the generative model, not left to prompt
instructions. FDA should recognize decline-and-route as staying within a non-directive intended use and
give examples of acceptable routing. Sponsors should test these drift paths and keep records showing
the scope controls work. Acceptance levels should be set for each device and agreed with FDA in
advance. Over-escalation also has a cost, since practices will turn off tools that flood them with calls.

For safety-critical patient interactions, evaluation should address the full escalation pathway, to the
extent those steps are performed by the device: recognizing the patient’s statement, applying the
relevant protocol, making the routing decision, delivering the escalation to the care team, and, where
 DRAFT for Bausch + Lomb review

appropriate, confirming the handoff. A correct model response alone does not establish that the clinical
workflow performed as intended.

3. Scale premarket evidence to risk, without making a prospective study the default
(Questions 8, 10–11)
Premarket evidence and the risk grid (Question 8). We believe a function’s position on the grid should
guide how much premarket evidence is needed, judged on residual risk after safeguards are verified. To
make that workable, FDA should publish an illustrative mapping from regions of the grid to the
confirmation options in the paper, with examples. The mapping should recognize benchmarking,
simulation, standardized-patient testing, and shadow or supervised deployment as valid stages of
evidence.

The final level should then be agreed between the sponsor and FDA in pre-submission discussion, before
testing begins. This makes the cost of entry predictable for companies of every size, without fixing a
level for every device.

Benchmarks and real-world behavior (Question 10). We suggest that sponsors use private sequestered
test sets that are refreshed and, where possible, built from real patient interactions, since public
benchmarks leak into training data and saturate. Sponsors should also explain why their benchmark is
expected to reflect real use, with supporting data where they have it. FDA should encourage sponsors to
prespecify acceptance criteria, document why benchmark cases are clinically relevant, and maintain
traceability from identified hazards to the competencies evaluated and the evidence supporting each
performance claim.

Confirmation without a prospective study (Question 11). We do not think a prospective clinical study
should be the default. A lighter path fits when a clinician reviews outputs before action, when
consequences are limited, or when a function extends an already cleared function of similar risk.

In those cases, confirmation can come from standardized-patient testing, where clinicians and
representative lay actors play patients with known ground truth, together with shadow or supervised
deployment, in which outputs are recorded and reviewed but not used in care. This gathers real
evidence without changing care, and lets sponsors test rare, dangerous situations without exposing
patients. We would reserve prospective studies for outcome claims and for first-of-kind, autonomous, or
irreversible high-consequence functions, decided case by case.

4. Keep synthetic and real evidence separate, and choose realistic comparators (Questions
12–14)
Synthetic and real data (Questions 12 and 13). When synthetic and real evidence are mixed, we
recommend reporting them separately and being clear about what each can support. Pooling them
hides how the device performs on real patients, unless a paired comparison on the same scenarios
shows the two are exchangeable. Synthetic data is good enough for covering rare presentations, stress
testing, probing scope boundaries, and interaction-mode variation (for example, audio or display
 DRAFT for Bausch + Lomb review

differences). It is not enough for routine performance claims, outcome claims, subgroup claims, or
patient comprehension, which need real data or representative users.

Rare, safety-critical events need particular care. Because they occur so infrequently, real-patient data
alone is unlikely to contain enough of them to show that a device catches them. Evidence should come
from enriched sets: real complication cases gathered with clinical partners, plus synthetic cases and
standardized-patient testing, each reported separately with confidence bounds on sensitivity. Synthetic
cases can support these claims when they are anchored to real cases and checked by clinicians.

In addition, to avoid reproducing the evaluation’s own blind spots, synthetic cases used for subgroup or
safety testing should be generated or reviewed independently of the model class under evaluation, not
by that same model.

When real-world data are used to support performance or safety conclusions, sponsors should show
that the data are relevant and reliable for that purpose, consistent with FDA’s existing real-world
evidence guidance for devices, with attention to provenance, completeness, timeliness,
representativeness, measurement reliability, and traceability to the encounter and the deployed
software and model version.

Choosing a comparator (Question 14). We would use two references. Correctness should be graded by
a panel of relevant specialists, with their disagreement measured. For safety-critical behavior, such as
recognizing red-flag symptoms and escalating, the acceptance bar should be what the clinical protocol
and guidelines require, not how often staff currently miss them.

For other quality measures, the bar should reflect who performs the equivalent task in current practice.
In post-surgical eye care that is usually staff following protocol, not surgeons, so a generic physician
standard would be the wrong comparison.

5. Monitor after launch in proportion to risk (Questions 18–21)
Trading premarket evidence for monitoring (Question 18). Yes, within limits and in proportion to risk.
Where errors are mild and recoverable, strong premarket evidence (benchmarks, simulation, and
standardized-patient testing) together with safeguards and a supervised early launch can justify
accepting more uncertainty. In a supervised launch, clinicians review early encounters until error rates
are shown to be below preset limits. Where harm could be severe and irreversible, however, the
balance should lean toward premarket evidence.

Monitoring after launch (Question 19). We think monitoring should be risk-based and proposed by the
sponsor in a plan that FDA reviews. We would build it in two phases. The first is an intensive early period
after each release, with clinician review of every encounter or a high share of them, until error rates are
shown to be below preset limits. The second is steady-state surveillance made up of automated signals
on every interaction, benchmark reruns after model changes, and sampled clinician review that includes
encounters with the automated layers cleared.
 DRAFT for Bausch + Lomb review

Sample sizes should follow how rare the failures being sought are, and every confirmed failure should be
added to the test set. Cadence should follow risk, volume, and how often the underlying model changes.
Anticipated changes to the underlying model should be managed through a predetermined change
control plan (PCCP), with a modification protocol that sets the testing and acceptance criteria for each
change, so that a new clinical study is not the default for every model update.

Postmarket datasets used for regulatory conclusions should be assessed for fitness for that specific use
against prespecified data-quality criteria. A dataset that fails a critical criterion should not be treated as
adequate because it performs well on others, and the assessment should be repeated when data
collection methods, patient populations, or software or model versions change materially.

AI supervisory agents (Question 20). Yes, we see them as one useful layer of monitoring. Supervisory
models can check every interaction, which no human team can. They should be validated against
clinician review, and we think the paper’s independence expectations for model-based adjudicators are
reasonable.

Roles for clinicians and institutions (Question 21). The manufacturer should stay accountable for
performance, monitoring, and fixes. Clinicians and practices should report problems, act on escalations,
and use the device as labeled, but they should not be asked to validate it. Reporting must be simple
enough for a small practice.

6. Manage change through a defined envelope (Questions 22–24)
Changes after deployment (Question 22). We suggest a tiered approach. Any change to the model,
prompts, safety layer, or clinical content that touches a device function should trigger a rerun of the
safety competencies, and a new model version should trigger the full benchmark. Clinical confirmation
should be repeated only when results move outside preset margins or the intended use changes.
Changes confined to non-device functions should stay inside the quality management system (QMS).

Change control plans (Question 23). We would define the plan by its envelope, not by a list of changes.
The envelope is the performance bounds, the test protocol, the acceptance criteria, and the rollback
procedure. A change that stays inside it proceeds; one that does not is evaluated under FDA’s existing
device modification policies to determine whether a new marketing submission is needed. Third-party
model updates should be an explicit class of change within the plan.

Sponsors should maintain configuration traceability linking model versions, validation results, residual
risks, release decisions, and rollback actions to existing QMS controls.

Updates to a foundation model (Question 24). The device maker remains accountable for its device. To
carry that responsibility, it needs certain information from the model developer. The framework could
describe the following as good practice, without mandating contract terms:

• A pinned, identifiable model version.
• Advance notice of changes, with a description of what changed.
 DRAFT for Bausch + Lomb review

• Access to test a new version before it reaches patients.
• The option to stay on the prior version for a defined period, and to roll back.
Device makers can also run routine check tests to detect an unannounced change, and guidance on
what counts as adequate detection would help.

7. Foundation model files and agentic systems (Questions 25–26)
Foundation model master files (Question 25). Yes, we think they could be practical and useful if the file
holds what a device maker cannot produce alone: version identifiers, known healthcare failure modes,
subgroup results, and update-notification commitments. Referencing it should also spare the device
maker from re-proving the base layer in each submission, though the device maker must still show its
own device is safe.

A sponsor without a master file should not be disadvantaged and can supply the same evidence itself. A
predictable review benefit would give developers a reason to file.

Agents that plan and act (Question 26). We think oversight should scale with what the agent can do
without a person. Reading information, writing a record, and taking an irreversible or clinical action are
different levels of risk, and the highest level should require a human checkpoint. Every agent should
have the narrowest tool access its task needs, a log of its actions, and tested handling of tool errors.
Booking an appointment, for example, should not be regulated like changing a medication.

For actions that write to a record or take a clinical or irreversible step, sponsors should retain auditable
records of initiating requests, permissions, relevant model and tool versions, actions taken, failures, and
any human review or override. The level of logging and review should be proportionate to clinical
consequence and privacy risk. Logs that contain patient information should be retained and protected
consistent with applicable privacy requirements.

Closing
Bausch + Lomb thanks CDRH and the Digital Health Center of Excellence for their work on this discussion
paper and for the opportunity to comment. We would welcome the opportunity to discuss these
comments and to contribute to future work in this area.

Respectfully submitted,

Manisha Narasimhan
President, Digital Health Services
Bausch + Lomb