Guidelines for Hard-Locking a Clinical Research Database
May 27, 2010 Clinical Research Education
For every clinical research study, there is a beginning, several interim milestones and a definite endpoint. For the clinical research database, the initial milestone is normally finalization of the study protocol. While interim milestones vary by study, phase, indication, endpoint and sponsor; common interim milestones include the following: safety analysis of cohort data in dose escalation studies; interim analysis based on milestones defined in the Clinical Study Report (i.e.: 50% of subject data received or with an endpoint of survival, 50% of study subjects deceased); testing of programming code for the development of draft tables, figures and listings.
The final milestones relate to database closure and are termed ‘database soft lock’ or ‘database freeze’ and ‘database hard lock’. The distinction between these terms is as follows:
Database soft lock also known as database freeze is a milestone defined in the Statistical Analysis Report and is most commonly defined as the point where all case report form data has been input into the database and all known queries are resolved. When soft lock is declared, the edit rights of all data entry and data management personnel are rescinded so that only the Lead Data Manager has the ability to modify the database.
At this point, the QA department will review a random sample of the study data in order to assure that the data is clean enough for analysis and to define the exact error rate. The sample size reviewed by QA is based on the square root of the total number of records. So, for instance, given a database with approximately 950,000 records, 974 of those records will be printed out on a listing for QA to review against the original CRFs. These records are generated using a random seed so that if the listing at some point needs to be regenerated, the seed allows the team to do so. The FDA standard for an acceptable error rate is = .05% or = 1 error every 2000 fields. Once the database passes QA, a QA certificate is generated documenting the actual error rate and hard lock can then be declared.
Once hard lock is declared, all edit rights, including those of the Lead Data Manager, are rescinded from the team. At this point final tables, figures and listings can be generated. Also, if the clinical study was blinded, the statisticians can now generate programs to unblind the data. Unblinding does not take place prior to hard lock in order to minimize the potential for bias.
Once hard lock is declared, the database is considered final and should never be unlocked. Of course there are exceptions to every rule. On rare occasion, even after all queries generated by the clinical and data team have been resolved, a statistical programmer, a statistician or a medical writer on the team will notice an inconsistency in a data value. If the inconsistency is associated with a critical data field, the database may need to be unlocked.
A likely reason for unlocking the database is identification of a difference in the regulatory and clinical databases associated with a serious adverse event. Oftentimes, the reconciliation between these 2 databases is not finalized until the very end of the study. Also, if subjects develop SAEs near study end, they need to be followed for 30 days beyond their official ‘final date on study’ OR until the SAE is resolved OR until the subject begins treatment with another medicinal product. Also, should a female subject or the spouse of a male subject being treated on a clinical trial becomes pregnant, the pregnancy is followed until birth, in order to identify potential SAEs. In this case, data could stream in well after all of the previous data have been received and analyzed; and if an SAE is identified, it should be incorporated into the final tables, figures and listings.
The process for unlocking a ‘final’ database must be pre-defined in the study project plan and must be supported by the sponsor’s relevant SOPS. Also, when the erroneous data is changed, an audit trail will document what data field was changed, who changed it, when it was changed and why it was changed. The database is then re-locked following the same process as noted previous for the first hard lock and generation of final Tables Figures and Listings and the Clinical Study Report are then completed.
For changes to less critical fields, unlocking a ‘final’ database is not warranted. In this case, a memo is generated to the team, and incorporation of the relevant database change can be handled programmatically, with proper documentation.
Erin P. Johnson is a Clinical Research Consultant with 22 years industry experience including data management, quality assurance, field monitoring and project management and all phases of clinical research. She is currently a Clinical Consultant at Supergen, and also teaches Clinical and Data Management topics in the Clinical Research Education and Training Online (CREAT-e) Certificate program offered by California State University, East Bay and ClinfoSource.
Share this:
May 27, 2010 Clinical Research Education
For every clinical research study, there is a beginning, several interim milestones and a definite endpoint. For the clinical research database, the initial milestone is normally finalization of the study protocol. While interim milestones vary by study, phase, indication, endpoint and sponsor; common interim milestones include the following: safety analysis of cohort data in dose escalation studies; interim analysis based on milestones defined in the Clinical Study Report (i.e.: 50% of subject data received or with an endpoint of survival, 50% of study subjects deceased); testing of programming code for the development of draft tables, figures and listings.
The final milestones relate to database closure and are termed ‘database soft lock’ or ‘database freeze’ and ‘database hard lock’. The distinction between these terms is as follows:
Database soft lock also known as database freeze is a milestone defined in the Statistical Analysis Report and is most commonly defined as the point where all case report form data has been input into the database and all known queries are resolved. When soft lock is declared, the edit rights of all data entry and data management personnel are rescinded so that only the Lead Data Manager has the ability to modify the database.
At this point, the QA department will review a random sample of the study data in order to assure that the data is clean enough for analysis and to define the exact error rate. The sample size reviewed by QA is based on the square root of the total number of records. So, for instance, given a database with approximately 950,000 records, 974 of those records will be printed out on a listing for QA to review against the original CRFs. These records are generated using a random seed so that if the listing at some point needs to be regenerated, the seed allows the team to do so. The FDA standard for an acceptable error rate is = .05% or = 1 error every 2000 fields. Once the database passes QA, a QA certificate is generated documenting the actual error rate and hard lock can then be declared.
Once hard lock is declared, all edit rights, including those of the Lead Data Manager, are rescinded from the team. At this point final tables, figures and listings can be generated. Also, if the clinical study was blinded, the statisticians can now generate programs to unblind the data. Unblinding does not take place prior to hard lock in order to minimize the potential for bias.
Once hard lock is declared, the database is considered final and should never be unlocked. Of course there are exceptions to every rule. On rare occasion, even after all queries generated by the clinical and data team have been resolved, a statistical programmer, a statistician or a medical writer on the team will notice an inconsistency in a data value. If the inconsistency is associated with a critical data field, the database may need to be unlocked.
A likely reason for unlocking the database is identification of a difference in the regulatory and clinical databases associated with a serious adverse event. Oftentimes, the reconciliation between these 2 databases is not finalized until the very end of the study. Also, if subjects develop SAEs near study end, they need to be followed for 30 days beyond their official ‘final date on study’ OR until the SAE is resolved OR until the subject begins treatment with another medicinal product. Also, should a female subject or the spouse of a male subject being treated on a clinical trial becomes pregnant, the pregnancy is followed until birth, in order to identify potential SAEs. In this case, data could stream in well after all of the previous data have been received and analyzed; and if an SAE is identified, it should be incorporated into the final tables, figures and listings.
The process for unlocking a ‘final’ database must be pre-defined in the study project plan and must be supported by the sponsor’s relevant SOPS. Also, when the erroneous data is changed, an audit trail will document what data field was changed, who changed it, when it was changed and why it was changed. The database is then re-locked following the same process as noted previous for the first hard lock and generation of final Tables Figures and Listings and the Clinical Study Report are then completed.
For changes to less critical fields, unlocking a ‘final’ database is not warranted. In this case, a memo is generated to the team, and incorporation of the relevant database change can be handled programmatically, with proper documentation.
Erin P. Johnson is a Clinical Research Consultant with 22 years industry experience including data management, quality assurance, field monitoring and project management and all phases of clinical research. She is currently a Clinical Consultant at Supergen, and also teaches Clinical and Data Management topics in the Clinical Research Education and Training Online (CREAT-e) Certificate program offered by California State University, East Bay and ClinfoSource.
Share this:
1
