Oracle Health & Life Sciences (Alex Mugge)

See attached file(s)

8779 Hilcrest Road
Kansas City, MO 64138
Direct: (816) 201-1024

October 19, 2026

Michelle E. Tarver, M.D., Ph.D.
Director, Center for Devices and Radiological Health

Rick Abramson, M.D.
Associate Director for Digital Health
Director, Digital Health Center of Excellence
Center for Devices and Radiological Health

U.S. Food and Drug Administration
10903 New Hampshire Avenue
Silver Spring, MD 20993

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

Dear Dr. Tarver and Dr. Abramson:

Oracle Health & Life Sciences ("Oracle Health" or “OHLS”) appreciates the opportunity to
respond to the discussion paper titled "Considerations for the Regulation of GenAI -Enabled
Medical Devices: Discussion Paper and Request for Feedback" (the "Discussion Paper"), issued
in August 2026 by the Digital Health Center of Excellence within FDA's Center for Devices and
Radiological Health ("CDRH"). Oracle Health commends CDRH for its thoughtful efforts in this
area and for seeking stakeholder input before proposing guidance.

Because generative artificial intelligence (“GenAI”), including agentic AI, has unique
characteristics, it is important that the regulatory framework account for them while ensuring that
FDA stays focused is on GenAI-enabled functions that meet the definition of a medical device.
Early and open dialogue between the agency and the companies building these tools is the best
way to reach a framework that protects patients, supports innovation, and reflects how these
technologies are actually built and used. Oracle Health appreciates CDRH's collaborative
approach and would welcome the opportunity to meet with the Digital Health Center of
Excellence to discuss these comments.

The way we refer to this technology is evolving as quickly as the technology itself. Therefore,
throughout this comment letter, we refer to the technology as GenAI for consistency with the
Discussion Paper and questions presented though we acknowledge that it is also referred to as
Super Intelligence (“SI”) in other contexts.

Our detailed responses appear on the next set of pages. They follow the organization of the
Discussion Paper and its consolidated discussion questions. As the Discussion Paper invites, we
focus on the questions most relevant to Oracle Health's experience. Please direct any questions to
 Page 2 of 21

Alex Mugge, Senior Director, Global Health Policy & Regulatory Intelligence, at
alex.mugge@oracle.com.

Sincerely,

Alex Mugge
Sr. Director, Global Health Policy & Regulatory Intelligence
Oracle Health
 Page 3 of 21

Oracle Health Responses to Discussion Questions
Docket No. FDA-2026-N-7874

I. Introduction

Oracle Health's Role in Health Care

Oracle Health brings a unique and multifaceted perspective to the Discussion Paper. As a health
IT developer, Oracle Health's electronic health record ("EHR") and related solutions are used by
over 2,000 hospitals, health systems, and clinics in the United States and 25 other countries.
Oracle Health is also building GenAI directly into clinical, operational, and administrative
workflows in healthcare. For example, the Oracle Health Clinical AI Agents support
functionality ranging from drafting structured clinical notes from patient-clinician conversations
for clinician review and approval to generating suggested billing codes and modifiers for
provider review and approval.

In 2026, Oracle Health extended the agents to draft clinical orders, support clinician-controlled
dictation, and summarize relevant information from across the patient record. In each case, a
clinician reviews the output before it becomes part of the record or takes effect. Since launch,
Clinical AI Agent note generation alone has saved U.S. physicians more than 400,000 hours.
Our new Oracle Health EHR is an all-in-one voice-first intelligent solution that embeds AI
directly into workflows. This built-in AI approach delivers faster performance, improved data
integrity, and a more seamless user experience than a traditional approach of bolting AI onto
legacy technologies and infrastructure. Oracle Health also has extensive experience in life
sciences in delivering software and cloud services to meet the needs of companies engaged in
clinical studies and vigilance activities. Oracle Health has incorporated GenAI into our cloud -
based pharmacovigilance platform, to facilitate safety case narrative accuracy, coherence, and
contextual relevance.

Oracle Health's Commitment to Responsible AI
Oracle Health has established our own rigorous AI review process under which every AI feature
developed for our customers is assessed. Our formal governance framework, Oracle AI Review
for Health (“OARH”), drives review of all features before release. The framework rests on six
principles: (i) human-centered design, (ii) transparency and explainability, (iii) performance and
reliability, (iv) privacy and security, (v) fairness and integrity, and (vi) accountability. Each
OARH review looks at the feature's purpose and intended users, data provenance, evaluation
strategy, safety risks, reliability evidence, human oversight design, monitoring plans, and
feedback mechanisms. Each feature is reviewed to ensure that a human is the ultimate decision
maker and that information is presented only from the patient record or other clinically
appropriate sources. The framework is built into Oracle Health's software development lifecycle
and quality management system and has achieved ISO/IEC 42001 AI Management System
certification.
 Page 4 of 21

These commitments are also reflected in Oracle Health's products and development practices.
Oracle Health's clinical AI tools are designed to support, rather than replace, clinician judgment
by presenting outputs as drafts for clinician review and keeping the clinician in control of care
delivery. For example, users can trace elements of an AI-generated summary back to the
underlying clinical documentation, test results, or other clinically appropriate source materials.
Oracle Health also makes model cards openly available within product documentation, providing
information about intended and non-intended uses, training and evaluation datasets, and relevant
performance metrics. Following deployment, Oracle Health monitors AI-enabled features against
predefined performance measures and escalation thresholds designed to identify when review,
mitigation, or corrective action may be warranted.

Much of the framework described in the Discussion Paper reflects practices Oracle Health
already employs in the development and governance of AI-enabled technologies. Oracle Health’s
comments are informed by practical experience implementing these measures across healthcare
AI products and services. Many providers in the country today are struggling to know what
governance practices they should adopt internally or should require from the technology they
use. We strongly encourage FDA and HHS to educate the public on AI governance best practices
and use their existing regulatory authorities to set minimum standards where appropriate to the
products each agency regulates.

