---
title: Mobile Apps as Medical Devices Under MDR: When Your App Needs CE Marking
description: Not every health app is a medical device — but the line under MDR is sharper than founders realise. Here is when your mobile app needs CE marking.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: mobile apps medical devices MDR
canonical_url: https://zechmeister-solutions.com/en/blog/mobile-apps-medical-devices-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Mobile Apps as Medical Devices Under MDR: When Your App Needs CE Marking

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A mobile app is a medical device under the MDR when its manufacturer-stated intended purpose meets one of the specific medical purposes listed in Article 2(1) of Regulation (EU) 2017/745, and when the app performs an action on data that goes beyond storage, archival, lossless compression, communication, or simple search. Delivery on a phone changes nothing about the qualification test. Once the app qualifies, Annex VIII Rule 11 classifies it, and in most cases pushes it to Class IIa or higher — which means CE marking through a Notified Body, a full QMS, technical documentation, clinical evaluation, and post-market surveillance. The MDCG 2019-11 Rev.1 decision tree (June 2025) is the walk-through Notified Bodies and Competent Authorities apply to health apps, and the App Store review is not the regulatory assessment.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- A mobile app is treated exactly like any other software under the MDR. The delivery channel — App Store, Play Store, web — does not change the qualification test.
- The qualification question runs through the four-gate test in MDCG 2019-11 Rev.1 Rev.1 (June 2025), anchored in MDR Article 2(1) and Article 2(12).
- A wellness app stays outside the MDR only if every public claim — website, app store listing, in-app copy, marketing — matches the non-medical positioning. One diagnostic sentence is enough to flip the qualification.
- Most medical apps that provide information used for diagnostic or therapeutic decisions are Class IIa at minimum under Annex VIII Rule 11. Class I apps under the MDR are rare.
- Qualification as a medical device triggers the full stack: CE marking, Notified Body conformity assessment at Class IIa and above, QMS under EN ISO 13485, software lifecycle under EN 62304:2006+A1:2015, risk management under EN ISO 14971, clinical evaluation, PMS, and vigilance.
- App Store and Play Store approval is a commercial gate, not a regulatory one. Neither store audits for MDR compliance. Shipping on the store without CE marking when CE marking is required is placing a non-conforming device on the EU market.

---

## The qualification question for health apps

Founders building health apps arrive with a consistent pattern. The product has a clinical use case — sleep tracking, symptom checking, cycle prediction, mood logging, medication reminders, arrhythmia detection — and the team assumes that shipping on a consumer app store somehow keeps them out of the regulatory stack. It does not. A Stockholm-based founder once told us, "We are not a medical device because we are on the App Store." We had to walk them back through Article 2(1), gate by gate, to show that their app — which classified ECG strips and returned a rhythm label to the user — was squarely inside the MDR.

The MDR does not name mobile apps as a category. It does not need to. Article 2(1) names "software" as one of the things that can be a medical device, and MDCG 2019-11 Rev.1 makes explicit that this covers mobile applications, cloud services, web platforms, and any other form of software regardless of delivery channel. The qualification is driven by the stated intended purpose under Article 2(12), not by the form factor or the distribution model. A phone is a general-purpose computer. Medical software on a general-purpose computer is still medical software.

The consequence is that the qualification test for a mobile app is identical to the test for any other software. The post on [when software qualifies as a medical device](/blog/when-does-software-qualify-medical-device) walks through the full four-gate decision tree in MDCG 2019-11 Rev.1. For a mobile app, the gates apply in exactly the same order with exactly the same weight.

## The qualification test for apps — the four gates

MDCG 2019-11 Rev.1 runs every piece of software through four sequential gates. The first gate that fails stops the process and the software is not a medical device. An app that passes all four is a medical device and moves on to classification under Annex VIII Rule 11.

**Gate 1 — Is it software?** A mobile app is software by definition. This gate always passes for apps. The gate is there to catch confusion about analogue processes that get called software by habit. It is not there to give apps an exit.

**Gate 2 — Does the app perform an action on data beyond storage, archival, lossless compression, communication, or simple search?** This is where many wellness apps correctly fall out. A pure diary that records what the user types is storage. A pure reminder that triggers at a fixed time is not an action on data. A step counter that displays raw counts without interpretation is storage and display. But the moment the app calculates, interprets, classifies, scores, segments, predicts, or alerts on clinical thresholds, the gate crosses. Symptom checkers cross it. Dosage calculators cross it. Arrhythmia classifiers cross it. Mental-health screeners that compute severity scores cross it.

