Can medical-device AI assessments be reproduced?
Fourteen hosted model deployments changed at least one repeated assessment despite low-variance settings. A company-built pipeline reproduced every stage on fixed hardware, but the study tested repeatability—not correctness, usefulness or regulatory approval.
The short version
- What happened
- Each of 14 commercial model-route deployments changed at least one repeated assessment; 12 changed a compliance label on at least one prompt, despite using the lowest-variance settings each interface accepted.
- Who it affects
- Regulatory and quality professionals need stable evidence trails so a changed assessment can be distinguished from ordinary model variation.
- What remains unproven
- Single-author, company-funded preprint evaluating the funder's proprietary product
Keep in mind
Single-author, company-funded preprint evaluating the funder's proprietary product
No independent reproduction at the time of publication
Public documents for two device types rather than full manufacturer records
One model family and one reference GPU class in the deterministic pipeline
No measurement of assessment accuracy, expert usefulness or automation bias
Regulatory requirements are discussed by analogy, not as approval of the system
Source analysis · 1 linked source. Primary analysed source date: 15 October 2026.
Read the full report · 9 min The evidence, methods, implications and limitations
The answer: repeatability is possible, but ordinary hosted calls did not provide it
Fourteen commercial deployments—seven model names from three providers reached through six routes—failed to return identical assessments for every repeated prompt. Twelve changed the substantive label on at least one request, even though the author used each interface's accepted low-variance settings. The same model could be more reproducible through one route than another. That means a stored prompt, model name and temperature may not be enough to recreate the preliminary judgment behind a regulated record.
A self-hosted pipeline built by the author did reproduce every tested stage byte for byte under a fixed hardware and software configuration. That is an engineering demonstration, not proof that the output was right. The preprint repeatedly separates determinism from accuracy: a system can reproduce the same wrong conclusion perfectly. The regulatory relevance is therefore audit and change control, not automated approval of a medical device.[1]
What was assessed
The task was a preliminary document assessment. For a requirement defined by an expert, a model returned a label such as Satisfied, Not satisfied or Cannot determine, a written reason and quoted evidence from named files. The author assembled public US Food and Drug Administration documents for blood glucose meters and infusion pumps. Experts would still choose applicable requirements and make the final conformity judgment; the model's role was limited to preparing a source-linked draft.
For the commercial comparison, 70 prompts were selected by fixed rules from blood-glucose-meter device-item pairs and divided into short, medium and long document sets. Every deployment received each byte-identical request five times on each of two days, producing up to ten outputs per prompt. The comparison looked separately at the label, cited files, overlapping passages, exact quotations, comment and complete output bytes. It measured whether outputs changed, not which output was best.[1]
What varied across hosted deployments
No hosted deployment reproduced every prompt exactly. Within one day, ten of the fourteen changed the label for at least one prompt; adding the second day brought the total to twelve. Even when labels stayed stable, cited files, passages, quotations or explanations could change. Some differences appeared only between days. Reducing model reasoning where an interface allowed it did not remove the variation, and shortening the input to retrieved passages eliminated variation only for the smallest models tested.
The study does not rank providers by accuracy. It used changing 2026 products, provider defaults in eight deployments and pay-as-you-go routes in one client region. Different caching, hardware, batching or serving software could contribute, but the author did not have internal access to attribute causes. The practical finding is narrower: a model identifier and nominally deterministic sampling setting did not guarantee a repeatable assessment record.[1]
How the deterministic pipeline worked
The self-hosted system fixed six properties. Files, extracted text, chunks, vectors, retrieval results, prompts and outputs were content-addressed with SHA-256 hashes and component manifests. Scanned pages used deterministic optical character recognition. Embeddings were computed and stored reproducibly. Retrieval was exact and limited to the relevant device documents. The judgment model ran with batch-invariant inference, greedy decoding and grammar-constrained output. Quotations were verified against sources, unverifiable evidence was removed, and each record entered a hash-chained ledger.
On a reference RTX PRO 6000 configuration, the pipeline returned identical intermediate data and outputs across reruns, restarts, reordered documents, concurrent requests, adding and deleting a document, another machine with the same GPU model and different days. The blood-glucose corpus covered 337 documents and 776 device-item pairs; the infusion-pump test covered 85 PDFs and 516 pairs. Batch-invariant serving added about 18% to the wall time in the reported concurrency test.[1]
Hardware and scheduling remained part of the result
Changing the GPU model broke byte-level identity. Text-only extraction remained stable, but OCR output, every embedding set, retrieval results and judgments could differ. Among 650 assessment items with otherwise identical prompts after the hardware change, labels differed for 30. Changing the inference engine's prefill scheduling budget also changed outputs. Disabling batch invariance caused the same open-weight model to vary under concurrency, while enabling it restored repeatability for the tested setup.
This means the reproducibility record must include more than the model and prompt. GPU class, weights, libraries, drivers, inference engine, scheduling settings, retrieval parameters and every preprocessing component can be part of the effective configuration. For regulated records retained for ten or fifteen years, providers may retire models and hardware long before the retention period ends. Stored outputs and provenance therefore remain necessary even when a pipeline can reproduce its current configuration.[1]
What regulators and quality teams can take from it
A manufacturer considering LLM assistance can test repeated runs before using the system in a quality process. It should version the complete pipeline, preserve inputs and outputs, hash evidence, record routes and hardware, and define what level of variation triggers review. A changed label deserves different attention from a punctuation change, but changing evidence can still undermine the audit trail even when the label stays fixed. Final decisions should remain with qualified experts who can inspect the cited source.
The paper cites EU medical-device documentation requirements, US electronic-record controls, FDA and PMDA discussions of reproducibility and the EU AI Act by analogy. None of those sources is presented as a regulator's endorsement of this pipeline or a universal demand for byte-identical generative output. The study offers a testable engineering condition. Whether that condition is necessary or sufficient for a particular regulated use depends on risk, jurisdiction, validation and the authority responsible.[1]
The commercial interest is central
The single author works for GFLOPS Co., which funded the study, develops and sells the proprietary AskDona Assessment product tested and has filed a provisional patent covering the described pipeline. Two company colleagues reviewed drafts. The author also used Claude tools to help write and check analysis scripts and draft and edit the manuscript, then stated that every number and claim was verified. Inputs, outputs and hashes are promised for Zenodo, while the tested product remains proprietary and a minimal reference implementation is promised with a later journal version.
Those disclosures do not invalidate the measurements, but they raise the value of independent reproduction. The strongest result—the company's pipeline reproducing itself—is also the result most closely tied to its commercial product. At publication, no outside group had reproduced the system. Buyers and regulators should therefore demand access to the promised artifacts and repeat the test on an independently implemented pipeline before treating determinism as established beyond this configuration.[1]
Limits that matter most
Public 510(k) documents for two device types stood in for manufacturers' full quality records. Assessment items were guidance sentences selected by rule, not a representative sample of real notified-body or regulatory decisions. The deterministic pipeline used one judgment-model family and one reference GPU class. Its six design properties were sufficient for the operations tried, not mathematically proven to cover every failure. Several controls and follow-up experiments were added during the study rather than preregistered.
No expert-accuracy comparison was reported. The paper does not show whether quoted passages were the ones a regulator would choose, whether draft assessments saved time, whether automation biased reviewers or whether any device would receive a different decision. It is an unreviewed preprint. Reproducibility is useful because it lets a change be investigated, but it is not clinical safety, cybersecurity, legal compliance or evidence that an LLM belongs in a regulated quality system.[1]
What would change the assessment
Confidence would rise if the promised records and reference implementation are released on schedule and independent teams reproduce the fixed-hardware result. Replication should include other models, GPUs, inference engines, document types and quality-management tasks. Studies should preregister configurations and compare exact retrieval with approximate indexes under realistic document updates. Regulators and notified bodies should help define which fields must be stable and what evidence must be retained.
Usefulness needs a separate blinded study. Multiple device experts should judge accuracy, evidence relevance, review time, disagreement and automation bias against a manual process. Only then can organizations weigh the cost of deterministic infrastructure against operational benefit. The current paper supports a concrete warning and a promising design pattern: hosted generative calls can change under apparently fixed inputs, while reproducibility can be engineered locally. It does not yet show that the resulting assessment is one an expert should trust.[1]