Framing FDA’s GenAI Regulatory Strategy
While we believe FDA (combined with HHS) could serve an important educational role in the
health industry writ large, we also strongly believe that any regulatory requirements imposed by
FDA need to clearly apply only to products within the agency’s regulatory authority. Given the
fact that GenAI functionality can span many different purposes and contexts in healthcare –
including both device and non-device functions – and the general lack of clarity around AI
regulation in the industry today, it is critical that any guidance or related publications from FDA
be clear about the scope of applicability.

The Discussion Paper states that “FDA does not regulate GenAI as such. It regulates medical
devices, including GenAI-enabled devices.” Oracle Health agrees and emphasizes the criticality
of this point. Any framework or policy (including the FY 27 Under Construction guidance
“Risk Assessment and Evidentiary Considerations for Generative Artificial IntelligenceEnabled Devices) that results from this process must very clearly specify that it applies
exclusively to GenAI-enabled device software functions. Accordingly, FDA should confirm in
any subsequent publications that software functions excluded from the device definition under
section 520(o) of the FD&C Act, including clinical decision support software that meets the
criteria in section 520(o)(1)(E), remain outside the framework, regardless of whether such
functions use GenAI. The same should be true of functions subject to existing enforcement
discretion policies. Consistent with FDA’s Multiple Function Device Products guidance, a
GenAI-enabled device function within a product should not bring the product’s other functions
under device oversight.
 Page 5 of 21

Moreover, for EHR manufacturers in particular, there continues to be a significant amount of
uncertainty regarding what FDA considers to be exempt administrative or clinical decision
support functions under 21st Century Cures vs. what software functions are regulated as a device.
And in the meantime, certified EHR developers continue to be subject to multiple overlapping
regulatory and certification regimes, while we see many competitor technology companies
offering products to the health industry with no certification requirements, no quality
management system, no AI governance programs, etc. This disparity in regulatory burdens and
uncertainty regarding regulatory requirements places EHRs at a competitive disadvantage. It is
ultimately harmful to providers, who are unclear of what regulatory standards have been
followed by all the various healthcare AI products on the market, and also harmful to patients
with even less ability to distinguish products.

It is critical that as FDA works to resolve this uncertainty, the agency should take care to learn
about EHRs and understand that EHRs are the foundation of how medicine is practiced in the
United States today, and that FDA not disrupt the tools that clinicians have relied on for many
decades to do their work. It is also essential that as EHR vendors begin to use Gen AI to make
the clinician experience more user friendly, that FDA does not impose unnecessary regulatory
burdens on tools that are reducing administrative burdens and allowing doctors and nurses to
finally practice medicine at the top of their licenses.

II. Considerations for the Assessment of Risk (Discussion Paper Section IV)

Question 1
Does the two-axis risk framework, organized around device activity and the consequence of relying on
an incorrect output, appropriately capture the dimensions most relevant to the risk of a GenAI-enabled
software function? If there are additional dimensions—such as the reversibility of a resulting action,
the availability of downstream safeguards, the time pressure of the deployment setting, or the
traceability of the output (i.e., to primary source materials)—that should be represented in a risk
framework, please describe and provide examples of how they should be represented.

Oracle Health Response
While the two-axis framework is a helpful construct to understand risk, and in general Oracle
Health supports a risk-based approach to regulation of SaMD, it is unclear to us how this
construct would apply within the existing framework of regulation and guidance. Is it the
intention of FDA that for GenAI functions this two-axis framework might replace existing
policies, such as the 2026 Clinical Decision Support Software guidance, and offer new categories
of enforcement discretion for low-risk software functions? If that is the case, Oracle Health
would potentially support that, but we would need to better understand the proposed categories
and what their regulatory status would be. In general, we believe the risk-based framework
proposed for clinical decision support in 2018 is more aligned to the statute and strikes a better
balance between safety and innovation than the approach adopted in the 2022 draft and 2026
final guidance. We would support a new regulatory framework that is more aligned to the statute
and exempts more low risk software functions from regulation.
 Page 6 of 21

However, if it is FDA’s intention for this two-axis construct to coexist alongside existing policy,
it is unclear to us how to understand the two-axis framework in the context of the 21st Century
Cures Act clinical decision support exemptions and the 2026 Clinical Decision Support Software
guidance. For example, for any clinical decision support software falling into the “Informational
– Non-Directive” category, it is our understanding that under current law and policy, those
software functions would be exempt from device regulation or fall under enforcement discretion.
This discussion paper was framed as only applying to software that qualifies as a device, so that
has created confusion for us as to what “Informational – Non-Directive” software might qualify
as a device.

FDA gives an example in the discussion paper of a risk score for a future cardiovascular event
and says that is “meaningfully different” from a software function that “while nominally
informational, directs an action (for example a strongly worded patient-facing recommendation
about whether to seek emergency care.)” While we agree that the wording used in patient-facing
software functions might make a meaningful difference in the risk and regulatory status of the
software functions, we ask FDA to clarify whether this would also apply to clinical decision
support. For clinical decision support, in our experience working with clinicians for over 30
years, we believe clinicians are highly capable professionals with many years of training and
education, and they are adept at evaluating the source and basis of clinical decision support
outputs before acting, regardless of how “strongly worded” the recommendation is. FDA has not
presented any evidence in this paper to demonstrate otherwise. Ultimately, if FDA decides to
adopt a concept like this in the clinical setting, we ask FDA to be sure to clearly delineate what
wording falls into what category of risk, so industry is not left guessing.1