**Gate 3 — Is the action performed for the benefit of individual patients?** Mobile apps almost always pass this gate, because the unit of use is a single phone and a single user. Population-level dashboards are rare on mobile. An app that generates a per-user output crosses the gate.

**Gate 4 — Does the intended purpose meet Article 2(1)?** This is the decisive gate. If the manufacturer's stated intended purpose — in the app store listing, the website, the in-app copy, the marketing — falls within the specific medical purposes named in Article 2(1), the app is a medical device. If it does not, it is not. The gate is sensitive to phrasing and to consistency across every public surface.

An app that passes all four gates is a medical device and must be CE-marked under the MDR before being placed on the EU market.

## The wellness app safe harbor versus the medical device line

The cleanest exit from the MDR for a health app is a genuine wellness positioning held consistently across every public claim. MDCG 2019-11 Rev.1 recognises that lifestyle and wellness applications without medical claims fall outside the Regulation. The safe harbor exists. What it requires is discipline.

A wellness positioning means the intended purpose stays within general health, fitness, well-being, or lifestyle — none of which are medical purposes under Article 2(1). The positioning has to hold across the app store listing (name, subtitle, category, screenshots, description), the website copy, the marketing materials, the in-app onboarding, the push notifications, the investor deck, and the support documentation. Every surface. If the app store says "heart-rate monitoring for fitness" and the website says "early detection of atrial fibrillation," the manufacturer has placed a medical device on the market without CE marking, regardless of which of the two descriptions they meant.

The line is sharper than founders realise because Article 2(12) pulls in all public claims, not only the one printed on a label. Investor decks do not bind the Regulation directly, but they bind reality once the product ships — Competent Authorities read marketing, and they treat consistent diagnostic language as evidence of real intended purpose. The safe harbor survives as long as the discipline survives.

Three tests to know whether a wellness positioning is real:

- Would the product be commercially meaningful if every medical claim came off every public surface tomorrow?
- Does any public surface use the words "diagnose," "detect," "screen," "monitor," "predict," "prevent," or "treat" in a clinical sense?
- If a Competent Authority read the website, the app store listing, and the marketing in one sitting, would they reach the same conclusion as the regulatory file?

A no on any of these means the safe harbor is not real, and the qualification answer is "medical device" regardless of what the founders intended.

## Examples by app type

The qualification answer depends on the specific intended purpose and the specific feature set. These are archetypes, not rulings on any one product.

**Symptom checkers.** An app that asks users about symptoms and returns a list of possible conditions, a severity score, a triage recommendation, or an urgency flag is providing information used for diagnostic or therapeutic decisions. This passes all four gates. Under Rule 11 the default is at least Class IIa, and if the triage output could lead to inappropriate delay in serious conditions, Class IIb is the realistic floor. A pure educational symptom glossary that does not take per-user input and return per-user output stays under Gate 3 and typically fails the test.

**Dosage calculators.** An app that takes patient-specific inputs — weight, age, renal function, indication — and computes a drug dose is providing information used for therapeutic decisions. This crosses Gate 2 cleanly (calculation) and Gate 4 cleanly (therapeutic purpose). Under Rule 11 the class depends on the severity of the consequence if the dose is wrong — from Class IIa as a floor up to IIb or III for high-risk medications where a wrong dose could cause serious deterioration or death. A pure reference app that displays static dosing tables without patient-specific calculation is closer to "simple search" and may stay below Gate 2, but the line is narrow and contested.

**Fitness trackers.** A step counter, calorie estimator, or workout logger with general wellness positioning typically fails Gate 4 — general fitness is not a medical purpose. The moment the same device adds "detects atrial fibrillation" or "screens for sleep apnoea," the intended purpose changes and Gate 4 passes. The regulatory status follows the claim, not the hardware. Several consumer wearables run a dual-track strategy — the fitness features stay outside, the ECG or SpO2 features ship as separately qualified medical device software with their own CE marking.

**Mental-health apps.** A mood journal or meditation timer with wellness positioning stays outside. A screener that administers PHQ-9 or GAD-7 and returns a depression or anxiety severity score for clinical use crosses Gate 2 (scoring) and Gate 4 (diagnosis and monitoring of disease). A therapy-delivery app that treats a diagnosed condition under MDR Article 2(1) — "treatment of disease" — is a medical device and commonly qualifies as Class IIa software intended to provide information used for therapeutic decisions, or higher if the consequences of failure are severe. The German DiGA pathway is the clearest example of medical mental-health apps running under a defined regulatory framework; DiGA approval sits on top of CE marking, not instead of it.

