Digital Pathology Association (John Groth)

See attached file.

Digital Pathology Association
370 Medical Drive, Suite A
Carmel, Indiana 46032

October 19, 2026
Re: Docket No. FDA-2026-N-7874 for “Considerations for the Regulation of Generative AIEnabled Medical Devices: Discussion Paper and Request for Feedback.”

In August 2026, the US Food and Drug Administration (FDA) published a discussion paper on
the Considerations for the Regulation of Generative AI-Enabled Medical Devices which is
intended to seek early input from groups and individuals to advance a broader discussion among
stakeholders on regulation of generative AI within medical devices. As requested in the Federal
Register Notice, the Digital Pathology Association (DPA) is providing comments on the
discussion paper principles through the Federal Register docket.

The Digital Pathology Association (DPA) is the leading multistakeholder organization for
industry, academic, and healthcare systems advocating for global adoption of digital pathology
now entering its third decade. The DPA applauds FDA for its continued discussions on AIenabled medical devices through the release of this discussion paper.

We would like to thank FDA for the opportunity to comment on this important topic. Should the
agency have questions on the feedback provided, we welcome the opportunity to provide
additional information.

Sincerely,

John Groth
John Groth (Oct 19, 2026 17:45:22 CDT)

John Groth, MD
Chair Regulatory & Standards Task Force
Digital Pathology Association
Email: john.groth@endeavorhealth.org
Phone: 1 (224) 656-0294

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 1 of 31
 Abbreviations and Defined Terms

AI Artificial Intelligence
API Application Programming Interface
CAP College of American Pathologists
CDRH Center for Devices and Radiological Health
CLIA Clinical Laboratory Improvement Amendments
CP Computational Pathology
DHAC Digital Health Advisory Committee
DPA Digital Pathology Association
FDA U.S. Food and Drug Administration
FM Foundation Model
GAN Generative Adversarial Network
GenAI Generative AI
H&E Hematoxylin and Eosin
HCP Health Care Provider
IHC Immunohistochemistry
IMDRF International Medical Device Regulators Forum
LLM Large Language Model
MAF Model Device Master File
ML Machine Learning
OTS Off-the-Shelf
PCCP Predetermined Change Control Plan
QMSR Quality Management System Regulation
R&STF Regulatory & Standards Task Force
SaMD Software as a Medical Device

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 2 of 31
 SOUP Software of Unknown Provenance
VAE Variational Autoencoder
WSI Whole Slide Image

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 3 of 31
 Digital Pathology Association

INTRODUCTION AND SUMMARY
The Digital Pathology Association (DPA) appreciates the opportunity to comment on CDRH's
discussion paper, Considerations for the Regulation of Generative AI-Enabled Medical Devices
(Docket FDA-2026-N-7874). The DPA represents pathologists, laboratory professionals,
scientists, device manufacturers, and technology developers working to advance digital and
computational pathology (CP), including CP technologies that use foundation models (FMs) and
generative AI (GenAI). These comments were developed by the DPA Foundation
Model/Generative AI Subcommittee (DPA FM/GenAI Subcommittee).
The DPA supports CDRH's decision to engage stakeholders at the discussion-paper stage, and
supports several of the paper's central choices: a risk-based framework that considers what a
device does and the consequence of error, evaluation of the final user-facing device as
configured for real-world use, recognition that a prospective clinical study is not required in
every case, a total product lifecycle approach that would accept greater premarket uncertainty
through greater reliance on postmarket monitoring where that monitoring can resolve specific,
identified uncertainties, and a voluntary Foundation Model Device Master File (MAF) program.
While DPA supports the framework for risk of GenAI-enabled software functions, DPA
proposes a three-axis framework by decomposing the horizontal activity axis in the two-axis
framework from the discussion paper into device output and level of oversight as two separate
axes (refer to DPA response to Q1). In addition, the DPA does not support the competency-based
approach to premarket evaluation, for the reasons given in our responses to Q7 and other related
questions.
Our comments focus on how these concepts apply to CP. Our principal recommendations are:
• Clarify scope and definitions. State that the paper's risk framework and evaluation
approach presume outputs presented to an end user, and address GenAI-enabled devices
that are not end-user-facing. In addition to separate definitions of “foundation model” and
“generative AI”, state explicitly that neither implies the other, so that non-generative, FMbased devices are clearly addressed.
• Keep risk proportionate to autonomy and actual harm. Separate what a device outputs
from how much human oversight applies, using three axes (device output, level of
oversight, and consequence) aligned with IMDRF N81, and treat other factors as defined
modifiers. In a pathologist-facing GenAI-enabled CP device, its output that a pathologist
reviews and signs out is an informational output with the pathologist in the loop and
supervised; non-autonomous CP tools should not be over-classified.
• Evaluate devices on device evidence, not clinician-style competency. Keep
benchmarking and clinical confirmation as ordinary device evidence, drop the credentialing
framing, and do not cap device performance at human performance.
• Let evidence expectations follow device behavior. Route evidence by output space,
verifiability, and model control rather than by architecture labels, and recognize that CP's
established ground-truth-based validation can presumptively satisfy clinical confirmation
for many use cases.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 4 of 31
 Digital Pathology Association

• Anchor third-party FM/GenAI controls in existing mechanisms. Use the off-the-shelf
(OTS) software guidance, IEC 62304 software of unknown provenance (SOUP) processes,
and QMSR/ISO 13485 purchasing controls, keep the Foundation Model MAF voluntary,
and recognize that locally held, version-pinned models carry no developer-initiated change
burden.
• Define roles across the AI supply chain. Distinguish the foundation model developer, the
harness developer, and the device manufacturer, with responsibility following control and
clinical claims.

2. GENERAL COMMENTS

G1. Scope clarification: devices that are not end-user-facing, and foundation models versus
generative AI

The DPA asks CDRH to clarify the scope of the discussion paper in two respects.
Gap 1: GenAI-enabled devices that are not end-user-facing. The paper's risk framework,
benchmarking elements, and clinical confirmation approaches presume an output presented to an
end user that informs, directs, or acts. Some GenAI-enabled devices do not work this way. In CP,
potential examples include a whole slide imaging scanner that uses a generative model to remove
stitching or focus artifacts, software that converts H&E images into synthetic
immunohistochemistry (IHC) images, and generative encoders used within a device pipeline
rather than to produce content for a user. For these functions, the relevant questions are the
fidelity of the generated data and its effect on downstream device functions, which can often be
evaluated against a reference, such as an actual IHC stain on a consecutive section. IMDRF N81
similarly recognizes that the destination of a software output may be a medical device rather than
a human user. The DPA recommends that CDRH state that the paper's approaches are directed at
end-user-facing GenAI functions and describe how GenAI functions that are not end-user-facing
should be evaluated.
Gap 2: A foundation model is not necessarily generative. A large share of CP devices under
development use a pathology FM as a feature extractor: the FM converts a whole slide image
(WSI) into numerical representations, and a task-specific component (for example, a classifier,
regression model, or segmentation decoder) trained by the manufacturer produces a bounded
output such as a category, score, or mask. These devices are FM-based but not generative. When
the FM weights are frozen and version-pinned, the complete pipeline is deterministic for a given
input and fits the established locked-algorithm paradigm. On the other hand, some generative AI
models are not foundation models, such as traditional Generative Adversarial Networks (GANs),
task-specific Variational Autoencoders (VAEs) and narrow rule-based or procedural generators,
etc.
The discussion paper introduces FM-specific concepts, including definitions, benchmarking
considerations, and the voluntary Foundation Model MAF, but scopes them to generative AIenabled devices. The January 2025 draft guidance on AI-enabled device software functions
addresses pre-trained models only generically. As a result, non-generative FM-based devices are
not clearly addressed by either document.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 5 of 31
 Digital Pathology Association