We also request further clarification of the boundaries between “Informational: Action
Directing” and “Action-Taking: HCP Supervised.” It is unclear to us how a software can be both
“informational” and “action directing.” If the software is merely providing information to a
clinician, we do not believe it can also be “directing action.” Likewise, it is unclear how a
software can be “action taking” but “HCP supervised.” If a clinician is ultimately deciding
whether to take an action, the software is not action-taking and the clinician remains in control. If
FDA means something different by “supervising,” that would be helpful to clarify.

Oracle Health disagrees with FDA that the language used in clinical decision support has a
material impact on how it is understood or used by a clinician that should impact the regulatory
burden on the software. FDA gives several examples in the discussion paper of different
potential phrasings of clinical decision support – e.g., “clinicians often…,” “I recommend…,” or
“increase….” As noted above, in our experience working with clinicians for over 30 years, we
believe clinicians are highly capable professionals that understand and evaluate the source and
basis of clinical decision support outputs before acting, regardless of how “strongly worded” the
recommendation is.
For example, industry has largely been left to guess about what FDA considers “time critical” clinical
decision support that would trigger a premarket authorization.
 Page 7 of 21

Oracle Health also disagrees with the examples provided as “Action Taking – HCP Supervised”
being higher risk, and we believe FDA might not understand how some of these functions
operate in clinical practice. The examples given of “higher risk” software functions are
“affirmative assignment of a clinical diagnosis, the prescription of a medication, or the initiation
of a clinical order set.” Oracle Health’s clinical AI agents can draft prescriptions and initiate
order sets, but they take these actions only after a clinician has verbalized in a patient encounter
what will be prescribed or ordered. The agent does the administrative work of filling out the
paperwork, and the clinician always must review and approve the paperwork before any
prescription or order is entered. If a GenAI software function is truly generating or
recommending a diagnosis on its own, rather than generating paperwork based on a diagnosis
verbalized in a patient interaction or recorded in the clinical record, then we agree that is a higher
risk function that warrants different regulatory treatment.

Oracle Health agrees that traceability of the output to primary source materials is a critical
component in not only the risk presented by a software function but also whether that software
function qualifies as a device. For clinical decision support software, if a clinician retains the
ultimate decision-making authority for an action and the software provides an explanation for the
source or basis of a recommendation that is understandable to the clinician, that should fall
squarely within the 520(o)(1)(E) exemption. But even in circumstances where the software may
still be treated as a device, if the software function provides the source and basis for the
information or recommendation to the user to evaluate and exercise their own judgment, we
strongly believe that significantly reduces the overall risk of the software.

FDA should also factor into the risk level the degree of customizability by users. For example,
health systems frequently decide for their clinicians what best practices they want to be followed
for different diseases or conditions. If a health system has decided that in all cases where patients
are diagnosed with X disease, they should be treated according to Y protocol, and a software
function is helping to administer that protocol by surfacing to clinicians or patients the next steps
in that protocol, that is a much lower risk software function than one that is independently
deciding what those next best steps are. In fact, Oracle Health believes such software functions
that are implementing a health system or provider’s customized choices should be exempt from
device regulation because they are practice of medicine.
Likewise, FDA should also factor into the risk level the extent to which healthcare providers
have designed a GenAI software function themselves. Oracle Health and other companies are
developing GenAI tools that are essentially AI Agent tool builders that providers can use to build
their own AI agents or clinical decision support tools. We believe these provider-created tools,
when used only within one health system and not marketed for widescale use, should also fall
into the practice of medicine and should not be regulated as devices. We consider these providerdeveloped and provider-used agents to be analogous to lab developed tests and to fall outside of
FDA’s jurisdiction. But even if FDA reached a different conclusion about the regulatory status of
these provider-developed agents, we think that anything developed by providers for their own
practice should fall into a much lower risk category than other software functions.
 Page 8 of 21

FDA has also asked whether “the time pressure of the deployment setting” should be a factor in
the risk analysis. Oracle Health strongly disagrees that the time pressure of the deployment
setting should be relevant to the device status of the software function or to the risk category of
the function. FDA introduced the extra-statutory considerations of “automation bias” and “time
criticality” in previous guidance documents. We strongly disagree that these concepts are
consistent with the statutory text and we disagree that they should be relevant as a matter of
policy. FDA has not conducted any study and has never pointed to any evidence to show that
clinicians are less capable of making independent decisions or evaluating the basis of a CDS
recommendation in a time sensitive setting. Clinicians work in time-sensitive settings every day
and are highly trained to be able to process multiple sources of complex data in seconds to make
time-critical decisions. By raising the bar for getting this clinical decision support to clinicians,
FDA has made it harder for clinicians to give patients the best possible care, because FDA has
created a regulatory hurdle to valuable sources of information. We strongly disagree with
exacerbating that problem by treating time criticality as an important factor in this two-axis
framework.

Oracle Health agrees with FDA that the existence of downstream safeguards is a relevant factor
that should be considered in a Gen AI risk framework. The incorporation of dedicated safeguards
to control GenAI functions and protect against out of domain (or otherwise unintended outputs)
is a fundamental aspect of GenAI development that responsible developers incorporate into the
core design of any GenAI system. But in the context of medical device functions, they become
even more critical and relevant to consider as part of the GenAI-enabled medical device
regulatory framework.

For example, a GenAI-enabled device function designed to provide recommended diagnostics
limited to a particular context associated to its intended use may/should build -in guardrails to
detect out of bounds inputs that prevent responses on out of context requests, as well as output
guardrails to detect out of scope or inappropriate recommendations for in-context requests. The
presence of such safeguards should be considered a mitigating factor that can reduce the risk
profile of a GenAI-enabled device function. Therefore, safeguards that keep a GenAI-enabled
device function within its intended use should be treated as a mitigating factor that reduces
the function’s risk profile.
FDA also should provide clarity on how to appropriately and consistently define what constitutes
limited, moderate, and severe consequences. Consistent definitions help drive the evidence FDA
expects both before and after marketing authorization. Making the categorizations as clear and
concise as possible is critical. Oracle Health suggests that FDA define each tier by reference to
the severity of harm that could reasonably result from relying on an incorrect output, and
illustrate each tier with clinical examples, building on those already in the Discussion Paper.

