How Smarteeva Generates a PSUR in 8 Minutes From Connected Post-Market Data

What EU MDR requires for periodic safety reporting

EU MDR Article 86 establishes the PSUR as a mandatory output of the Post-Market Surveillance system for Class IIa, IIb, and III medical devices. Class I devices require a Post-Market Surveillance Report (PMSR) instead, which follows a simpler format but draws from the same data sources.

The PSUR must contain a summary and analysis of post-market surveillance data collected during the reporting period. This includes complaint volumes and trends, adverse event summaries, regulatory reports filed (MIRs, FSCAs), risk management updates, literature review findings, and the manufacturer's own assessment of whether the device's benefit-risk profile has changed.

For Class III and implantable devices, the PSUR must be submitted at least annually. For Class IIa and IIb devices, the minimum frequency is every two years, though Notified Bodies can and do request annual updates. The PSUR is submitted through EUDAMED and reviewed by the relevant Notified Body, who evaluates whether the manufacturer's surveillance activities are adequate and whether the conclusions are supported by the data.

Under the UK MDR (post-Brexit), separate reporting requirements apply with their own formats and timelines. Manufacturers selling in both the EU and UK must produce two separate periodic reports from the same underlying data. Add Health Canada, TGA, PMDA, and other jurisdictions, and the reporting burden multiplies for every market a device is sold in.

Why 100 hours of assembly work is a risk management problem

The time burden of manual PSUR production creates three risks that compound over reporting cycles.

The first is data staleness. When assembling a PSUR takes six weeks, the complaint data in the final document reflects what existed on the day someone ran the export, not what existed at the end of the reporting period. Complaints received during the assembly window are excluded. The report describes the device's safety profile as of an arbitrary date in the middle of the analysis, not as of the reporting period close.

The second is a reconciliation error. The PSUR requires complaint counts, adverse event counts, and regulatory report counts for the same device over the same period. When complaints live in an eQMS, adverse events in a regulatory database, and MDR submissions in a separate filing system, the numbers must be manually cross-referenced. If the PSUR says 847 complaints and the adverse event database shows 203 reports but 14 of those do not match a complaint record, someone has to investigate the discrepancy before the report can be trusted. This reconciliation step alone can consume a full week.

The third is submission delay. When a team has five PSURs due in the same quarter and each takes 200 hours, deadlines slip. Notified Bodies track late submissions. Consistent delays can trigger findings that affect the device's market authorization. And while the team is catching up on overdue PSURs, they are not doing proactive surveillance work.

What manual PSUR production looks like across six weeks

Weeks 1 to 2 are data collection. A Regulatory team member exports complaint data from the eQMS into Excel. They pull adverse event reports from the regulatory database. They request clinical data from the clinical team. They gather literature review findings from whoever was assigned that task. If any source is incomplete, the process stops while someone chases down missing records.

Week 2 to 3 is reconciliation. The team cross-checks complaint counts against adverse event counts against regulatory submission counts. Discrepancies are investigated. Numbers are adjusted. The analysis cannot begin until the data is trusted.

Week 3 to 4 is trend analysis. The team builds pivot tables in Excel, calculates complaint rates by product, event type, and severity, creates charts, and compares current trends against historical data. If the data was re-exported because of reconciliation issues, the trend analysis starts over with the new numbers.

Week 4 to 5 is report writing. The narrative sections are drafted: summary of surveillance activities, complaint trend analysis, adverse event overview, benefit-risk evaluation, and conclusions. Every number in the narrative is manually transcribed from the Excel analysis.

Week 5 to 6 is review and formatting. Clinical, Regulatory, and Quality reviewers check the draft against their own records. Discrepancies trigger corrections that ripple back through the trend calculations. The final document is formatted to match the Notified Body's template requirements, converted to PDF, and submitted.

Total elapsed time: six weeks. Total person-hours: 100 to 200. And the same process repeats for every device in the portfolio at every reporting interval.

How Smarteeva generates a PSUR in 8 minutes

A connected data model, not a data assembly step

The 8-minute generation works because Smarteeva does not assemble the report at the time of generation. The platform maintains a connected data model where complaints, adverse events, investigations, IMDRF codes, regulatory reports, and risk assessments already exist in a single Salesforce environment. The PSUR is a structured view of that data, not a separate document built from disconnected exports.

This architectural difference is the reason the process takes minutes instead of weeks. There is no export step. There is no reconciliation step. The complaint count in the PSUR is the same number you see in the complaint module because it comes from the same database.

One-click report generation

A Regulatory team member opens the PMS reporting module, selects the device, the reporting period, and the template. The system pulls every relevant record filed during that period: complaints with IMDRF codes, adverse events with investigation outcomes, regulatory reports with submission references, and risk assessment updates.

Trend calculations run against live data. Complaint rates by product, event type, severity, and time period are computed from the source records. Tables and charts are generated automatically and embedded in the report. No pivot tables. No manual chart creation.

The complete report is assembled into a configurable template that matches the Notified Body's section structure and formatting preferences. The draft is ready for review in 8 minutes.

Clinical assessment remains with the team

The Regulatory team reviews the generated report, adds their clinical assessment, writes the benefit-risk evaluation, and documents their conclusions about whether the device's safety profile has changed. This is the work that requires human expertise. The 8-minute generation removes the 95+ hours of assembly work so the team can spend their time on the analysis that actually matters.

Multi-format, multi-market support

Smarteeva generates PSURs, PMSRs (Class I), HCSRs (IVDR), and UK PSURs from the same underlying data model. The difference between report types is the template and the depth of analysis required. The data does not change.

One customer was generating their PMSR through a 50-step manual process spanning three departments and taking weeks to complete. After implementation, the same report generates in a single click. The 50 steps collapsed into one because the system already had the data each step was designed to collect.

From assembly work to actual surveillance

When the assembly work goes away, the team's role shifts from report production to surveillance. This is a meaningful change in how the PMS function operates.

A Regulatory professional spending four weeks assembling a PSUR is not analyzing whether complaint trends suggest an emerging safety signal. They are not evaluating whether new literature changes the benefit-risk profile. They are not proactively reviewing whether PMCF activities need to be updated. They are copying data from one system into another and formatting tables.

When that work takes 8 minutes instead of four weeks, the same professional spends their time on the clinical and regulatory judgment that defines their role. The quality of the PSUR improves because the person writing the benefit-risk evaluation has time to think about it rather than rushing through it at the end of a six-week assembly marathon.

The consistency improvements are equally significant. When every PSUR is generated from the same data model with the same trend calculation logic, the numbers are internally consistent. An auditor reviewing three years of PSURs sees the same methodology applied every time. There are no unexplained changes in how complaint rates were calculated or how adverse events were categorized between reporting periods.

Smarteeva's PSUR automation is part of the platform's post-market surveillance suite. Teams already running complaints, adverse events, or MDR submissions on Smarteeva can activate PMS report generation without a separate implementation or data migration.

‍