Epic Systems Corporation (David Hoffert, Kasia Klotz)

Please see attached for comments from Epic on docket number FDA-2026-N-7874.

1

October 19, 2026

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

Submitted electronically at: https://www.regulations.gov

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

Dear Sir or Madam:

Thank you for the opportunity to respond to your discussion paper regarding considerations for
the regulation of generative AI-enabled medical devices. Epic is a global healthcare technology
company that works with hospitals and clinics in every state across the nation, providing an
integrated software suite to manage both clinical care and back-office operations. Our patient
portal, MyChart, puts medical records in the pockets of patients, enhancing medical literacy,
communication, and wellness.

AI has the potential to ease administrative burdens for providers and help patients get well
faster. Drawing on our decades of experience in developing software used in healthcare, we
provide feedback to help inform the development of further policy in this area.

We would be happy to answer any questions you may have and would welcome further
collaboration on your work to develop efficient, scientifically sound, and least burdensome
approaches to the premarket evaluation and post-market monitoring of GenAI-enabled devices
across the total product life cycle.

Sincerely,

David Hoffert Kasia Klotz
Director of AI Policy Quality Manager, AI Regulatory

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
Considerations for the Assessment of Risk for GenAI-Enabled Medical Devices
Risk-Proportionate Approach
Epic supports CDRH's effort to develop a risk-proportionate approach for GenAI-enabled
medical devices. Epic also appreciates CDRH's reiteration that many software functions are not
medical devices and that FDA regulates medical devices incorporating GenAI, not GenAI as a
technology. The use of GenAI does not itself determine whether a software function qualifies as
a medical device or the level of regulatory risk associated with that function. CDRH should
address GenAI-related considerations through existing, technology-neutral medical device
requirements and guidance wherever practicable, rather than create duplicative GenAI-specific
requirements.

Risks associated with a software function's intended use should be assessed consistently,
regardless of whether the function uses GenAI. Risk assessment should remain grounded in the
function's intended use and the likelihood and severity of harm if the function does not perform
as intended. These principles should inform CDRH’s proposed approach to assessing the risk of
GenAI-enabled software functions.

CDRH proposes a two-axis framework, assessing Activity and Consequences, as a heuristic for
evaluating risk. Device activity and the consequence of relying on an incorrect output are
relevant dimensions of risk, but they should not be considered in isolation. Risk assessment
should also consider the likelihood that an incorrect output will occur and, separately, the
likelihood that the output will result in harm. The proposed framework does not explicitly
account for either likelihood or for the controls and safeguards that may reduce them. Controls
such as human review before an output is acted on, the ability to verify an output against
authoritative underlying information, and downstream workflow safeguards can reduce the
likelihood of harm and should be considered when assessing risk. Accordingly, the proposed
framework should not be used in isolation to determine regulatory expectations applicable to a
particular software function.

If CDRH pursues the two-axis framework, it should clarify how likelihood and safeguards should
be considered in assessing risk. CDHR should also define the consequence levels, Limited,
Moderate, and Severe, with sufficient specificity to support consistent and predictable
application by manufacturers.

Informational and CDS Functions
CDRH should distinguish between functions based on the role they play in clinical decisionmaking, without undermining the statutory CDS exclusion or departing from FDA’s existing
Clinical Decision Support Software guidance. Software functions may play different roles in
clinical decision making. For example, a function may present protocols, evidence, or patient
data for a user to evaluate; apply an established clinical protocol to patient-specific information
and recommend the pathway specified by that protocol; or independently assess patientspecific information and develop a recommendation without relying on an established protocol.
These distinctions are relevant both to determining whether a function qualifies as a medical

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
device and, for functions that do qualify as devices, assessing their risk. The use of GenAI alone
should not determine either outcome. The relevant question is not simply whether GenAI
generated the output, but what the function is doing, where the information processed by
GenAI comes from, and how the output is intended to be used.

