Device Events (Madris Kinard)

Comments submitted by Madris Kinard

October 19, 2026
Dockets Management Staff
U.S. Food and Drug Administration
Re: Docket FDA-2026-N-7874

I appreciate the opportunity to comment on FDA’s consideration of regulatory approaches
for generative artificial intelligence (GenAI)-enabled medical devices. I am the founder and
CEO of Device Events and a former FDA Center for Devices and Radiological Health (CDRH)
medical device adverse event reporting subject matter expert. My work at FDA included the
MAUDE replacement initiative and stakeholder engagement for the Unique Device
Identification (UDI) program and Global Unique Device Identification Database (GUDID). My
subsequent work has focused on adverse event surveillance, device traceability, recalls, and
identifying emerging medical device safety signals.
Before FDA substantially expands its regulatory framework for GenAI-enabled medical
devices, I believe it must address longstanding gaps in adverse event reporting, device
identification, and traceability. These foundational weaknesses already limit FDA’s ability to
identify safety problems with conventional medical devices and will become even more
consequential as AI-enabled devices gain greater autonomy and undergo frequent software
changes.
My principal concern is that FDA must have sufficient technical visibility to assess the safety
and effectiveness of changing technology, while manufacturers and surveillance systems
must be able to identify the precise configuration associated with patient outcomes. These
needs apply to GenAI and intersect with augmented and virtual reality (AR/VR), robotic
surgery, and connected medical devices.
Priorities for Implementation:
FDA should establish a phased approach that prioritizes improvements to existing systems
while developing longer-term regulatory solutions:

1. Immediate actions: Release information FDA already collects but does not make
publicly available, improve links between GUDID, adverse event reports, and recalls,
and make existing device histories and investigation findings easier to access.
2. Near-term improvements: Add fields or identifiers to existing systems to track
software versions, compatible components, AI models, and device configurations.
Consider expanding existing UDI capabilities where practical rather than creating
entirely new identification systems.
3. Longer-term changes: Update regulations, reporting requirements, and technical
infrastructure where existing systems cannot adequately support AI-enabled
devices, autonomous functions, and evolving software.
 Note: These efforts should proceed concurrently wherever possible. FDA should not
delay improvements that can be implemented now while waiting for more
comprehensive regulatory or technological solutions.

1. Technical visibility and independent regulatory assessment
FDA should obtain risk-proportionate technical documentation sufficient to understand a
device’s AI model, intended functions, architecture, validation, limitations, training-data,
third-party dependencies, and change controls. If models may be developed and updated by
entities other than the device manufacturer, the FDA needs to be able to evaluate those
third parties as if they are a supplier, subject to supplier controls and required to ensure
patient safety. The FDA should be able to evaluate the medical device as deployed, including
material changes to upstream components. Proprietary information can be protected from
public disclosure without limiting FDA’s access for review, inspection, or investigation.
Recommendation: Establish expectations for confidential technical documentation and
independent evaluation of clinically significant model and system behavior.

