What the IRB wants to know: unanticipated problems, serious adverse events, protocol deviations, and safety summaries
Classify the four primary categories of IRB safety reporting, analyze how a single event can trigger overlapping obligations, and evaluate the operational impact of IRB variation across a multi-IRB portfolio.
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.
What you will learn
By the end of this lesson, you will be able to:
1
Classify the four primary categories of IRB safety reporting -- unanticipated problems, serious adverse events, protocol deviations, and periodic safety summaries -- and identify the regulatory source for each
2
Analyze how a single safety event may simultaneously trigger reporting under multiple categories, and determine the RC's documentation and submission strategy
3
Evaluate the variation in IRB reporting requirements across central, local, and commercial IRBs, identifying operational implications for a multi-IRB portfolio
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.
Classification drives workflow
The RC does not decide whether something is reported to the IRB. That determination was made in Module 2 when the communication passed through Gate 3. What the RC determines here is under which category the report is submitted. This distinction matters because each category carries different documentation requirements, different timelines, and -- critically -- different expectations for what the IRB will do with the information once received.
What it is: An event, experience, or outcome that is (1) unexpected in terms of nature, severity, or frequency; (2) related or possibly related to participation in the research; and (3) suggests that the research places participants or others at a greater risk of harm than was previously known or recognized. This is the OHRP three-part test, which Lesson 2 will explore in depth.
What it is NOT: A synonym for 'serious adverse event.' Many SAEs are expected and listed in the Investigator's Brochure. An expected SAE that occurs at the expected frequency is not an unanticipated problem. The distinction between expected and unexpected is the critical first filter.
Typical reporting timeline: Prompt reporting -- most IRBs require notification within 5-10 business days of the investigator becoming aware of the event. Some IRBs require reporting within 48 hours for events involving immediate risk.
RC's operational note: This is the category that requires the most judgment. The investigator must determine whether the three-part test is met. The RC's role is to ensure the investigator makes that determination, documents it, and submits the report within the IRB's required timeframe.
Regulatory source: ICH E6(R3) Annex 1, Section 1.4.8(c)-(d), and 21 CFR 312.32 (for IND studies)
What it is: A serious adverse event -- any untoward medical occurrence that results in death, is life-threatening, requires hospitalization or prolongation of existing hospitalization, results in persistent or significant disability, causes a congenital anomaly, or is an important medical event -- reported to the IRB according to that specific IRB's requirements. And this is where it gets complicated, because IRBs differ dramatically in what SAE reporting they require.
The variation problem: Some IRBs require reporting of ALL SAEs regardless of expectedness or relatedness. Others require only those SAEs the investigator assesses as related and unexpected. Still others use a hybrid approach: report all SAEs for the first year of a study, then only unanticipated problems thereafter. Section 1.4.8(c) requires reporting to the IRB of all suspected unexpected serious adverse reactions (SUSARs) in accordance with applicable regulatory requirements -- but many IRBs layer their own requirements on top of the regulatory minimum.
Typical reporting timeline: Varies by IRB -- ranges from 24 hours (for deaths) to 10 business days (for non-fatal SAEs at IRBs requiring comprehensive reporting).
RC's operational note: The RC must maintain an IRB-specific matrix that maps each study to its IRB and that IRB's SAE reporting requirements. Assuming all IRBs want the same thing is the most common operational error in multi-IRB portfolios.
Regulatory source: ICH E6(R3) Annex 1, Section 1.4.8(a), and 21 CFR 56.108(b)
What it is: A departure from the IRB-approved protocol that requires IRB notification. Section 1.4.8(a) specifies that the investigator should not implement any deviation from the protocol without prior IRB approval except where necessary to eliminate an immediate hazard to the participant. Deviations made to eliminate immediate hazards must still be reported to the IRB as soon as possible.
What it is NOT: Not all protocol deviations require IRB reporting. Minor logistical deviations (e.g., a visit window exceeded by two days with no safety impact) may require only internal documentation. The distinction between IRB-reportable deviations and internally documented deviations is defined by each IRB's policies -- and again, these policies vary across IRBs.
Typical reporting timeline: Deviations made to eliminate immediate hazards must be reported as soon as possible. Other reportable deviations are typically due within 5-10 business days, though some IRBs require reporting at the next continuing review rather than in real time.
RC's operational note: The RC's task is not to document the deviation itself -- that is a CRC competency covered elsewhere. The RC ensures that deviations identified as IRB-reportable are submitted to the correct IRB, in the correct format, within the required timeline. For deviations that also constitute safety events, the RC must determine whether multiple reports are required.
Regulatory source: ICH E6(R3) Sections 2.4.5 and 1.2.4, and 45 CFR 46.109(e)
What it is: Aggregate safety data compiled for the IRB's annual continuing review. Section 2.4.5 establishes that the IRB should receive the information necessary to perform ongoing risk-benefit assessment. Section 1.2.4 reinforces that oversight activities should be proportionate to the risks identified in the study. The periodic safety summary is the mechanism through which the IRB evaluates whether the cumulative safety profile remains acceptable.
What it includes: Typically: a summary of all AEs and SAEs by type and severity, enrollment status, protocol deviations to date, any new safety information from the sponsor (IND Safety Reports, IB updates, DSMB communications), and the investigator's overall assessment of the study's risk-benefit profile.
Typical reporting timeline: Annually, aligned with the IRB's continuing review schedule. Due dates are set by the IRB and typically require submission 4-6 weeks before the protocol's approval expiration date.
RC's operational note: This is the most operationally complex category because it requires data aggregation across the full span of the study. The RC manages the preparation calendar, identifies data collection windows, and coordinates with the CRC (who compiles per-study AE data) and the investigator (who provides the medical assessment). Module 3, Lesson 4 will cover annual safety summary construction in detail.
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.
Figure 1: The four categories of IRB safety reporting and their regulatory sources. A single safety event may fall into the overlap zone, triggering reporting under multiple categories 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.
Never assume reports can be combined
Before submitting a single report to cover multiple categories, verify that the IRB's policies explicitly permit combined reporting. If the IRB's guidance is silent on the question, submit separate reports. An over-submission (two reports for one event) creates a minor administrative burden. An under-submission (one report when two were required) creates a compliance gap the RC may not discover until an audit. When in doubt, separate is safer.
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.
Step three: identify the shortest deadline. 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.
Step four: verify prerequisites. Before any IRB safety report is submitted, the investigator's assessment must be complete and documented. The RC does not submit safety reports without the investigator's medical determination. This is the handoff point where Module 4's content -- supporting the investigator's safety assessment -- becomes directly relevant.
Cross-reference overlapping reports in the tracking system
When a single event generates multiple IRB reports, link them in the tracking system using a common event identifier. This creates a single audit trail: one event, multiple reports, all traceable to the same source. Without this cross-reference, the site may not be able to reconstruct the complete reporting history during an inspection.
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.
Key takeaway: the IRB requirements matrix is a living document
Review and update the matrix every time a new study is added to the portfolio, every time an IRB revises its policies, and at least annually as part of the RC's quality management review. An outdated matrix is worse than no matrix at all, because it creates false confidence in compliance.
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 what the IRB wants to know. The reportability framework in Lesson 2 tells you how to decide whether a specific event meets the criteria.
Check your understanding
1 of 3
A participant in a clinical trial experiences a seizure that results in an emergency department visit but not hospitalization. The event is listed in the Investigator's Brochure as an expected adverse reaction at the reported frequency. The investigator assesses it as related to the study drug. Under which IRB safety reporting category does this event most likely fall?
Key takeaways
IRB safety reporting is not a single obligation but a classification problem with four distinct categories: unanticipated problems (45 CFR 46.103(b)(5) and OHRP guidance), serious adverse events per IRB-specific criteria (ICH E6(R3) Section 1.4.8(c)-(d)), protocol deviations requiring IRB notification (Section 1.4.8(a)), and periodic safety summaries for continuing review (Sections 2.4.5 and 1.2.4). Each category has its own regulatory source, reporting criteria, and timeline.
The most consequential challenge is not complexity but overlap: a single event can trigger reporting under multiple categories simultaneously, and the RC must identify all triggered obligations before submitting any report. When in doubt about whether reports can be combined, submit separately and cross-reference. An extra submission is an inconvenience. A missing submission is a compliance failure.
And the variation across IRBs is real. Different IRBs define reportable events differently, use different forms, impose different timelines, and permit or prohibit combined submissions differently. The RC managing a multi
IRB portfolio must maintain an IRB requirements matrix -- a living reference document that maps each study to its IRB's specific reporting framework. This lesson gave you the classification system. Lesson 2 gives you the determination framework: how to apply the OHRP three-part test and navigate the interpretive variation that makes reportability decisions genuinely difficult.
Enjoyed this preview?
Enroll to access all courses in the Regulatory Coordinator track.
What the IRB wants to know: unanticipated problems, serious adverse events, protocol deviations, and safety summaries
Classify the four primary categories of IRB safety reporting, analyze how a single event can trigger overlapping obligations, and evaluate the operational impact of IRB variation across a multi-IRB portfolio.
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.
What you will learn
By the end of this lesson, you will be able to:
1
Classify the four primary categories of IRB safety reporting -- unanticipated problems, serious adverse events, protocol deviations, and periodic safety summaries -- and identify the regulatory source for each
2
Analyze how a single safety event may simultaneously trigger reporting under multiple categories, and determine the RC's documentation and submission strategy
3
Evaluate the variation in IRB reporting requirements across central, local, and commercial IRBs, identifying operational implications for a multi-IRB portfolio
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.
Classification drives workflow
The RC does not decide whether something is reported to the IRB. That determination was made in Module 2 when the communication passed through Gate 3. What the RC determines here is under which category the report is submitted. This distinction matters because each category carries different documentation requirements, different timelines, and -- critically -- different expectations for what the IRB will do with the information once received.
What it is: An event, experience, or outcome that is (1) unexpected in terms of nature, severity, or frequency; (2) related or possibly related to participation in the research; and (3) suggests that the research places participants or others at a greater risk of harm than was previously known or recognized. This is the OHRP three-part test, which Lesson 2 will explore in depth.
What it is NOT: A synonym for 'serious adverse event.' Many SAEs are expected and listed in the Investigator's Brochure. An expected SAE that occurs at the expected frequency is not an unanticipated problem. The distinction between expected and unexpected is the critical first filter.
Typical reporting timeline: Prompt reporting -- most IRBs require notification within 5-10 business days of the investigator becoming aware of the event. Some IRBs require reporting within 48 hours for events involving immediate risk.
RC's operational note: This is the category that requires the most judgment. The investigator must determine whether the three-part test is met. The RC's role is to ensure the investigator makes that determination, documents it, and submits the report within the IRB's required timeframe.
Regulatory source: ICH E6(R3) Annex 1, Section 1.4.8(c)-(d), and 21 CFR 312.32 (for IND studies)
What it is: A serious adverse event -- any untoward medical occurrence that results in death, is life-threatening, requires hospitalization or prolongation of existing hospitalization, results in persistent or significant disability, causes a congenital anomaly, or is an important medical event -- reported to the IRB according to that specific IRB's requirements. And this is where it gets complicated, because IRBs differ dramatically in what SAE reporting they require.
The variation problem: Some IRBs require reporting of ALL SAEs regardless of expectedness or relatedness. Others require only those SAEs the investigator assesses as related and unexpected. Still others use a hybrid approach: report all SAEs for the first year of a study, then only unanticipated problems thereafter. Section 1.4.8(c) requires reporting to the IRB of all suspected unexpected serious adverse reactions (SUSARs) in accordance with applicable regulatory requirements -- but many IRBs layer their own requirements on top of the regulatory minimum.
Typical reporting timeline: Varies by IRB -- ranges from 24 hours (for deaths) to 10 business days (for non-fatal SAEs at IRBs requiring comprehensive reporting).
RC's operational note: The RC must maintain an IRB-specific matrix that maps each study to its IRB and that IRB's SAE reporting requirements. Assuming all IRBs want the same thing is the most common operational error in multi-IRB portfolios.
Regulatory source: ICH E6(R3) Annex 1, Section 1.4.8(a), and 21 CFR 56.108(b)
What it is: A departure from the IRB-approved protocol that requires IRB notification. Section 1.4.8(a) specifies that the investigator should not implement any deviation from the protocol without prior IRB approval except where necessary to eliminate an immediate hazard to the participant. Deviations made to eliminate immediate hazards must still be reported to the IRB as soon as possible.
What it is NOT: Not all protocol deviations require IRB reporting. Minor logistical deviations (e.g., a visit window exceeded by two days with no safety impact) may require only internal documentation. The distinction between IRB-reportable deviations and internally documented deviations is defined by each IRB's policies -- and again, these policies vary across IRBs.
Typical reporting timeline: Deviations made to eliminate immediate hazards must be reported as soon as possible. Other reportable deviations are typically due within 5-10 business days, though some IRBs require reporting at the next continuing review rather than in real time.
RC's operational note: The RC's task is not to document the deviation itself -- that is a CRC competency covered elsewhere. The RC ensures that deviations identified as IRB-reportable are submitted to the correct IRB, in the correct format, within the required timeline. For deviations that also constitute safety events, the RC must determine whether multiple reports are required.
Regulatory source: ICH E6(R3) Sections 2.4.5 and 1.2.4, and 45 CFR 46.109(e)
What it is: Aggregate safety data compiled for the IRB's annual continuing review. Section 2.4.5 establishes that the IRB should receive the information necessary to perform ongoing risk-benefit assessment. Section 1.2.4 reinforces that oversight activities should be proportionate to the risks identified in the study. The periodic safety summary is the mechanism through which the IRB evaluates whether the cumulative safety profile remains acceptable.
What it includes: Typically: a summary of all AEs and SAEs by type and severity, enrollment status, protocol deviations to date, any new safety information from the sponsor (IND Safety Reports, IB updates, DSMB communications), and the investigator's overall assessment of the study's risk-benefit profile.
Typical reporting timeline: Annually, aligned with the IRB's continuing review schedule. Due dates are set by the IRB and typically require submission 4-6 weeks before the protocol's approval expiration date.
RC's operational note: This is the most operationally complex category because it requires data aggregation across the full span of the study. The RC manages the preparation calendar, identifies data collection windows, and coordinates with the CRC (who compiles per-study AE data) and the investigator (who provides the medical assessment). Module 3, Lesson 4 will cover annual safety summary construction in detail.
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.
Figure 1: The four categories of IRB safety reporting and their regulatory sources. A single safety event may fall into the overlap zone, triggering reporting under multiple categories 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.
Never assume reports can be combined
Before submitting a single report to cover multiple categories, verify that the IRB's policies explicitly permit combined reporting. If the IRB's guidance is silent on the question, submit separate reports. An over-submission (two reports for one event) creates a minor administrative burden. An under-submission (one report when two were required) creates a compliance gap the RC may not discover until an audit. When in doubt, separate is safer.
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.
Step three: identify the shortest deadline. 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.
Step four: verify prerequisites. Before any IRB safety report is submitted, the investigator's assessment must be complete and documented. The RC does not submit safety reports without the investigator's medical determination. This is the handoff point where Module 4's content -- supporting the investigator's safety assessment -- becomes directly relevant.
Cross-reference overlapping reports in the tracking system
When a single event generates multiple IRB reports, link them in the tracking system using a common event identifier. This creates a single audit trail: one event, multiple reports, all traceable to the same source. Without this cross-reference, the site may not be able to reconstruct the complete reporting history during an inspection.
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.
Key takeaway: the IRB requirements matrix is a living document
Review and update the matrix every time a new study is added to the portfolio, every time an IRB revises its policies, and at least annually as part of the RC's quality management review. An outdated matrix is worse than no matrix at all, because it creates false confidence in compliance.
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 what the IRB wants to know. The reportability framework in Lesson 2 tells you how to decide whether a specific event meets the criteria.
Check your understanding
1 of 3
A participant in a clinical trial experiences a seizure that results in an emergency department visit but not hospitalization. The event is listed in the Investigator's Brochure as an expected adverse reaction at the reported frequency. The investigator assesses it as related to the study drug. Under which IRB safety reporting category does this event most likely fall?
Key takeaways
IRB safety reporting is not a single obligation but a classification problem with four distinct categories: unanticipated problems (45 CFR 46.103(b)(5) and OHRP guidance), serious adverse events per IRB-specific criteria (ICH E6(R3) Section 1.4.8(c)-(d)), protocol deviations requiring IRB notification (Section 1.4.8(a)), and periodic safety summaries for continuing review (Sections 2.4.5 and 1.2.4). Each category has its own regulatory source, reporting criteria, and timeline.
The most consequential challenge is not complexity but overlap: a single event can trigger reporting under multiple categories simultaneously, and the RC must identify all triggered obligations before submitting any report. When in doubt about whether reports can be combined, submit separately and cross-reference. An extra submission is an inconvenience. A missing submission is a compliance failure.
And the variation across IRBs is real. Different IRBs define reportable events differently, use different forms, impose different timelines, and permit or prohibit combined submissions differently. The RC managing a multi
IRB portfolio must maintain an IRB requirements matrix -- a living reference document that maps each study to its IRB's specific reporting framework. This lesson gave you the classification system. Lesson 2 gives you the determination framework: how to apply the OHRP three-part test and navigate the interpretive variation that makes reportability decisions genuinely difficult.
Enjoyed this preview?
Enroll to access all courses in the Regulatory Coordinator track.
All SAEs regardless of expectedness or relatedness
Only SAEs meeting the unanticipated problem criteria (unexpected + related + increased risk)
The RC must apply different filters to the same event depending on which IRB oversees the study
Protocol deviation reporting
All deviations reported at continuing review unless they affect participant safety
Major deviations reported in real time; minor deviations reported at continuing review
The RC must classify the deviation severity using each IRB's definitions, which may differ
Reporting timeline for unanticipated problems
Within 5 business days of the investigator becoming aware
Within 10 calendar days with follow-up within 30 days
Timelines are not interchangeable; the RC must track each IRB's specific deadlines per study
Periodic safety summary format
Institution-specific template with predefined sections
IRB-provided online form with structured data fields
The RC must maintain familiarity with multiple formats and cannot apply a single template across all studies
Combined vs. separate reports
Single form accommodates SAE + unanticipated problem
Separate submission pathways for SAEs and unanticipated problems
The RC must determine per-IRB whether overlapping obligations can be satisfied with one submission
Case Study
"The dual-obligation hospitalization"
Clinical ResearchIntermediate10-15 minutes
Scenario
At Pacific Coast Research Institute, a participant in the HORIZON trial -- a Phase II cardiovascular outcomes study -- presents to the emergency department with severe nausea and is admitted for IV fluid resuscitation after 48 hours of intractable vomiting. The hospitalization meets the definition of a serious adverse event. Dr. David Park, the principal investigator, reviews the case and notes that the nausea is not listed in the Investigator's Brochure as an expected adverse reaction at this severity. He assesses the event as possibly related to the study drug.
During the investigation, a CRC reviewing the participant's source documents discovers that the participant has a documented history of gastroparesis -- a pre-existing gastrointestinal condition that was listed as an exclusion criterion in the HORIZON protocol. The participant should not have been enrolled. The enrollment constitutes a protocol deviation.
Dr. Park now faces a participant who experienced an SAE while enrolled in violation of the protocol's exclusion criteria. The RC at Pacific Coast must determine all IRB reporting obligations triggered by this event.
Pacific Coast Research Institute submits to two IRBs across its portfolio: a central commercial IRB for HORIZON and an institutional IRB for other studies. The central IRB requires reporting only of events meeting the unanticipated problem criteria. It uses a single combined reporting form for SAE and unanticipated problem submissions. The institutional IRB is not involved in HORIZON but the RC needs to know whether any cross-study reporting obligations exist.
The challenge:
As the regulatory coordinator, classify this event under all applicable IRB reporting categories. Determine whether the central IRB requires one report or multiple reports. Identify what information must be verified before any submission occurs.
Analysis
Category identification: This event triggers at least three of the four categories. It is an SAE (hospitalization). The investigator has assessed it as unexpected in severity and possibly related, which may satisfy the criteria for an unanticipated problem -- though the definitive determination requires applying the three-part test, which Lesson 2 will cover in depth. The enrollment of an excluded participant is a protocol deviation requiring IRB notification per Section 1.4.8(a). The event will also appear in the next periodic safety summary.
Combined vs. separate reporting determination: The central commercial IRB uses a combined form for SAE and unanticipated problem submissions and requires only events meeting the unanticipated problem criteria. If Dr. Park's assessment confirms the event meets all three prongs of the OHRP test, a single combined report may satisfy both the SAE and unanticipated problem obligations. However, the protocol deviation is a separate category. The RC must verify whether the central IRB accepts deviation reports on the same form or requires a separate submission.
Pre-submission verification: Before any report is submitted, the RC must verify: (1) Dr. Park's written assessment of relatedness and expectedness is complete and documented; (2) the source documentation confirming the pre-existing gastroparesis and the exclusion criterion violation is assembled; (3) the IRB's specific timeline for each report type is confirmed; (4) the participant's current clinical status is documented, as the IRB will want to know the participant's condition at the time of reporting.
Cross-study awareness: Although the institutional IRB does not oversee HORIZON, the RC should assess whether the protocol deviation pattern -- an enrollment criterion violation -- has occurred in any other study in the portfolio. A single deviation is an event. A pattern of enrollment criterion violations across studies may constitute a systemic quality issue that the RC should flag for the site's quality management review.
Reference Table
IRB variation in safety reporting requirements
Reporting dimension
Local institutional IRB (typical)
Central commercial IRB (typical)
Operational implication for the RC
SAE reporting scope
All SAEs regardless of expectedness or relatedness
Only SAEs meeting the unanticipated problem criteria (unexpected + related + increased risk)
The RC must apply different filters to the same event depending on which IRB oversees the study
Protocol deviation reporting
All deviations reported at continuing review unless they affect participant safety
Major deviations reported in real time; minor deviations reported at continuing review
The RC must classify the deviation severity using each IRB's definitions, which may differ
Reporting timeline for unanticipated problems
Within 5 business days of the investigator becoming aware
Within 10 calendar days with follow-up within 30 days
Timelines are not interchangeable; the RC must track each IRB's specific deadlines per study
Periodic safety summary format
Institution-specific template with predefined sections
IRB-provided online form with structured data fields
The RC must maintain familiarity with multiple formats and cannot apply a single template across all studies
Combined vs. separate reports
Single form accommodates SAE + unanticipated problem
Separate submission pathways for SAEs and unanticipated problems
The RC must determine per-IRB whether overlapping obligations can be satisfied with one submission
Case Study
"The dual-obligation hospitalization"
Clinical ResearchIntermediate10-15 minutes
Scenario
At Pacific Coast Research Institute, a participant in the HORIZON trial -- a Phase II cardiovascular outcomes study -- presents to the emergency department with severe nausea and is admitted for IV fluid resuscitation after 48 hours of intractable vomiting. The hospitalization meets the definition of a serious adverse event. Dr. David Park, the principal investigator, reviews the case and notes that the nausea is not listed in the Investigator's Brochure as an expected adverse reaction at this severity. He assesses the event as possibly related to the study drug.
During the investigation, a CRC reviewing the participant's source documents discovers that the participant has a documented history of gastroparesis -- a pre-existing gastrointestinal condition that was listed as an exclusion criterion in the HORIZON protocol. The participant should not have been enrolled. The enrollment constitutes a protocol deviation.
Dr. Park now faces a participant who experienced an SAE while enrolled in violation of the protocol's exclusion criteria. The RC at Pacific Coast must determine all IRB reporting obligations triggered by this event.
Pacific Coast Research Institute submits to two IRBs across its portfolio: a central commercial IRB for HORIZON and an institutional IRB for other studies. The central IRB requires reporting only of events meeting the unanticipated problem criteria. It uses a single combined reporting form for SAE and unanticipated problem submissions. The institutional IRB is not involved in HORIZON but the RC needs to know whether any cross-study reporting obligations exist.
The challenge:
As the regulatory coordinator, classify this event under all applicable IRB reporting categories. Determine whether the central IRB requires one report or multiple reports. Identify what information must be verified before any submission occurs.
Analysis
Category identification: This event triggers at least three of the four categories. It is an SAE (hospitalization). The investigator has assessed it as unexpected in severity and possibly related, which may satisfy the criteria for an unanticipated problem -- though the definitive determination requires applying the three-part test, which Lesson 2 will cover in depth. The enrollment of an excluded participant is a protocol deviation requiring IRB notification per Section 1.4.8(a). The event will also appear in the next periodic safety summary.
Combined vs. separate reporting determination: The central commercial IRB uses a combined form for SAE and unanticipated problem submissions and requires only events meeting the unanticipated problem criteria. If Dr. Park's assessment confirms the event meets all three prongs of the OHRP test, a single combined report may satisfy both the SAE and unanticipated problem obligations. However, the protocol deviation is a separate category. The RC must verify whether the central IRB accepts deviation reports on the same form or requires a separate submission.
Pre-submission verification: Before any report is submitted, the RC must verify: (1) Dr. Park's written assessment of relatedness and expectedness is complete and documented; (2) the source documentation confirming the pre-existing gastroparesis and the exclusion criterion violation is assembled; (3) the IRB's specific timeline for each report type is confirmed; (4) the participant's current clinical status is documented, as the IRB will want to know the participant's condition at the time of reporting.
Cross-study awareness: Although the institutional IRB does not oversee HORIZON, the RC should assess whether the protocol deviation pattern -- an enrollment criterion violation -- has occurred in any other study in the portfolio. A single deviation is an event. A pattern of enrollment criterion violations across studies may constitute a systemic quality issue that the RC should flag for the site's quality management review.
