EU MDR Post-Market Surveillance: PMS Plan, PSUR and PMCF Requirements

Introduction

Post-market surveillance is where the EU MDR departs most sharply from the Directive it replaced. Under the MDD, PMS was a general obligation with no defined deliverables. Under the MDR it is a documented system with named outputs, fixed frequencies, and mandatory feedback into the clinical evaluation and the risk management file.

The gap between what the Regulation asks for and what most manufacturers have in place is widest here, and the reason is structural rather than technical. PMS is the only part of the technical documentation that never finishes: it has to be resourced and run for as long as the device is on the market, and a system built to pass certification will not survive its first surveillance audit two years later.

This guide covers the articles that create the obligations, what the PMS plan must contain, which report each device class produces and how often, the PMCF requirements that generate the most findings, and how the whole system feeds back into the rest of the file.

Table of Contents

• What the MDR requires, article by article
• The eight things PMS data must be used for
• The PMS plan
• PMSR or PSUR: which report, which class, how often
• The Post-Market Surveillance Report
• The Periodic Safety Update Report
• Post-Market Clinical Follow-Up
• The PMCF plan
• The PMCF report
• The Summary of Safety and Clinical Performance
• How PMS connects to the rest of the file
• The audit findings that recur
• Building a system that works
• Frequently asked questions
• Conclusions

What the MDR requires, article by article

The obligations are spread across five articles and two annexes, which is part of why they are so often assembled incompletely.

Vigilance and PMS are separate systems that share data. Vigilance is event-driven, with reporting deadlines measured in days. PMS is continuous and analytical, with outputs measured in years. The thresholds that trigger a vigilance trend report are not the same as the indicators that trigger a PMS signal investigation, and a plan that treats them as one set has under-specified both.

The eight things PMS data must be used for

Article 83(3) is the most operationally useful provision in the whole chapter and the one least often reproduced. It states what the data gathered by the PMS system shall be used for — and each item is a place a reviewer can look for evidence that the loop actually runs.

Read as a checklist, this is the fastest self-assessment available. A PMS system that collects data diligently and produces a report every year, but cannot show an instance of items 2, 6 or 7, is a reporting system rather than a surveillance system — and the distinction is exactly what a surveillance audit is looking for.

The PMS plan

The PMS plan is the foundation of the system and part of the technical documentation under Annex III. It has to exist before the device is placed on the market, and it has to be device-specific — a template applied unchanged across a product range is the single most common finding on this subject.

PMSR or PSUR: which report, which class, how often

This is the question the page is most often opened for, and the answer is determined entirely by class.

The distinction that costs the most is between implantable and non-implantable Class IIb. Both produce an annual PSUR; only the implantable one is submitted through EUDAMED and reviewed. A manufacturer that treats its implantable Class IIb device as a hold-and-produce-on-request case has a submission obligation it is not meeting.

The Post-Market Surveillance Report

The PMSR is the Class I output. It is simpler than a PSUR and it is not a memo: it summarises the results and conclusions of the analysis of the PMS data collected under the plan, sets out the rationale and description of any preventive and corrective actions taken, and confirms that the benefit-risk determination remains acceptable.

It is updated when necessary rather than on a fixed cycle, and made available to competent authorities on request. “When necessary” is a decision the manufacturer has to be able to defend, which means the PMS plan should state what would make an update necessary rather than leaving the judgement undocumented.

The Periodic Safety Update Report

The PSUR is the comprehensive output for Class IIa and above. Article 86 sets the mandatory content, and MDCG 2022-21 provides the template against which most Notified Bodies now read it.

The sales volume and population estimate is the section most often left thin, and it is load-bearing: without a denominator, a complaint count is a number rather than a rate, and no trend can be established from it. This is also the section that makes the PSUR useful internally rather than only to the reviewer.

Post-Market Clinical Follow-Up

PMCF is the clinical half of surveillance and the element that generates the most major findings in Notified Body surveillance audits. It is defined in Annex XIV Part B as a continuous process in which the manufacturer proactively collects and evaluates clinical data from devices already on the market, in order to confirm safety and performance across the expected lifetime, identify previously unknown side-effects, and confirm that the benefit-risk ratio remains acceptable.

It must be addressed in the PMS plan for every class. For Class IIb and III a PMCF plan and report are in practice always required; for Class I and IIa a plan is required unless the manufacturer documents a justification for why PMCF is not applicable.

The PMCF plan

Write the PMCF plan as if it were a study protocol. A reviewer’s test is whether an independent party could execute it from the document: named databases, search terms, inclusion and exclusion criteria, sample sizes, analysis method. A plan that says literature will be reviewed annually has not specified an activity, it has expressed an intention.

