Mosaic Intelligence Labs, Inc.

Please see the attached file for our comments; and do not hesitate to reach out with any questions.

Response to the FDA’s “Considerations for the Regulation of Generative
AI-Enabled Medical Devices: Discussion Paper and Request for Feedback”

Docket Number FDA-2026-N-7874

Prepared by Mosaic Intelligence Labs, Inc.

Submitted to U.S. Food and Drug Administration, Center for Devices and Radiological
Health, Digital Health Center of Excellence

Courtesy attention Jared Seehafer, M.S., Deputy Commissioner for Technology and AI

Matthew Medlock Main Point of Contact
matt@mosaicintelligence.xyz

Dr. Ileana Pirozzi Chief Executive Officer

Dr. Alison Mackanic Chief Technology Officer

Dr. Charles Dinerstein Medical Affairs

Website mosaicintelligence.xyz

Table of Contents
Introduction to Mosaic Intelligence
Who we are
Executive Summary
Responses to Discussion Questions
Section IV: Considerations for the Assessment of Risk for GenAI-Enabled Devices
Section V: A Competency-Based Approach for Premarket Evaluation of GenAI Enabled
Devices
Section VI: Postmarket Monitoring for GenAI-Enabled Devices

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
Introduction to Mosaic Intelligence
Mosaic Intelligence is developing an integrated sensing, navigation, and robotic platform for
endovascular interventions designed to improve spatial awareness and procedural control of
catheter-based interventions. The platform combines patient-specific anatomical models with
live intravascular imaging, multimodal sensing, and real-time sensor fusion and state estimation
to create a continuous representation of the anatomy and procedural state, with the objective of
supporting physician-guided navigation and, over time, increasingly capable sensor-guided
robotic assistance and autonomy.

Who we are
Mosaic Intelligence Labs Inc., based in San Francisco, was co-founded by Stanford alumni Dr.
Ileana Pirozzi and Dr. Alison Mackanic. Co-authors of 20+ peer-reviewed publications and
multiple patents in medical robotics, they trained under Prof. Paul Yock, Prof. Mark Cutkosky,
and Dr. Joseph Woo. The Mosaic Intelligence team brings over 50 years of combined
experience commercializing leading surgical robotics, contributing to 400+ patents and 10+ FDA
clearances. Uniquely bridging medical technology and autonomous vehicles, our engineers and
scientists hold degrees from top institutions (Stanford, UC Berkeley, Columbia, Brown, Georgia
Tech) with prior experience at Intuitive Surgical, Auris Health, NVIDIA, J&J, Genentech, NASA,
OpenAI, and robotics startups.

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
Executive Summary
Mosaic’s approach to the regulation of generative artificial intelligence (GenAI) begins with a
guiding principle: intelligent systems should strengthen clinical judgment while preserving
professional accountability. Regulatory oversight should focus on what an AI system actually
does, the potential clinical consequences when it is wrong, and whether the healthcare
professional (HCP) can meaningfully recognize, challenge, and/or correct an error. The
presence of a physician “in the loop” does not, by itself, establish safety. Equally, preserving
clinical accountability does not diminish the manufacturer’s responsibility to demonstrate and
maintain the safety and effectiveness of its device.

We concur with the two-axis risk framework that distinguishes device activity from the potential
clinical consequences of error. The first axis identifies whether software provides information,
interprets data, recommends or directs an action, or performs one independently - an effective
clinical analog to the “Levels of Driving Automation” established in SAE J3016. The second
considers the harm that could result from an erroneous output or action, following established
practices in safety-critical engineering.

This approach is conceptually similar to the safety-critical engineering practices and standards
that have been successfully employed in other industries (e.g. ISO 21448, PAS / ISO 8800, etc.)
while remaining grounded in medical-device risk-management principles. While automotive
frameworks do not translate directly to medicine, they underscore the importance of specifying
which responsibilities belong to the operator and which to the automated system, including
monitoring, intervention, and recovery from failure. Explicitly allocating these responsibilities
also facilitates error traceability, consistent with medicine’s tradition of examining adverse
outcomes.

