A useful clinical AI safety label should tell a clinician what the tool is for, when it should not be used, what the clinician must check and how to respond when something does not fit. A row of badges cannot communicate those decisions. The information needs to change behaviour at the point of use.
The format proposed here is an original communication aid, not an official regulatory label, certification scheme or claim of compliance. It draws on the joint transparency principles for machine-learning medical devices, published in June 2024 and checked for this article on 13 October 2026.
Start with the decision the user faces
Imagine a fictional clinician opening a software-generated outpatient summary just before reviewing a patient. They need to know whether the summary includes the complete record, whether missing information is marked and whether the tool has already taken any action.
They do not necessarily need to read the entire technical file at that moment. However, shortening the information should not remove the limitations that affect safe use. The challenge is to distinguish essential operational information from background assurance detail, while preserving a route to the latter.
The MHRA's intended-purpose guidance gives the underlying description its structure: function, user, population and environment. A clinician-facing brief should translate that scope accurately rather than invent a simpler but broader promise.
A proposed one-page safety brief
The following mock-up concerns a fictional product called ReviewBrief. It describes a proposed restricted workflow only. Its build identifier is invented, and no certification or successful evaluation is implied.
| Field | Fictional clinician-facing entry |
|---|---|
| Tool and configuration | ReviewBrief, proposed training build R1; not a live clinical approval |
| Supported task | Prepare an outpatient record summary for review by the responsible clinician |
| Required information | Selected encounter and the specified records; missing sources must remain visible |
| Intended users | Staff trained for the defined review workflow |
| Outside this example's scope | Autonomous diagnosis, triage, treatment and patient communication |
| Human role | Review the complete draft, resolve consequential uncertainty and approve the final record |
| Important limitation | A fluent summary may omit relevant information or misrepresent its status |
| Action status | Draft only; no external action should be inferred from generated wording |
| When to stop | Wrong encounter, unexplained missing information or a material mismatch with the source |
| Escalation | Use the locally designated clinical safety and technical support routes |
| Supporting assurance | Link the actual configuration to its applicable evidence and local decision record |
A real implementation would replace the fictional entries with verified details and functioning local contacts. It should not display "approved" unless the nature and scope of that approval are clear.
Keep the assessment claim separate from operating instructions
The brief can identify the applicable assessment documentation, but that should not crowd out the user's practical task. A certificate about a management system and a conformity assessment of a medical device establish different things; neither is an instruction to accept every output.
A useful interface might provide a short scope statement with access to the relevant documents. The wording should identify what has been assessed and avoid implying that the entire platform is covered. The European Commission's description of notified bodies reinforces that assessment operates within a designated scope.
The user also needs local information that may not appear in the product-level documents: which functions are enabled, who reviews exceptions and what happens when the responsible team is unavailable. Product assurance and local instructions should be linked, not merged into an unexplained green badge.
Show the information when it can affect the action
A safety brief hidden in onboarding may not help when a user encounters an unsupported task months later. Equally, displaying the full document repeatedly can make it harder to find the detail that matters.
Our proposed design uses a stable summary with context-sensitive reminders at consequential boundaries. A change of patient, unavailable source or proposed external action should expose the relevant information before the user commits, not after the event.
This is a design proposal to evaluate, not a claim that a particular interface arrangement has been proven to reduce harm. The transparency principles support considering the audience, timing and presentation of information; the actual effectiveness depends on testing with intended users.
Test understanding, not whether the page was opened
A useful educational test would show participants the fictional brief and then present cases that fall inside and outside its limits. Ask them what they would do, what remains uncertain and where they would seek further information.
One case might contain a summary from the wrong encounter. Another could include a confident statement whose source is unavailable. A third might ask the clinician to assume that a referral has been sent because the generated text says it is complete.
The proposed outcomes include recognition of unsupported use, correct interpretation of action status and ability to locate the escalation route. Reading time and satisfaction can be measured too, but they do not establish that users understand the boundary.
No test results are reported here. A real evaluation would need a defined configuration, appropriate participants, prespecified criteria and analysis of errors rather than a claim based on a polished mock-up.
Make the brief accessible without making the medicine simplistic
Plain language should describe the task and the limitation directly. "Review required" is less useful than stating what must be reviewed and what approval permits. "May be inaccurate" is less useful than explaining the types of information that require attention in this workflow.
The format should also work for staff who do not share the designer's assumptions about terminology or navigation. An understandable version identifier, a clear explanation of missing sources and an accessible help route can matter more than decorative assurance symbols.
This does not justify removing clinically important uncertainty. A concise summary should preserve distinctions between reported, observed, inferred and unassessed information. The objective is less effort finding the relevant limit, not less effort understanding its clinical significance.
Give the brief an owner and a change trigger
A safety brief can become misleading if it remains unchanged while the product or local workflow changes. The owner should know which updates require revision: expanded permissions, different sources, new patient groups or a changed review process.
The joint change-control principles support a lifecycle approach. In an applicable English NHS setting, the local brief should also connect with the manufacturer's and adopter's responsibilities under DCB0129 and DCB0160.
As described on 13 October 2026, Insights by iatroX offers clinical safety and readiness support. Helping translate a safety argument into operational information is a relevant advisory task, but this proposed format is not a certification issued by iatroX. Its value would need to be demonstrated through clearer, more appropriate use.
Frequently asked questions
Is the proposed safety label an official regulatory requirement?
No. It is an editorial communication format informed by transparency principles, not an official label or a complete compliance specification.
Can a safety brief replace the instructions or technical documentation?
No. It should accurately summarise the information users need while preserving access to the applicable instructions, evidence and local arrangements.
How should a team test whether the brief helps?
Use representative task-based exercises that examine whether users recognise limitations and respond appropriately. Opening the page or liking its design is not sufficient evidence of understanding.