Why Most PSUR Files Miss the Point of Post-Market Surveillance
I have seen manufacturers submit PSUR files that read like clinical evaluation reports. Pages of literature summaries. Long descriptions of device characteristics. But almost nothing about what actually happened after the device went to market. The PSUR is not a CER update. It is a surveillance report. And that distinction matters more than most people realize.
In This Article
The confusion starts early. Manufacturers hear “Periodic Safety Update Report” and think it means periodically updating the safety section of the CER. So they copy paragraphs from the clinical evaluation, add a few tables from complaint data, and call it done.
Then the Notified Body reviewer opens the file and asks: where is the analysis of emerging risks? Where is the trend evaluation of complaints over time? Where is the integration with vigilance data?
The manufacturer is confused. They thought they had submitted everything required.
But they had submitted a document that answered the wrong question.
What the MDR Actually Requires for PSURs
The PSUR requirement comes from Article 86 of the MDR. It applies to devices in Class IIa, IIb, and III. The regulation does not provide a long list of content requirements. It says the PSUR must contain:
– A summary of the results and conclusions of the analyses of post-market surveillance data
– A rationale and description of any preventive and corrective actions taken
That is intentionally broad. Because the PSUR is meant to be a living document that reflects what is happening in the real world. Not a static review of what was known before the device was placed on the market.
The key phrase is “results and conclusions of the analyses.” This is not raw data. This is not a data dump. It is analysis. And analysis requires methodology, baselines, trends, and interpretation.
The PSUR is a surveillance report, not a clinical evaluation update. It focuses on what happened after the device reached the market, not what was known before.
The Structure That Actually Works
Most PSUR templates I review are overcomplicated. Manufacturers try to include everything from device description to full literature reviews. This dilutes the focus and makes it harder for reviewers to find what matters.
A functional PSUR structure follows the logic of post-market surveillance:
1. Device Identification and Scope
Keep this minimal. Device name, UDI-DI, classification, covered variants. One page maximum. The reviewer already knows what device this is.
2. Surveillance Methodology
How complaints are collected, how incidents are classified, how trends are identified, how vigilance data is accessed. This section answers: how do you know what you claim to know?
If your methodology section is missing or vague, every conclusion in the report becomes questionable. I have seen reports where manufacturers claim “no safety concerns identified” but have no documented process for identifying safety concerns in the first place.
3. Data Summary and Trend Analysis
This is the core of the PSUR. Number of devices placed on market. Number of complaints. Categories of complaints. Severity. Trends over time. Comparisons to previous periods.
What matters here is not the raw numbers. It is the analysis. Are complaint rates increasing or stable? Are there patterns by device variant, manufacturing batch, geographic region, user group?
Reviewers look for thinking, not tables.
Presenting complaint data without trend analysis or context. Raw numbers without interpretation tell the reviewer nothing about whether the device is performing as expected.
4. Integration with Vigilance
PSURs must connect to the vigilance system. If there were reportable incidents during the period, they should be referenced. If Field Safety Corrective Actions were implemented, they must be described.
This is where I see disconnects. The PSUR says “no safety concerns.” But the vigilance database shows two FSCAs in the same period. Either the FSCAs were not safety-related, or the PSUR is incomplete.
The PSUR should explain that connection explicitly.
5. Benefit-Risk Re-Evaluation
This is not a repeat of the CER benefit-risk conclusion. It is a re-evaluation based on post-market data. Has anything changed? Are the known risks behaving as expected? Are there new risks emerging?
If the answer is “everything is as expected,” that is fine. But the report must show how that conclusion was reached.
6. Preventive and Corrective Actions
If issues were identified, what was done? If no issues were identified, state that explicitly. Reviewers need to see the decision path.
Frequency and Timing Under MDR
The MDR does not set a universal frequency for PSURs. That is determined by the Notified Body based on risk class and specific circumstances. For most Class III devices, annual PSURs are standard. For Class IIb and IIa, it may be every two or three years.
But here is what manufacturers often miss: the PSUR period must align with the PMS plan review cycle. If your PMS plan is updated annually, the PSUR should cover the same annual period. If there is a mismatch, it creates confusion about which data set is being evaluated.
I have reviewed files where the PMS plan covered January to December, but the PSUR covered April to March. The Notified Body had to ask: which complaints are in which report? How do we track trends across periods?
Alignment seems trivial. But in practice, it makes the difference between a clear surveillance trail and a confusing patchwork.
PSUR timing must align with PMS plan cycles. Mismatched periods make trend analysis impossible and raise questions about data integrity.
The Relationship Between PSUR and CER Updates
This is where confusion runs deepest. Manufacturers think the PSUR feeds directly into the CER update. Or that the CER update replaces the PSUR. Neither is correct.
The PSUR analyzes post-market surveillance data. The CER evaluates clinical evidence. These are related but separate activities.
Post-market data from the PSUR may trigger a CER update. For example, if complaint trends reveal a previously unrecognized risk, that risk must be addressed in the CER. But the PSUR itself is not the clinical re-evaluation. It is the surveillance summary that informs the re-evaluation.
Think of it this way: the PSUR answers “what happened?” The CER answers “what does this mean for clinical safety and performance?”
Both are required. Both must be maintained. And both must reference each other when conclusions overlap.
What Notified Bodies Actually Check
When a Notified Body reviews a PSUR during surveillance audit or CER assessment, they look for specific things:
Is the data complete?
Does the report cover all devices in scope? Are all complaint sources included? Are vigilance reports referenced?
Is the analysis credible?
Are trends calculated correctly? Are comparisons meaningful? Is the methodology documented?
Are conclusions justified?
If the manufacturer claims no safety concerns, does the data support that? If corrective actions were taken, were they appropriate and effective?
Is the document current?
Is the PSUR covering the correct period? Is it aligned with the PMS plan? Has it been updated as required?
These are not theoretical checks. These are the questions I ask when reviewing PSURs in real audits. And when the answers are unclear, the entire post-market surveillance system comes into question.
Submitting a PSUR that contains data but no analysis. Reviewers need to see interpretation, not just tables. If complaint rates doubled, explain why. If they stayed flat, explain how you know that is acceptable.
Building a PSUR Process That Lasts
Most manufacturers treat the PSUR as a periodic documentation burden. They scramble to compile data at the deadline. They copy structure from previous years. They hope the Notified Body does not ask too many questions.
This approach creates risk. Because the PSUR is not just a report. It is evidence that post-market surveillance is functioning.
A sustainable PSUR process starts with ongoing data collection. Complaints are logged continuously. Trends are monitored in real time. Issues are flagged as they emerge, not discovered months later when compiling the report.
The PSUR then becomes a summary of work already done, not a frantic search for data to fill a template.
This also makes the document more useful internally. If the PSUR reflects real surveillance activity, it becomes a tool for decision-making. If it is just a compliance document, it sits in a folder and adds no value.
Manufacturers who build PSURs as living documents find that the compliance part becomes easier. Because they are documenting what they already do, not inventing content to satisfy a requirement.
The Template Is Not the Solution
There are many PSUR templates available. Some from consultants. Some from industry groups. Some from Notified Bodies.
None of them solve the real problem.
The problem is not structure. The problem is understanding what post-market surveillance means and how to analyze it. A template gives you section headings. It does not tell you what complaint rate is acceptable. It does not explain how to identify emerging trends. It does not clarify when a pattern becomes a signal.
That knowledge comes from experience with your device, your market, your data. And from building a PMS system that generates meaningful information, not just compliance paperwork.
Use a template if it helps organize your thinking. But do not mistake filling in the template for doing the work.
The PSUR that passes review is the one where the manufacturer clearly understands what happened to their device in the field and can explain why that matters.
Everything else is formatting.
A PSUR template organizes information. It does not create analysis. The value of the PSUR comes from surveillance activity, not document structure.
Final Thought
The PSUR is one of the few MDR documents that forces manufacturers to look at real-world performance. Not theoretical risks. Not literature predictions. Actual data from actual use.
That makes it uncomfortable for some manufacturers. Because real-world data is messy. Complaints come in. Users make mistakes. Devices sometimes fail in unexpected ways.
But that discomfort is the point. The PSUR exists because post-market reality does not always match pre-market expectations. And when it does not, someone needs to notice and respond.
If your PSUR feels too clean, too confident, too similar to last year, ask yourself: are you documenting surveillance, or are you documenting assumptions?
Because Notified Bodies can tell the difference.
Peace,
Hatem
Clinical Evaluation Expert for Medical Devices
Follow me for more insights and practical advice.
Frequently Asked Questions
What is a Clinical Evaluation Report (CER)?
A CER is a mandatory document under MDR 2017/745 that demonstrates the safety and performance of a medical device through systematic analysis of clinical data. It must be updated throughout the device lifecycle based on PMCF findings.
How often should the CER be updated?
The CER should be updated whenever significant new clinical data becomes available, after PMCF activities, when there are changes to the device or intended purpose, and at minimum during annual reviews as part of post-market surveillance.
What causes CER rejection by Notified Bodies?
Common reasons include inadequate equivalence demonstration, insufficient clinical data for claims, poorly structured SOTA analysis, missing gap analysis, and lack of clear benefit-risk determination. Structure and logical flow are as important as the data itself.
Which MDCG guidance documents are most relevant for clinical evaluation?
Key documents include MDCG 2020-5 (Equivalence), MDCG 2020-6 (Sufficient Clinical Evidence), MDCG 2020-13 (CEAR Template), MDCG 2020-7 (PMCF Plan), and MDCG 2020-8 (PMCF Evaluation Report).
Need Expert Help with Your Clinical Evaluation?
Get personalized guidance on MDR compliance, CER writing, and Notified Body preparation.
✌
Peace, Hatem
Your Clinical Evaluation Partner
Follow me for more insights and practical advice.
– MDR 2017/745 Article 86
– MDR 2017/745 Annex III (Post-Market Surveillance)
– MDCG 2022-21 Guidance on Periodic Safety Update Reports





