Is My Software a Medical Device? MDR Rule 11 Explained

Founders building health software usually ask this question the wrong way round: "is this a medical device?" as if it were a binary yes or no about the product itself. Under EU MDR, the answer turns on purpose, not technology, which is the same test at the centre of classification under MDR and FDA rules. This guide walks through the logic regulators actually use, step by step, and ends with a self-check you can run against your own product today.

In short: Under EU MDR, software is a medical device if it has a medical purpose: diagnosing, preventing, monitoring, predicting, or treating disease. Classification Rule 11 then assigns most decision-supporting software to Class IIa or higher, which means Notified Body involvement. Pure wellness, admin, or lifestyle software falls outside MDR.

The decision logic in plain language

The Medical Device Coordination Group, the body that publishes EU-wide guidance on MDR interpretation, sets out a simple test in its guidance document MDCG 2019-11 (Rev.1, March 2021): software is a medical device when it performs an action on data beyond storage, archival, communication, or simple search, and that action is for the benefit of an individual patient, for a medical purpose defined in Article 2(1) of MDR.

Two things matter in that sentence. First, "beyond storage, archival, communication, or simple search": an electronic health record system that stores and displays results is not a medical device merely for doing so. Software becomes a device candidate when it processes, analyses, interprets, or transforms data in a way that produces new clinical information. Second, "medical purpose": the software has to be intended to diagnose, prevent, monitor, predict, prognosticate, treat, or alleviate disease, injury, or disability, or to provide information by means of in vitro examination of specimens derived from the human body — and that last limb is a signpost to a different regulation entirely, covered below.

Intended purpose is the operative word, and it's defined by what the manufacturer says the software does, not by what a clinician might choose to do with it. This is why the same underlying algorithm can be a medical device in one product and not in another, depending entirely on how it's described, labelled, and marketed. Two teams could ship functionally identical code and land on opposite sides of MDR, because the line is drawn by the claim, not the classifier.

What "medical purpose" actually covers

For founders, the abstract test is less useful than the pattern-matching. A few examples that consistently land inside MDR: software that calculates a risk score used to inform a treatment decision; software that flags an abnormality in an image, ECG trace, or lab result for clinical follow-up; software that titrates or recommends a dose based on patient parameters; software that triages patients by likely severity or urgency; software that monitors a physiological parameter and alerts on a clinically significant change.

A few examples that consistently sit outside MDR: software that stores, transmits, or displays data without interpretation; general fitness or wellbeing tracking that makes no diagnostic or therapeutic claim; scheduling, billing, and administrative systems; general-purpose communication tools used in a healthcare setting, such as secure messaging.

A scope note before going further: this page covers software under the MDR. Software with an in vitro diagnostic purpose — analysing specimens such as blood, saliva, or genomic data, whether that's lab-result interpretation, assay scoring, or a companion-diagnostic algorithm — falls under the IVDR (Regulation (EU) 2017/746) instead: it classifies under IVDR Annex VIII (Rules 1–7, Classes A–D) and requires a performance evaluation rather than an MDR clinical evaluation report. If your software's information derives from in vitro examination of specimens, you are in IVDR territory, and the Rule 11 hierarchy below does not apply to it. Note also that Rule 11 covers software that is a device in its own right; software that merely drives or influences a hardware device is classified together with that device rather than on its own.

The harder cases sit in between, and they're where founders most often get the classification wrong in the direction that costs them later: a sleep-tracking app that starts recommending "possible sleep apnoea, consult your doctor" has crossed from wellness into diagnostic-adjacent territory. A symptom checker that outputs a specific likely condition, rather than general information, has done the same. The test is always what the software is telling the user to do or believe about their health, not how the interface is styled.

Rule 11: why Class I is now rare for software

