Precision Health Ventures (A.R. Henderson)

Docket No. FDA-2026-N-7874
Comment of Precision Health Ventures (Arlington, Virginia)

Precision Health Ventures is a small operating holding company. Its platforms include IntelaCare PBC (a Medicare-enrolled clinical AI practice and CMS ACCESS Model participant whose clinical intelligence layer is being built as software as a medical device) and SHIRLe Health / HealthDigits (a patient-controlled health record platform and 2026 ASTP/ONC EHIgnite Phase 1 winner). We support the direction of the discussion paper and answer Questions 1, 2, 3, 5, 6, 9, 12, 14, 18, 19, 20, 22 through 24, 25, and 26 in the attached letter, which opens with a plain-language definition of the terms it uses.

Our central recommendation is that the activity axis of the two-axis framework be treated as a measured runtime setting of each thing a device can do (off, propose, or auto) rather than an attribute declared at submission. A device can be authorized with a ceiling and operate below it until a recorded track record of human approvals justifies moving up. We describe the decision ledger, automatic reversal on quality degradation, and permanently never-earnable actions that make this inspectable, and show how they answer the questions on multi-turn drift, greater reliance on postmarket monitoring, supervisory agents, PCCP adaptation, and third-party foundation model changes.

For care escalation we recommend that sponsors report sensitivity, specificity, and time to escalation separately and declare in advance which failure mode they have accepted per clinical context; under-escalation and over-escalation are different failures and a blended accuracy score hides both. For patient-facing functions we recommend placement by whether outputs are traceable to the patient’s own record and whether uncertainty is stated in human terms, rather than a category-wide upward shift. We also ask CDRH to recognize that a model pinned on sponsor- or patient-controlled hardware is itself a change-control answer.

The full comment letter is attached.

A.R. Henderson
Managing Partner, Precision Health Ventures
ahenderson@PrecisionHealthVentures.com | 703-957-0110

PHV Comment, Docket No. FDA-2026-N-7874

Precision Health Ventures
2200 Wilson Blvd., Suite 102-205, Arlington, VA 22201

October 18, 2026
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 AIEnabled Medical Devices: Discussion Paper and Request for Feedback
Precision Health Ventures (PHV) thanks the Center for Devices and Radiological Health
(CDRH) and its Digital Health Center of Excellence for the discussion paper. We support its
direction. This letter answers sixteen of the twenty-six questions, chosen because we have built
and operated the mechanisms the questions ask about. Section 2 defines the handful of terms
the letter relies on, so that a reader does not need prior familiarity with our work to follow the
argument.

1. Who We Are
PHV is a small operating holding company in Arlington, Virginia. We are commenting as a
prospective sponsor: one of our platforms is being built toward FDA oversight, and the
approaches CDRH adopts will apply to us directly.
• IntelaCare PBC is a Medicare-enrolled clinical AI practice participating in the CMS
ACCESS Model. Its clinical intelligence layer is being designed as software as a medical
device. In an ARPA-H proposal, IntelaCare described that layer with a three-level ladder
(informational support, clinical recommendation, executable action within protocol) and
automatic escalation to a clinician when uncertainty crosses a threshold. That ladder is, in
effect, the activity axis in the discussion paper.
• SHIRLe Health and HealthDigits are a patient-controlled health record platform, a 2026
Phase 1 winner of the ASTP/ONC EHIgnite Challenge. It reads a patient's electronic
health information export, photographed documents, and patient-authorized device
streams, and uses generative AI to help patients and caregivers understand their own
records. It is patient-facing, the population the paper treats with the most caution.
• Affinity Networks Inc., PHV's affiliate, publishes the Earned Autonomy governance
framework and the executive white paper Sensitivity, Specificity and Latency. Both are
drawn on throughout this letter and are available on request. The governance mechanisms
described in Section 2 are the subject of a pending United States patent application.
Our founder spent years building submarine command and control systems, where the age of a
data point is a safety property. That experience shapes the emphasis on latency and detection
in this letter.

2. Five Ideas This Letter Uses

Page 1 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

Each idea is stated in plain language with one example. Later sections refer back to them by
name.

