Monday morning, three frameworks deep

It is 8:15 on a Monday morning. The regulatory coordinator opens the shared safety inbox and finds three items waiting:

First, an IND Safety Report from a pharmaceutical sponsor. The sponsor is fulfilling its obligation under 21 CFR 312.32(c)(1)(i) to notify all participating investigators of a Suspected Unexpected Serious Adverse Reaction that occurred at another site in the trial. The investigator must review this report. And the IRB must receive it -- but under which timeline? That depends on the IRB's interpretation of 45 CFR 46.103(b)(5) and whatever reporting policy the IRB has established for inbound SUSAR notifications.

Second, an email from the IRB requesting the site's overdue annual safety summary for a Phase II cardiovascular trial. The IRB's continuing review requires current safety data per 45 CFR 46.109(e), and the site is seven days past the submission deadline. This is a compliance gap the RC must close immediately.

Third, an internal flag from a CRC: the investigator completed a causality assessment on a serious adverse event late Friday, and the completed SAE report has not yet been transmitted to the sponsor. Per ICH E6(R3) Annex 1, Section 2.7.2(b), SAEs should be reported to the sponsor "immediately." The RC needs to transmit this report within hours, not days.

Three items. Three different regulatory sources. Three distinct obligations generating three different RC tasks. This is not a hypothetical -- it is a representative Monday for any RC managing a multi-study portfolio at an active investigator site.

In the previous two lessons, we mapped the safety reporting pipeline and established the role boundaries within it. Now we turn to the question that every RC must be able to answer with precision: What, exactly, do the regulations require? Not approximately. Not "whatever the sponsor says." The specific provisions, from the specific regulations, that generate the specific obligations the RC must fulfill.

Three frameworks, one desk

The regulatory coordinator's safety reporting obligations do not emerge from a single source. They emerge from three overlapping regulatory frameworks, each with its own authority, its own requirements, and its own enforcement mechanisms. Understanding where these frameworks overlap -- and where they diverge -- is fundamental to competent regulatory coordination.

ICH E6(R3) provides the international standard for Good Clinical Practice, including investigator and sponsor safety reporting obligations. Adopted on 06 January 2025, E6(R3) is the authoritative GCP guideline referenced in clinical trial agreements worldwide. Its safety provisions appear primarily in Annex 1, Sections 2.7.2 (investigator safety reporting), 3.13.1--3.13.3 (sponsor safety assessment and reporting), and 1.4.8 (IRB reporting requirements).

21 CFR 312.32 is the FDA regulation governing IND safety reporting. It specifies what the sponsor must report to the FDA and to investigators, the timelines for those reports, and the definitions that determine which events trigger expedited reporting. For the RC at a U.S. site, this regulation governs the IND Safety Reports that arrive in the inbox and the sponsor reporting obligations that drive SAE submission timelines.

45 CFR 46 -- the Common Rule -- establishes the requirements for IRB oversight of human subjects research. While it does not prescribe specific safety reporting forms, it requires IRBs to conduct continuing review and to be notified of events that affect participant safety. The IRB's interpretation of 45 CFR 46 generates the site's IRB safety reporting obligations, which the RC must execute.

I want to be precise about something that new regulatory coordinators sometimes misunderstand: these frameworks are not redundant. They address different aspects of the safety reporting system, and they impose obligations on different parties. A single safety event at a site can trigger requirements under all three frameworks simultaneously -- and the RC must satisfy each one according to its own terms, its own timeline, and its own documentation standard.

ICH E6(R3): the investigator's safety reporting obligations

Let us begin where the previous two lessons left off -- with the investigator's safety reporting obligations under ICH E6(R3) Annex 1, Section 2.7.2. We addressed these provisions in L1 and L2 in the context of the pipeline and role boundaries. Now I want you to read them as what they are: regulatory requirements that generate specific, traceable RC tasks.

Section 2.7.2(a): reporting AEs and abnormal test results to the sponsor

The provision states: adverse events and abnormal test results required for safety evaluations "should be reported to the sponsor according to the reporting requirements and within the time periods specified in the protocol."

This provision does two things for the RC. First, it establishes that the protocol -- not E6(R3) alone -- defines the specific reporting requirements and timelines. The RC must know each study's protocol-specific safety reporting plan, because the timeline for reporting a non-serious AE may be 24 hours in one protocol and five business days in another. Second, it means the RC must maintain current knowledge of which events are "required for safety evaluations" in each study, because that threshold varies by protocol.

RC task generated: Maintain a protocol-by-protocol reference of safety reporting thresholds and timelines. Monitor compliance with protocol-specific timelines for each active study.

Section 2.7.2(b): SAE reporting with causality assessment

The provision states: all SAEs "should be reported immediately (after the investigator reasonably becomes aware of the event) to the sponsor," and "the investigator should also include an assessment of causality."

This is the provision that drives the most time-sensitive RC work. "Immediately" is not a defined number of hours in E6(R3) -- it is operationally interpreted through the protocol's safety reporting plan, which typically specifies 24 hours for initial notification. But "immediately" also means the RC cannot batch SAE transmissions. Each completed SAE report must be transmitted to the sponsor as soon as the investigator's causality assessment is documented.

