A supplier can explain why its clinical AI is acceptably safe within specified conditions. It cannot establish, without examining the deployment, that those conditions exist in your hospital. The local assessment must connect the product's assumptions to the actual patients, staff, systems and recovery arrangements on which safe use will depend.
This article concerns NHS deployment in England, with guidance checked on 10 October 2026. The distinction is explicit in the clinical-risk standards: DCB0129 addresses manufacture, while DCB0160 addresses deployment and use. These are connected responsibilities, not interchangeable certificates. The proposed handover method below is an implementation aid, not an additional official standard.
Start with the assumptions, not the cover page
Imagine a fictional outpatient service buying a tool that drafts letters from consultation recordings. The supplier's safety argument assumes that the responsible clinician reviews the complete draft before release, that the selected patient is confirmed and that unapproved material cannot enter the clinical record.
The hospital's implementation, however, sends drafts to a shared administrative queue. A member of staff can release a letter when a clinic runs late, and the review screen displays only the first part of the document. Nothing about the underlying model needs to change for the original safety argument to become incomplete.
The question is therefore not simply whether the supplier has produced a safety case. It is which claims depend on local behaviour, and whether that behaviour has been demonstrated. A statement such as "reviewed by a clinician" should lead to questions about the reviewer, information displayed, available time, release permissions and response when the reviewer is absent.
Turn supplier assumptions into a local handover
A useful handover makes every consequential assumption testable. Rather than filing the supplier's documents as background reading, select the assumptions that prevent identified hazards and map them to local arrangements.
| Supplier assumption | Local question | Proposed evidence before use |
|---|---|---|
| The correct encounter is selected | Can a user change patients while a draft remains open? | A supervised patient-switching test using synthetic records |
| A clinician checks the complete output | Who reviews the whole document, including attachments? | An observed review workflow and release permissions |
| Failed transfers are visible | Where does an unsuccessful write-back appear? | A simulated failure with a named recipient for the alert |
| Users understand the limitations | Can staff recognise an unsupported task? | A task-based training assessment |
| The service can operate without the tool | What happens during an outage? | A rehearsed fallback, including unfinished work |
The local owner should be someone able to change the relevant process, not merely the person who received the document. An administrator may own a queue configuration, a clinical lead a review protocol, and an IT team an integration control. The clinical safety assessment should explain how those parts work together.
The same product can encounter different hazards
Consider an emergency department using the same documentation technology. Interruptions, handovers and rapidly changing working diagnoses create different test cases from a scheduled outpatient clinic. A provisional interpretation might be superseded before the note is approved. The assessment should ask which version reaches the receiving team and whether outstanding uncertainty survives the transfer.
In general practice, a fictional deployment might place suggested follow-up tasks in an individual doctor's inbox. That arrangement needs an answer for annual leave, locum sessions and work that belongs to another service. A technically successful transfer can still leave nobody responsible for completing the task.
These examples are hypothetical, not reported failures of a particular supplier. Their purpose is to show why a list of supported settings is not a substitute for examining the work in each setting. A manufacturer may have relevant evidence from all three environments; the purchasing organisation should identify which evidence matches its configuration.
Test the interfaces where responsibility changes
An integration demonstration often ends when text appears in the destination system. A safety assessment should continue. Is it labelled as a draft? Does acceptance also create a diagnosis code? Does a later edit update the referral already generated from the earlier version?
The distinction matters beyond AI. HSSIB's interim investigation into electronic referrals, published on 18 August 2026, examines the safety of ongoing-care referrals across electronic systems and organisational boundaries. It is not a trial of generative AI. Its relevance here is that information transfer must be understood as part of a care pathway, rather than treated as an isolated technical success.
For a proposed AI implementation, construct tests around the boundaries: a rejected destination, an unavailable reviewer, a patient who changes details, an encounter reopened after approval and an action duplicated after a retry. Record what the system did and what staff understood. Both are needed to identify an unsafe gap.
Approval must survive maintenance and eventual withdrawal
An assessment that was reasonable at installation can become incomplete when a new feature changes the work. A drafting tool acquiring permission to send messages is not simply a more convenient version of the same workflow. The consequential action, affected people and recovery requirements have changed.
A proposed change register should distinguish security maintenance from changes to clinical behaviour, source selection, model configuration, permissions or the population served. The depth of reassessment should follow the change, not its marketing label. Minor interface changes can matter when they obscure warnings or make acceptance easier than review.
Withdrawal also deserves a plan. Identify where approved records, unfinished drafts, pending tasks and relevant safety evidence will remain. Disabling an account should not leave a clinic unable to identify work that was in progress. This lifecycle perspective is part of why the deployment standard includes more than initial installation.
What a defensible local decision looks like
A useful approval record says what is being authorised, for whom, in which setting, with which controls, and what remains outside scope. It also identifies unresolved issues and the person authorised to restrict use if the assumptions fail. It should be understandable to staff who were not involved in procurement.
For a reference workflow, the same discipline means distinguishing a general knowledge question from processing an identifiable patient record. As described in iatroX's methodology, checked on 10 October 2026, retrieval and source-grounding are design features supporting verification. They do not establish that every answer or local deployment is safe.
The practical objective is not to duplicate the supplier's engineering work. It is to make sure the organisation is not relying on a safeguard that exists only in the supplier's assumed workflow.
CE marked, but is this deployment ready?
Certification adds an important layer to the supplier-to-hospital handover, but it does not collapse product conformity and local clinical safety into the same decision. This section was added following a review of the relevant guidance on 13 October 2026.
The European Commission's notified-body guidance explains the role of designated conformity assessment. The MHRA's UK market-access guidance separately describes the conditions for placing devices on the Great Britain market. A buyer should establish the applicable route and documents for the actual product, rather than treat a CE logo as either irrelevant or a complete deployment permission.
Return to the fictional outpatient letter tool. Suppose its manufacturer supplies relevant conformity documentation alongside the safety case. That can support the assessment of the product within its intended purpose. It does not establish that the hospital's shared queue, truncated review screen or administrative release permissions match the assessed assumptions.
The useful response is not to start the entire assessment again from nothing. It is to distinguish evidence that can be relied upon from the local questions it leaves open.
| Handover item | What the hospital should establish | Proposed local release condition |
|---|---|---|
| Applicable conformity documents | They concern the legal manufacturer, product and relevant scope | Resolve any mismatch before relying on the claim |
| Intended purpose and instructions | The proposed patients, users and setting fit | Restrict use where the evidence does not support the broader proposal |
| Safety case and residual risks | Required controls are visible and assignable | Name an owner and verification method for each local control |
| Configuration and integration description | The deployed behaviour matches the evidence | Test consequential differences, including release permissions |
| Change and incident arrangements | The adopter will receive information needed to act | Agree notification, restriction and recovery responsibilities |
This is an illustrative handover checklist, not an official certificate or a complete compliance template. Some documents may be supplied through controlled access. The test is whether the adopter can understand and discharge its responsibilities, not whether every internal file is publicly downloadable.
A conditional go-live decision for the fictional hospital
A defensible decision might permit the tool only in the outpatient workflow for which full clinician review and controlled release have been demonstrated. It would withhold the proposed administrative release permission until that change had been assessed. It would also specify what happens to drafts when the responsible clinician is absent.
That is a proposed decision structure, not the result of an actual implementation test. In a real project, no control should be marked verified until the relevant test or evidence review has occurred. Missing evidence should remain visible rather than being converted into an assumption that staff will compensate.
The joint transparency principles for machine-learning medical devices support communicating information relevant to safe use, limitations and local acceptance testing. A hospital can use that principle to request an operational handover rather than a marketing summary.
Clinical safety support can help translate the documents into a hazard log, assigned controls and a release argument. As described on 13 October 2026, Insights by iatroX offers CSO and regulatory-readiness services in that advisory space. Such work does not replace the manufacturer's obligations, the independent conformity assessment or the hospital's own accountable deployment decision.
Frequently asked questions
Does a supplier's safety case make a local assessment unnecessary?
No. Manufacturer evidence informs the local assessment, but the deploying organisation still needs to address its workflow, integration, users and operating conditions.
Must every organisation repeat every supplier test?
Not necessarily; relevant, reliable evidence can be reused where its assumptions match. Local differences and consequential interfaces still need examination rather than an automatic equivalence claim.
Should reference tools receive the same assessment as clinical agents?
The depth and content should reflect the intended task, information and potential consequences. Reading guidance, recording consultations and executing actions create different questions, even when supplied by one company.