Oracle Health agrees with other stakeholder groups including the Consumer Technology
Association (CTA), AdvaMed, and the US Chamber of Commerce that additional clarity is
needed with more examples mapped to the framework to provide clarity to developers on
appropriate, least burdensome, risk-proportionate evidence generation.
 Page 9 of 21

Oracle Health also reiterates the importance of FDA ensuring that eventual guidance maintains
maximum clarity that the framework applies exclusively to GenAI functions that are separately
determined to meet the definition of a medical device. Since the framework itself can be read to
be generic and applicable to non-device functions, it is critical that the industry have full clarity
on the scope and intent to avoid misapplying regulatory obligations to non-device GenAI
functions.

If FDA moves forward with the concepts presented in the two-axis framework in future
regulation or guidance, Oracle Health requests that such a policy be issued in draft form so
industry will have another opportunity to comment once the concepts have been further clarified.

Question 2
CDRH seeks input on how to account for the spectrum of GenAI-enabled informational functions that
vary in the degree to which they direct a user to a particular action (i.e., between “non-directive” and
“action-directing”). What characteristics of an output—such as its wording, specificity,
personalization, or context—could be considered as modifiers of the risk associated with an
informational function, after accounting for the device’s overall functionality and intended use? What
additional information would provide manufacturers with sufficient clarity and predictability around
risk assessment for informational functions while recognizing that directiveness may exist along a
continuum rather than as a binary distinction?

Oracle Health Response
Although the Discussion Paper suggests that directiveness exists along a continuum, we believe
it is feasible to cleanly delineate between an output that directs an action, autonomously or not,
and one that is purely informational, and that FDA should provide clear guardrails for the
industry. As noted in the response to Q1, the difference between Informational: Action Directing
and Action-Taking: HCP-Supervised is unclear and arguably irrelevant for purposes of assessing
risk in circumstances where a human in the loop is ultimately responsible for making the relevant
clinical decision.

Wording considerations on its own also should not be the sole factor for assessing risk. Risk
mitigations should include whether the output is explainable with appropriate source information
for review by the user. FDA must also take into account the specific context of an output. Even
where two functions align on wording and explainability, their impact may be very different
given context and specifics of the output based on the intended use and users.

Finally, we again reiterate that this distinction should inform risk assessment only for functions
that are devices. It should not affect whether an HCP-facing function meets the clinical decision
support exclusion in section 520(o)(1)(E) of the FD&C Act, as FDA has interpreted that
exclusion in its revised Clinical Decision Support Software guidance.
 Page 10 of 21

Question 3
CDRH seeks input on whether and when a GenAI-enabled function that results in delivery of clinical
information to patients, as opposed to HCPs, could present different or higher risks, while also
recognizing the potential benefits associated with improved patient empowerment, engagement, and
access to clinical information. What device characteristics, output features, or safeguards might
mitigate risks that could arise when a user lacks the domain knowledge to independently evaluate an
output, without unnecessarily underestimating patient capability?

Oracle Health Response
We do not agree that device functions intended for a patient or consumer audience inherently
present elevated risks that warrant different considerations in the regulatory framework. Patients
and consumers already use these technologies in their day-to-day lives. FDA should continue to
take a risk-based approach and focus on higher risk functions. Functions that provide information
from a chart or clinical guidelines with source information should not be a focus of FDA
oversight. Functions that diagnose or treat a condition should continue to be under FDA’s
oversight.

Measures to mitigate risk may include increased transparency that outputs are AI -generated,
clear language appropriate to the intended user, and disclaimers that accurately describe the
intended use. For interactive devices, guardrails should address areas such as unsafe clinical
queries or scenarios, harmful or abusive content, and the risk of unintended social or emotional
connections. Together, these safeguards can preserve the benefits of patient access to clinical
information without underestimating patient capability.

Question 4
CDRH seeks input on whether and how the distinction between generalist and specialist physicians
might inform the assessment of risk for HCP-facing GenAI-enabled functions. Under what
circumstances, if any, might risk be affected when an HCP who lacks the relevant clinical specialist
knowledge receives information that falls within a specialist area of practice? What device
characteristics or safeguards might mitigate such risks?

Oracle Health Response
The most straightforward way to address this issue is a clear definition of intended and nonintended uses and users. These details should be explicitly defined in the marketing submission,
supporting documentation, and device labeling to minimize the risks that can arise from misuse.
Model cards or other methods to display the indications for use and intended users within the
technology may also be helpful to mitigate risks.

FDA should not, however, presume that a function addressing a specialist area must always be
limited to specialists. GenAI-enabled functions can extend specialty knowledge to primary care
and other generalist clinicians, which may improve access to care where specialists are scarce or
wait times are long. The Discussion Paper recognizes this benefit. Rather, the important
 Page 11 of 21

consideration is whether the developer/manufacturer intends the function to be used outside of a
specialty area and has trained and/or evaluated it for generalists.

Where a manufacturer designs and validates a function for use by generalists, its labeling should
be able to say so. Any added risk can then be addressed through design and testing rather than
limits on who may use the function. Relevant safeguards include outputs that identify their basis
and the limits of the underlying evidence, prompts that flag when specialist consultation or
referral is warranted, and usability testing with representative generalist users. We believe
performance should also be compared against the realistic alternative for those users, such as
unaided generalist judgment or delayed specialist review, rather than against specialist
performance alone (see our responses to Questions 14 and 15).

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

