ICH E2F DSUR: The Annual Safety Report Has Its Own Clock

The ICH E2F Development Safety Update Report reached Step 4 on 17 August 2010, built to give sponsors one harmonized annual safety report for a product still in clinical development, instead of a different aggregate report for every region running the trial. Most teams that already produce one treat the hard part as the template. It isn't. The hard part is the clock: the DSUR runs on the Development International Birth Date, not the calendar year, not your fiscal year, and not necessarily the date your IND went into effect — and getting that anchor wrong misaligns every downstream deadline it sets.

The one clock behind every regional deadline

A multi-region program accumulates national annual-report dates the way it accumulates everything else — one per authority, each tracked separately, each eventually treated as its own deadline. ICH E2F does not work that way. It sets a single Development International Birth Date — the date of the sponsor's first authorization to conduct a clinical trial anywhere in the world — and anchors the entire annual reporting period to it. The first DSUR period runs no longer than one year from that date; every subsequent period, and the data lock point that closes it, follows the same anniversary. For global trial sponsors, that means the DSUR calendar is set once, upstream of any individual region's submission date, not negotiated region by region.

Where the DSUR meets the IND annual report

FDA's August 2011 E2F guidance treats the DSUR as interchangeable with the IND annual report under 21 CFR 312.33 — a sponsor already producing a DIBD-anchored DSUR for other regions can submit it to satisfy the U.S. requirement rather than drafting a second document on a second schedule. That convenience has a live asterisk: FDA has proposed replacing the 312.33 annual report with an FDA-specific DSUR requirement of its own, with a data lock point set one calendar day before the anniversary of the date the IND went into effect — a different anchor than the DIBD the rest of the world's DSUR runs on. Treat that proposal as unsettled until you confirm its current status; the practical risk it already creates is sponsors assuming one DSUR clock serves every authority without checking whether the anchor dates actually match.

• Confirm the DIBD before the first cycle. Everything downstream — data lock point, drafting window, distribution dates — is set relative to it.
• Don't assume the IND anniversary and the DIBD are the same date. They frequently aren't, and FDA's proposed IND-specific DSUR variant would widen that gap rather than close it.
• Build the DSUR from the safety specification, not a generic template. The report's substance is the identified and potential risks defined in the safety specification, not a reformatted literature summary.
• Decide the synchronization question once, in writing. A DSUR can be synchronized to a PBRER's international birth date instead of maintaining two separate ones — but once synchronized, that date can't be changed.

One program, one Development International Birth Date, one DSUR clock — however many regional deadlines happen to follow from it. Why the anchor date is the whole exercise

Not a smaller PBRER

The DSUR and the PBRER get confused for the same reason the QSR and the QMSR did: they look like the same kind of document wearing a different acronym. They aren't. A DSUR evaluates an investigational product still in development against the PBRER's job, which is an integrated benefit-risk verdict on a marketed product under ICH E2C(R2). Confusing the two creates a specific, avoidable failure mode: a safety team that treats the DSUR as a lighter-weight PBRER drafts a document the DSUR's own structure doesn't call for, and a sponsor nearing marketing authorization that never explicitly plans the handoff between the two ends up with a gap — a period after DSUR reporting winds down and before PBRER reporting is actually running — where aggregate safety review quietly isn't happening at all.

None of this is exotic once the anchor date is fixed. It is a bounded piece of work: confirm the DIBD, build the data lock point and drafting timeline off it, decide explicitly how the DSUR serves each region's annual-report requirement, and name the date the handoff to PBRER reporting happens. Programs that skip the first step end up relitigating their reporting calendar every year; programs that fix it once build every later cycle on a date that doesn't move.