skip to main content
iatroX JournalClinical AI

Should Clinical AI Be Regulated Like Traditional Medical Devices? The Problem of Changing Software

Featured image for Should Clinical AI Be Regulated Like Traditional Medical Devices? The Problem of Changing Software

Updated 21 October 2026.

A clinical AI product can keep the same name while changing the model, evidence retrieval, prompts or settings that determine its output. That creates a basic assurance problem: does the evidence describing last month's product still describe the product a clinician uses today?

The issue is not that all traditional device regulation is static or incapable of handling change. Medical devices have long required change management. The difficulty is that contemporary software can change through multiple interacting components, sometimes supplied by different organisations, with effects that are hard to infer from a conventional release note.

Three kinds of change should not be confused

A manufacturer-led update replaces or modifies part of the product. An organisation-level configuration changes how it operates in a particular service. Personalisation changes aspects of the experience for an individual user. Each can matter, but they do not necessarily create the same risks.

Nor should every personalised feature be called autonomous online learning. A system can adapt formatting within defined controls without retraining its underlying model on each patient encounter. Precise descriptions are necessary before making either alarming or reassuring claims.

Tandem's Adaptive Notes announcement provides a timely example. The company describes adaptation to a clinician's editing preferences, separately for each template, while retaining draft review and an option to disable the feature. That is a specific product description, not evidence of unrestricted self-modification or improved clinical accuracy.

The unit of evaluation is the product configuration

A model benchmark can help compare components, but clinicians encounter a configured application. Its behaviour depends on sources, permissions, interface design and the circumstances in which it is used. Performance from a generic benchmark cannot be assumed to transfer unchanged.

An evaluation should therefore record the important configuration and the intended task. For a reference system, that includes the source collection and retrieval approach. For documentation, it includes the input quality, templates and review process. For a recommendation function, it includes the clinical information available and the boundaries of the output.

This does not require publishing every proprietary implementation detail. It requires enough traceability for the manufacturer, regulator and deploying organisation to understand what was evaluated and what has changed since.

Retrieval changes can matter as much as model changes

A clinical answer may change because a source was updated, a document was removed or a ranking rule began favouring a different guideline. The underlying language model can remain unchanged while the recommendation presented to the user becomes materially different.

That is why "we have not changed the model" is not a complete assurance statement. Product teams need to identify changes to the whole information pathway. Some changes will be routine and beneficial; others may require targeted regression tests or local communication.

iatroX's methodology describes a source-focused architecture, making retrieval and evidence handling relevant parts of the product discussion. The same scrutiny should apply to every supplier. A grounding system is an object of evaluation, not a permanent guarantee that all future answers will be correct.

Personalisation needs boundaries around meaning

A note that matches a clinician's style may take less effort to edit. It may also feel more familiar, which could make an error less conspicuous. The second possibility is a reason to evaluate the interface, not proof that personalisation necessarily causes harm.

A sensible test would distinguish stylistic changes from changes in clinical meaning. Shortening prose should not silently remove uncertainty. Reordering sections should not make an important warning harder to find. Adopting preferred phrasing should not convert a possibility into an established diagnosis.

These are proposed evaluation principles. They are not claims about failures observed in Tandem or any other named product. They illustrate why usability and clinical content should be assessed together when a system adapts to its user.

Proportionate change control is better than a blanket freeze

Requiring a complete assessment for every minor interface correction could discourage useful improvements. Allowing every change to proceed without meaningful review could undermine the evidence supporting the product. The challenge is to distinguish changes according to their effect and uncertainty.

A practical framework would define which changes need routine verification, which need broader performance testing and which may affect regulatory scope. It would also specify rollback procedures and the information available to deploying organisations.

The National Commission's recommendations and the government response are relevant to this evolving policy area. They should be read as a programme of reform rather than an assertion that a finished new licensing model is already available.

International recognition does not solve lifecycle oversight

The UK's CE-recognition outcome concerns a route to market. It does not make product changes unregulated or eliminate the manufacturer's continuing responsibilities. A recognised product still needs to maintain the conformity and other obligations applicable to it.

Post-market surveillance and software-related incident reporting remain important because real use can reveal issues not visible in pre-deployment testing. The quality of those processes depends on identifying the relevant version and circumstances.

A report stating that "the chatbot was wrong" may be difficult to investigate. A report preserving the product, time, input context, output and relevant configuration is more useful, subject to appropriate handling of patient information. Traceability should be designed before incidents occur.

Multifunction products add another layer

An interface may combine a non-medical administrative function with regulated clinical decision support. A change to a shared component can affect both. The product should make these boundaries understandable rather than relying on a company-level badge.

The MHRA's AVT guidance is especially relevant to distinguishing documentation-related functions from functions with a medical purpose. European qualification and classification should separately follow the applicable EU guidance.

For buyers, the useful request is a function-level account: what is included, what evidence supports it, how changes are controlled and who reviews the output. A single broad promise that a platform is "safe AI" is too imprecise for a changing product.

What clinicians should expect from a responsible supplier

A responsible supplier should be able to explain significant changes in language relevant to the clinical user. It should preserve a route for reporting concerns and avoid treating ordinary feedback as proof that safety monitoring is complete.

Clinicians do not need access to every technical detail, but they need to know when a change could affect their work. Organisations need enough information to decide whether training, local assessment or a pause is appropriate.

The objective is not to regulate software as though it never changes. It is to make change governable. The most credible clinical AI products will be those whose evidence, controls and communication evolve with the product rather than remain attached to its original launch.

Frequently asked questions

Does adaptive software always retrain itself on patient data?

No. Personalisation, configuration and model retraining are different mechanisms. The supplier should explain exactly what changes and what data is involved.

Does indefinite CE recognition allow unrestricted AI updates?

No. Recognition concerns the route to market. Maintaining conformity, controlling changes and meeting applicable surveillance obligations remain relevant.

Should every minor software update require a complete new assessment?

A proportionate approach should consider the change's effect on intended purpose, risks and performance. Minor and material changes should not automatically be treated as identical.

Understand the information pathway behind an answer

Read iatroX's methodology to see how source selection, retrieval and output design contribute to its clinical-information workflow.

More from the Journal