Vendor track · Module 3 · 45 min
Understand Your Likely Classification
How MDR classification is reasoned and documented: intended purpose governs classification, independent software is classified in its own right, the strictest applicable rule wins, Rule 11(a) decision impact, Rule 11(b) monitoring, the narrowness of 11(c), competing rules and linked devices — ending in a learner-authored preliminary classification position, never an automated class.
After this module you can
Reason and document a preliminary classification position that a regulatory specialist can review — instead of asserting a class.
- Explain why classification starts only after the qualification question is stable
- Apply the MDR Annex VIII classification principles, including the strictest-rule principle
- Use Rule 11(a) for information used to take diagnostic or therapeutic decisions
- Reason about escalation through decision impact rather than a generic severity label
- Use Rule 11(b) for monitoring, and recognise the vital-parameter branch
- Recognise why genuine class I clinical software is narrower than many startups assume
- Spot competing rules and device-linkage principles
- Write a reviewable classification rationale with assumptions and uncertainties
Conformity routes, evidence, the AI Act layer and quality management systems (QMS) are planned for later modules and are not yet released.
This course is educational decision support for vendors and is not legal advice. It structures regulatory reasoning and produces learner-authored working positions. It does not tell you whether your product is a medical device, whether MDR or IVDR applies, what class it is, which conformity route applies, whether a notified body is required, or whether your AI system is high-risk under the AI Act, and it produces no compliance or readiness score. It does not replace a competent regulatory review. MDCG and AI Board guidance is cited throughout because it is the practical reference practitioners use, but it is not binding law: only the regulations themselves bind, and only the Court of Justice of the European Union gives binding interpretations of them. Regulatory basis reviewed: 18 September 2026.
Step 1
How classification is actually reasoned
A common startup shortcut is to ask “are we Class IIa?” before the boundary and intended purpose are stable. That reverses the legal sequence: the MDR classification rules are applied according to intended purpose, so if the purpose changes, the applicable rule or class can change with it.
Independent software is classified in its own right. Software that drives or influences another device can follow the class of that device. Accessories are classified separately. Where several rules or sub-rules apply, the strictest rule producing the higher classification applies. Those implementing rules are why a one-question “Rule 11 calculator” is not enough for a real product.
Using your saved Module 1 profile and Module 2 purpose, state the premises first: which function you are classifying, which purpose wording you rely on, which qualification premise you assume, which supported configurations are included and what is linked. If a premise is unstable, the class is unstable too.
Intended purpose governs
Classification rules are applied according to the intended purpose of the device. Change the purpose and the applicable rule can change.
Software in its own right
Independent software is classified in its own right. Software that drives or influences a device can follow that device; accessories are classified separately.
Strictest rule wins
Where several rules or sub-rules apply, the strictest rule resulting in the higher classification applies.
Premises before conclusions
A class is only as stable as the boundary, intended purpose and qualification premise it rests on. State them first.
0 of 7 steps complete
- A · Product boundary — Not written yetNot written yet
- B · Workflow and context — Not written yetNot written yet
- C · Claims inventory — Not written yetNot written yet
- D · Draft intended purpose — Not written yetNot written yet
- E · Qualification assessment — Not written yetNot written yet
- F · Classification position — Not written yetNot written yet
- G · Conformity strategy — Not written yetNot written yet
- H · Clinical evidence plan — Not written yetNot written yet
- I · EU AI Act overlay — Not written yetNot written yet
- J · QMS and lifecycle plan — Not written yetNot written yet
Your own writing, section by section. Nothing here is scored, and no section states device status, a class, a route or readiness.
Sources & evidence · 8 sources
This module cites primary legal, public or consensus guidance.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
Regulation (EU) 2017/745 (MDR), consolidated text 02017R0745 — 19.07.2026
Article 2(1) and 2(12) definitions; Article 10 manufacturer obligations; Article 15 PRRC; Article 52 and Annexes IX–XI conformity assessment; Article 61 and Annex XIV clinical evaluation; Annex II technical documentation; Annex VIII implementing rules and Rule 11.
Open sourceRegulation (EU) 2017/746 (IVDR), consolidated text 02017R0746 — 10.01.2025
Article 2(2) in-vitro diagnostic definition and Article 2(4) accessory definition.
Open sourceRegulation (EU) 2024/1689 (AI Act), consolidated text — 27.07.2026
Article 3 definitions and actor roles, Article 6 high-risk classification routes, Articles 8–15 requirements for high-risk AI systems, Article 25 value-chain responsibilities and the transitional provisions.
Open sourceMDCG 2019-11 rev.1, Qualification and Classification of Software in MDR and IVDR — June 2025
Figure 1 and Figure 2 decision sequences, §3.1–3.3, §4.2.1, Annex II examples and Annex IV classification examples.
Open sourceMDCG 2021-24 rev.1, Guidance on classification of medical devices — April 2026
Supplementary Rule 11 teaching examples. Used as illustrative context, not as a determination.
Open sourceMDCG 2020-1, Clinical evaluation of medical device software
Valid clinical association, technical performance and clinical performance as the structure of a software evidence plan.
Open sourceMDCG 2025-10, Post-market surveillance guidance
Used for the surveillance, PMCF and vigilance loop taught in Module 7.
Open sourceMDCG 2025-6 / AIB 2025-1, interplay between the MDR/IVDR and the AI Act
Used for how the two frameworks sit alongside each other, including integrated documentation and conformity work.
Open source