Clinical

Writing the PSUR / PBRER: from safety summary to benefit-risk

Under ICH E2C(R2) the PSUR/PBRER is an integrated benefit-risk evaluation, not a safety summary. Software can compile and reconcile the data; the benefit-risk evaluation must stay with qualified people.

2026-10-24Cybroscape Technologies3 min read
Key takeaway

Under ICH E2C(R2) the PSUR/PBRER is an integrated benefit-risk evaluation, not a safety summary. Software can compile and reconcile the data; the benefit-risk evaluation must stay with qualified people.

Once a product is approved, safety writing changes character. The Periodic Benefit-Risk Evaluation Report, still called the PSUR in Europe, is no longer about whether trial participants are safe. It asks whether the balance of benefit and risk is still positive for the whole patient population.

That shift in question changes how the document should be written. This is a practical guide.

What changed with ICH E2C(R2)

The older PSUR format was largely a safety summary. ICH E2C(R2) replaced it with the PBRER, which puts benefit and risk side by side and asks for an integrated evaluation. The EU kept the PSUR name but adopted the same format and content.

The practical effect is that a report which only lists adverse events is no longer enough. It has to show that someone weighed the new safety information against what the product actually does for patients.

Where the effort goes

Much of each report is assembled from the same sources every cycle: exposure data, cumulative tabulations, literature, signal reviews and the conclusions of previous reports. A large share of writing time goes into rebuilding material that has not changed.

The part that does change, and the part a reviewer reads first, is the integrated benefit-risk evaluation. That is where qualified people should spend their time.

What software can do well

Compilation and consistency. Pulling the cumulative data together, making sure the tables agree with each other and with the text, carrying forward unchanged sections accurately, and flagging where something has changed since the last report.

Those are the tasks that eat time and introduce errors when done by hand. Done well, they free the safety physician to focus on the evaluation.

What it must not do

The benefit-risk evaluation is the reason the document exists. It requires clinical judgement about the significance of new findings, the size of the benefit, and the populations affected. No tool should draft that conclusion, and a vendor that offers to is misunderstanding the job.

Signals and the reference safety information

The section reviewers tend to read most closely, after the evaluation itself, is the signal overview. Every signal opened, closed or still under evaluation during the interval needs a clear status and a reason for that status. A signal that appears in one report and quietly disappears from the next is a common finding.

The same goes for the reference safety information. If the core safety information changed during the interval, the report should say what changed and why, and the rest of the document should be written against the right version. Mixing versions is an easy mistake when sections are carried forward from the previous report.

Common reasons a report comes back

  • Exposure estimates that do not match what the company has reported elsewhere, with no explanation of the method.
  • Cumulative tables that do not add up to the previous report plus the interval.
  • A benefit section that restates the label instead of saying anything about benefit in the interval.
  • Conclusions that do not follow from the evaluation, or that propose no action when the evaluation suggests one.

Almost all of these are consistency problems, which is good news. They are the kind of thing a careful check against source catches before submission.

A sensible way to start

Use software on the cumulative tabulations and the carried-forward sections first, where checking is quick and errors are costly. Add consistency checking across the whole report next. Keep the evaluation and conclusions with your qualified people.

Our pharmacovigilance practice and TraceDraft both work this way. Get in touch to see it against one of your own reports.

Where to go next

Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.

psur ai writing softwarepbrer writingpsur writingich e2c r2periodic safety report

Frequently Asked Questions

What is the difference between a PSUR and a PBRER?+

Under ICH E2C(R2) the PBRER replaced the older PSUR format with an integrated benefit-risk evaluation. The EU still uses the name PSUR but follows the same format and content.

What can software do on a PBRER?+

Compile the cumulative data, keep tables consistent with each other and with the text, carry unchanged sections forward accurately and flag what changed since the last report.

What should software never write in a PBRER?+

The integrated benefit-risk evaluation and conclusions. That is the clinical judgement the report exists to record.

Next step

Bring a system. We'll show you the package.