The two axes provide an initial assessment, supplemented by structured modifiers rather than
an increasingly complex scoring system or evaluation matrix. These include reversibility,
detectability, uncertainty, clinician competence, time available for intervention, and other
safeguards. Consistent with ISO 14971, some factors influence the severity of potential harm;
while others influence the likelihood that an error progresses to harm. Reversibility, for example,
is particularly context-dependent: an error may be technically correctable but clinically
consequential if detected too late, and some consequences may emerge long after the
intervention.

We also propose distinguishing linguistic directiveness from functional influence. Whether an AI
says “consider,” “recommend,” or “stop” is less important than how its output influences clinical
behavior and the consequences if that output is wrong. Overemphasizing cautious language
may encourage vague, less useful recommendations without improving safety. The objective
should be appropriate reliance, not merely reduced reliance.
Professional expertise does not eliminate automation bias, confirmation bias, or unwarranted
confidence. Meaningful oversight requires task-specific knowledge, sufficient information and
time, actionable communication of uncertainty, and opportunities to intervene. The distinction

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
between recognizing uncertainty and being confidently unaware of it is particularly
consequential. These capabilities and safeguards should be demonstrated, not presumed from
professional credentials.

These principles should directly inform evidence requirements. We support a
competency-based approach that combines device benchmarking with clinical confirmation, with
the rigor and scope of evaluation proportionate to intended use, operating conditions, and risk.
Evaluation should reflect the intended configuration of use, including the performance of the
clinician-AI team where appropriate, and compare it with the care likely to occur without the
device. Where suitable public benchmarks do not exist, sponsors should have a clear pathway
to develop and justify their own tests and datasets.​

This flexibility is particularly important in our domain of endovascular surgery, where available
data are limited and existing technologies often cannot directly observe or reliably label the
quantities that new systems seek to estimate. Mosaic’s “perception first” approach introduces
lower-risk capabilities that improve observation and measurement, creating an evidence base
for increasingly capable assistance and autonomy to follow. Synthetic data can support this
progression by providing controlled variation, consistent labels, and coverage of challenging
scenarios that are difficult to capture clinically. Its value should be established through
task-relevant validation and independent real-world testing. In our prior experience, a model
trained exclusively on synthetic data outperformed one trained exclusively on available clinical
data in an animal study; and we would welcome the opportunity to provide a detailed case study
on this matter for further review.​

Premarket and postmarket evidence should therefore be considered together across the device
lifecycle. Where potential clinical benefit is substantial, remaining uncertainty is explicitly
characterized, and risks can be bounded and mitigated, a limited deployment with defined
monitoring obligations may provide a justified pathway to generate additional evidence. Such
programs should measure whether anticipated benefits are realized, monitor known and
emerging risks, and establish performance thresholds and triggers for reassessment. The
intensity of monitoring should reflect both device risk and the uncertainty accepted at
authorization.

Ultimately, GenAI regulation should encourage systems that improve clinical decisions while
preserving the ability to question, intervene, and remain accountable. The measure of
successful medical AI is not how independently a machine can decide, but how effectively
clinicians and intelligent systems can work together to deliver safer, better-informed care.

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
Responses to Discussion Questions

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

Response to Question 1​
​
The proposed two-axis risk framework presents a highly focused and interpretable assessment
of GenAI-enabled software functions. The framework and approach are conceptually aligned to
similarly established frameworks and standards used in automotive (e.g. SAE J3016, SOTIF /
ISO 21448, ISO 8800, etc.) and related industries for the assessment of GenAI-enabled
software functions. It is also aligned to commonly practiced analytical methods in safety-critical
engineering.​
​
The delineation of different device activity types - informational: non directive, informational:
action-directing, etc. - mirrors the levels of autonomy SAE J3016 established for
automotive/roadway autonomy while adapting it more directly to clinical applications. This
delineation is critical to understanding the risk - and thereby the consequence - of a given
software function, as it provides a vehicle to clearly establish responsibilities (e.g. between a
HCP and a GenAI-enabled software function) in the evaluation of consequence.​
​
The noted additional considerations or dimensions - e.g. reversibility of a resulting action - are
obviously critical to the assessment of consequence, but should be considered in the overall
assessment of consequence as opposed to being independent dimensions in such an
evaluative framework. This delivers both a highly interpretable framework (i.e. one that frames
the decision-driving information and outcomes clearly) and focus on clinical outcome and safety
- in this case by way of assessing “consequence.”​
​
These additional considerations should be codified as non-exhaustive guidance in assessing
consequence - perhaps similar to the way ISO 14971 presents non-exhaustive guidance on
hazard categories for consideration when developing e.g. a Preliminary Hazard Analysis. These
considerations may be considered as informants to or modifiers of consequence as appropriate,
similar to the concept of “controllability” employed in hazard analysis for automotive (see: ISO
26262).​
​
As a specific example, we can consider the concept of reversibility. An action with a high
reversibility should, naturally, carry a lower level of consequence than an action with limited or
no reversibility. This must, of course, be paired with the ability to detect that such action needs
to be reversed. So an action that carries a high reversibility and an ability to detect the need for
reversal may have a significantly reduced consequence as compared to an action that is highly
reversible but carries less ability to detect that need. For simplicity’s sake, the ability to detect
this need can be captured with reversibility.​
Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
​
These elements should be considered for inclusion as “considerations of consequence:”​

