Changing AI medical devices: keeping assurance current

What changed

Nothing new is being announced. This is a standing explainer written from the cited official pages. Their historical publication and update dates are not evidence of a recent regulatory change. Sources checked 30 October 2026.

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

The cited MHRA pages establish three relevant guidance themes: predetermined change control plans (PCCPs), good machine learning practice (GMLP) and software-specific adverse incident reporting. They do not reproduce the underlying principles or the detailed reporting rules, and they do not grant permission to release a particular model change. The controls below are practical assurance recommendations, not a claim that every item is expressly required by these pages.

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 rapid changes in software and AI products. The GMLP page describes ten principles intended to inform the development of safe, effective, high-quality AI and machine learning devices.

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 distinguishes device-specific guidance from the underlying requirements: the guidance neither replaces nor extends them. The regulation itself is not among the cited pages, so this briefing cannot establish its commencement, detailed duties or reporting deadlines. Page publication and update dates should not be treated as legal effective dates.

Who this affects

Suppliers and manufacturers: this briefing is mainly 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.

The reporting guidance is directed at manufacturers. Where development, hosting, distribution and manufacturer responsibilities sit with different parties, a practical first step is to document who makes release decisions, evaluates safety concerns and handles reporting assessments. Do not assume a software support contract settles those responsibilities.

Deploying NHS and care organisations: an update can change the assumptions behind local use, even where the supplier retains control of the model. A technically successful installation does not, by itself, answer questions about workflow, user understanding or local monitoring. Deployers should seek enough information to assess local consequences, identify the installed version and escalate concerns. Their local safety review and the manufacturer's incident assessment are connected, but they are not the same thing.

The MHRA overview explains that many software and AI products fall within medical device or in vitro diagnostic (IVD) device regulation. It does not classify 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

Separate planned change from permission to release

The PCCP page supports planning for product changes. It does not establish that writing a plan gives a supplier permission to make any future model update, or removes the need for regulatory assessment. The page also does not reproduce the principles or explain a UK authorisation route.

As a practical control, separate three questions: was this change anticipated; does the evidence support it; and what regulatory assessment is needed before release? A plan can organise the evidence without answering all three. Where a PCCP is relied on, check its actual scope and regulatory standing separately from the engineering release decision.

For each proposed change, describe the deployed baseline, the proposed version, the reason for the change, what is expected to behave differently and what stays the same. Possible areas to review include model weights, training data, decision thresholds, preprocessing and user-facing outputs. These are review prompts, not a list taken from the guidance. Distinguish an anticipated change from one whose scope has grown during development. Otherwise the original rationale can stay attached to a materially different release.

Make evidence specific to the change

The GMLP page does not reproduce its ten principles, so it cannot support a detailed compliance checklist or a testing checklist presented as an MHRA requirement.

A useful practical response is an explicit evidence argument for each release. Identify which previous findings still apply, which assumptions need retesting and what new evidence is needed. Ask which claims are unchanged, which need fresh evidence and which can no longer be made. Explain the intended improvement, possible disadvantages, evidence examined and unresolved limitations.

Do not rely solely on an overall performance result if the change could affect particular users, settings or patient groups differently. For example, a release review could ask whether an improvement in one measured outcome shifts the balance of errors elsewhere. This is a suggested review question, not a reported product defect or an official acceptance criterion.

Define acceptance criteria before reviewing results. Record datasets, evaluation methods, limitations and unresolved concerns alongside the decision, so it is clear why the released version is supported rather than merely that testing took place. The same reasoning can inform an AI clinical safety assessment.

Plan monitoring before release, around decisions

The reporting page places software incident guidance alongside wider post-market surveillance material. The cited pages do not, however, specify monitoring measures, thresholds or review frequencies, and these should not be presented as MHRA requirements.

As an assurance recommendation, decide before deployment what each monitoring activity is meant to answer. Is the deployed version performing as expected? Are inputs or operating conditions different from those evaluated? Are users encountering outputs they cannot interpret or act on safely? Consider measures related to the clinical claims being supported, alongside complaints and operational feedback. Record collection limitations too: the absence of a signal tells you less where relevant outcomes cannot be observed.

Give each signal an owner and a defined response. Consider what would trigger investigation, more testing, restricted use or an assessment of whether rollback is appropriate. These are options to plan, not automatic remedies or regulatory instructions. Link observations to the relevant model version, software configuration and deployment context wherever practicable. Otherwise reassuring results from one configuration may be wrongly used to support another, or a pre-existing issue confused with a change-related signal.

Keep incident assessment distinct from defect handling

