The 44-Point Plan: How the UK is Rewriting the Rules for Healthcare AI

Sam: The UK government is officially accepting all 44 recommendations for regulating AI in healthcare, marking a complete overhaul of how medical algorithms will be approved, monitored, and trusted in the real world.

Maya: Today we are analyzing the Government Response to the National Commission's recommendations, a major policy document published by the Medicines and Healthcare products Regulatory Agency on Tuesday 6th October 2026.

Sam: Before we get started, we want to remind you that our voices are AI-generated, and this episode is a Smart Summary of a publicly available document.

Maya: This response is a big deal, Sam. The government explicitly states that the current rules, specifically the UK Medical Devices Regulations 2002, are simply not fit for purpose when it comes to the pace and nature of artificial intelligence.

Sam: Which makes total sense. Back in 2002, the idea of an adaptive, learning algorithm diagnosing a stroke in real time sounded like science fiction. Now, the government is framing this as a critical piece of the 10 Year Health Plan for England.

Maya: Exactly. And there is serious financial backing mentioned right at the start. The government has committed major funding to invest in technology, digital, and data initiatives.

Sam: Wait, that much funding? That is a massive signal to the market. They say they want the NHS to become the most AI-enabled healthcare system in the world. But you cannot scale at that level without clear rules.

Maya: Right, which is why they are accepting all 44 of the Commission's recommendations. They break their action plan down into several main themes. The first is proportionate lifecycle regulation. The second is system-wide responsibility and safe management. And the third is trust, transparency and predictability.

Sam: Let us start with that first theme, lifecycle regulation. For developers listening, this feels like the biggest shift in how they will actually build and release products. What does proportionate lifecycle regulation actually mean in practice?

Maya: It means moving away from point-in-time, pre-market assessments. The document notes that traditional regulation focuses heavily on getting the product approved once. But AI changes. So they want less reliance on those static pre-market checks and a conscious shift towards robust, ongoing post-market assurance.

Sam: So if I am a medical device manufacturer, I do not just pass a test and walk away. I have to prove it keeps working safely over time. How are they planning to manage those continuous changes? If the model learns, does it need a new approval every week?

Maya: This is where recommendation 6 comes in. The MHRA is going to issue draft guidance by December 2026 on Predetermined Change Control Plans, or PCCPs. This allows manufacturers to establish boundaries to define the scope of allowable change, rather than just prespecifying specific modifications.

Sam: That is fascinating. So instead of saying exactly how the algorithm will change, the developer draws a box and says, as long as the AI stays within these boundaries and maintains its intended use, we are good.

Maya: Exactly. They specifically note this is for adaptive AI-enabled medical devices, and it could allow for things like site or sub-population specific tuning. So a model could theoretically adjust to the specific demographic of a local hospital without breaking its regulatory approval.

Sam: That is huge for hospital deployments. But what happens before a product even gets to that stage? Does the document change what is actually considered a medical device in the first place?

Maya: Yes, recommendation 1 targets this directly. The MHRA plans to use secondary legislation to introduce an updated definition of a medical device. They want to provide clarity on when certain software and AI-enabled products are not classed as medical devices.

Sam: Give me an example. What would not be a medical device under these new rules?

Maya: The document lists certain administrative software, general wellbeing apps, and certain decision support software as carve-outs. If your tool is just helping schedule patients, it shouldn't be regulated like a stroke imaging algorithm.

Sam: Which makes total sense. But what if a product does a bit of both? What if an electronic health record system has a scheduling tool, but also has a clinical diagnostic AI built into it?

Maya: That is addressed in recommendation 4. The MHRA is exploring options for a function-based approach to regulation. That means focusing regulatory oversight on the functionality with a medical intended purpose, rather than getting bogged down by the non-medical functionalities present in the same product.

Sam: Okay, that is a huge relief for big enterprise tech companies. They won't have their entire platform regulated as a medical device just because they added a single clinical AI feature.

Maya: Right, but on the flip side, the MHRA is tightening expectations around foundational technology. Recommendation 7 explores establishing an opt-in Master File approach for general-purpose models or platforms used by medical device developers.

Sam: A Master File? How would that work?

Maya: It means the builders of general-purpose AI models would provide proportionate information like benchmarks, model cards, and internal guardrails. Device developers who build on top of those foundation models could reference this Master File to support their own regulatory submissions.

Sam: I see, so if a startup builds a diagnostic tool on top of a massive open-source or proprietary large language model, the startup doesn't have to re-prove the safety of the base model from scratch, assuming a Master File exists.

Maya: Exactly. And recommendation 8 goes further, stating that manufacturers must transparently report product dependencies on underlying general-purpose models, including related risks and mitigations like continuity plans.

Sam: Continuity plans are key. If the company hosting the foundation model suddenly updates it or goes out of business, the hospital relying on the diagnostic tool needs to know what happens next. This ties into cybersecurity, too, right?

Maya: It does. Recommendation 10 requires the MHRA to issue draft guidance and educational resources setting out cyber security expectations across the lifecycle. The text specifically notes that cybersecurity threats can directly compromise safety or effectiveness, including the potential to cause rapid harm to many people.