The paper's own reasoning supports distinguishing these devices. Section II describes GenAIenabled devices as ones that “may accept open-ended inputs, perform multiple subtasks, and
produce variable outputs to similar inputs,” and that may evolve over time. A frozen FM feature
extractor with a bounded output has none of these characteristics. Section V recognizes that
evaluation approaches “developed for software with bounded inputs and fixed outputs may not
be appropriate for GenAI-enabled devices”; the converse should also hold, so that those
established approaches remain appropriate for devices that do have bounded inputs and fixed
outputs. And, as Section III notes, FDA “does not regulate GenAI as such; it regulates medical
devices.” However, the Section III definition of a foundation model lists “text synthesis, image
manipulation, and audio generation” as typical tasks, which may lead reviewers and users to
assume that every FM-based device is generative. The Executive Summary for the November
2024 DHAC meeting, which the paper references, similarly states that “GenAI models that can
be broadly applied to multiple tasks are often referred to as foundation models” which could be
mis-interpreted that all foundation models are GenAI models.
As such, the DPA recommends that CDRH:
• State whether and how the discussion paper's FM-related concepts (unit of evaluation,
benchmarking, third-party change management, and the Foundation Model MAF) apply to
non-generative FM-based devices.
• Treat “foundation model” and “generative AI” as separate dimensions. Define a
foundation model by how the model is developed and for what purpose: broad pretraining
for general use, without a specific medical device intended use. Define generative AI by its
output: content that is generated or synthesized and may vary. State explicitly that neither
term implies the other. A foundation model pretrained with a generative or self-supervised
objective but deployed only to produce embeddings for a downstream classifier performs a
non-generative device function. Generativity should be assessed on the output exposed to
the user and the intended use, not on the architecture or training objective.
• Distinguish locally held, version-pinned weights from externally hosted, API-accessed
models. This is a separate dimension from generative versus non-generative, and it drives
the third-party change-management concerns described in Section VI.
• Confirm that, consistent with the Multiple Function Device Products guidance referenced
in Section III, when a CP product combines a GenAI-enabled function (for example, draft
report text) with non-generative functions (for example, a validated classifier), the
approaches in the paper apply to the GenAI-enabled function and the other non-generative
functions continue to be evaluated under existing AI/ML approaches.

G2. Roles and responsibilities across the AI supply chain

The discussion paper identifies the challenges created when a device is built on a model
developed by another party, and Section VI.B recognizes a broader ecosystem of clinicians,
institutions, and others with roles in deployment and monitoring. It does not, however, define the
participants in the AI supply chain, the layer between the model and the finished device, or how
responsibilities divide between those who build a device and those who use it. The DPA
recommends that CDRH define these roles, and that it does so using existing regulatory roles

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 6 of 31
 Digital Pathology Association

wherever possible rather than creating new ones. Responsibility should follow control and
clinical claims, and no single participant should bear responsibility for risks it cannot see or
control.
Roles in developing the device. FDA already defines responsibilities for the parties that design
and make a device, including the manufacturer, the specification developer (who develops the
specifications for a device manufactured by a second party and remains the manufacturer of
record for design controls and complaints), and the contract manufacturer (who makes a finished
device to another party's specifications) under 21 CFR Part 807, the submission sponsor, and
component suppliers, whose products are outside the scope of the QMSR (21 CFR 820.1) and
are controlled through the manufacturer's purchasing controls. The DPA recommends that
CDRH clarify how the AI supply chain maps to these existing roles:
• Model developers: upstream developers pre-train, develop, and release the base
FM/GenAI model while downstream developers perform adaptations and fine-tuning to
achieve more specific functions. In most cases the upstream model developer is a supplier
of a software component rather than a device manufacturer, and its model is controlled
through the device manufacturer's purchasing and OTS/SOUP processes. A model
developer’s responsibility encompasses what it declares about the model (identity and
version, training provenance and breadth, known limitations, update cadence, and changenotification commitments), for honoring any notification commitments it makes, and,
where it chooses to participate, for the content of a FM/GenAI MAF.
• Harness developer: builds the application and control layer that turns an FM/GenAI
model into a finished device function, including adaptation (task-specific heads, adapters,
fine-tuning, calibration) and controls (input validation and preprocessing, out-ofdistribution rejection, scope and refusal logic, prompts and templates, thresholds, output
structuring, and defer-to-human logic). The harness developer is usually the device
manufacturer. Where it is a separate party, it functions as a contract manufacturer or
specification developer, and existing roles should apply.
• Device manufacturer and sponsor: responsible for the safety and effectiveness of the
finished device, including risks introduced by the FM/GenAI and uncertainty arising from
unavailable upstream information. This includes component selection, integration,
verification and validation, risk management, labeling, change control, and postmarket
monitoring. The manufacturer must also give end users the information they need to use
and oversee the device: intended use, validation evidence, known limitations, performance
boundaries, failure modes, and notice of changes.
Roles in using the device. For CP devices, the users work within an established regulatory
structure: laboratories operate under CLIA, typically with accreditation, and pathologists practice
under medical licensure and board certification. Similar principles of roles apply to other medical
devices in their real-world use. The DPA recommends that CDRH recognize these roles and state
explicitly what each can reasonably be expected to do:
• Deploying institution and laboratory: decide whether to adopt a device. Verify, before
clinical use, that it performs as intended in the local environment, with local scanners,
stains, and workflows. Maintain ongoing device quality control and report problems. These
activities should be defined clearly and limited to what can reasonably be performed in a

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 7 of 31
 Digital Pathology Association

clinical laboratory. Laboratories should not be expected to validate the underlying
FM/GenAI, assess inaccessible training data, or audit internal model mechanisms.
• Pathologist: interprets the device output in the context of the case, recognizes apparent
errors, follows the instructions for use, and remains responsible for the diagnosis when in
the loop. Pathologist review is meaningful oversight only when the pathologist has enough
information to independently assess, challenge, and override the output. Responsibility for
quality control cannot exceed the ability to perform it, and a sign-out step should not
transfer responsibility to the pathologist for outputs that cannot be verified, for undisclosed
model behavior, or for changes to the model that the pathologist was not told about.
• Treating clinician: acts on the pathology report in making patient management decisions,
and shares responsibility for those decisions.
Mapping the supply chain to existing roles clarifies accountability without diluting it, avoids the
need for new regulatory categories, and complements our recommendations on third-party
FMs/GenAIs in our responses to Q24 and Q25. With foreseeable more postmarket monitoring of
GenAI-enabled devices, DPA anticipates that device manufacturer will also play a critical role in
using the device, to ensure the continued safety and effectiveness.

3. RESPONSES TO FDA DISCUSSION QUESTIONS

Question 1 (Discussion Paper §IV.A)

FDA question: 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.
DPA response:
The two-axis framework is a useful starting point, but its activity axis combines two different
things: what the device outputs, and how much human oversight applies before the output takes
effect. Figure 1 places oversight only on action-taking functions (“HCP-Supervised” and “Fully
Autonomous”), although oversight matters equally for informational outputs, and “HCPsupervised” does not distinguish a professional who makes the final decision from one who only
monitors. The DPA recommends a three-axis framework, with other factors treated as defined
modifiers. This structure draws on IMDRF/SaMD WG/N81 FINAL:2025, Characterization
Considerations for Medical Device Software and Software-Specific Risk. N81 which
characterizes medical device software by features that include output type, degree of autonomy,
intended user, explainability, and destination of the output, and it encourages jurisdictions to
incorporate its harmonized language into their guidance. The DPA recommends that CDRH use
N81's features and terms wherever possible, both for international harmonization and to help
ensure that supervised, non-autonomous CP devices are not over-classified. The correspondence
is noted for each element below.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 8 of 31
 Digital Pathology Association

• Axis 1, device output. Informational and non-directive; informational and action-directing;
or action-taking, where the device itself makes the final decision. Measurement and in vitro
diagnostic outputs, which N81 describes as “data for use in medical purpose,” are
informational and non-directive on this axis; whether the user can verify them should be
addressed as a modifier. N81's output types (clinical interpretation or intervention,
workflow recommendation, and data for use in medical purposes) can further describe the
output at each point on this axis.
• Axis 2, level of oversight. This axis corresponds to N81's degree of autonomy, and the
DPA recommends using its four levels. Non-autonomous (HCP in the loop): the output is
considered by a professional who can assess it, and reach a different conclusion, in making
the final decision. Supervised (HCP on the loop): the output takes effect without a
professional having to approve it, but a professional supervises and can intervene, override,
or stop the device function. Conditionally autonomous: the output takes effect without
review only for some results or circumstances; in CP, for example, software that finalizes
cases that it classifies as negative and refers all others to a pathologist. Autonomous: the
output takes effect with no review and no opportunity to intervene beforehand. Risk, and
the evidence needed, increase from non-autonomous to autonomous; in particular,
supervised devices carry higher risk than non-autonomous devices.
• Axis 3, consequence. The severity of harm from relying on an incorrect output, as CDRH
describes.
Modifiers, including those CDRH lists in Question 1, can be grouped into three categories:
• Clinical setting: reversibility of the resulting action, availability of downstream safeguards
such as a required confirmatory test, and time pressure. These relate to N81's context-ofuse features, including the intended use environment and the timing of the output within the
healthcare task.
• Output use: verifiability of the output by the intended user, which corresponds to N81's
explainability feature (logic and output explained and evaluable, partially evaluable, or not
evaluable); the expertise of the intended user, using N81's intended-user categories, which
list pathologists among specialist physicians (see Q4); and the declared recipient (HCP or
patient), consistent with N81's destination-of-output feature. Patient review should count as
oversight only where the output is within lay competence and the patient is a declared
recipient (see Q3).
• Lifecycle configuration: stability and control of the deployed model (for example, a
locally held, version-pinned model versus an API-accessed model subject to unannounced
change), which relates to N81's change-management features; propagation of the output to
downstream device functions, which relates to N81's role of the software and output within
the healthcare task; and exposure scale, such as population-level use versus use in a rare
disease, which relates to N81's domain of change implementation.
Like the benchmarking elements, this framework presumes an output presented to an end user; as
noted in General Comment G1, it should be adapted for GenAI functions that are not end-userfacing. Applied to CP, the DPA highlights the following:
• Who makes the final decision. Section IV gives “the affirmative assignment of a clinical
diagnosis” as an example of an action-taking function. In CP, many devices propose a
finding, such as a tumor region, grade, or suspected diagnosis, that becomes part of a
diagnosis only after a pathologist reviews the slide and signs out the report. Such outputs

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 9 of 31
 Digital Pathology Association

