What is it? Why is it important?
Database lock is the action taken to prevent any further changes to the study data. Two main database locks exist:
- Interim lock which is performed during study conduct due to:
- Final lock which is performed after:
Interim database locks (before all data has been collected) can be planned in order to evaluate whether to continue, adapt or terminate a study. This can be due to:
- Safety concerns (e.g. a potential high frequency of adverse events (AE, ADE) during study treatment)
- Efficacy concerns (e.g. treatment effect compared to placebo is highly superior or has no added benefit)
Data analysis not based on specifications given in the study protocol carries the risk of corrupting the study, as researchers are no longer independent study bystanders but become biased as to study outcome.
Database locks can also be planned during long term studies, with the aim to minimise data cleaning workload once the study is terminated.
What do I need to do?
- Grounds for database lock (e.g. based on study protocol specifications)
- Frequency and timing of lock(s) (e.g. after inclusion of 3 participants, 1st participant has completed the planned study treatment)
- SP-INV and Site-INV responsibilities (e.g. eCRF sign-off confirming that study data is complete, correct and validated)
- Access management (e.g. staff logins are cancelled to prevent further changes to the study data)
- How to document database lock (e.g. time and date of lock, including the version of the locked database)
- Type of interim statistical analysis, including required implications in the event of unexpected deviations (e.g. the study may have to be adapted or discontinued due to safety or efficacy concerns)
Upon locking the database, it is important to document the exact date and version of the locked database. This confirms that:
- The current and correct study database version was used by the statistician during data analysis
- Data analysis was done after the database was locked
To ensure data quality and facilitate database lock, plan ahead and ensure that:
- Data entries are performed on an ongoing basis, while data is still “fresh”. Hindsight backlog of large volumes of data carries increased risks of data errors, and data quality concerns
- SP-INV and Site-INVs sign-off CRFs on an ongoing basis. A task that should not be postponed to the end of the study. By signing-off the CRFs, it is confirmed that all required data (variables) is entered in the database and has been monitored to be correct
- External data providers (e.g. laboratories) are informed of upcoming database locks to ensure that all data (variables) imports have been integrated into the study database
- Data monitoring visits are planned in good time before any planned database locks
Where can I get help?
Your local CTU↧ can support you with experienced staff regarding this topic
Basel, Departement Klinische Forschung, CTU, dkf.unibas.ch
Lugano, Clinical Trials Unit, CTU-EOC, www.ctueoc.ch
Bern, Clinical Trials Unit, CTU, www.ctu.unibe.ch
Geneva, Clinical Research Center, CRC, crc.hug.ch
Lausanne, Clinical Research Center, CRC, www.chuv.ch
St. Gallen, Clinical Trials Unit, CTU, www.kssg.ch
Zürich, Clinical Trials Center, CTC, www.usz.ch
ICH GCP E6(R2) – see in particular guidelines
- 5.5. Trial Management, data handling, and record-keeping