The organisation operating a healthcare AI workflow needs a defined process for assessing changes that could affect its behaviour. That responsibility should be shared through clear arrangements with the supplier, not left to an individual clinician noticing an unfamiliar answer. A quiet interface does not establish that the model, retrieval system or action rules underneath it are unchanged.
An update can change more than the version label
A foundation-model replacement is an obvious change. Less visible changes can include the instructions surrounding the model, the source collection, retrieval ranking, output checks, clinical templates and connected-tool behaviour. A product may look identical while one of these components changes what users receive.
The NCSC's secure-operation guidance, published in November 2023 and checked on 10 October 2026, explicitly recognises that changes to data, models and prompts can alter behaviour. It recommends update processes that support evaluation, including treating major changes as new versions.
For healthcare, the useful question is what the update could change in the authorised workflow. Faster generation, different wording and a new action permission have different implications. A single label such as "maintenance release" should not replace an assessment of the actual change.
Assign ownership before the first surprise
A proposed change process should identify the supplier contact, the local technical owner, the clinical safety lead and the service manager responsible for operational consequences. These roles can be held by different people, but the decision route should be understandable to front-line staff.
The supplier should explain the change, affected functions, expected benefits, known limitations and any required customer action. The local team should determine whether its configuration and patient population introduce concerns that the supplier's generic assessment does not resolve.
The clinician's role is important but bounded. They should have a simple way to report an unexpected output and know when to stop relying on the affected function. They should not be expected to infer invisible infrastructure changes or reconstruct the product's release history during a consultation.
Use a change register that follows the workflow
A useful register records the product release, relevant component versions, configuration, source collection where applicable, permissions and date of local introduction. It also records the evidence reviewed and the decision about additional testing.
The register need not reproduce every internal engineering detail. It should be sufficient to answer a practical question: which system produced this output under this local configuration? If the supplier cannot provide a stable identifier for a component, document that limitation rather than inventing precision.
For a fictional referral assistant, the relevant change might be a new destination-selection mechanism rather than the language model. A register limited to model names would miss the component most important to investigating a misrouted referral.
Regression tests should protect meaning and boundaries
A proposed regression set should include representative routine cases, known difficult cases and earlier failure examples. Score clinically important meaning, handling of missing information, uncertainty, correct destinations and action status. Do not judge success solely by similarity to the old wording.
An update may legitimately produce a different answer because the underlying guidance changed. That is why the test needs an independently maintained expectation, not automatic agreement with the previous release. Conversely, a fluent new answer may conceal a lost exception that a text-similarity score would not identify.
Keep synthetic cases separate from patient-care records, and maintain appropriate governance for any retrospective material. The purpose is to test the intended system before expansion, not create an uncontrolled archive of clinical conversations.
A fictional release decision
Imagine an organisation using an AI assistant to prepare discharge summaries. A release changes how uncertainty is condensed and adds an optional facility to prepare follow-up tasks.
The documentation change calls for testing whether provisional findings remain provisional and whether pending investigations remain visible. The new task function requires a separate decision about permissions, ownership and completion evidence. Passing the summary tests would not automatically justify enabling the action feature.
The team might accept the documentation update while leaving task preparation disabled pending further evaluation. This is a proposed scenario showing function-specific governance, not a claim that a particular supplier has released these features or handled them unsafely.
Do not solve change risk by freezing security indefinitely
Keeping an old version forever may preserve familiar behaviour while introducing other risks. The NCSC guidance also supports secure, timely updating. A healthcare change process should therefore distinguish urgent security remediation from changes needing a broader clinical evaluation, without assuming the two categories can never overlap.
Where an urgent update cannot wait for the full preferred test cycle, the team should define compensating controls and a focused assessment. That might mean temporarily restricting a function, increasing review or reverting to an approved non-AI workflow while the update is evaluated.
The decision should be documented with its uncertainties. "We did not update" is not inherently safer than "we updated"; the answer depends on the vulnerabilities, behaviour changes and available alternatives.
Rollback must include pending work
A rollback plan should identify which components can be restored and what happens to actions already prepared or executed. Restoring a previous model does not retract messages, repair records or resolve tasks created by the newer version.
Test how the team identifies potentially affected outputs and reconciles pending work. Some cases may require clinical review even when no technical error is confirmed, because the basis of an important decision is uncertain. Others may be unaffected because the changed component was not involved.
The NCSC's secure-deployment guidance provides a broader foundation for deployment controls and incident preparation. Local procedures should connect technical recovery to continuing care rather than treating the restoration of service as the only endpoint.
Update the users' understanding as well as the software
A meaningful release communication should explain what users can now do, what remains outside scope and what deserves particular checking. A long technical changelog is not a substitute for a clear account of changed clinical behaviour.
The same principle applies to clinical-reference tools, including iatroX: published methods and product descriptions should not be treated as permanent guarantees independent of version and source changes. A team's learning response might involve a fictional case demonstrating a newly recognised limitation, followed by source checking and discussion of the appropriate fallback.
The aim is not to make every clinician a release engineer. It is to ensure that changes are assessed by the right people and that front-line users understand the consequences relevant to their work.
Connect the release process to conformity assessment and local acceptance
The supplier's engineering release, any required conformity-assessment decision and the adopter's local deployment decision are related, but one does not automatically substitute for the others. This section was added on 13 October 2026 to make that connection explicit.
Return to the fictional discharge-summary update above. The manufacturer needs to establish which product claims and risks are affected by the altered treatment of uncertainty and the proposed task function. It should identify whether the change remains within its documented intended purpose and assessment arrangements, or requires further assessment under the applicable route.
The adopter then needs information relevant to its own configuration. The English NHS clinical-risk standards distinguish manufacturer responsibilities from deployment and use. A supplier's statement that a release has passed its internal tests does not establish that a hospital's particular interface, permissions or review staffing are covered.
A proposed release record would connect the change description, affected safety claims, verification evidence, assessment position, user communication and local decision. It should identify outstanding dependencies rather than allowing a green engineering status to become an unexplained clinical go-live decision.
Distinguish maintenance, bounded change and expanded purpose
The table offers practical triage categories, not universal legal definitions of significant or non-significant change. The applicable assessment route determines what further review is required.
| Change description | Question before release | Evidence or decision to establish |
|---|---|---|
| Routine maintenance | Could the change nevertheless affect clinical behaviour or a control? | Relevant technical and clinical impact assessment |
| Modification within a defined plan | Does this exact change meet the plan's scope and conditions? | Required verification, impact assessment and documented conformity with the plan |
| Changed intended purpose or consequential function | Does previous evidence still support the expanded claim? | Additional evaluation and any required assessment before the new use |
| Urgent remediation | What risk arises from delay and what from the update? | Proportionate urgent review, restrictions and follow-up verification |
For the fictional discharge-summary tool, adding a task function should not be described as ordinary maintenance simply because it is delivered in the same software package. Equally, a security fix should not be delayed automatically because the organisation has only one slow process for every kind of change.
What a predetermined change-control plan can and cannot do
The joint FDA, Health Canada and MHRA principles, published on 24 October 2023, describe a plan specifying certain proposed modifications, how they will be implemented and controlled, and how their impacts will be assessed. The principles emphasise bounded scope, risk, evidence, transparency and the product lifecycle.
The important word is specified. A plan should not be presented as advance permission for arbitrary model replacements, new patient populations or expanded actions. The document also states that implementation may differ between regulatory jurisdictions. Its publication does not itself confer authorisation on a manufacturer's preferred plan.
For the fictional release, a proposed plan might define a particular category of component modification and the tests required before use. The manufacturer would still need to establish whether the actual change fits, complete the required evidence and follow the applicable assessment arrangements. A change outside those boundaries would return to the appropriate review route.
Even where a plan is accepted, the local adopter still needs relevant information about changed behaviour and operating conditions. Transparency principles support that communication. As described on 13 October 2026, Insights by iatroX offers clinical safety and readiness advice that can help connect these responsibilities, without replacing the independent assessment or organisational release decision.
Frequently asked questions
Does an unchanged interface mean the clinical AI is unchanged?
No. Models, prompts, retrieval sources and connected functions can change without an obvious alteration to the screen.
Should an organisation block every automatic update?
Not necessarily, because delayed security remediation can create its own risk. The organisation needs an agreed change process that handles urgency, clinical impact and proportionate testing.
Is restoring the previous version enough after a problematic update?
Not always. The team must also identify affected outputs and reconcile any records, messages or unfinished actions created while the changed version was in use.