The provision also requires follow-up reports: "subsequent information should be submitted as a follow-up report, as necessary." This creates an ongoing tracking obligation -- the RC must monitor open SAE reports and ensure that follow-up information (discharge summaries, autopsy reports, additional test results) is submitted when it becomes available.

RC tasks generated: Transmit completed SAE reports to the sponsor within protocol-specified timelines. Track open SAE reports requiring follow-up. Ensure follow-up reports are submitted when additional information becomes available.

Section 2.7.2(c): death reporting

For reported deaths, the provision states: "the investigator should supply the sponsor, the IRB/IEC and, where applicable, the regulatory authority with any additional requested information (e.g., autopsy reports and terminal medical reports) when they become available."

This provision creates a multi-destination reporting obligation from a single event. A participant death triggers simultaneous reporting to the sponsor, the IRB, and potentially the regulatory authority -- each with its own timeline and content requirements. The RC must coordinate all three tracks.

RC task generated: Coordinate multi-destination reporting for participant deaths, ensuring the sponsor, IRB, and (if applicable) regulatory authority each receive the required information on the required timeline.

Section 2.7.2(d): delegation with retained responsibility

We addressed this provision extensively in L2. In the regulatory requirements context, what matters is the operational implication: the RC performs delegated safety reporting activities, but the investigator retains accountability. This means the RC must maintain a clear delegation record for each study, and the RC's work must be performed under documented oversight.

RC task generated: Ensure the delegation log accurately reflects the safety reporting activities delegated to the RC for each study. Maintain documentation that supports the investigator's oversight of delegated activities.

ICH E6(R3): sponsor obligations that generate RC workload

The investigator's obligations under Section 2.7.2 are the most visible to the RC -- they produce the outbound reporting tasks the RC coordinates every day. But the sponsor's obligations under Section 3.13 are equally important, because they generate the inbound safety communications the RC must process.

I have often observed that new regulatory coordinators focus so heavily on outbound reporting that they underestimate the volume and complexity of the inbound side. At an active multi-study site, sponsor safety communications can arrive daily. Each one requires receipt, logging, investigator notification, and -- depending on its content -- IRB submission. The regulations that drive this inbound flow deserve careful attention.

Section 3.13.1: sponsor review of safety information

The provision states that the sponsor "should aggregate, as appropriate, and review in a timely manner relevant safety information," and that information affecting participant willingness, trial conduct, or IRB/regulatory approval "should be communicated to the participants, investigator, IRB/IEC and regulatory authorities, as applicable, in a timely manner."

This provision is the engine behind every safety letter, every Investigator's Brochure update, and every DSMB communication the RC receives. The sponsor reviews aggregate safety data, identifies signals, and communicates them outward. The investigator site is one of the destinations.

RC task generated: Process all inbound sponsor safety communications -- receive, log, route to the investigator, and determine whether IRB submission is required.

Section 3.13.2(a)-(b): sponsor reporting to regulatory authorities

These provisions require the sponsor to submit safety updates and expedited SUSAR reports to the regulatory authority. The RC does not execute these tasks -- they are the sponsor's obligation. But understanding them matters because the regulatory authority's response to sponsor reports can generate follow-up actions at the site level. When the FDA receives a SUSAR report and requests additional site-level information, the RC may need to coordinate the site's response.

Section 3.13.2(c): expectedness assessment against the IB

This provision specifies that safety reporting to regulatory authorities "should be undertaken by assessing the expectedness of the reaction in relation to the applicable product information (e.g., the reference safety information (RSI) contained within the Investigator's Brochure)."

For the RC, this provision underscores a task from L2: the RC must maintain current copies of every Investigator's Brochure for every active study, because the Reference Safety Information in the IB is the basis against which expectedness is determined. When the IB is updated, the Reference Safety Information may change -- and that change affects what counts as "unexpected" going forward.

RC task generated: Maintain current IB versions for all active studies. When an updated IB is received, route it to the investigator and determine whether the updated Reference Safety Information changes any open safety assessments.

Section 3.13.2(d): SUSAR reporting to investigators and IRBs

This is, in my view, the single provision that generates the most RC workload. It states: "The reporting of SUSARs to investigator(s)/institutions(s) and to the IRB(s)/IEC(s) should be undertaken in a manner that reflects the urgency of action required."

When the sponsor identifies a SUSAR, the sponsor notifies the site. That notification arrives as an IND Safety Report (in the U.S. context) or equivalent document. The RC must then do three things: (1) ensure the investigator receives and reviews the notification, (2) document the investigator's review, and (3) determine whether the IRB requires submission of this notification -- and if so, submit it within the IRB's specified timeline.

For a site running 15 studies, SUSAR notifications can number in the dozens per month. Each one follows this three-step sequence. This is volume work with zero tolerance for missed items.

RC tasks generated: Receive and log all SUSAR notifications. Ensure investigator review and documented acknowledgment. Submit to the IRB per the IRB's reporting requirements and timelines.

Section 3.13.2(e)-(f): urgent issues and alternative arrangements

