The Clinical Evaluation Report (CER) became a required part of European Union medical-device technical documentation under Regulation (EU) 2017/745, adopted on 5 April 2017 and applicable since 26 May 2021. The MDR replaced Directives 93/42/EEC and 90/385/EEC as the central framework for most devices (Regulation (EU) 2017/745).
For software manufacturers, the practical question is how to keep the CER aligned with evidence as the product and its claims change. The CER is a living document assessed by a notified body, not a one-time literature summary. This guide covers its legal basis, evidence requirements, software evaluation, equivalence, lifecycle updates and notified-body review.
The Regulatory Shift to the MDR
Under the former Medical Devices Directive framework, manufacturers commonly used MEDDEV 2.7/1 rev. 4 as the Commission's clinical evaluation guide. The MDR changed the legal footing: Article 61 requires clinical evaluation, and Article 61(12) requires its results and supporting clinical evidence to be documented in a CER included in the device's technical documentation, except for custom-made devices (Regulation (EU) 2017/745).
The MDCG issued several relevant guidance documents in 2020: MDCG 2020-1 on clinical evaluation of medical-device software, MDCG 2020-5 on equivalence, MDCG 2020-6 on sufficient clinical evidence for legacy devices, and MDCG 2020-13, the Clinical Evaluation Assessment Report (CEAR) template. These are guidance, not legislation; the MDR remains the binding framework. The European Commission's MDCG guidance list provides the official document catalogue.
In practice, the CER connects clinical evidence to the device's intended purpose, safety, performance, undesirable side effects and benefit-risk acceptability. For a software device, that connection must remain intelligible when claims, functions or evidence change. The following sections explain the evaluation plan, evidence stages, software-specific analysis, equivalence limits and the notified body's assessment.
Definitions and the Clinical Evaluation Plan
The MDR's definitions distinguish the activity from the material it evaluates. A clinical evaluation is a systematic and planned process to continuously generate, collect, analyse and assess clinical data relating to a device, and to verify its safety and performance, including clinical benefits, when used as intended (Art. 2(44)). Clinical data concern safety or performance and are generated from use of a device, including clinical investigations, other studies, scientific literature and relevant post-market information (Art. 2(48)). Clinical evidence comprises clinical data and clinical evaluation results pertaining to a device (Art. 2(51)). MDCG 2020-1 sets out these definitions in its discussion of software evaluation (MDCG 2020-1).
Article 61(1) requires the manufacturer to specify and justify the level of clinical evidence necessary to demonstrate conformity with the General Safety and Performance Requirements (GSPRs). The evaluation must be planned, conducted and documented in accordance with Article 61 and Part A of Annex XIV. MDCG 2020-6 describes sufficient clinical evidence as evidence adequate to demonstrate conformity for the device's intended purpose, taking account of its characteristics and risk profile; the notified body verifies the proposed level (MDCG 2020-6).
Annex XIV Part A Section 1(a) makes the clinical evaluation plan the acceptance framework, not an administrative preface. The CEAR template helps expose the expected planning elements (MDCG 2020-13):
Identify the GSPRs requiring support from clinical data.
Define intended purpose, target groups, indications and contraindications.
Specify clinical benefits and patient-relevant outcome parameters.
Set methods for assessing clinical safety, residual risks and side effects.
Define parameters for judging benefit-risk acceptability against the state of the art.
Set out the clinical development plan, including PMCF where applicable.
A plan that names outcomes without defining how they support a clinical claim leaves the later analysis without a meaningful test.
The Stages of Clinical Evaluation
Annex XIV Part A Section 1(b) to (e) describes an evidence process: identify relevant clinical data, appraise the data, generate new clinical data where necessary, then analyse the available data. MDCG 2020-6 section 6 expands on how those stages fit together. They are not interchangeable. A literature search identifies potential evidence; appraisal judges its quality and relevance; new data may be needed where the available evidence does not answer the plan's questions; analysis supports the conclusion.
The CER records that reasoning. It should show why data were included or excluded, how limitations affect their weight, and how the combined evidence supports or fails to support each clinical claim. A favourable result cannot stand alone if relevant unfavourable findings have been set aside. Both favourable and unfavourable data considered in the evaluation belong in the technical documentation under the MDR (Regulation (EU) 2017/745).
The CER also sits alongside relevant non-clinical testing and the wider technical documentation. A claim-to-evidence structure makes that relationship reviewable: intended-purpose statements, clinical benefits, safety endpoints, performance claims and residual risks each map to evidence and the applicable GSPR. This is especially useful when the device has several configurations or the clinical claim depends on specific input conditions. Our article on SaMD technical documentation shows where the CER sits in the wider file, and our guide to post market surveillance covers how PMS data feed back into the evaluation.
Clinical Evaluation for Software
Software evidence fails when the CER stays a template. For software and AI-enabled devices it has to operate as a living system shared by regulatory, clinical, quality and data science teams. MDCG 2020-1 describes three components for evaluating software clinical performance: valid clinical association, technical performance and clinical performance. They answer different questions. A technically functioning algorithm does not, by itself, establish that its output is clinically meaningful or that using it supports the intended clinical outcome.
| Component | What it shows | Example evidence | Source |
|---|---|---|---|
| Valid clinical association | The clinical meaning of the software output and its relationship to the condition or clinical state | Relevant scientific literature and clinical guidance | MDCG 2020-1 |
| Technical performance | Whether the software processes inputs and produces outputs as intended | Verification and validation evidence for the software function | MDCG 2020-1 |
| Clinical performance | Whether the software output achieves the intended clinical purpose in the target population | Clinical performance data relevant to the intended users, setting and population | MDCG 2020-1 |
Sources: MDCG 2020-1.
Keep these components distinct while showing how they support one another. Technical accuracy alone can leave the clinical association and clinical benefit unproven. That gap is where notified bodies tend to probe, especially when inputs, thresholds or target users differ between versions.
Release management is the control point. MDCG 2020-1 says clinical performance validation should be considered at each new software release. In practice every release needs an impact assessment that asks what changed: data, model, algorithm logic, intended purpose, users, operating environment, cybersecurity controls or labelling. A release note that says "minor model update" is not an impact assessment. If the change touches the clinical claim or the conditions under which the output is used, update the evidence plan, appraisal and conclusions.
Demonstrating Equivalence
Treat equivalence as evidence borrowed under licence: it can support a claim only while every criterion in Annex XIV Part A Section 3 of Regulation (EU) 2017/745 remains demonstrable for one named comparator. The manufacturer must compare technical, biological and clinical characteristics, device by device, and hold sufficient access to the data behind each claim. A shared indication or similar marketing language carries no weight at a notified body.
| Characteristic | MDR requirement | Software note | Source |
|---|---|---|---|
| Technical | Compare design, conditions of use and relevant technical characteristics | Algorithm, functional principle, inputs, outputs and operating conditions can affect whether evidence transfers | MDCG 2020-5 |
| Biological | Compare materials or substances in contact with the same human body tissues or fluids, where relevant | This may be inapplicable to software alone, but cannot be ignored where the device includes relevant physical components | MDR Annex XIV |
| Clinical | Compare intended purpose, clinical condition, site, population and relevant outcomes | Similar intended purpose alone does not resolve differences in users, workflow or clinical performance | MDCG 2020-5 |
Sources: Regulation (EU) 2017/745, Annex XIV Part A Section 3; MDCG 2020-5.
For software and AI-enabled devices, MDCG 2020-5 narrows the route further. Algorithms sit inside the technical comparison, so functional principle, inputs, outputs, operating conditions, training or reference data and clinical workflow all affect whether another product's evidence transfers. A model with the same intended purpose can still fail equivalence when thresholds, preprocessing, user groups or performance endpoints differ.
The legal limits are strict. Article 61(4) requires clinical investigations for class III and implantable devices unless an exemption in Article 61(4) to (6) applies. Where a manufacturer of a class III or implantable device relies on equivalence to another manufacturer's device in order not to perform a clinical investigation, Article 61(5) requires a contract that explicitly allows full access to that device's technical documentation on an ongoing basis. MDCG 2020-6 also confirms that the Article 61(10) route is not available for class III and implantable devices. Equivalence therefore demands full data access, demonstrated criteria and compliance with the applicable investigation requirement before it can carry any clinical claim.
A Worked Example for a Software Device
Hypothetical example: a Dutch company develops software that flags possible atrial fibrillation in ECG recordings for cardiologists. This example does not assign a device class or reach a conformity conclusion.
The clinical evaluation plan, under Annex XIV Part A Section 1(a), defines the intended purpose, target population, clinical benefits, outcomes and methods for assessing safety. The manufacturer then supports valid clinical association with relevant literature and guidelines, technical performance with verification and validation, and clinical performance with a study using data from the target population, in line with MDCG 2020-1 section 4.4.1.
Equivalence is relevant only if the company can meet all Annex XIV Part A Section 3 criteria and obtain sufficient access to the other device's data. If PMCF is appropriate, its plan should be developed with the applicable guidance, including MDCG 2020-7. The notified body assesses the CER using MDCG 2020-13. No performance metrics, class or conclusion can be supplied without evidence specific to the hypothetical device.
Legacy Devices and the Notified Body Assessment
MDCG 2020-6 addresses sufficient clinical evidence for legacy devices under the MDR. MEDDEV 2.7/1 rev. 4 remains pre-MDR guidance and may inform work where it aligns with the current framework, but it does not override the Regulation. MDCG 2020-5 section 1 and MDCG 2020-6 Appendix I make that relationship clear (MDCG guidance list).
The CEAR template in MDCG 2020-13 applies to notified-body assessment under Annex IX Section 4 and Annex X Section 3. Its sections A to K give reviewers a structured way to assess the clinical evaluation. That assessment includes whether the CER is consistent with the latest PMS and PMCF reports, and whether its conclusions follow from the evidence presented.
The MDR does not establish a universal fixed interval for updating every CER. MDCG 2020-13 instead has the notified body set when updates will be assessed. For a software device, the review should also consider whether product changes or new evidence affect the existing clinical conclusions. Using the CEAR as a drafting checklist helps identify gaps before the assessment, without mistaking a completed template for a sufficient evaluation.
Conclusion
The MDR makes the CER part of the device's technical documentation and ties it to the evidence supporting safety, performance and clinical benefit. For software and AI-enabled devices, that evidence has to remain connected to the product's intended purpose and actual clinical use. A literature review can contribute to the evaluation, but it cannot substitute for a reasoned assessment of device-specific evidence, limitations and residual uncertainty.
Equivalence deserves particular caution. The MDR's criteria, the need for access to relevant data and the specific characteristics of software mean that similarity in intended purpose is not enough. In our view, manufacturers should plan for their own evidence unless equivalence can be demonstrated in full. MDCG 2020-13 is useful as a CER checklist, while release planning should include an assessment of whether software changes affect clinical performance evidence.
A CER also needs lifecycle governance. PMS and PMCF outputs, risk-management conclusions, labelling and software changes should remain consistent with the evaluation, and the notified body determines when it will assess updates. MDCG guidance continues to develop, so the legal requirements and the current guidance should be checked together rather than treating older practice as a safe default. The MDR applies to medical devices in scope; performance evaluation for in vitro diagnostic devices is addressed separately under the IVDR, including Article 56.
Our guide to CE marking for medical devices shows where the CER fits in the conformity assessment. If you need support planning clinical evidence or preparing a CER, our regulatory strategy team can help, or contact MedQAIR.
Frequently asked questions
Can software claim equivalence?
Yes, but only where the manufacturer demonstrates the MDR's technical, biological and clinical criteria and has sufficient access to the relevant data. The software-specific comparison is addressed in MDCG 2020-5.
When is a clinical investigation required?
Article 61(4) requires clinical investigations for class III and implantable devices, subject to the exemptions in Article 61(4) to (6). The applicable provision is in Regulation (EU) 2017/745.
Is MEDDEV 2.7/1 rev. 4 still valid?
It is pre-MDR guidance, not law, and may be used where it aligns with the MDR. Where there is a conflict, the Regulation prevails, as explained in MDCG 2020-6.
How often is a CER updated?
The MDR does not prescribe one universal CER update interval. MDCG 2020-13 provides for the notified body to set when updates are assessed, and the manufacturer must keep the evaluation aligned with relevant lifecycle evidence under MDCG 2020-13.
What is a CEAR?
A CEAR is the Clinical Evaluation Assessment Report template used by notified bodies to document their assessment of the clinical evaluation. Its application to the relevant conformity-assessment routes is set out in MDCG 2020-13.
