Veritas Biomedical Analytics, Inc. (Gilbert H. Olson)

See attached file(s)

Veritas Biomedical Analytics, Inc.
Dallas, Texas

Document ID: VBA-REG-FDA-2026-001 Docket No.: FDA-2026-N-7874
Version: 001 Date: October 18, 2026
Author: Gilbert H. Olson, Founder and Chief Executive Officer

Submitted electronically via www.regulations.gov
Dockets Management Staff (HFA-305)
Food and Drug Administration
5630 Fishers Lane, Room 1061
Rockville, MD 20852
Re: Docket No. FDA-2026-N-7874, Considerations for the Regulation of Generative
AI-Enabled Medical Devices: Discussion Paper and Request for Feedback
Dear Dockets Management Staff:
Veritas Biomedical Analytics, Inc. (VBA), a Texas corporation based in Dallas, submits these
comments on the Food and Drug Administration (FDA) discussion paper [1]. VBA is a small,
early-stage developer of a generative artificial intelligence (AI)-enabled medical device that
synthesizes longitudinal medical records for clinicians caring for patients whose conditions
remain undiagnosed or unresolved. VBA intends to seek FDA marketing authorization for it. Its
founder brings 27 years of forensic failure analysis of complex systems, including automotive
diagnostics, and that background shapes these comments: VBA approaches clinical AI as a
system whose failures must be detectable, traceable, and safely contained.
VBA's comments rest on one principle: a generative AI device should be a glass box, not a black
box. The person who relies on its output must be able to verify it. That means four things:
• each finding traces to its sources;
• when the record cannot support a conclusion, the device says so and identifies what kind of
information is missing, and that answer is itself the output;
• if the device cannot finish its analysis, it releases nothing rather than a partial result; and
• every step from input to output is recorded and auditable.
VBA responds below to each of the 26 questions posed by the Center for Devices and
Radiological Health (CDRH) [1]. The examples describe the kind of function VBA is developing.
They illustrate the recommendations; they are not a device specification.
SUMMARY OF POSITIONS
1. The two-axis risk grid is sound. Four factors should adjust a function's position on the grid.
They should not become new axes. The four factors are traceability, downstream safeguards,
reversibility, and time pressure.
2. The activity axis should record two separate facts. The first is whether the analysis runs
without a human, called process autonomy. The second is whether the output can act on a
patient without a human, called action autonomy.
3. Each function should declare a directiveness ceiling, the highest point its outputs may reach.
Benchmarking should verify that outputs stay at or below it.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 1 of 13
 4. Risk rises when an output reaches a user who cannot evaluate it independently. That condition
should be tested directly. It should not be assumed from the type of user.
5. Benchmarks should include cases with no definitive answer. Those cases test whether a device
recognizes the limits of its own evidence.
6. Clinical confirmation should proceed in stages that match the function's risk.
7. Change control should prespecify the limits a device must stay within, not every individual
change.
8. Roles should be clear when a device function runs inside another company's platform.
DEFINITIONS
Process autonomy: whether a function's analytic work runs without a human step.
Action autonomy: whether a function's output can change a patient's state without an
accountable human decision.
Handoff: the point at which output must pass to a qualified human.
Operational Design Domain (ODD): the conditions under which a function is validated. These
include the user, the setting, the required inputs, and the uses that are excluded.
The four factors: each is a structural pass/fail test that can move a function within a bounded
band on the grid.
• Traceability: each finding is bound to source records the clinician can open.
• Downstream safeguard: a qualified clinician must act before any clinical consequence can
occur.
• Reversibility: a decision based on the output can still be revised, and no automated
component can alter the device's record of its output.
• Time pressure: whether full review is possible before action is taken.
Directiveness ceiling: the highest point a function's outputs may reach, declared in its intended
use. The points are the four in CDRH's lisinopril example: general information, contextualized
information, endorsement, and instruction [1, § IV, p. 7].
Benchmarking elements: labels such as S.1 refer to Appendix A of the discussion paper [1, App.
A, pp. 24–26].
• S.1: safety-critical recognition and escalation.
• S.2: scope maintenance and boundary adherence.
• S.3: calibration, uncertainty communication, and clinical deferral.
• E.2: information gathering and clinical analysis.
• E.3: quantitative and measurement analysis.
• E.4: communication quality and user comprehension.
• R.2: subgroup performance.
• A.1: agentic AI competencies.
Clinician of record: the licensed healthcare professional (HCP) responsible for the patient's care,
whose license and credentials are verified before a case is accepted.
Function A: an illustrative HCP-facing function that synthesizes complete longitudinal records
into a fully cited analytic document for the clinician of record.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 2 of 13
 • Output: possible explanations ranked by strength of evidence, each with the evidence for and
