Karan Tejpal

Please see the attached comment, which responds to Questions 19, 20, 21, 22 and 24 (Postmarket Monitoring). In summary, I recommend that FDA require postmarket monitoring plans that name an owner for each monitoring task, pre-specify measurable reassessment triggers, monitor performance by subgroup and site, validate the monitoring system itself, re-benchmark after foundation model changes, and encourage a minimal common data specification for postmarket monitoring.

Comment on Docket FDA-2026-N-7874
Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and
Request for Feedback
Submitted by Karan Tejpal, as an individual
Responding to Questions 19, 20, 21, 22 and 24 (Section VI, Postmarket Monitoring)

Commenter background
I am submitting this comment as an individual. I am a Business Intelligence Engineer with more
than eight years of experience in analytics engineering, healthcare data and AI-enabled workflows,
and an IEEE Senior Member.

At the Massachusetts Department of Public Health, I built surveillance dashboards and
HIPAA-compliant data pipelines for perinatal and infant health, including Neonatal Abstinence
Syndrome tracking and birth defects monitoring. I have also published IEEE research on AI in
personalized medicine.

My comment draws on that operational experience. Public health surveillance has spent decades
solving a problem the discussion paper now faces: how to watch a changing system continuously,
decide when a change is real, and make sure someone is responsible for acting on it.

Summary
The discussion paper's postmarket proposals (periodic re-benchmarking, sample-based clinician
review and monitoring for performance degradation) are sound. Their weak point is operational:
each one is a recurring task that needs a named owner, a data feed, a decision rule and a deadline,
and in most deploying organisations none of these exists today.

I recommend that FDA:

1. Require a postmarket monitoring plan that names who does each monitoring task, while
keeping the manufacturer accountable for the outcome (Q21).

2. Ask manufacturers to pre-specify quantitative triggers and a risk-scaled cadence for
reassessment (Q19).

3. Make subgroup and site-level monitoring the default, with explicit handling of small samples
(Q19).

4. Treat the monitoring system itself as something to validate, including any machine-based
supervisory agents (Q20).

5. Treat a change to an underlying foundation model as a trigger for re-benchmarking against a
fixed reference set (Q22, Q24).

Karan Tejpal · Comment on FDA-2026-N-7874 Page 1
6. Publish a minimal common data specification for postmarket monitoring, so deploying
institutions can supply what manufacturers need (Q21).

The operational ownership gap
A locked algorithm can be approved once because it behaves the same way afterwards. A
generative AI-enabled device does not. Its outputs can shift when the foundation model is updated,
when prompts or guardrails change, or when the patients and clinical workflows at a site change.
Oversight therefore becomes a continuous operational function, not a single approval.

That function needs four things to work: data showing how the device performs in use, a rule for
deciding when a change matters, a person or team responsible for applying the rule, and a defined
response when the rule fires. In my experience, the data usually sits with the deploying institution,
the decision rule is often undefined, and responsibility is split between the manufacturer, the
foundation model developer and the institution's clinical and IT teams. When no one owns the
whole loop, degradation is found late, through complaints or adverse events rather than
monitoring.

Public health surveillance offers a useful model. A state health department watching birth
outcomes or disease reports works from case definitions, fixed reporting cadences, statistical
thresholds that distinguish signal from noise, and named epidemiologists who must investigate
when a threshold is crossed. The same structure can make postmarket monitoring of generative AI
devices dependable.

Recommendations
1. Name an owner for every monitoring task (Q21)
FDA could ask manufacturers to submit a postmarket monitoring plan that assigns each recurring
task (data collection, re-benchmarking, sample review, threshold review, escalation and corrective
action) to a named role. The plan should state what the deploying institution must supply and how
often. Institutions and clinicians can carry defined duties, such as supplying data or completing
review samples, while the manufacturer stays accountable for detecting and acting on degradation.
Written roles prevent diffusion of accountability; unwritten ones cause it.

2. Pre-specify triggers and a risk-scaled cadence (Q19)
Reassessment should happen on a fixed schedule and also on defined events. The schedule can
scale with the paper's two-axis risk level, for example quarterly for higher-risk devices. Event
triggers should be written in advance and be measurable, such as:

• a new version of the underlying foundation model, prompts or guardrails

• a shift in the distribution of inputs beyond a stated threshold, measured with a standard statistic
such as the population stability index

Karan Tejpal · Comment on FDA-2026-N-7874 Page 2
• a fall in a monitored performance measure beyond a stated tolerance

• a rise in complaints, overrides or clinician corrections above baseline

Each trigger should map to a response tier, such as “review within 30 days” versus “suspend the
affected function”. Surveillance systems use the same graded approach to avoid both missed
signals and alarm fatigue. Where many measures are checked at once, manufacturers should
control for false alarms, for example with false discovery rate methods.

3. Monitor by subgroup and site, with small samples handled explicitly (Q19)
Aggregate performance can stay stable while performance falls for a particular patient group,
language, care setting or site. Monitoring plans should report performance by the subgroups and
sites most likely to differ, and should say how they will handle groups too small to measure
reliably in one period, for example by pooling over time or borrowing strength from the overall
estimate. Without this, monitoring is least sensitive for the populations most likely to be
underserved.

4. Validate the monitoring system itself (Q20)
A monitoring system can fail silently. FDA could ask manufacturers to show that their monitoring
detects degradation, for example by backtesting on historical data or by injecting known changes
into test data and reporting how many are caught and how many false alarms result, broken down
by subgroup and site size. Machine-based supervisory agents can usefully extend sample-based
review, but they should be calibrated against human-reviewed samples at the start and checked
again on a schedule, because a supervisory model can drift too. I have released an open-source
example of this approach for county perinatal surveillance, which validates its own detection by
injecting known changes and reports sensitivity and false alarms by county size (perinatal-ews,
https://doi.org/10.5281/zenodo.23374047).

5. Re-benchmark against a fixed reference set after model changes (Q22, Q24)
When the manufacturer does not control the foundation model, it needs advance notice of changes
and a way to test them. FDA could expect manufacturers to (a) pin and log the model version in
use, (b) secure contractual notice of planned updates from the model developer, and (c) maintain a
fixed, versioned reference set on which every new model version is re-benchmarked before it
reaches patients. The extent of re-benchmarking can scale with the size of the change and the
device's risk level, and routine changes that pass pre-specified acceptance criteria could fall under a
PCCP or quality management system.

6. Publish a minimal common data specification (Q21)
Many hospitals and clinics lack the analytics capacity to build monitoring feeds for each device
separately. A minimal common specification would make monitoring feasible at scale. It could
cover model version, timestamp, input category, output, clinician action (accepted, edited or
overridden) and site, with privacy safeguards. Public health reporting shows that common case

Karan Tejpal · Comment on FDA-2026-N-7874 Page 3
 definitions and fields are what make data from many sources comparable. Industry groups could
maintain the details; FDA's role would be to encourage convergence.

Closing
The discussion paper rightly moves oversight of generative AI-enabled devices from a single
approval to continuous monitoring. That shift will succeed only if monitoring is treated as an
operational system with owners, data, decision rules and validation, not as an obligation stated in
general terms. Public health surveillance shows this is achievable. I thank FDA for the opportunity
to comment and would welcome further discussion.

Karan Tejpal
Business Intelligence Engineer; IEEE Senior Member
Burlington, Massachusetts
ORCID: 0009-0004-8609-2854

Karan Tejpal · Comment on FDA-2026-N-7874 Page 4