Adverse Event of Special Interest (AESI)

An Adverse Event of Special Interest (AESI) is an adverse event — serious or non-serious — that a trial sponsor identifies in advance, in the study protocol, as warranting enhanced monitoring and expedited investigator-to-sponsor reporting because there is a specific scientific or medical reason to suspect a link to the investigational product or research programme.

AESIs are a defining feature of vaccine trials, gene and cell therapy studies, and other high-scrutiny interventions where a mechanistic risk, a class-effect signal, or a prior safety finding is already known before enrollment starts.

How AESI differs from AE and SAE

The general Adverse Event (AE) definition under ICH E2A is causality-neutral and open-ended: any untoward medical occurrence in a participant, whether or not it is considered related to the intervention. A Serious Adverse Event (SAE) is an AE that crosses a defined severity threshold — death, a life-threatening event, hospitalization or prolongation of hospitalization, persistent or significant disability, a congenital anomaly, or another event judged ‘otherwise medically important.’ Both AE and SAE are classified retrospectively, after the event occurs, against criteria that apply the same way across essentially any trial.

An AESI is different on both axes. It is defined prospectively — named, by event, in the protocol or an accompanying safety monitoring plan before the first participant is enrolled — and it is defined by the reason for concern, not by severity. A non-serious event that would otherwise be captured only in routine AE logs can still be an AESI if it is on the pre-specified list, and it will then follow the AESI programme’s enhanced procedures (dedicated case-definition criteria, expedited reporting timelines, and often independent clinical-events-committee adjudication) rather than the routine AE pathway. In practice, most AESIs are also serious, but seriousness and AESI status are separate, independently-determined properties of the same event, and a protocol can and often does designate non-serious events as AESIs precisely because early signal detection matters more than the event’s individual severity.

Where the AESI concept comes from

The AESI concept is embedded in the ICH E2F guideline (Development Safety Update Report, finalized 2010), which describes adverse events of special interest as events of scientific and medical concern specific to the sponsor’s product or programme, for which ongoing monitoring and rapid communication from investigator to sponsor is appropriate — and for which the protocol should explain the basis for selecting each event. A Development Safety Update Report (DSUR) is required to summarize cumulative AESI experience across the reporting period alongside routine SAE/SUSAR data, which is one of the main downstream reasons sponsors maintain a clean, explicit AESI list from the start of a programme rather than reconstructing one later.

Why protocols pre-specify AESIs

• Known mechanistic risk. The product class has a biologically plausible pathway to a specific harm (e.g. immune-mediated reactions for a novel biologic, insertional oncogenesis for a gene therapy vector), even if no case has yet occurred in this particular programme.
• Prior signal from the same class or an earlier study. A related product, an earlier trial phase, or post-market experience with a comparable intervention surfaced a specific safety concern that this protocol now watches for deliberately.
• Regulatory expectation. Regulators reviewing a novel platform (vaccines, cell and gene therapy, biosimilars) frequently expect a pre-specified AESI list and an associated safety monitoring plan as a condition of proceeding, so the sponsor and regulator are watching for the same defined set of outcomes throughout the programme.
• Faster signal detection. Naming the event and its case definition in advance means every site captures it the same way, using the same diagnostic criteria, which materially shortens the time between a real signal emerging and the sponsor being able to recognize and act on it — compared to noticing a pattern only after the fact across loosely-coded routine AE terms.

How AESIs are operationalized

A well-constructed AESI programme typically includes a written case definition or diagnostic algorithm for each listed event (often adapted from an external standard, such as Brighton Collaboration case definitions in vaccine safety work), a dedicated data-capture form distinct from the routine AE case report form, an expedited investigator-to-sponsor reporting timeline that can be shorter than the protocol’s routine AE schedule, and, for many programmes, independent adjudication of reported cases by a clinical events committee or the trial’s safety monitoring board, to confirm each case actually meets the pre-specified definition before it is counted. This is separate infrastructure from, and in addition to, the general AE, SAE, and SUSAR reporting obligations that apply to every trial regardless of whether it has an AESI list at all.

Frequently asked questions

Is every AESI also a Serious Adverse Event?

No. AESI status and SAE status are determined independently. Most AESIs in practice turn out to be serious, because sponsors tend to pre-specify events they are genuinely worried about, but a protocol can designate a non-serious event as an AESI when early detection of that specific event matters for safety-signal purposes, and that event still follows AESI-level reporting even though it does not meet the ICH E2A seriousness criteria.

Who decides what counts as an AESI for a given trial?

The sponsor, informed by nonclinical data, prior clinical experience with the product or its class, and often direct input or expectations from the reviewing regulatory authority, defines the AESI list in the protocol and/or a companion safety monitoring plan, and is expected to document the scientific basis for each event selected.

Does an AESI have a different reporting timeline than a routine SAE?

The protocol and safety monitoring plan set the specific timeline for each programme; AESI reporting is frequently expedited relative to routine AE reporting, and cases are commonly routed through additional steps (dedicated forms, independent adjudication) that a routine, non-AESI AE would not go through, even when both are eventually captured in the same DSUR.

How does AESI relate to a DSUR?

The DSUR is the periodic aggregate safety report (annual, anchored to the product’s development international birth date) that summarizes cumulative safety experience across a development programme, and cumulative AESI data — not just SAEs and SUSARs — is an expected component of that summary for programmes that maintain an AESI list.