against it. It names no diagnosis and no next step.
• Patient input: it may take in the patient's own account of their condition, provided
voluntarily.
• Recipient: it delivers its output only to the clinician of record.
• Limits: it does not prescribe, initiate orders, command other devices, or supply information
for coding, visit-level selection, or claims.
• Failure behavior: it withholds its output rather than issue an incomplete one.
SECTION IV: ASSESSMENT OF RISK
Question 1. Is the two-axis framework adequate, and how should additional dimensions be
represented?
The two axes are the right foundation. The four factors should adjust a function's position on the
grid rather than add axes, because all four answer one question: can an incorrect output be caught
or corrected before it reaches the patient? Traceability, reversibility, and time pressure bear on
how severe the consequence is. A downstream safeguard also confirms that the function does not
act on the patient itself, so it bears on activity as well. Only structural safeguards should earn
credit. CDRH is considering whether adding a "talk to your doctor" statement leaves an output no
less directive [1, § IV, p. 7]. VBA agrees that the statement does not reduce directiveness, and the
same principle should apply to all four factors. The two axes are a placement aid inside the
manufacturer's existing risk management file [2]. Traceability, downstream safeguards,
reversibility, and time pressure are recorded there as modifiers. They are not a second taxonomy.
The grid's "fully autonomous" label [1, § IV & fig. 1, p. 6] combines two distinct facts. Process
autonomy and action autonomy should be recorded separately, together with the handoff and the
ODD.
VBA proposes the driving automation taxonomy of SAE International (formerly the Society of
Automotive Engineers) as a reference for the process side. It is published as SAE J3016 and,
jointly with the International Organization for Standardization (ISO), as a Publicly Available
Specification (PAS), ISO/SAE PAS 22736 [3]. In VBA's view, it is the most mature published
framework for classifying autonomy where automation can cause human harm, and researchers
citing an earlier edition of the automotive levels have proposed a parallel six-level scale for
medical robots [4]. VBA offers the analogy as its own proposal, not as established FDA practice.
• Level 4 means the system performs the entire task and its fallback within a specific ODD
(§ 5.5) [3].
• The fallback must reach a minimal risk condition, "a stable, stopped condition" that reduces
the risk of a crash (§§ 3.12, 3.16) [3].
• Section references are to J3016_202104, which is technically equivalent to ISO/SAE PAS
22736:2021 and uses the same section numbers [3]. SAE International issued a further
revision, J3016_202609, on September 20, 2026 [5].
• For an analytic function, the equivalent of a minimal risk condition is withholding the output.
• Where the clinician must complete the analysis, the process is Level 3.
No combination of these modifiers should move an action-taking function that lacks a required
human handoff out of the upper activity region, move a high-consequence function onto the
postmarket side of the trade described under Question 18, or offset a failed safety gate.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 3 of 13
 Example: Function A's analysis runs unattended within a defined ODD. That is Level 4, for the