The PMCF report

The PMCF evaluation report presents the results of the activities conducted, evaluates whether the objectives in the plan were met, draws clinical conclusions, and defines what further activity is needed. Its findings then travel: the main ones into the PSUR, the clinical conclusions into the clinical evaluation report, and any new hazard or changed risk estimate into the ISO 14971 risk management file.

Where a PMCF activity found nothing, the report says so and explains what that means. A report that presents only confirmatory findings, with no gaps and no limitations, invites the question of what the activity was capable of detecting.

The Summary of Safety and Clinical Performance

For Class III and implantable devices the MDR requires a public-facing document under Article 32: the SSCP, validated by the Notified Body and published on EUDAMED so that patients, clinicians and other stakeholders can read it.

It must be written in language a non-specialist can follow, and cover the device description and intended purpose, indications and contraindications, the target population, a summary of the clinical evidence, residual risks and undesirable effects, recommendations for follow-up, the suggested user profile, and the harmonised standards and common specifications applied.

Its update is part of the PSUR cycle. Where a PSUR changes the benefit-risk determination or the clinical conclusions, the SSCP has to move with it, and an SSCP on EUDAMED that predates the most recent PSUR is a visible inconsistency — visible to the public as well as to the reviewer.

How PMS connects to the rest of the file

PMS is the mechanism that keeps the technical documentation current. Five connections carry the traffic.

• Risk management file. New hazards, changed probability estimates and evidence that a control is insufficient all feed back under ISO 14971 clause 10, and the overall residual risk is re-evaluated.
• Clinical evaluation report. PMS and PMCF data update the clinical evaluation across the lifecycle. The PSUR is the natural trigger for the review, and the CER has to reflect current evidence rather than the pre-market set.
• CAPA. PMS signals are processed through the quality system’s corrective and preventive action procedure. PMS does not replace CAPA; it feeds it, and the CAPA record is where the response is evidenced.
• EUDAMED. The PSUR for Class III and implantable Class IIb devices and the SSCP are uploaded there, and the vigilance module generates data that comes back the other way. See our guide to EUDAMED registration.
• Technical documentation. The PMS plan and reports live in Annex III, alongside the Annex II file rather than inside it — our guide to the EU MDR Annex II structure covers the placement.

In vitro diagnostics follow a parallel but distinct regime under the IVDR, with different article numbers and its own guidance — see our guide to MDCG 2025-10 and post-market surveillance under the IVDR.

The audit findings that recur

A generic PMS plan. The most common finding by a distance. Data sources listed as categories, no device-specific indicators, no thresholds, no acceptance criteria. A compliant plan states what constitutes a signal for this device — a complaint rate, an event frequency, a literature finding — not which kinds of data exist.

A generic PMCF plan. The same failure one level down. No databases, no search terms, no inclusion and exclusion criteria, no sample size, no analysis method.

The PSUR cycle missed. A process failure rather than a technical one. The annual or biennial cycle has to sit in the quality system calendar with an owner and a deadline, because a missed PSUR is a non-compliance with no grace period.

PMS disconnected from risk management. Findings documented in the PSUR that never reach the risk file or the clinical evaluation. The loop is mandatory and it has to be evidenced, not asserted.

No record of the analysis. Data collected from complaints, literature and EUDAMED, and no documented trace of what was done with it. Trend graphs, signal assessment records and literature appraisal logs are the objective evidence that the analysis happened.

The SSCP out of step with the PSUR. For Class III and implantables, a public document on EUDAMED that no longer matches the most recent clinical conclusions.

Thresholds that cannot fire. Indicators defined with values set so high that no realistic signal reaches them. The plan satisfies Annex III on paper and the reassessment never runs.

Building a system that works

Write the plan before market placement. PMS is part of the technical documentation submitted for assessment, not a post-launch addition. Data sources, indicators and PMCF activities are defined before the device enters clinical use, and the thresholds come from the risk file rather than being invented later.

Derive the indicators from the claims. For each performance or safety claim in the intended purpose, define a measure: complaint rate per thousand devices per year, proportion requiring field service within a defined period, adverse event frequency for the primary hazard. Indicators derived from claims are defensible; indicators derived from what is easy to count are not.

Treat PMCF as clinical research. Surveys, registry participation and observational studies need ethical approval where applicable, informed consent, and enough statistical power to answer the question posed. A ten-patient survey addressing a safety gap in a population of fifty thousand will not satisfy a reviewer, and it will not answer the question either.