are informational outputs with an HCP in the loop, provided the pathologist can
meaningfully evaluate and override them. The DPA recommends that CDRH clarify that
such outputs are informational functions, and that a function is action-taking only when the
device itself finalizes, releases, or orders something.
• Verifiability and downstream confirmation, including for in vitro diagnostic and
measurement functions. Section IV suggests that in vitro diagnostic, measurement, and
signal processing functions may migrate higher on the consequences axis because the user
typically cannot independently evaluate the basis for the output. The DPA agrees that
verifiability matters, and treats it as an output-use modifier alongside FDA's proposed
“traceability” and “downstream safeguards” considerations. However, the adjustment
should depend on the specific output rather than on the function category. Many CP
outputs, such as detected regions, cell counts, or measurements, can be checked directly by
a pathologist against the slide. Others, such as prediction of a molecular alteration from
H&E morphology, cannot be checked visually but are paired with a required confirmatory
assay and validated against an objective reference standard. We recommend that an upward
adjustment apply where an output can neither be verified by the qualified user nor
confirmed by a required downstream test, and that verification and confirmation safeguards
be evaluated directly rather than assumed.
• Autonomy. Autonomous operation warrants the highest risk position on the oversight axis.
The DPA recommends that the level of oversight be declared explicitly in each submission,
including whether any step can occur without an opportunity for qualified human review
(see Q26).
Reversibility and time pressure are relevant in CP mainly through workflow design. For
example, a prioritization function that cannot cancel or delay confirmatory testing beyond a
clinically established turnaround time is largely reversible by design. We recommend that these
be addressed as clinical-setting modifiers rather than as separate axes.
Lifecycle configuration also matters. A model that can change outside the sponsor's control, such
as one accessed through an API, can raise risk because the device in clinical use may no longer
be the device that was evaluated due to the silent modifications to the underlying model accessed
through API. The same descriptors, together with whether the output is bounded or open-ended,
also determine the method and intensity of evidence and change control needed, as described in
our response to Q8. These modifiers do not lower the risk of a high-consequence device: a
frozen, bounded, highly verifiable device used for a high-consequence decision remains a higherrisk device.

Question 2 (Discussion Paper §IV.A)

FDA question: 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?

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 10 of 31
 Digital Pathology Association

DPA response:
The DPA agrees that directiveness is a continuum rather than a binary, and that the substance
and context of an output matter more than the presence of particular words. A disclaimer does
not by itself make an action-directing output less directive. For the same reason, labeling alone
should not be relied on to reduce directiveness; workflow design that changes what the output
can do, such as a requirement that confirmatory testing always occurs, is a more meaningful
modifier. In CP, the DPA suggests CDRH consider the following characteristics as modifiers,
assessed after accounting for intended use:
• Output form: a region highlight, measurement, or quantitative readout for pathologist
review is less directive than a categorical recommendation (for example, “test” or “do not
test”), which is less directive than free text that proposes a diagnosis or next action.
• Specificity and apparent certainty: outputs that present a single conclusion without
uncertainty information are more directive than outputs that communicate confidence,
indeterminate results, or conditions outside the validated intended use.
• Proximity to the final action: whether the output enters a report, a worklist, or an order
directly, or requires an independent professional step first.
• Workflow constraints: whether, for example, a prioritization result can only reorder work
or can also remove a case from confirmatory testing, together with interface controls that
distinguish a prioritization score from a confirmed test result.
To make placement along the continuum predictable, the DPA recommends that future FDA
guidance provide a boundary test for when an informational output moves from non-directive to
action-directing. The test could ask three questions: whether the output names a specific action;
whether it applies information to the specific patient or specimen; and whether it states what is
generally true or asserts that an action should be taken. Manufacturers could then build the same
test into device guardrails (see Q5).
For predictability, the DPA recommends that sponsors describe these characteristics in a short,
structured statement of device behavior submitted with the premarket submission (for example,
output space: bounded, partially bounded, or open-ended; output variability; and verifiability),
and that CDRH provide worked examples at several points along the continuum. Together with
the boundary test, worked examples will give manufacturers more predictability than a binary
definition.

Question 3 (Discussion Paper §IV.A)

FDA question: 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?

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 11 of 31
 Digital Pathology Association

DPA response:
Most CP devices are intended for use by pathologists and are not patient-facing. Patient
interaction with CP outputs is nevertheless increasingly likely, and in some cases unavoidable.
Patients often receive pathology reports through patient portals at the same time as, or before,
their clinicians; GenAI tools, whether or not they are devices, can let patients query their own
reports; and patients may in future have access to underlying data such as whole slide images.
The DPA agrees that patient-facing delivery can present different risks when the recipient cannot
independently evaluate the output. In the framework we propose in Q1, the recipient is a
declared output-use modifier, and patient review counts as oversight only where the output is
within lay competence and patients are a declared recipient. This is preferable to a blanket
elevation of all patient-facing functions.
Because one product can have several GenAI functions with different intended users, the
recipient should be declared, and risk assessed, for each function. For example, a CP system may
provide a final result that appears in the report, which patients may see, and a chat feature whose
responses go only to the pathologist.
Where patients are intended recipients, useful safeguards include plain-language explanation of
what a result does and does not mean, clear distinction between screening, prioritization, or
prediction outputs and confirmed diagnoses, explicit communication of uncertainty and
limitations, and direction to the treating clinician for interpretation. Manufacturers should state
clearly in labeling whether patients are an intended audience for each intended use output and
should evaluate outputs intended for patients for that specific intended use output. Where an
output is labeled for professional use only, the manufacturer generally does not control how a
healthcare facility configures its electronic health record or patient portal. In that case, the HCPs
and healthcare facilities that choose to share patient records containing AI outputs not intended
for patients should accept responsibility for that decision, consistent with the role of the
deploying institution described in General Comment G2.

Question 4 (Discussion Paper §IV.A)

FDA question: 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?
DPA response:
The DPA's primary position is that the pathologist is the specialist. Tissue diagnosis is the
pathologist's specialty, and CP devices are intended for use by board-certified pathologists who
have specialty-level training in exactly the domain the device addresses. Under the reasoning in
Section IV, this should lower, not raise, the risk of these devices. The pathologist is the best
equipped HCP to interpret a CP output in the context of the slide and the case, to recognize its
limitations, and to identify and decline to rely on an incorrect output. The risk concern CDRH
describes that a generalist receiving information that depends on specialist contextualization,
generally does not arise when the intended user is a pathologist. IMDRF N81 likewise

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 12 of 31
 Digital Pathology Association

distinguishes specialist physicians, including pathologists, from general practitioners in
characterizing the intended user of medical device software. The DPA recommends that CDRH
recognize specialist intended users as a factor that reduces and/or mitigates risk, both as an
output-use modifier in the risk framework (see Q1) and in determining the evidence needed.
Second, the DPA recommends that pathologists be treated as a single qualified user group for
risk assessment and clinical study design, rather than divided by subspecialty. American Board
of Pathology certification establishes a common baseline of competence in anatomic pathology,
and CLIA requirements govern laboratory personnel qualifications and quality systems. Within
that framework, laboratories and medical staff already determine case assignment, consultation,
and credentialing for subspecialty work. Requiring subspecialty-specific user groups would
multiply the size and complexity of reader studies without a corresponding reduction in risk and
could delay access to tools that support general pathologists who cover multiple subspecialties.
Where a device's intended use is restricted to a particular setting or user qualification, this should
be stated in labeling and supported by the validation population.
The generalist versus specialist distinction becomes relevant for CP where pathology-derived
information is delivered directly to a non-pathologist clinician. In that case, safeguards such as
clear communication of what the output means and its limits apply, as described in our response
to Q3.

