Startup time does not always disappear at the site. A Phase I/II oncology sponsor team had a protocol finalized in late November and a first patient in date in mid-February, leaving roughly eleven weeks for a 22-visit adaptive design with four expansion cohorts. CRF annotation had not started, and although the EDC vendor was selected, the build had not been scoped. The window was real, but its allocation across startup work was too optimistic.
The interval between protocol approval and first patient enrollment depends on several tracks that no single team controls. IRB approval, contracts, investigator training, and site feasibility proceed on their own schedules. Among sponsor-controlled activities, EDC setup is often the point that slips and pushes every downstream milestone. Sites may be ready, IRB approval may arrive, and investigators may be contracted, yet the study cannot open until the database is validated.
Why CRF Design Is Not the Bottleneck You Think It Is
Clinical operations teams often identify CRF design as the slow phase because it requires iteration among data management, medical writing, the study team, and sometimes regulatory affairs. CRF annotation, blank CRF review, and CRF completion guidelines are genuine coordination points, each requiring calendar time.
Still, CRF design usually runs alongside activities that take longer. The study team does not need to wait for a complete, approved CRF package before starting EDC configuration. Most builds begin with a draft CRF and evolve as annotation resolves open questions. CRF design feeds the EDC build, but in a well-run study, configuration is already in progress before the CRF is final.
The meaningful gap for first patient in is between the first complete EDC database draft and the validated, sponsor-approved, site-ready database. Internal UAT, sponsor review, data management plan alignment, and sometimes a third change round fill that gap. Every cycle needs time for scheduling, execution, and responses. A data management team can produce a first draft quickly and still miss enrollment if two extended review cycles follow.
Where Time Goes in a Typical EDC Build
We have reviewed startup timelines for a number of pilot studies. The pattern is consistent enough to serve as a planning reference, while the sample remains small and is not a formal study.
Initial protocol reading and mental model construction takes three to five business days when a data manager is starting cold. In complex adaptive designs, that can reach seven to ten days because the branching structure requires close reading across protocol sections that refer to one another.
The first visit schedule and form structure draft takes five to ten days for a moderately complex protocol on a major EDC platform. This work includes visit objects, naming conventions, basic form structure, and field types. Teams usually defer edit checks and derivations to a second configuration pass because those depend on a defined form structure.
Edit check configuration takes three to eight days, depending on eligibility criteria, primary endpoint calculations, and cross-visit derivations. Misinterpretations in the first draft often surface here and require changes that reach back into the form structure.
Internal review and the first revision cycle take one to two weeks, including reviewer time and implementation of changes. Sponsor UAT generally takes another one to two weeks. A study with three review rounds before sign-off can spend five to six weeks in review and revision alone, even when each review is completed promptly.
What Compression Actually Looks Like
Closing the gap between CRF design and first patient in means shortening at least one of these phases. The easiest phases to compress are those dominated by manual, sequential work that does not depend on external approvals or other parties' schedules.
Initial protocol reading and the first draft are the clearest opportunities. A data manager typically works through the protocol serially, forms a mental model, and translates it into database objects. Structured digitization shortens this work by producing a parsed protocol representation for the data manager to review instead of construct. Reviewing a proposed interpretation is faster than generating one, and it can expose more errors because the reviewer is testing an explicit interpretation.
Tooling has less effect on review and revision because those phases require coordination among people with independent schedules and different UAT capacity. A cleaner first draft still helps. A draft generated through structured parsing has a different error profile from a hand-built draft: fewer transcription errors from misreading the protocol, more consistent naming conventions, and closer alignment between form structure and the CDASH patterns expected by the sponsor's data management team. Fewer change requests follow, which shortens review cycles.
The CDASH Domain Alignment Question
CDASH domain alignment is one area where manual builds often generate review comments. The CDISC CDASH implementation guides define standard collection forms for common clinical domains, including demographics, medical history, adverse events, concomitant medications, laboratory tests, vital signs, and disease-specific assessments. A database aligned with CDASH conventions maps more cleanly to SDTM datasets and reduces annotation work in the submission package.
Manual builds differ in their consistency with CDASH conventions, based on data manager experience and sponsor standards. Common deviations include non-standard variable names in domains such as adverse events, for example AETERM versus sponsor-specific names, non-standard codelist implementations for standard dictionaries, and forms that combine CDASH domains in ways that make mapping harder.
A structured build that generates CDASH-aligned form objects by default establishes consistent domain alignment without requiring the data manager to recall every convention during configuration. Review cycles that previously included a CDASH check become shorter because alignment issues are addressed upstream. This illustrates a broader principle: preventing an error during generation is easier than finding the same error in UAT.
Site Readiness Depends on EDC Readiness
The interval from protocol approval to first patient in is influenced by more than the EDC build. That boundary matters. The connection between EDC readiness and site readiness, however, is tighter than many timelines show.
Investigator training on the EDC cannot finish until the database is validated. If electronic patient diaries are used, they depend on eCOA configuration, which in turn depends on the EDC form structure. Site login provisioning requires a finalized database. In jurisdictions that require evidence of database validation before site opening, regulatory submissions also depend directly on EDC completion.
Shortening the EDC phase does not shorten every dependency. Some sites will be slow to complete training, some jurisdictions will have lengthy review timelines, and some investigators will have competing commitments regardless of when credentials arrive. A validated database available six weeks earlier than baseline does give sites six additional weeks to train and activate. In a competitive enrollment setting, that can change how many sites are active during the early enrollment months, affecting enrollment velocity and total study duration.
The gap from CRF design to first patient visit has different types of work within it. External constraints cannot be moved by tooling. Protocol reading, database construction, and first-draft review cycles are internally controlled and can be compressed. Their effect continues downstream, which is why the value of a better build process can appear before the first patient visits a study site.