●​ Reversibility: Is the action able to be reversed? What is the consequence of reversing
the action (e.g. loss of time, increased risk of readmittance, etc.)? Can the need to
reverse be detected?
●​ Downstream Safeguards: Are there safeguards downstream that mitigate consequence?
What is the probability that those safeguards also fail? Are the safeguards dependent on
specific HCP training and/or knowledge? Are the safeguards immediate/short-term (e.g.
intraoperative imaging confirmation) or long-term (e.g. readmittance)?
●​ Time Sensitivity: Does the time sensitivity of a given application allow for or prevent
consultation or reference?
●​ Confidence: Is the information, direction, or action able to be displayed/executed at a
high level of confidence? Is there an interpretable means of displaying the associated
confidence to the HCP? Is the information, direction, or action directly traceable?
●​ Error Detectibility: Is erroneous information, direction, or action able to be detected - by
the system itself or by an HCP? Is it able to be detected nominally or does detection
require further and specific action? On what time horizon is the error able to be detected
(e.g. real-time, post-operative review, re-examination, etc.)?
​

Response to Question 2​

While it is tempting and obvious to consider the linguistic characteristics of an output (e.g. its
directiveness - “consider” vs. “recommend” vs. “do”), a more appropriate evaluation may be to
approach consideration through the lens of functional influence. We will consider a specific
observational example from Mosaic’s domain of clinical expertise: endovascular surgery. The
following are examples of two statements with differing levels of linguistic directiveness:​

●​ “The current trajectory may be subintimal”
●​ “Stop advancing. Subintimal passage is expected.”

The first statement carries a lower linguistic directiveness than the second, but does not
necessarily carry a lower risk because of that. Conversely, the second statement is more direct,
but is not necessarily undesirable or higher risk.​
​
Instead, we will consider the functional influence - how HCP (or patient) behavior is changed,
and the potentially caused outcomes and consequences - associated with each of the above
two statements. In the above example, there is a strong argument to be made that the second
statement prompting the HCP to stop and reassess carries a lower overall risk even if it is
linguistically more direct. This comparison is more robust through the lens of functional influence
than linguistic characteristics alone.​
​
Furthermore, if evaluation is disproportionately focused on linguistic characteristics,
Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
manufacturers/sponsors may be wrongfully incentivized to produce outputs that are more
linguistically defensible but less clinically impactful and, in some cases, higher (comparative)
risk.

Response to Question 4

There may be specific knowledge, competence, or capability that a specialist HCP carries that a
generalist does not, but this should not necessarily be a default assumption. Instead a more
robust consideration to make is around user competence and capability (specialist, generalist,
or otherwise), specifically when considered as operating in tandem with a device or software
function. When considering risk, the target user - and their existing knowledge, competence,
and capability - should be explicitly considered. Where there exists elevated risk based on the
target user, corresponding mitigations should be required to be established. It may be helpful to
establish categories of such mitigations and corresponding examples. Example categories may
include:​

●​ Operational: L&D / Training Programs, Device Representative Presence, etc.
●​ Technical: Device Safeguards, etc.
●​ Interface & Control: User-Differentiated Capabilities, etc.​
​

