--- title: "Wellness App or Medical Device? Your Intended Purpose Decides" description: "When does a wellness app become a medical device under the EU MDR? Explore intended purpose, software qualification, Rule 11 and common grey areas." url: https://qbdgroup.com/en/blog/wellness-app-or-medical-device-intended-purpose type: "Blog post" language: en published: 2026-10-21 author: "Judith Prevoo & Caroline Aernouts" category: "Regulatory Affairs" publisher: "QbD Group" citation: "QbD Group, \"Wellness App or Medical Device? Your Intended Purpose Decides\", https://qbdgroup.com/en/blog/wellness-app-or-medical-device-intended-purpose" --- # Wellness App or Medical Device? Your Intended Purpose Decides > When does a wellness app become a medical device under the EU MDR? Explore intended purpose, software qualification, Rule 11 and common grey areas. Two apps measure your heart rate. One is a fitness tracker. The other is a regulated medical device that may need a Notified Body, a quality management system and clinical evidence before it can reach the European market. Same sensor. Same algorithm. Completely different regulatory reality. So what makes the difference? In one word: your claim. More precisely, it is the intended purpose expressed through your claims, functionality and supporting information. That decision can shape your entire route to market. **In This Blog Post** - Why intended purpose matters more than the underlying technology - How similar software functions can fall on different sides of the MDR boundary - What to do when wellness and medical functions coexist - How MDR Rule 11 affects software classification - Four questions to ask before launch ## It Is Not the Technology, It Is the Intended Purpose Under the EU Medical Device Regulation (MDR), software can qualify as a medical device when its manufacturer intends it to serve a medical purpose, such as diagnosis, prevention, monitoring, prediction, prognosis or treatment of disease. Regulators do not start from your code alone. They look at what your product is intended to do. That intended purpose lives in more places than the technical documentation. It is reflected in your website, App Store description, user manual, sales presentations and the way you describe the product to customers. If your marketing says “helps you manage your hypertension”, a disclaimer stating “for entertainment purposes only” is unlikely to outweigh the medical claim. The overall evidence of intended purpose matters. Clinical context also deserves attention. A wellness app does not automatically become a medical device simply because a healthcare professional uses it. But intended users, functions, outputs and claims can reveal a medical purpose that needs to be assessed. ## Same Feature, Two Regulatory Realities The easiest way to see the distinction is to put similar functions side by side. These examples illustrate how intended purpose can change qualification; they are not automatic classification rules. | Function | Wellness App | Potential Medical Device | |---|---|---| | Heart rate | Helps you stay in your target cardio zone during training | Analyses heart-rate data to detect arrhythmia or atrial fibrillation | | Diet tracking | Tracks calories and macros to support healthy eating | Uses carbohydrate intake to recommend insulin doses for people with diabetes | | Mental health | Offers meditation and breathing exercises for everyday stress | Provides CBT modules intended to treat diagnosed generalised anxiety disorder | | Chatbot | Provides general information about common cold symptoms | Performs patient-specific triage and recommends whether emergency care is needed |

In each pair, the potential medical device version moves beyond general wellbeing towards disease-related assessment, treatment or clinical decision support. The precise qualification still depends on the manufacturer's intended purpose and the actual functionality.

## Real Products Live in the Grey Zone The examples above are deliberately clear. Real digital health products often combine wellness features with functions that may qualify as medical devices. A single app might track daily activity, offer lifestyle tips and provide a separate module that supports clinical decisions. That is where a clear, documented qualification rationale makes all the difference. Map the software architecture and identify the intended purpose and function of each relevant module. Assess which modules may fall within the MDR and whether they can be meaningfully separated from non-medical functionality. A modular approach can help define the regulatory scope more precisely. But simply labelling one part of an app "wellness" does not exclude it from regulation if it contributes to a medical function or cannot be meaningfully separated from it. ## Once Software Qualifies, Classification Follows Qualification and classification are two distinct decisions. First, establish whether the software is a medical device. Then determine its risk class using the applicable MDR classification rules, particularly Rule 11 for many software products. Depending on what the software does and the significance of the information it provides for healthcare decisions, Rule 11 can lead to Class IIa or higher. Certain software may qualify as Class I when the applicable criteria support that conclusion. For Class IIa and higher devices, a Notified Body is generally involved in conformity assessment. A defensible classification rationale therefore matters for planning evidence generation, quality-system activities, timelines and budget. The updated MDCG 2019-11 guidance can support qualification and classification reasoning, but it does not create a shortcut to Class I. The outcome must follow the software's actual intended purpose and the applicable MDR rules. ## Four Questions to Ask Before You Launch 1. Do your website, App Store listing, instructions or sales materials claim to diagnose, monitor, predict, prevent or treat a disease? 2. Could the software output be intended to inform a healthcare professional's or patient's decision about diagnosis or treatment? 3. Have you documented the intended purpose and regulatory qualification of the relevant software modules, not just the product as a whole? 4. If a module qualifies as a medical device, have you justified its classification under Rule 11 and any other applicable rules? A “yes” to the first two is a reason for closer assessment, not automatic proof of medical-device status. A “no” to the last two signals that important groundwork may still be missing. ## Your Claim Is a Strategic Choice Qualification is not a box to tick at the end of development. It can determine the evidence you need, the quality-system requirements that apply, the conformity-assessment route and the time it takes to enter the market. Choose your claims deliberately. Make sure your product, marketing and regulatory teams tell the same story. Most importantly, design and document the software so that its functionality, evidence and intended purpose are aligned. The same technology can support very different products. The difference is not a clever disclaimer. It is a clear, defensible intended purpose that matches what the software actually does. ## Clarify Your Software’s Route to the EU Market Not sure which side of the line your software is on? QbD Group helps digital health companies assess intended purpose, qualify software modules, justify classification decisions and plan a realistic route to EU market access. Get in touch with our experts to build a regulatory strategy that fits your software and the claims you want to make. --- Source: https://qbdgroup.com/en/blog/wellness-app-or-medical-device-intended-purpose — © QbD Group. Quote freely with attribution and a link back.