If you work in regulatory affairs for a medical device company selling in the European Union, you know the Periodic Safety Update Report. You probably also know the particular dread that accompanies the realization that the next one is due in eight weeks and nobody has started the data collection.
The PSUR is one of the most important — and most labor-intensive — documents in the EU MDR post-market surveillance framework. Under Article 86, manufacturers of Class IIa, IIb, and III devices must prepare and submit PSURs at defined intervals. For Class III and implantable devices, PSURs are due annually. For Class IIa and IIb devices, the interval is at least every two years, or when necessary.
This article covers what goes into a PSUR, why they consume so much time, what can realistically be automated, and where human judgment remains essential.
What Is a PSUR?
A Periodic Safety Update Report is a structured document that summarizes and analyzes post-market surveillance data collected during the reporting period. Its purpose is to demonstrate that the device's benefit-risk profile remains acceptable and that the manufacturer's PMS system is functioning effectively.
Under EU MDR Article 86, the PSUR must include:
- The conclusions of the benefit-risk determination
- The main findings of the PMS data analysis
- The volume and type of post-market surveillance data collected (sales volumes, usage data, adverse event reports)
- The rationale and description of any preventive and corrective actions taken
- The outcomes of analyses of comparable devices on the market
The PSUR is submitted to the relevant notified body (for Class IIa and IIb devices) or to both the notified body and the competent authority (for Class III and implantable devices) via EUDAMED.
MDCG 2022-21 provides detailed guidance on PSUR content and format. If you have not read this guidance document recently, review it — notified bodies are increasingly auditing PSURs against its recommendations.
Why PSURs Take Weeks
The timeline problem with PSURs is primarily a data collection and analysis problem, not a writing problem. A well-structured PSUR template is straightforward to populate once the data is assembled. But assembling the data is where the weeks go.
Adverse event data collection. The reporting period may cover 12-24 months of adverse event data across multiple regulatory databases: MAUDE for U.S. events, the manufacturer's own complaint database, vigilance reports filed in Europe, and potentially databases in other markets (Health Canada, TGA, PMDA). Pulling this data, deduplicating across sources, and normalizing it into a consistent format is time-consuming.
Event classification and trending. Each adverse event needs to be classified by type, severity, and outcome. Then the classified events need to be analyzed for trends: are certain failure modes increasing? Are there new types of events not seen in previous periods? How does the current period compare to historical baselines? This analysis is the heart of the PSUR and requires both data processing and clinical judgment.
Literature review. The PSUR should include relevant findings from scientific literature published during the reporting period. This means searching PubMed and other databases for publications related to your device type, identifying clinically relevant studies, and summarizing their implications for your benefit-risk analysis.
Sales and usage data. Putting adverse event rates in context requires denominator data — how many devices were sold, how many patients were exposed, how many procedures were performed. Collecting this data from sales systems and customer records adds another data integration task.
Comparable device analysis. EU MDR requires analysis of comparable devices on the market. This means monitoring competitor adverse events (as discussed in our article on competitor device monitoring) and incorporating that analysis into the PSUR.
Benefit-risk assessment. The PSUR must conclude with an updated benefit-risk determination. This requires synthesizing all of the above data streams into a coherent argument that the device's benefits continue to outweigh its risks.
What Can Be Automated
Not everything in a PSUR can be automated, but a significant portion of the data collection and preliminary analysis can be:
Automated Data Collection
Adverse event data from regulatory databases can be pulled automatically via APIs. The openFDA API provides structured access to MAUDE data. The manufacturer's complaint database can be queried programmatically. With appropriate integration, vigilance report data from European databases can be incorporated as well.
Automation here means that instead of a regulatory professional spending days manually searching databases and copying data into spreadsheets, the data arrives in a normalized format on a scheduled basis. By the time the PSUR writing period begins, 12 months of pre-collected, pre-organized data is ready for analysis.
Automated Classification
AI-powered natural language processing can classify adverse events by failure mode, severity, and clinical outcome. This classification does not replace human review — it accelerates it. Instead of reading 500 narratives and classifying each from scratch, a reviewer validates 500 pre-classified reports, correcting the AI's output where needed.
For most adverse event narratives, modern NLP achieves classification accuracy in the range of 85-95%, depending on the complexity of the device and the quality of the source narratives. The remaining cases that need human correction tend to be the genuinely ambiguous ones — exactly the cases where human judgment adds the most value.
Automated Trending
Statistical trend analysis is a natural candidate for automation. Algorithms can compare current-period event rates against historical baselines, calculate proportional reporting ratios, identify statistically significant increases, and generate trend charts. These analyses should be validated by a statistician or qualified regulatory professional, but the computation itself is deterministic and automatable.
Automated Report Drafting
With classified data and trend analysis complete, generating the initial PSUR document — populating tables, creating charts, drafting standard sections — can be substantially automated. Template-based generation produces a first draft that a regulatory writer then reviews, edits, and supplements with the narrative sections that require human expertise.
What Needs Human Judgment
Certain elements of the PSUR inherently require qualified human professionals:
Benefit-risk determination. This is a clinical and regulatory judgment that synthesizes quantitative data with qualitative factors — clinical benefit evidence, available alternatives, patient population characteristics, risk mitigation measures. While AI can organize the input data, the judgment itself must be made by qualified individuals.
Regulatory narrative. The written sections of the PSUR that explain the manufacturer's interpretation of the data, describe corrective actions taken, and justify the continued positive benefit-risk profile require regulatory expertise and clear communication. The tone, emphasis, and framing of these sections matter.
Literature interpretation. While AI can search for and summarize relevant publications, assessing their clinical significance and implications for your specific device requires domain expertise.
Escalation decisions. When the data reveals a genuine safety concern, deciding whether it rises to the level of a field safety corrective action, a regulatory report, or a design change is a human decision with significant consequences.
A Practical Automation Strategy
For teams looking to reduce PSUR preparation time from weeks to days, here is a pragmatic approach:
Phase 1: Automate data collection. Set up automated ingestion of adverse event data from openFDA and your internal complaint database. Run this on a weekly schedule so that data accumulates continuously rather than being collected in a sprint before the PSUR deadline.
Phase 2: Implement AI classification. Apply NLP-based classification to incoming adverse event narratives. Build a review workflow where regulatory professionals validate classifications on an ongoing basis — this distributes the review work across the year rather than concentrating it.
Phase 3: Automate trending and visualization. Build or adopt dashboards that track event frequency, severity distribution, and failure mode trends in real time. When PSUR preparation begins, the trend analysis is already done.
Phase 4: Template-based report generation. Create a PSUR template that auto-populates with collected data, validated classifications, and trend analyses. The regulatory writer starts with a substantially complete draft rather than a blank document.
DeviceWatch's report generation features support this workflow. The platform continuously collects and classifies adverse event data, maintains trend analyses, and can export the structured data needed to populate PSUR sections. The human expertise is directed toward the elements that genuinely require it — interpretation, judgment, and narrative — while the data assembly happens in the background.
The ROI Calculation
For a Class III device requiring annual PSURs, a typical manual preparation timeline is 4-6 weeks of regulatory team effort. This includes data collection (1-2 weeks), classification and analysis (1-2 weeks), writing and review (1-2 weeks), and internal approval (1 week).
With a well-implemented automation strategy, the data collection and classification phases shrink from weeks to hours (since the work has been happening continuously). Analysis time is reduced by automated trending. Writing time decreases with template-based generation. The total preparation time drops to 1-2 weeks — and the quality is typically higher because the data foundation is more complete and consistent.
For a company with multiple devices requiring PSURs on staggered schedules, the cumulative time savings can justify the investment in automation within a single reporting cycle.
The PSUR is not going away. EU MDR has made it more rigorous, not less. The question is not whether to prepare them — it is whether to spend six weeks on each one or invest in the tooling that reduces it to one.