Section 3.13.2(e) addresses urgent safety issues requiring "immediate attention or action" -- these must be reported "without undue delay." Section 3.13.2(f) permits alternative arrangements for safety reporting, prospectively agreed upon and described in the protocol.

For the RC, 3.13.2(e) establishes that some safety communications demand a faster response than the standard processing timeline. The RC must be able to identify urgent communications and escalate them accordingly. And 3.13.2(f) means the RC must check whether any active study has negotiated alternative safety reporting arrangements that differ from the standard E6(R3) framework.

RC task generated: Identify and escalate urgent safety communications per 3.13.2(e). Check protocols for alternative safety reporting arrangements per 3.13.2(f).

ICH E6(R3): IRB reporting requirements

Section 1.4.8 sits in a different part of E6(R3) -- the section on IRB/IEC responsibilities -- but its requirements land directly on the RC's desk. This provision specifies what the investigator must report to the IRB, and since the RC typically prepares and submits these reports, Section 1.4.8 generates some of the RC's most consequential work.

The provision states that the investigator/institution should promptly report to the IRB:

(a) Deviations from the protocol to eliminate immediate hazards to the trial participants. If the investigator deviates from the protocol to protect a participant from immediate danger, the IRB must be notified. The RC prepares this notification.

(b) Changes increasing the risk to participants and/or significantly affecting the conduct of the trial. This is cross-referenced with Section 2.4.6, which requires prompt communication to the IRB of changes that significantly affect trial conduct or increase participant risk.

(c) All SUSARs in accordance with applicable regulatory requirements. This is the provision that creates the IRB submission obligation when the RC receives a SUSAR notification from the sponsor. Not every IRB requires submission of every SUSAR -- but the determination must be made for each one.

(d) New information that may adversely affect the safety of the participants or the conduct of the trial. This is the broadest category. It encompasses safety information that does not fit neatly into the SUSAR category but still has implications for participant safety or trial conduct. Updated Investigator's Brochures, DSMB recommendations, and sponsor safety letters may trigger reporting under this provision.

21 CFR 312.32: IND safety reporting in the U.S. context

ICH E6(R3) provides the international framework. In the United States, 21 CFR 312.32 adds a layer of specificity that directly affects the RC's daily work. This regulation governs how sponsors report safety information under an Investigational New Drug application -- and the reports it generates are among the most common items in the RC's inbox.

I do not intend to recapitulate the entire regulation here -- that would duplicate what you learned in GCP Foundations. What I want to do is identify the specific provisions that generate RC tasks.

What 312.32 requires of the sponsor (and why the RC cares)

Under 21 CFR 312.32(c)(1)(i), the sponsor must notify the FDA and all participating investigators of an IND safety report within 15 calendar days after the sponsor determines that the information qualifies for reporting. For events that are both serious and unexpected and suggest a significant risk to participants, the timeline compresses to 7 calendar days per 312.32(c)(2).

These timelines are the sponsor's obligation, not the site's. But they determine when IND Safety Reports arrive at the site. A SUSAR that occurred at a site in Houston may generate an IND Safety Report that arrives at a site in Portland 10 days later. The RC at the Portland site then has its own timeline obligations: investigator review, documentation, and IRB submission (if required by the IRB).

The 15-day and 7-day reports

The two reporting timelines create two categories of inbound safety communication:

15-day IND Safety Reports cover SUSARs -- suspected unexpected serious adverse reactions. These are the standard expedited reports the RC processes most frequently. They describe an event at another site, the sponsor's assessment, and any changes to the risk-benefit profile.

7-day IND Safety Reports are reserved for events suggesting a significant risk to trial participants -- typically fatal or life-threatening SUSARs. These are urgent communications. When the RC receives a 7-day report, the investigator notification and IRB submission (if required) should be expedited accordingly.

RC tasks generated: Receive and log IND Safety Reports. Distinguish 15-day from 7-day reports. Prioritize 7-day reports for immediate investigator review. Submit to the IRB per the IRB's reporting requirements. Maintain documentation of the complete processing chain.

What 312.32 does NOT require of the site

A point of clarification that matters operationally: 21 CFR 312.32 imposes obligations on the sponsor, not the investigator. The investigator's reporting obligations to the sponsor are governed by the protocol and by ICH E6(R3) Section 2.7.2. The RC should understand 312.32 because it explains where IND Safety Reports come from and why they arrive on the timelines they do -- but the RC's direct regulatory obligation for outbound reporting flows from E6(R3) and from 45 CFR 46, not from 312.32.

45 CFR 46: the Common Rule and IRB safety oversight

The third framework is 45 CFR 46 -- the federal regulation governing the protection of human subjects in research. Where E6(R3) addresses clinical trial conduct and 312.32 addresses IND safety reporting, 45 CFR 46 addresses the IRB's oversight function and, by extension, the site's obligation to keep the IRB informed about safety.

Continuing review and safety information

Under 45 CFR 46.109(e), the IRB must conduct continuing review of approved research at intervals appropriate to the degree of risk, but not less than once per year. This continuing review requires current safety information from the site -- aggregate adverse event data, SUSAR summaries, protocol deviations, and any changes to the study's risk-benefit profile.

