Why Aggregate Reports Exist

Every module in this course up to this point has worked, in one way or another, at the level of the individual case: how one case gets coded, how one case gets written up as a narrative, how one case gets assessed for causality and seriousness, how one drug-event pair gets statistically flagged as a candidate signal. Aggregate reporting is where all of that individual-case work gets synthesised into something a single case can never provide on its own: a cumulative, pattern-level judgment about a product’s safety profile as a whole.

The distinction matters because the two kinds of judgment answer genuinely different questions. A well-assessed individual case can tell you, with appropriate uncertainty, whether this drug plausibly caused this event in this patient. It cannot tell you whether the drug’s overall benefit-risk balance across its entire patient population has shifted — that requires looking at exposure, at patterns across hundreds or thousands of cases, at what’s changed since the last time someone asked the same question. That’s exactly the job an aggregate report does, on a defined periodic schedule, for the entire life of a marketed product.

This module works through that job in the order it actually gets done: the structure of the PBRER — the aggregate report format that superseded the older PSUR — first, then the specific mechanics that make compiling one possible at all (the data lock point, cumulative exposure estimation), then how findings get summarised and how the whole thing converges into a single benefit-risk judgment. From there it covers the DSUR, the PBRER’s clinical-trial-stage counterpart, before closing with regional variation, common quality findings, and where AI genuinely helps with drafting.