The inflection point

Picture a site running 15 active studies. A coordinator managing one of those studies -- a Phase III oncology trial with a central IRB -- spends two hours preparing a continuing review package, submits it through the portal, and moves on. The submission is complete. The work is done.

Now picture the person responsible for ensuring that all 15 continuing reviews, across three different IRBs, are submitted correctly and on time over the next 90 days. That person is not doing the same work faster. They are doing fundamentally different work. They are managing a pipeline.

This distinction -- between executing a single submission and managing a submission pipeline -- is the defining operational shift of the regulatory coordinator role. Course 1 introduced the difference between task-level execution and systems-level thinking. This lesson makes that difference concrete in the domain where it matters most: the flow of regulatory submissions through your site.

What the coordinator does versus what the pipeline requires

A clinical research coordinator preparing an IRB submission needs to know the specific requirements for that study's IRB, assemble the correct documents, obtain the necessary signatures, and submit the package by the deadline. This is skilled work that demands attention to detail, familiarity with the protocol, and competence with the IRB's portal or forms. It is not, however, systems work.

The coordinator does not need to know that four other studies at the site have continuing reviews due within the same two-week window. The coordinator does not need to reconcile the fact that the principal investigator whose signature is needed for this submission also has signatures pending for two other studies with earlier deadlines. The coordinator does not need to evaluate whether the IRB that reviews this study processes amendments faster than the IRB reviewing the oncology trial down the hall -- or whether submitting this package on Tuesday rather than Friday would avoid a processing bottleneck that delays three other pending submissions.

These are pipeline-level concerns. They exist only when someone is looking across all studies simultaneously, and they require operational capabilities that no single-study workflow produces.

Five capabilities that exist only at the pipeline level

The difference between per-study execution and pipeline management is not merely one of volume -- doing more of the same thing. It is a difference in kind. Managing a pipeline creates operational capabilities that are structurally impossible when submissions are handled study-by-study, no matter how competent the individual coordinators are.

I find it useful to name these capabilities explicitly, because they define what the RC role adds to the site's regulatory operations that no collection of CRC-level work can replicate.

These five capabilities are not aspirational ideals. They are operational necessities at any site managing more than a handful of concurrent studies. And here is the critical insight: they do not emerge organically from individual coordinators doing their jobs well. You can have five excellent coordinators, each managing their own studies flawlessly, and still have a site with no cross-study deadline awareness, no resource conflict resolution, and no standardized quality baseline. The capabilities are properties of the system, not of the individuals within it.

This is why the RC role exists. Not to do what coordinators do, only more of it, but to create and maintain the operational infrastructure that produces these five capabilities.

Failure modes: what breaks when there is no pipeline

ICH E6(R3) Annex 1, Section 3.10.1.1 requires the sponsor to identify risks that may have a meaningful impact on critical to quality factors. In the context of regulatory submissions, this means identifying how the absence of pipeline-level management creates systemic risk -- risk that is invisible from within any individual study but devastating when it materializes.

I have seen these failure modes at dozens of sites over the years, and what strikes me most is how predictable they are. They are not exotic disasters. They are the inevitable consequences of managing submissions study-by-study at a site that has outgrown that approach.

The architecture of a submission pipeline

A submission pipeline is not a metaphor. It is a concrete operational architecture with four components: inputs, processing, outputs, and feedback. Understanding this architecture is the foundation for everything you will build in this module.

Inputs are the events that generate submission work. A new study requires an initial submission. An approaching approval expiration date triggers continuing review preparation. A protocol amendment creates an amendment submission. A safety event generates a safety report to the IRB. A study ending initiates close-out notification. At any given moment, a site with 15 active studies may have 20 or more input events in various stages of readiness.

Processing is where pipeline-level capabilities live. This is where deadlines are aggregated into a unified view, where resource conflicts are identified and resolved, where quality standards are applied consistently, and where each submission is routed to the correct IRB through the correct portal with the correct forms. Processing is the RC's domain -- the operational infrastructure that transforms raw input events into submission-ready packages.

Outputs are completed submissions delivered to the appropriate IRB. But "completed" is a precisely defined state: the package meets the IRB's specific requirements, includes all required signatures, contains current documents, and has passed the site's quality control process. A submission that reaches the IRB incomplete is not an output -- it is a processing failure that will generate rework.

