Vendor track · Module 4 · 45 min
Plan Your Conformity Strategy
How conformity assessment is structured and what it demands of a small software manufacturer: Article 52 route logic by class, technical documentation as a traceable chain, what a notified body does and does not do, and which workstreams your working position sets in motion — ending in a learner-authored Conformity Strategy Worksheet with an explicitly preliminary route hypothesis.
After this module you can
Turn a preliminary classification position into a structured conformity-strategy hypothesis: the route to investigate, the evidence workstreams it implies, and the questions only a specialist can close.
- Restate the product, intended purpose and class premise a conformity plan depends on
- Explain why CE marking is the output of a conformity process rather than its first decision
- Describe the connected system of GSPRs, technical documentation, QMS, risk, clinical evidence and post-market surveillance
- Read MDR Article 52 route logic at vendor level, including where notified-body involvement enters
- Explain what a notified body does and does not do for a manufacturer
- Describe the technical documentation as a traceable system rather than a folder
- Write a conformity-strategy hypothesis a regulatory reviewer can challenge
You now know which workstreams your working position implies. Module 5 tests the hardest of them: whether your clinical claims have the evidence to support them.
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
Start from your working position, not from CE marking
Conformity planning starts from a position, not a wish. Using your saved Module 1 profile, Module 2 purpose and Module 3 class hypothesis, write down four things: the exact function and version you are planning for, the intended-purpose wording you rely on, the qualification premise you assume, and your own preliminary class hypothesis.
Those four are premises, not confirmed facts. A plan built on an unstable premise gets re-planned — cheap now, expensive after you have committed budget and booked an assessment slot. That is why each saved artefact records which upstream version it relied on: if the facts move, your worksheet is flagged for review rather than silently rewritten.
Scope
Which product, function, version and supported configurations is this plan for? A plan for the demo is not a plan for the product.
Intended purpose
Which saved wording are you relying on? Route and evidence both follow intended purpose, so an unversioned purpose makes an unversioned plan.
Qualification premise
You are planning on the assumption that the function qualifies, and under which framework. Record the assumption instead of hiding it.
Class premise
Your own preliminary class hypothesis, with its uncertainties. The plan inherits every uncertainty in it.
Write this now
Your scope and your working premise
The first two lines of your Conformity Strategy Worksheet. Carry your own Module 2 and Module 3 wording forward.
Carry your own Module 2 and Module 3 wording forward. This is a premise, not a confirmed position.
Saved into your draft as you type. You review and save the whole artefact later in this module; nothing here is evaluated.
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