If you have ever used an app to log symptoms, interpret a blood glucose reading, or get a personalised health recommendation, there is a real chance you have interacted with something that the MHRA considers a medical device. Most people have no idea that category exists, let alone what it requires of the companies building these tools. The MHRA AI medical device regulation UK framework is one of the most consequential and least-discussed shifts in British healthcare right now, and it is worth understanding in plain terms.
What the MHRA actually classifies as a medical device in software
The MHRA’s Software and AI as a Medical Device (SaMD) framework draws a clear line: if a piece of software is intended to be used for a medical purpose, it falls under regulatory oversight. That includes diagnosing a condition, predicting deterioration, monitoring a chronic illness, or informing a treatment decision. General wellness apps, step counters, and sleep trackers that make no medical claims sit outside this definition. The moment an app says it can detect an arrhythmia, flag early signs of diabetic retinopathy, or suggest a medication adjustment, it crosses the line.
The MHRA uses a risk-based classification system, running from Class I (lowest risk) up to Class III (highest risk). Most AI-driven diagnostic tools land in Class IIa or IIb, which requires a Conformity Assessment carried out by a UK Approved Body. Developers must maintain a technical file that includes clinical evidence, details of the algorithm’s training data, and a post-market surveillance plan. For Class IIb and above, that plan must be proactive, not reactive. The MHRA’s published guidance on AI as a medical device lays out the current framework in detail, including the 2024 roadmap updates that are now being implemented.
How the UK framework differs from what came before
Prior to the UK leaving the EU’s regulatory orbit, software developers could rely on CE marking under the EU MDR. Since then, the MHRA has been building its own regime, and the UK Conformity Assessed (UKCA) mark is now the requirement for Great Britain. The MHRA published its “Software and AI as a Medical Device Change Programme” in stages from 2022 onwards, and the 2026 position is that manufacturers must demonstrate what the regulator calls “safe and effective performance” throughout the entire product lifecycle, not just at launch.
What makes this genuinely different for AI tools is the acknowledgement of continuous learning. An algorithm that updates itself based on new patient data is not the same product it was six months ago. The MHRA’s framework addresses this with the concept of predetermined change control plans, meaning developers must specify in advance what kinds of changes they anticipate the model making and get those parameters approved. That is a meaningful shift from how software regulation has historically worked, where a product was reviewed once and then largely left alone.
What developers are required to demonstrate
In practical terms, a company seeking approval for an AI-driven diagnostic app needs to show several things. Clinical validation is the big one. The algorithm must be tested against the population it will actually serve, not just the dataset it was trained on. This matters enormously because training data bias is a real and documented problem. An ECG algorithm trained predominantly on data from white men in their forties will perform differently on South Asian women in their sixties, and the MHRA expects developers to account for that explicitly.
Beyond clinical evidence, developers must provide transparency about how the algorithm reaches its outputs. That does not necessarily mean publishing the model weights, but it does mean producing documentation that allows a clinician to understand the basis for a recommendation. There is also a usability requirement: the interface must be tested with real users to ensure the information is presented in a way that supports safe decision-making rather than creating confusion or misplaced confidence.
Post-market surveillance is where many smaller developers struggle. They are required to collect real-world performance data after launch, track adverse events, and submit periodic safety update reports. For a well-funded medtech company this is manageable. For a startup with a lean team, the administrative burden is substantial, and I would argue that is partly why so many health apps quietly drop medical claims from their marketing to avoid classification altogether.
Where the gaps still are
The framework is improving, but several gaps remain. Enforcement is the most obvious. The MHRA does not have the resource to proactively audit every app marketed to UK users. In practice, most enforcement is complaint-driven, which means a poorly validated tool can operate for months or years before anyone formally challenges it. This is particularly concerning given how many AI-driven health apps are marketed directly to consumers via app stores, where the App Store and Google Play review processes have no meaningful medical device checkpoint.
International products are another complexity. An app developed in the US, Canada, or elsewhere, marketed to UK users, technically requires UKCA marking if it makes medical claims. In reality, many do not have it, and the MHRA’s ability to pursue overseas developers is limited. Given the rapid growth of AI wearables and monitoring platforms, this is not a small edge case.
There is also a definitional grey area around generative AI tools used in health contexts. A large language model that answers questions about symptoms is almost certainly providing information, not diagnosis, and therefore sits outside SaMD classification. But that line is blurring. If a tool consistently recommends specific courses of action based on symptom inputs, at what point does it become a diagnostic aid? The MHRA has signalled it is watching this space closely, but firm guidance is still in progress.
What this means if you use health apps
As a consumer, you have limited visibility into whether a given app has gone through proper regulatory review. A few practical checks help. If an app makes medical claims, look for a UKCA mark or CE mark in the product documentation (many legitimate medical device apps display this in their terms or in app store listings). Check whether the company publishes a clinical evidence summary. If they do not, ask yourself why. Apps that have genuinely validated their algorithms tend to say so clearly because it is a genuine competitive advantage.
The MHRA maintains a register of certified medical devices, though navigating it is not exactly user-friendly. It is worth knowing that the NHS App and NHS-commissioned digital tools are held to a higher standard, going through NHS England’s Digital Technology Assessment Criteria (DTAC) as well as MHRA requirements. That dual-layer review gives NHS-approved tools more credibility than consumer apps operating solely on the basis of self-declaration.
The regulatory picture for AI in health is improving, but slowly. The gap between what technology can claim and what it has rigorously demonstrated is still wide in places. For anyone relying on an app to inform decisions about their health, that gap is worth keeping front of mind.
If you are thinking about how digital health tools intersect with NHS systems and patient data, the questions raised about NHS diagnostic pathways and patient experience are closely connected. And the broader question of how UK adults manage their health with limited NHS access is part of why so many people turn to consumer apps in the first place. Understanding what those apps are, and are not, legally required to prove is a reasonable starting point for anyone trying to make informed choices.