Capacity Health

Please see the attached comment of Capacity Health, Inc. on Docket No. FDA-2026-N-7874.

Comment of Capacity Health, Inc. on Docket FDA-2026-N-7874,
Considerations for the Regulation of Generative AI-Enabled
Medical Devices: Discussion Paper and Request for Feedback
Capacity Health, Inc. develops software for emergency department care, including clinicianfacing decision support that combines continuous physiologic monitoring with the clinical record,
and a patient-facing conversational system that checks in with patients after emergency
department discharge and escalates deviations from expected recovery to a care team. We
respond to discussion questions 1, 5, 6, 9, and 11.

Question 1: the two-axis framework
The framework’s two axes are appropriate. We suggest one modifier be represented explicitly:
whether the generative function’s safety-critical behaviors are bounded by deterministic controls
that the generative component cannot override. A conversational function whose escalation
decisions are made by a deterministic evaluator running on every message, which can force an
escalation but cannot be argued out of one, sits materially lower on the consequence axis than
the same function relying on the language model’s own judgment, even though the two are
indistinguishable at the level of intended use. The framework already gestures at this in its
treatment of continuous professional supervision; we suggest that non-suppressible
deterministic control of the safety-critical output be treated as an equivalent modifier.
Reversibility of the resulting action and traceability of the output to primary sources, both named
in the question, are also useful, and traceability in particular is easily testable.

Question 5: conversational trajectories and emergent intended use
We agree that risk should be assessed across realistic conversational trajectories and not only
per function. The practical difficulty is that a trajectory is not a fixed input, so exhaustive testing
is impossible and the sponsor must instead characterize behavior over a distribution of
trajectories. This becomes tractable when the trajectory distribution is anchored to real
encounters. A simulation harness in which a simulated patient, built from a de-identified real visit
including its clinical course, converses with the device while an independent judge scores each
turn and the whole exchange against prespecified criteria can produce repeatable, auditable
trajectory-level evidence, and can surface the failure modes the paper anticipates, such as drift
from information toward medical direction over a long exchange, and adoption of a confused
patient’s framing.
On characterizing intended use when behavior is emergent: we suggest the intended use be
stated in terms of the device’s escalation contract rather than its conversational content.
Specifically: what triggers an escalation, who receives it, and what the patient is told when
escalation is triggered. The conversation is the means for the contract, and it is the contract that
should be evaluated, labeled, and held constant across model and prompt changes.

Question 6: both directions of escalation error
Under-escalation and over-escalation are not equivalent and should not be collapsed into one
accuracy figure. We suggest the following structure. The primary safety endpoint of an
escalation function should be its false-negative rate for adjudicated safety-critical events,
estimated against a reference set built from real conversations and adjudicated by clinicians
independent of the sponsor, with the adjudication procedure written before the events are
reviewed. The over-escalation rate should be reported alongside it, together with its
downstream consequences where they can be measured (unnecessary contacts, visits, or
tests), because the burden of over-escalation falls on patients and health systems and shapes
whether the function stays in use. The acceptable trade-off between over- and under-escalation
depends on the clinical context and the population, and we suggest it be stated in labeling
rather than fixed by rule. A device designed with mandatory over-escalation, in which a
deterministic layer can force an escalation the generative layer would not have made, accepts a
higher over-escalation rate as the price of a bounded false-negative rate. This design choice
should be visible to the reviewer and to the user.

Question 9: benchmarking structure
The proposed elements map closely onto the ways conversational devices fail in practice. We
suggest three additions. First, an element for deterministic control coverage: which safetycritical behaviors are governed by deterministic logic, whether that logic runs on every input and
every candidate output, and what the device does when the generative component is
unavailable, since a device that degrades to a scripted fallback is a different device from one
that degrades to silence. Second, adversarial testing under element S.2 (scope maintenance)
should be versioned and re-run on every change to the model, prompt, retrieval, or
orchestration, so that the benchmark is a regression suite and not a one-time gate. The paper’s
postmarket section implies this; we suggest making it explicit. Third, provenance: whether the
device can show the source of each clinical statement it makes, which supports both the user’s
independent review and the reviewer’s audit.
On adjudicator independence, we agree that adjudicators should be structurally independent of
the sponsor and of the foundation-model developer, and we note that the same standard should
apply when the adjudicator is itself a language model: an evaluating model from the same
developer as the device’s model, or from the sponsor, is not independent.

Question 11: clinical confirmation
The ladder is right, and its middle rungs are most important for patient-facing conversational
devices. Retrospective evaluation on real patient inputs, shadow deployment, and clinician
adjudication of real cases can each be run before any patient is exposed to device outputs, and
together they characterize the device under the distribution of inputs it will actually see. A
prospective study answers a different question (whether the device changes outcomes) and
should be required in proportion to the device’s position on the two axes, rather than by default.
Sample sizes for these approaches are naturally framed around bounding the false-negative
rate for safety events (the width of the interval on the primary safety endpoint) rather than
around effectiveness endpoints. The anticipated distribution of real-world inputs can be
estimated directly from a shadow deployment, which is the strongest argument for making
shadow deployment a standard step.
On synthetic data: synthetic patients modeled on real de-identified visits are useful for
exercising rare and adversarial trajectories, and we agree with the paper’s caution that synthetic
data generated by models of the same class as the device can reproduce the gaps the
evaluation exists to detect. We suggest using synthetic inputs to widen coverage and real inputs
to estimate performance, never combining the two into a single estimate.
Postmarket
We support the paper’s direction on postmarket monitoring and note that a deployed
conversational device can generate the evidence continuously: every interaction can be
recorded with the prompt and model version in effect, sampled for independent clinician review
on a defined cadence, and re-benchmarked against the premarket suite after any change. A
predetermined change control plan is the natural instrument for the deterministic components of
such a device. For the generative components we suggest the premarket benchmark, re-run
and reported, is the more workable control until the field has more experience.
Capacity Health would be glad to discuss any of these points with the Center.