From Protocol to Database Lock: The Clinical Research Data Lifecycle

Every clinical study, whatever its size or sponsor, has to solve the same problem: turning a protocol — a document describing what should happen — into a locked, analyzable database describing what actually happened. The distance between those two artifacts is where clinical data management lives. This guide walks that distance stage by stage.

Design: the protocol becomes a data specification

Data management starts before any system is touched. The protocol defines visits, assessments, endpoints, and eligibility criteria; the data management team translates those into a concrete specification — which data points will be collected, when, from whom, in what structure, and against which standards. On regulated studies this is also where teams decide how collection will map to CDISC standards such as CDASH, so the eventual submission datasets are designed in rather than retrofitted ^[4]. Good practice reviews the protocol itself for data collectability: an endpoint that cannot be captured cleanly is a protocol problem, best caught now. See protocol and study design and metadata and data dictionaries.

Build and test: the eCRF, edit checks, and UAT

The specification becomes an electronic case report form (eCRF) — the structured forms sites and participants will complete. The build includes:

• eCRF design — forms, fields, coded value lists, skip logic, and layout, often starting from form and study libraries rather than a blank page.
• Edit checks — the automated validation rules that fire at entry or in batch: ranges, required fields, cross-form consistency, date logic.
• Visit scheduling — the visit matrix that ties forms to protocol-defined timepoints and windows.
• Roles and access — role-based permissions and, on blinded studies, blinding controls configured before the first participant is entered.

Then the build is tested. User acceptance testing (UAT) means entering realistic data — good data, bad data, edge cases — and confirming that forms behave, checks fire when they should and stay silent when they should, and exports contain what the statisticians expect. On regulated studies, this testing is documented as part of the evidence that the system is fit for purpose, alongside the vendor's and sponsor's validation documentation ^[2][3].

Capture: data enters the system

Once the database goes live and sites are trained, capture begins. Site staff transcribe visit data into the EDC system; participants may contribute directly through participant-reported outcomes instruments; laboratory data, imaging and device data, and EHR-sourced data may flow in through transfers or integrations. Every entry and correction is recorded in the audit trail — who, what, when, and why — which is a core expectation of both ICH GCP and FDA's guidance on electronic systems in clinical investigations ^[2][3].

It helps to follow a single data point through the machinery:

The protocol demands a measurement; a visit produces it; an eCRF captures it; validation questions it; a query resolves it; and the cleaned value flows into a dataset that supports a submission or publication. Everything in this guide exists to protect that chain.

Review and query: cleaning the data

Cleaning runs continuously from first entry to lock. It combines:

• Automated data validation — edit checks plus batch listings that scan for missing visits, outliers, and cross-form inconsistencies.
• Query management — the formal conversation between data reviewers and sites: a discrepancy is raised, the site answers or corrects, the reviewer closes or re-queries. Query aging and volume are the day-to-day health metrics of a study.
• Source data review and monitoring — monitors comparing the database against source records, increasingly guided by risk-based approaches under ICH E6(R3) rather than 100% verification ^[2]. EDC systems support this with monitoring workflows.

The goal is not perfect data — it is data whose remaining imperfections are known, documented, and acceptable for the analysis at hand ^[1].

Code: standardizing medical terms

Free-text medical terms have to become standard vocabulary before analysis. Adverse events and medical history are coded to MedDRA (MedDRA coding); concomitant medications to WHODrug (WHODrug coding). Autocoders handle exact and synonym matches; human coders — with medical review — handle the rest, and ambiguous verbatim terms generate their own queries back to sites. See coding workflow and autocoding and adverse event data.

Reconcile: making parallel records agree

Most studies hold the same facts in more than one system, and those systems must agree before lock:

• Safety reconciliation — the clinical database versus the sponsor's pharmacovigilance safety database, case by case for serious adverse events.
• External data reconciliation — central lab transfers, randomization systems, ePRO platforms, and imaging vendors against the EDC record (data reconciliation).

Reconciliation is tedious and essential: a submission whose safety database and clinical database disagree invites exactly the questions no sponsor wants.

Interim and blinded reviews

Before lock, most studies hold structured looks at the data. Blinded data reviews examine cleanliness, protocol deviations, and analysis-population decisions without revealing treatment assignment (blinding controls). Studies with data monitoring committees or planned interim analyses require partial database snapshots delivered under controlled unblinding procedures. Each review is effectively a rehearsal for lock — and frequently surfaces cleaning work the routine process missed.

Lock: soft, then hard

Soft lock (or freeze) restricts editing while the team runs final checks: outstanding queries resolved or formally waived, coding complete, reconciliation signed off, protocol deviations documented, and required electronic signatures — such as investigator signoff on casebooks — in place.

Hard lock removes write access entirely. It is a formal, documented, signed decision: from this point, the dataset that statisticians analyze is fixed, and on blinded studies, unblinding for analysis follows lock — never the reverse. Any later change requires a controlled, documented unlock with its own audit trail. See database lock.

Deliver and archive

After lock, data management delivers: extracts to statistical systems, submission datasets in CDISC SDTM structure where required ^[4], and transfers to sponsors, registries, or repositories via data export. Then the study is archived — data, audit trails, queries, signatures, and the documentation of the build and testing itself — under archiving and retention obligations that typically run for years, and in a form a future auditor can actually reconstruct ^[2][3].

What commonly goes wrong

• Late protocol amendments. An amendment that changes assessments or visit structure forces mid-study changes to a live database — new forms, migrated data, re-fired edit checks, site retraining — while enrollment continues. Amendments are often unavoidable; underestimating their data management cost is not.
• Dirty legacy data. Studies that begin on spreadsheets or paper and migrate into an EDC mid-stream import every inconsistency of the old process, usually without audit trails for the original entries. The migration itself becomes a mini-study: mapping, validation, and documented reconciliation.
• Rushed UAT. When build timelines slip and first-patient-in does not, testing is what gets compressed. The defects do not disappear — they reappear as mid-study changes and query volume, at many times the cost.
• Lock-then-unlock cycles. Locking before the data is genuinely ready — to hit a milestone date — leads to unlocks, each requiring documented justification and each eroding confidence in the final dataset. A lock date driven by data readiness is slower once; a lock date driven by the calendar is often slower twice.

Where to go next

This workflow is one half of a larger frame — the study lifecycle and the data lifecycle running in parallel — which we develop in The Two Lifecycles of Clinical Research. For the systems that support each stage, see our capability reference and the technology directory; for choosing among them, start with Choosing an Electronic Data Capture System.