Response to Question 6​
​
It is typical safety-critical engineering practice to account for the various ways a system can fail
(e.g. wrong output, no output, reversed output, etc.) when doing hazard analysis. The concepts
of over-escalation and under-escalation are not especially different (other than the fact that they
are particularly relevant to GenAI-enabled software functions) from the other means of failure
that are typically considered, and thus can be treated similarly. The end result of such analyses
is to develop a concept of the associated risk (or consequence) of a given failure. As such, the
appropriate manner of evaluation of under- and over-escalation is simply to similarly evaluate
the potential consequence of failure in each direction and to incorporate this back into the
overall assessment of risk/consequence.​

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

Response to Question 7​
​
A competency-based approach is aligned to the evaluation processes and standards that have
emerged and converged for other safety-critical AI-enabled devices, such as autonomous
vehicles. And the challenge is similar: demonstrate device performance in a large, highly

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
dynamic distribution environment with a variety of edge cases. For GenAI-enabled devices,
particularly those expected to operate under these conditions, this approach has emerged as
the most practical and effective. That said, it is worth further considering how the autonomous
vehicle space has shaped its approach, including beyond what relevant standards mandate. A
generic outline is as follows:

●​ Performance in known (either experienced or anticipated) safety challenge cases, which
includes both physical scenario testing and validated simulation extrapolation
○​ NOTE: This is highly related to Safety of the Intended Function (SOTIF) testing
corresponding to ISO 21448 and ISO 8800 (which is a specific AI extension to
ISO 26262 and ISO 21448)
●​ Limited (and observed/governed) real-world deployments under specific conditions and
constraints
●​ Scaled real-world deployments under specific conditions and constraints
○​ NOTE: It is common practice, as a means of validation, to consecutively roll
software out to larger portions of the fleet over a given period of time or
accumulated “experience.”

Response to Question 8​
​
The two-axis risk framework should directly inform the level of evidence needed for a premarket
submission. Specifically, higher device activity and/or higher output consequence should carry a
higher burden of evidence. This may include increased expectations around the breadth of
benchmarking and/or the rigor of clinical confirmation and validation. As called out in the text,
the level of evidence may also scale the type of evidence required (e.g. from retrospective
evaluation on real-world inputs/data to a clinical study and/or trial).​
​

Response to Question 9​
​
The provided text proposes that “sponsors might not only use well-defined tests and datasets
developed by third-party entities, but also propose their own specialized tests and datasets …”
As discussed in the responses to other questions, many GenAI-enabled devices and software
functions will have very limited existing data, and often no existing well-curated datasets. As
such, it will be critical to enable a pathway for such devices that relies exclusively on sponsors
proposing their own specialized tests and datasets. Such proposals could be included in
pre-market approval, and subsequent (post-market) benchmarking could, for example, be
compared against pre-market results to ensure continued “as good as” performance that
supported the initial market launch.

The specifically proposed benchmarking elements - and the acknowledgment that not all
elements will necessarily apply to all devices or software functions - reflect the major elements
for a benchmarking program. The following (minor) adaptations may be considered:

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
 ●​ S.1 may also consider “handling” of safety critical events (to account for increasing levels
of device or function autonomy over time)
●​ R.1 may be split into separate elements for “Robustness” and “Reliability &
Reproducibility”

Beyond these minor adaptations, it is also worth considering an approach (similar to ISO
14971’s approach to hazard categories) where the noted elements are recommended or default,
but suppliers/manufacturers are welcomed to employ (and justify) different and/or additional
elements beyond these.​
​

Response to Question 10​
​
As noted in the responses to other questions (including question 9), many GenAI-enabled
devices and software functions will have very limited existing data, and often no existing
well-curated datasets, from publicly available benchmarking assets. As such, it will be critical to
enable - and to provide guidance for - a pathway that allows sponsors/manufacturers to
construct and justify their own benchmarking assets. The justification should include specific
arguments for why the benchmarking dataset or other asset supports the evaluation of the
product’s safety, reliability, and efficacy; and these should be again determined through
traditional safety-critical analysis techniques (e.g. hazard analysis, FMEA, FTA, etc.) or
appropriate adaptations thereof.​
​
This approach again bears similarity to autonomous vehicles. While the availability of publicly
available data is arguably more prevalent, this data is predominantly captured only at the
highest level (e.g. accident statistics, an analog in healthcare being something like complication
rate). While this data is incredibly useful and should be considered, it does not satisfy the
complete needs of a benchmarking dataset or asset, particularly to demonstrate the safety,
efficacy, and reliability pre-launch. For autonomous vehicles, this has led to various standards
(e.g. ISO 21448, ISO 8800, etc.), analysis (e.g. codification of the operational design domain,
etc.), and test/evaluation methods (e.g. simulation, scenario replay/resimulation, public road
testing, etc.) that are intended to demonstrate these aspects prior to full market launch.
Specifically, emphasis is placed on:​