Govern the literature search. Literature surveillance is the most universally applicable PMCF method and the easiest to do badly. Define the databases, the search strings, the inclusion and exclusion criteria, the frequency and the owner, and record each cycle with its date, results and appraisal conclusion — so that the search can be re-run and produce the same result.

Put the PSUR cycle in the document management system. With automated reminders and a named owner. This is the failure that is entirely preventable and still happens.

Make every PSUR state whether the CER needs updating. An explicit statement, with a defined timeframe for the update where the answer is yes, and a reference in the updated CER to the PMS data that triggered it. That reference is what turns two documents into a system.

Frequently asked questions

What is the difference between PMS and vigilance reporting?

They are complementary and distinct. PMS is proactive and continuous: it collects and analyses post-market data to confirm that safety and performance hold, and produces periodic outputs such as the PSUR and PMSR. Vigilance is reactive and event-driven: it requires notification to competent authorities when a specific serious incident occurs, on defined deadlines. The thresholds that trigger a vigilance trend report and the indicators that trigger a PMS signal investigation overlap but are not the same set.

Which report does my device class require?

Class I devices produce a post-market surveillance report under Article 85. Class IIa, IIb and III devices produce a periodic safety update report under Article 86 — at least every two years for Class IIa, and at least annually for Class IIb and Class III. For Class III and implantable Class IIb devices the PSUR is submitted to the Notified Body through EUDAMED; for the others it is held and made available on request.

Is PMCF mandatory for every device?

A PMCF plan, or a documented justification for why PMCF is not applicable, is required for every class. For Class I and IIa a justified decision not to conduct PMCF can be acceptable where the clinical evidence is comprehensive and the device has an established history. For Class IIb and III such a justification is very difficult to sustain, and PMCF is required in practice.

When must the PSUR be submitted to the Notified Body?

For Class III and implantable Class IIb devices, through EUDAMED, where it is reviewed as part of the surveillance cycle. For Class IIa and non-implantable Class IIb devices there is no proactive submission requirement: the PSUR is maintained and made available to the Notified Body and the competent authority on request.

Can several devices share one PMS plan?

Devices within a family may share a PMS plan where they have the same intended purpose and comparable risk profiles, with the device-specific elements documented as appendices. Each device still requires its own PMSR or PSUR — an aggregate report covering several devices is not acceptable.

What must PMS data actually be used for?

Article 83(3) lists eight uses: updating the benefit-risk determination and risk management; updating the design and manufacturing information, the instructions for use and the labelling; updating the clinical evaluation; updating the summary of safety and clinical performance; identifying needs for preventive, corrective or field safety corrective action; identifying options to improve usability, performance and safety; contributing to the post-market surveillance of other devices; and detecting and reporting trends under Article 88.

How do the transition deadlines affect PMS obligations?

Manufacturers transitioning legacy devices have to establish an MDR-compliant PMS system as part of the transition, with the plan and associated documentation ready before the MDR certificate is issued rather than assembled afterwards. Our guide to the EU MDR transition deadlines covers the timeline that applies.

What is the most common PMS audit finding?

A generic PMS plan: one that lists categories of data source without naming specific databases or registries, and defines no device-specific indicators, thresholds or acceptance criteria. The plan has to state what constitutes a signal for this device, not what kinds of data exist in general.

Conclusions

The MDR turned post-market surveillance from an obligation into a system, and the difference shows in one place: whether the outputs come back. A file that collects data, analyses it and reports it, but never changes a risk estimate, a label, a clinical conclusion or a design input as a result, has built a reporting function rather than a surveillance function.

Two things separate the systems that pass surveillance audits. The plan is specific — named sources, indicators derived from the device’s own claims, thresholds set at values a real signal would reach. And the loop is evidenced — a CAPA that traces to a PMS finding, a CER revision that names the data that triggered it, a risk file entry that came from the field rather than from the design phase.

The eight uses in Article 83(3) are the fastest self-assessment available. If the system cannot produce an example of each, it is not yet the system the Regulation describes.

If you are building the documentation, the EU MDR Clinical Documentation Kit includes the PMS plan aligned with Annex III, the PSUR following MDCG 2022-21, the PMCF plan and evaluation report under Annex XIV Part B, and the SSCP for Class III and implantables — deployable in an existing ISO 13485 quality system.

Related articles

• EU MDR Technical Documentation Requirements
• EU MDR Clinical Evaluation Report
• Benefit-Risk Analysis under EU MDR
• ISO 14971 Risk Management
• ISO 13485 CAPA Procedure
• EU MDR Transition Deadlines
• MDCG 2025-10: Post-Market Surveillance Under the IVDR