2. UDI and software/model traceability
A physical device may retain the same UDI-DI while software, AI models, prompts,
guardrails, or connected services change substantially. Existing identification and reporting
practices may not allow an investigator to reconstruct the actual configuration used during
an event. FDA should distinguish modifications that trigger a new UDI-DI under existing
requirements from changes that warrant more granular version-level records but not
necessarily a new DI. FDA may find that the threshold for a new DI has to be modified for
traceability.
Recommendation: Develop standardized, linkable records of software versions, AI model
identifiers, configurations, deployment dates, and update histories, including appropriate
connections to GUDID and postmarket systems. If there is a newer software version, does it
affect the use of the device (software programming error) or is it a new functionality or
enhancement? If a software update is needed to ensure the safety of a product (due to a
“bug”) it must be made clear to users. Terminology used by the FDA and industry may not
be helpful to users so clear instructions about the use of the device in absence of a software
release needs to be clear. Does a surgeon need to postpone surgeries until a fix is made?
Make arrangements to do a surgery differently? What will happen if this software updated
by generative AI models does not fix the issue its intended to fix? Will the FDA step in? What
will that look like?
An example may serve well in this instance. This is in no way intended to imply that the
company didn’t track its devices. We are entering new territory, and having a solution that
tracks these changes, at the outset, is vital. This is an adverse event report for the Freestyle
Libre 3 that was not compatible with the patient’s iphone. In order to replicate the issue, the
manufacturer tested it with the iphone 13 mini. The patient has an iPhone 14 that they now
have purchased, and if this happens once, it’s likely to happen again with other patients.
This patient did everything in their power to obtain the new iPhone that would be
compatible. In another report, again for the Freestyle use with iPhone 14, they tried to
replicate the problem on iPhone 11 Pro.
The UDI record for Freestyle Libre 3 appears in the public GUDID system. The UDI record
for the iOS has its own UDI. Perhaps, instead of having a separate UDI, the UDI of the
components, in this instance the iPhone, should be listed as a Package DI or something
similar. If the compatibility changes or can no longer be supported, the Package DI could
contain a commercial distribution end date, and the newer version would be listed as a
newer Package DI within the same Freestyle Libre 3 UDI record. If there is a related recall, a
link to the recall or field safety notice associated with the older version would be present so
users could determine the risk relative to their practice area and patient population.
FDA already has examples of software version identification within UDI records. For
instance, the PatientTouch Blood Product Administration software application
(00853209005006), manufactured by PatientSafe Solutions, Inc., identifies Version or
Model 3.3.1. This demonstrates that existing device identification records can capture
software-specific information. FDA should build upon these capabilities to establish more
consistent identification of software versions, AI models, compatible operating systems, and
connected components. Where existing GUDID fields are insufficient, FDA should consider
additional fields, linked identifiers, or modifications to existing identification structures
rather than waiting to develop an entirely new system. This UDI record is one of the most
human-friendly records, and goes above and beyond what is in other software UDI records:

Postmarket surveillance of devices employing software and AI need direct guidance on how
to track to the level needed to ensure patient care and accountability. If the UDI can become
to hospitals, patients and the medical device industry, what UPCs are for consumer goods,
we will be one step closer to patient safety and innovation.
3. Safety-related changes and change control
A modification labeled a “bug fix,” “maintenance,” or “enhancement” may alter clinical
functionality or risk. GenAI modifications may include retraining, fine-tuning, prompts,
safety controls, or tool permissions. FDA should clarify how manufacturers demonstrate
that changes remain within authorized boundaries, including any applicable predetermined
change control plan, and how safety-related changes are communicated to users.
Recommendation: Require traceable change histories and risk-based validation; distinguish
routine changes from changes requiring additional regulatory review or user notification.
Provide users with information that’s actionable. Do I now need a new phone or different
type of phone/watch? Will the change affect performance positively or negatively? The term
“Change Control” and “Process Control” exist within FDA and technology companies, but
what effect will it have on the user? When a product is recalled in Canada, the label is
typically “Performance”. Generally it can be assumed it was poor performance.
When adverse events come to the FDA from the manufacturer, the manufactures use the
1IMDRF coding set to explain the nature of the adverse event and/or product problem. The

codes that show the detailed findings after the device investigation are redacted from public
view. The FDA needs to unredact these fields so that hospitals, patients, clinicians, and
biomedical engineers have enough information to understand if continued use of the device
is feasible. These codes appear in Annexes/Tabs B, C and D because it has been determined
that this level of granularity was important for NCI, IMDRF and FDA. New codes are added
to address new risks identified, and many are software related. This granular data should be
transparent to the public in adverse event reports. It would also be useful to expand on the
one AI-related code as new or unexpected outcomes occur with the use of AI.

• Inadequate Labeling and/or Instructions for Use
• Incompatible Material
• Reactivity Problem Identified
• Tolerance Stack-Up
• Separation Problem
• Mechanical Shock Problem
• Vibration Problem
• Wear Problem
• Clinical Imaging Problem Identified
• Magnetically-Induced Movement
• Radiofrequency Induced Overheating
• Configuration Issue
• Design Error
• Data Compression Error
• Incorrect Algorithm
• Incorrect Data Definition
• Interface Design Error
• Non-Functional Defect
https://www.fda.gov/medical-devices/mdr-adverse-event-codes/coding-resources-medicaldevice-reports
 • Software Timing Problem