For the RC, this provision generates two obligations. First, the RC must prepare and submit the safety component of each study's continuing review package -- typically an annual safety summary that aggregates all reportable events for the review period. Second, the RC must track continuing review dates across the portfolio and ensure safety summaries are submitted before the IRB's deadline. A lapse in continuing review approval means the study cannot enroll new participants and, in some cases, must suspend all research activities until approval is restored. That is not a paperwork inconvenience. It is a regulatory emergency.

Unanticipated problems involving risks to subjects

45 CFR 46.103(b)(5) requires institutions to report to the IRB "any unanticipated problems involving risks to subjects or others." The OHRP guidance on this provision defines an unanticipated problem as an event 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 subjects or others at a greater risk of harm than was previously known or recognized.

This is the provision that determines a substantial portion of the RC's IRB safety reporting workload. Not every adverse event is an unanticipated problem. Not every serious adverse event is an unanticipated problem. The determination depends on the three-part test -- and that determination, while informed by the RC's analysis, ultimately rests with the investigator's medical judgment and the IRB's interpretation.

RC tasks generated: Prepare continuing review safety summaries for each active study. Track continuing review dates across the portfolio. Prepare and submit reports of unanticipated problems per the IRB's reporting criteria and timelines.

The regulatory requirements matrix

The preceding sections trace each obligation to its regulatory source. But knowing the requirements is not the same as being able to act on them at 8:15 on a Monday morning when three items are waiting in the inbox. For that, you need a working reference -- a matrix that connects the obligation, the source, the timeline, and the accountable party in a format you can consult in real time.

What follows is the matrix I recommend every RC build for their own portfolio. The version here covers the universal requirements. Your operational version will add protocol-specific timelines and IRB-specific reporting criteria for each active study.

When a single event triggers all three frameworks

The regulatory requirements matrix is a reference tool. But it becomes operationally meaningful only when you can trace a real event through it and determine -- in real time -- which obligations activate and in what sequence.

Consider this scenario. A participant in a Phase III trial at the site experiences a serious adverse event: an unexpected hospitalization for hepatotoxicity. The investigator assesses the event as possibly related to the investigational product. Here is what the three frameworks require, in sequence:

E6(R3) Section 2.7.2(b): The SAE must be reported to the sponsor immediately, with the investigator's causality assessment. The RC transmits the completed report. Timeline: per protocol, typically 24 hours from investigator awareness.

21 CFR 312.32 (downstream effect): The sponsor receives this report and, along with data from other sites, determines whether the event qualifies as a SUSAR. If so, the sponsor generates an IND Safety Report. That report will be sent back to the originating site and to all other sites participating in the trial. When the RC at other sites receives this IND Safety Report weeks later, the RC's processing obligation begins.

E6(R3) Section 1.4.8(c)-(d) and 45 CFR 46.103(b)(5): At the originating site, the investigator determines whether this event meets the criteria for an unanticipated problem (unexpected, related, and suggesting greater risk than previously known). If so, the RC must prepare and submit a report to the IRB within the IRB's specified timeline. If the event resulted in death, Section 2.7.2(c) adds a further obligation to provide autopsy reports and terminal medical reports when available -- to the sponsor, the IRB, and the regulatory authority.

One event. Three frameworks. Multiple reporting tracks running in parallel, each with its own deadline. This is what the regulatory coordinator manages. And this is why the matrix is not an academic exercise -- it is a survival tool.

What this means for the RC's daily work

Let me draw out the practical implications -- the operational realities that follow from the regulatory requirements we have traced.

The RC must maintain a protocol-specific reference for every active study. The universal matrix above provides the framework, but the operative timelines and reporting thresholds are study-specific. Each protocol defines its own SAE reporting window. Each IRB defines its own SUSAR submission deadline. Each sponsor uses its own reporting mechanism (electronic portal, email, fax). The RC's working version of the matrix must capture these study-specific details for every active study in the portfolio.

Inbound and outbound obligations are not symmetric. The RC's outbound obligations (SAE reports to sponsor, safety reports to IRB) are event-driven and time-sensitive. The RC's inbound obligations (processing IND Safety Reports, routing IB updates) are volume-driven and process-intensive. Both categories are regulatory requirements. Both require tracking. But they demand different operational approaches, and the systems the RC builds must accommodate both. We will address those systems in the next lesson.

Multi-IRB sites face multiplicative complexity. A site that uses one central IRB and one institutional IRB across its portfolio must maintain two separate reporting matrices for IRB submissions. The central IRB may have a 10-business-day window for SUSAR submissions. The institutional IRB may require 5 business days and a different form. The RC must know which IRB governs which study and apply the correct reporting requirements to each.

The "promptly" standard creates operational ambiguity that the RC must resolve. E6(R3) uses "promptly" and "immediately" without defining them in hours or days. 45 CFR 46 uses "promptly" without a numeric timeline. The protocol and the IRB's policies resolve this ambiguity operationally -- but only if the RC has read them and built the specific timelines into the tracking system. An RC who relies on "I'll get to it as soon as I can" instead of "this is due by Thursday at 5:00 PM per the IRB's 5-business-day reporting policy" is setting the site up for a compliance failure.

