Summary
In September 2026, the National Commission into the Regulation of AI in Healthcare published its recommendations to the Medicines and Healthcare products Regulatory Agency (MHRA) for a future regulatory framework. The report contains around 44 recommendations, including staged authorisations, a rebalancing of evidence towards the post-market phase and financial penalties for manufacturers who put patients at risk.
In this blog, Clive Flashman, Patient Safety Learning's Chief Digital Officer, shares his personal reflections on this. He sets out the five recommendations he most strongly supports, and five gaps that need addressing before the cross-government response is published. One of the key gaps is that the Learn from Patient Safety Events (LFPSE) service does not appear anywhere in the report's 119 pages.
Content
Why this report matters
The Commission was established by the MHRA in September 2025 and has now reported.[1] Its central conclusion is one I agree with: the regulation and assurance of AI in healthcare needs to be proportionate, lifecycle-based and system-wide. It draws on a substantial engagement programme, including a call for evidence, public deliberation events and engagement with seldom-heard groups.
The Commission's vision is a framework that is "safe, fast and trusted". That is the right ambition, and there is a lot in the report that would move us towards it. There is also, from a patient safety perspective, several unanswered questions and a lack of joined-up thinking.
Five recommendations I strongly support
Intended purpose grounded in design and function (Recommendations 1 and 4). Defining a product's intended purpose by what it actually does, rather than only by what the manufacturer claims it does in its promotional material, closes the most exploited gap in the current framework. Combined with a function-based approach to regulation, it stops vendors from labelling their product as "administrative" or "wellbeing" software and therefore out of scope. Anyone who has sat through a health tech pitch will know why this matters.
Rebalancing evidentiary weight towards the post-market phase (Recommendation 5). This is at the core of the report. Single-timepoint approval was always a poor fit for a technology that changes after deployment and performs differently in different settings. Shifting the burden of proof towards real-world performance accepts that safety is demonstrated in use, not at authorisation. Staged authorisation (Recommendation 14) is the practical expression of the same idea.
Post-market surveillance with escalation before harm (Recommendation 17). A one-size-fits-all approach to surveillance was never going to work. What matters most here is the requirement for established processes to escalate when performance degrades, even where no reportable incident has occurred.
Traceability in the patient record, with automated reporting (Recommendations 20 and 21). Without product identity and version recorded in the patient record, you cannot go back and identify which patients were exposed to a failing AI model. The report suggests exploring a unique device identifier for exactly this purpose. Pair that with automating low-burden reporting and you remove the main practical excuse for not reporting, which is that it costs clinical time that the system does not have.
Enhanced enforcement, including financial penalties (Recommendation 22). There needs to be consequences for manufacturers who fail to comply and place patients at risk; the framework mainly relies on goodwill, and goodwill has never been a safety control.
I would perhaps add Recommendation 28 to this list too. Requiring the contract between manufacturer and provider to allocate responsibility explicitly for delivering risk controls follows directly from a principle the report states well: risk should sit with whoever is actually able to manage it, and clinicians should not be asked to carry accountability for risks they cannot plausibly mitigate. Procurement contracts remain the one regulatory tool a provider organisation fully controls.
Five gaps
LFPSE does not appear in the report. The Yellow Card scheme is mentioned around a dozen times. LFPSE is not mentioned at all. Neither are the Patient Safety Incident Response Framework (PSIRF) or the Health Services Safety Investigations Body (HSSIB). That matters, because Yellow Card is a drug and device vigilance route designed for manufacturers and for people who recognise that a product has malfunctioned. AI-related harm is rarely obvious or does not directly impact the patient. It surfaces as a clinical incident, recorded locally by a nurse or a doctor who in their career might never have submitted a Yellow Card. The report suggests designing a Yellow Card button into the device interface, which is a good idea. My suggestion is simple: add an LFPSE route alongside it or, better still, have one report populate both. One action from the clinician, two systems learning.
Existing clinical safety infrastructure is not mentioned. DCB0129 (the NHS clinical risk management standard for manufacturers/developers of health IT systems) appears nowhere in the report. DCB0160 (the corresponding NHS standard for health and care organisations deploying and using health IT systems) appears only once, in a footnote. Clinical safety officers (CSOs) are not mentioned at all. Yet Recommendations 29 to 31 propose building a new 'AI readiness' toolbox covering decision-making readiness and implementation readiness. The CSO workforce should be extended, trained and funded to apply these recommendations.
The Master File is voluntary. The report proposes an opt-in 'Master File' approach for general-purpose models, building on work by the US Food and Drug Administration (FDA), Health Canada and Japan's Pharmaceuticals and Medical Devices Agency (PMDA). It is a sensible mechanism. Many AI-based tools have a huge dependency on foundation models built by a small number of very large companies and the only tool proposed for it is optional. If the MHRA, FDA, Health Canada and the PMDA jointly required these files, disclosure could become a condition of market access. Acting alone, the UK gets what vendors choose to share.
There is no resourcing model anywhere. The report suggests a centralised, vendor-independent, head-to-head testing function for the NHS. I like that idea very much. But nobody is named to pay for it. The same applies to provider-side post-market surveillance to record the product version in the patient record, and to CSO capacity. Unfunded safety obligations will have to be absorbed by clinical teams already at capacity... and then quietly dropped.
Equity is named as fundamental to safety, then left as guidance. The report is clear that unequal performance is a safety failure, and that public consultation participants drew a firm line at any population group receiving worse outcomes. Recommendation 13 responds with voluntary guidance for manufacturers. There is no mandatory requirement for subgroup performance reporting after deployment.
Conclusion
This is a better report than I expected. It accepts that AI cannot be regulated as if it stops changing on the day it is approved, and it is honest about the limits of a single point-in-time assessment. Staged authorisation (and deployment), traceability, escalation before harm and real enforcement powers would together represent a substantial improvement on where we are now.
But a framework built on real-world evidence needs the routes through which real-world evidence actually arrives. For AI, most of that post-market evidence will come from frontline staff describing something that has gone wrong through the systems they already use. Right now the report does not mention those systems at all.
A cross-government response is still to come, I look forward to reading it when it arrives
References
Further reading on the hub:
About the author
Clive Flashman is Patient Safety Learning's Chief Digital Officer.
Recommended Comments
Create an account or sign in to comment