Feedback closes the loop. Post-submission tracking captures what the IRB does with each submission: approval, approval with modifications, deferral, request for additional information. This feedback informs the processing layer. If a particular IRB consistently requests additional documentation for a specific submission type, the processing layer adjusts the quality control standard for that combination. If submissions to a particular portal are taking 30% longer than expected, the processing layer adjusts timelines. Without feedback, the pipeline operates blind.

Proportionality: the pipeline scales with the portfolio

Not every site needs the same pipeline. A site managing four studies through a single IRB has different infrastructure requirements than a site managing 25 studies across four IRBs. ICH E6(R3) Principle 7 (Sections 7.1--7.4) establishes that quality management approaches should be proportionate to risks and the importance of the data. The same principle applies to submission pipeline design.

The essential question is not "How elaborate should my pipeline be?" but rather "At what point does the absence of pipeline-level management create unacceptable risk?" For most sites, that threshold arrives somewhere between five and eight concurrent studies -- the point at which no single person can reliably hold all deadlines, dependencies, and quality requirements in working memory simultaneously.

Below that threshold, a diligent coordinator with a good calendar may suffice. Above it, you need infrastructure: a tracking system, quality control checkpoints, defined escalation procedures, and someone whose job it is to look across all studies simultaneously. That infrastructure is the submission pipeline. And building it is the work of the next three lessons.

Key takeaways

The shift from per-study submission execution to pipeline management is not about doing more of the same work. It is about creating operational capabilities -- cross-study deadline awareness, resource conflict resolution, IRB pattern recognition, quality normalization, and institutional memory -- that cannot exist without portfolio-level visibility.

When a site manages submissions study-by-study, four predictable failure modes emerge: deadline collision blindness, signature bottleneck cascades, quality variance, and institutional memory loss. These failures are not caused by individual incompetence. They are structural consequences of the absence of a pipeline.