●​ Understanding and codifying the intended usage and operation of the device; and the
explicit capabilities and limitations of the device or function, including the environmental
conditions it may be exposed to (i.e. Concept of Operations, Operational Design
Domain, etc.)
●​ Using this information to identify - both statistically and expert-driven - operational
hazards and worst-case scenarios (incl. worst-of-worst analyses) for evaluation
●​ Developing test and validation plans and methods - which may span controlled or
structured physical scenario testing to edge-case simulation to public road testing - to
demonstrate safety, reliability, and efficacy
Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
 ●​ Formulating this information and results into a justification of acceptably low - or as low
as reasonably possible (ALARP) - risk for public deployment or launch
●​ Enacting safety management systems (SMS) to ensure that emergent operational
conditions and hazards that were not identified in pre-market diligence are included in
future benchmarking and validation sets

The same ideology and principles outlined can be applied to healthcare, and used to justify the
validity of benchmarking assets, and of device or function performance.​
​

Response to Question 12​
​
The inclusion of synthetic data allows for a controlled extrapolation of variability (e.g.
anatomical, acquisition, etc.) beyond what a limited real-world dataset may already contain and
what may be achievable to collect premarket. Particularly noteworthy is that synthetic training
data can be useful without being visually realistic. SynthSeg (Billot et al., 2023), for example,
trains a brain-segmentation model on synthetic images with deliberately randomized, often
unrealistic contrasts and resolutions, yet generalizes to real scans across diverse acquisition
conditions without retraining. This type of variation can help a model learn anatomical features
that remain useful across changes in image appearance, illustrating why the value of synthetic
data is best understood through performance on the downstream task (as opposed to e.g. visual
realism).​
​
The evidence required to support premarket acceptance should reflect the intended usage,
relevance to the clinical task or indication, and the consequences of an incorrect training
estimate of the device or software function. Therefore, sponsors/manufacturers should be
required to produce validation of the synthetic data training characteristics that materially affect
the device’s performance. Training comparisons can then be made to justify the inclusion of
synthetic data, particularly by evaluating models trained on real-only, synthetic-only, and
combined data using the same, independent real-world test set. These training comparisons
can then be used as evidence to support any combined performance estimates.​
​
In our own experience in the context of intraoperative medical imaging, we have developed
models where the synthetic-only trained model outperformed the real-only trained model.
Synthetic data generation gave us control over both the diversity of the training scenarios and
the consistency of their labels, including the ability to vary image appearance while preserving
the underlying anatomy. Simulation also gave us direct access to the underlying characteristics
(e.g. geometry, instrument state, etc.) allowing us to generate labels automatically and
consistently, making it practical to generate large, precisely labeled datasets (notably including
challenge cases that would be otherwise burdensome or improbable/near-impossible to collect)
and to evaluate quantities that may be difficult or impossible for a human to label from clinical
images alone. Conversely, expert annotation is expensive, time-consuming, and subject to
disagreement, particularly when anatomy or instruments are difficult to distinguish in an image.
Ultimately, leveraging synthetic data helped the model to learn more generalizable features and
Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
reduced its dependence on patterns specific to the real-world training dataset. We are happy to
provide a detailed case study on the above to further support our claims and recommendations.​
​

