How to Structure a PMS Plan Under EU MDR

What the PMS plan is actually for

Most manufacturers know they need a PMS plan. Fewer understand what it's actually supposed to do. The plan is not a list of data sources — it's a documented commitment to how you will collect, analyse, and act on post-market information. If someone reads your plan and still doesn't know what would trigger a corrective action or a technical file update, the plan is not doing its job.

Article 84 of EU MDR sets out the requirement. But the substance of what makes a plan workable comes from MDCG 2013-4 (updated), MDR Annex III, and what Notified Bodies actually look for in practice. The regulation tells you to have a plan. The question teams ask — and where they often get stuck — is what the plan needs to say.

The structure of a compliant PMS plan

A well-built PMS plan typically covers these areas in a way that connects them:

Scope and device identification. The plan should clearly identify the device or device family it covers, including UDI reference where applicable. Plans that are too generic — covering a whole product portfolio with a single vague document — tend to fail on specificity.

Data sources. You are expected to cast a wide net: complaint data, field reports, post-market clinical follow-up (PMCF) data, literature on the same or equivalent devices, adverse event databases (including EUDAMED, once fully operational), benchmark data from equivalent products, and user feedback. The key is not just listing these — you need to say how each one is accessed, how frequently it is reviewed, and who is responsible.

Thresholds and signals. This is where most plans fall short. You need to define in advance what constitutes a signal — a data point or pattern that requires escalation. What complaint rate is acceptable? What combination of events would trigger an unplanned PSUR update? What criteria trigger a field safety corrective action? Auditors look specifically for this specificity. Vague language like "adverse trends will be assessed" does not pass.

Review frequency. State explicitly how often the PMS plan itself will be reviewed — not just the data it covers. The plan should be a living document, updated when the device, the market environment, or the regulatory context changes.

Responsibilities. Name the roles or functions accountable for each PMS activity: data collection, signal detection, reporting, and escalation. In smaller teams this may be the same person for everything — that's fine, but it still needs to be explicit.

Outputs. The plan must describe what reports will be produced from the PMS activity — PSUR or PMSR depending on device class — and at what intervals. It should also state how PMS outputs feed into risk management, clinical evaluation, and technical documentation updates. This connection is one of the most commonly missed elements in first-draft plans.

Where teams typically run into trouble

The most common audit finding related to PMS plans is not a missing section — it's vagueness. Plans that describe activities without committing to thresholds, frequencies, or decision criteria are rarely rejected outright, but they produce weak PMS reports downstream, and the weakness becomes visible when the Notified Body reviews the PSUR.

A second common problem: the plan is written once at initial certification and never updated. Device modifications, new literature, market expansion into new geographies, or significant PMCF findings should all trigger a plan review. If your plan hasn't been touched since initial CE marking, that's a flag.

Third: the plan doesn't mention what happens when a threshold is crossed. The signal detection mechanism is there, but the escalation path isn't. "Results will be reported to management" is not an escalation path — who in management, by when, and with what decision authority?

Connecting the plan to the rest of the technical file

One thing that's easy to miss: the PMS plan doesn't sit in isolation. MDR is explicit that PMS outputs must feed back into risk management (Annex I, Chapter I), clinical evaluation (Article 61), and — when significant changes are identified — the technical documentation itself. Building these links into the plan from the start means you don't have to retrofit them later when an auditor asks how your PMS data informed your last CER update.

A well-written PMS plan should make it straightforward to write a compliant PSUR. If the PSUR consistently requires information that the plan doesn't specify how to collect, the plan needs revision — not the PSUR.

Where to go from here

If you are writing a PMS plan for the first time, start with your device's complaint and incident history, identify what data sources you actually have access to, and build your thresholds around the risk profile defined in your risk management file. The PSUR structure resource in this category walks through what the plan's outputs need to feed into. The vigilance reporting resource covers the separate but related track of incident reporting obligations.