• Software Maintenance Problem Identified
• Software Installation Problem Identified
• Software Requirement Error
• Software Runtime Error
• Software Security Vulnerability
• Data Storage or Loss of Data
• Erroneous Data Transfer
• Artificial Intelligence Training/Validation Problem Identified
• Inadequate Software Design
• Inadequate Cybersecurity
• Sabotage or Intentional Misuse
• Reasonably Foreseeable Misuse
• Design Inadequate for Purpose
• Corrupt Software
• Overheating Problem Identified
• Inadequate Cooling Identified
• Protective System Problem Identified
• Fail-Safe Problem Identified
• Alarm System Problem Identified
• Problem of Device to Self-Test
• Problem to Auto Stop
• Premature Indicator Activation Identified
• Missing or Inadequate Safety Measures Identified
• Incorrect Interpretation of Results/Data
• Patient Sample Problem
• New or Unknown Interferent
• Problem Related to Variant/Mutant
• Pre-Analytical Handling Problem
• Environmental Temperature Problem Identified
• Contamination of Device by Foreign Material from Environment
• Contamination of Environment by Device
• Environmental Pressure Problem Identified
• Ambient Light Problem Identified
• Environmental Humidity Problem Identified
Once unredacted by CDRH, these additional codes can tell the public more about the issues
and investigation findings with the medical device, including the AI-related code that was
highlighted in yellow.
CDRH has oversight over millions of devices and isn’t staffed to meet the changing needs AI
will bring, or even to meet the changing needs of AR/VR, wearable, and robotic devices
already on the market. I say this respectfully. Providing these IMDRF codes publicly as they
appear in adverse events, is in the interest of public health and they shouldn’t be redacted
as they currently are—as a trade secret.
4. Interoperability and third-party dependencies
Connected devices may depend on smartphones, operating systems, cloud services,
communications infrastructure, and applications outside the manufacturer’s control. A
compatibility change can interrupt access to clinically important functions or require
patients to purchase replacement hardware. Similar risks arise when AI-enabled products
rely on external products to deliver or transmit the data related to care. If a software update
makes a certain smartphone obsolete, does CMS cover a new device that is compatible?
These are real life examples of medical device product failures due to component parts and
software out of the control of the manufacturer. How will this be measured? Who is
responsible to report? Can FDA work within this realm and rein in technologies that are in
conflict with the goal of providing safe innovation?
Recommendation: Identify critical dependencies, validate compatibility, provide timely
notices and contingency plans, and clarify responsibilities when third-party changes
compromise functionality. Expand on-site inspections to require them more frequently and
ensure someone with the relevant background is conducting the inspection. When there are
actions indicated, make those 483 Forms public without requiring FOIA requests.
Transparency should be the rule, not the exception.

5. Competency assessment and real-world performance
Premarket benchmarks cannot fully predict variable GenAI outputs across clinical
populations and environments. Evaluation should consider detectability of erroneous
outputs, clinical reliance, reversibility of harm, and the realistic ability of clinicians to
independently verify recommendations. Human oversight should not be presumed effective
merely because a clinician is nominally in the loop. Consider that the users of GenAI may not
be the same age as the trial population. Glucose meters are used on children not old enough
to read them, and patients sometimes not able to react to the messages that are sent.
Redundancies need to be in place. Real-world performance will rely on communication
made in clear terms.
Recommendation: Tie premarket competency criteria to measurable postmarket
performance thresholds, drift monitoring, and escalation or corrective-action triggers. If a
corrective action is needed to preclude death or serious injury, the recall should be Class I.
Near misses/close calls need to be reportable directly to the FDA to speed the time for
signals to be identified.
6. Agentic AI, autonomy, and auditability

Agentic AI systems can independently select tools, perform multiple tasks, access
information from other systems, and take actions that affect medical devices or patient care.
Manufacturers should clearly define the limits of what these systems are allowed to do
without human involvement. For example:

• Clinical decisions: AI may recommend a diagnosis or treatment, but certain
decisions should require clinician approval.

• Robotic surgery: AI may assist with instrument positioning but should not
independently change a surgical plan without surgeon authorization.

• Medication delivery: AI may adjust dosing within established safety limits but
should not exceed those limits.

• Software updates: AI should not independently install changes that could affect
device safety or performance without appropriate validation and authorization.

• Connected devices: AI should not send commands to other devices unless those
actions are specifically authorized and validated.

