MDCG 2020-8: PMCF evaluation report template, explained

Who this applies to

You are affected if your PMS plan includes post-market clinical follow-up (PMCF) activities for a device under the MDR. MDCG 2020-8 is the reporting half of MDCG 2020-7: the plan says what you intend to do, and the evaluation report records what happened and what you learned.

The PMCF evaluation report becomes part of both the clinical evaluation report and the technical documentation. Its conclusions must feed back into the clinical evaluation, risk management, PMS plan, Summary of Safety and Clinical Performance (where applicable), and the next PMCF plan.

What the report must contain

The template deliberately mirrors the PMCF plan, so a reviewer can trace every promised activity through to a result:

Section C is the core. Create a subsection for each activity from the plan: registry, study, survey, real-world evidence analysis, literature review, or other method. Report the collected clinical data and assess its quality. If an activity was delayed, changed, abandoned, or produced less data than planned, say so and explain why.

Results, not a copy of the plan

The easiest bad PMCF report is the plan copied into past tense: "A survey was conducted. No new risks were identified." That skips the actual evaluation.

For each activity, a useful result answers four questions:

1. What happened? Give the dates, population, response or follow-up rate, dataset size, and any deviation from the protocol.
2. How good is the data? Discuss completeness, relevance, bias, missing data, and other limitations.
3. What did it show? Include positive and negative findings, not only the result you hoped for.
4. What changes because of it? State the effect on safety, performance, clinical benefit, known side-effects, emerging risks, and the benefit-risk determination.

Data from equivalent or similar devices gets its own section. Use it to check for changes in the state of the art and newly identified hazards, then explain whether these affect your device. Keep the source references visible: publications, public documents, or the relevant part of another technical record.

The technical-documentation feedback loop

Section E asks you to combine the results from all activities rather than evaluating each one in isolation. At minimum, consider the clinical evaluation report and risk management file. A finding may be individually weak but still matter when complaints, a literature signal, and a user survey point in the same direction.

The template allows you to state that no relevant CER or risk-management information was considered, but then expects an explanation of why potentially relevant information was left out. In other words, tick-boxes do not remove the need for reasoning.

The final conclusion should answer the aims in the corresponding PMCF plan, state how the findings will be used in the next clinical evaluation and risk-management update, and identify any preventive or corrective action. It may also create the questions and activities for the next PMCF cycle.

What this means for you, practically

1. Keep the activity numbering identical to the plan. If the plan says C.1, C.2, and C.3, use those identifiers in the report. Traceability should take seconds, not detective work.
2. Report deviations honestly. Low recruitment, a weak survey response, missing follow-up, or an unusable dataset is itself a result. Explain its impact and how the next cycle will fix it.
3. Show the data behind "no change". No complaints and no new risks are not the same thing as positive evidence that safety and performance remain acceptable.
4. Combine the signals. Look across your own PMCF data, similar-device data, literature, complaints, and risk controls before reaching the benefit-risk conclusion.
5. Name every downstream update. List the document, version, owner, and action for the CER, risk management, PMS plan, SSCP, labelling, CAPA, and next PMCF plan. Otherwise the report ends where the real work should start.