process only. Its action autonomy is low, and an unattended process alone should not place it in
the highest-risk cell. A function that initiates orders or controls another device stays in the upper
region regardless of the factors.
Question 2. How should the spectrum between non-directive and action-directing
information be addressed?
CDRH's four lisinopril statements [1, § IV, p. 7] are reference points on the continuum, not the
only positions on it. VBA recommends assessing three characteristics:
• Specificity: whether the output adopts an action as what the user is to do. Naming a drug, a
clinical fact, or a common practice without adopting it does not move an output toward
endorsement or instruction.
• Personalization: whether the output applies to the individual patient rather than to a
population.
• Pre-emption: whether the output chooses among options the user would otherwise weigh.
Wording alone should not move an output [1, § IV, p. 7]. Context about the user and setting
belongs on the consequence axis.
Explanations ranked by strength of evidence remain contextualized information, provided each
shows the evidence for and against it and no next action is stated. An output above the declared
ceiling is a boundary failure of the kind element S.2 addresses. It should be tested with the
adversarial and multi-turn methods described for S.2 [1, App. A, S.2, p. 24].
Example: Function A declares a contextualized-information ceiling. When a finding is
unresolved, the output identifies the kind of evidence that would resolve it, not a specific test,
order, or care setting. If the genetic evidence in the record does not resolve a finding, for instance,
the output states that and identifies further genetic evidence as what is missing. It does not name a
test, a depth, or a laboratory. The clinician can ask the device to explain the gap in more detail,
and each answer stays within the same ceiling (Question 5). The clinician chooses the test.
Question 3. When does patient-facing delivery present different or higher risk?
Risk rises when the patient:
• cannot evaluate the output independently;
• has no clinician in the path;
• may take an irreversible step; or
• may act without time for review.
Patient-facing delivery therefore changes whether the four factors pass; it is not a fifth factor.
Accepting input from a patient is not patient-facing delivery. A function that delivers its output
only to an HCP remains HCP-facing.
Appropriate safeguards include:
• a plain-language statement of each finding's basis, bound to its sources;
• a statement of what the output cannot determine, which is the uncertainty-communication part
of S.3 [1, App. A, S.3, p. 24]; and
• testing that the user understands those limits, under E.4 [1, App. A, E.4, p. 25].

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 4 of 13
 A patient-facing function should declare a lower directiveness ceiling. The exception is a
safety-critical clinical state: when the function recognizes one, it must direct the patient to care,
tested for both under-escalation and over-escalation under S.1 [1, App. A, S.1, p. 24]. The
strongest safeguard is clinician-mediated release, in which the output reaches a clinician first. To
avoid medical parentalism, a sponsor should be able to earn lower placement by demonstrating
two things: comprehension across health-literacy levels (E.4) and consistent performance across
subgroups (R.2) [1, App. A, E.4, p. 25; R.2, p. 26].
A function can engage the patient without delivering output to the patient, by taking in the
patient's own account of their condition. That account may raise questions for the analysis to
examine. It cannot change any fact in the medical record, because a patient's perception does not
always match the recorded findings. Where the two disagree, the output reports the disagreement
for the clinician to evaluate. The account should be handled as evidence, never as an instruction to
the device.
Question 4. Should the distinction between generalist and specialist physicians inform risk?
It should, but not as a rule that generalist use is inherently riskier. Risk rises when the safe use of a
finding depends on specialty expertise the intended user lacks. The four factors test that condition
directly:
• Traceability: a finding about a cardiac conduction abnormality links to the specific
electrocardiogram report it came from. A generalist can open that report and see what the
finding rests on, or recognize that it needs a cardiologist's reading.
• Downstream safeguard: the generalist, not the device, decides what happens next, including
whether to consult a specialist.
• Reversibility: a decision informed by the output, such as seeking a neurology opinion, can be
revised as more is learned.
• Time pressure: in a non-emergency setting, the generalist has time to seek specialist input.
The same finding delivered in an emergency setting would carry higher risk.
The intended use should declare the intended user. Each finding should name its clinical domain
and link to its sources. Experts qualified in each finding's domain should adjudicate the findings
[1, § V.B.2, pp. 13–14], and comprehension under E.4 should be tested with the declared intended
user [1, App. A, E.4, p. 25].
Question 5. How should risk be assessed for multi-turn conversational devices?
The directiveness ceiling should hold across any realistic conversation, not only within single
outputs. Testing should include conversations designed to push the device past its ceiling [1, App.
A, S.2, p. 24]. The intended use should be characterized by the highest point the device can reach
over a realistic conversation, not by its typical first answer.
Conversation should be used where it adds value. Where a function's inputs are fixed before the
analysis begins, interaction during the analysis adds nothing. After delivery, however,
conversation lets the clinician verify the output. The clinician asks about a finding, and the device
retrieves the finding, its source records, and any measurement or annotation it made, such as a
measurement marked on an imaging study. Annotations should appear beside the unaltered
original and be marked as device-generated, so the clinician can check the measurement
independently under E.3 [1, App. A, E.3, p. 25]. In these exchanges:
• the ceiling applies to every answer;

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 5 of 13
 • the exchange cannot change the delivered output or any fact in the record;
