.jpg){kind=link}
- Published
- Updated
- Sources checked
A database lock date is a planning milestone, not evidence that the study data are ready. The lock decision should state exactly which data cut, unresolved issues and approvals it covers.
Set readiness criteria
Define readiness criteria in the data management plan and align dependencies with statistics, medical review and safety teams. Account for external data, coding, investigator review and reconciliations. Assign a decision owner for exceptions rather than assuming all open items have equal significance.
Assemble the lock pack
A lock pack can identify the database version, accepted external files, reconciliation summaries and remaining issues. If a late laboratory file is excluded, explain the population affected and how the decision relates to the planned analysis. Preserve the decision before restricting changes.
Pre-lock checks
- Confirm the exact extract and coding versions for analysis.
- Document every accepted exception and its impact assessment.
- Verify lock permissions and the controlled unlock procedure.
Control lock and reopening
Accept lock when named reviewers approve the defined readiness evidence and downstream users receive the agreed data package. If reopening becomes necessary, record the reason, authorised changes, checks repeated and replacement extract; do not silently overwrite the previous handover. Keep the lock implementation time distinct from the data cut, and connect final provider acknowledgements with the analysis team’s receipt record.
Frequently asked questions
- Can a database lock with open queries?
- A justified, approved exception may be possible; assess its effect rather than rely on the query count.
- Is lock the same as analysis finalisation?
- No. Preserve separate decisions for database control, analysis datasets and final reporting.