## The consequences of getting it wrong

Shipping a mobile app that is a medical device without CE marking is placing a non-conforming device on the EU market. MDR Article 5 prohibits it. The consequences scale with the severity of the non-conformity and the reaction of the Competent Authority.

The commercial consequences come first and come fast. Market withdrawal is the baseline outcome — the app is pulled from the stores, the website is taken down, and every existing user is notified. For an app-based business, market withdrawal is often existential because the user base is the company. Reconstruction after a withdrawal takes months at minimum and years in serious cases, because the product has to be re-built under a medical-grade lifecycle from an earlier point in the history than the founders had imagined.

The regulatory consequences follow. Competent Authority enforcement action, reporting to EUDAMED, mandatory field safety corrective actions, and in serious cases administrative penalties. The reputational consequences are the hardest to reverse — a health app that gets pulled for regulatory non-compliance carries that label into every later funding round, every partnership conversation, and every hospital procurement process.

The clinical consequences are the ones that matter most. An app that gives wrong information to the wrong user at the wrong time can cause real harm. This is the reason the MDR applies in the first place — not to slow down innovation, but to make sure software that affects clinical decisions is developed under a lifecycle that matches the risk. Founders who skip the qualification question are not just taking a regulatory risk; they are taking a patient-safety risk, and the Regulation treats those as the same thing.

The App Store and Play Store review does not protect against any of this. Neither store audits for MDR compliance. Both stores have accepted, and then later removed, apps that turned out to be non-conforming medical devices. Store approval is a commercial gate. CE marking is the regulatory gate. They are not substitutes.

## Common mistakes

- **"We are just an app."** The MDR does not carve out apps. Delivery channel is irrelevant to qualification.
- **"The App Store approved us."** The stores do not assess medical device compliance. Their approval is not a conformity assessment.
- **"Our disclaimer says we are not a medical device."** A disclaimer cannot override the intended purpose that the rest of the marketing and the feature set establish. Competent Authorities read the whole product, not only the fine print.
- **"We are in beta, the MDR does not apply yet."** MDR Article 5 applies from the moment the device is placed on the market or put into service. Beta in the App Store is on the market. Research deployment in a hospital can be outside the MDR if it is genuinely non-clinical research, but user-facing betas in consumer stores are not.
- **"We will CE-mark later, after product-market fit."** The qualification question does not wait. Shipping a medical device without CE marking in the meantime is non-compliance, not a stage of development. The two-phase approach exists for exactly this case — run Phase 1 with a non-medical intended purpose held consistently, and move into the MDR work only after Phase 1 signals.
- **"US FDA clearance covers us in Europe."** It does not. MDR and FDA run separate qualification and classification frameworks. An FDA-cleared app still needs a separate MDR pathway for the EU market.

## The Subtract to Ship angle for mobile apps

The highest-leverage subtraction for a mobile health app is the one at the qualification gate — running the four-gate test from MDCG 2019-11 Rev.1 in writing before the product is built, and deciding with eyes open whether to stay outside the MDR with a wellness positioning or to enter the MDR with a medical positioning. Both choices are legitimate. The damage comes from making the choice by accident.

Subtract to Ship applied to apps cuts two specific kinds of waste. First, the waste of building a full MDR stack for a product whose intended purpose a small rewrite would keep outside the Regulation entirely — the Purpose Pass from [the Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr) catches this case. Second, the waste of assuming the App Store is the regulatory gate and discovering eighteen months later that the product is retroactively a non-conforming medical device. Running the test on day one costs an hour. Running it eighteen months late costs the company.

The discipline for a mobile medtech team is the same as for any other SaMD team, but with one extra layer. Every public surface has to match — and for apps, the public surfaces include the store listing, the screenshots, the review replies, the push notifications, the onboarding flow, and the support articles, in addition to the website and the marketing. The qualification answer is only as stable as the least-disciplined surface. Keeping them in sync is cheap if you start early and expensive if you start late.

## Reality Check — Where do you stand on your app's qualification?