Question 5 (Discussion Paper §IV.A)

FDA question: For multi-turn conversational GenAI-enabled devices that may migrate from
providing “non-directive” 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?
DPA response:
Conversational interfaces are emerging in CP, for example, assistants that let a pathologist ask
questions about a WSI or retrieve similar cases. The DPA recommends that, for these devices,
intended use be characterized by the envelope of permitted outputs that the control layer
enforces, not by the behavior of an individual exchange. The manufacturer should define inscope and out-of-scope requests, the boundary between non-directive and directive and refusal
logic that keeps outputs within the envelope, and the deferral behavior when a conversation
moves toward action-directing content outside the intended use.
Evaluation should then test whether the device stays within that envelope across realistic and
adversarial trajectories, using structured probe suites, boundary and refusal testing, and redteaming, supported by postmarket monitoring. Because exhaustive testing of open-ended
conversation is not achievable, the evidence should focus on the reliability of the controls rather
than enumeration of trajectories.
The DPA recommends that CDRH specify the boundary test described in our response to Q2 in
future guidance, so that manufacturers can build it into the output envelope as a guardrail:
identifying user requests that would move the device from non-directive to action-directing

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 13 of 31
 Digital Pathology Association

output, and declining or redirecting them where they fall outside the intended use. Evaluation
should include testing against that boundary.

Question 6 (Discussion Paper §IV.A)

FDA question: 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?
DPA response:
The DPA agrees that the two error directions are generally not commensurable and recommends
that manufacturers characterize them separately, with acceptance criteria justified for the clinical
context. CP has a close analogue in triage and prioritization functions, such as worklist
prioritization or prioritization of confirmatory molecular testing.
In CP, the most effective way to manage under-prioritization is often workflow design rather
than a single trade-off threshold. For example, a device that prioritizes confirmatory testing can
be designed so that a low-priority or negative result never cancels testing or delays it beyond a
clinically established turnaround time, and so that invalid or indeterminate results return the case
to the standard pathway. In that design, the harm from under-prioritization is bounded delay, and
the harm from over-prioritization is primarily workload. Manufacturers should evaluate these
safeguards directly (for example, measuring prioritization errors, invalid results, and turnaroundtime effects) rather than assuming that pathologist involvement will detect errors.
The same two-directional view applies to benchmarking element S.1 (safety-critical recognition
and escalation) for CP. The closest analogue is flagging of unexpected or urgent findings, such
as an unsuspected malignancy on a case prioritized as routine, where both missed flags and
excessive flagging (which drives alert fatigue) are relevant failures.
The same considerations apply to de-escalation. In CP, de-escalation includes lowering a case's
priority, indicating that a case does not need expedited review or ancillary testing, or
downgrading a previously flagged finding. An incorrect de-escalation has the same effect as
under-escalation and can be harder to detect, because it removes a case from attention.
Manufacturers should characterize de-escalation errors separately and apply the same workflow
safeguards; for example, a de-escalated case should still receive any required confirmatory
testing.

Question 7 (Discussion Paper §V.E)

FDA question: Is the competency-based approach described above, i.e., device benchmarking
followed by clinical confirmation, a useful and appropriate framework for evaluating GenAIenabled devices?
DPA response:
No. The DPA does not support the competency-based approach as framed in the discussion
paper, for three reasons:

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 14 of 31
 Digital Pathology Association

• Accountability. The approach is modeled on how human clinicians are evaluated and
credentialed, but credentialing works in part because clinicians face professional, legal, and
reputational consequences when they fall short, a point the paper itself notes in citing
Freyer et al., devices face none of these. Device regulation instead relies on prespecified
evidence, design controls, and postmarket obligations, and the evaluation framework
should rest on those mechanisms rather than on an analogy to clinician licensure.
• The elements are already device evidence. Benchmark testing and clinical confirmation
are already well accepted under the existing framework for AI-enabled devices. The paper
does not define “competency,” and the methods it describes, including benchmarking,
prespecified acceptance criteria, independent adjudication, and clinical confirmation, do
not depend on it. The label of “competency-based” adds ambiguity without adding a
distinct evidentiary element.
• Human performance should not be the ceiling. A competency-based framing invites
comparison to human capability. Some CP functions, such as quantitative image analysis,
prediction of molecular status from H&E morphology, and integration of multimodal data,
may exceed what a human reader can do. These should be evaluated against the best
available reference standard, not against human competency (see Q14 and Q15).
The DPA recommends that CDRH drop the competency and credentialing framing and describe
the same two-step structure, non-clinical benchmark testing followed by clinical confirmation, as
device evidence under the existing framework, supported by benchmarks with demonstrated
construct validity (see Q10). Under that structure, the object of review should be what the device
manufacturer controls: the adaptation and fine-tuning layers, the control layer, and the finished
device, with the underlying FM/GenAI addressed through third-party component controls (see
Q24 and Q25) rather than evaluated on its own. The objective should be to demonstrate that the
final user-facing device is fit for its intended use through valid, clinically meaningful, and
generalizable evidence.
If CDRH retains the term, it should define “competency” precisely and in measurable terms and
explain how competency differs from existing concepts such as validation, generalizability, and
reasonable assurance of safety and effectiveness. The DPA does support evaluating “the final
user-facing device, as configured and intended to be deployed for real-world use,” rather than the
FM/GenAI alone, which matches how CP devices are developed and validated.
Whatever framing CDRH adopts, the DPA recommends that it clarify four points. First, whether
the approach applies to non-generative FM-based devices and to GenAI functions that are not
end-user-facing (see General Comment G1). Section V introduces the approach because testing
methods developed for software with bounded inputs and fixed outputs may not be practical for
GenAI; for devices that do have bounded inputs and fixed outputs, those established methods
should remain available and presumptively sufficient. Second, how the unit of evaluation in
Section V.A (the final user-facing device) relates to Section III, which states that the paper
addresses the GenAI-enabled component of a broader device but not the entire device. The DPA
supports evaluating the final device as configured. Third, benchmarking elements designed for
conversational GenAI, such as communication, apply only where the device has those functions;
many CP devices are image-based and non-conversational (see Q9). Fourth, where a human
comparator is used, the framework should not cap device performance at human performance.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 15 of 31
 Digital Pathology Association

Question 8 (Discussion Paper §V.E)

