What the IRB wants to know: unanticipated problems, serious adverse events, protocol deviations, and safety summaries

The board that cannot oversee what it does not know

Consider a study site running a Phase II trial under a local institutional IRB. Three weeks ago, a participant was hospitalized for severe dehydration secondary to persistent vomiting -- an event the investigator assessed as possibly related to the study drug. Two weeks ago, a separate participant was discovered to have been enrolled despite meeting an exclusion criterion for a pre-existing gastrointestinal condition. Last week, the sponsor distributed its quarterly safety summary showing a signal for hepatotoxicity across all participating sites.

Each of these events carries different implications for participant safety. Each triggers different IRB reporting obligations. And each must reach the IRB through the correct channel, in the correct format, within the correct timeframe -- or the IRB's ability to exercise its oversight function is compromised.

I have spent years watching regulatory coordinators struggle not with the mechanics of IRB reporting -- the forms, the portals, the submission clicks -- but with the classification problem that precedes all of that. Which of the four categories of IRB safety reporting does this event fall under? Does it fall under more than one? Does the answer change depending on which IRB oversees this study? These are the questions that, when answered incorrectly, create the most consequential reporting failures. Not the missed deadline, but the missed obligation entirely.

This lesson builds the classification framework. You learned the regulatory requirements in Module 1. You built the triage system in Module 2 -- and when a communication passed through Gate 3 with a "yes," you flagged an IRB reporting obligation. Now it is time to understand what the IRB actually wants to know, why, and how the categories of information it requires vary in ways that directly affect the RC's workflow.

Four categories, four regulatory origins

The IRB's oversight mandate is broad. Per 45 CFR 46.109(a), the IRB must conduct continuing review of research at intervals appropriate to the degree of risk, but not less than once per year. Between those annual reviews, the IRB depends on the site to report events and findings that could alter the risk-benefit assessment for participants. But "report everything potentially relevant" is not operational guidance. The regulatory framework defines four distinct categories of information the IRB requires, each with its own source authority, reporting criteria, and timeline.

Understanding these categories is not about memorizing definitions. It is about developing the classification instinct that allows the RC to look at a safety event -- or a sponsor communication, or a protocol deviation, or an accumulation of data -- and immediately identify which category (or categories) it triggers. This classification drives everything downstream: the form, the timeline, the level of investigator input required, and the IRB's expected response.

Seeing the framework whole

Those four categories are not a list to memorize. They are a classification system the RC applies in real time, every time a safety event occurs or a sponsor communication arrives that triggers an IRB obligation. And what makes this system demanding is not its complexity -- four categories is manageable -- but the fact that the categories are not mutually exclusive.

A single event can trigger reporting under one, two, three, or even all four categories simultaneously. The hospitalization I described at the start of this lesson -- a participant hospitalized for severe dehydration -- is an SAE by definition (hospitalization). If the investigator determines it was unexpected and possibly related to the study drug, it may also be an unanticipated problem. If the participant should not have been enrolled in the first place due to a pre-existing condition, the enrollment itself is a protocol deviation. And regardless of immediate reporting, the event will appear in the next periodic safety summary for continuing review.

One event. Three immediate reports. One future summary. The RC must see all four obligations simultaneously.

When one event triggers three reports

The overlap problem is where experienced RCs distinguish themselves from those who are merely following procedures. It requires the ability to hold multiple regulatory frameworks in mind simultaneously and to determine -- for each event, at each IRB -- which obligations have been triggered.

Consider the mechanics. When a participant experiences a serious adverse event that the investigator also determines is an unanticipated problem, the RC faces a procedural question: does the site submit two separate reports to the IRB (one for the SAE, one for the unanticipated problem), or does a single submission satisfy both obligations?

