Under the MDR, clinical evaluation is "a systematic and planned process" (Article 2(44)), and Annex XIV Part A Section 1(a) requires the manufacturer to establish and update a clinical evaluation plan (CEP). The notified body later judges the clinical evaluation report against that plan, so a gap in the plan becomes a gap in the evidence.
This article explains what a CEP must contain, how software evidence is planned per claim, how the plan links to PMCF and risk management, and what the notified body checks. It covers the MDR only; an IVDR performance evaluation plan is a separate document.
What the plan must contain
Article 61(1) requires the manufacturer to specify and justify the level of clinical evidence needed to show conformity with the relevant general safety and performance requirements (GSPRs). Annex XIV Part A Section 1(a) lists what the plan must include:
| Element | What the CEP states | Software note |
|---|---|---|
| GSPRs requiring clinical data | Each GSPR that needs clinical evidence | Include software GSPRs that depend on performance data |
| Intended purpose | The intended purpose of the device | Describe the clinical task the software performs, not only its function |
| Target groups | Intended target groups, with clear indications and contraindications | Name the indication each claim supports |
| Clinical benefits | Intended clinical benefits, with relevant and specified outcome parameters | Plan each indication and benefit on its own parameters |
| Clinical safety | Methods to examine qualitative and quantitative aspects of clinical safety, including residual risks and side-effects | Link to the software risk management file |
| Benefit-risk | Parameters used to determine the acceptability of the benefit-risk ratio, based on the state of the art | Use the state of the art for the software's clinical task |
| Pharmaceutical and tissue components | How benefit-risk issues of such components are addressed, where relevant | Usually not applicable; say so explicitly |
| Clinical development plan | Progression from exploratory investigations to confirmatory investigations and PMCF, with milestones and acceptance criteria | Set milestones per claim |
Sources: MDR Annex XIV Part A Section 1(a); MDCG 2020-13.
MDCG 2020-13 (July 2020) is the clinical evaluation assessment report (CEAR) template that notified bodies use. Its Section C covers the device description, classification and the clinical evaluation plan. It is guidance, not law, but it shows how the plan will be read.
In our view, keep rows that do not apply in the plan and state why. A blank row looks like an unfinished plan, not a reasoned exclusion.
The results of the evaluation are documented in the clinical evaluation report. Our article on the clinical evaluation report covers that document.
Software: evidence per claim
Article 2(53) defines clinical benefit as the positive impact of a device on the health of an individual, expressed as meaningful, measurable, patient-relevant clinical outcomes, including outcomes related to diagnosis, or a positive impact on patient management or public health.
According to MDCG 2020-1 (March 2020), the guidance on clinical evaluation of medical device software:
the benefit of software may lie in providing accurate medical information on patients;
each indication and claimed clinical benefit should be assessed individually;
where software does not claim measurable patient-relevant outcomes, clinically relevant outputs are shown through predictable and reliable use and usability.
MDCG 2020-1 sets out three components of clinical evidence for software:
| Component | What the CEP plans | Example evidence |
|---|---|---|
| Valid clinical association | The link between the software output and the clinical condition | Literature, professional guidelines, proof-of-concept studies |
| Technical performance | That the software reliably and accurately generates the intended output | Verification and validation records, curated databases |
| Clinical performance | That the software yields clinically relevant output in the target population | Retrospective or prospective study on target-population data |
Source: MDCG 2020-1, sections 4.1 to 4.4.
Some specific points from MDCG 2020-1:
Software that drives a device without its own medical purpose is evaluated together with the device it drives (Table 1).
Module-level validation of clinical performance is allowed when a module's function is independent of other modules (section 4.4).
Validation of clinical performance should be considered at each new software release; if it is not done, the technical documentation should give a justification (section 4.4).
Retrospective studies can be appropriate where there is no impact on patient management, provided the data come from the target population in sufficient amount and quality (section 4.4.1).
In our view, every claim in the plan should name its evidence component, its data source and its population. If one of the three is missing, the claim is not yet planned. Our article on software as a medical device covers qualification and classification.
Linking the plan to PMCF and risk management
Annex XIV Part A requires the clinical evaluation to be updated throughout the life cycle with data from the PMCF plan and the post-market surveillance plan (Article 84). A plan that stops at pre-market validation is incomplete where open questions remain.
MDCG 2020-7 (April 2020) is the PMCF plan template. It has sections A to G, and:
activity timelines are to be defined quarterly or at least yearly;
Section D refers back to the clinical evaluation report and the risk management file;
for implantable and class III devices where clinical investigations were not performed under Article 61(4), the PMCF plan must include post-market studies.
On the risk side, MDCG 2020-6, section 6.1, addresses establishing or updating the CEP. Where the manufacturer argues under Article 61(10) that clinical data are not appropriate, MDCG 2020-1 (section 4.4.2) says the justification must be based on the output of the risk management process.
In our view, for each residual uncertainty, record the PMCF activity and the risk file entry that addresses it. Our articles on the post-market surveillance plan and state of the art cover two of these inputs.
What the notified body checks
Under MDR Annex VII Section 4.6, the notified body reviews the manufacturer's clinical evaluation. That review covers the adequacy of the benefit-risk determination, the risk management, the instructions for use, user training, the post-market surveillance plan and the PMCF plan.
The CEAR template structures this review:
| CEAR section | Content |
|---|---|
| C | Device description, classification and clinical evaluation plan |
| F | PMS, PMCF and the plan for updates |
| H | Summary of all available data and conclusions, including whether risk management and clinical evaluation are aligned |
Source: MDCG 2020-13.
The sources set no fixed review interval for the plan, so the plan has to set its own triggers:
new clinical data, as part of continuous update (MDCG 2020-1, section 4.6);
each new software release, where clinical performance validation should be considered (section 4.4);
a change to the design, intended purpose or indications.
In our view, write and version the CEP before clinical data are gathered, and tie its review to the software release process.
A hypothetical example
Hypothetical example: a Dutch company markets software that flags suspected pneumothorax on chest X-rays for radiologists. Classification is not covered here.
GSPRs: the plan names the Annex I requirements that depend on the diagnostic output, tied to the claim that the flag supports the radiologist's read.
Intended purpose and users: the user is the radiologist and the input is a chest X-ray. The plan states which populations and acquisition settings are excluded.
Clinical benefit and outcome parameters: the benefit is accurate information on a suspected pneumothorax. Outcome parameters include diagnostic sensitivity and specificity, which MDCG 2020-1 lists for clinical performance.
Residual risk: a missed finding is taken from the risk management file, with the control that the radiologist remains responsible for the final read.
Clinical development plan: a retrospective study on data from the intended population first, then PMCF using real-world performance data, with acceptance criteria set before the data are seen.
Conclusion
The CEP is a legal requirement under Annex XIV Part A, and the notified body reads the clinical evaluation against it. For software, the plan works best when every claim has its own evidence component, data source and population.
In our view, write and version the plan before data are gathered, link it to the PMCF plan and the risk file, and review it with each software release.
If you need help preparing a clinical evaluation plan, our clinical writing team can help, or contact MedQAIR.
Frequently asked questions
What is the difference between a CEP and a CER?
The plan states how the clinical evaluation will be carried out. The report documents the results and the clinical evidence. Both are required under Annex XIV Part A.
Is a CEP needed if the manufacturer relies on Article 61(10)?
Yes. A clinical evaluation is still required, and the plan records the route. According to MDCG 2020-1, the justification must be based on the output of risk management.
Can the CEP be updated after the CER is written?
Yes. Annex XIV Part A requires the plan to be established and updated through the life cycle. Each version should have a reference, version and date.
Does a legacy device need a CEP?
Yes. MDCG 2020-6 Appendix II describes a clinical evaluation plan for legacy devices.
Does every software release require new clinical data?
Not necessarily. MDCG 2020-1 says validation of clinical performance should be considered at each new release, and if it is not done, a justification should be documented.