Once software clears the medical-purpose threshold, MDR's Annex VIII sets out twenty-two classification rules that sort every device into Class I, IIa, IIb, or III by risk. Rule 11 is the one written specifically for standalone software, introduced with MDR to close a gap left by the previous Medical Devices Directive, under which most software defaulted to low-risk Class I.

Rule 11 works by asking what the software's output is used for, and by whom. Software intended to provide information used to take decisions with diagnostic or therapeutic purposes is classified according to the significance of that information and the state of the patient. In practice, the rule creates a hierarchy:

Software providing information that could lead to a decision causing death or an irreversible deterioration of health is Class III. Software providing information that could lead to a decision causing serious deterioration of health or requiring surgical intervention is Class IIb. Everything else that provides diagnostic or therapeutic decision-support information defaults to Class IIa, the outcome for the majority of clinical decision-support software, since most products fall into this middle band rather than the higher-severity ones. Software intended to monitor physiological processes is Class IIa, unless it monitors vital parameters where variation could pose immediate danger, in which case it's Class IIb. All other software, meaning software that has cleared the medical-purpose threshold but doesn't provide diagnostic or therapeutic decision-support information in the sense above, is Class I.

The practical consequence is the headline of this article: for most software with any genuine clinical decision-support function, Class I self-certification is no longer available. Rule 11 was written deliberately to prevent software developers from defaulting to the lightest-touch route, and it has done so. A Notified Body, an organisation designated by an EU member state to assess conformity of medium- and higher-risk devices, has to review your technical file before you can place a Class IIa device or above on the market.

One forward-looking caveat belongs next to that headline. In December 2025 the European Commission published a proposal to simplify the MDR and IVDR (COM(2025) 1023, procedure 2025/0404(COD)). Among other things it would move much stand-alone software toward Class I self-declaration and make external PRRC arrangements explicitly available to SMEs. It is a proposal, not law — adoption is realistically ~2027 at the earliest — so plan against the current rules, including today's Class IIa default, while factoring the possible change into longer-term strategy.

Worked examples across the four outcomes

Seeing Rule 11 applied to specific products is more useful than reading the rule in the abstract. A symptom-checker app that suggests possible conditions and a general urgency level, without directly recommending treatment, typically lands in Class IIa: it provides diagnostic information, but a wrong output is unlikely on its own to cause serious harm before a clinician intervenes. A dosing-calculation tool for a high-risk medication, where an error could require surgical correction or cause serious deterioration, typically lands in Class IIb. An algorithm that directly controls or closely informs treatment for an acute, rapidly progressing condition, where an error could plausibly contribute to death or irreversible harm, is a Class III candidate, and should be treated as such from the earliest design stage rather than discovered late.

At the other end, a medication reminder app that logs doses and sends notifications, without interpreting whether a dose was clinically appropriate, is Class I or arguably outside MDR entirely, since it isn't providing diagnostic or therapeutic decision-support information as Rule 11 defines it. The distinguishing question across all four outcomes is the same: what's the realistic worst-case consequence if the software's output is wrong, and how directly does that output feed a clinical decision.

Five more borderline products worth working through

The examples above cover the obvious end of the spectrum. Most founders writing to us are stuck somewhere messier, so it's worth walking through a handful of products that come up repeatedly in early regulatory conversations.

A mental health chatbot that screens for depression using a validated questionnaire, then tells the user their score and whether to "consider speaking to a professional," sits close to the line. Presenting the score with a generic prompt to seek help reads as closer to a screening tool. Naming a likely condition, or implying the tool itself assessed severity, reads as diagnostic decision support, putting it at Class IIa at minimum.

A postpartum recovery app that tracks bleeding, pain, and mood, and flags "these symptoms may indicate a postpartum complication, seek care today," has moved past tracking into interpretation with a specific clinical implication, even though the app's primary framing is wellness and recovery support.

A medication interaction checker that cross-references a patient's drug list against a known interaction database and returns "no significant interactions found" or "potential interaction, review with your pharmacist" is providing therapeutic decision support regardless of how simple the underlying logic is. Simplicity of the algorithm doesn't reduce the classification; the clinical stakes of a missed interaction do.