Oracle Health Response
FDA’s oversight should focus on the device function including the intended use of the product
and guardrails and mitigations in place to prevent a conversation from moving into functions
outside that intended use. Conversational devices should be regulated based on what the product
is designed and tested for, not on every theoretical output. That testing should include realistic
conversational paths, including reasonably foreseeable misuse. An output outside the device’s
intended use is a performance issue to be addressed through design, testing, and postmarket
controls. It does not change the device’s intended use. Postmarket monitoring, real-world data,
and other guardrails can be effective ways to identify and correct those outputs. We discuss these
concepts in response to later questions. This is a least burdensome approach for both FDA and
industry while maintaining safety and effectiveness.

Question 6
For GenAI-enabled care escalation functions, CDRH is considering how the evaluation may account
for both under-escalation and over-escalation. How could manufacturers characterize and weigh these
two directions of error, given that they may not be commensurable and that acceptable trade-offs may
vary by clinical context?

Oracle Health Response
We are supportive of ensuring that both over- and under-escalation are characterized and
evaluated for a device. The specifics will depend on the intended use of the device. The
characterization of over- and under-escalation of care should not be applied to certified EHRs or
the underlying platform technology. FDA should also be aware that health systems often
customize clinical decision support to raise or lower the bar for when clinical decision support
 Page 12 of 21

will alert. Providers are in the best position to decide for themselves what alerts are causing
fatigue and to evaluate their own population health data to determine where there are care gaps
among their own patient population. The ability to customize CDS tools improves care for
patients and ultimately is a practice of medicine decision that should be within the choice of the
provider to make. FDA should treat these provider choices as outside of its device jurisdiction, or
at least treat it as lower risk.

III. A Competency-Based Approach for Premarket Evaluation (Discussion Paper
Section V)

Question 7
Is the competency-based approach described above, i.e., device benchmarking followed by clinical
confirmation, a useful and appropriate framework for evaluating GenAI-enabled devices?

Oracle Health Response
Yes, we believe this is an appropriate approach to the regulation of GenAI-enabled medical
devices. Benchmarking evaluation should be a core activity in the development and design
process for any AI-based product and thus should be an absolute baseline expectation for GenAIenabled medical devices. The addition of an independent set of obligations focused on clinical
competency is logical and necessary to account for the specific functions that devices serve.

Importantly, FDA should design benchmarking and clinical confirmation expectations so that
sponsors/developers have flexibility in how they show evidence of the expected competencies. In
many ways, every AI-enabled function is unique and may necessitate unique approaches or proof
points (e.g., different types of evaluations, scoring rubrics, and acceptance criteria). Sponsors are
best suited to make that determination and should be able to justify their evaluation methods and
data for FDA consideration. That approach is preferable to requiring every GenAI -enabled
device to conform to a single, prescribed set of evaluations or acceptance criteria. This flexibility
is consistent with the Discussion Paper’s description of sponsors prespecifying evaluation
methods and justifying their scoring rubrics and acceptance criteria.

It may be helpful to align these competencies with existing concepts, such as the characteristics
identified in the NIST AI RMF (see “AI Risks and Trustworthiness”) and the ONC list of
characteristics related to Validity, Reliability, Robustness, Fairness, Intelligibility, Safety,
Security and Privacy. Some of these characteristics already appear in the Discussion Paper’s
benchmarking elements. This would offer a helpful default approach and establish consistency
across agencies and across similar functions for developers of both health IT and medical
devices.
 Page 13 of 21

Question 8
How might the two-axis risk framework described in Section IV be considered within the competencybased approach described above to help determine the level of evidence needed for a premarket
submission?

Oracle Health Response
The two-axis framework is a good way to determine the level of scrutiny a GenAI-enabled
device must undergo in the benchmarking and clinical confirmation phases. For example, a
device that is both fully autonomous and considered to pose severe risks (see our response to
Question 1 regarding how that term should be defined) would require the highest level of
scrutiny, including premarket evaluation of real-world clinical data and results/evidence, as
opposed to being allowed to be cleared with evaluation using only synthetic data attempting to
mirror real world data expected.

In differentiating scrutiny and evidentiary expectations across the risk framework, the most
critical factor is autonomy. Autonomy is, by far, the component that introduces the most risk and
complexity in healthcare delivery settings, and it should be emphasized as such in the regulatory
framework.

We also acknowledge that as data science and evaluation methodologies or capabilities evolve it
may become more acceptable and reliable to rely more on synthetic data. Thus, FDA must also
keep in mind the future-proofing of the regulatory framework.

Question 9
Would a benchmarking structure such as the one described above be likely to provide adequate
evidence of clinical knowledge, analytic capabilities, safety behavior, communication, and
generalizability to support a reasonable assurance of safety and effectiveness? Are there elements that
are missing, redundant, or inappropriately categorized? Are there externally developed standards that
could be leveraged?

Oracle Health Response
The structure of the benchmarking approach is sound and can support the necessary level of
evidence, etc. The key is how those principles are applied in practice. The Discussion Paper
addresses this to some extent in its Methodological Approaches and General Principles section,
but we suggest organizing the principles around a framework such as the NIST AI RMF
principles (see “AI Risks and Trustworthiness”) and providing direct guidance on the
expectations for each, while leaving the approach and evidence to the developer to support with
justification in its submission.

FDA could also consider supplying open data sets for benchmarking evaluations that could be
specialized for different classes of use cases or scenarios. This would give benchmarking a
common foundation and make results more comparable across developers. To address the
contamination and saturation concerns the Discussion Paper identifies, FDA could hold back part
 Page 14 of 21

of each dataset as a sequestered test set. This is also an opportunity for collaboration with the
National Institutes of Health (NIH), the Advanced Research Projects Agency for Health (ARPA -
H), and other agencies, because high-quality benchmarking data is a major need for the
healthcare sector as a whole and could have benefits beyond FDA’s regulatory activities.