• every exchange is logged; and
• a question that requires new analysis starts a new, separately evaluated run only at the
clinician's request.
A conversational function used during a live clinical encounter should be evaluated as a separate
intended use, with its own ODD and with time pressure applied.
Question 6. How should under-escalation and over-escalation be weighed?
The two error rates should be reported separately, each against a prespecified acceptance
threshold, because the two errors carry different consequences and cannot be traded one for one.
Each threshold should reflect the consequence of that error in the intended setting. For a
care-escalation function where a missed emergency would be catastrophic, a higher
over-escalation rate may be acceptable, and the sponsor should state that trade-off in advance.
SECTION V: PREMARKET EVALUATION
Question 7. Is the competency-based approach useful and appropriate?
Yes. VBA agrees that the final configured device, rather than the foundation model alone, should
be evaluated [1, § V.A, p. 11]. Every competency claim should identify the configuration that was
evaluated: model version, prompts, reference sources, tools, and guardrails. The configuration
evaluated, the configuration authorized, and the configuration deployed are the same object. A
change to any of them invalidates the claim until the evidence is re-established. Competency
should be a set of tested claims, not a single score. Safety invariants, such as the directiveness
ceiling, withholding, and the human checkpoint before an irreversible action, are verified as pass
or fail against a measured result. For the ceiling, that result is the escape rate: how often outputs
exceed the ceiling under testing. The rate is the test; it is not a competency score and is not
averaged with other results. Where behavior is probabilistic, sponsors should run identical inputs
repeatedly under the configuration proposed for marketing and report, for each endpoint, the
distribution of results and the device's own run-to-run variation. A difference smaller than that
variation is not evidence, and no proficiency result offsets a failed safety gate. For a device built
from separate modules, VBA recommends pairing that evaluation with verification of each
module against its own specification [6]. Module-level verification traces a failure to the module
that caused it and allows a changed module to be re-verified on its own (Question 22).
Device-level benchmarking remains the basis for authorization, because modules interact.
Question 8. How should the risk grid inform the level of evidence?
Evidence should scale with a function's position on the grid after the four factors are applied,
consistent with CDRH's statement that evidence should be proportionate to a device's risk profile
[1, § V.C.1, p. 15]. A function with low action autonomy and structural safeguards should need
less clinical confirmation than an action-taking function at the same consequence level. It should
never need less benchmarking of the safety elements that apply to its intended use. CDRH
chooses those elements by intended use and risk profile [1, § V.B.1, p. 13]; for Function A, they
are S.2 and S.3. S.1 does not apply because Function A does not escalate care.
Question 9. Is the benchmarking structure adequate?
VBA supports the structure and recommends four additions:
• Source fidelity: whether each finding is correctly bound to its supporting records, and
whether the device misstates what a source says.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 6 of 13
 • Appropriate withholding: whether the device withholds its output when it cannot complete
