Legacy Device PMS Uplift: What MDR Requires vs What Most MDD Systems Had

The gap is larger than most teams realise

MDD post-market surveillance was, in practice, loosely defined. Manufacturers were required to have a system for collecting and reviewing post-market experience, but the specific requirements for what that system had to contain, how often it had to produce outputs, and what those outputs had to say were not prescribed in detail. Many MDD-era PMS systems were largely complaint-handling systems with a periodic trend analysis bolted on. That was enough to satisfy MDD audits in most cases.

MDR is different in two ways that matter. First, it is prescriptive — Annex III defines the minimum content of a PMS plan and a PMS report (or PSUR for higher-class devices), and Notified Bodies check against that list. Second, MDR frames PMS as a proactive activity that feeds back into your clinical evaluation and PMCF, not just a reactive system that logs complaints. If your system does not have those feedback loops built in, it will not satisfy an MDR review even if the complaint handling side is solid.

What Annex III actually requires — and where most plans fall short

When you read through what Annex III expects from a PMS plan, the gaps in most MDD-era documents become obvious fast. The parts teams most often have to build from scratch are: a real methodology for gathering information from actual clinical use (not just waiting for complaints to arrive), a live link between the PMS plan and the PMCF activities so that post-market evidence feeds the clinical picture, and pre-defined thresholds that tell your team when a data pattern triggers a specific type of action.

That last one — pre-defined thresholds — is the most common gap, and it is the one that draws the most Notified Body questions. Many MDD plans say something like "we review complaints and assess for trends." That is not enough under MDR. Your plan has to specify in advance: at what point does a trend become a signal that requires a corrective action, a field safety assessment, or an authority notification? If your team is making that call fresh every time a trend appears, with no documented decision criteria, expect that to be flagged. The fix is not complicated — it is mostly a matter of sitting down with your QA and clinical leads and defining the thresholds explicitly — but it has to be done before your Notified Body review.

PMS reports versus PSURs — knowing which you need

For Class IIa devices, MDR requires a Periodic Safety Update Report (PSUR) at least every two years. For Class IIb and Class III, it is annually. For Class I devices, a PMS report is required but on a less prescriptive schedule.

One thing that surprises a lot of teams is that a PSUR is not just a complaint summary. It has to include: a summary of the results and conclusions of the analyses of the PMS data gathered, a rationale and determination of the frequency of PMCF, the main findings of the PMCF, and the benefit-risk conclusion. If your current periodic review document is a complaint trend analysis with a brief conclusion, it needs to be rebuilt as a PSUR — same underlying data, very different structure and depth.

The feedback loops that MDR requires

The part that takes the most structural work to implement is the feedback loop between PMS and the clinical evaluation. MDR requires that the outputs of your PMS system feed into the clinical evaluation review cycle — meaning that when your PSUR or periodic CER update happens, it has to reference the post-market data and explain what it adds to or changes in the clinical picture.

This means your CER update cycle and your PSUR cycle have to be coordinated. If your CER is reviewed annually and your PSUR is annual, they need to happen in the right sequence so the PSUR data feeds the CER conclusion. In most MDD-era systems, these were separate activities with no defined relationship. Building that relationship — and documenting how it works — is one of the more time-consuming parts of MDR PMS uplift.

Vigilance integration

MDR vigilance requirements (serious incident reporting under Article 87) have to be integrated into your PMS system in a way that is auditable. Your PMS plan should define the process for identifying reportable events, the decision pathway from initial complaint to reporting decision, and the timeline for reporting. If your current process relies on informal escalation and individual judgment rather than a documented procedure, that needs to change.

The interaction between trend reporting and vigilance is also something that catches teams out. Under MDR, you are required to report to the competent authority if an analysis of your PMS data reveals a trend in incidents that constitutes a serious risk — even if no single event crossed the reporting threshold. This is different from MDD practice in most organisations, where trend analysis and vigilance were managed separately.

Building a practical uplift plan

The most effective approach is to run a structured gap analysis against Annex III before starting the rewrite. Go through each required element of the PMS plan and assess whether it is present, partially present, or missing. Then prioritise: fix the structural gaps first (missing sections, undefined thresholds, absent feedback loops), then layer in the process improvements (vigilance integration, PSUR format, CER coordination).

Allow more time than you think this will take. A team that has never written an MDR-compliant PMS plan or PSUR from scratch typically underestimates the effort by a factor of two. The writing is not the hard part — the hard part is the underlying processes that the PMS system has to document, many of which do not exist yet and have to be designed, agreed, and implemented before they can be documented.