Question 11
CDRH is considering that clinical confirmation for a GenAI-enabled device might not require a
prospective clinical study in every case,and has described above a range of approaches of increasing
rigor and patient exposure. How might a sponsor select and justify a confirmation approach tailored to
a device’s intended use and proportionate to the device’s risk profile? Are there device types or risk
profiles for which one or more of these approaches would be insufficient or inappropriate? How might
the anticipated distribution of real-world inputs be taken into consideration? Are there other methods
of clinical confirmation that might help inform the evaluation of GenAI-enabled devices?

Oracle Health Response
We support a risk-based approach under which only the highest-risk cases require a prospective
clinical study (e.g., those involving autonomous functions and severe consequences). For lowerrisk devices, less intensive approaches, such as retrospective evaluation on real patient inputs or
shadow deployment, should generally be sufficient.

Question 12
How should sponsors achieve statistically meaningful performance measurement for GenAI-enabled
devices? Where synthetically generated inputs supplement real patient data, how should sponsors
account for differences between the synthetic and real-world distributions when estimating
performance, and under what conditions, if any, is it appropriate to combine benchmarking evidence
and clinical confirmation evidence to support a single performance estimate?

Oracle Health Response
We strongly support allowing the use of synthetic data. When developed correctly and
thoughtfully, synthetic data sets can be extremely valuable and highly representative of actual
real-world data and conditions – and that is only expected to continue to improve as developers
gain more experience with synthetic data sets and technical capabilities advance. It is also
important to recognize that obtaining high quality real-world clinical data sets that are suitable
for specific evaluation needs can be challenging – in many/most cases the only way to truly
conduct real-world clinical data evaluation is to deploy to production use in a limited or trial
basis.

This flexibility is critical to avoid unnecessarily slowing market access for valuable device
functions solely because of an inability to obtain adequately sized real-world clinical datasets for
premarket evaluation. The level of use of synthetic data will depend on the risk profile of the
model and other evidence that is developed, but it is also important to remember that real-world
clinical data evaluations will also be produced as part of postmarket monitoring.
 Page 15 of 21

Question 13
For which clinical domains, device functions, or subpopulations is synthetic data particularly wellsuited, or particularly inadequate, as a supplement to real-world evidence? What safeguards would
mitigate the risk that synthetic data generated by models of the same class as the device under
evaluation reproduces the very performance gaps the evaluation is intended to detect, particularly for
underrepresented subgroups?

Oracle Health Response
Synthetic data should be permitted to support all clinical domains or device functions; however,
where a device is fully autonomous and its outputs carry severe consequences, it may not be
suitable in isolation and should be supplemented by real-world clinical data as a premarket
expectation – or at least as a requirement for full market approval with the opportunity for trial
periods under which to conduct real-world clinical data evaluation. As stated above, for other
Gen-AI enabled devices, synthetic data is both useful and important to build or obtain sufficient
datasets while reducing privacy and security concerns and to speed innovation and testing.

In terms of safeguards for synthetic data, it would be helpful for FDA and industry to work
together to determine what are appropriate benchmarking standards for synthetic data.
Furthermore, as stated above, retrospective evaluation on real patient inputs or shadow
deployment can provide sufficient safeguards for Gen-AI enabled devices. Testing on real
patient inputs can reveal performance gaps, including for underrepresented subgroups, that
synthetic data generated by similar models may miss, but a focus on strong postmarket
monitoring activities can ensure that those situations are identified quickly and appropriate
mitigations occur to circumvent negative outcomes.

Question 14
For open-ended device outputs, how should performance comparators and acceptance criteria be
selected? When a panel of qualified clinicians serves as the comparator, how should the applicable
standard (for example, the standard of care versus the performance of a median clinician in practice)
be defined and justified? Should generalist or specialist physicians be used as a performance
standard? When should human-AI team performance, rather than the device operating alone, serve as
the basis for evaluation?

Oracle Health Response
The appropriate comparators and acceptance criteria will depend heavily on the specific use case
and functions of the device. CDRH should consider developing more product specific guidances
like the proposed FY27 A-list draft guidance on “Generative Artificial Intelligence-Enabled
Conversational Devices for Mental Disorders: Evidentiary Recommendations.” We recognize
guidance development takes a lot of Agency time and effort; thus, we also support frameworks
for the FDA to provide clear expectations for developers more quickly.

For example, for clinician-facing tools where the clinician reviews the output before acting,
benchmarking and clinical competence should include standalone model performance and
 Page 16 of 21

human/AI team performance. Where a manufacturer relies on clinician review as a risk control, it
should be able to show that the review works in practice. For lower risk devices, less clinicianmodel interaction evaluation would be needed.

If the intended use of a model is for generalists to support specialist activities, comparators
should include specialist standard of care of the model itself and how the model and generalist
clinician perform compared to standard of care. When standard of care is not an appropriate
measure, sponsors should work with FDA on what the appropriate acceptance criteria is.

Another important consideration is establishing benchmarking and acceptance criteria in
situations where the device is direct-to-consumer and there may be no physician involved in
patient care, such as consumer-directed mental health tools. In those situations, the appropriate
comparator cannot always be limited to an established standard of care or the performance of a
median clinician in practice. Where the intended use includes clinician review of device outputs,
the combined performance of the clinician and device working together is generally the most
relevant basis for evaluation.

Question 15
Are there ways in which performance might be assessed relative to the care, technology, or course of
action likely to occur in the absence of the device, rather than to the comparators described in this
section? What approaches might be used to identify and justify a comparator such as unaided clinical
judgment, delayed specialist review, or no intervention?

Oracle Health Response
Please see our response to Question 14. Where no care is present, the course of action likely to
occur in the absence of the device, including no intervention, may be the most meaningful
comparator.

Question 16
Should independent third parties be involved in some or all aspects of a competency-based approach,
including device benchmarking and clinical confirmation? If so, in what ways might qualified,
independent third-party participation contribute to this approach, and what qualifications and
independence criteria should apply? Are there aspects of the assessment for which third -party
involvement would be impractical or inadvisable? What safeguards or program design features would
be critical to prevent third-party participation from limiting competition or preventing innovation?

