A clinical AI evidence pack should connect a defined product claim to the evidence supporting it, the limitations that remain and the controls needed in use. It should let a reviewer trace what was tested to the system being proposed. A collection of publications and certificates is not enough when their relevance is unclear.
The contents page below is an editorial checklist, not a universally sufficient regulatory submission. The appropriate evidence depends on the product, risk, intended purpose and jurisdiction. Sources were checked on 13 October 2026, including the joint good machine learning practice principles.
Begin with an answerable claim
Consider a fictional tool that helps clinicians identify follow-up questions from an outpatient record. "Improves care" is too broad to guide a useful evaluation. "Identifies specified unresolved information for clinician review in this defined workflow" is more amenable to testing, although it still needs careful specification.
The claim should identify the intended users, patient population, available information and action expected after the output. The MHRA's intended-purpose guidance provides the regulatory foundation for that clarity.
The evidence pack should also state what is not claimed. If the tool has not been evaluated as a triage system, a reader should not have to infer that limitation from the absence of a triage study in an appendix.
An illustrative contents page
The following index is designed for the fictional follow-up tool. It should be adapted, not copied into a submission with an assumption of completeness.
| Evidence section | What the reviewer should be able to establish |
|---|---|
| Product and claim map | The system, intended purpose, users and exclusions |
| Configuration record | Which models, prompts, retrieval sources, interfaces and permissions were evaluated |
| Clinical rationale | Why the proposed task matters and how the output is intended to help |
| Data and reference standards | Where evaluation material came from and how appropriate answers were established |
| Performance evaluation | Results for relevant tasks, including failures and uncertainty |
| Human-AI workflow evaluation | What happens when intended users interpret and act on the output |
| Risk and control evidence | Which hazards are addressed and whether controls have been verified |
| Applicability and limitations | Where findings may not transfer and which questions remain unresolved |
| Release and lifecycle plan | How changes, concerns and ongoing performance will be managed |
| Deployment handover | What an adopter must know, provide and test locally |
A short navigation layer can make a substantial technical package usable. Each entry should point to evidence rather than merely repeat that a policy exists.
Separate the evidence types instead of merging their claims
A software test may establish that a button cannot release an unapproved draft. A clinical evaluation may examine whether the draft includes the right information. A user study may examine whether clinicians recognise an important omission. Those findings are complementary, not interchangeable.
The good machine learning practice principles include representative testing, appropriate reference data and assessment of the human-AI team. They provide a useful discipline for avoiding a model-only evidence package when the commercial claim concerns clinical work.
For the fictional tool, a favourable model result on complete records would not establish performance when correspondence is missing or contradictory. A successful interface demonstration would not establish that staff notice the missing context. The evidence register should keep these distinctions visible.
Describe how the reference answers were established
Readers need to understand what counted as an appropriate output and who decided. A benchmark with a convenient answer key may not capture legitimate variation in clinical practice. Equally, unrestricted reviewer opinion can make a result difficult to interpret.
Our proposed evaluation protocol would define the task, provide adjudication criteria, record disagreement and explain how ambiguous cases are handled. It would distinguish a missing essential question from an optional additional question, rather than count both as identical errors.
The pack should preserve clinically meaningful uncertainty. Where experts reasonably disagree, the product may need to expose that uncertainty instead of being trained or scored to imitate one confident label. The evaluation design should explain which disagreements reflect ambiguity and which indicate a substantive failure.
Make denominators and exclusions inspectable
A result is difficult to interpret without knowing what was counted. The unit could be a statement, record, encounter, user or completed care episode. Excluding incomplete interactions may produce a favourable view of completed cases while obscuring a different operational problem.
A proposed results table should therefore state the unit, evaluated population, exclusions, missing outcomes and relevant uncertainty. Separate minor wording differences from consequential omissions or inappropriate actions. Do not convert every kind of performance into a single reassuring percentage.
This is a reporting recommendation, not a claim that the fictional tool has produced any particular score. Where testing is planned but not completed, the entry should say so plainly and identify the decision that remains dependent on it.
Include the user as part of the system being assessed
A clinician can receive a technically accurate output and still misunderstand its scope. A product can also help a user notice something important that they would otherwise miss. Both possibilities need direct examination rather than assumptions about professional expertise.
The joint transparency principles emphasise information relevant to human-centred use. A practical test might ask intended users to identify an unsuitable case, locate the supporting evidence and respond to an uncertain result. The evaluation should record what people do, not only whether they say the interface is clear.
For the fictional follow-up tool, a useful exercise would include a record that appears complete but refers to an unavailable attachment. The question is whether the system and user preserve that missingness, not whether the generated list reads fluently.
Keep the gaps beside the favourable findings
An evidence register should make limitations easy to locate. A proposed entry might say that a workflow was assessed with specialist users but not with the broader workforce proposed for the next deployment. Another might identify limited evidence for a particular communication need.
Those gaps do not all require the same response. Some may justify further testing, others a restricted scope or an additional control. The important point is that the decision-maker sees them before accepting the broader claim.
Change management belongs in the same pack. The joint predetermined change-control principles support bounded modifications and evidence across the lifecycle. A publication about an earlier configuration should not silently become evidence for a materially changed system.
Turn the pack into a deployment conversation
For an English NHS adopter, the evidence must connect to local clinical-risk work under DCB0160, alongside the manufacturer's responsibilities. The handover should explain required review, unsupported uses, configuration assumptions and the response to concerns.
As described on 13 October 2026, Insights by iatroX supports clinical safety and readiness work. Its relevant role is helping organise and interrogate the evidence, not converting an incomplete package into a guarantee of safety. A strong pack makes the justified claim easier to see and the unjustified extension harder to make.
Frequently asked questions
Is a clinical AI evidence pack the same as a regulatory submission?
Not necessarily. This article proposes an organising framework; the actual submission must satisfy the requirements of the relevant product and assessment route.
Should negative results and unresolved questions be included?
Yes, they are relevant to understanding the limits of the claim and deciding what can safely proceed. They should be linked to actions, restrictions or further evidence needs rather than hidden from the summary.
Does a peer-reviewed paper validate every version of a product?
No. The evaluated configuration and conditions must be connected to the version and use being proposed, with changes assessed explicitly.