the analysis, rather than issuing a partial result.
• Longitudinal synthesis: whether the device correctly integrates evidence across many
documents and years. Element E.2 addresses this only in general terms [1, App. A, E.2, p. 25].
• Incidental findings: whether the device states what the sources show. This includes a finding
with no documented follow-up, and a finding visible in a source that the source's own report
did not state.
For incidental findings, the benchmark should test that:
• each finding is stated separately, cited to its source, and indexed so the clinician can find and
search for it;
• calling a finding incidental does not mean it is unimportant, and significance is left to the
clinician;
• where the finding is visible in an image, the image is shown unaltered beside what the device
marked;
• the statement stays within the function's declared directiveness ceiling; and
• reporting criteria are prespecified and tested for both missed findings and excessive reporting.
Omission and false reassurance should be tested and reported as their own failure types, separate
from incorrect statements. An output can be accurate in every statement and still cause harm by
leaving out a pertinent finding, by reassuring where the record does not support reassurance, or,
for a function that escalates care, by failing to say that care is needed when the record supports it.
FDA-recognized consensus standards can anchor several elements:
• ISO 14971, for linking benchmark failures to risk controls [2];
• International Electrotechnical Commission (IEC) 62366-1, for testing user comprehension
under E.4 [7]; and
• IEC 62304, for tying re-benchmarking to the software change process [6].
Question 10. How should a sponsor show that a benchmark predicts real-world
performance?
Construct validity is strongest when benchmark cases come from the same population and record
types as the intended use. Sponsor-developed benchmarks should be acceptable if they are
prespecified and sequestered before testing so they cannot be tuned to the test. Sequestration can
mean an independent party holds them, or a published cryptographic hash fixes them.
Sequestration also guards against the contamination and saturation CDRH identifies in public
benchmarks [1, § V.B.1, p. 12]. Benchmarks should also include cases with no definitive answer,
to test whether the device recognizes the limits of its evidence rather than producing a confident
wrong answer.
Question 11. How should a sponsor select and justify a clinical confirmation approach?
Confirmation should be staged, and the sponsor should justify each stage against the function's
position on the grid. For an HCP-facing function that works on existing records and takes no
clinical action, VBA recommends three stages:
1. Retrospective evaluation on resolved cases. The final diagnosis is withheld from the device,
and independent adjudicators are blinded to its output.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 7 of 13
 2. Prospective shadow deployment. The device runs on live cases, its output does not reach
clinicians, and its output is later compared with how each case was resolved [1, § V.C.1, p.
15].
3. Postmarket monitoring against prespecified measures (Question 19).
The prospective stage tests the device on records as they arrive, not only on records assembled
after the fact. Confirmation cases at every stage should reflect the real mix of inputs, including
incomplete and conflicting records. Prospective interventional studies should be expected for
functions whose outputs reach patients directly or take action.
Example: Function A's endpoint is whether the explanations and findings it reports are supported
by the record, as judged by adjudicators. The endpoint is not whether it names the eventual
diagnosis, which it does not do.
Question 12. How should statistically meaningful performance be achieved?
Sample sizes and acceptance criteria should be prespecified, and confidence intervals reported.
Benchmarking and clinical confirmation results should be reported separately, not combined into
a single estimate. They measure different things: capability under controlled conditions, and
performance in clinical use. Synthetic and real-data results should also be reported separately.
They should be combined only where the synthetic data has been shown to match the real
distribution for the measure in question.
Question 13. Where is synthetic data suitable or inadequate?
Synthetic data suits testing of boundary behavior where realistic clinical detail is not required,
such as out-of-scope requests, malformed inputs, and prompt injection. It is poorly suited to
longitudinal, multi-specialty records. The value of those records lies in real inconsistencies, gaps,
and errors that generated data tends to smooth over. Where synthetic data is used, it should come
from a different model class than the device under test. It should never be the only evidence for a
subgroup. Where the intended use includes children, evidence should be stratified by
developmental age rather than pooled into a single pediatric subgroup. If children are outside the
intended use, the labeling should say so.
Question 14. How should comparators and acceptance criteria be selected for open-ended
outputs?
Three choices should be made separately:
• Reference standard: where the device informs specialist-level questions, a panel of
specialists in the relevant domains should judge whether each finding is supported. A median
clinician is not the right standard, because specialist-level questions call for specialist-level
judgment.
• Acceptance criterion: a prespecified minimum proportion of findings the panel judges
supported, and a maximum rate of unsupported findings. This is the pass rule.
• Clinical utility: measured by comparing patient outcomes against the care likely without the
device (Question 15). It is reported as its own result, and it is not a pass rule. A difference in
the workup is not this result.
Where the intended use requires a person to act on the output, performance should be judged on
that person and the device working together, including whether that person catches the device's
errors or accepts them, which tests automation bias directly. Device-alone performance should be
the basis only for functions that act without a person.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 8 of 13
 Question 15. Can performance be assessed relative to care without the device?