Monday morning, three frameworks deep

It is 8:15 on a Monday morning. The regulatory coordinator opens the shared safety inbox and finds three items waiting:

First, an IND Safety Report from a pharmaceutical sponsor. The sponsor is fulfilling its obligation under 21 CFR 312.32(c)(1)(i) to notify all participating investigators of a Suspected Unexpected Serious Adverse Reaction that occurred at another site in the trial. The investigator must review this report. And the IRB must receive it -- but under which timeline? That depends on the IRB's interpretation of 45 CFR 46.103(b)(5) and whatever reporting policy the IRB has established for inbound SUSAR notifications.

Second, an email from the IRB requesting the site's overdue annual safety summary for a Phase II cardiovascular trial. The IRB's continuing review requires current safety data per 45 CFR 46.109(e), and the site is seven days past the submission deadline. This is a compliance gap the RC must close immediately.

Third, an internal flag from a CRC: the investigator completed a causality assessment on a serious adverse event late Friday, and the completed SAE report has not yet been transmitted to the sponsor. Per ICH E6(R3) Annex 1, Section 2.7.2(b), SAEs should be reported to the sponsor "immediately." The RC needs to transmit this report within hours, not days.

Three items. Three different regulatory sources. Three distinct obligations generating three different RC tasks. This is not a hypothetical -- it is a representative Monday for any RC managing a multi-study portfolio at an active investigator site.

In the previous two lessons, we mapped the safety reporting pipeline and established the role boundaries within it. Now we turn to the question that every RC must be able to answer with precision: What, exactly, do the regulations require? Not approximately. Not "whatever the sponsor says." The specific provisions, from the specific regulations, that generate the specific obligations the RC must fulfill.

Three frameworks, one desk

The regulatory coordinator's safety reporting obligations do not emerge from a single source. They emerge from three overlapping regulatory frameworks, each with its own authority, its own requirements, and its own enforcement mechanisms. Understanding where these frameworks overlap -- and where they diverge -- is fundamental to competent regulatory coordination.

ICH E6(R3) provides the international standard for Good Clinical Practice, including investigator and sponsor safety reporting obligations. Adopted on 06 January 2025, E6(R3) is the authoritative GCP guideline referenced in clinical trial agreements worldwide. Its safety provisions appear primarily in Annex 1, Sections 2.7.2 (investigator safety reporting), 3.13.1--3.13.3 (sponsor safety assessment and reporting), and 1.4.8 (IRB reporting requirements).

21 CFR 312.32 is the FDA regulation governing IND safety reporting. It specifies what the sponsor must report to the FDA and to investigators, the timelines for those reports, and the definitions that determine which events trigger expedited reporting. For the RC at a U.S. site, this regulation governs the IND Safety Reports that arrive in the inbox and the sponsor reporting obligations that drive SAE submission timelines.

45 CFR 46 -- the Common Rule -- establishes the requirements for IRB oversight of human subjects research. While it does not prescribe specific safety reporting forms, it requires IRBs to conduct continuing review and to be notified of events that affect participant safety. The IRB's interpretation of 45 CFR 46 generates the site's IRB safety reporting obligations, which the RC must execute.

I want to be precise about something that new regulatory coordinators sometimes misunderstand: these frameworks are not redundant. They address different aspects of the safety reporting system, and they impose obligations on different parties. A single safety event at a site can trigger requirements under all three frameworks simultaneously -- and the RC must satisfy each one according to its own terms, its own timeline, and its own documentation standard.

ICH E6(R3): the investigator's safety reporting obligations

Let us begin where the previous two lessons left off -- with the investigator's safety reporting obligations under ICH E6(R3) Annex 1, Section 2.7.2. We addressed these provisions in L1 and L2 in the context of the pipeline and role boundaries. Now I want you to read them as what they are: regulatory requirements that generate specific, traceable RC tasks.

Section 2.7.2(a): reporting AEs and abnormal test results to the sponsor

The provision states: adverse events and abnormal test results required for safety evaluations "should be reported to the sponsor according to the reporting requirements and within the time periods specified in the protocol."

This provision does two things for the RC. First, it establishes that the protocol -- not E6(R3) alone -- defines the specific reporting requirements and timelines. The RC must know each study's protocol-specific safety reporting plan, because the timeline for reporting a non-serious AE may be 24 hours in one protocol and five business days in another. Second, it means the RC must maintain current knowledge of which events are "required for safety evaluations" in each study, because that threshold varies by protocol.

RC task generated: Maintain a protocol-by-protocol reference of safety reporting thresholds and timelines. Monitor compliance with protocol-specific timelines for each active study.

Section 2.7.2(b): SAE reporting with causality assessment

The provision states: all SAEs "should be reported immediately (after the investigator reasonably becomes aware of the event) to the sponsor," and "the investigator should also include an assessment of causality."

This is the provision that drives the most time-sensitive RC work. "Immediately" is not a defined number of hours in E6(R3) -- it is operationally interpreted through the protocol's safety reporting plan, which typically specifies 24 hours for initial notification. But "immediately" also means the RC cannot batch SAE transmissions. Each completed SAE report must be transmitted to the sponsor as soon as the investigator's causality assessment is documented.

