1. What counts as a medical device under EU MDR?
Under EU MDR 2017/745, software qualifies as a medical device when it is intended by the manufacturer to be used for a medical purpose — specifically for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. The key word is intended: it is your intended use statement, not the technical capability of the software, that triggers the regulation.
Software that drives or influences the use of a hardware medical device is automatically considered a medical device accessory and must comply with MDR regardless of its standalone classification.
General-purpose software — even when used in a clinical environment — is not a medical device unless it has a specific medical intended use. A spreadsheet used to track patient appointments is not a medical device. The same spreadsheet with a built-in algorithm that recommends treatment options based on patient data likely is.
2. Rule 11 — the classification logic
Once you have established that your software is a medical device (SaMD — Software as a Medical Device), Rule 11 of Annex VIII determines its risk class. The logic follows three questions:
Step 1: What is the purpose of the information provided?
Does the software provide information used to make decisions with diagnosis or therapy implications? If yes, proceed to Step 2. If the software merely stores, archives, or transmits data without interpretation, it is generally Class I.
Step 2: What is the severity of the condition?
Rule 11 distinguishes between three severity levels: serious / life-threatening conditions (Class IIb), conditions requiring major therapeutic intervention (Class IIa), and conditions not serious or requiring minor intervention (Class I / IIa depending on diagnosis or monitoring purpose).
Step 3: Is it diagnosis or monitoring?
Software intended to provide diagnosis is typically one class higher than software intended only for monitoring the same condition. A system that diagnoses arrhythmia is Class IIb; a system that monitors heart rate trends in already-diagnosed patients may be Class IIa.
Many startups underclassify their software by writing an intentionally vague intended use statement. Notified Bodies review the actual clinical workflow and marketing materials — not just the IFU. If your product is marketed as a diagnostic tool, it will be assessed as one.
3. Common grey areas
These are the software categories where classification is most frequently disputed:
- AI/ML diagnostic tools — if the algorithm outputs a clinical recommendation (even with a disclaimer "for physician review only"), it typically qualifies as Class IIa or IIb depending on the indication.
- Clinical decision support (CDS) — CDS that aggregates data and surfaces insights without making a recommendation may be Class I. CDS that scores risk and recommends a specific intervention is Class IIa minimum.
- Wellness and lifestyle apps — apps that claim to measure physiological parameters (heart rate, SpO2, sleep quality) for health monitoring purposes are increasingly scrutinised by competent authorities. Several national authorities have issued warnings to app stores.
- Digital therapeutics (DTx) — software delivering a therapeutic intervention (CBT-based mental health, chronic pain management) falls under Rule 11 if the therapeutic effect is the primary intended purpose.
If you are unsure about your classification, request a formal opinion from the competent authority in the country where you plan to first place your product on the market. This costs nothing in most EU member states and gives you a documented justification for your technical file.
4. Documents you need
Your classification decision must be documented and justified in your Technical Documentation (Annex II). At minimum you need:
- Intended use statement — specific, unambiguous, covering indication, target patient population, user, and clinical environment
- Classification rationale — explicit reference to Rule 11, the classification path taken, and why alternative classifications were rejected
- MDCG guidance reference — MDCG 2019-11 (qualification and classification of software) is the primary reference document; cite it explicitly
- Equivalent device analysis (if applicable) — if you are claiming equivalence to a predicate device, document the technical, biological, and clinical equivalence
5. Next steps
If your classification exercise confirms that your software is a Class IIa or IIb medical device, your immediate next steps are: appointing a Person Responsible for Regulatory Compliance (PRRC), initiating your Quality Management System under ISO 13485, and selecting a Notified Body early — NB capacity is currently constrained across the EU, with lead times of 6–18 months for initial certification.
If you are still uncertain about your classification after working through Rule 11, the most efficient path is a short scoping session with a regulatory consultant before committing development resources to a compliance programme that may be either insufficient or unnecessary.
