A health app stays outside MDR scope only as long as its intended purpose, read across the website, in-app copy, app store listing, and sales materials, makes no medical purpose claim under MDR Article 2(1). The moment any claim maps to diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, the same app becomes a medical device and the wellness safe harbor closes.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Article 2(12) defines intended purpose as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation.
  • Apps that promote general wellness, fitness, stress reduction, or lifestyle improvement sit outside MDR when no medical purpose claim is made anywhere in the product or its marketing.
  • MDCG 2019-11 Rev.1 is the primary guidance for deciding whether software falls inside or outside MDR scope.
  • A single line of marketing copy can move an app from outside scope to Class IIa under Rule 11 by introducing a medical purpose claim.
  • The Subtract to Ship path is to decide on day one which side of the line the product lives on, then freeze the wording that protects that decision.

Why the wellness safe harbor is so easy to lose

Most health app founders want to stay outside MDR. The reasoning is commercially sound. A wellness app has no notified body fees, no clinical evaluation, no QMS under EN ISO 13485:2016+A11:2021, no technical file, no post-market surveillance reports. A product that costs a few engineer-months to launch as a wellness app can cost an order of magnitude more to launch as a medical device.

The trap is that the line between wellness and medical device is not drawn by what the software does under the hood. It is drawn by what the manufacturer claims. The same algorithm that tracks resting heart rate is a wellness feature when the copy says "understand your general fitness level" and a monitoring medical device feature when the copy says "detect abnormal heart rhythms".

Tibor has reviewed several cases where a founding team believed they had a wellness product until the CEO gave a single podcast interview promising that the app could help patients "manage their condition". That sentence was picked up by a competitor, forwarded to a competent authority, and the app was in MDR scope the following week.

Felix has coached founders through the opposite problem. Teams that want to be wellness sometimes describe the product to investors as "medical grade" because the fundraising climate rewards that framing. The same deck ends up on a founder's LinkedIn page. That post is evidence of intended purpose.

What MDR Article 2(12) actually says

MDR Article 2(12) defines intended purpose as follows: "intended purpose means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation".

Two words in that definition carry most of the weight.

First, "statements". The definition is not limited to the formal instructions for use. A statement on a website, in a pitch deck, in a press release, in an app store listing, or even in a founder interview is covered.

Second, "promotional". The definition explicitly includes marketing. A marketing team that writes aggressive copy is contributing to the intended purpose whether or not the regulatory lead ever sees the draft.

The practical consequence is that intended purpose is not a field in a regulatory document. It is the sum of everything the manufacturer has ever said about the product. A wellness safe harbor defense depends on that sum staying consistent.

MDCG 2019-11 Rev.1 as the primary filter

MDCG 2019-11 Rev.1 is the authoritative MDCG guidance on qualification and classification of software under MDR and IVDR. The guidance sets out a four-step decision flow:

  1. Is the product software in the MDR sense?
  2. Does the software perform an action on data beyond simple storage, archival, communication, or simple search?
  3. Is that action performed for the benefit of an individual patient?
  4. Does the intended purpose match one of the medical purposes listed in MDR Article 2(1), including diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease?

An app that answers yes to all four questions is medical device software under MDR and is classified under Rule 11 in Annex VIII. An app that answers no at any step is outside MDR scope.

The guidance also gives worked examples. A general-purpose fitness tracker that records steps, heart rate, and sleep and displays them back to the user for general wellness purposes is outside scope under the examples. An app that uses the same raw data to detect an arrhythmia and flag it to the user or a clinician is in scope. The difference is the intended purpose, not the hardware and not the algorithm.

Tibor uses MDCG 2019-11 Rev.1 as a first filter with every software startup he advises. The founders walk through the four steps, write the answers down, and sign them. That signed document becomes the anchor for every downstream regulatory decision.

Apps that sit safely outside MDR

The patterns that consistently stay in the wellness safe harbor share three features.

First, the product describes general wellness, fitness, lifestyle, or emotional well-being. The copy uses words like "fitness", "wellness", "mindfulness", "activity", "general awareness of your body".

Second, the product makes no claim of diagnostic, monitoring, prognostic, predictive, preventive, or treatment value against a disease or condition. The copy avoids disease names, disease stages, and clinical decisions.

Third, the product is marketed to the general population rather than to patients with a specific condition. The onboarding does not ask for a diagnosis. The clinician dashboard, if any, is for general coaching rather than clinical management.

Examples that typically sit outside MDR when the claims match: - A meditation app that helps users practice mindfulness for general well-being. - A running app that coaches users through training plans for general fitness. - A nutrition app that lets users log meals and see macronutrient totals for general dietary awareness. - A sleep tracker that shows sleep duration and patterns without claiming to diagnose or treat insomnia.

The line-crossing examples

The same underlying product crosses into MDR scope the moment the intended purpose changes. MDCG 2019-11 Rev.1 is explicit on this.

  • A mindfulness app becomes a medical device when it is marketed as a treatment for clinical anxiety or depression.
  • A running app becomes a medical device when it is marketed as a cardiac rehabilitation program for post-infarct patients.
  • A nutrition app becomes a medical device when it is marketed as a glycemic management tool for diabetic patients, even if the underlying food logging is unchanged.
  • A sleep tracker becomes a medical device when it is marketed as a diagnostic aid for sleep apnea.

