The 68-day number comes from the Tufts CSDD eClinical Landscape Study on database build cycle times. We have cited it before. What we have not done is go through what those 68 days actually consist of — because the breakdown is more instructive than the headline.
We spoke with DM leads at six mid-size sponsors (two biotech, two CRO, two academic). We asked each one to walk us through the last study build they had managed, hour by hour where possible, and categorize the time. The names and therapeutic areas are anonymized. The cycle times are real.
The composite timeline
The six studies ranged from 51 to 84 days. Across all six, the time breaks down roughly as follows:
Protocol interpretation: 8–12 days. The DM team reads the protocol and extracts the information needed to build the CRF: endpoints, assessments, visit schedule, eligibility criteria, data collection requirements. This is done in a Word document or a structured template, depending on the sponsor. It takes this long because the protocol is written for a clinical audience, not a data management audience, and the DM team has to infer data collection requirements from clinical language. ("Vital signs at screening and each visit" means something specific about which vital signs, at which visit windows, with what units and normal ranges — none of which the protocol states explicitly.)
CRF design: 6–10 days. Once the data collection requirements are extracted, the DM team designs the CRF. This involves decisions about form structure, field-level specifications, controlled terminology, and the relationship between CRF design and SDTM domain structure. The CRF has to be designed with SDTM in mind, which means the DM team is effectively making SDTM decisions during CRF design — even if the formal SDTM mapping comes later.
Internal review: 5–8 days. The DM team circulates the CRF design for internal review. The protocol team flags clinical concerns. Biostatistics flags endpoint inconsistencies. Regulatory flags controlled terminology questions. Each round of comments requires the DM team to interpret, respond, and revise. Most studies go through two review rounds at this stage.
EDC build: 8–14 days. The approved CRF design is handed to the EDC configuration team (sometimes the same person, sometimes a specialized contractor). The EDC build translates the CRF specification into the EDC system — Medidata Rave, Veeva Vault, or similar. This includes field configuration, edit checks, derivation rules, and form logic. The complexity here scales steeply with protocol complexity; adaptive designs and complex eligibility logic add days.
UAT: 7–12 days. User acceptance testing catches configuration errors in the EDC build. Most UAT cycles surface between 20 and 80 issues that require revision. Each revision cycle takes 1–3 days. Most studies complete UAT in two rounds; complex protocols need three.
SDTM mapping documentation: 6–10 days. While the EDC is being built and tested, a separate SDTM mapping document is produced. This maps every CRF field to its SDTM variable, documents the derivation rules for derived variables, assigns controlled terminology, and documents the logic for producing conforming SDTM datasets. Most DM leads describe this as "the most tedious part of the entire process."
DMP production: 4–8 days. The Data Management Plan is a regulatory document that describes how the trial's data will be collected, validated, and prepared for analysis. It references the CRF, the edit check specifications, the query management procedures, and the SDTM mapping documentation. Because it references all of these, it can only be finalized after they are all complete — which means it sits at the end of the critical path and delays the entire package.
Waiting: 8–16 days. This is the number nobody talks about. Across our six studies, 12–24% of the total build time was pure waiting: waiting for a medical monitor to review the CRF, waiting for a statistician to confirm an endpoint definition, waiting for legal to approve a consent form revision, waiting for the EDC vendor to respond to a configuration question. The DM team was not the bottleneck during these periods. They were waiting on other people.
Where the time actually goes
If you add up the active DM team hours versus the calendar days, a pattern emerges: the DM team is actively working on the build for roughly 30–35 days of the 68. The other 33–38 days are a combination of review waiting time, revision cycles, and coordination overhead.
The second pattern is that almost all of the active DM time is translation work. Protocol text → CRF fields. CRF fields → SDTM variables. SDTM variables → mapping documentation. SDTM mapping → DMP text. Each translation involves taking information that exists in one form and converting it to a different form for a downstream consumer. The intellectual content of those translations — the decisions about which SDTM domain to use, which controlled terminology to apply, how to handle a complex eligibility criterion — is a fraction of the total time. Most of the time is the mechanical work of the translation itself.
What a faster build actually looks like
TrialNexus Core cuts the active DM time roughly in half by automating the translation steps. Protocol → USDM happens in minutes, not 8 days. The SDTM mapping documentation is generated from the USDM representation rather than written by hand. The DMP is drafted from the CRF and SDTM mapping artifacts rather than assembled manually.
What it does not eliminate is the review cycle. The DM lead still needs to review every output before it is committed. Expert humans still need to confirm endpoint definitions and approve CRF designs. Biostatistics still needs to sign off on the analysis dataset structure.
But it transforms the review cycle from a correction exercise to a verification exercise. Instead of a biostatistician reviewing a blank template and writing endpoint specifications from scratch, they review a drafted specification that is correct for 80–90% of fields and needs judgment applied to the rest. The meeting that took three hours takes forty minutes.
The waiting time does not change. That is a coordination problem, not a tooling problem. But when the DM team's active work time drops from 30 days to 12, the waiting periods become visible as the actual bottleneck — and that is a solvable problem of process design, not software.
Twelve days is not a marketing claim. It is what happens when you remove the translation work and keep the judgment work. The people who used to spend their day converting PDFs to Excel spend it on the decisions that require their expertise. The calendar gets shorter because the right work takes less time, not because anyone is cutting corners.