DSUR vs PSUR: What's the Difference?

The short answer is lifecycle stage. A DSUR — Development Safety Update Report — is the annual safety report for a drug that is still in development, governed by ICH E2F. A PSUR — which in its current ICH form is the PBRER, the Periodic Benefit-Risk Evaluation Report — is the periodic benefit-risk report for a drug that is already on the market, governed by ICH E2C(R2). One tracks the evolving safety picture of an investigational product across your trials; the other evaluates the benefit-risk balance of an approved product in real-world use.

If you remember nothing else: DSUR is investigational, PBRER is marketed. Almost every real difference between the two documents follows from that single split — the guideline they answer to, the clock they run on, the reference document they judge events against, and what the body of the report is actually for.

The two reports do overlap at the seams. A product in late-stage development can be approved in one region while trials continue elsewhere, and for a while you may be producing both. But they are different documents governed by different guidelines, tied to different lifecycle stages, run on different clocks, and judged against different reference documents — and different regulators read them. The organizational owner may also differ in practice, but that is company-specific rather than an inherent regulatory distinction. Either way, it is worth being precise about which is which.

A quick word on PSUR vs PBRER

Before the comparison, clear up the naming, because it causes more confusion than the DSUR contrast does.

"PSUR" — Periodic Safety Update Report — is the older term. In 2012 the ICH E2C guideline was revised to E2C(R2), and the report it defines was renamed the PBRER, the Periodic Benefit-Risk Evaluation Report. The rename was not cosmetic. It signaled a shift from a safety-data catalog toward an integrated benefit-risk evaluation. But the old name stuck. In EU legislation and in everyday conversation, people still say "PSUR," and many regulators still label the submission that way. So for practical purposes: PBRER is the ICH E2C(R2) format, and "PSUR" is what most of the industry still calls it. When someone asks about a PSUR, they almost always mean a document written to the PBRER standard. Below, "PBRER" and "PSUR" refer to the same report.

The comparison, line by line

Each of those rows deserves a sentence or two, because the differences are where writers get tripped up.

Lifecycle stage and purpose

The DSUR's job is to give regulators a periodic, comprehensive view of the safety of a drug while it is being studied. Its scope is the clinical trial program: everything the sponsor is running, plus relevant information from other sources. The question it answers is whether anything in the accumulating data changes the understanding of the drug's safety, or affects the conduct of the ongoing trials — a dose, an exclusion criterion, the informed consent, the risk-benefit of continuing.

The PBRER's job is different. The drug is approved; there is now real-world exposure, often far larger and more varied than any trial population. The PBRER asks whether, in light of everything learned in the reporting interval, the benefit-risk balance of the approved product still holds. That is why E2C(R2) insists on an evaluation, not a data dump. The safety findings are weighed against the established efficacy to reach a reasoned position.

Reporting clock and the two birth dates

Both reports run on a clock anchored to a "birth date," and this is the single most common place to make an error, because the two dates sound alike and are not the same thing.

The DSUR is annual. Its clock is the Development International Birth Date (DIBD) — the date of the sponsor's first authorization to conduct a clinical trial in any country. The annual DSUR is prepared covering the year that follows, with a defined data lock point, and submitted within 60 days of that data lock.

The PBRER's clock is the International Birth Date (IBD) — the date of the first marketing authorization for the product in any country. The PBRER's periodicity is not universally annual; regulators set the required frequency and reporting intervals, which may be six-monthly, yearly, or longer for a well-established product, and in the EU are governed by the list of Union reference dates. So DSUR = annual, anchored to the DIBD (first trial authorization); PBRER = periodic per regulator, anchored to the IBD (first marketing authorization). Do not swap them.

The reference safety information — do not conflate these

To decide whether an adverse event is "expected" (or, for the marketed setting, "listed"), you compare it against a reference document. The DSUR and the PBRER use different reference documents, and mixing them up is a substantive error a reviewer will catch.

For the DSUR, the reference for expectedness is the reference safety information (RSI) in the Investigator's Brochure. The IB is the investigational-phase document that tells investigators what is already known about the drug; its RSI section is the yardstick for whether a serious adverse reaction is expected.

