Aggregate Reporting End to End: How Periodic Safety Reports Are Built
Individual cases are firefighting. Aggregate reports are the disciplined, regulator-ready story of a product's evolving benefit–risk. This guide covers which report is needed when, how line listings and tabulations are built, and how to build the software that generates them.
Foundations
From zero: what each report is, when it's due, and what goes inside — with a plain rule for which report a situation demands.
Build track
The data model, DLP snapshots, line-listing queries, tabulation aggregation, the template engine, and output/submission formats.
QC & review
The QC & reconciliation checks that survive an inspection — counts, DLP, cumulative arithmetic, MedDRA versions, ALCOA+.
What aggregate reporting is
A periodic, structured evaluation that consolidates all safety data over a defined interval and forces a disciplined conclusion about benefit–risk.
Expedited vs aggregate
Expedited (ICSR): one serious, unexpected case, reported fast (often 15 days). It answers “did something bad just happen?”
Aggregate: all cases over months, summarised and analysed together. It answers “across everything, is the benefit–risk still positive?”
Why regulators demand it
A single case can mislead. Only the aggregate — cumulative counts, exposure, trends, signals, literature — shows the true evolving picture. It's the product's periodic “health check”, submitted on a fixed schedule to the FDA, EMA, CDSCO, PMDA and others.
Think of a bank statement. Each transaction (ICSR) is one line, but the bank doesn't judge your finances one transaction at a time — every quarter it sends a statement: opening balance (cumulative), this period's activity (interval), and a summary. An aggregate report is a drug's safety statement: cumulative history + this interval + a benefit–risk conclusion.
Which report is needed — and when
Before building anything, you must know which report the situation demands. Pick the product stage and market — the selector tells you the report, its framework, and its timeline.
PSUR / PBRER
EU / ICH regions use PSUR/PBRER. One PBRER covers all forms and indications of a substance. Due dates come from the EURD list.
| Report | Stage | Framework | Timing |
|---|---|---|---|
| DSUR | Pre-approval (trials) | ICH E2F | Annually, from DIBD |
| PSUR / PBRER | Post-approval | ICH E2C(R2) · GVP VII | 6-monthly ×2yr, then per EURD list |
| PADER | Post-approval (US) | 21 CFR 314.80 | Quarterly ×3yr, then annually |
| ASR / IND Annual | Pre-approval (legacy) | Region-specific | Annually — largely replaced by DSUR |
The US FDA requires PADER; the EU, Canada, Japan and other ICH regions use PSUR/PBRER. Newer marketed products use the PBRER structure; some legacy/regional filings still use the older PSUR format.
Key concepts & timelines
Five terms unlock every aggregate report. Get these and the schedule, scope and numbers all fall into place.
| Term | Meaning | Why it matters |
|---|---|---|
| DLP (Data Lock Point) | The cut-off date; only cases up to this date are included. | Defines exactly what data the report covers. |
| IBD (International Birth Date) | Date of first marketing authorisation anywhere. | Anchors PSUR/PBRER periodicity. |
| DIBD | Developmental IBD — the trial-phase equivalent. | Anchors DSUR periodicity. |
| Interval data | Cases only within this reporting period. | Shows what's new this cycle. |
| Cumulative data | All cases since the product's start (IBD/DIBD). | Shows the full lifetime picture. |
| EURD list | EU list fixing DLPs & submission dates per substance. | Tells you exactly when the PSUR is due. |
Almost every table in an aggregate report has two columns: this interval and cumulative since IBD. If you understand that split, you understand the structure of the whole report.
Don't compute a report live against the mutable case database — cases keep changing. At the DLP, freeze an immutable snapshot (as-of that timestamp) and generate every listing and tabulation from that frozen copy. Two people regenerating the same report from the same DLP must get byte-identical numbers.
Line listings
The case-level backbone: one row per case, showing the facts a reviewer needs to judge it. Everything else in the report aggregates upward from here.
| Case ID | Country | Source | Age/Sex | Dose & dates | Reaction (PT) | Outcome | Serious | Causality / comments |
|---|---|---|---|---|---|---|---|---|
| 2026-IN-0412 | India | Spontaneous | 54 / M | 50 mg OD | Hepatotoxicity | Recovered | Yes | Positive dechallenge |
| 2026-US-1189 | USA | Literature | 39 / F | 100 mg BD | Anaphylaxis | Recovering | Yes | Confounder: known allergy |
| 2026-DE-0777 | Germany | Trial | 61 / M | 50 mg OD | Rash | Recovered | No | Possible |
Standard line-listing columns
- Case reference number (unique)
- Country of occurrence & source (spontaneous / trial / literature)
- Patient age & sex
- Dose, dates of therapy, indication
- Reaction term(s) — MedDRA PT
- Outcome & seriousness
- Comments — dechallenge/rechallenge, causality, history
Special line listings
SAE line listing — all serious adverse events in the interval (common in DSUR).
SUSAR line listing — Suspected Unexpected Serious Adverse Reactions, often a biannual cumulative listing in clinical development.
These feed directly into the report's tabulations and are a favourite inspection target.
Summary tabulations
Roll the line listing up into counts — by MedDRA SOC and PT, split serious/non-serious and interval/cumulative. This is the report's quantitative core.
Example — summary tabulation of ADRs
| SOC / Preferred Term | Interval — Serious | Interval — Non-serious | Cumulative — Serious |
|---|---|---|---|
| Hepatobiliary disorders | 12 | 3 | 58 |
| Hepatotoxicity | 9 | 2 | 44 |
| Jaundice | 3 | 1 | 14 |
| Skin disorders | 2 | 18 | 21 |
The splits that always appear
- Serious vs non-serious
- Interval vs cumulative
- Spontaneous vs clinical trial vs literature
- By SOC, then by PT within it
Exposure / denominator
Counts alone mislead — 44 cases from 1,000 patients is not the same as 44 from 10 million. Reports include an estimated exposure section (patient-years, doses sold, trial subjects) so rates can be read in context.
The line listing and the tabulation must agree. If the interval line listing has 9 serious hepatotoxicity rows, the tabulation's interval-serious hepatotoxicity cell must read 9 — not 8, not 10. And prior cumulative + interval = new cumulative, unless a documented reclassification explains the gap. Any mismatch is an inspection finding.
PBRER — the 20 sections
The Periodic Benefit-Risk Evaluation Report (ICH E2C(R2), GVP Module VII) is the modern PSUR. It's not just tables — it builds to an integrated benefit–risk conclusion.
Sections 15–18 are where signal detection meets aggregate reporting. New, ongoing and closed signals from the signal engine are summarised here and folded into the benefit–risk conclusion. The two are two halves of the same lifecycle.
One PBRER covers all dosage forms, strengths and indications of a substance — not one per formulation. (PADER is the opposite: a separate report per formulation.)
DSUR & PADER at a glance
DSUR — ICH E2F
The annual safety report for a drug in clinical development. Focus: interventional-trial safety, cumulative development experience, and whether the benefit–risk for trial subjects still holds.
- Anchored to the DIBD; annual.
- Includes SAE & cumulative SUSAR line listings.
- Summary of important risks, changes to the investigator's brochure.
PADER — 21 CFR 314.80
The US FDA periodic report. Narrative summaries of serious, unexpected US adverse experiences, plus line listings on FDA MedWatch (3500A) basis.
- Quarterly for the first 3 years, then annually.
- Separate report per formulation/product.
- Simpler than PBRER — less benefit–risk narrative.
Global companies often prepare a PBRER as the core scientific document and derive a PADER for the US from the same locked dataset — aligning timelines to avoid duplicate work. A good platform generates both from one DLP snapshot.
The generation flow
How a report is actually built. Watch data flow from the safety database, through the DLP gate, into line listings and tabulations, into the report sections, then review, QC and submission.
How to build the reporting engine
The same flow as a technical pipeline. Written for the engineer who must design and ship it.
Report configuration
A config object defines a report: type (PBRER/DSUR/PADER), product/substance, interval (IBD/DIBD anchor, DLP), MedDRA version, and template. Config-driven, not hard-coded per report.
DLP snapshot service
At the DLP, freeze an immutable, as-of copy of all in-scope cases. Every downstream artefact is generated from this snapshot, never the live DB.
Line-listing query
One parameterised query per listing type (SAE, SUSAR) reads the snapshot and emits case-level rows in the required column order.
Tabulation aggregator
Group by SOC → PT, split serious/non-serious and interval/cumulative. Cumulative joins the current snapshot with prior locked snapshots.
Template & output engine
Merge listings, tabulations and authored narrative into the section template (E2C/E2F/CFR), producing Word for review and structured XML/eCTD for submission (EMA IRIS, FDA).
Cumulative tabulation, in pseudocode intermediate
def build_tabulation(product, dlp):
snap = freeze_snapshot(product, as_of=dlp) # immutable
prior = load_prior_cumulative(product, before=dlp)
interval = group_by_soc_pt(snap, period=(prior.dlp, dlp))
for (soc, pt) in all_terms(interval, prior):
i_ser = interval.serious(soc, pt)
i_non = interval.nonserious(soc, pt)
c_ser = prior.cum_serious(soc, pt) + i_ser # cumulative = prior + interval
c_non = prior.cum_nonserious(soc, pt) + i_non
emit_row(soc, pt, i_ser, i_non, c_ser, c_non)
assert_reconciles(line_listing(snap), interval) # counts MUST match- One DLP snapshot, many outputs. Generate PBRER and PADER from the same frozen data so their numbers can never disagree.
- Pin the MedDRA version per report. Coding rolls up differently across versions; store the version used so history stays valid.
- Reconcile in code, not by eye. Assert line-listing counts equal tabulation totals before the report can be marked ready.
- Never regenerate against the live DB. A late case arriving after the DLP must not silently change a locked number.
- Keep the exposure module separate & documented. Denominators come from sales/trial data with their own assumptions — log them.
QC & reconciliation — survive the inspection
Before a report is signed, the PV expert cross-checks it from every angle. If all pass, no number in the report can be challenged.
| Check | What it proves | How |
|---|---|---|
| 1 · Listing ↔ tabulation | Counts agree at every SOC/PT. | Sum listing rows; compare to tabulation cells. |
| 2 · Cumulative arithmetic | prior cumulative + interval = new cumulative. | Use the checker below; explain any gap. |
| 3 · DLP integrity | No case after the DLP is included. | Confirm max case date ≤ DLP. |
| 4 · Duplicates | No case counted twice. | Dedup on case ref before counting. |
| 5 · MedDRA version | One consistent version across the report. | Check the pinned version; re-code if needed. |
| 6 · Section completeness | Every required E2C/E2F/CFR section present. | Checklist against the guideline TOC. |
Reconciliation checker — try it
Enter the prior cumulative count, this interval's count, and the new cumulative your report shows. The check confirms the arithmetic — and flags any unexplained gap.
Every number must be Attributable, Legible, Contemporaneous, Original, Accurate (plus Complete, Consistent, Enduring, Available). Concretely: the DLP snapshot is preserved, who generated it and when is logged, the MedDRA version is recorded, and the report can be regenerated to the same numbers years later during an inspection.
Listing and tabulation counts don't match · a case dated after the DLP slipped in · cumulative ≠ prior + interval with no explanation · mixed MedDRA versions · missing exposure assumptions · a signal open in the signal system but absent from the PBRER signal section.
Platform landscape — learn from the leaders
The enterprise systems all generate aggregate reports from a governed safety database. Studying how they do it shapes how PVgenix builds its own engine.
| Platform | Character | Aggregate reporting approach |
|---|---|---|
| Oracle Argus Safety | Long-standing market leader; single global safety database. | Highly configurable periodic reports (PSUR/PBRER/PADER/DSUR) with rule-driven scheduling and strong analytics. |
| ArisGlobal LifeSphere | Cloud-first, 30+ years, heavy automation/AI; used by some regulators. | Case processing, periodic reports and signal management in one platform, with AI-assisted authoring. |
| Veeva Vault Safety | Modern cloud UI; unified with clinical/quality/regulatory Vaults. | Aggregate + individual submissions, CIOMS I & MedWatch 3500A, semi-annual dictionary auto-updates, real-time dashboards. |
| Others | Ennov PV Works, Sarjen PvEdge, AB Cube SafetyEasy, Extedo PcVmanager. | Extedo is eCTD-centric with automated PSUR/PBRER; others serve mid-size & regional needs. |
Product names are trademarks of their owners; feature descriptions are high-level and current as of early 2026 — verify specifics against each vendor's documentation before relying on them.
- One governed database, config-driven reports — don't build a bespoke pipeline per report type.
- Signal + aggregate in one platform — the PBRER signal section should pull straight from the signal engine.
- Modern UI + automatic dictionary updates + unified data — semi-annual MedDRA updates handled centrally.
- Native eCTD / structured-XML output — and readiness for EMA's IRIS-style structured submissions.
Golden rules — recap
If a new joiner remembers only these, they can already build, generate and QC an aggregate report the correct way.
- Know the report before you build — DSUR (dev), PSUR/PBRER (EU/ICH), PADER (US). Stage + market decide it.
- Interval + cumulative is the golden pair — almost every table has both columns.
- The DLP is a frozen snapshot — generate everything from it, never the live database.
- Listings and tabulations must reconcile — counts equal at every SOC/PT, or it's a finding.
- prior cumulative + interval = new cumulative — any gap must be explained.
- One PBRER per substance; one PADER per formulation — opposite scoping rules.
- Pin the MedDRA version & log exposure assumptions — reproducibility is non-negotiable.
- Signals flow in from the signal engine — PBRER sections 15–18 close the loop with signal detection.
Frequently asked questions
Common questions
Expedited reporting sends one serious, unexpected case fast (often within 15 days) — it answers did something bad just happen? Aggregate reporting summarises and analyses all cases over a defined interval — it answers across everything, is the benefit–risk still positive? Aggregate reports add cumulative counts, exposure, trends, signals and literature that a single case can't show.
Lifecycle stage and market decide it. A drug in clinical development uses a DSUR (ICH E2F) for any market. A product marketed in the US uses a PADER (21 CFR 314.80). A product marketed in the EU or other ICH regions uses a PSUR/PBRER (ICH E2C(R2), GVP VII). A global marketed product typically uses a PBRER as the core document with the US PADER derived from the same locked DLP snapshot.
The DLP is the cut-off date; only cases up to that date are included. Because the case database keeps changing, a report must be generated from an immutable as-of snapshot frozen at the DLP — never the live database. Two people regenerating the same report from the same DLP must get byte-identical numbers, and a late case arriving after the DLP must not silently change a locked number.
The line listing is the case-level backbone — one row per case. The summary tabulation rolls those rows up into counts by MedDRA SOC and PT, split serious/non-serious and interval/cumulative. They must reconcile: if the interval line listing has 9 serious rows for a term, the tabulation's interval-serious cell for that term must read 9.
The rule is simple: prior cumulative + this interval = new cumulative, unless a documented reclassification explains the gap. Check it in code before the report is marked ready:
reconcile(prior, interval, new_cumulative):
expected = prior + interval
if new_cumulative == expected: # 35 + 9 = 44 ✓ reconciles
return "OK"
flag_gap(new_cumulative - expected) # 35 + 9 = 45 ✕ gap +1Why it matters
An unexplained gap between prior + interval and the reported cumulative is a classic inspection finding. Store the triggering reclassification whenever the arithmetic legitimately doesn't add up.
MedDRA coding rolls up differently across versions, so a report must record the exact version used. Pinning the version keeps history valid and lets the report be regenerated to the same numbers years later during an inspection — part of the ALCOA+ data-integrity expectation.
The substance, not the MAH, drives the PBRER — when several companies hold authorisations for the same active substance (co-marketing, licensing, generics referencing the same innovator RSI), GVP Module VII expects one harmonised Reference Safety Information and, where practical, a single-assessment / work-sharing PBRER submitted on the EURD-list schedule. Each MAH still owns its own case data and exposure figures, so the engine must support importing a partner's cases into the same DLP snapshot (or reconciling two snapshots) before the cumulative tabulation is built — treat this as a data-integration problem, not a reporting-format problem.
Sections 16–18 (signal & risk evaluation, benefit evaluation, integrated benefit–risk analysis) must reconcile against the current RMP's safety concerns list — every important identified/potential risk in the RMP should be traceable to a PBRER evaluation, and any new signal confirmed in the PBRER must trigger an RMP update in parallel, not after the fact. Inspectors specifically cross-check the PBRER signal table against the RMP Part II safety-concerns table for concerns present in one but silently missing from the other.
Expectedness is assessed against the RSI version that was in effect on each case's receipt date, not the RSI current at the DLP — the same version-by-date discipline used for the reporting rules engine's expectedness lookup.
A single reporting interval can therefore contain cases assessed against two different RSI versions; the report should state the effective RSI version(s) and the cut-over date explicitly, since re-running the same interval later must reproduce the same expected/unexpected split.
It does not go into the current report, however compelling the timing — the DLP is a hard cut-off, and slipping a late case in after generation is exactly the audit finding QC exists to prevent (see the DLP-integrity check). The correct path is: let it fall into the next interval's data, and if the case is itself expedited-reportable (serious + unexpected), it still goes out on its own ICSR timeline regardless of where the aggregate report's DLP fell. If a regulator specifically requests inclusion, that requires a documented DLP extension or an addendum, not a silent edit to the locked snapshot.
Track two identifiers, not one: an internal, ever-incrementing generation ID (every attempt, including ones that failed validation) and the regulator-facing sequence number, which should only advance on an accepted submission. If a filing is rejected before acceptance, its sequence number is reused on the corrected resubmission rather than skipped — a visible gap in the accepted sequence is itself an inspection question. Log every attempt, accepted or not, in the same evaluation/audit trail used elsewhere in the pipeline, so the full history — including the rejected attempt and its reason — is reconstructable.