Directiveness should be assessed based on the function and intended use, not the wording of
individual GenAI outputs. For example, retrieving and presenting an established treatment
protocol, suggesting that a patient discuss a medication adjustment with a clinician, and
independently instructing a patient to change a specific medication dose illustrate different
degrees of directiveness in patient-facing functions. Relevant considerations include the
specificity of the action and the degree of independent judgment required by the user before
acting on the output.

For text produced by GenAI, CDRH should not expect manufacturers to evaluate the
directiveness of every potential output to verify that it is always non-directive; the nature of
GenAI renders this level of verification infeasible with current technology. Manufacturers should
instead define the function's permitted capabilities and use appropriate testing to demonstrate
that it operates reliably within those boundaries. An isolated output that falls outside those
boundaries should be evaluated as a deviation from the function's intended behavior, rather
than automatically treated as evidence that the function has a different intended use.

CDRH should maintain a clear distinction between determining whether a software function
qualifies as a device and assessing the risk of a function that does qualify as a device. CDRH
should clarify how its proposed framework interacts with FDA's existing Clinical Decision Support
Software guidance and the statutory CDS exclusion. For a function that is excluded from the
definition of a medical device, the proposed risk framework does not itself change the
qualification analysis.

For HCP-facing software functions, the ability of an HCP to independently review the basis for an
output and trace it to relevant source information is relevant to the statutory CDS exclusion
analysis, alongside the other applicable statutory criteria. For functions that do qualify as
devices, those same capabilities should remain important considerations in assessing device risk.

Intended Users
In assessing the risk of patient-facing GenAI-enabled medical devices, CDRH should consider
realistic alternatives available to patients. Patients seek health information from internet
searches or general-purpose AI applications that lack the clinical context or privacy and safety
controls of GenAI-enabled medical devices developed to work specifically for patient care. A
framework that unnecessarily restricts useful information from regulated products or is too
burdensome for regulated products to attain clearance will unintentionally steer patients to less
controlled general-purpose alternatives.

Additionally, CDRH should preserve meaningful distinctions between presenting health
information for a patient to use to make a decision; facilitating and supporting patient-clinician

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
communication; encouraging consultation with a clinician; directing a patient to take an action
based on an established clinical protocol; and independently directing a patient to take a clinical
action without reference to an established protocol.

For HCP-facing medical devices, whether an HCP is a generalist or specialist should not serve as
a proxy for risk. Generalists are often required to provide care for conditions for which other
patients may seek specialty care and would particularly benefit from tools that make specialtyspecific guidelines and protocols available at the point of care. For example, studies examining
pediatric sepsis care across pediatric and general emergency departments have identified lower
adherence to pediatric sepsis guidelines in general emergency departments and higher
mortality among pediatric patients with severe sepsis or septic shock treated in those settings.1,2
These findings highlight the potential value of tools that help generalists access and apply
established specialty-specific guidance.

Classifying the promotion of specialty guidelines to generalists as higher risk simply because
they are a generalist unnecessarily raises the bar for a current need, when the function and the
healthcare institution’s adoption of the guidelines or protocol are more relevant to risk.
Promoting a healthcare institution’s existing specialty protocols to generalists is low risk and
improves protocol-recall and adherence. CDRH should consider these potential benefits
alongside potential risks rather than presume that use by a non-specialist is inherently higher
risk.

Conversational and Care-Escalation Functions
For multi-turn conversational medical devices, the number of conversational turns does not itself
determine risk. Manufacturers should assess the functions the device is intended and permitted
to perform and establish appropriate controls around those functions. If a function is intended
to provide action-directing recommendations, that capability should be addressed regardless of
where in a conversation the recommendation occurs. If a function is intended to remain
informational, manufacturers should use appropriate controls and testing to support reliable
operation within that boundary across long-running conversations.