Yes, and for some functions this is the most meaningful comparison. For patients whose
conditions remain unresolved after extended workup, the alternative is continued workup without
the device. Comparing time to a supported finding, and the rate of supported findings, against that
course measures a difference in the workup. It does not, by itself, show that patients do better. A
competency claim shows whether the output matches the clinical evidence, and it should not be
read as a claim of benefit either. Clinical utility is shown only by comparing patient outcomes
against the care likely to occur without the device, reported as its own result. A strong
competency result does not establish it.
Question 16. Should independent third parties be involved?
Yes, to maintain sequestered datasets and to serve as independent adjudicators. An independent
party should have no financial interest in the sponsor or the foundation model developer.
Adjudicators should hold qualifications in the clinical domain under evaluation [1, § V.B.2, pp.
13–14]. Agreement among adjudicators should be measured and reported against a prespecified
range, and a model from the same family as the device under test should not serve as an
adjudicator.
In VBA's view, a mandatory third-party certification step before FDA review would add cost and
delay that fall hardest on small developers. Third-party participation should remain an option a
sponsor may use to strengthen its submission.
Question 17. Does the approach apply to multimodal and other architectures?
Yes. For functions that ingest imaging:
• benchmarking should use complete studies rather than summaries or single images;
• testing should cover behavior when input quality is inadequate, and inputs below a stated
minimum should fall outside the ODD; and
• where the device derives a measurement from an image, it should show the measurement on
the image beside the unaltered original, so the clinician can see how the value was obtained.
SECTION VI: POSTMARKET MONITORING
Question 18. When can greater premarket uncertainty be accepted through postmarket
monitoring?
Greater premarket uncertainty can be accepted when three conditions hold: the function has low
action autonomy, a structural human handoff stands between output and patient, and errors can be
detected after the fact through a traceable record. The monitoring program should then include:
• prespecified measures and thresholds, including those in Question 19;
• a fixed review cadence, with reporting to FDA;
• a predetermined response when a threshold is crossed, up to withholding output until the cause
is resolved; and
• sample-based clinician review of real-world outputs against their sources.
Greater uncertainty should not be accepted for action-taking functions or time-critical settings,
where an error reaches the patient before monitoring can detect it.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 9 of 13
 Question 19. Comment on re-benchmarking, clinician review, and degradation monitoring.
VBA supports all three [1, § VI.A, pp. 19–20]. Clinician review should be sample-based, with
qualified clinicians checking real-world outputs against their sources (Question 18). VBA
recommends monitoring three further measures:
• Withholding rate: how often the device withholds its output. A rising rate signals problems
with inputs or performance. A falling rate may signal weakened safeguards.
• Reference currency: the age of the reference knowledge the device relies on. Outdated
references degrade outputs even when the model has not changed.
• Source status: whether a source cited in a delivered output has since been retracted. When
one has, the manufacturer should notify the clinician of record who received that output.
Retracted studies continue to be cited: of 652 citations of one retracted study of drug therapy
in coronavirus disease 2019, only 115 noted the retraction [8].
Reassessment should occur on a fixed schedule, set in the monitoring plan and proportionate to
the function's risk, and whenever one of these triggers occurs:
• any change to the foundation model version;
• any change to reference sources; and
• any monitored measure crossing a prespecified threshold.
Each monitoring plan should state which failure types it can detect and which it cannot. An
absence of reports is not evidence of safety. Representative clinical sampling is not evidence of
resistance to scope escape, prompt injection, or multi-turn manipulation. At least one detection
method must be independent of the device's own output.
Some failures will not be foreseen. When monitoring finds a failure type not seen before, the
manufacturer should first contain it, withholding output from the affected configuration if patients
could be harmed, and report it where the medical device reporting and correction and removal
rules require [9, § 820.10(b)(3)–(4)]. It should then trace the cause through every safeguard the
failure passed, not only the last one, and add the failure to the benchmark, so every later version is
tested against it. A correction should ship only as a new configuration, after it passes the full
benchmark, including every failure added since the prior version and held-out cases the correction
was not designed for, and after a person authorizes its release. Whether that release needs FDA
review follows the limits in Question 23. This is the corrective and preventive action process the
Quality Management System Regulation already requires [9, § 820.10(a); ISO 13485:2016, cl.
8.5.2–8.5.3], applied to failures no one anticipated.
Question 20. Can machine-based supervisory agents facilitate monitoring?
Yes, provided the supervisor is independent of the system it monitors: separately implemented,
limited to read-only access, and unable to alter the records it reviews. VBA recommends going a
step further with design diversity: the supervisor's software should differ from the software of the
system it monitors, so that one software defect cannot compromise both. In the Airbus fly-by-wire
controls, the software of the monitoring channel differs from that of the control channel in order
to minimize the risk of a common error [10]. Where the supervisor is itself a model, VBA
recommends that it be a different model from the one it monitors, so that the two do not share the
same failure modes. A different model reduces that risk. It does not remove it, and the supervisor
should still be validated against known failures before anyone relies on it.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 10 of 13
 Question 21. What roles should other stakeholders play?
