Making every stage of medical device document assessment with large language models deterministic
Organizations: GFLOPS Co., Ltd., Tokyo, Japan.
Abstract
To show that a medical device complies with regulation, experts judge whether documents and records meet each requirement and record the judgment for others to verify. For each assessment item that experts define, large language models could prepare a preliminary assessment: a label such as Satisfied or Not satisfied, a reason and quoted evidence. We sent fourteen commercial deployments of such models (seven models from three providers, through six routes) the same request repeatedly, with the deterministic sampling settings each accepted; every deployment returned differing assessments for at least one request, and in twelve the label changed. Reducing reasoning where the interface allows it did not reduce the variation, and prompts of retrieved passages removed it only for the smallest models. The same open-weight model was reproducible or not depending only on how it was served. A pipeline we built to be deterministic at every stage -- text extraction and optical character recognition (OCR), chunking, embedding, indexing, retrieval and inference -- returned byte-identical output at each stage across reruns, interruptions, edits, machines of one graphics processing unit (GPU) model and days, for blood glucose meter and infusion pump documents. OCR, embedding and approximate retrieval varied when their own serving was not made invariant, and outputs changed with the GPU model and with the inference engine's scheduling settings, which therefore belong in the recorded configuration. End-to-end determinism is achievable and gives a testable basis for audit and change control.
Figures & tables
| Layer | Field | What is compared | Run 3 | Run 4 | Same? |
|---|---|---|---|---|---|
| Substance | Label | The model’s assessment label (not a ground-truth label). | Satisfied | Not satisfied | no |
| Files | The set of documents cited as evidence. | document 2 | document 2 | yes | |
| Passages | Where in the source the quotations are: two runs cite the same passage when their quotations overlap at the same place in the same document, whatever the spacing or order. | the repeatability and intermediate-precision studies: “… using three test strip lots and ten AG-607 blood glucose meters” | the hematocrit and interference studies: “The evaluation included 5 meters, each tested with two replicates …” | no | |
| Text | Quotes | The exact quotation strings, character for character. | 2 quotations | 3 quotations | no |
| Comment | The exact text of the reason. | “The precision studies used ten AG-607 meters … This meets the minimum …” | “Where the meter count and replicate numbers are reported, fewer than 10 measurements were taken …” | no | |
| Output | The whole response, byte for byte (not a separate output field). | no |
| Operation | Ingestion | Embedding | Judgment |
| Fixed configuration: operations that should not change the result | |||
| T1 Repeat; repeat on another day | |||
| T2 Interrupt and resume; inference server restarted a | |||
| T3 Reverse order; hash order | |||
| T4 Concurrency 1, 4, 16 documents; 1, 8, 16 items | |||
| T5 Add a document, assess, delete it | snapshot identical | ||
| Item | Sentence (subsection) |
|---|---|
| frn-01 | For this reason, any newly developed device should have its own unique safety case. (5. Safety Assurance Case) |
| frn-02 | The safety case for a specific infusion pump should incorporate the following: The persons for whose use the device is represented or intended; and The conditions of use for the device, including conditions of use prescribed, recommended, or suggested in the labeling or advertising of the device, and other intended conditions of use. (Safety Assurance Case: A. General Considerations for Safety Case Development) |
| frn-03 | Individual pump designs, environmental conditions, and conditions of use for the device will dictate what hazards should be identified and mitigated. (Safety Assurance Case: B. Hazard Analysis) |
| frn-04 | Your safety assurance case should address the appropriateness of any standard to support clearance of your infusion pump. (Safety Assurance Case: C. Performance Testing) |
| frn-05 | For a pump that does not maintain a constant flow rate, test results should be used to generate a representative flow profile. (Safety Assurance Case: C. Performance Testing) |
| frn-06 | The analysis should include a description of your system’s reliability specification and the reliability activities completed to verify and validate that the specification has been met (e.g., design analysis, test plans, and test reports). (Safety Assurance Case: C. Performance Testing) |
| T7 H100 | T8 budget 4,096 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Reference label | Satisfied | Not sat. | Cannot det. | none | Satisfied | Not sat. | Cannot det. | none | |
| Satisfied | 359 | 0 | 21 | 0 | 377 | 0 | 3 | 0 | |
| Not satisfied | 1 | 37 | 2 | 0 | 0 | 39 | 1 | 0 | |
| Cannot determine | 7 | 2 | 346 | 1 | 2 | 0 | 354 | 0 | |
| Stage | Component, parameters and rule |
|---|---|
| Extraction | pdf.js text layer; a page is read by OCR when its text layer, with white space removed, has fewer than 200 characters; the page is rendered at 150 dpi and decoded greedily (temperature 0, seed 0, at most 6,000 tokens) by allenai/olmOCR-2-7B-1025 , with zai-org/GLM-OCR used only when olmOCR-2 stops at the token limit; both served by vLLM 0.29.0 with batch invariance. Hashes: original (file bytes); provenance (original hash, extractor manifest, each page’s method); version (text, metadata, provenance hash). |
| Chunking | splitText v1: chunks of at most 1,400 characters overlapping by 120, cut at the last paragraph or sentence boundary in the final 40% of the window when there is one. Hash: the chunk-set hash over the chunk strings. |
| Embedding | Qwen/Qwen3-Embedding-8B , bfloat16, PyTorch deterministic algorithms ( CUBLAS_WORKSPACE_CONFIG=:4096:8 ), one text at a time on the GPU; document vectors unit-normalised and stored as float32; the question embedded at run time with the instruction prefix “Instruct: Given a query, retrieve passages that answer or support it”. Hashes: embedding-set identifier (version hash, chunker, embedder manifest); vector hash over the float32 vectors in sequence. |
| Retrieval | Tokenizer simple v1: lower-case, NFKC, maximal runs of letters and digits, no stop words or stemming. BM25 with , , statistics over the chunks in scope (the device’s documents). Cosine similarity as the dot product of unit vectors. Each ranking truncated to its top 30, min–max normalised, combined with weights 0.5 and 0.5; ties broken by document identifier, then chunk index; top six kept. Hash: query, parameters and scored hits. |
| Judgment | RedHatAI/gemma-4-31B-it-FP8-dynamic on vLLM 0.29.0, VLLM_BATCH_INVARIANT=1 , TRITON_ATTN , enforce-eager, chunked prefill with max-num-batched-tokens 16,600, max-num-seqs 16, FP8 KV cache, xgrammar structured output without white space, temperature 0, seed 0, at most 1,024 output tokens. Hashes: prompt (the chat messages); raw output (the output string). |
| Verification and record | A quotation and the passage it cites are NFKC-normalised, all quotation marks unified and all white space removed; each part of the quotation around an ellipsis must be an exact substring of the passage; failed quotations are recorded as rejected and removed, and the label is downgraded to Cannot determine only when no quotation remains. The ledger chains entries by hashing each with the previous entry’s hash. |
LLM Reliability
Large language model reliability studies whether outputs remain correct, calibrated, robust, and controllable across prompts, contexts, and deployment conditions.
See all 802 papers