A digital physiotherapy app that adjusts an exercise programme based on reported pain levels sits closer to therapeutic than most founders assume, because the adjustment is a treatment decision made by software, even when the "treatment" is exercise rather than medication.

A skin-lesion photo tracker that lets a user photograph a mole over time and simply stores the images for comparison is a reasonable candidate for staying outside MDR, provided it makes no assessment of the images itself. The same product adding "this mole has changed significantly, consider a dermatology review" based on automated comparison has crossed into Rule 11 territory, likely Class IIa or above.

The pattern across all five: the deciding factor is rarely the technology's sophistication. It's whether the software forms and communicates a clinical judgment, however softly worded, rather than simply presenting data back to the user.

Borderline cases: wellness, fitness, admin tools

The gap between wellness and medical device is where most founder confusion sits, and it's worth being direct about why: the technology can be identical while the regulatory status differs entirely, because classification follows claims, not code.

A heart rate app that says "track your heart rate during exercise" is wellness. The same underlying sensor data, packaged as "detect signs of atrial fibrillation," is a medical device, and depending on the clinical significance of a missed or false detection, likely Class IIa or above. A sleep app that reports sleep stages for personal interest is wellness. The same app recommending a diagnosis or treatment pathway based on those stages is not.

This has a direct consequence for how you write marketing copy, app store descriptions, and even social media posts: regulators and courts look at the totality of what you communicate about the product, not just the formal instructions for use. A single unguarded claim in a landing page, "helps detect early signs of...", can be enough to pull an otherwise wellness product into device territory, regardless of what the terms and conditions say. If your commercial team makes claims your regulatory documentation doesn't support, you don't have a wellness product with enthusiastic marketing. You have an unclassified medical device with a marketing problem.

The reverse mistake is also common and more expensive to unwind: labelling a genuine clinical decision-support tool as "wellness" to avoid MDR doesn't change its legal status. It changes only whether you've complied with the obligations that already apply to it, which is a materially worse position to discover in due diligence or at a Notified Body audit than starting the classification conversation early. Wellness App or Medical Device? The FDA Line covers the equivalent US test, which runs on similar logic but different specific criteria.

Drift: how a compliant product becomes non-compliant without anyone deciding that

Classification is not a one-time event that stays true for the life of the product. A product can be built, classified, and launched correctly, and still drift out of alignment with its own technical file over the following year. This happens in a few predictable ways.

A feature ships that wasn't in the original intended-purpose statement. A growth experiment adds a claim the regulatory file never anticipated. A partnership or integration puts the software in front of a new user population, such as clinicians rather than consumers, changing how its output will actually be used even if the underlying code is untouched. None of these require a formal decision to reclassify, which is exactly the danger: nobody signs off on drifting out of compliance, it just accumulates in small increments across product and marketing decisions made by people who aren't thinking about Rule 11 at all.

The fix isn't bureaucratic paranoia about every change. It's a habit of checking new features and new marketing copy against your documented intended purpose before they ship, not after a Notified Body or a competitor's complaint prompts the question. Teams that treat their technical file as a living reference, revisited at each significant product or claims change, rarely get caught by surprise. Teams that treat it as a document produced once for a submission and then filed away are the ones who discover, eighteen months later, that their actual product no longer matches what they told a regulator it does.

What classification means for your cost and timeline

Classification is the fork in the road that determines almost everything that follows. Class I self-certified software can be placed on the market once you hold a compliant technical file and a declaration of conformity, with no third-party review required before launch.

Class IIa and above require a Notified Body to review your technical documentation, your quality management system, and, depending on class, sample your design and manufacturing records, before you can affix the CE mark. This adds real time and cost. A commonly cited industry range puts Class IIa–III software CE marking at roughly 12 to 18 months and an initial investment in the EUR 120,000 to 300,000 range — verify it against your own quotes rather than treating it as a benchmark — and the actual figure depends heavily on how mature your technical file and QMS already are when you start. CE Marking Cost and Timeline for Medical Software breaks this down by artefact.