For care-escalation medical devices, both under-escalation and over-escalation should be
evaluated without creating incentives that systematically favor one type of error. Underescalation can delay necessary treatment, while over-escalation can result in unnecessary
utilization, testing, procedures, costs, and burden on higher-acuity settings. The appropriate
balance depends on the clinical context, the likelihood of each type of error, the likelihood and
severity of resulting harm, and realistic performance benchmarks. CDRH should also distinguish
between guideline-directed recommendations and recommendations based on independent
Kessler, D.O., Walsh B., Whitfill, T., et al. (2016). Disparities in Adherence to Pediatric Sepsis Guidelines across a
Spectrum of Emergency Departments: A Multicenter, Cross-Sectional Observational In Situ Simulation Study. J
Emerg Med, 50(3), 403-415.e3.
Baker, A.H., Monuteaux, M.C., Eisenberg, M.A., Hudgins, J.D. (2022). Pediatric Sepsis Survival in Pediatric and
General Emergency Departments. Am J Emerg Med, 51, 53-57.

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
GenAI assessment. For example, a function that applies an established triage protocol differs
from one that independently determines if a patient’s symptoms warrant escalation.

Agentic AI Systems
For agentic AI, CDRH should avoid treating an agentic architecture as an independent indicator
of risk. Agentic systems can operate within tightly constrained workflows in which available
actions and automations are predefined. These systems may not present materially different
risks from deterministic software performing the same functions. The use of an agentic
architecture should not, by itself, trigger medical device regulation or additional regulatory
requirements for functions that qualify as medical devices.

Different considerations may be appropriate for devices incorporating agentic AI that are
capable of independently planning and executing multi-step actions or using external tools with
limited human involvement. For these devices, evaluation should consider the scope and
potential consequences of actions the device is permitted to take, the likelihood and potential
consequences of errors, controls around tool use, and opportunities for human oversight.
Agentic systems may also support automated testing and monitoring before and during
deployment, providing additional opportunities for oversight.

Evaluation of GenAI-Enabled Devices
Applicability of Competency-Based Evaluation
A competency-based approach is appropriate for certain GenAI-enabled devices, particularly
those intended to exercise clinical judgment across a broad range of diseases or conditions that
would otherwise require substantial judgment by an HCP. For example, a device intended to
independently evaluate a patient's presentation, suggest a differential diagnosis, propose
treatments, and initiate clinical actions across a broad range of conditions warrants a
competency-based assessment. Such a function uses the broader capabilities of GenAI and may
provide clinical value without requiring manufacturers to artificially restrict the device’s intended
use to a narrow set of diseases or conditions. However, a device that performs a narrowly
defined function across many diseases or conditions should not require competency-based
evaluation solely because of the breadth of its clinical coverage.

Similarly, competency-based evaluation would be an inappropriate approach for a GenAIenabled device with a targeted intended use because it would unnecessarily assess capabilities
outside the device's intended function. For example, a device intended specifically to analyze
medical images to identify tumors should be evaluated on its performance for that function, not
on its ability to perform the broader range of tasks expected of a radiologist. Such devices
should be evaluated using performance testing and validation methodologies tailored to the
given device’s intended use.

Where competency-based evaluation is appropriate, CDRH should allow manufacturers to
define and justify the competencies to be assessed based on the device’s intended use and
supported modalities. Evaluation should not require a device to demonstrate capabilities outside
its intended use or perform tasks using modalities it does not support. CDRH should clearly

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
identify the characteristics that warrant competency-based evaluation, including the breadth of
clinical judgment the device is intended to exercise, the specificity of diseases or patient
conditions addressed, the degree of autonomy, and the nature and potential consequences of
the actions the device can take. Special controls for appropriate device classifications could
establish competency-based evaluation requirements where warranted.

Benchmarking and Clinical Confirmation
CDRH should not prescribe specific GenAI benchmarks or uniform performance thresholds at
this time. GenAI technology and evaluation methodologies are evolving rapidly, and a
benchmark that is appropriate for one device, intended use, or deployment context may be
poorly suited to another. Existing benchmarks may also become outdated, saturated, or
incorporated into model training data. Instead, manufacturers should define and justify a fit-forpurpose evaluation strategy, including appropriate methodologies, tools, test data, performance
measures, and acceptance criteria. CDRH should evaluate whether that strategy provides
adequate evidence for the particular device rather than prescribe specific benchmarks or
evaluation pathways.