Oracle Health Response
Third-party participation in benchmarking and clinical confirmation should be permitted to the
extent that a developer seeks to voluntarily involve a trusted third -party to assist in execution of
their evaluation and monitoring activities. It should not, however, be mandated by FDA. Thirdparty evaluation can be valuable, but it is not always necessary or appropriate, for example in
cases of highly specialized intended uses. Often, the developer is the most knowledgeable source
to conduct evaluations, and provided that it is able to supply necessary data with justification, its
 Page 17 of 21

evaluation can provide credible evidence. Any third-party program would also need safeguards
related to intellectual property, confidential commercial information and trade secrets, privacy,
and cybersecurity. Finally, leveraging third-party evaluators opens up the risk of inconsistent
proprietary methodologies for evaluation which undermine the quality and reliability of the
process. For those reasons, mandating third-party evaluations would be an unnecessary and
misguided policy move.

However, if optional to sponsors, Oracle Health strongly supports FDA placing greater reliance
on existing FDA programs, such as the “FDA Recognized 510k Third Party Review” program.
These programs already have appropriate safeguards in place and participants have already been
vetted by FDA for the quality of their reviews. Some of these third-party reviewers, such as
Scarlet NB N.V., are highly specialized reviewers with a niche knowledge and experience in Gen
AI. There are a limited number of individuals around the world who are capable of
understanding and reviewing GenAI tools at the level of skill that is concentrated in such a third -
party reviewer. Leveraging these highly skilled and experienced third -party reviewers could
facilitate getting safe and effective technologies to market faster in the US. In the case of thirdparty reviewers like Scarlet, which are able to assess CE marks in Europe and the UK, it could
also serve a dual purpose of increasing regulatory harmonization.

IV. Postmarket Monitoring (Discussion Paper Section VI)

Question 18
CDRH is considering whether it may be appropriate to accept greater premarket uncertainty
regarding a GenAI-enabled device’s benefit-risk profile through greater reliance on postmarket
monitoring. Under what conditions might such an approach be appropriate, and what characteristics
of a monitoring program would need to be in place to justify reduced premarket evidence? Are there
device types or risk profiles for which this approach would not be appropriate?

Oracle Health Response
We strongly support FDA accepting greater premarket uncertainty through greater reliance on
postmarket monitoring. We would expect premarket assessments to remain rigorous regardless
of a device’s risk profile, but evidence requirements could be shifted from premarket to
postmarket for most GenAI-enabled devices.

Enhanced postmarket monitoring may be needed to support the shift in data. We recommend
leveraging real-world data, including from EHRs, with more frequent and even near real time
monitoring by manufacturers. Other enhanced monitoring methods could include FDA having
direct access to RWD. Oracle Health would welcome an opportunity to discuss how regulators
can work with EHR vendors to access RWD and modernize and enhance postmarket monitoring.

Postmarket monitoring plans could also include performance checks at defined intervals and
model cards for transparency. Our response to Question 19 outlines a suggested framework for
postmarket monitoring and overall maintenance, and FDA should also consider how they can
 Page 18 of 21

partner with EHR vendors to gain access to real world data to help modernize postmarket
surveillance processes.

Shifting the burden for fully autonomous, high-risk devices may be more challenging. In such
cases, the risk of going to market without a suitable level of premarket evaluation and evidence
of safety is severely heightened in such fully autonomous devices because it lacks the additional
safeguard of having a human in the loop to act as a “gate” against catastrophic outcomes from
incorrect device outputs.

Question 19
Please comment on the potential approaches to postmarket performance evaluation, including periodic
re-benchmarking, sample-based clinician review, and performance degradation monitoring. What
additional approaches should CDRH consider, and how should the cadence and triggering events for
reassessment be determined?

Oracle Health Response
We recommend that every GenAI-enabled device have a tailored postmarket operations and
monitoring plan made up of defined required components or subject areas, while providing
flexibility for the developer to identify its own approaches or re-benchmarking elements. For
example, a sound operations and monitoring plan could include the following elements:

(i) Identification of specific responsible parties and escalation points for the device to
demonstrate accountability and clear paths for issue awareness and resolution.
(ii) Monitoring measurements for specific categories: basic operations (latency, throughput,
scaling, etc.), safety (distribution of inputs, jailbreak attempts, out-of-bounds inputs, etc.),
and performance (recall, precision, rubric-based metrics on fairness, etc.).
(a) Measurements should include frequency of execution, ranges for acceptability
and/or criticality, and plans for mitigation when thresholds are exceeded.
(iii) Strategies and plans for receiving and considering feedback from active users.
(iv) Maintenance and update plans such as a PCCP (i.e., how often the system is updated and
the process for those updates).
(v) Degradation or incident handling plans, including a “kill switch” methodology for fully
autonomous systems (i.e., how the developer will respond when an unexpected issue is
observed).
Under this approach, manufacturers could maintain and report their monitoring results as a
function of the quality system with accessibility to FDA on an enhanced basis. Required eventbased reporting aligned to existing regulations would continue. Real world data from EHRs can
facilitate this process and trigger warnings faster. For example, a breach of a criticality threshold,
such as an adverse event, could trigger a report submission and/or a more direct audit to verify
that the developer followed its predefined degradation plan as authorized. Examples of triggering
events may include breaches of safety or effectiveness thresholds, highly unusual spikes in
 Page 19 of 21

clinician overrides or guardrail blocks, significant drift, reliability degradation, adverse events,
and credible complaints. Human review should increase as risk signals rise rather than wait for
the next scheduled audit.