The reason to get classification right early, rather than treating it as paperwork to sort out before submission, is that your class determines the shape of the entire evidence-building programme: the depth of clinical evaluation required, whether you need a formal clinical investigation or can rely on equivalence and literature, and which quality system elements a Notified Body will actually inspect.

Self-assessment checklist: three questions to work through before you commit to a path

Founders on our review panel consistently point to this section as the most useful part of this guide, so it's worth treating it as a deliberate step-by-step exercise rather than something to skim. Work through these three questions in order, in writing, before you commit to a classification path or brief anyone else on your regulatory status.

Question one: what does the output actually do? Does the software's output, whether that's a score, a flag, a recommendation, or a triage decision, get used by a clinician or patient to make a decision about diagnosis, treatment, prevention, or monitoring of a specific medical condition? Write down the exact output and the exact decision it feeds, not a general description of the feature.

Question two: what do your claims say, everywhere? Does your marketing, anywhere, on the website, in the app store listing, in a sales deck, in a customer testimonial you've published, make a claim that implies diagnostic, therapeutic, or monitoring capability beyond general wellness? Check all of these separately. It's common for the app itself to be conservatively worded while a landing page or a case study makes a claim the product team never signed off on.

Question three: what's the realistic worst case? If the software's output were wrong, what's the realistic worst-case clinical consequence: no harm, temporary harm, serious harm, or death? This question is what Rule 11 actually runs on once you've established the software has a medical purpose at all, so answering it honestly here saves a round of back-and-forth later.

Running through these three in sequence gets most founders to a reasonably confident first read of whether MDR applies and roughly where Rule 11 would land them. They won't replace a formal classification review, and the stakes of getting this wrong, either by under-classifying and building an unauthorised device, or over-classifying and over-investing in compliance you didn't need, are high enough that a second opinion is worth having before you lock your regulatory strategy.

Frequently asked questions

Can the same software be Class I in one context and Class IIa in another? Yes. Classification follows intended purpose and claims, not the underlying code. Identical sensor and analytics logic can sit in a Class I wellness product with general claims and a Class IIa or higher product with diagnostic or monitoring claims tied to a specific condition.

Does Rule 11 apply to software that only runs on a clinician's device, never a patient's? Yes. Rule 11 doesn't distinguish by which device the software runs on. What matters is the purpose of the information it provides and how significant that information is to a diagnostic or therapeutic decision, regardless of whether the end user is a clinician or a patient.

Is a clinical decision-support tool that a doctor can override still a medical device? Almost always, yes. The ability for a clinician to disregard the software's output doesn't remove its classification as a device; MDR classifies based on the information provided and its intended use, not on whether a human has final say.

What if my software has both a wellness feature and a diagnostic feature? The diagnostic feature typically determines the classification of the whole product as placed on the market, unless the two are genuinely separable, distinctly labelled, and marketed as distinct products. Bundling a device-grade feature into an otherwise wellness app doesn't shield the product from MDR.

How often should classification be revisited? Whenever you add a feature, change a claim, or expand your intended population. Classification is tied to intended purpose as documented and marketed at a point in time; a product that evolves without revisiting its technical file can drift into a higher class without anyone formally deciding that it should.

the free MedTech Compass can give you an AI-generated first read on classification in minutes. It's not a validated determination, and classification logic this consequential deserves expert review before you build a submission around it.

---

Where next: Does My Health AI Need FDA Clearance? · MDR Annex VIII: How Device Classes Are Set · CE Marking Cost and Timeline for Medical Software · When Medical Device AI Becomes High-Risk

Find out in minutes where your product likely sits. Start the MedTech Compass →