Epic agrees that prospective clinical studies should not be expected for every GenAI-enabled
device. Retrospective evaluation, real-world data, simulation, shadow deployment, post-market
monitoring, and other forms of clinical evidence may each be appropriate depending on the
device and its intended use and the evidence needed to establish its safety and effectiveness.
CDRH should allow flexibility in selecting and justifying the clinical confirmation approach
appropriate for the device, consistent with applicable regulatory requirements.

Adjudication and Performance Comparators
CDRH should carefully consider the cost, burden, and timelines associated with extensive
clinician adjudication, as well as whether such human review provides meaningful benefits over
other evaluation methods. Requiring multiple independent clinicians or specialists to adjudicate
large volumes of open-ended outputs would be costly, time-consuming, and difficult to scale. It
would also place additional demands on already limited clinician time and significantly delay
development and deployment.

CDRH appropriately recognizes that an expert adjudicator may itself be a Large Language Model
(LLM). CDRH should expressly permit validated LLM-as-a-Judge approaches where
manufacturers can demonstrate that the evaluator is sufficiently reliable and fit for the
evaluation purpose. Manufacturers should determine and justify the appropriate reliability
standard for each use case, rather than CDRH imposing a uniform requirement. Research
evaluating an LLM-as-a-Judge for clinical AI-generated summaries found that LLM and human
ratings were highly consistent, and replacing a human evaluator with the LLM did not
significantly change overall reliability.3 LLM-based adjudication can therefore provide an
Croxford, E., Gao, Y., First, E., et al. (2025). Automating Evaluation of AI Text Generation in Healthcare with a
Large Language Model (LLM)-as-a-Judge. medRxiv.

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
important scalable alternative to manual review of large volumes of GenAI outputs where
appropriately validated for the evaluation task.

For open-ended outputs, CDRH should avoid prescribing a single performance comparator.
Depending on a device's intended function, an appropriate comparator may be an established
clinical reference standard, applicable clinical guidelines, an existing technology, or the care
likely to occur without the device. For devices intended to support HCP decision-making,
evaluation may appropriately focus on the performance of the HCP using the device rather than
the AI output in isolation. Manufacturers should identify and justify the comparator and
acceptance criteria appropriate to their evaluation strategy without a general requirement that
AI outputs match the response of a particular clinician or panel of clinicians.

Independent Third Parties
Independent third parties may provide useful datasets, evaluation tools, standards, or services,
but their involvement should remain optional. Requiring third-party testing or certification for
GenAI-enabled devices as a general matter would add cost and delay, limit access to qualified
evaluation resources, and create barriers to entry without necessarily improving the quality of
the evidence. Manufacturers should remain able to develop and validate their own evaluation
approaches where they can demonstrate that the approach is appropriate for the device.

Post-market Monitoring for GenAI-Enabled Devices

Reliance on Post-market Evidence
Epic supports a total product lifecycle approach that combines appropriate premarket validation
with risk-proportionate post-market monitoring. Premarket evaluation relies on assumptions
about the inputs, patient populations, users, workflows, and clinical environments a device will
encounter after deployment, and those conditions cannot be fully replicated through premarket
testing. Post-market monitoring provides an opportunity to evaluate those assumptions against
actual use and generate more representative evidence of performance across deployment
environments. Premarket evaluation should provide evidence for safety and effectiveness
appropriate to the device and applicable regulatory requirements, while post-market monitoring
should help identify and address performance issues that emerge during real-world use. This
approach can support more timely access to beneficial technologies while enabling continued
evaluation of device performance under real-world conditions.

Post-market Performance Monitoring
Post-market monitoring should be tailored to the device and deployment context rather than be
subject to a prescribed combination of periodic re-benchmarking, clinician review, and
performance degradation monitoring. Relevant approaches may include real-world performance
monitoring and ongoing regression testing. Monitoring can assess not only degradation over
time, but also differences in performance associated with patient populations, workflows, users,
or other characteristics of the deployment environment. Where evaluation can be automated,
ongoing monitoring may also provide more useful information than reassessment on an
arbitrary periodic schedule. The scope and cadence of monitoring should reflect the risks

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
associated with the device, its intended use, the deployment environment, and relevant
triggering events.