FDA question: How might the two-axis risk framework described in Section IV be considered
within the competency-based approach described above to help determine the level of evidence
needed for a premarket submission?
DPA response:
Although the DPA does not support the competency-based framing (see Q7), the risk framework
should inform the level of evidence in two steps. First, the DPA's position on the three axes we
propose in Q1 (device output, level of oversight, and consequence), with its modifiers, should
determine how much evidence and postmarket monitoring the device requires. Second, two
behavior and control descriptors should determine which evidence methods and what intensity of
change control apply to the model-behavior component:
• Frozen, bounded, and verifiable: benchmarking against prespecified thresholds on
representative data, followed by clinical confirmation, with precision and repeatability
characterization and standard change control.
• Mutable (configuration can change outside the sponsor's control), bounded, and
verifiable: as above, plus version pinning where possible, change notification, performance
degradation monitoring, and reassessment after defined triggering events.
• Frozen, open-ended or hard to verify: rubric-based adjudication grounded in clinical
guidelines or qualified expert input, scope and boundary adherence, refusal and deferral
testing, uncertainty communication, and automation-bias safeguards.
• Mutable and open-ended: all of the above, plus adversarial testing, control-layer scrutiny,
and greater reliance on postmarket monitoring.
The second step does not lower the risk level set in the first step. Its purpose is to make evidence
expectations predictable and based on device behavior rather than labels such as “generative,”
“foundation,” or “LLM.” A short, sponsor-attested statement of these attributes in the submission
would let reviewers apply it consistently.

Question 9 (Discussion Paper §V.E)

FDA question: 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?
DPA response:
The structure is a useful menu, and the DPA supports CDRH's statement that elements would be
chosen based on the device's intended use and risk profile. However, the descriptions in
Appendix A are written largely for conversational devices (for example, multi-turn encounters,
paraphrase consistency, dialects, and health literacy). The DPA asks CDRH to state directly how
the elements apply to non-conversational, image-based devices, and suggests the following
mapping for CP:

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 16 of 31
 Digital Pathology Association

• Generally applicable: S.2 (scope maintenance), as rejection of inputs outside the intended
use, such as an unsupported stain, tissue type, or scanner, or an out-of-distribution image;
S.3 (calibration and deferral), as calibrated scores and indeterminate or invalid results that
return the case to the standard pathway; E.1 (task fidelity); E.3 (quantitative and
measurement analysis), for counts, percentages, areas, and other measurements; R.1; and
R.2.
• Applicable only where the device has the corresponding function: S.1 (escalation), E.2
(multi-turn information gathering), and E.4 (communication quality), except that the
automation-bias and user-comprehension aspects of E.4 remain relevant to how any CP
output is displayed.
R.1 and R.2 are the most important elements for CP and would benefit from pathology-specific
content. The DPA recommends that CDRH describe the following as examples:
• R.1 (robustness, reliability, and reproducibility): cross-scanner and cross-stain testing,
including stain variability across laboratories and protocols; cross-site testing with external
sites not used in development; robustness to common artifacts (for example, folds, blur,
pen marks, and tissue processing variation); sensitivity to preprocessing choices such as
tiling and color normalization; and repeatability and reproducibility across runs and
supported runtime environments.
• R.2 (subgroup performance): prespecified analysis across clinically relevant patient
subgroups and across specimen and disease subgroups, such as biopsy versus resection,
tumor subtype, and rare histologies, with justified sample sizes and without treating lack of
statistical significance as equivalence. For image-based devices, the dialect, accent, and
literacy considerations in R.2 do not apply.
The DPA suggests adding additional elements to the benchmarking framework:
• Verifiability and traceability, meaning whether an output can be traced to the source
region of the slide and independently reproduced, which determines whether a reference
comparison is available at all.
• Fidelity of generated content, where the output is itself the clinical data, as with virtual
staining: faithfulness to the underlying tissue, equivalence to a reference acquisition
where one exists, and detection of fabricated or erased structure.
Two elements are mis-categorized. E.4 (communication quality) is not a clinical proficiency but
a human factors property for which this paper links to automation bias, which IEC 62366-1
addresses. S.3 mixes a statistical property with a workflow behavior, since calibration can be
measured objectively while deferral is judged. In addition, E.1 and E.2 also overlap for bounded
devices and S.1 and S.3 both route to a human, so the framework should state which element
governs which failure.
• The DPA recommends building the benchmarking framework by leveraging existing
standards and guidance for generative AI, such as ISO/IEC 42001 for AI management
systems; IEC 62366-1 for usability engineering, which is directly relevant to E.4 and to
automation bias; ISO 14971 for medical device risk management with ISO/IEC 23894
which provides AI specific risk guidance; NIST AI 100-1, AI Risk Management
Framework 1.0, NIST AI 600-1 Generative AI Profile, NIST AI 100-4, Reducing Risks

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 17 of 31
 Digital Pathology Association

Posed by Synthetic Content and NIST SP 800-218A Secure software development
community profile for generative AI and dual use foundation models.

Question 10 (Discussion Paper §V.E)

FDA question: CDRH recognizes that publicly available benchmarking assets may be subject to
data contamination, saturation, and limited real-world representativeness. How should a
sponsor establish that performance on a given benchmark predicts safe and effective real-world
behavior for the device’s intended use? What evidence should support the construct validity of a
benchmark used to gate device evaluation, and what role should sponsor-developed benchmarks
play given potential concerns around independence and optimization to the test?
DPA response:
The three concerns CDRH identifies, contamination, saturation, and limited representativeness,
are all present in CP. Pathology FMs/GenAIs are frequently pretrained on large public WSI
collections, the same sources from which most public pathology benchmarks are drawn. Many
public benchmarks measure general tasks, such as tissue-type classification, on which leading
models already score near the ceiling. And few public datasets reflect a specific device's intended
use population, specimen types, scanners, and staining protocols. For these reasons, the DPA
recommends that public benchmarks be used to characterize the capabilities of a foundation
model, and that the benchmark used to gate evaluation of the device be one matched to the
device's intended use, which in CP will usually be sponsor-developed.
Establishing that benchmark performance predicts real-world behavior. A sponsor should
show that the benchmark reflects the conditions under which the device will be used, and then
confirm that relationship with clinical data:
• Representativeness: the benchmark should match the intended use population and
deployment conditions, including case mix and prevalence, specimen types, sites, scanners,
staining protocols, and the expected range of image quality and artifacts, with the basis for
this documented.
• Difficulty and discrimination: the benchmark should include clinically difficult cases,
rare but important presentations, and cases near decision thresholds, so that high overall
scores do not hide the failures that matter. Where a benchmark is saturated, such
discriminating power should be reported, not only accuracy, since a high score may not be
the evidence when the benchmark can no longer separate good from poor performance.
• Confirmation: performance in clinical confirmation (Section V.C), for example in a
retrospective multi-site study or shadow deployment, should be consistent with benchmark
performance. A material gap between the two indicates that the benchmark does not predict
real-world behavior.
Evidence of construct validity. For a benchmark used to gate device evaluation, the sponsor
should show that it measures the clinical property the device claims. In CP, the strongest
evidence is a reference standard that directly measures the target, such as a molecular assay for a
mutation prediction or outcomes for a prognostic claim. Where the reference is expert consensus,
the sponsor should document reader qualifications, labeling criteria grounded in clinical

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 18 of 31
 Digital Pathology Association

guidelines, and inter-reader agreement. The sponsor should also show that benchmark labels and
scoring are defined the same way the device output will be used clinically.
The role of sponsor-developed benchmarks. The DPA supports CDRH's recognition in
Section V.B that sponsors may propose their own tests and datasets. For most CP devices, a
sponsor-developed benchmark is the only way to match the intended use. Concerns about
independence and optimization to the test can be addressed through design controls rather than
by requiring third-party benchmarks:
• Prespecification of the test protocol, analysis plan, and acceptance criteria before the test
set is used.
• Sequestration of the test set, with access controls, so that it is not used for FM/GenAI
selection, model training, tuning, or threshold selection, and a documented limit on how
many times it is used.
• Independence from FM/GenAI pretraining data, through temporal separation (specimens
collected after the FM/GenAI version was fixed), exclusion of public datasets known to
have been used in pretraining, and duplicate checks, rather than a general claim of “zero
leakage.” If the use of public datasets is unavoidable, then reporting both what could be
established about contamination and what could not be warranted.
• Where the model or device benchmark assessment requires adjudication, an independent
adjudication by adjudicators independent of the model or device developer, should be
conducted.
• Reference standards established by adjudicators independent of the sponsor and, where
applicable, the FM/GenAI developer, consistent with the paper's general principles.
• Auditable records, so that FDA can confirm the controls were followed.
• When the same party (model developer and/or device developer) builds the model or
device and the gate (benchmark), the gate is not independent evidence. It would be good
practice to utilize separate and independent benchmark teams within the model/device
developer to ensure certain degree of independence. However, when a device is of high risk
based on risk assessment framework, and benchmark assessment of a higher degree of
independence should be conducted.

Question 11 (Discussion Paper §V.E)

FDA question: 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?

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 19 of 31
 Digital Pathology Association

DPA response:
The DPA strongly supports CDRH's position that a prospective clinical study is not required in
every case. For established CP tasks, rigorous ground-truth-based validation already exists and
should presumptively satisfy clinical confirmation. Examples are multi-site concordance and
reproducibility studies against expert pathologist ground truth or an objective reference method,
conducted on retrospectively assembled, representative cohorts. Default prospective study
requirements would add cost and delay without a corresponding reduction in uncertainty for
these devices.
Selection of a confirmation approach
The governing principle is that clinical confirmation resolves the uncertainty that benchmark
cannot and establishes the clinical performance of the device in real or clinically representative
use. The clinical confirmation should be selected by identification of the uncertainty and
choosing the method that resolves it. When such uncertainty is not identified or minimal, the
device developer should consider benchmarking without clinical confirmation.
Prospective studies may be appropriate where the uncertainty to be resolved requires them, for
example, for novel predictive or prognostic claims without an established reference standard,
multimodal devices whose clinical effect depends on workflow integration, or highly
autonomous functions. The sponsor should justify the approach by identifying the specific
uncertainty and the method that resolves it and should state that justification in advance so that
the choice can be prespecified and reviewed.
Applied to the confirmation approaches in Section V.C.1 for CP:
• Retrospective evaluation on real patient inputs against an established reference standard is
the primary and, for established tasks, presumptively sufficient approach. Pathology is well
suited to it because archived slides and blocks allow representative, multi-site cohorts with
confirmed outcomes or ancillary test results.
• Clinician adjudication of real cases, in the blinded form the paper describes, corresponds to
the reader studies commonly used for assistive CP devices, in which pathologists read
cases with and without the device.
• Shadow deployment is feasible in CP, since a device can run on live cases without its
output being shown, and may be useful for workflow and turnaround-time questions.
• Standardized patient interactions generally do not apply to tissue-based devices.
The DPA also notes that prospective specimen collection and prospective study design are
distinct. A retrospectively assembled cohort can include specimens collected after the FM/GenAI
version was fixed, addressing contamination without the burden of a prospective interventional
study. The anticipated distribution of real-world inputs should be addressed through site,
scanner, stain, and specimen-type representativeness in the validation cohort.
Considerations for an approach being insufficient or inappropriate
• When the reference is derived from, or correlate with the device output, or the
contamination cannot be resolved or the model may change, and when the claim is about
clinical effect for which a reference standard or retrospective comparison cannot

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 20 of 31
 Digital Pathology Association

establish, a retrospective assessment against a reference standard is insufficient or
inappropriate, and a prospective evaluation (or a prespecified retrospective assessment)
should be considered.
• When the claim depends on the device output is being acted upon, for example, when
assessing the time to diagnosis for a prioritization function, or the device output is the
clinical data, for example, when assessing a virtual staining function, shadow deployment
may provide little value except for usability and turn-around-time assessment.
• When the harm may arise from real world heterogeneity that a design panel cannot
capture, or tissue-based device with no patient interaction, the standardized patient or
case interaction is insufficient or inappropriate.
• When the claim is prognostic or predictive where the clinical outcome rather than
agreement with experts must be used or an objective reference standard exists, clinical
adjudication is insufficient or inappropriate.
• When the study is powered around a surrogate rather than the clinical claim, or for a lowrisk informational device, a prospective study is insufficient or inappropriate.
The anticipated distribution of real-world inputs should be handled as a declared assumption.
The device developer should first set out what inputs the device expects to see in real use: the
mix of cases and how common each condition is, the specimen type, the scanners and stainers,
the sites, and the range of image quality and imperfections. The clinical confirmation study
should then match that expectation, or state where it does not. Where the device is intended for
use at sites, scanners or processes that the confirmation work did not cover, that should be stated
rather than assumed to generalize. Performance should be assessed at the prevalence expected in
practice, because a device that looks accurate in the study where a condition is common will
raise more false alarms when the condition is rare. Cases near the decision threshold (borderline
cases) should be enriched when necessary and feasible, since that is where the false results
concentrate. If real use falls outside what has been declared that should trigger reassessment,
consistent with the postmarket monitoring described in Q19.
Additional methods of clinical confirmation
CDRH has identified the principal approaches to clinical confirmation for devices whose output
reaches an end user, and DPA supports the ladder as described. Our comments are therefore
offered as refinements within the approaches CDRH has set out, together with one observation
about how they are ordered.
Retrospective evaluation on real inputs – additional variants and options include external
validation on an independent cohort; blinded independent adjudication; paired specimen
comparison against a reference acquisition; a contamination audit; enrichment for borderline
cases and rare (histological) subgroups; and prespecified retrospective analysis.
Shadow deployment – additional variants and options include delayed reveal review where the
output is withheld until after the decision and then reviewed; a stated endpoint to pair design to
claim.
Standardized patient interactions – additional variants and options include a structured
examination with trained assessors; unannounced actors in a live channel; simulated users at
scale, as supporting evidence only.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 21 of 31
 Digital Pathology Association

Clinician adjudication of real cases - additional variants and options include an interventional
reader study with and without the device so the clinical performance for clinical and device
together is assessed; blinded review to produce an independent reference and unblinded review
of full records to assess appropriateness in context.
Prospective clinical study - additional variants and options include stepped wedge where
individual assignment is impractical; randomized discontinuation to test durability; and follow
up long enough to test persistence.

Question 12 (Discussion Paper §V.E)

FDA question: 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?
DPA response:
No response.

Question 13 (Discussion Paper §V.E)

FDA question: For which clinical domains, device functions, or subpopulations is synthetic data
particularly well-suited, 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?
DPA response:
Synthetic data can help where more cases of the same kind are needed. It cannot help where
more different cases are needed, i.e., synthetic data adds volume, not variety. In pathology,
synthetic data includes generated images such as whole slide images with synthetic stains,
generated report text and referral and consultation letters, patient questions and copilot
conversations, structured clinical and specimen fields, molecular findings, annotations and
labels. Synthetic data is well suited to testing how a system copes with unusual stains, poor
quality slides, or inputs near the edge of what it was built for; to checking that an update did not
break something that worked before; to testing whether confidence tracks accuracy; and to
testing refusal and scope behavior in text. It can also help where a condition is rare but otherwise
ordinary and there are simply not enough real examples. It does not help where the question is
how often a condition occurs, or how often a positive result is correct, because a generator
reproduces what it was trained on. It does not help for the subgroups most at risk, for rare
failures, or for tracking how a device behaves as the mix of cases shifts over time. And generated
labels and generated outcomes are the weakest of all, because they replace the very thing being
measured.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 22 of 31
 Digital Pathology Association

If the cases used to test a device are made by a model of the same kind as the device, the test is
not independent. Both learned from similar data, so they share the same blind spots. The test will
tend to show what the device already does well and to miss what it does badly, which is exactly
the failure the test is meant to find. The bias has a direction: it makes the device look better, and
it does so most in the subgroups where real cases are hardest to find. To ensure independency,
test data should come from a different system, built differently and trained on different data.
Whether the data generated is realistic should be checked against real cases set aside from
development, focused on the areas where problems are suspected. Any claim about a subgroup
should rely on at least some real cases, and where only synthetic data exists for a group, the
finding should be presented as a signal for further study rather than as proof. And the sponsor
should say which way the result is likely to be wrong, not only that a difference exists.

Question 14 (Discussion Paper §V.E)

FDA question: 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?
DPA response:
Where an objective reference standard exists, it should be the comparator, as Section V.D.1
recognizes. The paper cites “a diagnosis confirmed by biopsy” as an example; in pathology, the
histopathologic diagnosis is itself that reference for many other devices. For CP devices, the
reference is typically expert pathologist consensus, ancillary testing such as
immunohistochemistry or molecular assays, or clinical outcomes. Comparison to clinicians in
those cases can understate device capability, particularly where the device performs a task a
human cannot, such as predicting molecular status from H&E morphology. A framework asking
whether the device performs “as well as, or better than, a reference clinician” should not become
a ceiling for such devices.
Where no single ground truth exists, the DPA supports comparison against a panel of qualified
clinicians whose consensus reflects the applicable standard of care, using rubrics grounded in
clinical guidelines. The standard of care, rather than a median clinician, is the appropriate
reference for standalone device performance. For CP, the qualified clinician is a board-certified
pathologist, consistent with our response to Q4. Adjudicators should be structurally independent
from the sponsor and, where applicable, from the FM/GenAI developer.
Human-AI team performance should be the basis for evaluation when the intended use is to
assist a pathologist, as it is for most CP devices. In that design, comparing pathologists reading
with and without the device reflects performance in typical practice. Standalone performance
remains relevant for characterizing the device and for autonomous functions.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 23 of 31
 Digital Pathology Association

Question 15 (Discussion Paper §V.E)

FDA question: 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?
DPA response:
Yes. This is often the most relevant comparator for CP functions that add capability rather than
replace a reader. For example, a device that prioritizes confirmatory testing can be compared to
the standard workflow on turnaround time and missed or delayed cases, and a device that
predicts a biomarker from H&E can be compared to current testing practice, including rates of
testing and time to result. The comparator should be justified by describing current practice in
the intended use setting, and the study should measure the outcomes that the device is claimed to
improve.

Question 16 (Discussion Paper §V.E)

FDA question: 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?
DPA response:
Of the roles listed in Section V.D.2, the DPA sees the most value in independent expert
adjudicators, standards development, and FDA-qualified tools, and supports building on existing
programs such as MDDT and ASCA rather than creating new ones. Maintaining sequestered
datasets and benchmarks can also be useful, provided that use remains optional.
The DPA does not support a third-party determination or certificate becoming a de facto
prerequisite for review. Centralized benchmarks can become saturated or contaminated, may not
represent a device's intended use, and could create bottlenecks or advantage larger organizations.
Sponsors should retain the ability to use sponsor-developed benchmarks with documented
independence controls (see Q10). Safeguards should include transparent qualification criteria,
multiple qualified providers, and no requirement that a sponsor disclose proprietary models or
data to a third party as a condition of review. Professional societies, including the DPA, could
contribute to developing reference datasets and evaluation protocols.

Question 17 (Discussion Paper §V.E)

FDA question: CDRH is exploring whether a competency-based approach could be applied to
devices that incorporate a variety of underlying model architectures, such as multimodal visionlanguage models and generative or predictive world models. Are there aspects of the described

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 24 of 31
 Digital Pathology Association

approach that might be ineffective or inapplicable to these devices? What additional or distinct
considerations might need to be addressed?
DPA response:
To the extent CDRH retains the benchmarking and clinical confirmation structure (see Q7), the
DPA supports applying it across architectures, provided evidence expectations are based on
device behavior rather than architecture. A multimodal vision-language model deployed only to
classify a WSI against a fixed set of labels, with fixed prompts, behaves like a bounded classifier
and should be evaluated as one. The same model generating free-text interpretations should be
evaluated as an open-ended device.
The approach should also cover non-generative FM feature extractors, which are the most
common FM use in CP today (see General Comment G1). For multimodal devices that integrate
imaging with molecular or clinical data, additional considerations include missing-modality
behavior, consistency of performance across data sources, and a reference standard appropriate
to the combined claim.

Question 18 (Discussion Paper §VI.D)

FDA question: 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?
DPA response:
Section VI grounds this idea in the difficulty of premarket testing for devices that “produce
varied, open-ended outputs” and “may undergo continuous adjustments.” For frozen devices
with bounded outputs, which describes most CP devices, premarket evidence can usually address
the intended use directly, so the trade-off should be applied selectively and consistent with
FDA's guidance on considering uncertainty in benefit-risk determinations. Within that frame, the
DPA supports limited use of real-world data where premarket validation cannot fully resolve a
specific safety or effectiveness question, for example, performance on rare subgroups or rare
acquisition configurations, or where the relevant outcome only becomes observable over time.
The monitoring program should be linked to the identified uncertainty, with defined data
sources, metrics, thresholds, and corrective actions.
The DPA recommends that a Section 522 postmarket surveillance study not be the standard
mechanism. For most CP devices, a manufacturer-designed monitoring plan within the quality
system, supported by the laboratory's existing quality management under CLIA and accreditation
programs, will be more proportionate. Reduced premarket evidence is not appropriate where the
device acts autonomously with no opportunity for review, or where errors cannot be detected in
time to prevent harm.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 25 of 31
 Digital Pathology Association

Question 19 (Discussion Paper §VI.D)

FDA question: 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?
DPA response:
The DPA supports the three approaches in Section VI.A and CDRH's statement that their scope
and frequency should be proportionate to the device's risk profile. For frozen, version-pinned
devices, the model does not change, so calendar-based re-benchmarking adds limited value.
Reassessment should be triggered by events that can change performance: changes to the
deployed pipeline or runtime, new scanners, stains, or protocols at a site, shifts in input
characteristics, or signals from complaints or monitoring. For devices whose configuration can
change outside the sponsor's control, both a defined cadence and event-based triggers are
appropriate.
Useful CP-specific approaches include monitoring input quality and distribution (for example,
scanner and stain characteristics and out-of-distribution rejection rates), invalid and
indeterminate result rates, and outcome-linked performance where a confirmatory result becomes
available, such as a subsequent molecular test.

Question 20 (Discussion Paper §VI.D)

FDA question: 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?
DPA response:
Automated tools can support postmarket monitoring, for example, by flagging inputs outside the
validated distribution, detecting shifts in output distributions, or selecting cases for clinician
review. Any such supervisor is itself software whose reliability affects the monitoring
conclusions, so it should be validated for its monitoring function, versioned, and controlled. A
supervisory agent should supplement, not replace, outcome-linked performance measurement
and qualified human review.

Question 21 (Discussion Paper §VI.D)

FDA question: 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?
DPA response:
Clinical laboratories already operate within an established system of external oversight, and the
DPA encourages CDRH to leverage it rather than add a separate FDA benchmarking
requirement for deployed devices. Laboratories are regulated under CLIA, most are also

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 26 of 31
 Digital Pathology Association

accredited by the College of American Pathologists (CAP), which requires and administers
proficiency testing, and many also meet ISO 15189 or state requirements such as those of the
New York State Department of Health. These programs already require laboratories to verify
performance before clinical use, maintain quality control, and take part in external quality
assessment. Within that system, roles in postmarket monitoring could include:
• Laboratories and deploying institutions: local verification before clinical use, ongoing
quality control, and reporting of malfunctions and adverse events to the manufacturer and,
where applicable, to FDA.
• Pathologists and other clinicians: recognizing and reporting apparent errors and
persistent discordance between device outputs and their own assessment.
• Accreditation bodies and professional societies: incorporating AI-enabled devices into
proficiency testing and external quality assessment, developing practice guidelines, and
contributing reference datasets.
• Standards-setting bodies: developing consensus methods for performance monitoring that
FDA can recognize.
The device manufacturer remains responsible for postmarket monitoring of its device across all
installations, including aggregating site-level signals, re-benchmarking (see Q19), and corrective
action. Laboratory quality control and proficiency testing results provide an additional layer of
monitoring and should feed into the manufacturer's monitoring.

Question 22 (Discussion Paper §VI.D)

FDA question: 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 expected
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?
DPA response:
The DPA supports using the premarket benchmarking and clinical confirmation evidence as the
baseline for re-evaluating modifications. Of the three change types in Section VI.C, locally held,
version-pinned CP devices undergo only discrete, sponsor-initiated modifications. Modelevolution (continuously learning) devices are uncommon in CP today and would warrant
separate treatment. For sponsor-initiated modifications, the DPA suggests CDRH describe
categories along the following lines:
• Managed within the QMS with regression testing: runtime, library, driver, and hardware
changes, and security patches that do not alter the model or decision logic, verified against
reference inputs and numerical and decision-stability tolerances.
• Suitable for a Predetermined Change Control Plan (PCCP): adding scanners, stains, or
specimen types under a prespecified validation protocol; retraining or recalibrating the

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 27 of 31
 Digital Pathology Association

manufacturer's task-specific component on additional data; and threshold adjustments
within prespecified bounds. Because FM/GenAI derived or generated features may
generalize to new configurations, extending intended use may sometimes require validation
of the complete system rather than retraining, but this should be demonstrated, not
assumed.
• May require new premarket review, depending on risk: replacing the FM/GenAI, or an
FM/GenAI change that materially alters device output or performance; changing the output
space (for example, from a bounded classification to free text); or expanding to a new
clinical claim. Whether a 510(k) is required should follow FDA's existing approach to
software changes, informed by the device's position in the risk framework (see Q1 and
Q24), rather than a presumption that every FM/GenAI change requires one.