2.1 Sensitivity, specificity, and latency
Sensitivity is how often a system notices a real event when one is present. Specificity is how
often it stays quiet when nothing is wrong. Latency is the total time from an event occurring to
the organization acting on it, including every human review step, not just network or computing
time. A device that misses a real event produces false confidence; a device that raises constant
false alarms produces fatigue and is eventually ignored or switched off. The two failures are not
the same failure, they are not measured the same way, and a single headline accuracy score
hides both. In the discussion paper's vocabulary, under-escalation is a sensitivity failure and
over-escalation is a specificity failure.

2.2 Earned autonomy
Earned Autonomy is a governance framework in which every action an AI system can take is
listed in advance, and each listed action has one of three settings: off (the system cannot do it),
propose (the system drafts the action and a human must approve before anything happens), or
auto (the system does it and records it). Everything starts at propose. The system may
recommend moving an action to auto only after a track record of human approvals clears a
stated evidence gate; the reference implementations use ten decisions with at least ninety
percent accepted. Only a human can grant that promotion. The system cannot promote itself. In
healthcare deployments the framework's stated posture is that clinical actions stay at propose.
Example: a device drafts a medication change. At propose, the draft waits for a clinician. If the
clinician approves ninety-five of the last hundred such drafts, the system may ask to be
promoted to auto for that one action; a human decides whether to grant it. The approving
human is not always a clinician: for an action on the patient's own record, such as filing a
captured document or sharing a summary, the patient or their caregiver is the one who
approves.

2.3 The decision ledger
Every proposal, approval, rejection, and automatic action is written to an append-only log,
together with the state of the data before the change. Because the before-state is kept, any
change can be rolled back. The ledger is what makes a track record possible, and it is the
evidence base for everything postmarket.

2.4 Automatic reversal and never-earnable actions
The framework includes two further mechanisms. First, automatic reversal: an action at auto is
monitored against its own history and drops back to propose automatically when quality falls
below a stated threshold, on a rollback, on a change of the underlying model, or on a change of
scope. Second, a never-earnable class: some actions can never reach auto no matter the track
record; in our implementations these include sharing patient data outside the trust boundary and
changing consent. The framework also treats consent and autonomy as two separate axes, so
permission to read a class of data never implies permission to act on it.

2.5 Provenance and patient control

Page 2 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

In the Person-Sovereign Health Record architecture, every fact in the record carries its source,
date, and who recorded it (provenance), and the AI is required to cite the entries it relied on.
Consent is enforced as routing: the AI can only read the parts of the record the patient has
authorized, so it cannot drift into data outside its scope. The architecture also allows the model
itself to run on hardware the patient or sponsor controls rather than on an AI vendor's platform.
Our published position is that health intelligence should run where the patient controls the data,
not the other way around.

Term What it means in this letter

Action class One specific thing a device can do, such as draft a medication change or
send a message to a clinician.

Gate The single check every action passes through. It fails closed: anything not
explicitly enabled is refused and logged.

Oversight latency The time between a system acting or changing and a human noticing. From
the Sensitivity, Specificity and Latency white paper.

Behavioral A fixed set of inputs with expected outputs, re-run on a schedule to detect that
fingerprint an underlying model has changed.

Pinned baseline The premarket benchmark battery kept unchanged so that it can be re-run
identically after a modification.