Response to Question 13​
​
Synthetic data has the potential to serve as a crucial accelerant or enabler in device or software
function development, enabling sponsors/manufacturers to deliver a more well validated and
justified proposal on a shorter timeline (and in many cases without intermediary steps that may
carry significantly less benefit to patients and HCPs). The validity of synthetic data as evidence
is less dependent on the specific clinical domain, device function, or subpopulation of
application; and more related to existing knowledge of the domain of application or problem.
Specifically, synthetic data is most appropriately leveraged in areas where the characteristics,
distributions, and variances of a given problem (e.g. anatomical limits) - and the underlying
physical processes - are well understood, as this allows for the most representative synthetic
data to be generated. This includes, for example, generating ultrasound, MRI, or X-ray imaging
from a defined anatomy. And it is specifically less or not appropriate in the case of problems with
mechanics or responses that are not well understood and/or are difficult to model and validate,
such as patient response to a particular drug. The use and application of synthetic data should
of course be justified, particularly by demonstration that existing real-world data (that could
otherwise be used) is sparse or nonexistent, expensive, or otherwise prohibitive to obtain.​
​

Response to Question 14​
​
The performance comparators and acceptance criteria for premarket evaluation should,
unsurprisingly, vary by device or software function type, intended use, and risk profile. These
considerations are explored in detail in the response to question 18 — both in justifying
premarket uncertainty and in establishing a post-market monitoring program.​
​
The FDA’s existing “as good as” guidance provides a solid basis for establishing an applicable
evaluation standard. That is, the standard should focus on core clinical KPIs relevant to the
specific device or software function and be adequately comparable to the existing standard of
care, both pre-market and during ongoing monitoring. This evaluation standard should also be
based on the device's intended user, a generalist, a specialist, or otherwise. And in cases where
both generalists and specialists may use a device or software function, a weighted evaluation
schema or comparison should be considered (e.g., if usage is 90% generalists and 10%
specialists, the weighted average or median of the two should be considered). This provides the
strongest basis for evaluation, and the required level of “proof” can be adjusted (and justified)
based on the risk profile of a given device or software function.​
​
Similarly, evaluate the device or software function according to its intended modality of
operation: as a human-AI team (with the AI serving as an informant, assistant, or observed
actor) or as a standalone actor. The modality of operation, naturally, feeds into the assessment
Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
of risk (and consequence) and ultimately the evaluation of premarket acceptance.​

Response to Question 15​
​
As noted in the response to question 14, the performance of GenAI-enabled devices and
software functions should be evaluated in accordance with their intended mode of operation and
against the existing state of care. So for devices or functions which augment human
performance - intelligence, visualization, etc. - there is a strong argument to be made that these
should be compared against the existing state of care (i.e. without such devices or functions)
and the corresponding performance. This provides the most rational basis for comparison, as it
allows for the demonstration that a device or function yields improved outcomes over existing
solutions.​

Section VI: Postmarket Monitoring for GenAI-Enabled Devices

Response to Question 18​
​
The argument for accepting greater premarket uncertainty centers on two main points: benefits
to patient outcomes and the precedent set by (and the success of) other safety-critical
industries, especially autonomous vehicles.​
​
The deployment of autonomous vehicles, particularly in the US, has followed a path of
accepting greater premarket uncertainty and relying on postmarket monitoring to bring a product
with high potential benefit to society to market faster and to accelerate its advancement (in
safety and performance). The initial deployment of autonomous vehicles is allowed with
pre-market diligence that may include some combination of component and subsystem testing,
scenario-based physical testing (e.g., of known challenge and/or edge cases), simulation (incl.
hardware-in-the-loop and re-simulation of experienced challenge and/or edge cases), and
closed-course testing. This pre-market diligence is intended to demonstrate that the technology
performs as well as or better than human drivers - on the whole, but not necessarily in every
singular aspect - across a range of relevant scenarios, both nominal driving and edge case, and
conditions. Notably, regulations and permitting for autonomous vehicles remain piecemeal,
managed by a combination of federal (e.g., NHTSA), state (e.g., DMV), and local (e.g., city
council) entities.​
​
Unsurprisingly, the approach taken to autonomous vehicles does not differ in spirit from the
FDA’s existing “as good as” guidance; it only amends the burden of pre-market proof required to
something practical and achievable (in a reasonable timeframe) in the interest of bringing a high
potential benefit to society; and ensures continued safety and efficacy via post-launch
monitoring. This also has the added, critical benefit of enabling continued collection of real-world
data used to train, validate, and ultimately improve the safety and performance of these same

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
devices.​
​
The approach taken by the FDA should follow a similar principle: establish a scope of
pre-market diligence that allows for the confident launch of GenAI-enabled devices and
functions, allowing their potential benefits to be realized sooner and the continued acceleration
of their development; while also enacting post-market monitoring to ensure that they do, in fact,
perform as intended and expected when applied to the breadth of real-world scenarios and
conditions that they may encounter.​
​
To that end, conditions should be established for when greater pre-market uncertainty is
acceptable. These conditions should include:​