Clinicians and institutions are best placed to report outputs they judge incorrect, and each output
should give them a structured way to do so. Professional societies and standards bodies can
maintain reference standards, benchmark case sets, and adjudication criteria, so that every
sponsor is measured against a common bar. Accountability for acting on reports should stay with
the manufacturer.
Host platforms need clear roles. These are the electronic health record (EHR) and practice
systems that integrate a device function built by another company. VBA recommends that CDRH
clarify when a host that integrates an authorized function through a defined interface, without
altering, relabeling, or separately marketing it, does not take on manufacturer obligations. For
such integrations, VBA recommends three conditions:
• the device function runs as a separable module with read-only access to the record;
• every exchange between host and device is logged; and
• device output has no path into coding, visit-level selection, or claims.
Question 22. How should re-benchmarking scale with the nature of a change?
Two kinds of change should be distinguished because they carry different risk.
Reference corpus changes alter what the device knows, such as updates to its medical references
and changes to reflect new regulatory requirements. These are part of the device's design and may
occur frequently. They should be prespecified in the Predetermined Change Control Plan (PCCP)
as a recurring change type, not treated as a new modification each time. Each release of the
reference corpus should be authorized by a designated responsible individual under the
manufacturer's quality system and verified by re-benchmarking before it is deployed.
Inference changes alter how the device reaches its outputs, such as replacing or retraining its
models or restructuring its analytic process. These should be tiered:
• PCCP: a change that stays within the declared ODD and directiveness ceiling, verified by full
re-benchmarking against the premarket baseline. This can include a planned transition from
one model to another.
• New submission: any change to the intended use, ODD, directiveness ceiling, benchmark
thresholds, or action autonomy.
Compression of the model artifact, including quantization, pruning, and distillation, is its own
change. It is not presumed to be low impact, and it is not managed only inside the quality system.
After a material compression or inference-stack change, the sponsor validates the artifact that will
actually run.
Cybersecurity patches and other changes that do not alter outputs, as confirmed by
re-benchmarking, remain a quality-system matter. A modular design lets each change be isolated
and re-verified at the module level, then confirmed at the device level, without re-validating the
entire device.
Question 23. How can PCCPs accommodate changes that cannot be fully prespecified?
By prespecifying the limits rather than the changes: the ODD, the directiveness ceiling, and the
benchmark thresholds. A change that keeps the device within those limits, verified by
re-benchmarking, falls under the PCCP. A change that would move any of them requires FDA
review.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 11 of 13
 Question 24. How should changes to third-party foundation models be managed?
