Vendor track · Module 5 · 45 min
Build Your Clinical Evidence Plan
Claim → evidence → gap → action, claim by claim: valid clinical association, technical and analytical performance, clinical performance, what literature and internal validation can and cannot carry, prospective and live evidence, and how to name a gap precisely enough to fund it — ending in a learner-authored Clinical Evidence Plan.
After this module you can
Turn the claims your company actually makes into an evidence plan: what each claim would need, what you already have, where the gap is, and what you would do about it.
- Explain why clinical evaluation is tied to the intended purpose and the claims, not to a document template
- Separate technical, clinical-association, workflow and clinical-benefit claims
- Describe what a software function's evidence has to support to be credible
- Judge whether existing evidence fits the claim as written
- Name the specific gap between a claim and its evidence
- Write an evidence action with an owner and an acceptance criterion
- Recognise post-market evidence as part of the plan rather than an afterthought
You now have an MDR/IVDR evidence story tied to your claims. Module 6 adds the AI Act layer on top of it — a separate set of questions that reuses some of this work and creates obligations of its own.
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
Evidence follows the claim, not the product
The whole module in one line: your evidence has to reach the claim you are making, in the population and setting you are making it about. Claim → evidence → gap → action is the structure you will fill in for every material claim.
Clinical evaluation is not a document you file once. Under the MDR it is a planned, continuous process: define what must be demonstrated, appraise and analyse the available clinical data, decide whether it is sufficient for the claims and intended purpose, and keep doing that across the product's life using post-market data. Unfavourable data counts — an evaluation that cites only supportive literature is not an evaluation, and the omission is visible.
How much evidence is enough is proportionate, not fixed: it depends on the device, its intended purpose, the claims, the risk and the state of the art. For medical device software, MDCG 2020-1 frames it as three connected things, in the guidance's own terms: valid clinical association (scientific validity) — the link between the output and the clinical condition; technical performance and analytical performance — whether the software correctly and reliably generates the intended output from its inputs; and clinical performance — whether that output achieves the intended purpose in the intended context. The guidance is more nuanced than any three-box diagram and is not binding law, but a product can be technically excellent and still fail the third question.
Valid clinical association (scientific validity)
Is there a valid clinical association — an accepted scientific basis — between the inputs used and the clinical concept the output refers to?
Technical and analytical performance
Does the software generate the intended output correctly, repeatably and within its specified limits, from the inputs it is intended to accept?
Clinical performance
In the intended population, setting and workflow, does the output deliver what the intended purpose claims?
Write this now
What this plan is written against
The opening of your Clinical Evidence Plan: the function and version, the intended-purpose wording it relies on, and why you treat these claims as the material ones.
Material claims are the ones a user, buyer or patient could reasonably rely on.
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