Britain wants lifecycle rules for AI medical devices. Patients need the change log

THE SIGNAL IN ONE SENTENCE

A medical device is approved. Then the software changes. Maybe a hospital installs a new model version. Maybe the developer adjusts a threshold. Maybe the device begins seeing patients from a population that was thinly represented in the original evidence. The product name stays the same, but the thing helping to shape care is no longer quite the thing that was first reviewed. If that system helps triage a scan or flags a patient at risk, the update should not be a mystery hiding behind a generic notification. Britain's Medicines and Healthcare products Regulatory Agency, or MHRA, has now put this moving-target problem near the center of its AI agenda. In a release published October 19, the regulator said it is developing a more flexible, lifecycle-based approach for software and AI-enabled medical devices. The plan includes regulatory sandboxes, better device data and traceability, a new Centre for AI and Digital Health, and closer work with regulators including the US Food and Drug Administration. The plain signal is this: lifecycle regulation needs a patient-readable change log. Not a marketing page. Not a 90-page technical dossier. A durable public record that connects each deployed version to the evidence, affected patients, safety signals, regulator decisions and rollback conditions. The MHRA's announcement is an agenda, not a finished rulebook. Its 2030 Strategy sets the direction: build an adaptive framework for AI as a medical device, improve identification and traceability across a device's life, use real-world data to identify safety problems sooner, simplify adverse-event reporting and expand international reliance routes. That direction makes sense because medical AI does not stop changing when a certificate is issued. Some systems may receive deliberate software updates. Others can behave differently because the surrounding world changed: a new scanner entered the hospital, a lab altered its workflow, clinical practice shifted, or the mix of patients moved away from the data used in development. Even a frozen model can produce a new risk profile when its context changes. Traditional regulation often imagines a product with a stable design that can be tested, approved and monitored. Software turns that line into a loop. AI makes the loop harder to see. The patient-facing answer should start with identity. Every hospital deployment should expose the product name, developer, intended use, current software and model version, installation date and clinical setting. A patient should be able to ask which version contributed to a decision about their care and receive an answer that survives vendor changes and hospital procurement cycles. Then comes the actual change. The log should say whether the developer changed the model, training data, decision threshold, user interface, supported hardware, intended population or workflow. It should explain why. It should name the sites and patient groups most likely to feel the effect. If performance was re-evaluated, it should show results by clinically meaningful groups instead of burying them in one average. Next comes authority. Was the update reviewed by the MHRA? Was it allowed under an agreed change plan? Did the regulator rely on evidence from another trusted authority? Was the change limited to a sandbox or released across the NHS? Which independent body made the final decision? The MHRA says its work with the FDA will include scientific exchange and coordination, while both agencies retain independent regulatory decisions. That distinction belongs in the public record. International reliance can reduce duplicate work, but patients should still be able to see what evidence the UK considered and what UK-specific conditions were applied. Finally comes the exit. Every change log should list the signals that would trigger extra review, suspension or rollback. It should name the previous safe version, if one exists, and explain how clinicians and patients can report a suspected problem. A rollback plan that lives only in a vendor's incident binder is not much comfort during an actual incident. This is not speculative paperwork for its own sake. The MHRA's strategy promises more precise device identification, better traceability and simpler Yellow Card reporting for adverse events. A public change log would connect those pieces. Imagine a radiology triage tool that receives a threshold adjustment. The log could show that the change aims to reduce missed urgent cases, identify which scans were used for validation, report how sensitivity and false alerts shifted, note any groups with limited evidence, name the approving pathway and list the hospital contacts responsible for monitoring. Or consider an AI-enabled tool that identifies people at higher risk of complications from a long-term condition. The MHRA says systems of that kind are expected among the first technologies considered by the Manchester health innovation sandbox. A useful public record would show that the deployment remains an evidence-generating test, not a proven nationwide standard. That sandbox matters, but the word can make uncertainty sound friendlier than it is. The Manchester partnership between the MHRA and Manchester University NHS Foundation Trust is designed to test technologies in real NHS settings with oversight and guardrails. The regulator says the programme will gather evidence on safety, effectiveness and impact, and help determine what developers need for wider NHS use. That is a testing arrangement. It is not evidence that every system inside the sandbox works, improves outcomes or deserves broader adoption. The same is true of the regulator's AI Airlock programme. A sandbox can reveal where old rules fit badly, surface operational hazards and let regulators observe products earlier. It can also become a soft-launch lane if entry, incidents and exit criteria are opaque. Publish the sandbox receipt. Name the product and intended use. Name the hospitals involved. Explain what evidence is being gathered, what guardrails apply and which patients are included or excluded. Report serious incidents and material protocol changes promptly. When the test ends, publish the decision and the reason, including a decision not to proceed. Patients also need an honest account of what the change log cannot do. A clean version history does not prove a device is safe. Developers can choose flattering metrics. Hospitals can install software incorrectly. Small groups can disappear inside sparse data. A model can perform well in a study and poorly during a winter surge. An incident log can miss harms that nobody recognized or reported. The record therefore needs independent checks, links to underlying evidence and room for uncertainty. It should disclose missing demographic data, sites where results did not transfer and unresolved disagreements among reviewers. It should distinguish a regulator's decision from a developer's claim. Privacy needs equal care. A public log should describe affected populations and incidents without exposing individual health records. More traceability does not justify building a new public trail back to a named patient. Accessibility matters too. The technical record can remain detailed, but the top layer should be readable on a phone, available in accessible formats and explain the consequence of a change in ordinary language. A version number without meaning is traceability theatre. For clinicians, the change log becomes a handover tool. It says what changed between last month's recommendation and today's. It shows whether an alert threshold moved, whether the evidence now covers the local population and when human review is mandatory. For procurement teams, it becomes a contract. Vendors can be required to notify hospitals before material updates, preserve old versions, support rollback and deliver the evidence fields needed for public reporting. For developers, a standard format could reduce the current thicket of bespoke explanations. If every update uses the same identity, evidence, population, incident and rollback fields, teams know what proof they need to collect before shipping. For regulators, it turns the phrase lifecycle oversight into something the public can inspect. The MHRA's plan reaches to 2030. It includes a new center, new data connections, real-world surveillance, regional testing and closer coordination abroad. Those are institutional moves. The patient experience will be much smaller and more immediate. Which system touched my care? Which version was it? What changed? Who checked it? What happens if it goes wrong? If lifecycle regulation cannot answer those five questions, the lifecycle is still mostly visible to the people selling and regulating the device. Britain has identified the right problem. Now it needs to make the update history part of the medical record, the device record and the public record. Patients should not have to reverse-engineer the machine that helped judge them.