The manufacturer should:
• pin each model to a specific version;
• detect any change by running a fixed regression test set on a defined schedule; and
• deploy no new version until it passes full re-benchmarking.
Contracts should require advance notice of changes. A planned transition to a new model version
can be prespecified in the PCCP (Question 22). Where available, licensing model weights for the
manufacturer to hold is a further option, because it removes the possibility of an unannounced
change to the model itself.
If the model serving the output is not the validated configuration, because it changed without
notice or because no validated version remains available, the device does not emit a clinical
output from that model. Continued operation on a validated pin is not a failure. This rule applies
to the generative clinical output, not to essential functions that do not depend on that model.
SECTION VII: OTHER TOPICS
Question 25. Would voluntary Foundation Model Device Master Files be practical?
VBA supports them. Keeping a Master File current is practical if updates are tied to each model
version release, so that every version a sponsor pins has a matching file. Useful content includes
training data provenance, known failure modes, update notification commitments, and evaluation
results on healthcare-relevant benchmarks [1, § VII.A, p. 22 & n.24]. Participation would be more
attractive if referencing a Master File visibly reduced the sponsor's burden. Without one, sponsors
should be able to rely on their own version pinning and re-benchmarking.
Question 26. What additional considerations apply to agentic devices?
The distinction between process autonomy and action autonomy under Question 1 applies
directly. Agentic behavior within an analysis carries different risk from agentic action on patients
or other devices. VBA recommends four acceptance criteria:
• No agent may delete or alter records or evidence; the record is append-only.
• Each agent has access only to the tools and data its task requires.
• Any irreversible or high-consequence action requires a human checkpoint, under element A.1
[1, App. A, A.1, p. 26].
• Reference content is limited to curated sources. All other text the device reads, including any
patient account, is treated as evidence rather than instruction, and that treatment is tested
against prompt injection [1, App. A, S.2, p. 24; A.1, p. 26].
Example: Function A's agents operate only within the analysis and cannot alter the record. They
issue no commands to any other device or physical system.
CONCLUSION
VBA commends CDRH for opening this discussion early and in a form that invites practical
engagement, and VBA supports the framework in the discussion paper. The refinements offered
here share one aim: every generative AI output that reaches a clinician should be one the clinician
can verify. VBA would welcome the opportunity to discuss these comments further.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 12 of 13
 Respectfully submitted,

Gilbert H. Olson
Founder and Chief Executive Officer
Veritas Biomedical Analytics, Inc.

REFERENCES
[1] U.S. Food and Drug Administration, Center for Devices and Radiological Health, Digital Health Center of
Excellence, Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper
and Request for Feedback, Docket No. FDA-2026-N-7874, Aug. 2026.
[2] International Organization for Standardization, ISO 14971:2019, Medical devices — Application of risk
management to medical devices, 2019.
[3] SAE International, Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road
Motor Vehicles, Recommended Practice J3016_202104, Apr. 2021; technically equivalent to International
Organization for Standardization and SAE International, ISO/SAE PAS 22736:2021, Taxonomy and definitions
for terms related to driving automation systems for on-road motor vehicles, 2021, reconfirmed 2026.
[4] G.-Z. Yang et al., “Medical robotics—Regulatory, ethical, and legal considerations for increasing levels of
autonomy,” Science Robotics, vol. 2, no. 4, eaam8638, Mar. 2017.
[5] SAE International, Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road
Motor Vehicles, Recommended Practice J3016_202609, Sept. 20, 2026.
[6] International Electrotechnical Commission, IEC 62304:2006+AMD1:2015, Medical device software — Software
life cycle processes, 2015.
[7] International Electrotechnical Commission, IEC 62366-1:2015+AMD1:2020, Medical devices — Part 1:
Application of usability engineering to medical devices, 2020.
[8] T. C. Lee, J. Senecal, J. M. Hsu, and E. G. McDonald, “Ongoing Citations of a Retracted Study Involving
Cardiovascular Disease, Drug Therapy, and Mortality in COVID-19,” JAMA Internal Medicine, vol. 181, no. 11,
pp. 1535–1537, 2021.
[9] U.S. Food and Drug Administration, “Medical Devices; Quality System Regulation Amendments,” Final Rule, 89
Fed. Reg. 7496, Feb. 2, 2024, codified at 21 C.F.R. Part 820, Quality Management System Regulation, effective
Feb. 2, 2026, incorporating by reference ISO 13485:2016, Medical devices — Quality management systems —
Requirements for regulatory purposes.
[10] D. Brière and P. Traverse, “AIRBUS A320/A330/A340 electrical flight controls — A family of fault-tolerant
systems,” in Proceedings of the 23rd International Symposium on Fault-Tolerant Computing (FTCS-23),
Toulouse, France, 1993, pp. 616–623.

VBA-REG-FDA-2026-001 | Version 001 | Docket No. FDA-2026-N-7874 Page 13 of 13