Changing an AI medical device: keeping assurance current

What changed

Nothing new is being announced here. This is a standing explainer written from the cited official pages as they stood in the supplied retrieval snapshot for 21 September 2026. Their historical publication and update dates are not evidence of a recent regulatory change.

For an AI medical device supplier, the practical question is how to keep the justification for using a product aligned with the version actually deployed. A change plan, development evidence and incident handling need to connect, rather than sit in separate folders.

The supplied pages establish three relevant guidance themes: predetermined change control plans, good machine learning practice and software-specific adverse incident reporting. They do not provide the underlying principles or detailed reporting rules. The controls below are therefore practical assurance recommendations, not a claim that these landing pages prescribe a complete release process.

Status and dates

All four cited pages are labelled guidance. None is itself legislation or a statutory standard.

The PCCP page describes five principles jointly identified by the MHRA, FDA and Health Canada for managing product changes. The GMLP page describes ten principles intended to inform development practice.

The software incident reporting page says its guidance complements SI 2024 No. 1368 and should be read alongside that regulation and general post-market surveillance guidance. It expressly distinguishes device-specific guidance from the underlying requirements: the guidance neither substitutes for nor enlarges them. The supplied extract does not establish the regulation’s commencement date or detailed duties, so publication dates must not be treated as legal effective dates.

Who this affects

Suppliers: This briefing is primarily for manufacturers of AI-enabled medical devices and teams preparing model or software changes. Regulatory, engineering, quality and clinical safety colleagues need a shared account of what is changing and which existing evidence remains relevant. A release record that describes code changes alone may leave the clinical significance unexplained.

Deploying organisations: NHS and care organisations need to understand whether a supplier’s update changes the assumptions supporting local use. A technically successful installation does not, by itself, answer questions about workflow, user understanding or local monitoring. Recommended deployment review should therefore address the change’s practical consequences, not merely confirm receipt of a release note.

The MHRA overview explains that many software and AI products fall within medical device or IVD regulation. It does not establish the classification or regulatory route of any particular product. This briefing assumes the reader has already identified their product as an AI-enabled medical device; it does not determine that status.

What this means in practice

Make the change boundary explicit

The PCCP landing page supports the idea of planning for product changes. It does not establish that writing a plan gives a supplier permission to implement any future model update, or removes the need for regulatory assessment.

A useful internal change description would identify the deployed baseline, the proposed version, the reason for changing it and the aspects of product behaviour expected to differ. Distinguish an anticipated change from one whose scope has expanded during development. Otherwise, the original rationale can remain attached to a materially different release.

For assurance purposes, ask which claims are unchanged, which need fresh evidence and which can no longer be made. Treat the answers as review inputs, not as an automatic conclusion that a change is acceptable. Where a PCCP is being relied upon, verify its actual scope and regulatory standing separately from the engineering release decision.

Connect development evidence to use

The GMLP page identifies a development framework but does not reproduce its ten principles. It would therefore be inappropriate to present a detailed testing checklist as an MHRA requirement derived from this extract.

As a practical control, assemble a proportionate comparison between the existing and proposed versions. Explain the intended improvement, possible disadvantages, evidence examined and unresolved limitations. An aggregate performance result may be useful, but reviewers also need a reasoned account of its relevance to the product’s intended clinical use.

For example, a hypothetical release review could ask whether an improvement in one measured outcome changes the balance of errors elsewhere. This is a suggested review question, not a reported product defect or an official acceptance criterion. The aim is to make the decision traceable rather than reduce it to a single score.

Plan monitoring before release

The reporting page places software-specific incident guidance alongside wider post-market surveillance material. However, the extracts do not specify monitoring measures, review intervals or action thresholds.

A recommended operational approach is to decide before deployment what information will be collected, who will review it and what findings will prompt investigation. Record the released version against monitoring information wherever practicable. Without that connection, a team may struggle to distinguish a pre-existing issue from a change-associated signal.

Consider measures related to the clinical claims being supported, alongside complaints and operational feedback. Also record collection limitations: absence of a signal is less informative where relevant outcomes are not observable. Monitoring should help test whether the release rationale continues to hold, rather than simply demonstrate that a dashboard exists.

Keep incident assessment distinct from defect handling

The software reporting page specifically addresses events involving potential indirect harm that can be reportable. That is a reason not to restrict internal escalation to obvious technical failures. It is not enough information to decide whether an individual event meets the applicable reporting criteria.

As a recommended control, connect customer support and engineering records to a separate incident-assessment process. Preserve the reported behaviour, affected version, known circumstances, possible consequences and remaining information gaps. Give someone clear responsibility for obtaining a reporting assessment under the applicable rules.

Do not use a successful patch as a substitute for that assessment. Resolving behaviour and determining reporting obligations are different questions. Conversely, avoid treating every anomaly as automatically reportable: thresholds and timelines need verification against the full applicable material, which is not supplied here.

What remains uncertain

These extracts are publication landing pages, not the full linked guidance documents. They do not reveal the five PCCP principles or ten GMLP principles, detailed validation expectations, reporting deadlines, event categories or the circumstances in which a change requires further regulatory action.

Nor do they establish that PCCPs have an identical legal effect across the UK, United States and Canada. Joint authorship of guiding principles is not evidence of interchangeable regulatory permissions.

A supplier consequently cannot use this briefing alone to settle a release or reporting decision. The useful distinction is between evidence that can be prepared now and regulatory questions that still require verification. Record those questions explicitly, assign an owner and avoid silently converting an assumption into an approval criterion.

The supplied historical page updates also cannot establish whether other relevant material existed on the retrieval date. This explainer describes the supplied evidence, not an exhaustive regulatory search.

Documents and controls to review

Start with the change record and its supporting evidence index. Together, these should make it straightforward to locate the baseline, proposed change, assessment rationale, testing evidence, limitations and decision record. This is a recommended evidence structure, not an official document list extracted from the cited pages.

Review the monitoring plan and incident-handling procedure together. Check that observations can reach the people assessing clinical significance and reportability, rather than remaining isolated in service tickets. Include arrangements for communicating material findings to deploying organisations and for considering corrective action.

Where relevant to an NHS-facing assurance workstream, connect the change evidence to the supplier’s DCB0129 clinical safety work and information needed for the deploying organisation’s DCB0160 review. These are related review areas, not additional duties established by the MHRA extracts supplied here.

Keep the clinical safety case aligned with the version and conditions of use it actually supports. A useful review asks whether existing hazards, controls and residual-risk arguments still describe the changed product. The objective is a coherent evidence trail, not simply a newly dated document.

For support preparing change evidence for your own appointed Clinical Safety Officer, contact Assurance AI.

Next-step checklist

• Define the deployed baseline and proposed change boundary.
• Identify the clinical claims and assumptions requiring review.
• Verify the regulatory standing and scope of any PCCP relied upon.
• Assemble comparative evidence and record unresolved limitations.
• Assign monitoring owners, review points and escalation criteria.
• Check incident-assessment criteria against the full applicable rules.
• Update safety evidence and communicate deployment-relevant changes.