Question 23 (Discussion Paper §VI.D)

FDA question: 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?
DPA response:
Where specific modifications cannot be prespecified, a PCCP could instead prespecify the
boundaries within which modifications may occur and the method for confirming performance:
the fixed elements of the intended use and output space, the control-layer behaviors that must be
preserved, the re-benchmarking protocol and acceptance criteria against the premarket baseline,
and the conditions that take a change outside the plan. For CP, many anticipated changes, such as
new scanners or stains, can be prespecified in the conventional way.

Question 24 (Discussion Paper §VI.D)

FDA question: For devices built on third-party foundation models, changes to the underlying
model may be initiated by the third-party model developer rather than the device manufacturer.
How can a manufacturer detect, evaluate, and respond to such changes in a timely manner?
What mechanisms—for example, contractual, technical, or through a PCCP—could provide
reasonable assurance that third-party developer-initiated changes do not compromise the safety
or effectiveness of the device?
DPA response:
Section VI.C describes three types of change: discrete, sponsor-initiated modifications; modelevolution changes; and unplanned changes arising from updates to an underlying third-party
foundation model. Whether the third type can occur depends on whether the manufacturer
controls the deployed weights. The DPA recommends that CDRH distinguish two deployment
configurations explicitly:
• Locally held, version-pinned models. The manufacturer retains an exact copy of the
model weights, identifies them (for example, with a cryptographic hash verified at build
and at startup, with inference blocked on mismatch), and changes them only through its
own change-control process. In this configuration there are no developer-initiated changes

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 28 of 31
 Digital Pathology Association