1. Have you written down the intended purpose of your app in one paragraph, in the form Article 2(12) expects?
2. Have you walked the app through the MDCG 2019-11 Rev.1 four-gate decision tree and recorded the answer at each gate?
3. At Gate 2, have you listed every action your app performs on data and confirmed which ones go beyond storage, archival, lossless compression, communication, or simple search?
4. At Gate 4, does the intended purpose map to one of the specific medical purposes in Article 2(1), or does it stay within general wellness?
5. Do the app store listing, the website, the in-app copy, the push notifications, and the marketing all match the intended purpose you ran the test against?
6. If you believe the app is a wellness product, could you defend that position with every public surface printed out on a desk in front of a Competent Authority?
7. If you believe the app is a medical device, do you know its class under Annex VIII Rule 11 and the conformity assessment route under Article 52?
8. Is your engineering team running a documented lifecycle that would map onto EN 62304:2006+A1:2015, even if the formal standard is not yet in place?

Any question you cannot answer with a clear yes is a gap. Close it before the next release.

## Frequently Asked Questions

**Does every health app need CE marking under MDR?**
No. Only apps that qualify as medical devices under MDR Article 2(1) need CE marking. Apps with a genuine wellness positioning — general fitness, lifestyle, well-being — that hold that positioning consistently across every public surface are not medical devices and do not need CE marking. The qualification test is the MDCG 2019-11 Rev.1 four-gate decision tree.

**Can a mobile app be Class I under the MDR?**
Rarely. Annex VIII Rule 11 pushes most medical software that provides information used for diagnostic or therapeutic decisions to Class IIa at minimum. A mobile app that is Class I under the MDR is usually one that does not provide decision-support information at all. Assuming Class I for a medical app without walking through Rule 11 with MDCG 2019-11 Rev.1 open is the single most common classification mistake we see.

**Does App Store approval mean my app is MDR-compliant?**
No. Apple's App Store review and Google's Play Store review do not assess MDR compliance. Their approval is a commercial gate covering their own policies, not a regulatory conformity assessment. A medical device app still needs CE marking under the MDR before being placed on the EU market, regardless of store status.

**If my app only processes data on the phone, does that change the qualification?**
No. On-device processing and cloud processing are both software actions. MDCG 2019-11 Rev.1 does not treat them differently for qualification. Where processing happens can matter for data protection, security, and lifecycle architecture, but it does not change whether the app is a medical device under Article 2(1).

**What is the difference between a medical app and a DiGA?**
A DiGA (Digitale Gesundheitsanwendung) is a German reimbursement pathway for digital health applications that are already CE-marked as low-risk medical devices. DiGA approval sits on top of MDR CE marking, not instead of it. A DiGA is always a medical device under the MDR; the DiGA status is the reimbursement layer on top.

**Can an app update move us from non-medical to medical device?**
Yes. Adding a feature or a claim that crosses one of the four gates moves the app into the MDR. A wellness step counter that adds arrhythmia detection becomes a medical device through that single feature. The update itself is the regulatory event, and shipping it without CE marking is non-compliance. Post 432 covers the substantial-change logic for medical software.

## Related reading

- [MDR Classification Rule 11 for Software — The Short Version](/blog/mdr-classification-rule-11-software) — the classification rule that applies to mobile medical apps.
- [Rule 11 Borderline Cases](/blog/rule-11-borderline-cases) — the edge cases where Rule 11 is contested for software.
- [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) — the pillar post for the SaMD category.
- [SaMD vs. Software in a Medical Device (SiMD)](/blog/samd-vs-simd-distinction) — the split that follows qualification when software is embedded in hardware.
- [When Does Software Qualify as a Medical Device?](/blog/when-does-software-qualify-medical-device) — the full four-gate decision tree walkthrough.
- [MDCG 2019-11 Rev.1 — What the Software Guidance Actually Says](/blog/mdcg-2019-11-software-guidance) — the full reading of the definitive guidance document.
- [The MDR Software Lifecycle and EN 62304:2006+A1:2015](/blog/mdr-software-lifecycle-iec-62304) — the lifecycle obligations that apply to mobile medical apps.
- [Substantial Changes to Medical Device Software](/blog/substantial-changes-medical-device-software) — when an app update triggers re-assessment.
- [Digital Health and DiGA Pathway in Germany](/blog/digital-health-diga-germany) — the German reimbursement layer on top of MDR CE marking.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar for this blog, with direct application to mobile app qualification.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2, points 1 and 12; Annex VIII, Rule 11. Official Journal L 117, 5.5.2017.
2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).

---

*This post is part of the Software as a Medical Device Under MDR category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — MDCG 2019-11 Rev.1 operationalises Article 2(1) and Article 2(12) for mobile app qualification, and Annex VIII Rule 11 governs classification. For startup-specific regulatory support on mobile medical device qualification and CE marking, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*