A submission pipeline has a concrete architecture: inputs (submission-generating events), processing (where the RC's pipeline capabilities operate), outputs (completed submissions to IRBs), and feedback (post-submission tracking that informs future operations). The next lesson begins building this pipeline by teaching you to see your submission landscape -- the full scope of what you are managing.

The inflection point

Picture a site running 15 active studies. A coordinator managing one of those studies -- a Phase III oncology trial with a central IRB -- spends two hours preparing a continuing review package, submits it through the portal, and moves on. The submission is complete. The work is done.

Now picture the person responsible for ensuring that all 15 continuing reviews, across three different IRBs, are submitted correctly and on time over the next 90 days. That person is not doing the same work faster. They are doing fundamentally different work. They are managing a pipeline.

This distinction -- between executing a single submission and managing a submission pipeline -- is the defining operational shift of the regulatory coordinator role. Course 1 introduced the difference between task-level execution and systems-level thinking. This lesson makes that difference concrete in the domain where it matters most: the flow of regulatory submissions through your site.

What the coordinator does versus what the pipeline requires

A clinical research coordinator preparing an IRB submission needs to know the specific requirements for that study's IRB, assemble the correct documents, obtain the necessary signatures, and submit the package by the deadline. This is skilled work that demands attention to detail, familiarity with the protocol, and competence with the IRB's portal or forms. It is not, however, systems work.

The coordinator does not need to know that four other studies at the site have continuing reviews due within the same two-week window. The coordinator does not need to reconcile the fact that the principal investigator whose signature is needed for this submission also has signatures pending for two other studies with earlier deadlines. The coordinator does not need to evaluate whether the IRB that reviews this study processes amendments faster than the IRB reviewing the oncology trial down the hall -- or whether submitting this package on Tuesday rather than Friday would avoid a processing bottleneck that delays three other pending submissions.

These are pipeline-level concerns. They exist only when someone is looking across all studies simultaneously, and they require operational capabilities that no single-study workflow produces.

Five capabilities that exist only at the pipeline level

The difference between per-study execution and pipeline management is not merely one of volume -- doing more of the same thing. It is a difference in kind. Managing a pipeline creates operational capabilities that are structurally impossible when submissions are handled study-by-study, no matter how competent the individual coordinators are.

I find it useful to name these capabilities explicitly, because they define what the RC role adds to the site's regulatory operations that no collection of CRC-level work can replicate.

These five capabilities are not aspirational ideals. They are operational necessities at any site managing more than a handful of concurrent studies. And here is the critical insight: they do not emerge organically from individual coordinators doing their jobs well. You can have five excellent coordinators, each managing their own studies flawlessly, and still have a site with no cross-study deadline awareness, no resource conflict resolution, and no standardized quality baseline. The capabilities are properties of the system, not of the individuals within it.

This is why the RC role exists. Not to do what coordinators do, only more of it, but to create and maintain the operational infrastructure that produces these five capabilities.

Failure modes: what breaks when there is no pipeline

ICH E6(R3) Annex 1, Section 3.10.1.1 requires the sponsor to identify risks that may have a meaningful impact on critical to quality factors. In the context of regulatory submissions, this means identifying how the absence of pipeline-level management creates systemic risk -- risk that is invisible from within any individual study but devastating when it materializes.

I have seen these failure modes at dozens of sites over the years, and what strikes me most is how predictable they are. They are not exotic disasters. They are the inevitable consequences of managing submissions study-by-study at a site that has outgrown that approach.

The architecture of a submission pipeline

A submission pipeline is not a metaphor. It is a concrete operational architecture with four components: inputs, processing, outputs, and feedback. Understanding this architecture is the foundation for everything you will build in this module.

Inputs are the events that generate submission work. A new study requires an initial submission. An approaching approval expiration date triggers continuing review preparation. A protocol amendment creates an amendment submission. A safety event generates a safety report to the IRB. A study ending initiates close-out notification. At any given moment, a site with 15 active studies may have 20 or more input events in various stages of readiness.

Processing is where pipeline-level capabilities live. This is where deadlines are aggregated into a unified view, where resource conflicts are identified and resolved, where quality standards are applied consistently, and where each submission is routed to the correct IRB through the correct portal with the correct forms. Processing is the RC's domain -- the operational infrastructure that transforms raw input events into submission-ready packages.

Outputs are completed submissions delivered to the appropriate IRB. But "completed" is a precisely defined state: the package meets the IRB's specific requirements, includes all required signatures, contains current documents, and has passed the site's quality control process. A submission that reaches the IRB incomplete is not an output -- it is a processing failure that will generate rework.

Feedback closes the loop. Post-submission tracking captures what the IRB does with each submission: approval, approval with modifications, deferral, request for additional information. This feedback informs the processing layer. If a particular IRB consistently requests additional documentation for a specific submission type, the processing layer adjusts the quality control standard for that combination. If submissions to a particular portal are taking 30% longer than expected, the processing layer adjusts timelines. Without feedback, the pipeline operates blind.

Proportionality: the pipeline scales with the portfolio

Not every site needs the same pipeline. A site managing four studies through a single IRB has different infrastructure requirements than a site managing 25 studies across four IRBs. ICH E6(R3) Principle 7 (Sections 7.1--7.4) establishes that quality management approaches should be proportionate to risks and the importance of the data. The same principle applies to submission pipeline design.

The essential question is not "How elaborate should my pipeline be?" but rather "At what point does the absence of pipeline-level management create unacceptable risk?" For most sites, that threshold arrives somewhere between five and eight concurrent studies -- the point at which no single person can reliably hold all deadlines, dependencies, and quality requirements in working memory simultaneously.

Below that threshold, a diligent coordinator with a good calendar may suffice. Above it, you need infrastructure: a tracking system, quality control checkpoints, defined escalation procedures, and someone whose job it is to look across all studies simultaneously. That infrastructure is the submission pipeline. And building it is the work of the next three lessons.

Key takeaways

The shift from per-study submission execution to pipeline management is not about doing more of the same work. It is about creating operational capabilities -- cross-study deadline awareness, resource conflict resolution, IRB pattern recognition, quality normalization, and institutional memory -- that cannot exist without portfolio-level visibility.

When a site manages submissions study-by-study, four predictable failure modes emerge: deadline collision blindness, signature bottleneck cascades, quality variance, and institutional memory loss. These failures are not caused by individual incompetence. They are structural consequences of the absence of a pipeline.

A submission pipeline has a concrete architecture: inputs (submission-generating events), processing (where the RC's pipeline capabilities operate), outputs (completed submissions to IRBs), and feedback (post-submission tracking that informs future operations). The next lesson begins building this pipeline by teaching you to see your submission landscape -- the full scope of what you are managing.