The provision also requires follow-up reports: "subsequent information should be submitted as a follow-up report, as necessary." This creates an ongoing tracking obligation -- the RC must monitor open SAE reports and ensure that follow-up information (discharge summaries, autopsy reports, additional test results) is submitted when it becomes available.

RC tasks generated: Transmit completed SAE reports to the sponsor within protocol-specified timelines. Track open SAE reports requiring follow-up. Ensure follow-up reports are submitted when additional information becomes available.

Section 2.7.2(c): death reporting

For reported deaths, the provision states: "the investigator should supply the sponsor, the IRB/IEC and, where applicable, the regulatory authority with any additional requested information (e.g., autopsy reports and terminal medical reports) when they become available."

This provision creates a multi-destination reporting obligation from a single event. A participant death triggers simultaneous reporting to the sponsor, the IRB, and potentially the regulatory authority -- each with its own timeline and content requirements. The RC must coordinate all three tracks.

RC task generated: Coordinate multi-destination reporting for participant deaths, ensuring the sponsor, IRB, and (if applicable) regulatory authority each receive the required information on the required timeline.

Section 2.7.2(d): delegation with retained responsibility

We addressed this provision extensively in L2. In the regulatory requirements context, what matters is the operational implication: the RC performs delegated safety reporting activities, but the investigator retains accountability. This means the RC must maintain a clear delegation record for each study, and the RC's work must be performed under documented oversight.

RC task generated: Ensure the delegation log accurately reflects the safety reporting activities delegated to the RC for each study. Maintain documentation that supports the investigator's oversight of delegated activities.

ICH E6(R3): sponsor obligations that generate RC workload

The investigator's obligations under Section 2.7.2 are the most visible to the RC -- they produce the outbound reporting tasks the RC coordinates every day. But the sponsor's obligations under Section 3.13 are equally important, because they generate the inbound safety communications the RC must process.

I have often observed that new regulatory coordinators focus so heavily on outbound reporting that they underestimate the volume and complexity of the inbound side. At an active multi-study site, sponsor safety communications can arrive daily. Each one requires receipt, logging, investigator notification, and -- depending on its content -- IRB submission. The regulations that drive this inbound flow deserve careful attention.

Section 3.13.1: sponsor review of safety information

The provision states that the sponsor "should aggregate, as appropriate, and review in a timely manner relevant safety information," and that information affecting participant willingness, trial conduct, or IRB/regulatory approval "should be communicated to the participants, investigator, IRB/IEC and regulatory authorities, as applicable, in a timely manner."

This provision is the engine behind every safety letter, every Investigator's Brochure update, and every DSMB communication the RC receives. The sponsor reviews aggregate safety data, identifies signals, and communicates them outward. The investigator site is one of the destinations.

RC task generated: Process all inbound sponsor safety communications -- receive, log, route to the investigator, and determine whether IRB submission is required.

Section 3.13.2(a)-(b): sponsor reporting to regulatory authorities

These provisions require the sponsor to submit safety updates and expedited SUSAR reports to the regulatory authority. The RC does not execute these tasks -- they are the sponsor's obligation. But understanding them matters because the regulatory authority's response to sponsor reports can generate follow-up actions at the site level. When the FDA receives a SUSAR report and requests additional site-level information, the RC may need to coordinate the site's response.

Section 3.13.2(c): expectedness assessment against the IB

This provision specifies that safety reporting to regulatory authorities "should be undertaken by assessing the expectedness of the reaction in relation to the applicable product information (e.g., the reference safety information (RSI) contained within the Investigator's Brochure)."

For the RC, this provision underscores a task from L2: the RC must maintain current copies of every Investigator's Brochure for every active study, because the Reference Safety Information in the IB is the basis against which expectedness is determined. When the IB is updated, the Reference Safety Information may change -- and that change affects what counts as "unexpected" going forward.

RC task generated: Maintain current IB versions for all active studies. When an updated IB is received, route it to the investigator and determine whether the updated Reference Safety Information changes any open safety assessments.

Section 3.13.2(d): SUSAR reporting to investigators and IRBs

This is, in my view, the single provision that generates the most RC workload. It states: "The reporting of SUSARs to investigator(s)/institutions(s) and to the IRB(s)/IEC(s) should be undertaken in a manner that reflects the urgency of action required."

When the sponsor identifies a SUSAR, the sponsor notifies the site. That notification arrives as an IND Safety Report (in the U.S. context) or equivalent document. The RC must then do three things: (1) ensure the investigator receives and reviews the notification, (2) document the investigator's review, and (3) determine whether the IRB requires submission of this notification -- and if so, submit it within the IRB's specified timeline.

For a site running 15 studies, SUSAR notifications can number in the dozens per month. Each one follows this three-step sequence. This is volume work with zero tolerance for missed items.

RC tasks generated: Receive and log all SUSAR notifications. Ensure investigator review and documented acknowledgment. Submit to the IRB per the IRB's reporting requirements and timelines.

Section 3.13.2(e)-(f): urgent issues and alternative arrangements

