When Does Your Product Become a Medical Device?

Why intended purpose determines everything, borderline wellness vs. medical claims, software classification under EU MDR, and the risks of under‑classifying early

Your product becomes a medical device the moment you promise it will do something for a health condition, not just for general wellbeing. Under EU MDR, that promise, your intended purpose, is what pulls you into the medical‑device world, with all the obligations that follow.

Intended purpose: the one sentence that changes everything

EU MDR 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.

In plain language, regulators read your website, app‑store text, sales deck, and IFU and take you at your word about what the product is for. If your claims talk about diagnosis, prevention, monitoring, prediction, or treatment of disease or injury, you are in medical‑device territory; if you stick to general wellbeing and avoid disease language, you are more likely to stay outside MDR.

Borderline: wellness or medical device?

The EU Borderline Manual and national authorities show how small wording changes can flip a product from “wellness” to “medical device.”

• A mood app
  • “Track your mood and reflect on your patterns” → usually wellness, because it supports self‑reflection without making clinical claims.
  • “Detects early signs of depression and tells you when to seek treatment” → medical device, because it aims at identifying a mental disorder and guiding medical action.
• A heart‑rate app
  • “Shows your heart rate during workouts” → classic fitness app, typically outside MDR.
  • “Screens for atrial fibrillation using your camera and flags possible events” → software as a medical device, because it screens for a specific cardiac condition.
• A fertility app
  • “Helps you understand your cycle and plan your life” → can remain on the wellbeing side.
  • “Prevents pregnancy with medical‑grade reliability” → medical device, and a higher‑risk one if failure leads to unintended pregnancy.

Same codebase, completely different regulatory story—decided by how you describe what the product does.

When software quietly turns into a medical device

MDR explicitly covers software when it has its own medical purpose, not only when it controls hardware. Rule 11 in Annex VIII sets the classification rules, and updated MDCG 2019‑11 guidance clarifies how this applies to modern health apps and AI tools.

Your software is very likely a medical device when it:

• Analyses data and provides information used to diagnose or rule out a disease.
• Recommends treatment, dosing, triage, or care pathways that clinicians or patients act on.
• Predicts disease risk or progression, such as stroke risk or deterioration probabilities.

Under Rule 11, diagnostic and therapeutic decision‑support software is generally Class IIa, IIb, or III depending on how serious the consequences would be if it failed, while only software with no clinical impact can remain Class I. Regulators and even app‑store operators are now instructed to look closely at these functions and the stated intended purpose.

The real cost of under‑classifying early

Labeling your product as “just wellness” or “only Class I” can feel like a smart shortcut, but guidance and case experience show it often backfires:

• Forced reclassification: Authorities use tools like the Borderline Manual and MDCG guidance to challenge weak wellness positioning, forcing manufacturers to re‑classify devices, rework documentation, and sometimes halt marketing until gaps are fixed.
• Market disruption: Health apps that actually meet the MDR definition of a medical device must obtain CE marking and meet post‑market obligations; if this is discovered late, apps can be blocked from the EU market or stores until they comply.
• Time and trust loss: Because intended purpose drives clinical evaluation, risk management, and required evidence, changing it mid‑development often means re‑doing core work and can undermine confidence from investors and partners.

In short, “we’ll figure MDR out later” often becomes “we’ll pay more and wait longer later.”

How Health Tech Pathways turns this into a clear decision

This is exactly the pain Health Tech Pathways is designed to solve.

Health Tech Pathways is a non‑profit, AI‑powered toolkit built for health‑tech and software‑driven products. It helps you use regulatory concepts like intended purpose, borderline rules, and Rule 11 as design inputs instead of last‑minute obstacles.

With Health Tech Pathways, you can:

• Test and refine your intended purpose safely
  You describe what your product does, who uses it, and how you talk about it. The platform helps you map that wording against the MDR definition of a medical device and current thinking on borderline products, so you can see clearly whether you are in wellness or medical‑device territory—and adjust before you lock in risky claims.
• See your likely MDR class, including for software
  Health Tech Pathways walks you through the Annex VIII rules in plain language, including Rule 11 for software and the latest MDCG perspectives, and shows what Class I vs IIa/IIb/III means for Notified Bodies, documentation, and timelines.
• Get a concrete roadmap, not just a verdict
  Instead of a simple “yes/no” on being a medical device, you get a tailored, step‑by‑step roadmap: which documents to create, which standards and guidance matter, and how to line up MDR work with product development and fundraising.[compliancenavigator.bsigroup]​

Because it is built specifically for health‑tech teams and SaMD, Health Tech Pathways translates dense legal text into practical next steps, turning regulatory uncertainty into a story you can confidently share with your team, your investors, and—importantly—your users.

From guesswork to strategy

Intended purpose is not a footnote; it is the strategic hinge between “interesting wellness tool” and “regulated medical product that can be trusted in care pathways.” Get it right early, and MDR becomes a demanding but navigable route. Get it wrong, and you face rework, delays, and some very tough conversations.

Health Tech Pathways exists to help you make that call with eyes open—so instead of fearing the moment your product becomes a medical device, you can use it as a deliberate step toward building something clinically credible, compliant, and genuinely impactful.