The Periodic Safety Update Report is not a data aggregation exercise. Under EU MDR, the PSUR is a structured argument — updated on a defined schedule — that the benefit-risk balance of the device remains acceptable in light of all available post-market evidence. The distinction between aggregating data and making a benefit-risk argument is what shapes how the document should be written, and it is the difference between a PSUR that satisfies reviewers and one that generates clarification requests.

What a PSUR is — and what it is not

A PSUR that presents complaint volumes, PMCF summaries, and literature search results without drawing explicit benefit-risk conclusions has not fulfilled its regulatory purpose. The data is necessary but not sufficient. The document's purpose is to state: given everything we know from the market about this device's performance and safety profile, the conclusion reached in the clinical evaluation still holds — or here is how it needs to be updated.

Equally, a PSUR is not a copy of the PMCF Evaluation Report. The two documents serve related but different functions. The PMCF Evaluation Report summarises findings from PMCF activities and feeds them back to the CER. The PSUR takes a broader view — incorporating all PMS data, including complaints, vigilance reports, and post-market literature — and draws a periodic benefit-risk conclusion.

The benefit-risk structure that works

The most review-ready PSUR benefit-risk sections share a common structure:

  • Restate the established benefit-risk conclusion from the current CER
  • Summarise the post-market data reviewed in this period — complaint rates, serious incidents, PMCF findings, updated literature
  • Assess each data type against the residual risks and clinical benefits identified in the CER
  • State explicitly whether the post-market data supports, challenges, or requires refinement of the existing benefit-risk conclusions
  • Confirm the conclusion, update it, or flag that a CER update is needed

The explicit comparison — post-market findings assessed against the CER's benefit-risk framework — is the step most commonly missing. Without it, the data presented in the PSUR is not connected to any regulatory conclusion.

Using complaint data as evidence, not noise

Complaint data is one of the primary PMS data sources for PSURs, and it is frequently underused. The most useful approach is to present complaint data not just as a volume count but as a rate — complaints per device on the market, ideally per device-year of use — and to compare that rate against the expected rate of adverse events identified in the risk management file.

Where the observed complaint rate is lower than the predicted rate, that is a positive finding for the benefit-risk conclusion and should be stated explicitly. Where it is higher, the PSUR should address the implications for the residual risk assessment and whether a risk management file update is warranted.

When a PSUR should trigger a CER update

A PSUR that identifies any of the following should document the requirement for a CER update, with a timeline:

  • Post-market data that materially changes the observed benefit or risk profile
  • New published literature that changes the state-of-the-art conclusions in the CER
  • Field safety corrective actions or vigilance reports that affect the benefit-risk analysis
  • Changes to the intended purpose or device design not yet reflected in the clinical evaluation

A PSUR that identifies these triggers but does not record the requirement for CER action creates an audit finding — the connection between the periodic review and the living technical file is one of the things Notified Bodies check in surveillance audits.

Writing for the reviewer

PSUR reviewers — whether Notified Body staff or internal auditors — want to follow the benefit-risk logic from the data to the conclusion without ambiguity. Clear section headings, explicit cross-references to the CER and PMCF Evaluation Report, and a summary benefit-risk statement at the end of the document make this straightforward. A document that requires a reviewer to reconstruct the argument from disconnected sections will typically generate more questions than one that makes the logic explicit.