For the PBRER, E2C(R2) allows the reference to be the company core data sheet (CCDS) — the reference product information the company maintains for the approved product — or another clearly specified reference product information, whose safety section is used to judge whether an event is listed. In practice it is typically the CCDS. Either way it is a marketed-product document, not an Investigator's Brochure.

So: DSUR expectedness is judged against the IB; PBRER listedness is judged against the specified reference product information, typically the CCDS. Two documents, two different products of the lifecycle. If a draft judges investigational events against a marketed-product reference, or marketed events against an IB, something has gone wrong.

Content emphasis

The DSUR is built around two distinct safety presentations that E2F keeps separate: interval line listings of serious adverse reactions and cumulative summary tabulations of serious adverse events, drawn from across the sponsor's studies and presented so a reviewer can see the whole program's serious-event experience at once. Treatment information should remain blinded where appropriate; unblinded data are used when available and justified. The analytical work is reconciling those interval and cumulative figures against the source safety data and flagging anything that shifts the picture.

The PBRER is built around an integrated benefit-risk evaluation. It still contains cumulative safety data and tabulations, but those feed a conclusion rather than being the conclusion. E2C(R2) walks through the state of the safety information, any new signals and their evaluation, an appraisal of benefit, and then an integrated benefit-risk analysis for the approved indications. Writing a PBRER as though it were a DSUR — a catalog of events with no benefit-risk narrative — is the classic mistake E2C(R2) was revised to prevent.

Which do I file for a drug in Phase 3?

A DSUR. As long as the drug is investigational and you are running trials, the periodic obligation is the annual DSUR under E2F, regardless of phase. The PBRER obligation begins with marketing authorization and runs off the IBD, though the specific submission obligation and frequency remain jurisdiction-specific. If the product later gets approved in one market while Phase 3 continues elsewhere, you can find yourself producing both for a period — the DSUR for the ongoing development program and the PBRER for the newly approved product.

Both reports sit inside the wider pharmacovigilance and reporting picture covered in our field guide to regulatory documents in drug development, and the guidelines behind them are two of the six in the ICH guidelines every regulatory writer should know. If you want the deeper background on how any of this fits together, start with the complete guide to regulatory writing.

Both documents are largely template-bound: E2F and E2C(R2) specify the sections, the tabulations, and the reference documents in advance, so the mechanical parts can be automated and the writer's time redirected to judgment. That is the thinking behind Asthra's DSUR automation and PSUR automation — the guideline supplies the structure, the safety database supplies the counts, and the writer supplies the interpretation.

FAQ

Is a PBRER the same as a PSUR? Effectively yes. PSUR is the older name; the ICH E2C(R2) revision renamed the report the PBRER and reframed it as an integrated benefit-risk evaluation rather than a safety-data summary. Most of the industry, and much EU legislation, still says "PSUR," but the document expected today is written to the PBRER standard.

Which report do I file for a drug still in clinical trials? The DSUR, under ICH E2F, submitted annually and anchored to the Development International Birth Date. The PBRER is for marketed products; its obligation begins once the drug has a marketing authorization, with the specific submission requirement and frequency set by each jurisdiction.

What's the difference between the DIBD and the IBD? The DIBD, the Development International Birth Date, is the date of first authorization to conduct a clinical trial anywhere, and it anchors the DSUR clock. The IBD, the International Birth Date, is the date of first marketing authorization anywhere, and it anchors the PBRER clock. Same idea, different lifecycle event.

Do the DSUR and PBRER use the same reference safety information? No. The DSUR judges expectedness against the reference safety information in the Investigator's Brochure. The PBRER judges listedness against a clearly specified reference product information for the approved product — typically the company core data sheet. Conflating the two is a common and consequential error.

DSUR vs PSUR vs PBRER — where does the DSUR sit in all this? The DSUR is separate from that naming debate entirely. PSUR and PBRER are two names for the same marketed-product report. The DSUR is a different document for a different lifecycle stage, governed by a different guideline (E2F, not E2C(R2)).