Manual PMS Reporting vs Automated: What 100+ Hours of Assembly Work Actually Costs
What EU MDR and FDA regulations require for periodic safety reporting
EU MDR Article 86 requires PSURs for Class IIa, IIb, and III devices. The PSUR must summarize post-market surveillance data, analyze complaint and adverse event trends, evaluate the benefit-risk profile, and present conclusions on whether the device continues to meet safety and performance requirements. Class III and implantable devices require an annual submission. Class IIa and IIb devices require submission at least every two years.
Class I devices under EU MDR require a Post-Market Surveillance Report (PMSR) instead of a PSUR. The PMSR is simpler in structure but draws from the same underlying data: complaints, adverse events, field actions, and risk management updates. The PMSR must be updated when necessary and made available to Notified Bodies on request.
Under IVDR, the equivalent report is the HCSR (Health and Clinical Safety Report). The UK has its own PSUR requirements under the UK MDR, separate from the EU framework. Manufacturers selling globally may need to produce four or five different periodic reports from the same underlying data, each with jurisdiction-specific format requirements.
The FDA does not require a direct equivalent of the PSUR, but manufacturers must maintain complaint trending data under 21 CFR 820.198 and make it available during inspections. The practical effect is similar: the data must be aggregated, analyzed, and presented in a format that demonstrates the manufacturer is actively monitoring device performance.
The manual process, step by step across six weeks
The following timeline reflects what actually happens at manufacturers producing PSURs manually. The steps are consistent across company sizes because the bottleneck is architecture, not team capability.
- Weeks 1 to 2 involve data collection. A Regulatory team member exports complaint data for the reporting period from the eQMS into Excel. They pull adverse event reports from whatever system or folder those records live in. They request field safety corrective action records, clinical data, and literature review findings from other departments. If any data source is incomplete, which it frequently is, the process pauses while missing records are tracked down.
- Weeks 2 to 3 are data reconciliation. The complaint export shows 847 records. The adverse event database shows 203 reports filed during the same period. But 14 of those adverse event reports do not match a complaint record in the export. Were they filed from a different system? Were the complaints entered after the export date? Were they miscoded and showing up under a different product? Someone has to investigate every discrepancy before the report can proceed.
- Weeks 3 to 4 are trend analysis. The team calculates complaint rates by product, by event type, by severity, and by reporting period using Excel pivot tables. They create charts, compare current period trends against historical data, and identify any rates that exceed predefined thresholds. If the complaint data had to be re-exported because of reconciliation issues from the previous week, the trend analysis starts over with the new dataset.
- Weeks 4 to 5 are report writing. The team drafts narrative sections: summary of surveillance activities, complaint trend analysis, adverse event overview, benefit-risk evaluation, and conclusions. Every number referenced in the narrative is manually transcribed from the Excel analysis. Every chart referenced is manually created and embedded.
- Weeks 5 to 6 are internal review and formatting. Clinical, Regulatory, and Quality reviewers check the draft against their own records. If anyone finds a discrepancy between the PSUR numbers and their source data, the team traces the issue back to the export, corrects it, and updates the affected sections. The final document is formatted to match the Notified Body's template preferences, converted to PDF, and submitted.
Six weeks. Three departments. 100 to 200 person-hours. And the same process repeats for every device in the portfolio at every reporting interval.
The same report, generated in 8 minutes
Smarteeva's PSUR generation works differently because the data architecture is different. The platform does not assemble data at report time. It maintains a connected data model where complaints, adverse events, investigations, IMDRF codes, and regulatory reports already exist in a single Salesforce environment.
A Regulatory team member opens the PMS reporting module, selects the device, the reporting period, and the report template. The system pulls every relevant record filed during that period from the same database where those records were created. Complaint counts come from the complaint module. Adverse event counts come from the adverse event module. Both reference the same underlying records, so reconciliation is unnecessary.
Trend calculations run against live data. Complaint rates by product, event type, severity, and time period are computed from source records in real time. There are no pivot tables. There are no manual chart builds. The trend data in the PSUR is identical to the trend data visible in the analytics dashboard because both draw from the same source.
The complete report is assembled into a configurable template that matches the Notified Body's section structure and formatting requirements. Data summaries, trend charts, adverse event listings, and risk assessment references are populated automatically. The draft is ready for review in 8 minutes.
The Regulatory team then does the work that requires human judgment: writing the clinical assessment, evaluating the benefit-risk profile, and documenting conclusions about whether the device's safety performance has changed. This is the work they were hired to do. The 8-minute generation removes the 95+ hours of assembly so the team can focus entirely on analysis and interpretation.
Smarteeva supports PSURs, PMSRs (Class I), HCSRs (IVDR), and UK PSURs from the same data model. The difference between report types is the template configuration and the depth of analysis required. The underlying data is identical.
One customer was producing their PMSR through a 50-step manual process spanning three departments. After implementation, the same report generates with a single configuration step. The 50 steps collapsed because the system already contained the data each step was designed to collect.
What changes when 100 hours become 8 minutes
The financial calculation is straightforward. A manufacturer producing four PSURs per year per device family at 150 hours each spends 600 hours annually on assembly work. At a loaded cost of $80 per hour for a senior Regulatory professional, that is $48,000 per year spent on exporting data, reconciling numbers, building pivot tables, and formatting documents.
The capacity argument is more significant than the cost argument. 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 updating. They are performing assembly work that a connected system eliminates.
The audit argument is strongest of all. When every PSUR is generated from the same connected data model with the same trend calculation methodology, the reports are internally consistent across periods. An auditor reviewing three consecutive PSURs sees the same methodology applied each time. There are no unexplained changes in how complaint rates were calculated or how adverse events were categorized between reports. Every figure in every report is traceable to the source complaint records through a documented, repeatable workflow.
Notified Bodies evaluate the content and accuracy of PMS reports, not the method of generation. A PSUR generated from a connected data model with full audit traceability meets the same regulatory requirements as a manually assembled report. The difference is that the automated version is produced faster, with more complete data coverage, and with traceable methodology that strengthens the submission during review.
Smarteeva's PMS report automation is part of the post-market surveillance suite. Teams already running complaints, adverse events, or MDR submissions on Smarteeva can activate report generation without a separate implementation or data migration.
