EDC Database Build: What Happens Between Protocol and First Patient In
An EDC database build runs in a fixed order: protocol review, data collection specification, eCRF design, edit check specification, configuration, testing, validation documentation, training and go-live. The durations vary by study. The sequence does not, and the three steps teams compress under pressure are always the same three.
The build is the part of a study where decisions are cheapest to make and most expensive to postpone. Every ambiguity left open here becomes a query, a reconciliation problem or a mapping cost later, usually landing on someone who was not in the room when it was left open.
This guide walks the sequence in order, says what each step should produce, and names the three that get cut when the timeline slips. It sits under the wider subject of how clinical trial data moves from site entry to submission, and assumes you have a final protocol in hand.
After reading this you will be able to:
- Sequence a build and know which steps sit on the critical path
- Name the artifact each step should produce, so progress is checkable
- Recognize the three compressions before they happen, and price them
- Run a readiness check that is harder to pass than a status call
The Build Sequence, in Order
Seven steps. The order is not a convention, it is a dependency chain: each step produces the input the next one needs.
Teams that run these out of order almost always do the same thing, which is to start designing forms before the data collection specification exists. The forms then become the place where unresolved protocol questions get answered, quietly, by whoever is building them.
From Protocol to Data Collection Specification
The protocol says what the study measures. The specification says what the database will accept. Turning one into the other is where the real work of a build happens.
A specification worth the name lists every item to be collected, the visit at which it is collected, its units, its permitted values, and what should happen in the cases the protocol does not address. If the protocol says an assessment occurs at screening and your form offers a single date field, someone has already decided how to handle the site that spreads screening across two days. The only question is whether that was a decision or an accident.
The mechanism that closes those questions is a joint read. Put the medical, data and statistics leads in the same room and go through the specification with one question in mind: what would two different sites do with this field? It is an afternoon, and it routinely saves a fortnight.
eCRF Design, and Why CDASH Belongs Here
Form design is the visible part of a build and the part most often judged on how it looks. What matters more is the structure underneath, because that structure has to survive all the way to a submission dataset.
Designing with CDASH conventions in view costs a little at this step and saves considerably later. Field naming, code lists instead of free text, one concept per field, consistent date handling: these are the choices that decide whether submission mapping takes days or months. Annotating the forms to the submission structure while they are being designed is the cheapest decision in the whole study, and where CDASH to SDTM mapping breaks goes through the specific choices that hurt.
Edit Checks: Specify Before You Configure
Checks should be written down before anyone builds them, in plain language, with the expected behavior stated. This sounds bureaucratic and is the difference between a check set someone can review and a check set that exists only inside the system.
The review question is not whether a check is logically correct. It is what a site coordinator will do when it fires. A check written against the protocol can be perfectly correct and still produce a query nobody can answer, which is how studies end up with high query counts and long resolution times at the same time. Why query volume rises late in a study covers the design patterns in detail.
Testing, Documentation and Go-Live
Testing comes in two layers. The build team confirms the study matches the specification. Then the people who will use it try to break it: out-of-range values, missing visits, assessments out of order, the screening that ran across two days. Testing done only by the builders confirms the build matches the build, which was never the question.
Validation documentation is assembled alongside, not afterwards. It records what was tested, against what, with what result, and who approved it. Scoping that effort by risk rather than by habit is the approach in GAMP 5 Second Edition, and it is how regulators expect effort to be targeted.
Go-live is then an administrative event rather than a milestone to be survived: sites are trained, records exist, the release is approved, the database opens.
The Three Steps Everyone Compresses
When a build runs late, three things get cut, and it is reliably the same three.
None of this is a moral point about discipline. Timelines slip for real reasons and something has to give. The argument is only that compressing these three does not remove work, it relocates it, usually into a month with less room and onto a team that did not make the decision.
What Each Step Should Produce
The useful test of build progress is not percentage complete. It is whether the artifact exists.
A Readiness Check Before Go-Live
Eight questions. More than two uncertain answers means the date is optimistic.
- Has the data collection specification been read jointly by medical, data and statistics, in this version?
- Is every open question in it closed, in writing?
- Have the eCRFs been annotated to the submission structure, and has statistics seen the annotation?
- Was every edit check tested with data designed to break it, not only clean data?
- Did anyone who will actually enter data take part in UAT?
- Has each external data transfer been run end to end at production-shaped volume?
- Does the validation documentation describe what was tested, not only that testing happened?
- Is there a change-control route for an amendment that someone has walked through?
Clinera EDC is the platform layer this sequence configures, and clinical and R&D AI covers where automation helps in review and reconciliation once the study is live. If the build is already behind you and the protocol has changed, handling a mid-study amendment without revalidating the whole build picks up from there.
References
- ICH E6(R3) Good Clinical Practice. International Council for Harmonisation, adopted 6 January 2025. www.ich.org
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- CDASH, Clinical Data Acquisition Standards Harmonization. CDISC foundational standards. www.cdisc.org
- Good Clinical Data Management Practices. Society for Clinical Data Management. scdm.org
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
How long does an EDC database build take?
It depends on protocol complexity, how many external data sources are involved, and how much of the specification is settled before configuration starts. A single-arm study with a stable protocol and one laboratory feed is a different exercise from an adaptive design with device data and three vendors. The more useful planning question is which steps sit on the critical path, because the sequence is fixed even when the durations are not.
What is the first step in a database build?
Turning the final protocol into a data collection specification. Not eCRF design, which is the common mistake. The specification says what will be collected, at which visits, in what units, with what permitted values and what happens in the edge cases the protocol does not address. Designing forms before that exists means the forms become the place where those decisions get made by accident.
Should the eCRF be annotated to SDTM during the build?
Yes, and it is the single cheapest submission decision available to you. Annotating at design time costs a few hours and shapes field choices while they are still easy to change. Annotating at submission time means the mapping has to absorb every decision that was left open during the build, under the tightest timeline in the study. The specific design choices that make this cheap or expensive are worth understanding before the forms are finalized.
Who should do user acceptance testing?
The people who will actually use the system, which means site coordinators or their proxies for data entry, and data managers for review and query workflow. Testing done only by the team that built the study confirms that the build matches the build, which is not the question. UAT should try to break things: out-of-range values, missing visits, out-of-order assessments, the patient who does screening across two days.
What goes in a validation package for a study build?
A validation plan describing what will be tested and why, the executed test scripts with actual results, a record of defects raised and how they were resolved, a summary report, and approvals. The distinction that matters at inspection is between documentation describing what you validated and documentation merely asserting that you validated. The first is inspectable and the second is not.
Can Nirmitee Healthtech run the build if our protocol is already final?
Yes, and a final protocol is the right starting point rather than a late one. The first piece of work is the data collection specification and the open questions in it, which is also the fastest way to see where the study will be difficult. From there the sequence is the one described above, with the annotation and validation steps built in rather than added at the end.