The answer depends on the IRB. Some IRBs use a single reporting form that captures both the SAE details and the unanticipated problem determination. The investigator checks a box indicating the event meets the criteria for an unanticipated problem, attaches the medical assessment, and the IRB processes it as a combined report. Other IRBs maintain separate reporting pathways: an SAE report submitted through one portal and an unanticipated problem report submitted through another, with different forms, different reviewers, and occasionally different deadlines.

When a protocol deviation also constitutes a safety event, the overlap is particularly consequential. Section 1.4.8(a) requires reporting the deviation. If the deviation contributed to an SAE, Section 1.4.8(c) requires reporting the SAE. If the combined event meets the three-part test for an unanticipated problem, 45 CFR 46.103(b)(5) requires that report as well. The RC's submission strategy must address each obligation independently, even when the underlying facts are identical.

Here is the practical framework I recommend to every RC managing overlapping obligations:

Step one: list every category triggered. Before touching a form or opening a portal, identify all categories the event falls under. Write them down. This prevents the common error of submitting one report and assuming it covers everything.

Step two: check each IRB's combination policy. Can the SAE and unanticipated problem be reported together? Does the deviation require a separate form? Document the answers.

If the IRB requires unanticipated problems within five business days and SAEs within ten, the five-day deadline governs the entire submission. The RC cannot submit the unanticipated problem report on day five and the SAE report on day ten -- the SAE facts are needed in the unanticipated problem report.

The variation problem: same event, different IRB, different obligations

I have alluded to this throughout the lesson, and now it is time to address it directly. The most operationally challenging aspect of IRB safety reporting for a multi-IRB portfolio is not the complexity of any single IRB's requirements. It is the variation across IRBs.

A site running 12 studies under three different IRBs -- say, a local institutional IRB, a central commercial IRB, and a second central IRB used by a different sponsor -- may face three entirely different reporting frameworks for the same type of event. The local IRB requires all SAEs regardless of relatedness or expectedness. The first central IRB requires only those events meeting the OHRP definition of unanticipated problems. The second central IRB uses a hybrid approach: report all SAEs for the first 90 days post-enrollment, then only unanticipated problems thereafter.

Same event. Same participant population. Three different reporting obligations. The RC must know each IRB's requirements for each study and apply the correct framework to each event.

This variation is not a flaw in the system. It reflects the fact that IRBs exercise independent judgment about the information they need to fulfill their oversight responsibilities, consistent with ICH E6(R3) Principle 3, which establishes that trials should be subject to independent review by an IRB/IEC. But independent judgment produces operational diversity, and the RC must manage that diversity without error.

The practical solution is an IRB requirements matrix -- a reference document that maps each active study to its IRB and records that IRB's specific requirements for each reporting category. This matrix answers, at a glance, the question the RC asks every time a reportable event occurs: "For this study, under this IRB, what exactly must I submit, in what format, by when?"

Building this matrix is not optional for any RC managing more than a handful of studies. I have seen sites attempt to manage IRB variation through institutional memory alone -- "I know WCG wants unanticipated problems only, and our local IRB wants everything." That approach works until it does not: until a new study comes under a third IRB, until the local IRB updates its policies, until the RC who held the institutional memory takes a new position. The matrix externalizes that knowledge and makes it auditable.

What comes next

This lesson established the classification framework: four categories of IRB safety reporting, each with a distinct regulatory origin, and the reality that a single event may trigger obligations under multiple categories simultaneously. You also confronted the variation problem -- the fact that different IRBs require different things, and the RC must manage that variation systematically rather than from memory.

But classification is only the beginning. Knowing that the IRB requires reports on unanticipated problems does not answer the harder question: how does the investigator determine whether a specific event is, in fact, an unanticipated problem? That determination requires applying the OHRP three-part test -- unexpected, related or possibly related, suggests increased risk -- to the specific facts of the event. And how IRBs interpret that test varies just as much as their reporting requirements vary.

Lesson 2 takes you into that determination process. The classification framework you built here tells you the IRB wants to know. The reportability framework in Lesson 2 tells you whether a specific event meets the criteria.