●​ High potential benefit(s) to patient outcome, HCPs, and/or healthcare systems. This
could include reduced complication rates (e.g., reduced readmission), increased
throughput or caseload capacity (e.g., reduced staff time requirements), and/or cost
reductions.
●​ Exceptional burden (e.g. duration, expense, etc.) required to demonstrate the required
performance against the existing or traditional pathway. This burden may be imposed by
existing data availability (for training, validation, etc.), high procedural and/or anatomical
variance (particularly as it relates to the ability to collect data and/or validate the system),
etc.
●​ The identification of risk limits and corresponding mitigation measures. This could
include identifying possible worst-case outcomes or other associated risks for target
indications, and corresponding mitigation measures for each (which may be technical,
operational, interface, or otherwise). Notably, this aspect is closely related to the
proposed two-axis evaluation framework.
●​ Appropriate placement within the two-axis framework of evaluation. As with identifying
explicit risk limits and mitigations, the overall risk incurred when launching a device or
software function should be appropriate. For example, an action-taking function with a
high level of both reversibility and downstream safeguards may carry a lower pre-market
burden than one with a high level of either, but not both.

Similarly, the aspects of a post-market monitoring program should also be explicitly defined.
Such programs can also draw inspiration from autonomous vehicles, where post-market
monitoring focuses on safety and efficacy. As an example, this may include the number of miles
per experienced incident, the impact(s) on traffic patterns in designated deployment zones, and
even the utilization of the vehicles (i.e., what percentage of the time are they actually serving a
customer - or, in other words, fulfilling the promised benefit). The characteristics of a
post-market monitoring program for a GenAI-enabled medical device or software function may
include:​

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
 ●​ The monitoring of express clinical KPIs. These should tie back to the initial “high
potential benefit” justification and aim to ensure the benefit of accepting greater
premarket uncertainty is realized.
●​ The monitoring - and capture - of risks. This monitoring should confirm both the severity
and frequency of pre-identified risks and demonstrate that the corresponding mitigation
measures are controlling those risks to an appropriate level. This monitoring should also
capture unforeseeable and/or evolving risks that were not identified in advance.
Establish a review and resolution cadence that requires the same identification,
mitigation, and justification as pre-market.
The monitoring of critical performance metrics as identified by the manufacturer. These
performance metrics should be specific to the device and should represent key product and/or
technical metrics critical to the performance and usage of the product. While they may carry less
direct clinical indication than the prior characteristics, they should serve as a means of validating
the continued performance and understanding of the device or software function.​
​

Response to Question 19​
​
The approaches to and cadence of post-market evaluation can and should vary significantly
based on both the device itself and the amount of pre-market uncertainty accepted (for a given
device). The nominal cadence should be aligned and agreed upon, per device or function,
between the manufacturer and the FDA at pre-market acceptance. Similarly, establish
device-specific triggering events that correspond to risk, denote each identified pre-market risk
as triggering or not, and establish a causality/assessment table for post-market risks based on
consequence (or severity). Other approaches that should be considered for post-market
performance evaluation include:
●​ Device self-monitoring against pre-identified clinical KPIs and critical performance
metrics
●​ HCP and/or Healthcare System/Facility monitoring against pre-identified clinical KPIs
●​ Limited release acceptance - which may limit the number of HCPs allowed to use, the
number of devices allowed to be distributed, the number of facilities allowed to install,
etc. - with periodic post-market performance reviews to unblock further release. Note
that this is similar to the “limited release” concepts employed in the release of software
to, e.g., fleet-managed devices (such as autonomous vehicles).​
​

Response to Question 20​
​
The viability of machine-based supervisory agents depends entirely on the device and/or
software function type, its risk profile, and ultimately the pre-market uncertainty acceptance
justification. For many device and software functions, at least some level of monitoring can be
facilitated by machine-based supervisory agents, particularly when used in tandem with other

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
approaches (such as those described in the responses to questions 18 and 19). Like the device
or software-enabled function itself, the supervisory agent should have robust design
considerations, including identified risks and mitigations, and test plans.​
​

