Doctronic Inc. (Matt Pavelle)
Themes it raises
FDA questions it names
Q1 · The two-axis risk frameworkQ6 · Care escalation functionsQ7 · The competency-based approachQ9 · The benchmarking structureQ10 · Benchmark contamination and saturationQ11 · Clinical confirmation without a prospective trialQ12 · Statistically meaningful performanceQ13 · Synthetic dataQ14 · Comparators and acceptance criteriaQ16 · Independent third partiesQ18 · Trading premarket certainty for postmarket monitoringQ19 · Postmarket performance evaluationQ21 · Clinicians, institutions and societies
The comment as filed
See attached file.
Attachment
October 19, 2026
BY ELECTRONIC SUBMISSION
Michelle E. Tarver, M.D., Ph.D.
Director, Center for Devices and Radiological Health
U.S. Food and Drug Administration
Rick Abramson, M.D.
Associate Director for Digital Health and Director, Digital Health Center of Excellence
Center for Devices and Radiological Health
U.S. Food and Drug Administration
10903 New Hampshire Avenue
Silver Spring, MD 20993
Re: Comments on Considerations for the Regulation of Generative AI-Enabled Medical
Devices: Discussion Paper and Request for Feedback (Docket No. FDA-2026-N-7874)
Dear Dr. Tarver and Dr. Abramson:
Doctronic appreciates the opportunity to comment on the Digital Health Center of Excellence
and Center for Devices and Radiological Health’s discussion paper, Considerations for the
Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for
Feedback (the “Discussion Paper”).
I. Introduction
Doctronic’s mission is to help people achieve better health outcomes. We built an artificial
intelligence (“AI”) medical platform designed to streamline people’s interactions with doctors
and other healthcare providers, making communication in both directions smoother and more
efficient. In collaboration with Utah’s AI Learning Lab, we are looking to develop autonomous
clinical decision software that renews certain long-course medication prescriptions in a phased
manner. The software has been in operation since December 2025 under Utah’s regulatory
mitigation program, the first state program to allow an AI platform to participate in prescription
renewal decisions. During the program’s current phase, a licensed physician reviews and
authorizes each renewal before it is sent to a pharmacy.
We believe that establishing the safety and effectiveness of AI solutions in healthcare is critical
to addressing persistent physician shortages across the country. The Association of American
Medical Colleges (“AAMC”) projects a shortage of up to approximately 86,000 physicians by
2036.1 Its prior projection estimated a shortage of between 37,800 and 124,000 physicians by
Association of American Medical Colleges. The Complexities of Physician Supply and Demand: Projections from
2021 to 2036. Washington, DC: AAMC; March 2024.
2034.2 These shortages contribute to delays in care, clinician burnout, and reduced access to
essential services. AI has the potential to help fill these gaps, and we applaud FDA for its effort
to develop a meaningful framework for GenAI-enabled devices.
Our comments draw on our experience developing clinical AI, including software that operates
in real patient care. They are organized to follow the structure of the Discussion Paper, and each
section identifies the discussion questions it addresses.
II. Risk Assessment (Discussion Paper Section IV)
A. Question 1: Additional Element – Probability of Harm
While the proposed two-axis framework provides a useful starting point, it omits a key element
of risk: the probability that harm will occur. The consequences axis captures the severity of harm
from relying on an incorrect output, but not how likely that harm is to occur. Consider two
autonomous devices: The first may produce mild, limited consequences for 5% of users. The
second may produce severe consequences, but only for 0.0001% of users (roughly one in a
million). A framework based on severity alone would treat the second device as the higher-risk
device. A complete assessment, however, must consider how severe the potential harm is, how
often it is likely to occur, and the benefits each device provides.
Incorporating probability would also allow the framework to credit device characteristics that
reduce the likelihood of harm, such as grounding in authoritative sources, downstream
safeguards, and escalation pathways. The probability of harm is different from the probability of
software failure. A software failure does not necessarily result in harm, particularly where
downstream safeguards, such as pharmacist review or independent clinical assessment, can
prevent harm. The framework should account for these safeguards even when a software failure
occurs.
B. Question 1: The “Activity” Axis
In its discussion of the “consequences” axis, the Discussion Paper appropriately recognizes that
“[a]n incorrect recommendation about an over-the-counter remedy for a minor symptom is
meaningfully different from an incorrect recommendation about adjusting an insulin dose.” We
agree that the severity of potential harm (coupled with the probability of harm) should be a
significant factor in determining the appropriate premarket and postmarket evaluation
approaches.
We believe the same principle should inform the “activity axis.” The Discussion Paper describes
action-taking functions as “typically higher risk” than informational functions, yet an
autonomous, action-taking function may present low risk overall. For example, a system that
autonomously renews a prescription for ketoconazole 2% shampoo, a prescription-strength
topical antifungal, would present lower risk than a system that instructs patients on how to
self-titrate a prescription medication, even though the latter is only action-directing. Rather than
treating a device’s activity category as establishing a presumption of risk that must then be
Association of American Medical Colleges. The Complexities of Physician Supply and Demand: Projections from
2019 to 2034. Washington, DC: AAMC; June 2021.
moderated, FDA should assess device activity together with the severity and probability of harm
from the outset.
C. Question 1: Need for Additional Definitions and Guidance
A thorough assessment of the framework will depend on how its various aspects are defined and
implemented. The Discussion Paper currently gives sponsors limited guidance for determining
where a particular device falls within the framework and, importantly, what the regulatory
implications of that placement would be. We therefore request that FDA provide greater
specificity in two areas.
First, FDA should define key terms, such as “informational,” “non-directive,” “action-directing,”
“HCP-supervised,” “action-taking” and “fully autonomous.” These terms may determine where a
device falls within the framework, and their meaning will shape how the framework operates in
practice. Without clearer definitions, it is difficult for stakeholders to evaluate whether the
framework appropriately captures the risks of GenAI-enabled devices, and therefore difficult to
provide meaningful feedback. For example, the Discussion Paper notes that “[a] function that
acts with continuous healthcare professional (HCP) supervision is meaningfully different from a
function that acts in fully autonomous fashion.” “Supervision” in this context could mean that an
HCP directly reviews each output before it affects care. Alternatively, it could mean that an HCP
oversees the patient’s care, which involves the use of an AI device, without reviewing the
device’s outputs one by one. These interpretations carry very different risk profiles and could
significantly affect where a device falls within the framework. Similar clarity is needed for other
terms that affect risk, including what constitutes an “incorrect output,” what it means for a user
to “rely” on an output, and how the severity of consequences will be assessed.
Second, FDA should describe how a device’s position within the framework translates into
concrete regulatory expectations, including the type and amount of evidence needed for clinical
confirmation, the safeguards expected, and the level of postmarket monitoring. Worked examples
drawn from realistic GenAI-enabled devices, showing how specific device characteristics lead to
particular risk determinations and evidentiary expectations, would be especially helpful.
We recognize that the framework is preliminary, and we appreciate FDA’s effort to seek
stakeholder input at this early stage. Greater specificity in these areas would allow stakeholders
to provide more thorough feedback, and we would welcome the opportunity to comment further
as the framework develops.
III. Premarket Evaluation: The Competency-Based Approach (Discussion Paper
Section V)
A. Question 7: The Competency-Based Approach
We believe the competency-based approach articulated in the Discussion Paper is a reasonable
and appropriate method for establishing that a GenAI-enabled device is competent for its
intended use. As the Discussion Paper notes, the approach is inspired by how physicians are
evaluated and credentialed, and the analogy is apt. Physician competence is established through a
multi-step process of increasing autonomy:
• Examinations, such as the USMLE, confirm that a physician has the necessary
knowledge and can apply it (e.g., to anticipate a drug interaction).
• Entrustable professional activities (EPAs) confirm that a physician can reliably
perform core clinical tasks in practice. EPAs are units of professional practice that may be
entrusted to a trainee once the trainee has demonstrated the competencies needed to
perform them without supervision. Evaluation begins with direct supervision and
progresses through increasing independence until the trainee reliably performs the
activity unsupervised.
This progression corresponds closely to FDA’s competency-based approach:
Where it is reflected in
Stage Question
FDA’s approach
1. Knowledge Does the device have the clinical knowledge its Benchmarking, element
intended use requires? E.1
2. Procedural Can the device reliably perform the entrustable Benchmarking, elements
competence activities its intended use requires (e.g., E.2 and E.3
gathering a medication history)?
3. Clinical Can the device apply knowledge and process to Clinical confirmation
management real patients and reach a safe, appropriate result?
The two-axis risk framework could be used to determine how much evidence is needed at each
stage. A device that only provides information may need strong evidence at the first two stages,
while a device that manages patients autonomously should demonstrate all three, with more
rigorous clinical confirmation. For example, the activity axis could determine which stages apply
and the type of clinical confirmation required, while the consequences axis, together with the
probability of harm, could determine the acceptance criteria and sample sizes for each stage. An
autonomous function could then progress from supervised to independent use in defined steps,
with advancement contingent on meeting prespecified performance criteria, much as a trainee is
granted increasing independence for an entrustable activity.
B. Question 9: Benchmarking Safety Elements and Escalation
We support the proposed benchmarking elements and offer suggestions on the safety elements,
focusing on escalation.
As an initial matter, the Discussion Paper uses the term “escalation” (element S.1) for directing a
user to a higher level of care, and “clinical deferral” (element S.3) for handing a question to a
human clinician when it is too complex or uncertain for the device. In these comments, we use
“escalation” to refer to both: any situation in which a device directs a user to seek care from a
human clinician, or facilitates that connection. If FDA intends these terms to carry distinct
regulatory consequences, we ask that it clarify the distinction.
1. Escalation Triggers
Escalation judgment is a core aspect of physician competence, and we agree that a device’s
ability to recognize when a user should be escalated to a human should be benchmarked directly.
We suggest that FDA evaluate four concrete escalation triggers, as applicable to the device’s
intended use. The first three are reflected in the Discussion Paper’s safety elements; the fourth is
an additional trigger we recommend FDA consider:
Escalation trigger Example Element
Emergency: an identifiable or suspected A patient reports chest pain S.1
medical emergency
Complexity boundary: the case exceeds A device triaging a simple cough without S.2, S.3.
the complexity the device is intended to fever learns that the patient has a history of
manage tuberculosis
Judgment sufficiency threshold: the Key history is missing or contradictory S.3
device lacks enough information, or
information of sufficient quality, to decide
Conflicting patient values: a A patient choosing whether to start insulin New
values-laden decision where the patient’s for diabetes indicates they value blood
stated values conflict sugar control but do not want to gain
weight
The last two triggers reflect how clinicians decide whether they have enough to make a clinical
decision. A device that does not meet the threshold should not act. The conflicting values trigger
applies only when a patient’s stated priorities conflict, not whenever values are involved. If the
patient’s priorities are consistent, the device can proceed.
Each trigger can be tested with synthetic patients during benchmarking and verified through
clinician review during clinical confirmation and postmarket monitoring. Defining triggers in
this way would also help FDA and sponsors measure both under-escalation and over-escalation
against concrete criteria, as Question 6 contemplates.
2. Scaling Escalation Obligations to Intended Use
One question the Discussion Paper leaves unresolved is when a device may respond to a request
beyond its scope, complexity, judgment or other boundary simply by declining it (e.g., “I’m
unable to help with that question”), and when it must have effective escalation protocols and
functionality, such as a handoff to a human clinician or a defined care pathway.
One approach is to use the two-axis risk framework (with probability of harm added as discussed
in Section II.A), together with a foreseeability standard tied to the device’s intended use.
Under this approach, patient-facing devices would generally need to meet a minimal baseline of
basic emergency escalation. If a user presents an evident emergency, the device should recognize
it and direct the user to emergency care. This mirrors the expectation placed on every physician
regardless of specialty. A dermatologist whose patient mentions chest pain is not expected to
manage the chest pain, but is expected to tell the patient to go to the emergency department. This
baseline requires only that the device direct the user to care. It does not require escalation
functionality, such as clinician handoff or care pathways.
Above that baseline, escalation obligations should be commensurate with the device’s intended
use, design, and risk. HCP-facing devices may not require separate escalation functionality,
because the clinician serves as the escalation path. For action-directing and particularly
autonomous devices, the device should be able to recognize and escalate the situations that are
foreseeable given its intended use and the severity and probability of harm. For example, a
device intended to address skin conditions would be expected to recognize and escalate
foreseeable dermatological emergencies. A device acting as a general primary care clinician
would be expected to recognize and escalate the range of emergencies foreseeable in primary
care practice.
Foreseeability should also reflect the device’s design, including the inputs it accepts. A device
that invites open-ended conversation can foresee a broader range of user statements than one
limited to structured inputs, and manufacturers can shape what is foreseeable through those
design choices.
This approach helps ensure user safety without requiring every device to have escalation
functionality, or functionality out of proportion to its intended use.
C. Question 11: Clinical Confirmation
Physicians are entrusted with patient management after attending physicians directly observe
them caring for real patients. Several of the Discussion Paper’s clinical confirmation approaches
closely resemble this process, particularly clinician adjudication of real cases and shadow
deployment. We recommend that FDA recognize these as primary methods for confirming
management-level competence, meaning the ability to apply clinical knowledge and procedural
competence to real patients to reach a safe and appropriate management decision, such as
whether a patient’s medication may be renewed. The choice and rigor of method should be tied
to the device’s position within the risk framework.
We also support the Discussion Paper’s recognition that confirmation approaches may be used
“individually, in sequence, or in combination.” For example, pairing retrospective evaluation on
real patient inputs with prospective shadow deployment or clinical adjudication of real cases
could test the device across a large and varied set of past cases while also confirming how it
performs on current patients under actual deployment conditions.
D. Questions 12 & 13: Synthetic Data
The Discussion Paper posits that there “could be opportunities for sponsors to leverage
methodologies such as synthetic data generation and simulation tools, including virtual patient
avatars, to conduct testing in a manner that is predictable, standardized, and amenable to
automation.” (Discussion Paper at 13.) We support the use of synthetic data and synthetic patient
simulations in this manner. Synthetic data can provide the type of “scalable, high-throughput
approach” needed for device benchmarking. It can be particularly useful to confirm a device
implements its specification where clinical judgment is not required. Synthetic data makes this
practical because a generated case carries its expected result as a field of the record, so the
required output is known before the case is run, pass-fail is machine-checkable without a
reviewer, and the suite can run unattended on every build.
The Discussion Paper further states that synthetic data generation and simulation tools “could
potentially support not only initial evaluation but also ongoing assessment of device performance
over time and in response to modifications . . . .” (Id.) We also agree that synthetic data can be a
useful tool beyond initial benchmarking, and may be appropriate in clinical confirmation and
postmarket monitoring. For clinical confirmation, simulated patients are particularly appropriate
to supplement real-world patient encounters to ensure coverage of edge cases not found in the
real-world dataset. The Discussion Paper describes directing trained patient actors to follow
defined scenarios, evaluated against prospectively defined criteria, as a possible proxy for
performance with actual patients. This function could be performed at scale using persona-driven
simulated interactions. High-fidelity simulations in which AI avatars or even robots mimic
human interactions are another scalable approach and one which avoids an over-dependence on
scarce human actors.
Simulated interactions are most useful when they are built and controlled in a defined way,
meaning that each simulated case pairs a clinical scenario with an interactive patient persona
such that relevant facts are brought forward in a realistic way. Controlling disclosure is important
because unconstrained simulated patients may volunteer information without being asked (which
is not reflective of actual clinical practice) and may potentially show inflated performance.
Because the generating model does not determine which cases are tested or what the expected
results are, it has less influence over the test set and scoring. That does not, however, mean
simulated patients behave like real patients. Research has found that LLM-simulated users may
behave less variably than real people, that testing with them can overstate system performance,
and that LLMs may inaccurately portray the demographic groups they are asked to represent.3 As
a potential solution, sponsors could compare performance on simulated interactions with
performance on comparable real interactions before relying on simulation as evidence of device
performance. For example, comparing device performance on simulated cases with its
performance on deidentified real interactions that present the same clinical facts.
Further, with certain types of devices and modifications, synthetic data may be the most
appropriate evaluation method. For example, if a device receives open-ended data from patients
through direct patient interactions, a change in the interview protocols may only be testable using
synthetic data. A retrospective evaluation on real patient inputs cannot be used because the
corpus of prior interactions was produced by the interview that is being replaced. Shadow
deployment would be of limited use in most situations because the modified interview would
have to be conducted with the actual patient to produce data. Clinical adjudication of real cases
has no interaction record to adjudicate until the modified interview has been conducted. Thus, in
this type of scenario, the use of synthetic patients can provide the best methodology.
E. Question 14: Standards of Performance
The Discussion Paper notes that open-ended outputs often have no single correct answer. We
suggest two complementary criteria, each assessed together with the process that produced the
output:
Angelina Wang, Jamie Morgenstern, John P. Dickerson: Large language models that replace human participants
can harmfully misportray and flatten identity groups, arXiv:2402.01908 [cs.CY] (last revised Feb. 3, 2025).
• Accurate: Where a reference standard exists, as is often the case for diagnostic functions,
whether the device’s conclusion is correct (e.g., whether the diagnosis is correct or the
differential diagnosis appropriately reflects the potential conditions).
• Reasonable: Where several responses may be acceptable, as is typical of management
functions, whether the actions the device chose fall within the range that a clinician
exercising the applicable standard of care could reasonably take.
Rubrics should distinguish competency failures from stylistic variation. Physicians legitimately
differ in how they approach the same case, and those differences grow with clinical complexity.
These differences are not deficiencies. We believe this principle has implications for how
performance is evaluated.
Traditional evaluation of diagnostic devices asks adjudicators to establish a single reference
standard (e.g., the lesion is malignant or not), and the device’s output is scored against that
answer. However, for many AI-generated outputs, no single correct answer will exist. A clinical
summary, a differential diagnosis, or a management recommendation could take several forms,
each of which a qualified clinician would find acceptable. For example, two differential
diagnoses for a patient presenting with chest pain may rank the possibilities differently and both
still be clinically sound. In these scenarios, the relevant question for establishing ground truth is
whether the output was reasonable. We encourage FDA to consider study designs and statistical
approaches that accommodate multiple clinically reasonable outputs. For example, adjudicators
could rate each output for clinical acceptability rather than concordance with a single reference,
and the acceptance criteria could focus on the rate of unacceptable outputs. Without this
reframing, evaluations risk penalizing valid clinical variation and rewarding conformity to
narrow standards rather than safety and appropriateness.
Question 14 also asks whether generalist or specialist physicians should serve as the comparator.
We suggest that the comparator match the level of practice the device’s intended use
encompasses, much as a physician who holds themselves out as a specialist, or undertakes
specialist care, is held to the specialist standard of care. A device intended for specialist-level
tasks would be compared with specialists, and a device intended for primary-care-level tasks
with generalists.
F. Questions 10 and 16: Independence
The Discussion Paper refers to the need for “independence” in several contexts (independent
expert adjudicators, independent clinicians, independent third parties and independently
developed benchmarks). We agree that independence can strengthen confidence in evaluation
results. We offer two comments. First, we ask that FDA clarify what “independent” means,
because the Discussion Paper leaves several common arrangements unaddressed. Second,
independence should not be treated as a universal requirement, because some evaluation tasks
require expert knowledge of the system being evaluated, and other safeguards can provide
equivalent assurance.
1. Defining Independence
The Discussion Paper calls for independence in at least five contexts, but does not define the
term.4 Without a definition, sponsors cannot know whether common arrangements qualify. For
example:
• Clinicians employed by the sponsor. Is a licensed physician employed by the
manufacturer sufficiently independent to adjudicate outputs, given that the physician
remains bound by professional and ethical obligations that do not depend on
employment?
• Independent contractors. Is a clinician engaged and paid by the sponsor as an
independent contractor, rather than as an employee, independent? Does the answer
change if compensation is fixed rather than tied to results, or if the engagement is
one-time rather than ongoing?
• Affiliated entities. Is a third party independent if it is a corporate affiliate of the sponsor,
such as a subsidiary, a parent, or a company under common ownership? What if the
affiliation is with the foundation model developer rather than the sponsor?
• Other relationships. How should FDA treat equity holders, academic collaborators who
received research funding, or members of a sponsor’s advisory board? Is there a certain
threshold of equity ownership, research funding, or advisory board involvement that
would be acceptable to establish independence?
We recommend an approach that defines independence functionally rather than by employment
status or corporate relationship alone. FDA could consider factors such as:
● Financial interest: Whether the reviewer’s compensation or holdings are affected by the
results and whether the reviewer has a proprietary interest in the device.
● Control: Whether the sponsor can direct, alter, or veto the reviewer’s conclusions.
● Involvement in development: Whether the reviewer helped design, train, or tune the
device being evaluated.
● Organizational relationship: Whether the reviewer’s organization is under common
control with the sponsor or has received significant payments from the sponsor.
FDA’s financial disclosure requirements for clinical investigators (21 C.F.R. Part 54) could serve
as a possible model. That framework generally relies on disclosure and management of bias
through additional safeguards, rather than absolute exclusion.
Section V.B.2 (benchmarking) (expert adjudicators “structurally independent from the device sponsor” and
from any third-party model developer); section V.C (clinical confirmation) (adjudicator “independence
from the device manufacturer and foundation model developer” documented; “qualified, independent
clinicians” reviewing real cases); section V.D.2 (third parties) (third parties offering “independence
between development and testing” and sequestered datasets “developed independently from the device
manufacturer”); section VI.A (postmarket) (“qualified, independent clinician adjudicators” reviewing
real-world outputs); Questions 10 and 16 (concerns about sponsor-developed benchmarks and the
“independence criteria” that should apply).
2. Independence Is Not Appropriate in Every Case
Independence is one means of ensuring an objective evaluation, not a goal in itself. Some
evaluation tasks require detailed knowledge of the device that a fully independent reviewer is
unlikely to have:
• Interpreting outputs against the device’s design. Whether a refusal, a deferral or an
escalation was correct often depends on the device’s intended scope, configured
boundaries and escalation pathways. A reviewer without that knowledge may score
appropriate refusals as failures, or miss out-of-scope behavior.
• Designing targeted tests. Developers know where a system is most likely to fail, such as
specific input formats, retrieval behavior or multi-turn patterns. That knowledge is
essential for adversarial and edge-case testing under elements S.2 and R.1.
• Diagnosing failures. Determining whether a failure stems from the model, the prompts,
retrieval, integration or the interface requires system expertise, and is what allows failures
to be corrected.
• Ongoing monitoring. Postmarket review, re-benchmarking after modifications and drift
detection depend on continuous familiarity with the device and its deployment.
The clinical model the Discussion Paper draws on illustrates this. Residents are assessed through
direct observation by attending physicians in their own training program. Those attendings are
not independent of the program, yet their assessments are trusted because of their expertise,
professional obligations and the structure in which they work.
We recommend that FDA allow objectivity to be established through process safeguards, as an
alternative or complement to reviewer independence. These could include:
• prespecified test methods, rubrics and acceptance criteria, as the Discussion Paper
already contemplates;
• audit trails documenting every adjudication and any changes to results;
• independent audit of a sample of sponsor-conducted adjudications, rather than
independent adjudication of every case; and
• disclosure of reviewers’ relationships with the sponsor and model developer.
These mirror how sponsors already conduct credible clinical trials, through prespecified analysis
plans, blinded endpoint adjudication and independent data monitoring, without every participant
being independent of the sponsor. A hybrid approach, in which knowledgeable internal experts
design and run evaluations while independent parties audit or adjudicate selected elements, may
provide stronger assurance than either approach alone.
IV. Postmarket Monitoring (Discussion Paper Section VI): Questions 18, 19, and 21 –
Reliance on Postmarket Monitoring
We support FDA's consideration of whether to accept greater premarket uncertainty for some
GenAI-enabled devices through greater reliance on postmarket monitoring. For the reasons
discussed in Section II.B, eligibility for this approach should turn on the severity and probability
of harm rather than activity category, so that autonomous functions are not excluded by category
alone. The condition should be a prespecified monitoring plan, established at authorization, in
which the intensity of clinician review is tied to demonstrated performance. Consistent with the
progression described in Section III.A, review could begin at an intensity set by the strength of
the premarket evidence and the device’s risk. That intensity could range from review of every
output before it affects care, to retrospective review of every output, to review of a statistically
sampled subset. Each reduction would be contingent on prespecified performance criteria.
Review should return to a higher level after a defined trigger, such as a modification outside an
authorized predetermined change control plan (PCCP), a new deployment configuration (Section
V), a material shift in the patient population, or a safety signal. Utah's regulatory mitigation
program applies a similar phased structure to the prescription renewal software described in
Section I.
Postmarket monitoring should measure the competencies established premarket, not only
aggregate error rates. These include the rate of clinically unacceptable outputs (Section III.E),
under- and over-escalation against the triggers in Section III.B, and performance on periodic
re-benchmarking. Re-benchmarking can include synthetic cases where real-world data cannot
test a modification (Section III.D). The pace of step-down and any minimum review rate could
be set using the two-axis risk framework together with the probability of harm (Section II.A).
Clinicians and organizations deploying the device can share in review, while the sponsor remains
accountable for the monitoring program. Sponsor-led review can rely on the process safeguards
described in Section III.F.2.
We would support efforts to obtain Congressional authorization to operationalize any aspects of
this approach that FDA concludes may be required. We would welcome the opportunity to work
with FDA and Congress on the details of any such authority.
V. Additional Topic: Deployment Across Multiple Settings and Integrated
Environments
The Discussion Paper evaluates the final user-facing device “as configured and intended to be
deployed for real-world use” and notes that benchmark datasets should be representative of
deployment contexts. For a product deployed across multiple settings, however, there is no single
deployed configuration. One customer may use the device as a standalone application. Another
may connect it to its electronic health record (EHR) so that the device draws on patient records,
institutional protocols or local formularies and returns outputs into clinical workflows.
Integrations will use different EHR platforms, interfaces and local settings.
Manufacturers need clarity on several practical questions:
• What part of an integration is considered part of the device, and what is part of the
deployment environment?
• Can a device be authorized once for a defined range of integration configurations, rather
than per site?
• What evidence is expected for integrated configurations at premarket, and what can be
addressed at or after installation?
• How should changes to a customer’s systems be managed after deployment?
Clear answers should support FDA’s least burdensome goals, give manufacturers a predictable
path, and help health systems adopt authorized devices consistently.
VI. Conclusion
Doctronic appreciates FDA’s thoughtful approach to the regulation of GenAI-enabled devices
and its effort to seek stakeholder input at this early stage. This work is consistent with America’s
AI Action Plan, which recognizes that health care has been slow to adopt AI and calls for a
“try-first” culture, and we support FDA’s progress toward that goal through this Discussion Paper
and programs such as the Technology-Enabled Meaningful Patient Outcomes (TEMPO) for
Digital Health Devices Pilot. We believe a risk-proportionate, competency-based framework,
with clear definitions and practical evaluation pathways, can help bring safe and effective AI to
patients who need better access to care. We would welcome the opportunity to discuss these
comments further. Please contact Matt Pavelle at regulatory@doctronic.ai with any questions.
Sincerely,
Matt Pavelle Byron Crowe, MD MS
Cofounder and President Chief Medical Officer
Doctronic Inc. Doctronic Inc.