Machine-based supervisory approaches can make ongoing monitoring more scalable. CDRH
should permit validated LLM-as-a-Judge approaches and other automated methods to evaluate
real-world outputs and identify potential performance concerns. For post-market monitoring
that warrants evaluation at scale, LLM-as-a-Judge or other automated methods are necessary to
achieve a sufficient sample size. Human review should not be required for all post-market
monitoring or as a routine supplement to automated evaluation. Instead, it should be targeted
to circumstances where human clinical judgment is specifically warranted, such as validating
automated evaluation methods, investigating identified concerns, and evaluating safety-critical
events.

Post-market Modifications
For post-market modifications, CDRH should build on existing FDA change-control
requirements and guidance rather than establish a separate GenAI-specific approach.
Manufacturers should continue to evaluate modifications to determine whether they
significantly affect safety or effectiveness and whether a new premarket submission is required.
PCCPs may provide an appropriate mechanism for anticipated modifications that would
otherwise require premarket review. However, the level of specificity currently expected for
PCCPs limits their usefulness for GenAI-enabled devices, where the precise nature and frequency
of future modifications can be difficult to anticipate. CDRH should allow manufacturers to define
and justify broader categories of anticipated modifications and appropriate validation methods,
rather than require each potential change to be specified individually in advance.

For devices built on third-party foundation models, manufacturers should be able to use model
versioning, regression testing, and revalidation to determine whether changes to the underlying
model affect device performance. Where post-market monitoring identifies performance
concerns resulting from changes to an underlying model, CDRH should allow manufacturers to
implement and deploy device changes that mitigate or address the concern without
unnecessary regulatory delay. Where the manufacturer verifies that the change addresses the
concern without changing the device’s intended use or otherwise adversely affecting safety or
effectiveness, the change should be documented to file, similar to how FDA’s Deciding When to
Submit a 510(k) for a Software Change to an Existing Device guidance treats changes made solely
to strengthen cybersecurity. Automated evaluation methods, LLM-as-a-Judge approaches, and
established post-market monitoring plans can support timely validation of those updates. CDRH
should not require manufacturers to obtain specific contractual commitments from foundation
model developers where manufacturers may not have the ability to impose such requirements.

Other Topics
Foundation Model Device Master Files
Foundation Model Device Master Files (MAFs) could provide FDA with information about an
underlying model that may not be available to the device manufacturer. Foundation Model

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com
MAFs could also reduce duplicative requests for the same foundation model information across
device submissions. However, the usefulness of such a program will depend on participation by
foundation model developers, and manufacturers should not be expected to provide or
maintain information about an underlying model that they do not possess or control.

Foundation Model MAFs should remain voluntary and should not become a prerequisite for
using a particular foundation model in a medical device. Reducing the availability of particular
foundation models could limit manufacturers from using the most appropriate model for the
particular intended use. Foundation Model MAFs should also not substitute for evaluation of the
device itself. Where characteristics or changes to an underlying model could affect the safety or
effectiveness of a device, manufacturers should address those effects through appropriate
device-level validation, testing and monitoring, as warranted by the device’s intended use and
associated risks. This is consistent with how FDA already treats off-the-shelf (OTS) software
under its Off-the-Shelf Software Use in Medical Devices guidance, and how the FDA-recognized
standard IEC 62304 treats software of unknown provenance (SOUP). In both cases,
manufacturers must show that their device performs safely and effectively with the component,
but they are not required to have full knowledge of how the component was designed or built.
CDRH should apply the same well-established approach to foundation models rather than
creating a new framework.

| 1979 Milky Way, Verona, WI 53593 | (608) 271-9000 | FAX (608) 271-7237 | www.epic.com