.png){kind=logo}
On September 10, 2026 the UK's National Commission into the Regulation of AI in Healthcare published Recommendations for a future regulatory framework. The Commission was established by the MHRA in September 2025 as an independent advisory body, chaired by Professor Alastair Denniston (ophthalmologist and regulatory science lead at CERSI-AI) and Professor Henrietta Hughes (GP and Patient Safety Commissioner for England), with commissioners drawn from the NHS, UK academia, the Coalition for Health AI, Singapore's Health Sciences Authority, and US health systems. It gathered evidence from more than 12,000 people over a year, making it the largest engagement of its kind ever run in the UK on the regulation of healthcare technology.
The report matters for any company building software or AI-enabled medical devices for the UK market, and it matters beyond the UK because it lands on the same conclusions FDA and IMDRF have been converging on: point-in-time approval is the wrong model for products that iterate, drift, and depend on the environment they are deployed in. Below is what the report says and what it means for developers.
The core idea: proportionate, lifecycle-based, system-wide
The Commission's central conclusion is that current UK medical device regulation, designed for static products assessed once before market, is not fit for purpose for software and AI-enabled devices. It is heavily weighted toward pre-market assurance, which does not predict real-world performance well for these products, and it was not designed to accommodate frequent updates. The report proposes a framework it describes as "safe, fast and trusted", organised around three principles: proportionate lifecycle regulation, system-wide responsibility and safe management, and trust, transparency and predictability.
The report is explicit that it is setting direction ("what" and "how") and leaving the detailed policy design to the MHRA, DHSC, and the devolved health departments. A cross-government response will follow separately. So nothing below is law yet. But the Commission was sponsored by the MHRA, and the MHRA has already told the Commission it intends to explore directly licensing devices rather than relying solely on Approved Bodies, so the trajectory is credible.
What the Commission recommends
Chapter 1 carries most of the weight for manufacturers, with recommendations covering qualification and classification, tailored oversight, routes to market, post-market assurance, and enforcement.
Qualification and classification (Recommendations 1 and 2)
The MHRA should update the UK Medical Devices Regulations 2002 to clarify when administrative, general wellbeing, and low-risk clinical decision support software is not a medical device; replace the current classification approach, under which most software is self-declared Class I, with one that considers clinical risk, patient benefit, lifecycle, and international harmonisation; and update the definition of intended purpose so that device design and functionality count alongside the manufacturer's claims and promotional materials. Guidance with practical examples should follow, with an ongoing process for keeping it current.
Tailored and function-based oversight (Recommendations 3 to 5)
The MHRA should be empowered to add or reduce requirements for device types as evidence accumulates, including enforcement discretion for low-risk products. Oversight of multifunction products (an ambient voice tool with both transcription and decision-support functions, or a general-purpose LLM with one medical feature) should focus on the medical device function only, not the whole product. And the evidentiary balance should shift toward the post-market phase, with the MHRA setting out what pre-market evidence is sufficient for an adaptive device given the real-world monitoring that will follow.
PCCPs, Master Files, and foundation-model dependencies (Recommendations 6 to 8)
This is the section US-facing developers will recognise immediately. The Commission wants PCCPs to move from enumerated, prespecified changes toward boundaries and guardrails that define the allowable scope of change, and to explicitly support site- or subpopulation-specific tuning, broad or goal-defined intended purposes (the report names regulated AI agents), and evidence-driven use expansion that does not alter intended purpose. It cites the MHRA's AI Airlock finding that the significance of a change depends on clinical function, autonomy, deployment environment, and degree of human oversight, not just the technical modification.
Two new mechanisms sit alongside PCCPs. An opt-in Master File for general-purpose platforms and foundation models, modelled on FDA, Health Canada, and PMDA master file systems, would let upstream developers share benchmarks, model cards, and guardrail information confidentially with the regulator so downstream device manufacturers can complete submissions. And manufacturers should be expected to report any dependency on a general-purpose model, with related risks, mitigations, and continuity plans, both in regulatory submissions and in procurement contracts. The report flags the system-level concentration risk of many devices depending on a small number of externally owned models.
Transparency, cybersecurity, DTC, usability, and equity (Recommendations 9 to 13)
The MHRA should issue guidance on model cards, user-centred interface design, and dynamic labelling; on cybersecurity expectations across the lifecycle (the report names data poisoning and malware as AI-specific threats); on direct-to-consumer apps and wearables; on human factors and usability for AI devices; and on health equity, including ongoing subgroup monitoring. The public engagement produced a clear red line that AI should never lead to a worse outcome for any population group, and the report treats equity as a safety and performance issue rather than an ethics add-on.
Staged authorisation, sandboxes, and reliance (Recommendations 14 to 16)
The headline recommendation is a staged authorisation pathway. A device with an emerging use case could be deployed within a tightly controlled scope, at healthcare providers that can demonstrate AI readiness, based on MHRA review of initial evidence plus agreed risk controls and reporting. Authorisation expands once prespecified real-world performance and safety thresholds are met. The Commission sets conditions: the pathway must be tailored to technical maturity and clinical need, transparently reported to patients, temporary by design, and connected to a clearly defined path to full authorisation. The MHRA is asked to coordinate with NICE and the National Healthtech Access Programme so external stakeholders see one coherent route.
Regulatory sandboxes (AI Airlock, the London and Manchester real-world sandboxes) should be extended to test new regulatory mechanisms with a clear path to authorisation. And the MHRA should introduce recognition or reliance pathways for software and AI devices authorised by trusted international regulators, with review points and break clauses.
Post-market assurance and enforcement (Recommendations 17 to 19 and beyond)
Building on the June 2025 GB Post Market Surveillance Regulations, the Commission proposes a menu of mechanisms the MHRA may require: PMS and real-world data collection plans assessed at the time of authorisation, real-world post-market studies where residual uncertainty remains, regular performance reporting made available to regulators and, where appropriate, the public, and defined escalation processes when performance degradation is detected even if no reportable incident has occurred. Reporting routes should be refined for AI devices (the report floats a Yellow Card button designed into the user interface), and the MHRA should build a public, searchable adverse-incident tool for software and AI devices comparable to FDA's MAUDE database. The report also calls for stronger MHRA enforcement powers.
Chapters 2 and 3 address the wider system: clear roles and liability arrangements across manufacturers, providers, and professionals; an AI readiness toolkit for healthcare organisations; workforce AI literacy; procurement and deployment best practice; a proportionate approach to telling patients when AI is used in their care; patient and public involvement in policymaking; and predictable early-engagement mechanisms with the regulator to make the regulatory journey easier to navigate.
What this means for developers
Plan for staged market entry. If the staged authorisation pathway is implemented, the fastest UK route for a novel AI device will likely run through controlled deployment with AI-ready NHS partners, under a PMS plan that the MHRA reviews at authorisation. Start identifying deployment partners and designing the real-world evidence plan now; it will be part of the submission, not an afterthought.
Design your PCCP as boundaries, not a list. The Commission's direction on PCCPs (guardrails, site tuning, use expansion, agentic intended purposes) is more permissive than the current FDA PCCP guidance, but both regulators are moving the same way. A change-control architecture built around performance envelopes, prespecified test methods, and monitoring thresholds will be portable across jurisdictions.
Document your foundation-model dependencies now. Reporting of provenance, risks, mitigations, and continuity plans for underlying general-purpose models is proposed as a submission expectation and a procurement expectation. If your product is built on a third-party model, your design history file and your supplier controls should already answer these questions.
Treat post-market performance monitoring as a product feature. Logging to detect drift, prespecified degradation thresholds, subgroup performance tracking, and embedded feedback and incident reporting are all named in the report. They will be easier to build into the product than to retrofit for a regulator.
Revisit your intended purpose statement and classification. If the definition of intended purpose is expanded to include design and functionality, and if self-declared Class I is curtailed for software, broad or loosely worded intended-purpose statements will draw more scrutiny, not less. A precise, evidence-backed intended purpose remains the anchor for everything else.
Watch the reliance pathway. For companies with FDA clearance or a CE mark, an MHRA reliance route for software and AI devices would materially change the UK entry calculus. The Commission recommends it; the MHRA's earlier consultation showed majority support; the policy detail is still to come.
Caveats
These are recommendations to government from an advisory body. Many are phrased as "the MHRA should consider", the report deliberately stops short of policy design, and legislative change to the UK MDR 2002 takes time. The Commission itself notes that the MHRA will need to be resourced to deliver. Northern Ireland remains under EU MDR via the Windsor Framework, so any divergence in Great Britain qualification or classification rules creates a two-track problem the report acknowledges but does not resolve. And the staged authorisation pathway depends on healthcare providers being ready to host controlled deployments, which the Health Foundation's own commentary flags as the real test.
The bigger picture
This report is the strategic layer on top of the MHRA's 2026 reform programme, which we covered in The UK's Regulatory Reset: What MHRA's 2026 Reforms Mean for Medtech. Read together with the recent FDA and MHRA collaboration announcement and the IMDRF work on PCCP essential principles, it describes a regulatory world in which pre-market clearance is the beginning of the evidence obligation rather than the end of it. For background on how the US version of change control works today, see our post on what an FDA PCCP is and how to create one.
The full report is available in the Cosm resources library, and the easy-read version and Welsh executive summary are on GOV.UK.
How Cosm Can Help
Cosm advises developers of AI/ML-enabled medical devices and SaMD on regulatory strategy in the US, EU, and UK, including intended purpose and classification, PCCP design, real-world evidence and post-market surveillance planning, cybersecurity documentation, and pre-submission engagement with regulators. If you are assessing how a staged UK pathway, a reliance route, or a boundary-based PCCP would fit your product roadmap, contact us or visit cosmhq.com.
Disclaimer - https://www.cosmhq.com/disclaimer