to detect, and every change to the model is a discrete, sponsor-initiated modification. The
DPA recommends that CDRH confirm such deployments carry no third-party changemanagement burden beyond the manufacturer's normal design change, regression testing,
and regulatory assessment obligations (for example, for runtime, library, or hardware
updates).
• Externally hosted or API-accessed models. The controlling variable is upstream.
Assurance should combine contractual commitments (version identification, advance
notification of changes, and the ability to remain on or revert to a validated version),
technical controls (version checks and monitoring of outputs on stable reference inputs),
predefined triggers for reassessment, and fallback to the standard workflow. Referenceinput testing can detect some behavioral changes but cannot prove that the model is
unchanged, so it should supplement, not replace, version identification and notification.
A PCCP can be useful for planned, manufacturer-initiated updates, such as moving to a newer
FM/GenAI version under a prespecified re-benchmarking protocol. It is less suited to
unannounced upstream changes, which should be managed through the controls above and
through the manufacturer's software maintenance plan and SOUP controls: monitoring of the
third-party component, impact assessment, and regression testing or re-benchmarking, consistent
with IEC 62304 and FDA's guidance on Off-the-Shelf Software Use in Medical Devices.
Not every upstream change to an unpinned or API-accessed model should require a 510(k). The
DPA recommends that the risk framework described in our response to Q1 also drive this
decision, applied through FDA's existing guidance, Deciding When to Submit a 510(k) for a
Software Change to an Existing Device. For a device with informational output, an HCP in the
loop, verifiable outputs, and a required downstream confirmation, an upstream change that
passes prespecified re-benchmarking within established acceptance criteria could be documented
within the quality management system. A change that alters the device's output space or intended
use, a change that fails re-benchmarking, or a change to an autonomous or high-consequence
device would warrant FDA review. In either case, the manufacturer should document its
assessment and supporting evidence.