Sam: Rapid harm to many people. That is a sobering phrase to see in a government regulatory response. It really highlights the scale of risk when software is connected across networks. Speaking of reaching many people, does this cover consumer devices? Like smartwatches that detect irregular heartbeats?

Maya: Yes, recommendation 11 focuses on direct-to-consumer applications and wearables with medical device functionalities. The MHRA will issue guidance outlining how to balance transparency and user-centred design with post-market monitoring for these specific tools.

Sam: So, we have all these pre-market and lifecycle concepts. What about getting these products to patients faster? Is there anything in this plan that accelerates adoption?

Maya: Yes, staged authorizations. Recommendation 14 says the MHRA will explore options to introduce staged authorization pathways. This enables earlier patient access while generating real-world evidence.

Sam: That sounds like a regulatory sandbox.

Maya: They mention that exactly. Recommendation 15 commits to delivering phase 3 of the MHRA's AI Airlock programme, and working with the Department for Business, Innovation, Science and Trade to support sandbox provisions into their upcoming Regulating for Growth Bill.

Sam: The AI Airlock programme. I love the name. It gives companies a safe, controlled environment to test novel technologies before full market release. But what if a product is already approved somewhere else, like in the US or Canada?

Maya: The document addresses that in recommendation 16. The MHRA will take forward proposals from its 2026 economic growth goals to establish specific recognition and reliance arrangements with international partners like the FDA, Health Canada, and the Therapeutic Goods Administration.

Sam: That is music to the ears of medtech companies. You do not want to run completely separate clinical trials for the UK if you just passed the FDA. But Maya, let's pivot to the clinical side. What happens when these devices actually hit the wards? How does the government plan to manage system-wide responsibility?

Maya: This is arguably the most complex part of the document. Theme two focuses on safe management. Recommendation 24 states that the Department of Health and Social Care, the MHRA, the Care Quality Commission, NHS Resolution, and professional regulators will form a working group.

Sam: A working group to do what, exactly?

Maya: To ensure that responsibility for different actors across the lifecycle is clear. They note that the group will not determine or redistribute responsibilities, but they are developing a shared set of high-level principles to clarify new responsibilities professionals may be less familiar with.

Sam: Quick note before we carry on. This spot is open for a sponsor. If your company builds or sells AI for healthcare and wants to reach the clinicians, health-system leaders and industry teams who listen to this show, the link to our sponsorship page is in the show notes.

Maya: And now, back to the document.

Sam: So if an AI misses a diagnosis, who gets sued? The doctor who didn't override it, the hospital that bought it, or the developer who built it? It sounds like they are still trying to map that out.

Maya: They are. But they are taking steps. Recommendation 28 commits to reviewing opportunities to more clearly allow responsibility allocation between manufacturer and providers in contracts. Healthcare providers need access to necessary information to understand where responsibilities should practically sit.

Sam: That means procurement teams at hospitals are going to need a lot more legal and technical support to negotiate these contracts. They cannot just sign standard software agreements anymore.

Maya: Exactly. To help with that, recommendation 29 introduces the AI Readiness Toolbox. The Department of Health and Social Care will co-develop this toolbox so healthcare organizations can assess their ability to deliver the risk controls necessary for a particular AI product.

Sam: An AI Readiness Toolbox. I like that. It moves away from vague guidelines and gives hospitals a checklist. Can they handle the cybersecurity? Do they have the governance structures? But what about the clinical staff? How are doctors and nurses supposed to keep up?

Maya: Recommendation 32 tackles AI literacy. There will be a coordinated approach to improving AI literacy across the ecosystem. This spans initial education, postgraduate training, and continuing professional development to establish a shared baseline of general AI capabilities.

Sam: Which they definitely need if they are going to be on the hook for monitoring these systems. The report mentions shifting toward post-market surveillance. How are clinicians supposed to report problems?

Maya: The government is delivering improvements to the Yellow Card scheme. Recommendation 34 highlights the need to strengthen the culture of reporting AI product experience. They are going to run public campaigns and explore how suppliers could facilitate reporting, like standardizing reporting templates.

Sam: The Yellow Card scheme is traditionally for adverse drug reactions and medical device incidents. Expanding that for software glitches or AI hallucinations makes sense. But doctors are already drowning in paperwork. Are they going to have time to fill out detailed software bug reports?

Maya: They actually address that exact burden. Recommendation 21 says the MHRA will explore opportunities to automate low burden reporting requirements. They want to embed automated reporting into integrated systems like electronic patient records and into the AI devices themselves.

Sam: Okay, automated reporting directly from the Electronic Patient Record. That is smart. And speaking of the EPR, how do they even track which AI was used on which patient?

Maya: Through Unique Device Identifiers, or UDI. Recommendation 20 states the MHRA will publish guidance on the mandatory use of UDI for medical devices. Crucially, they will work with health departments to ensure version control traceability is captured directly in the electronic patient record.

