The MHRA classifies an app by what it is intended to do, not by how it is built. If the app has a medical purpose, it is a medical device and sits in Class I, IIa, IIb or III depending on risk. If it only stores data, handles admin or supports general wellbeing, it usually sits outside the rules. Decide which side of that line your app falls on before design starts, because the answer shapes the features, the evidence and the budget.
TL;DR
- An app becomes a medical device through its intended purpose, judged from your labelling, instructions and promotional material, including app-store text.
- UK classes run from Class I (generally low risk) to Class III (generally high risk). Most software that diagnoses lands in Class IIa, and software that monitors dangerous vital parameters lands in Class IIb.
- Storing or passing on medical data unchanged, and administrative functions, are generally outside scope. Calculations, interpretation, diagnosis and treatment influence can bring an app in.
- Great Britain and Northern Ireland follow different market-access rules, so state where you will launch.
- Write the intended-purpose statement first. Every feature then either serves it or gets cut.
Table of Contents
- Step one: is your app a medical device at all?
- Intended purpose: the sentence that decides your class
- What usually falls outside the rules
- The four UK risk classes for software
- Wellness, information or decision support?
- Great Britain and Northern Ireland are not the same
- What happens once you know it is a device
- How to scope a health app so the class is a decision, not a surprise
- Where Pocket App fits
- Our perspective
- FAQ
- Sources
Step one: is your app a medical device at all?
The starting point is the definition in the UK Medical Devices Regulations 2002. A product may be a medical device if it has a medical purpose, and standalone software can qualify. The MHRA's borderline guidance also makes clear that not every product used in healthcare, or by healthcare professionals, is a medical device. The medical purpose and the mode of action both have to meet the definition.
In practice, ask four questions about each feature:
- Does it diagnose, monitor, predict, treat or alleviate a disease, injury or disability?
- Does it change the data (calculate, interpret, analyse) rather than simply store or send it?
- Could its output influence a clinical decision or a treatment?
- Does it drive or control another medical device?
A yes to any of these is a signal to look closely. A no to all of them usually points to an app outside the device rules, though the claims you make about it still count, as the next section explains.
Intended purpose: the sentence that decides your class
The MHRA works out medical purpose from the manufacturer's labelling, instructions for use and promotional material. Its software flowchart spells out where that material lives: adverts, app-store descriptions and categories, landing pages and social-media channels. A disclaimer in the small print does not override a medical claim made elsewhere.
This catches teams out. An app can be built as a simple tracker, then listed in the store under a medical category with a description that promises to "detect" or "predict" a condition. The listing, not the code, can make it a device.
NHS England's AI and Digital Regulations Service advises that an intended-purpose statement should identify:
- the device's structure and function
- the intended population
- the intended user
- the intended environment
A workable example: "An app used by adult patients at home to record blood glucose readings and share them with their clinical team." Compare that with "An app that analyses glucose trends and recommends insulin adjustments." The first is mostly data capture and transfer. The second influences treatment and is a very different regulatory proposition.
What usually falls outside the rules
The MHRA software flowchart says that storing or transmitting medical data without change, and administrative functions, are generally outside scope. General fitness, health and wellbeing monitoring is not usually a medical purpose, and simple symptom diaries may also fall outside.
The borderline guidance gives a clear pairing. Standalone software that enhances X-ray or ultrasound images is a medical device. A patient-management or records-storage system used simply for administration is not.
Calculations are a grey zone. According to CMS's summary of the MHRA's updated guidance (2020), simple calculations that can be easily verified are unlikely to need device status. Calculations that cannot be easily verified, because of their complexity or hidden linked lookup tables, are likely to be devices. The same summary gives a fertility example: an app that only tracks menstrual-cycle data for ovulation prediction is unlikely to be a device, while functionality that uses basal body temperature to help conception may be one.
The mode of action also matters. A product with a medical purpose that works mainly through metabolic, immunological or pharmacological means is likely to fall under medicinal-product rules rather than device rules. That rarely applies to a pure software app, but it is worth knowing if your app accompanies a treatment.
The four UK risk classes for software
The UK uses four classes: Class I (generally low risk), Class IIa and IIb (generally medium risk) and Class III (generally high risk). The MHRA's software flowchart maps software to them like this:
| Class | Typical software | Risk level |
|---|---|---|
| Class I | Other active software that does not meet the rules below | Generally low |
| Class IIa | Software intended for direct diagnosis | Generally medium |
| Class IIb | Software monitoring changes in dangerous vital parameters, controlling Class IIb therapeutic devices, or used for contraception or STI prevention | Generally medium to higher |
| Class III | Highest-risk devices | Generally high |
Two points sit behind the table. First, software that drives a medical device or automatically influences its use takes the same class as that device (implementing rule 2.3 in the flowchart). An app that controls a Class IIb pump is Class IIb, however simple the interface looks.
Second, class decides the route to market. The GOV.UK guidance on getting a device to market and the MHRA's classification material explain what each class requires. As a general principle, the higher the class, the more independent scrutiny and clinical evidence you need, and the longer the lead time.
Worked examples
These are illustrations of how the flowchart logic reads, not a ruling on any real product.
- A clinic appointment and reminder app. Administrative. Generally outside the device rules.
- A symptom diary where patients log how they feel. A simple diary may be outside scope. If the app starts analysing entries and flagging likely conditions, the purpose has shifted toward diagnosis, and Class IIa becomes the question.
- An app that reads a connected monitor and alerts when vital signs reach dangerous levels. Monitoring of dangerous vital parameters points to Class IIb.
- An app that controls a connected therapeutic device. It takes the class of that device.
Wellness, information or decision support?
Most commissioning teams are not building a pure diagnostic tool. They are building something in the middle: a wellbeing programme, a patient information app, a clinician dashboard. For these, the MHRA answer is that it depends on intended purpose and functionality. Monitoring intended to affect treatment or diagnosis, or data analysis for a medical purpose, can bring software within the regulations.
NICE offers a useful second lens for health technologies used in England. Its evidence standards framework places health and wellness diaries, mindfulness and sleep-support technologies in Tier B. Medical devices, screening tools and technologies intended to diagnose or treat sit in Tier C. The tiers reflect potential risk to the person and the wider system. NICE tiers are not MHRA classes, but the two together tell you how much evidence a buyer such as the NHS is likely to expect.
For our own clients, this is why the scoping conversation matters. Our guidance on NHS clinical safety standards covers how to build safety requirements into the development lifecycle, and it pairs naturally with the classification work described here.
Great Britain and Northern Ireland are not the same
UK market access currently differs by territory. According to GOV.UK, Great Britain uses UK MDR 2002, with UKCA marking available and transitional acceptance of specified CE-marked devices. Northern Ireland follows EU MDR and IVDR rules and requires CE marking.
The same page sets out the Great Britain transition. General devices CE-marked under the old directives may remain on the market until the earlier of certificate expiry or 30 June 2028. Devices marked under the EU MDR, and IVDs marked under the IVDR, may generally use the transition until 30 June 2030, subject to the stated conditions. Check the GOV.UK page for the current position before you commit to a launch plan, as these arrangements can change.
If you plan to launch across the whole UK, say so in your brief. It affects which marks you need and which evidence you collect.
What happens once you know it is a device
A device placed on the market must meet the essential requirements, and the developer (or its UK Responsible Person) and the device must both be registered with the MHRA. The conformity route depends on class. Lower-risk Class I software can generally follow a self-declaration route, while higher classes need an approved body.
Two obligations catch teams after launch:
- Change control. Changes to functionality, clinical pathway or intended purpose can require updated evidence and, where applicable, review or reassessment by the approved body, according to the NHS AI and Digital Regulations Service.
- Reporting. The Health Research Authority notes that MHRA guidance covers procedures and reporting responsibilities when medical software changes or goes wrong.
The practical consequence: a feature roadmap for a regulated app is a regulatory roadmap. Adding an "insights" screen in version 2 can change your intended purpose and your class.
How to scope a health app so the class is a decision, not a surprise
- Write the intended-purpose statement first. Use the four elements above: function, population, user, environment.
- List every feature against the four questions. Mark each as store or transmit, administrative, wellbeing, or interpret and influence.
- Audit your claims. Check the app-store listing, landing page, adverts and social posts against the intended purpose. They must say the same thing.
- Decide whether you want the regulated route. Sometimes the commercially sensible choice is a well-defined, lower-risk first release. Sometimes the clinical value needs a regulated function from day one.
- Map the class and the territory. Use the flowchart for the class, and confirm whether you are launching in Great Britain, Northern Ireland or both.
- Plan evidence and change control. Build the cost and time of conformity assessment, clinical evidence and post-market duties into the project plan.
This is the work our discovery phase is designed to front-load. Putting the intended purpose on paper before design means the screens, the data flows and the store listing all follow the same decision.
Where Pocket App fits
We are an independent UK mobile app developer with a portfolio of over 300 projects, including work in healthcare and charity. Our process runs through Discover, Design, Develop and Deploy, and the discovery stage, with strategic workshops and technical recommendations, is where a feature list is tested against an intended purpose. From there we move through interactive prototyping and agile build cycles, with server monitoring and post-launch support once the app is live.
If you are still deciding what your app should and should not do, our Mobile App Clinics are a practical place to start. Bring the idea, and we will talk through scope and approach with you.
When you are ready to brief a build, our mobile app development team can take it from intended purpose through to launch.
Our perspective
Most of the health apps that come to us start with a feature list. The better ones start with a sentence: who is this for, what does it do for them, and where will they use it. That sentence is what a regulator reads, and it is what a good design brief needs too.
We build with a technology-agnostic approach, recommending the best platform for each project. In healthcare, that discipline extends to scope. A tightly defined app is easier to design, easier to test and easier to explain to the people who commission it.
Across more than 300 projects and 30+ years of collective experience, we have learned that late changes cost the most. Settling the intended purpose in discovery, before a screen is drawn, keeps the build calm and the roadmap honest. Our healthcare articles set out how UK health apps are being used, and the same thinking applies to classification.
Paul
FAQ
Is a health and fitness app a medical device?
Usually not. According to the MHRA software flowchart, general fitness, health and wellbeing monitoring is not normally a medical purpose. The position changes if the app claims to diagnose, monitor a condition or influence treatment.
What class is a diagnostic app?
The MHRA flowchart treats software intended for direct diagnosis as generally Class IIa. Software that monitors changes in dangerous vital parameters is generally Class IIb. The exact class depends on the intended purpose and the rules applied to your product.
Does a disclaimer stop my app being regulated?
No. The MHRA determines medical purpose from your labelling, instructions and promotional material, including app-store descriptions and social media. A disclaimer does not override a medical claim made elsewhere.
Do the rules differ in Northern Ireland?
Yes. According to GOV.UK, Great Britain uses UK MDR 2002 with UKCA available, while Northern Ireland follows EU MDR and IVDR rules and requires CE marking. State your launch territory at the start of the project.
Do updates change my classification?
They can. Changes to functionality, clinical pathway or intended purpose may require updated evidence and review by the approved body where one is involved. Treat each release as a possible change to your intended purpose.
Sources
- Borderlines with medical devices and other products in Great Britain, GOV.UK
- MHRA software flowchart: stand-alone software including apps
- Determining the intended purpose of your software medical device, NHS AI and Digital Regulations Service
- MHRA releases updated guidance on medical device software and apps, CMS
- How to use the framework, NICE evidence standards framework
- Regulating medical devices in the UK, GOV.UK
- I'm developing medical software, Health Research Authority