Section 3.13.2(e) addresses urgent safety issues requiring "immediate attention or action" -- these must be reported "without undue delay." Section 3.13.2(f) permits alternative arrangements for safety reporting, prospectively agreed upon and described in the protocol.

For the RC, 3.13.2(e) establishes that some safety communications demand a faster response than the standard processing timeline. The RC must be able to identify urgent communications and escalate them accordingly. And 3.13.2(f) means the RC must check whether any active study has negotiated alternative safety reporting arrangements that differ from the standard E6(R3) framework.

RC task generated: Identify and escalate urgent safety communications per 3.13.2(e). Check protocols for alternative safety reporting arrangements per 3.13.2(f).

ICH E6(R3): IRB reporting requirements

Section 1.4.8 sits in a different part of E6(R3) -- the section on IRB/IEC responsibilities -- but its requirements land directly on the RC's desk. This provision specifies what the investigator must report to the IRB, and since the RC typically prepares and submits these reports, Section 1.4.8 generates some of the RC's most consequential work.

The provision states that the investigator/institution should promptly report to the IRB:

(a) Deviations from the protocol to eliminate immediate hazards to the trial participants. If the investigator deviates from the protocol to protect a participant from immediate danger, the IRB must be notified. The RC prepares this notification.

(b) Changes increasing the risk to participants and/or significantly affecting the conduct of the trial. This is cross-referenced with Section 2.4.6, which requires prompt communication to the IRB of changes that significantly affect trial conduct or increase participant risk.

(c) All SUSARs in accordance with applicable regulatory requirements. This is the provision that creates the IRB submission obligation when the RC receives a SUSAR notification from the sponsor. Not every IRB requires submission of every SUSAR -- but the determination must be made for each one.

(d) New information that may adversely affect the safety of the participants or the conduct of the trial. This is the broadest category. It encompasses safety information that does not fit neatly into the SUSAR category but still has implications for participant safety or trial conduct. Updated Investigator's Brochures, DSMB recommendations, and sponsor safety letters may trigger reporting under this provision.

21 CFR 312.32: IND safety reporting in the U.S. context

ICH E6(R3) provides the international framework. In the United States, 21 CFR 312.32 adds a layer of specificity that directly affects the RC's daily work. This regulation governs how sponsors report safety information under an Investigational New Drug application -- and the reports it generates are among the most common items in the RC's inbox.

I do not intend to recapitulate the entire regulation here -- that would duplicate what you learned in GCP Foundations. What I want to do is identify the specific provisions that generate RC tasks.

What 312.32 requires of the sponsor (and why the RC cares)

Under 21 CFR 312.32(c)(1)(i), the sponsor must notify the FDA and all participating investigators of an IND safety report within 15 calendar days after the sponsor determines that the information qualifies for reporting. For events that are both serious and unexpected and suggest a significant risk to participants, the timeline compresses to 7 calendar days per 312.32(c)(2).

These timelines are the sponsor's obligation, not the site's. But they determine when IND Safety Reports arrive at the site. A SUSAR that occurred at a site in Houston may generate an IND Safety Report that arrives at a site in Portland 10 days later. The RC at the Portland site then has its own timeline obligations: investigator review, documentation, and IRB submission (if required by the IRB).

The 15-day and 7-day reports

The two reporting timelines create two categories of inbound safety communication:

15-day IND Safety Reports cover SUSARs -- suspected unexpected serious adverse reactions. These are the standard expedited reports the RC processes most frequently. They describe an event at another site, the sponsor's assessment, and any changes to the risk-benefit profile.

7-day IND Safety Reports are reserved for events suggesting a significant risk to trial participants -- typically fatal or life-threatening SUSARs. These are urgent communications. When the RC receives a 7-day report, the investigator notification and IRB submission (if required) should be expedited accordingly.

RC tasks generated: Receive and log IND Safety Reports. Distinguish 15-day from 7-day reports. Prioritize 7-day reports for immediate investigator review. Submit to the IRB per the IRB's reporting requirements. Maintain documentation of the complete processing chain.

What 312.32 does NOT require of the site

A point of clarification that matters operationally: 21 CFR 312.32 imposes obligations on the sponsor, not the investigator. The investigator's reporting obligations to the sponsor are governed by the protocol and by ICH E6(R3) Section 2.7.2. The RC should understand 312.32 because it explains where IND Safety Reports come from and why they arrive on the timelines they do -- but the RC's direct regulatory obligation for outbound reporting flows from E6(R3) and from 45 CFR 46, not from 312.32.

45 CFR 46: the Common Rule and IRB safety oversight

The third framework is 45 CFR 46 -- the federal regulation governing the protection of human subjects in research. Where E6(R3) addresses clinical trial conduct and 312.32 addresses IND safety reporting, 45 CFR 46 addresses the IRB's oversight function and, by extension, the site's obligation to keep the IRB informed about safety.

Continuing review and safety information

Under 45 CFR 46.109(e), the IRB must conduct continuing review of approved research at intervals appropriate to the degree of risk, but not less than once per year. This continuing review requires current safety information from the site -- aggregate adverse event data, SUSAR summaries, protocol deviations, and any changes to the study's risk-benefit profile.

