What changes when LLMs stop writing safety text and start linking evidence for medical devices?

Medical devices now run on software that updates over the air and learns from data. That software must meet ISO 14971 for risk management and IEC 62304 for lifecycle processes. Every requirement, design choice, test result, complaint, and post-market signal has to stay consistent with the others. The work is expensive. It also depends on experts who are in short supply.

Large language models look like a natural fit because the whole process runs on documents. But the studies so far treat the problem as text generation. They use generic prompts or public examples. They rarely keep source links, traceability, uncertainty handling, lifecycle updates, or a record of expert review. Without those, the output cannot be used in a regulated submission.

Why current LLM approaches fall short in regulated development

The paper identifies a mismatch. Researchers ask models to write hazard tables or traceability matrices. The models comply. The result looks plausible. But no one can point from a cell in the matrix back to the requirement that justified it. No one knows which claims the model invented. No one sees where the expert disagreed and why. That breaks the evidence chain regulators expect.

The authors list six gaps. Missing source links. Missing traceability. Missing uncertainty handling. Missing lifecycle updates. Missing recorded expert review. Missing support for method-specific generation. Each gap appears in multiple published studies. Together they make the output unusable for the actual job.

How the evidence-grounded framework connects artifacts to expert review

The proposed framework does not generate a final safety case. It prepares candidate artifacts that an expert can accept, reject, or edit. The pipeline has five stages. First, device artifacts are ingested and linked — requirements, design records, test reports, complaint files, post-market data. Second, a controlled knowledge store retrieves relevant standards clauses, prior analyses, and domain rules. Third, method-specific generators produce candidate safety items: hazards, risk controls, verification tasks, trace links. Fourth, critique and uncertainty checks flag unsupported claims, duplicates, and contradictions. Fifth, every candidate and every flag is presented to a human expert with the full provenance trail. The expert decision is recorded.

The framework treats the LLM as a research assistant that drafts, cites, and self-critiques. The expert remains the decision maker. The system does not decide whether a device is safe. It does not grant regulatory approval. Those statements appear explicitly in the paper.

What the framework explicitly does not do

A hard line appears in the paper. The framework prepares, links, checks, and updates candidate safety artifacts. It does not replace the safety engineer. It does not replace the regulatory submission. It does not certify anything. The distinction matters because many demos imply the opposite by showing a polished PDF that looks like a finished deliverable. The paper refuses that framing.

How they plan to evaluate it with real case studies

Evaluation will not use public benchmarks. The team plans non-public or newly built medical-device case studies. Expert reference analyses will measure coverage, correctness, relevance, traceability, duplicate rate, unsupported claims, and review effort. Those metrics map to the six gaps. If the framework closes them, the numbers should show it. The paper does not report results — the work is submitted to ISSRE 2026, AISQ track, and the evaluation is outlined as future work.

The shift is subtle but concrete. Stop asking the model to write the safety case. Ask it to keep the evidence connected while the expert writes the case. That is the research problem the paper puts on the table.