The software reporting guidance "outlines events that may cause indirect harm and are therefore reportable", and should be read with the post-market surveillance guidance. That is a reason not to limit internal escalation to crashes, outages or other obvious technical failures. It is not enough information to decide whether an individual event meets the applicable reporting criteria, and the cited page gives no detailed event examples or decision criteria.

As a recommended control, connect customer support and engineering records to a separate incident-assessment process. Record the reported behaviour, affected versions, known circumstances, possible consequences, remaining information gaps and the person responsible for the reporting assessment under the applicable rules.

A successful patch does not answer whether an event needs reporting: fixing behaviour and deciding reporting obligations are different questions. Equally, do not treat every inaccurate output, complaint or performance fluctuation as automatically reportable. Thresholds and timescales must be checked against the full applicable material; do not infer a deadline from these pages.

What remains uncertain

The cited pages are publication landing pages, not the full linked guidance documents. They do not reveal the five PCCP principles, the ten GMLP principles, detailed validation expectations, reporting channels or deadlines, event categories, or the circumstances in which a change needs further regulatory action. They also do not establish a product's classification, applicable conformity assessment steps or geographic distinctions.

Joint authorship of the PCCP principles does not establish that PCCPs have an identical legal effect, or that regulatory treatment is interchangeable, across the UK, United States and Canada.

For an individual release, further uncertainty may concern data quality, how representative the evaluation evidence is, access to deployment information and responsibilities between organisations. The historical page updates also cannot show whether other relevant material existed on the retrieval date; this explainer describes the cited evidence, not an exhaustive regulatory search. A supplier therefore cannot use this briefing alone to settle a release or reporting decision. Record open questions explicitly with an owner, rather than silently turning an assumption into an approval criterion.

Documents and controls to review

These are recommended evidence-review activities, not an official document list or additional statutory duties inferred from the MHRA pages.

• Change record and release decision, with an evidence index: the baseline and proposed version, scope, rationale, evidence considered, outstanding limitations and decision owner. Where a PCCP is used, show how the change relates to it without presenting the plan as automatic regulatory permission.
• Evaluation and monitoring plans, reviewed as a pair: pre-release testing should explain what is supported before deployment; monitoring should explain what still needs watching afterwards. Record gaps where deployment information cannot be obtained.
• Hazard record and [clinical safety case](/clinical-safety-case): check whether existing hazards, controls and residual-risk arguments still describe the changed product, version and conditions of use. The aim is a coherent evidence trail, not just a newly dated document.
• Complaint handling, incident assessment and deployer communications: check that a concern can move from customer support to the responsible safety and regulatory reviewers without being lost in an engineering backlog. Release communications should help deployers understand changed behaviour, relevant limitations, any corrective action and the escalation route.

Where relevant to an NHS-facing assurance workstream, connect change evidence to the supplier's DCB0129 clinical safety work and to the information the deploying organisation needs for its DCB0160 review. These are related review areas, not additional duties established by the MHRA pages. Supporting material should be prepared for the client's own appointed Clinical Safety Officer, whose role should remain clear.

Next-step checklist

• Define the deployed baseline, the proposed change boundary and every affected version and configuration.
• Separate planned-change coverage, evidence sufficiency and regulatory assessment; verify the scope and standing of any PCCP relied on.
• Identify the clinical claims and assumptions requiring review, set acceptance criteria and record which earlier evidence still applies.
• Assign monitoring owners, review points and escalation criteria.
• Route potential indirect harm into a documented reporting assessment, checked against the full applicable rules.
• Update safety evidence and communicate deployment-relevant changes to deploying organisations.
• Obtain the full guidance and applicable regulatory text before relying on detailed requirements.

For help preparing change-related clinical safety evidence for your own appointed Clinical Safety Officer, contact Assurance AI.

Primary sources

1. Predetermined change control plans for machine learning-enabled medical devices: guiding principles — MHRA, GOV.UK, 24 October 2023. https://gov.uk/government/publications/predetermined-change-control-plans-for-machine-learning-enabled-medical-devices-guiding-principles
2. Good machine learning practice for medical device development: guiding principles — MHRA, GOV.UK, 27 October 2021 (last updated 5 October 2026; that update changed only an MHRA contact email). https://gov.uk/government/publications/good-machine-learning-practice-for-medical-device-development-guiding-principles
3. Reporting adverse incidents involving software as a medical device under the vigilance system — MHRA, GOV.UK, 15 May 2023 (last updated 15 January 2025). https://gov.uk/government/publications/reporting-adverse-incidents-involving-software-as-a-medical-device-under-the-vigilance-system
4. Medical devices: software and artificial intelligence (AI) — MHRA, GOV.UK, 6 April 2023 (updated 3 February 2025). https://gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device