Risks can also arise when an AI system performs a series of actions that are individually
permitted but collectively create an unexpected safety issue. Manufacturers should be able
to reconstruct what the AI actually did, including the information it used, decisions it made,
commands it issued, and any human intervention. This information is essential for
investigating adverse events and determining whether an AI action, software change, or
interaction with another system contributed to a device malfunction or patient injury.

Recommendation: FDA should require manufacturers to define and test the limits of AI
autonomy, establish safeguards and human override capabilities, and maintain traceable
records of AI actions to investigate device failures, adverse events, and potential safety
risks.

7. Medical device reporting and postmarket signal detection
Postmarket surveillance already faces incomplete device identification, inconsistent coding,
and reporting delays. For AI-enabled devices, reports that identify only the product family
may obscure whether an event followed a specific model update or configuration change.
Conversely, pooling events across materially different versions may dilute a safety signal.
Recommendation: Evaluate structured fields or interoperable attachments for the UDI
database, Medwatch forms and electronic MDR submissions that capture relevant
software/model version, deployment configuration, update status, and critical
dependencies. Define how unexpected AI behavior should be documented and evaluated
against existing MDR reporting thresholds. If AI is ever-changing, then the FDA needs to be
iterative and learn from this change. The FDA needs to step up and make changes to
publicly-facing databases, regulations and guidance documents to adapt to the changing
pace of innovation. If a device or its software is recalled, should it be a predicate? Logic
would say no. The manufacturer should have the burden of proof to establish that their
device did not affect patient safety, not the reverse. A recall should be classed in an
abundance of caution. If the device malfunctions and has the ability to cause death or
serious injury, it should be a Class I recall. Class II should only be used for functions not
affecting patient safety, and a new recall class (Class IV) should be for market withdrawals
so the FDA is aware when a device is no longer commercially distributed. Older software
versions would be on this list if they were withdrawn for non-safety reasons.

8. Alignment with AR/VR and robotic device oversight
AR/VR and robotic systems illustrate how software modifications may change visualization,
usability, clinical decisions, or device operation without changing physical hardware.
Clinicians may rely on manufacturer technicians for updates and may not know which
configuration was active during an event. AI-specific policies should align with FDA’s
broader software, UDI, cybersecurity, interoperability, and postmarket programs.
Recommendation: Adopt consistent traceability principles across software-dependent
medical devices. Can a surgeon know if a software update was installed in advance of his
next surgery if the company’s field technician is the only one to receive notice about a
needed software update? How can device users be sure they are using the latest version if
UDI isn’t tracking software changes consistently and they aren’t recording the Complete UDI
of the device they are using in the Electronic Health Record or Claims databases? Even if the
payment isn’t based on the use of an augmented reality device used in spinal fusion
surgeries, the Complete UDI (with serial number) can still help to identify the exact device
used on a patient. Will GenAI be able to provide feedback to manufacturers so they know
which devices have and haven’t been updated? Auto manufacturers know and are relentless
with communication. Medical device manufacturers need to feel the same level of concern
for the hospitals and physicians who trust them.

Conclusion
A practical regulatory framework should answer three questions: What must FDA know to
independently evaluate the technology? What must manufacturers preserve to reconstruct
the deployed configuration? And what must clinicians, patients, and surveillance systems be
able to identify to investigate harm?
These questions are inseparable. Technical visibility, version-level traceability, and
postmarket signal detection must be foundational elements of FDA’s approach to GenAIenabled medical devices.
FDA already has systems and regulatory tools that can be improved to address many of
these challenges. Rather than waiting years for new infrastructure, FDA should prioritize
immediate improvements to existing databases, reporting requirements, and public access
to safety information while developing longer-term solutions.
As AI-enabled devices evolve, information that is not captured today may be impossible to
reconstruct when an adverse event occurs tomorrow. FDA must act now to ensure that
innovation does not outpace its ability to identify risks, investigate failures, and
protect patients.
Thank you for considering these comments.
Sincerely,
Madris Kinard, MBA
Founder and CEO, Device Events

References
1. FDA. Docket FDA-2026-N-7874-0001. https://www.regulations.gov/document/FDA2026-N-7874-0001
2. FDA Digital Health Advisory Committee. Total Product Lifecycle Considerations for
Generative AI-Enabled Devices. Executive Summary, November 20–21, 2024.
https://www.fda.gov/media/182871/download (discussion document; not draft or final
guidance).