Sam: That is a massive practical detail. So if a patient was assessed using a specific version of a diagnostic tool, and we find out a year later that this exact version had a flaw, the hospital can query the patient record, find everyone assessed by that exact version, and call them back.

Maya: Precisely. And transparency isn't just for the hospitals. Theme three of the document is entirely about trust, transparency and predictability for the public.

Sam: How are they bringing the public into this? Are patients going to know when an AI is involved in their care?

Maya: Yes, recommendation 35 looks at complementing existing Information Governance requirements to clarify transparency expectations where AI is used. They are even considering when opt-out arrangements may be feasible and appropriate.

Sam: Opt-outs? That could be highly controversial. If an AI tool is baked into the standard triage pathway at an emergency room, how does a patient opt out without disrupting their care?

Maya: The document acknowledges that tension. It says any opt-out arrangements must be balanced against clinical effectiveness, equitable access, and patient safety considerations, particularly where AI functionality forms an integral part of a clinically approved medical device or care pathway.

Sam: It will be very interesting to see how they thread that needle. What else are they doing for public transparency?

Maya: Recommendation 19 is a big one. The MHRA will work to introduce a public facing database or tool where members of the public can access and search for information on reports of adverse incidents for medical devices, including AI.

Sam: So anyone can just log on, search for a specific AI tool by manufacturer or device name, and see all the safety incidents reported against it? They mention building on the success of the Interactive Drug Analysis Profiles, or iDAPs.

Maya: Exactly. They also plan to publish a regularly updated list of authorized AI-enabled medical devices in the UK, as noted in recommendation 37.

Sam: That level of transparency is rare. It forces manufacturers to be completely upfront because their failures will be publicly searchable. But what if a company just ignores these rules? What enforcement mechanisms does the MHRA actually have here?

Maya: Recommendation 22 addresses enforcement. The MHRA will explore options to strengthen its approach, including implementing the civil sanctions regime by the Medicines and Medical Devices Act, enabling the issuance of financial penalties where appropriate.

Sam: Financial penalties. So if a manufacturer fails to comply with legal requirements and places patients at risk, they are going to get hit with fines. It is not just a polite warning letter.

Maya: Right. But the government also wants to make it easier for developers to do the right thing from the start. Under recommendation 43, the MHRA will consider establishing a formal classification confirmation service.

Sam: A classification confirmation service? Meaning a company can ask the regulator early on, 'Hey, is this a Class II device or not?'

Maya: Exactly. Manufacturers could submit a short package and receive a written determination on a product's regulatory status, reducing avoidable delay and rework. They are also looking at expanding the existing Integrated Advice Service to provide early, predictable regulatory advice.

Sam: That is so important for startups. You cannot raise venture capital if you cannot confidently tell investors what regulatory pathway your product falls under. Providing a formal, written determination de-risks the early stages of company building.

Maya: And for research entities, recommendation 44 notes the Health Research Authority will update guidance like the 'Is my study research?' decision tool. This will help organizations determine when AI deployment or silent local evaluation actually constitutes research and requires research governance.

Sam: Silent local evaluation is such a common practice right now. Hospitals run the AI in the background, not affecting patient care, just to see how it performs on their data. Clarifying when that crosses the line into regulated research is desperately needed.

Maya: There is also a strong emphasis on health equity. Recommendation 13 states the MHRA will issue guidance to ensure devices do not create or exacerbate disparities for relevant population groups, including children, women, and underrepresented groups like ethnic minorities.

Sam: That is vital. We have seen too many examples of algorithms trained on narrow datasets failing when deployed on diverse patient populations. So they will require representative data and ongoing monitoring across the lifecycle to catch those biases.

Maya: Exactly. The scope of this response is vast. They are forming a cross-system Programme Board to oversee all this, and they promise an implementation plan and roadmap will be published by Spring 2027.

Sam: Spring 2027. So the clock is ticking. This isn't just an abstract list of ideas; they are committing to timelines, secondary legislation, and structural changes across multiple regulatory bodies.

Maya: For me, the most memorable takeaway is the sheer shift in regulatory philosophy. The MHRA is openly acknowledging that you cannot regulate an adaptive AI model the same way you regulate a titanium hip implant. The move to Predetermined Change Control Plans and lifecycle assurance is a fundamental rewrite of medical device oversight.

Sam: For me, it is the focus on transparency. Between tracking algorithms down to the version number in the electronic patient record, and building a public-facing database for AI adverse incidents, the UK is setting a very high bar for accountability.

Maya: To recap, the UK Government has accepted all 44 recommendations from the National Commission. They are updating device definitions, rolling out an AI Readiness Toolbox for hospitals, establishing pathways for general-purpose models, and creating a multi-agency working group to tackle clinical liability.

Sam: And with massive funding committed to tech initiatives, the NHS is aggressively positioning itself as a global proving ground for healthcare AI. We have linked the full Government Response document in the show notes. It is a dense read, but if you are building or buying health AI, you need to know what is in it.

Maya: As always, thank you for listening to Smart Summaries. A quick reminder that this is not medical advice. We will see you next time!