For the RC, this provision generates two obligations. First, the RC must prepare and submit the safety component of each study's continuing review package -- typically an annual safety summary that aggregates all reportable events for the review period. Second, the RC must track continuing review dates across the portfolio and ensure safety summaries are submitted before the IRB's deadline. A lapse in continuing review approval means the study cannot enroll new participants and, in some cases, must suspend all research activities until approval is restored. That is not a paperwork inconvenience. It is a regulatory emergency.

Unanticipated problems involving risks to subjects

45 CFR 46.103(b)(5) requires institutions to report to the IRB "any unanticipated problems involving risks to subjects or others." The OHRP guidance on this provision defines an unanticipated problem as an event 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 subjects or others at a greater risk of harm than was previously known or recognized.

This is the provision that determines a substantial portion of the RC's IRB safety reporting workload. Not every adverse event is an unanticipated problem. Not every serious adverse event is an unanticipated problem. The determination depends on the three-part test -- and that determination, while informed by the RC's analysis, ultimately rests with the investigator's medical judgment and the IRB's interpretation.

RC tasks generated: Prepare continuing review safety summaries for each active study. Track continuing review dates across the portfolio. Prepare and submit reports of unanticipated problems per the IRB's reporting criteria and timelines.

The regulatory requirements matrix

The preceding sections trace each obligation to its regulatory source. But knowing the requirements is not the same as being able to act on them at 8:15 on a Monday morning when three items are waiting in the inbox. For that, you need a working reference -- a matrix that connects the obligation, the source, the timeline, and the accountable party in a format you can consult in real time.

What follows is the matrix I recommend every RC build for their own portfolio. The version here covers the universal requirements. Your operational version will add protocol-specific timelines and IRB-specific reporting criteria for each active study.

When a single event triggers all three frameworks

The regulatory requirements matrix is a reference tool. But it becomes operationally meaningful only when you can trace a real event through it and determine -- in real time -- which obligations activate and in what sequence.

Consider this scenario. A participant in a Phase III trial at the site experiences a serious adverse event: an unexpected hospitalization for hepatotoxicity. The investigator assesses the event as possibly related to the investigational product. Here is what the three frameworks require, in sequence:

E6(R3) Section 2.7.2(b): The SAE must be reported to the sponsor immediately, with the investigator's causality assessment. The RC transmits the completed report. Timeline: per protocol, typically 24 hours from investigator awareness.

21 CFR 312.32 (downstream effect): The sponsor receives this report and, along with data from other sites, determines whether the event qualifies as a SUSAR. If so, the sponsor generates an IND Safety Report. That report will be sent back to the originating site and to all other sites participating in the trial. When the RC at other sites receives this IND Safety Report weeks later, the RC's processing obligation begins.

E6(R3) Section 1.4.8(c)-(d) and 45 CFR 46.103(b)(5): At the originating site, the investigator determines whether this event meets the criteria for an unanticipated problem (unexpected, related, and suggesting greater risk than previously known). If so, the RC must prepare and submit a report to the IRB within the IRB's specified timeline. If the event resulted in death, Section 2.7.2(c) adds a further obligation to provide autopsy reports and terminal medical reports when available -- to the sponsor, the IRB, and the regulatory authority.

One event. Three frameworks. Multiple reporting tracks running in parallel, each with its own deadline. This is what the regulatory coordinator manages. And this is why the matrix is not an academic exercise -- it is a survival tool.

What this means for the RC's daily work

Let me draw out the practical implications -- the operational realities that follow from the regulatory requirements we have traced.

The RC must maintain a protocol-specific reference for every active study. The universal matrix above provides the framework, but the operative timelines and reporting thresholds are study-specific. Each protocol defines its own SAE reporting window. Each IRB defines its own SUSAR submission deadline. Each sponsor uses its own reporting mechanism (electronic portal, email, fax). The RC's working version of the matrix must capture these study-specific details for every active study in the portfolio.

Inbound and outbound obligations are not symmetric. The RC's outbound obligations (SAE reports to sponsor, safety reports to IRB) are event-driven and time-sensitive. The RC's inbound obligations (processing IND Safety Reports, routing IB updates) are volume-driven and process-intensive. Both categories are regulatory requirements. Both require tracking. But they demand different operational approaches, and the systems the RC builds must accommodate both. We will address those systems in the next lesson.

Multi-IRB sites face multiplicative complexity. A site that uses one central IRB and one institutional IRB across its portfolio must maintain two separate reporting matrices for IRB submissions. The central IRB may have a 10-business-day window for SUSAR submissions. The institutional IRB may require 5 business days and a different form. The RC must know which IRB governs which study and apply the correct reporting requirements to each.

The "promptly" standard creates operational ambiguity that the RC must resolve. E6(R3) uses "promptly" and "immediately" without defining them in hours or days. 45 CFR 46 uses "promptly" without a numeric timeline. The protocol and the IRB's policies resolve this ambiguity operationally -- but only if the RC has read them and built the specific timelines into the tracking system. An RC who relies on "I'll get to it as soon as I can" instead of "this is due by Thursday at 5:00 PM per the IRB's 5-business-day reporting policy" is setting the site up for a compliance failure.