When is an app considered a medical device?

The MHRA (the regulator for medical devices in the UK) doesn’t start with features or technology. It starts with an intended purpose.

In practice, that means:

• What does your app claim to do?
• What do users believe it will help them with?
• How will the information it provides be used?

If your app is aimed at general wellbeing (encouraging steps, supporting meditation, logging moods or habits), you’re probably safe on the “lifestyle app” side of the fence.

But if your app is designed to:

• diagnose a condition
• monitor a disease
• predict symptoms or flare-ups
• recommend treatments or actions
• or inform clinical decisions

…then you’ve crossed the line into medical device territory.

And here’s the nuance that catches people out:

It doesn’t matter whether the app is capable of medical accuracy, only whether it claims to be.

If your onboarding screen says “We’ll help identify early signs of X”, that’s a medical claim. If your website says “Our app can help you determine whether you need clinical attention”, that’s a medical claim. If your UI displays a score that implies a diagnosis or treatment recommendation, that’s a medical claim.

Even if that claim was meant to be “friendly” or “helpful”, it still triggers regulation.

This is why we encourage partners to involve their development agency early in the product design phase, especially teams that understand how quickly small wording changes across UX, onboarding, and marketing can shift an app into a higher risk category.

Before you go too far in design or development, it’s worth doing a quick internal “claims audit”. Nothing complicated, just a structured sweep of every place your app talks to the user:

• onboarding screens
• notifications
• dashboards / scoring systems
• website landing pages
• marketing content
• investor decks (yep, these get scrutinised too)

Ask one question of each:

“Does this wording imply diagnosis, prediction, treatment, or clinical action?”

You’d be surprised how often a medical claim sneaks in through UI copy or a single line of marketing messaging.

If something might be interpreted as clinical, it’s a good moment to pause and bring in a product, UX, or regulatory specialist before you go further. It’s infinitely easier to adjust messaging early than to retro-fit the entire app into a medical-device workflow later.

Let’s clear up the other side of the line, because not all health-adjacent apps need clinical approval.

Apps that typically don’t qualify as medical devices include:

• step counters
• sleep trackers
• calorie or nutrition logs
• journaling or mood-tracking apps
• meditation and breathing apps
• menstrual cycle trackers that don’t make medical predictions

To put it simply:

Wellbeing apps help you notice patterns.

Medical apps help you act on them.

The moment your app influences action (especially medical action), the rules tighten.

Image source.

If your app might fall under medical device regulation, discovering this late in development is the worst-case scenario.

It affects almost everything under the surface:

Medical-grade apps need clearer audit trails, more structured data, and tighter security controls.

Interfaces must avoid misleading users; subtle colour choices or wording can imply risk levels, which instantly changes classification.

Medical devices need traceability, validation, and repeatable processes. Your QA process suddenly becomes part of the legal compliance journey.

Submitting a regulated medical app to app stores involves more than the usual checklist, you also need to ensure compliance with regulatory requirements, provide supporting documentation, and confirm that all safety and validation processes are complete before it can go live.

Once it’s live, you’re required to monitor incidents, update safely, and report any issues proactively.

None of this is difficult when planned, but it’s incredibly challenging when bolted on at the end. This is why partnering with seasoned app developers (who have worked within regulated sectors before, like us!) can save months of rework.

If you do fall into regulated territory, you’ll need to build with a few extra layers baked in from the start. The big ones:

Medical-grade apps need formal requirements that map directly to testing, risk controls, and release notes.

This is essentially a living document that spells out:

• what could go wrong
• how likely it is
• what controls the app has in place
• how those controls are tested

It’s not scary, but it is mandatory.

UX isn’t just “clean and intuitive”. You have to prove users won’t misinterpret data, colour coding, or language in a way that could put them at risk.

You’re not just testing whether the app “works”. You’re testing whether it works as intended, for the intended user, in the intended environment, every single time.

Even after release, regulated apps need:

• incident monitoring
• a clear update process
• a way to handle user-reported issues
• documented safety checks before each release

These are the things that often catch teams off guard, and the reason it’s worth making the medical/non-medical decision early in the journey.

Medical device classification sounds intimidating, but you don’t need a regulatory degree to understand the basics.

Here’s a simplified version:

The more impact your app might have on someone’s health, the higher its classification, and the stricter the requirements.

Imagine three different apps dealing with the same condition:

App A: “Track your asthma symptoms and see patterns over time.” ➡ Likely not a medical device.

App B: “Based on your symptoms, we’ll show your risk of a potential asthma flare-up.” ➡ Likely is a medical device.

App C: “Based on your flare-up risk, we recommend you increase inhaler use.” ➡ Definitely a medical device, and a higher-risk one.

Nothing technical changes between A, B, and C. The difference is the impact on user decisions.

Many modern health apps now use machine learning (even simple forms of it) to detect trends, classify symptoms, or automate decision support.

But here’s the key line:

If AI influences diagnosis or treatment, regulation becomes non-negotiable.

That doesn’t mean AI is off-limits, far from it.

It simply means transparency, explainability, and validation matter even more. And this is why working with skilled app developers who understand both AI and healthcare is so important, it’s easy to unintentionally create a medical device without meaning to.

If you want to dig a little deeper (or check how your app might be classified), these are great starting points:

• MHRA: Medical Device Regulations – plain-language guidance on where the lines are drawn.
• MHRA: Software and AI as a Medical Device (SaMD) change programme – the latest thinking on how AI tools will be regulated.
• NHS Digital Service Manual – best practices for designing safe, user-centred digital health products.
• BS EN 62304 – the recognised standard for medical software lifecycle processes.
• IMDRF SaMD Framework – useful if you’re planning global rollouts beyond the UK.

They’re not bedtime reading, but if you’re building something health-focused, they’re absolutely worth bookmarking.

If you’re unsure, this rule rarely fails you:

If the app guides medical decisions (even a little), assume it’s a medical device.

It’s safer, it’s clearer, and it ensures users aren’t misled.

Digital health is one of the most exciting areas in tech right now. The potential for apps to support patients, lighten workloads, and improve access to care is huge. But it comes with responsibility - not just to regulators, but to users who depend on that information.

Understanding when an app becomes a medical device isn’t there to slow innovation. It’s there to make sure innovation is safe, reliable, and trustworthy.

And if you’re stepping into this space (whether you’re commissioning an app or building one yourself), choosing the right development partner matters. You’ll want a team that understands what makes a great user experience and what medical-grade quality looks like behind the scenes.

If you're curious to see how this works in practice, check out our success stories with projects like iPrescribe, Slimming World, and Health Swap to see real examples of safe, effective, and user-friendly health apps in action.