In each case the software did not change. The claim changed. Under MDR Article 2(12) the claim is the intended purpose, and under MDR Article 2(1) the intended purpose is what triggers medical device qualification.

Once the line is crossed, Rule 11 in Annex VIII determines the class. Most line-crossing apps land at Class IIa, because the decisions they inform have clinical consequences. Some escalate to Class IIb when the decisions could cause serious deterioration.

A worked example: the meditation app that crossed the line

A three-founder startup launched a meditation app for general stress reduction. The app sat cleanly outside MDR for eighteen months. The team grew to twelve, raised a Series A, and hired a marketing lead.

The marketing lead redesigned the landing page. The new hero line read: "Clinically proven to reduce symptoms of generalized anxiety disorder". A customer support agent added a paragraph to the FAQ: "Our app can help patients manage their anxiety between therapy sessions". An interview with the CEO appeared on a podcast in which the CEO said the app "treats mild to moderate anxiety".

Three statements. Three crossings of the MDR Article 2(12) line. The product was now a medical device software product under Rule 11, plausibly Class IIa, and the team had no QMS, no technical file, no clinical evaluation, no notified body relationship.

Tibor was called in two weeks after a competent authority inquiry landed. The remediation took six months and cost significantly more than building the regulatory path on day one would have. The irony the team learned the hard way: the wellness framing had been perfectly defensible, and the Series A pitch had not required the clinical language at all. The marketing team had added risk that brought no commercial benefit.

Felix has coached founders through exactly this conversation. The commercial question the team needs to answer before they write any copy is whether the medical purpose claim actually moves the business forward. In most wellness cases the answer is no, and the safe harbor is free.

The Subtract to Ship playbook for staying in the safe harbor

  1. Decide on day one whether the product is wellness or medical device. Write the decision down and sign it.
  2. If wellness, write the single paragraph that describes the intended purpose without any medical purpose claim. Treat that paragraph as a legal artifact.
  3. Publish a claims policy internally. Every marketing asset, every pitch deck, every website change, every app store listing must be reviewed against the claims policy before it ships.
  4. Train the founders. The founders are the most frequent source of line-crossing statements, because they are the ones doing podcast interviews and writing LinkedIn posts.
  5. Run the MDCG 2019-11 Rev.1 four-step flow every time the product adds a new feature. Any feature that moves an answer from no to yes moves the app into MDR scope.
  6. Keep the evidence file. Every time a regulatory question arises, the team needs to be able to pull the current website copy, the current app store listing, and the current claims policy within an hour.
  7. If the team decides later that a medical purpose claim is commercially necessary, plan the transition properly. The wellness-first path described by Tibor during the Round 2 follow-up is a legitimate strategy when done deliberately, and a disaster when done accidentally.

Reality Check

  • Has the team written and signed a single-paragraph intended purpose statement for the app?
  • Does the current website copy contain any word or phrase that could be read as a medical purpose claim under MDR Article 2(1)?
  • Does the app store listing, in every market and every language, contain any medical purpose claim?
  • Have the founders reviewed their own LinkedIn posts, press interviews, and pitch decks against the claims policy?
  • Does the team run the MDCG 2019-11 Rev.1 four-step flow every time a new feature ships?
  • Is there a named person responsible for approving claims before they go public?
  • Would a competent authority inquiry arriving tomorrow find a coherent wellness story or a contradictory mix of wellness and clinical claims?

If more than one of these answers is no, the wellness safe harbor is already at risk.

Frequently Asked Questions

Can an app describe health benefits without being a medical device? Yes, as long as the benefits are framed as general wellness, fitness, or lifestyle improvements and no claim maps to diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. The distinction is made by the language of the claim, not by the mechanism of the product.

Does the app store category matter for MDR qualification? No. MDR Article 2(12) looks at the data supplied by the manufacturer, including promotional statements. Selecting a "Health and Fitness" category in an app store does not protect against a medical purpose claim made in the listing text, website, or interviews.

What if the founder uses clinical language in a pitch deck that never reaches consumers? A pitch deck shared with investors is a statement by the manufacturer. If it describes a medical purpose, it contributes to the intended purpose under MDR Article 2(12). The mitigation is to keep the pitch deck consistent with the consumer-facing claims.

Is there any safe way to evolve from wellness to medical device? Yes. Tibor has described the wellness-first path as one of the best regulatory decisions he has seen founders make when done deliberately. The team launches as wellness, gathers real-world evidence and users, then plans a structured transition to a medical device version with a separate brand or a clearly versioned product. The transition is planned on day one, not discovered by a competent authority letter.

What does MDCG 2019-11 Rev.1 actually cover? MDCG 2019-11 Rev.1 is the Medical Device Coordination Group guidance on qualification and classification of software under MDR and IVDR. It provides the four-step decision flow for determining whether software is a medical device, the logic for applying Rule 11 classification, and worked examples across common software categories. It is the first document a software founder should read after MDR Article 2.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(1), Article 2(12), Annex VIII Rule 11.
  2. MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and Regulation (EU) 2017/746, June 2025.