Question 25 (Discussion Paper §VII.C)

FDA question: Would voluntary Foundation Model MAFs be practical for foundation model
developers to provide and to keep current, and what content might they include? Given that
participation would be voluntary and that model developers may have limited incentive to
disclose safety-relevant information, what would make such a program sufficiently useful for
premarket review? Are there alternative mechanisms CDRH should consider for obtaining
information about underlying foundation models?
DPA response:
The DPA supports the Foundation Model MAF remaining voluntary. A MAF could give CDRH
confidential upstream information without requiring disclosure to the device manufacturer.
However, as CDRH notes, model developers may have limited incentive to participate, and many
pathology FMs/GenAIs are released by academic groups or as open-weight models, where no
party may be available to file or maintain a MAF. The absence of an MAF should not, by itself,

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 29 of 31
 Digital Pathology Association

prevent a manufacturer from supporting a submission where sufficient alternative evidence is
available. Conversely, documenting an information gap does not establish that the gap is
acceptable.
The DPA recommends that CDRH anchor expectations for third-party FMs/GenAIs in existing,
recognized mechanisms that the manufacturer can satisfy without depending on developer
cooperation:
• FDA's guidance on Off-the-Shelf Software Use in Medical Devices, including assessment
of development assurance and continued maintenance, and justification of alternative
controls where upstream assurance is unavailable.
• IEC 62304 processes for software of unknown provenance (SOUP), where applicable, that
provide for component identification, requirements, risk assessment, integration testing,
anomaly assessment, and maintenance.
• QMSR (21 CFR Part 820) and ISO 13485 design and purchasing controls (clauses 7.3 and
7.4), adapted where no conventional supplier relationship exists, for example, for a publicly
released model obtained under license.
Under this approach, the manufacturer obtains and assesses available developer documentation
(model card, technical publications, release notes, known issues), documents information that is
available, requested but unavailable, or of unknown reliability, and links each material gap to its
risk, control, verification evidence, and residual-risk conclusion. This record can be kept within
existing design, risk management, and software documentation without a new document type.
Model cards should be treated as manufacturer-obtained developer documentation, not a filing
by the model developer to FDA, and not as a boundary on manufacturer responsibility.
The DPA supports the content CDRH lists for a Foundation Model MAF in Section VII.A
(footnote 24): architecture, training data provenance, and intended supported use cases;
characterized behaviors, known limitations, and failure modes; evaluation results, including
across clinically meaningful subgroups; safety-relevant constraints and guardrails; update
notification commitments; and audit log availability. For pathology FMs/GenAIs, the following
additional items would make a model card or MAF substantially more useful, both for review
and for the manufacturer's own study design:
• Exact model version identifiers and a means of verifying them, such as published weight
hashes.
• The dates on which pretraining data collection ended and the model version was fixed,
which allows manufacturers to design temporally separated test sets.
• Whether public datasets were included in pretraining, and which ones, so that
manufacturers can exclude them from test sets.
• Whether task or outcome labels (for example, biomarker or diagnosis labels) were used at
any stage of development.
• Composition of pretraining data by tissue and organ type, stain, scanner, magnification,
specimen type, and contributing site or region, where known.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 30 of 31
 Digital Pathology Association

Question 26 (Discussion Paper §VII.C)

FDA question: Are there additional considerations that inform the premarket and postmarket
evaluation of agentic GenAI-enabled devices, beyond those applicable to non-agentic GenAIenabled devices? How should the elevated risk associated with autonomous multi-step action,
tool use, and reduced opportunity for human review be reflected in acceptance criteria and
oversight?
DPA response:
The DPA supports treating fully autonomous operation as the highest-risk category, as Figure 1
does; in the three-axis risk framework we propose in Q1, this is the autonomous level of the
oversight axis. In CP, the highest-risk case is a device that autonomously renders a diagnosis and
acts on it without pathologist review, for example, by finalizing and releasing a pathology report,
or by using its own diagnostic conclusion to trigger treatment-relevant testing or to direct care. In
that case the risk-mitigating value of professional oversight is absent, errors reach the patient's
record and clinical decisions directly, and acceptance criteria should reflect that.
The DPA supports the capabilities described in benchmarking element A.1, particularly
compliance with human-oversight checkpoints before irreversible or high-consequence actions,
recognition of erroneous tool outputs, and resistance to prompt injection through retrieved
content and tool outputs. Additional considerations for agentic devices include: a defined and
enforced set of permitted actions and tools; evaluation of multi-step behavior end to end, not
only individual steps; logging sufficient to reconstruct each action; and postmarket monitoring of
actions taken, in addition to outputs produced. Responsibility for autonomous actions should not
rest on a clinician who had no opportunity to review them.
By contrast, many autonomous actions in the laboratory carry much lower risk. Section VII.B
notes that many agentic workflow functions may not be device functions. In the laboratory,
agentic tools are emerging for tasks such as case assignment, worklist routing, specimen
tracking, and ordering of reflex or ancillary tests under established laboratory protocols, where a
pathologist still makes the diagnosis. The DPA recommends that CDRH provide examples
distinguishing laboratory workflow automation of this kind, which is not the focus of device
oversight or is lower risk, from agentic functions that are higher risk, such as autonomous
diagnosis, actions based on the device's own diagnostic conclusion, or control of another device
such as a slide scanner.
Conversely, devices that do not act autonomously should not inherit agentic evidence
expectations. Most current CP devices provide outputs to a pathologist who retains control of the
diagnostic decision, and A.1 should apply only where the device actually performs autonomous
actions, as the paper states.

370 Medical Drive, Suite A
Carmel, Indiana 46032
T 317.816.1630 Toll-Free 877.824.4085
info@digitalpathologyassociation.org
Page 31 of 31
FDA-2026-N-7874_DPA_FDA GenAI
Comments_19Oct2026
Final Audit Report 2026-10-19

Created: 2026-10-19

By: Staci Kearney (skearney@elevationsd.com)

Status: Signed

Transaction ID: CBJCHBCAABAAvAH15jedRZlW0KgewGK-zI5r2SDd05fP

"FDA-2026-N-7874_DPA_FDA GenAI Comments_19Oct2026" H
istory
Document created by Staci Kearney (skearney@elevationsd.com)
2026-10-19 - 9:12:04 PM GMT

Document emailed to John Groth (jgroth474@gmail.com) for signature
2026-10-19 - 9:12:09 PM GMT

Email viewed by John Groth (jgroth474@gmail.com)
2026-10-19 - 10:44:56 PM GMT

Document e-signed by John Groth (jgroth474@gmail.com)
Signature Date: 2026-10-19 - 10:45:22 PM GMT - Time Source: server - Signature Appearance Selected: TYPE

Agreement completed.
2026-10-19 - 10:45:22 PM GMT