3. Summary of Recommendations
1. Treat the activity axis of the two-axis framework as a measured runtime setting of each
action class (off, propose, auto), not a fixed attribute declared at submission. A device can
be authorized with a ceiling and operate below it until evidence justifies moving up.
2. Add reversibility and a human decision gate as modifiers on the activity axis, and
provenance (traceability to the patient's own record) as a modifier on the consequences
axis.
3. For care escalation, require sponsors to report sensitivity and specificity separately, to
declare which failure mode they have accepted for each clinical context, and to report time
to escalation as a third metric. Do not accept a blended accuracy score.
4. Accept greater premarket uncertainty only when the device ships with a decision ledger,
automatic reversal, and a stated set of never-earnable actions, and only for action classes
below the severe consequence band.
5. Define postmarket reassessment by triggers rather than by calendar, set a maximum
oversight latency per risk band, and require any machine-based supervisory agent to be
governed by the same gate, with deterministic checks owning pass or fail.
6. Recognize automatic reversal on a foundation model change as a valid Predetermined
Change Control Plan (PCCP) mechanism, and recognize that a model pinned on sponsoror patient-controlled hardware removes the unannounced-change problem entirely.

Page 3 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

7. Do not shift patient-facing functions upward on the consequences axis as a class. Place
them according to whether outputs are traceable to the patient's own record and whether
uncertainty is stated in human terms.

4. Responses to Selected Questions
Each response follows the same shape: what CDRH asked, what we recommend, why, and an
example.

Section IV: Considerations for the Assessment of Risk for GenAI-Enabled Devices

Question 1. Does the two-axis framework capture the right dimensions? Should
reversibility, downstream safeguards, time pressure, or traceability be added, and how?
Recommendation. Keep the two axes. Add reversibility and downstream safeguards as a
single modifier on the activity axis, and traceability as a modifier on the consequences axis.
Handle time pressure in benchmarking, not in the risk framework.
Why. Reversibility and safeguards both reduce to one question: does the action commit without
a human decision? An action at propose does not commit; an action at auto commits but can be
rolled back from the ledger; an action with neither is the true worst case. Representing this as a
setting on the activity axis lets CDRH see the safeguard without a third axis. Traceability
belongs on the consequences axis because an output the user can check against the source is
less dangerous than one the user cannot, the same logic the paper already applies to
measurement outputs the user cannot independently assess. The consequences axis can also
be anchored to an existing clinical taxonomy: the Earned Autonomy framework maps its
consequence tiers to the American Medical Association's CPT Appendix S taxonomy for AI
services, and CDRH could anchor its bands the same way.
Example. Two devices both draft insulin adjustments. One queues the draft for a clinician, or for
the patient in a patient-facing device (propose). The other applies it (auto). They sit at different
points on the activity axis even though their outputs are identical, and the ledger proves which
one each device is.

Question 2. How should CDRH handle the continuum between non-directive and actiondirecting information? What output characteristics modify risk, and what would give
sponsors predictability?
Recommendation. Use a mechanical test instead of a wording test: would the output be acted
on by the device, or by a downstream system, absent a human decision? Ask sponsors to
enumerate every action class the device can reach and the maximum setting for each.
Why. CDRH is right that words like recommend or should, and disclaimers like talk to your
doctor, do not settle directiveness. A list of action classes with settings does. The sponsor does
not argue about adjectives; it shows the list and the ledger. CDRH can compare lists across
submissions and inspect them after authorization.
Example. The paper's four lisinopril outputs. A device that can only display the fourth one
(increase from 10 mg to 20 mg) is action-directing. A device that can queue it as an order is
action-taking at propose. A device that can place the order is action-taking at auto.

Page 4 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

Question 3. When does delivering clinical information to patients rather than clinicians raise
risk, and what safeguards mitigate it without underestimating patients?
Recommendation. Do not treat patient-facing functions as higher risk by category. Condition
placement on four testable safeguards: provenance (each statement cites the record entry it
came from), uncertainty stated in human terms tied to what the record contains, layered detail
the patient controls, and scope enforced by consent routing.
Why. More than eighty percent of health happens outside a clinic, and patients are routinely
handed records they cannot interpret. A device built so that its outputs can be checked against
the patient's own record supports the patient's capability rather than assuming its absence. Our
co-design cohort includes older Medicare beneficiaries, members of the disability community,
caregivers acting as proxies, and people with low digital literacy, and they can evaluate an
output when the output is built to be evaluated. A blanket upward shift would also push
sponsors toward over-escalation to compensate, which the paper itself lists as a harm.
Example. A patient asks why a lab value is flagged. The device answers with the value, the
date, the lab that reported it, and the prior values it compared against, and says plainly that it
has no record of the medication change the patient mentions. The patient can see what the
device knew and did not know.

Question 5. For multi-turn conversations that drift from non-directive to action-directing,
how should risk be assessed, and how should intended use be characterized?
Recommendation. Classify each output by action class at the gate, not the conversation as a
whole. Characterize intended use as the list of action classes the device can reach, the
maximum setting for each, and the data scopes it may read.
Why. If every output passes the gate, drift is a sequence of logged per-output checks, and the
device cannot reach an action it is not permitted to reach no matter how the conversation
arrived there. Trajectory testing is still needed to confirm the classifier is reliable, but the risk
question changes from what the device might say by turn twelve to whether it can ever commit
an action it was not permitted to commit. The list of action classes is stable even when
conversational behavior is not, and it is exactly what is re-verified after a modification.

Question 6. How should sponsors characterize and weigh under-escalation and overescalation, given they may not be commensurable and acceptable trade-offs vary by
context?
Recommendation. Require three separate numbers per clinical context: sensitivity (share of
true emergencies escalated), specificity (share of non-emergencies not escalated), and time to
escalation. Require the sponsor to state in advance which failure mode it has accepted for that
context and why. Reject any single blended accuracy figure.
Why. The two errors are different in kind. A missed emergency is silent and produces false
confidence. A false alarm is loud and produces fatigue, unnecessary utilization, and eventually a
device that patients and clinicians stop trusting. Every deployed device embeds a choice
between them; if the sponsor has not made it explicitly, a default setting has. Latency is the third
dimension the paper's framing leaves out: an escalation that is correct but late is functionally a
miss.

Page 5 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

Example. Chest pain triage: sensitivity floor near certainty, lower specificity accepted, time to
escalation measured in seconds. Pediatric sore throat: specificity weighted higher to avoid
unnecessary urgent care visits, with the sponsor stating the sensitivity it accepts and the redflag features that override it.

Section V: A Competency-Based Approach for Premarket Evaluation of GenAIEnabled Devices

Question 9. Would the benchmarking structure provide adequate evidence of clinical
knowledge, analytic capabilities, safety behavior, communication, and generalizability? Are
elements missing, redundant, or inappropriately categorized?
Recommendation. The elements cover what the device says. None of them owns how long the
device takes. Add latency as a measured benchmarking dimension, and require element S.1
(safety-critical recognition and escalation) to report sensitivity and specificity as separate
numbers per clinical context, never a blended score.
Why. Latency is a system property: the total time from input to escalation, including every
review step, not computing time alone. An escalation that is correct but late is functionally a
miss, and a benchmark that scores only the content of outputs will pass a device that is
unusable under the time pressure of its deployment setting. Our Question 1 response
recommended keeping time pressure out of the risk framework precisely because it belongs
here, in benchmarking, as a condition the safety battery runs under.
Example. Two devices score identically on S.1 content. One returns its escalation in four
seconds, the other in four minutes after a queued review pass. For a chest pain function they
are not the same device, and only a latency dimension in the battery shows it.

Question 12. How should sponsors achieve statistically meaningful performance
measurement for GenAI-enabled devices?
Recommendation. Require measurement per error direction, with the rare high-consequence
cases oversampled, and reject any single headline accuracy figure.
Why. When the event of interest is rare, headline accuracy is dominated by the easy majority
class. A triage function that never escalates scores ninety-nine percent accurate on a population
where true emergencies are one percent of inputs, while being useless for the one job that
matters. Statistically meaningful measurement for these devices means a sensitivity estimate
with adequate power on the rare class, a specificity estimate on the common class, and
confidence intervals on each, reported separately. This also disciplines the use of synthetic
data: a synthetic supplement is acceptable where it tightens the estimate on the rare class and
is validated against real cases of that class, not where it inflates the easy majority.

Question 14. For open-ended outputs, how should performance comparators and
acceptance criteria be selected, and how should the applicable standard be defined when a
clinician panel is the comparator?
Recommendation. Require the sponsor to state which error direction the chosen comparator
standard tolerates, because choosing a comparator is choosing a failure mode. When human-AI
team performance is the basis for evaluation, measure team latency alongside team accuracy.

Page 6 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

Why. A clinician panel is not a neutral yardstick. It has its own sensitivity and specificity, and the
two candidate standards the paper names embed different trade-offs: the standard of care tends
to encode conservative escalation (higher sensitivity, more false alarms), while the median
clinician in practice encodes the real-world balance, including its misses. A device judged
acceptable against one can fail against the other on the same outputs. Making the tolerance
explicit turns the comparator choice into a reviewable decision instead of an implicit one. And
where the device is evaluated as part of a human-AI team, the team is the system: a device that
improves accuracy while doubling the time to decision has degraded the property that matters
most in escalation contexts, and only a latency measure on the team shows it.

Section VI: Postmarket Monitoring for GenAI-Enabled Devices

Question 18. When is it appropriate to accept greater premarket uncertainty through
postmarket monitoring, and what must a monitoring program include?
Recommendation. Accept it only when the device ships with all three of: a decision ledger,
automatic reversal, and a stated set of never-earnable actions. Accept it for informational and
propose-setting functions across the consequences axis, and for auto-setting functions in the
limited and moderate bands. Do not accept it for auto-setting functions in the severe band;
those should require full clinical confirmation, and auto should be earned after deployment
under supervision, if ever.
Why. Premarket uncertainty about autonomous behavior is tolerable only if the device becomes
less autonomous tomorrow when it performs worse today, without waiting for a sponsor
meeting. Automatic reversal is that guarantee. The ledger is the evidence that reversal is
working. Never-earnable actions bound the worst case. Our own healthcare posture is more
conservative than this: clinical actions stay at propose.

Questions 19 and 20. Comment on periodic re-benchmarking, sample-based clinician
review, and degradation monitoring; how should cadence and triggers be set; and can
machine-based supervisory agents help, with what safeguards?
Recommendation. Set triggers first and cadence second. Mandatory re-benchmarking against
the pinned baseline on: a foundation model version change, a change to prompts, retrieval
corpus, or orchestration, a drift metric crossing its threshold, or any automatic reversal event.
Set a maximum oversight latency per risk band, meaning the longest permitted time between
one of those events occurring and a human at the sponsor knowing about it. Draw clinician
review samples from the ledger, stratified by action class and setting, so reviewers see rejected
proposals as well as auto actions.
On supervisory agents. Useful, and only if governed by the same rules as the device. A
supervisory agent may summarize, classify, reconcile, and flag. It may not own a pass or fail
determination; that belongs to a deterministic check or a human. Its own outputs go in the
ledger. It sits in the same capability register and can act in no class the device cannot. And it
should not share the device's foundation model, because shared failure modes will be invisible
to it. CDRH already requires adjudicators to be structurally independent of sponsor and model
developer; that rule applies with equal force when the adjudicator is a model.
Why detection matters most. In July 2026 two leading AI laboratories disclosed that their own
models, during controlled evaluations, left their test environments and reached the live systems

Page 7 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

of outside organizations. In one case two of the three affected organizations did not detect the
activity until the laboratory contacted them. The incidents are not evidence of uncontrollable AI.
They are evidence that the control surface that fails is monitoring and containment, not model
quality, and that the affected party is usually the last to know. Oversight latency is the metric
that captures this.

Questions 22 through 24. How should re-benchmarking scale with a modification; which
changes belong in a QMS, a PCCP, or a new submission; how should PCCP concepts
adapt when changes cannot be prespecified; and how should third-party foundation model
changes be detected and handled?
Recommendation. Key the change ladder to one question: does the change reset earned
autonomy for any action class? Changes that do not touch the model, prompts, retrieval,
orchestration, or gate logic belong in the sponsor's quality management system. Changes that
touch those but leave the action class list and never-earnable set unchanged are PCCP
candidates, with the PCCP stating that every affected class drops to propose and must re-earn
auto under the prespecified gate. Changes that add an action class, add a data scope, or
remove a never-earnable restriction require a new submission.
Why. A PCCP cannot prespecify what a future foundation model will do. It can fully prespecify
what happens to the device's autonomy when the model changes: affected classes drop to
propose, the pinned baseline is re-run, auto is re-earned class by class. The modification is
unknown in advance; the governance response is not. The Earned Autonomy framework
already maps this loop to CDRH's PCCP guidance for exactly this reason.
On third-party model changes. Three layers. Technically: pin the model version where the
vendor allows it, and where it does not, run a behavioral fingerprint on a schedule tight enough
to detect an unannounced change within the oversight latency for the device's risk band.
Contractually: obtain change notification and a minimum deprecation period. In the PCCP: an
unannounced or fingerprint-detected change is a reversal trigger. There is also a fourth option
the paper does not mention: run the model on hardware the sponsor or patient controls, so that
it cannot change without the sponsor's action. Our patient-record platform is built to allow this,
and the Earned Autonomy framework formalizes it as governed model selection: the person or
sponsor selects the model for each task type, every selection and change is recorded in the
ledger, and the model changes only by a recorded human act. We ask CDRH to state explicitly
that automatic reversal on model change is an acceptable PCCP mechanism, and to recognize
that a locally pinned model is itself a change-control answer.

Section VII: Other Topics

Question 25. Would voluntary Foundation Model Master Files be practical, what should
they contain, and what alternatives should CDRH consider?
Recommendation. Make commitments the core content, not disclosures: a versioning scheme
with a promise that behavior does not change within a version, a change notification
commitment with minimum notice, a deprecation timeline, documentation of refusal and contentpolicy behavior (these are often the safety-critical behaviors and are often changed silently), and
a statement on whether sponsor inputs are used for training. Subgroup evaluation results are

Page 8 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

useful but secondary, because the sponsor must generate its own on the deployed device
regardless.
Alternative. Where a model developer declines to file, require the sponsor to file the model
version and a behavioral fingerprint at submission. That gives CDRH a reference point for any
later dispute about whether the model changed, and it falls on the sponsor rather than on
voluntary participation. More broadly, a framework that depends on the goodwill of the
companies that hold both the model and the data has placed the control point in the wrong
place. Sponsors and patients should be able to keep the control point on infrastructure they
govern.

Question 26. What additional considerations apply to agentic devices, and how should the
risk of autonomous multi-step action, tool use, and reduced human review be reflected?
Recommendation. Four additions to element A.1. Gate every step, not every task: a plan that
is in scope overall can contain a step that is not. Gate by data class as well as action class:
reading a data class should not imply the right to write, share, or act on it. Make the human
checkpoint before an irreversible or severe-consequence action a never-earnable requirement,
not only a tested competency; the checkpoint human is the clinician for clinical actions and the
patient for actions on the patient's own record. Test prompt injection through tool outputs and
retrieved content, not only through user turns.
Why. A fail-closed gate is the most reliable defense we have found against injection, because
an injected instruction has to name an enabled action to succeed. The July 2026 incidents also
show that the environment an agent is tested in is part of the device: benchmarking
environments for agentic devices should be isolated and monitored, and CDRH should ask
sponsors to describe that containment.

5. Closing
The discussion paper asks, in several places, how CDRH can reason about a device whose
behavior is not fixed. Our answer is to require the device to carry a governance structure that is
fixed even when the behavior inside it is not: a list of action classes, a setting for each, a ledger
of every decision, an automatic path downward when performance degrades, and a set of
actions that can never be automated. That structure can be reviewed premarket, inspected
postmarket, and re-verified after any change. Our founder's operating rule from mission-critical
systems applies: do not approve automation until its owner can explain what it misses, what it
overreacts to, and how long it takes to act. Additional information on the Earned Autonomy
framework, the Person-Sovereign Health Record architecture, and the analyses described in
this letter is available from PHV on request, and we would welcome the opportunity to discuss
any of this with the Digital Health Center of Excellence. Interested parties may contact us at the
address below.
Respectfully submitted,

A.R. Henderson
Managing Partner, Precision Health Ventures
President and CEO, Affinity Networks Inc.
ahenderson@PrecisionHealthVentures.com | 703-957-0110

Page 9 of 10
 PHV Comment, Docket No. FDA-2026-N-7874

6. References
• FDA. Marketing Submission Recommendations for a Predetermined Change Control Plan
for Artificial Intelligence-Enabled Device Software Functions. December 2024.
• NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.
• OpenAI (July 21, 2026) and Anthropic (July 30, 2026), public disclosures of model
evaluation incidents.

Page 10 of 10