MatLogica Limited (Natalija Karpichina)

Please see the attached comment from MatLogica Limited.

To: Dockets Management Staff, Food and Drug Administration
Docket: FDA-2026-N-7874, Considerations for the Regulation of Generative AIEnabled Medical Devices: Discussion Paper and Request for Feedback
From: MatLogica Limited, United Kingdom
Date: 16 October 2026

Comment from MatLogica Limited

1. Who we are
MatLogica is a UK company that builds numerical software. Banks use our
technology to calculate prices and risk, where results must be reproducible and
open to audit. We are applying the same numerical methods to medical models,
including research models of drug dosing for vancomycin, meropenem and
tacrolimus. These are research prototypes; we do not market a medical device.
We comment as a developer of calculation tools that generative artificial
intelligence systems may call.

2. Our main point: separate the calculation from the
conversation
Many generative artificial intelligence devices will need to carry out clinical
calculations: doses based on weight and kidney function, unit conversions,
predicted drug concentrations. The discussion paper lists such calculations under
benchmarking element E.3 (quantitative and measurement analysis).
There are two ways a device can produce such a number. The language model
can generate the number itself, or it can pass the inputs to a separate, fixed
calculation tool and report the result. These designs carry different risks, and we
suggest the framework treat them differently.
When the number comes from a fixed, validated tool:
• the tool gives the same answer every time for the same inputs, so it can be
tested reproducibly against specified inputs, including boundary and out-ofrange cases, which open-ended language output cannot;
• it can be validated with existing methods, including the Agency’s guidance
Assessing the Credibility of Computational Modeling and Simulation in
Medical Device Submissions, which the discussion paper already cites, applied
to the tool’s stated context of use, including the patient population its model
was developed in;
• every result can carry a record of its inputs, model version and assumptions,
so a clinician or reviewer can check it.
Separating the calculation moves part of the risk into a component that can be
tested on its own. The remaining risk sits in two places: whether the tool is valid
for its context of use, and the language layer: whether it chooses the right tool,
passes the right inputs in the right units, reports the result unchanged and states
the limits of the result.

3. Answers to specific questions
Question 1 (additional risk dimensions). We support adding traceability, and
suggest that for computed outputs it cover the calculation as well as the primary
source materials. For numerical outputs, the key question is where the number
came from: was it generated by the model, or computed by an identified,
validated tool and reported unchanged? A dose generated freely by a language
model should sit higher on the risk scale than the same dose computed by a
validated tool with a full record of its inputs. We suggest representing this as a
modifier within the two-axis framework that affects the evidence and safeguards
expected, rather than as a third axis.
Question 2 (degrees of direction). We agree that how directive an output is
depends on its substance and context, not only on its wording. A specific,
personalised number, such as the paper’s example “increase the lisinopril from 10
mg to 20 mg daily”, is among the most directive kinds of output. Whenever an
output contains a patient-specific dose or quantity, the device should be able to
show which tool and version produced it, the inputs used with their units and
source, and the result as the tool returned it.
Question 9 (benchmarking elements). Under elements E.3 and A.1, we
suggest that benchmarks for tool-using devices test whether:
• the device chooses the correct tool for the question, and declines when no
suitable tool exists;
• the inputs passed to the tool match what the user supplied, including units,
and implausible values are queried rather than used;
• the tool’s result is reported without changes or rounding that alter its
meaning;
• the reply keeps the computed result separate from the model’s own
explanation;
• a tool failure or an out-of-range input leads to deferral, not a guessed number.
Most of these tests have a reference answer that can be set in advance, so they
can be automated and repeated after every change to the device.
Question 15 (comparison with the course of action without the device). We
support measuring devices against what would happen without them, judged on
outcomes, not only on the accuracy of outputs. In our own unpublished analysis of
battery trading in the British electricity market, a price forecast with 16.6% lower
mean absolute error produced 3.0% lower revenue over 606 out-of-sample days
under the same dispatch procedure. A more accurate output does not always lead
to a better decision, and the same may hold for clinical outputs. For a dosing
function, the comparator could be the clinician using an existing validated
calculator or nomogram, and the measure could be target attainment and adverse
events rather than calculation accuracy alone.
Question 24 (changes to third-party foundation models). Separating the
calculation helps here. If the foundation model is updated, the validated tool does
not change and, provided the tool version and its interface are unchanged, its
own validation need not be repeated. The device’s benchmarks still need to be
rerun, but the safety-critical numerical behaviour can be re-checked quickly with
the tool-use tests listed under Question 9. Manufacturers can also pin the
foundation model version they use and monitor the provider’s change notices. We
suggest the Agency consider allowing a predetermined change control plan to
cover foundation model updates when the safety-critical calculation sits in a
fixed, separately validated tool and the rerun benchmarks, including those tests,
pass.
Question 26 (agentic systems). Tool use raises a question of responsibility:
when an agent calls a calculation tool, is that tool a device function in its own
right, and who answers for its result: the tool developer, the device manufacturer
or the deploying institution? Guidance on how a separately validated calculation
tool could be described once and referenced across submissions, for example
through a master file of the kind the paper proposes for foundation models, would
help developers build safe designs from the start. A shared test suite for tool use
could be a candidate for qualification through the Medical Device Development
Tools program.

4. Our request
We ask the Agency to publish worked examples showing how it would assess two
versions of the same device: one where the language model generates a dose
itself, and one where it calls a validated dosing tool and reports the result
unchanged. Clear examples would encourage manufacturers to keep safetycritical calculations in tools that can be tested systematically.
Natalija Karpichina, Chief Operating Officer
MatLogica Limited
natalija.karpichina@matlogica.com