The Clinical Evaluation Section of Your Technical File

Why Section 6 is where most technical files struggle

Section 6 of Annex II covers clinical evaluation and post-market performance follow-up. In terms of Notified Body scrutiny and finding frequency, it is the most consequential part of the technical file. That is not because the requirement is unclear — the MDR and the MDCG guidance are fairly explicit about what is needed. It is because meeting the requirement in full is genuinely hard work, and teams often underestimate how device-specific the evidence needs to be.

The clinical evaluation section of the technical file is not just a container for the Clinical Evaluation Report (CER). It needs to contain the full CER, the PMCF plan, the PMCF evaluation report (once data is available), and — for Class III and implantable devices — the Summary of Safety and Clinical Performance (SSCP). These documents do not just need to exist; they need to be current, internally consistent, and connected to the rest of the technical file in ways an auditor can follow.

What Section 6 must contain

The Clinical Evaluation Report (CER) The CER is the main document. It needs to present the clinical evidence that demonstrates the device's safety, performance, and benefit-risk profile for its intended purpose. The key word is device-specific: generic technology reviews or literature summaries that describe a procedure without tying evidence to the specific device being evaluated are consistently flagged.

The CER must address:

• The intended purpose and claimed indications for use — these must match Section 1 of Annex II exactly
• The clinical evidence base — whether from clinical investigations, literature, or an equivalence claim
• An assessment of the clinical evidence against the GSPRs that have a clinical dimension (particularly GSPR 1 on benefit-risk)
• An explicit benefit-risk conclusion: why the clinical evidence supports a positive benefit-risk determination for this device

If your clinical evaluation relies on equivalence, the equivalence claim must be fully substantiated. Under MDR, equivalence requires that the comparator device is technically, biologically, and clinically equivalent — and for Class III devices and implantables, the manufacturer must have a contract allowing access to the comparator's technical documentation. This requirement has blocked a significant number of submissions where manufacturers had planned to use a competitor's device as their equivalent.

The PMCF plan The PMCF plan sets out how you intend to collect clinical data on the device after market introduction. It needs to be specific — not a general statement that you will monitor the device, but a description of the methods, timelines, and acceptance criteria. Notified Bodies have become increasingly critical of PMCF plans that consist of a single paragraph explaining that the manufacturer will review complaint data and literature. That approach does not meet the expectation, and at surveillance audits the Notified Body will look at whether the planned activities have actually been executed.

The PMCF evaluation report Once data collection is underway, the PMCF evaluation report documents what the data showed and whether it changed the benefit-risk picture. If you are at first submission, you will not yet have this. But if you are at a surveillance audit and your PMCF plan committed to specific activities within a certain timeframe, expect to be asked for the evaluation report. Absence of the report when it should exist is a finding.

The Summary of Safety and Clinical Performance (SSCP) Required for Class III devices and implantables. The SSCP is a publicly accessible document on EUDAMED and must be written in plain language accessible to lay persons. The SSCP must be part of the technical file. If the SSCP has been published on EUDAMED but the version in the technical file is out of date, that is an inconsistency.

How Section 6 connects to the rest of the technical file

The clinical evaluation does not stand alone in the technical file — it draws on and feeds into multiple other sections. These connections are where a lot of files fall apart:

Connection to Section 1 (device description) The intended purpose and indications in the CER must match the device description and specification in Section 1 exactly. If there is any drift — different terminology, a broader indication in the CER than in the device description, a contraindication in the IFU that does not appear in the CER's stated limitations — the inconsistency will be flagged. Both sections often go through separate revision cycles, and this is the most common source of internal inconsistency in the technical file.

Connection to Section 4 (benefit-risk and risk management) The CER benefit-risk conclusion must be grounded in the residual risk data from the risk management file. The clinical benefits documented in the CER need to be weighed against the residual risks documented in the risk management report. If the CER presents a benefit-risk conclusion that does not reference the risk management file's residual risk picture, the connection is missing. Auditors looking at Section 6 will check whether the benefit-risk analysis is substantiated by Section 4, not just asserted.

Connection to the GSPR matrix (Section 3) Several GSPRs have a clinical dimension — particularly GSPR 1 (benefit-risk), GSPR 5 (elimination and minimisation of risks), and GSPR 6 (risks from use errors). The GSPR matrix entries for these requirements should reference the CER as part of the evidence base. If the GSPR matrix and the clinical evaluation tell different stories about the benefit-risk picture, that is a finding.

The update requirement — keeping Section 6 current

One of the sharpest differences between MDD and MDR practice is the expectation that the clinical evaluation is continuously updated. Under MDR, the CER must be updated whenever the post-market surveillance system generates new relevant clinical data. This is not a bureaucratic formality — it is the mechanism by which the technical file reflects the current benefit-risk picture of the device in the real world.

In practice, this means that every PSUR preparation should include a review of the clinical evaluation summary. If post-market data is consistent with the pre-market CER, document that review and its conclusion. If post-market data changes the picture in any way — new adverse events, new evidence in the literature, a PMCF finding that was not anticipated — the CER needs to be updated, and the benefit-risk conclusion needs to be re-examined.

The most common failure here is that the CER stays at version 1 while the post-market data accumulates. By the time a surveillance audit comes around, the CER is two or three years old and does not reference any post-market data. That is a finding — and not a minor one.

Practical approach for teams building or updating Section 6

If you are building Section 6 from scratch, start by locking the intended purpose in Section 1 first, then ensure the CER is written to that intended purpose. Build the PMCF plan at the same time — do not treat it as an afterthought to the CER.

If you are reviewing an existing technical file: check the date of the last CER revision and compare it against when the last PSUR was produced. If the PSUR is more recent than the CER, ask whether the PSUR contained any data or conclusions that should have triggered a CER update. Then check the version alignment between the CER and the risk management file — these two documents need to be in sync on residual risk and benefit-risk terminology.