Response to Question 21​
​
Clinicians, healthcare institutions, professional societies, standard-setting bodies, and other
stakeholders are particularly well positioned to take part in the post-market monitoring of clinical
performance metrics. The metrics monitored could be high-level metrics (such as complication
rate, readmittance, throughput, etc.) proposed by the FDA or a developed standard; or could be
metrics defined by the sponsor/manufacturer itself as part of pre-market acceptance. Depending
on the design/architecture of pre-market acceptance, the metrics monitored could be scaled
with the level of deployment. For example: if there were to be a pre-market acceptance that
allowed for a limited launch with a small number of HCPs, the post-market monitoring program
may include those participating HCPs to monitor both the aforementioned high-level metrics and
manufacturer metrics, whereas a full launch (with a larger/unlimited number of HCPs) might only
have participating HCPs monitor the high-level metrics (since presumably a broad launch would
imply higher confidence). It is expected that the sponsor/manufacturer, themselves, would also
be monitoring these metrics as part of an established and accepted post-market monitoring
program, and so instead of diffusing accountability such programs could instead serve as a
confirmatory signal on manufacturer diligence.​
​

Response to Question 22​
​
The evidence required to support post-market modification should, naturally, point back to the
two-axis framework, with higher consequence (or risk) modifications carrying a heavier burden
of evidence. And the pre-market assessment is a rational baseline of performance to evaluate
post-market modifications against, particularly since many of these devices and software
functions will be first-in-kind (and so comparison against the pre-market assessment forms the
strongest indication of “as good as”) and those that aren’t will have been evaluated against the
existing state of care.​
​
As part of a pre-market submission, sponsors/manufacturers should produce a list of expected
change types and pathways for each for review and approval. These change types may include,
for example:​

●​ Changes managed exclusively within a QMS. These are changes which are not
expected to have a significant impact on performance or capability (e.g. changes to
GenAI training/validation data that do not change the distribution, characteristics, etc.).
●​ Changes managed within a PCCP process. These are changes which may be expected
to have an impact on performance or capability (e.g. changes to GenAI

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.
 training/validation data that do change distribution, characteristics, etc. in an effort to
improve some characteristic or performance of the device or software function)
●​ Changes that require review and authorization. These are changes which are expected
to enable a fundamentally new capability or indication (e.g. the deployment of a
fundamentally new GenAI model).

For each change enacted, regardless of its type, the sponsor/manufacturer must keep record of
why it is applicable to a given category and - in the cases of changes which do not require
explicit review and authorization - supporting evidence for its launch. The FDA may consider
periodic submissions or summarized reviews (e.g. change, evidence/justification, outcome) of all
such change records from sponsors/manufacturers for the purposes of complete
record-keeping.​
​

Response to Question 23​
​
As discussed in the response to Question 22, existing PCCP concepts could be abstracted or
generalized into guidance around different categories of changes and their corresponding
pathways; and sponsors/manufacturers could be expected to - as part of premarket acceptance
- establish and align with the FDA on types of pre-planned changes (such as changes to training
and validation data, but not what specific changes) for a given device or software function and
the change type and pathway for each. The FDA may also consider imposing periodic review
and/or reporting/submission requirements on the sponsor/manufacturer for each post-market
change (e.g. change, justification, outcome).​
​

Response to Question 24
​
There is a great analogy here to hardware supply chain agreements. Hardware (component or
material) suppliers may make changes to their products based on material availability, planned
improvements, or any number of other motivations. In a robust supply chain agreement, such
suppliers are obligated to provide advance notification of changes to their products (e.g. SCN,
NOC, etc.). A similar model could be employed for devices or functions built on third-party
foundation models. These changes should then feed into a post-deployment modification flow,
such as the one described in the response to question 22, to ensure the continued safety,
reliability, and performance of the device or software function.​
​
Separately, a “version check” feature should be required to be implemented where possible, to
ensure that the underlying model is the expected version. The inclusion of version information
and maintenance could also be managed as a contractual obligation on the third-party model
developer.​

Private and Confidential
Property of Mosaic Intelligence Labs, Inc.