Deeper audits with clinician subject matter experts should still occur, but they should be sample
based. Each authorized GenAI-enabled device should be audited on a reasonable cadence that
reflects the overall risk profile and intended use of the device (e.g., once every three years for
some devices and more frequently for others).

For ongoing updates and deployments of changes, any change defined and authorized within the
maintenance and update plan (PCCP) should be allowed without a new marketing submission,
and the next recurring monitoring report would capture updates to measurement criteria.

Finally, we recommend that FDA consider private-public partnerships on postmarket monitoring
and maintenance to help establish best practices and standards. This is arguably the most critical
part of a responsible and trustworthy AI strategy, yet it lacks clear and consensus best practices,
particularly ones that are specific to particular types of AI, such as generative and agentic AI.

Question 20
Please comment on whether the proposed approaches to postmarket monitoring can be facilitated by
machine-based supervisory agents. What considerations, including the evaluation and reliability of the
supervisory agent itself, should CDRH take into account for such an approach?

Oracle Health Response
Basic monitoring should absolutely be able to be conducted with supervisory agents. These
agents could be designed to review submitted monitoring results and check for aberrations in the
data indicating that measurement thresholds have been exceeded or other potential issues
requiring deeper review or analysis. When an issue is detected, human review and audit would
be triggered (in addition to the sample-based audits described above). Otherwise, leveraging
agentic automation for reviews is a sound strategy that also streamlines the review process and
conserves FDA resources.

Any supervisory agent itself should be validated for its monitoring purpose, and its performance
should be checked periodically against human review. The monitoring results may be submitted
to FDA depending on the agreed postmarket monitoring plan between a sponsor and FDA. It is
important to note that Oracle Health is not suggesting that monitoring plans and postmarket
monitoring data should be required as a matter of course. But Oracle Health would support a
regulatory approach where sponsors could have the choice to forego a more extensive premarket
review process in exchange for enhanced postmarket review requirements.
 Page 20 of 21

Question 21
What roles might clinicians, healthcare institutions, professional societies, standards-setting bodies,
and other stakeholders appropriately play in postmarket monitoring, and how can these roles be
structured without diffusing manufacturer accountability?

Oracle Health Response
These parties can be leveraged to develop precompetitive standards and best practices for
postmarket monitoring. Oracle Health agrees with CTA that currently there is no robust public
framework for postmarket monitoring and that a public-private convening on best practices is
needed. This effort can support best practices, standards, governance, and accountability without
creating a one-size fits all approach to postmarket monitoring.

In addition, FDA could recognize relevant standards so that operations and monitoring plans that
follow those standards receive less intensive review. Individual sponsors may consider
leveraging these stakeholders as needed in their monitoring programs.

FDA should also make clear that accountability rests with the party that controls the device
function. A health IT developer or cloud provider that hosts or integrates another manufacturer’s
GenAI-enabled device or AI agent – or facilitates a healthcare provider customer’s selfdevelopment of a GenAI-enabled device via tooling – should not, by that role alone, be treated as
the manufacturer of that device. The manufacturer is the party that establishes the device’s
intended use and controls its design, validation, labeling, and changes. A host or integrator
typically controls none of those things. It cannot validate a model it did not build, and it is not
positioned to meet design control, change management, or reporting obligations for another
company’s device. Treating the host as a manufacturer would duplicate those obligations, blur
accountability, and discourage health IT and cloud providers from making regulated devices
available to their customers.

Question 22
CDRH envisions that a manufacturer’s premarket competency-based assessment might serve as a
baseline against which post-deployment modifications could be re-evaluated. How might the extent of
re-benchmarking or other evidence be scaled to the nature and ex pected impact of a given
modification? For example, are there categories of change that might not significantly affect safety or
effectiveness of a GenAI-enabled device, or might be appropriately managed within a sponsor’s quality
management system versus requiring FDA premarket review and authorization before
implementation? Are there categories of changes that might be appropriate for inclusion in a PCCP?

Oracle Health Response
We agree that the results of premarket benchmarking (which are themselves measured against an
established standard or evidence base) should serve as the baseline for re-benchmarking. As
performance improves over time, those new benchmarks could become the measurement point
for future re-benchmarking, but this should be something developers measure for themselves and
 Page 21 of 21

maintain the original benchmark in the authorized acceptance criteria for purposes of
determining acceptable changes.

Changes that should not require further FDA review are:

• changes that do not change the risk profile of the device,

• defect releases,

• changes that do not impact usability,

• security patches and updates that aren’t safety related.

• changes to platforms which do not require device updates, or passive labelling changes or
new translations, and

• algorithm retraining on additional data within the same architecture, performance
specifications, and intended use.

In general, FDA should allow a PCCP to cover any type of change that can be suitably specified
in advance, along with the methods to validate it. Changes made under an authorized PCCP
should be deployable without a separate marketing submission, as the statute provides, provided
that the change matches what FDA authorized in the PCCP and that monitoring data for ongoing
re-benchmarking continues to be tracked and reported. Delaying deployment of updates pending
premarket authorization can also harm the system and its users by slowing the deployment of
important improvements.

Question 23
How might PCCP concepts or other change-control approaches be adapted for GenAI-enabled devices
when the nature or scope of future modifications cannot be fully prespecified?

Oracle Health Response
We agree with other stakeholders including AdvaMed and CTA that FDA’s existing PCCP
authority should be leveraged for GenAI-enabled devices and that FDA is currently not using
those PCCP authorities to the fullest extent. FDA should provide additional clarity on what level
of detail is needed to be prespecified per the current statute. Whether a change is appropriate for
a PCCP would have to be determined case by case in the initial marketing submission, but it
would be important to allow PCCPs to include broader prespecified changes with appropriate
justification and embedded controls. For example, a PCCP could define the boundaries for future
changes by prespecified performance thresholds and validation methods, rather than by an
exhaustive list of modifications. Any change that meets those thresholds would remain within the
scope of the PCCP authorization.