Endpoint Data Before Database Lock: A Reconciliation Checklist

A database lock is a documented decision that the clinical database is complete and reliable enough to freeze for analysis. It is not a calendar milestone that arrives once a task list runs out. The joint FDA/MHRA GCP workshop paper describes locking the database to prevent further changes and declaring it fit for analysis as “a key step and decision point in confirming data integrity.” For endpoint owners, that framing sets the test for every checklist row: does it supply evidence for the declaration, or not?

Take a hypothetical case, Protocol MET-402 (illustrative, not a real study): a 240-participant Phase IIb trial whose co-primary endpoints are a centrally read imaging score and a central-laboratory biomarker, with a weekly ePRO diary. Ten days before the planned final lock, five items are open: (1) the imaging core lab’s final read transfer is two weeks late; (2) one participant death exists in the safety database with no matching clinical-database record; (3) 38 diary queries remain open; (4) the principal investigator (PI) at the highest-enrolling site has not electronically signed a casebook in four months; and (5) the medical monitor has not approved the adverse-event coding list. Which items block the lock, what evidence must each resolution produce, who signs, and what has to happen before unblinding?

The short answer: four of the five items block the final lock. The fifth does not move the date on its own, provided it is closed explicitly.

• The late imaging transfer blocks the lock. For a final lock, the Society for Clinical Data Management’s Good Clinical Data Management Practices (GCDMP) expect all external data to be received, complete, and reconciled. A co-primary stream that has not arrived can be none of these.

• The safety-only death blocks the lock. A separate SAE database should be reconciled with the study database, and every safety-database SAE missing from EDC has to be researched. The result is either a monitored site update or a documented, explained difference.

• The unsigned casebooks block the lock. GCDMP and the FDA/MHRA paper both place PI sign-off before lock. EMA warns that one signature immediately before lock “will rarely be sufficient,” which makes the four-month gap a process finding as well as a blocker.

• The unapproved coding list blocks the lock. GCDMP expects a medical monitor or safety surveillance team to approve it before final lock.

• The 38 diary queries do not move the date by themselves. They must still close before lock, but a site’s confirmation that no further data exist counts as a resolution. The value then stays missing and is handled by the statistical analysis plan’s (SAP’s) pre-specified rules. An open query must never silently become missing data at lock.

Before edit access is removed, the approvals should be documented and the date of edit-access removal recorded. The database’s own audit trail or system log should be able to confirm the actual lock date, and the signed checklist itself is an essential record. In a blinded study, unblinding comes only after lock, SAP finalization, and review of subject populations for analysis, and only with documented authorization.

For orientation, the GCDMP chapter uses these working definitions:

• Interim lock: a snapshot of the database at a point in time while the study is still in progress, typically for interim analyses, listings, or reports. GCDMP accepts that an interim lock may proceed with unresolved queries and incomplete external data, although critical queries that could affect the interim analysis should be addressed. EMA is stricter for one case: all data submitted for a planned interim analysis, such as a marketing authorisation filing, need investigator sign-off before extraction.

• Soft lock: access to the database is limited while data management confirms the data are suitable for final analysis. Some organizations use it to check that every final-lock activity has actually been done.

• Final lock (freeze, hard lock): access is removed so that no further changes can be made, and access is typically restricted to the people responsible for closing, delivering, and archiving the database. In EDC systems, GCDMP notes, access may be set to read-only at the lock stages, with complete removal after closure. A final lock is not irreversible: it can be undone, but only through a predefined, documented unlock procedure.

• Database closure: the processes that finalize the database as a final study deliverable. The final lock is a key part of closure, not the whole of it.

ICH E6(R3) gives the checklist a status that vendor templates rarely mention. Among its criteria for an essential record, Appendix C lists a record that “documents the conduct of relevant trial procedures (e.g., database lock checklist produced from following data management standard operating procedures (SOPs))” (C.3.1(d)). Section 3.16.3 asks the sponsor to retain its sponsor-specific essential records in line with applicable regulatory requirements. That makes the completed, signed checklist an inspection artifact that belongs in the trial master file (TMF), not a tracker deleted after the lock call.

Two data-handling clauses in E6(R3) come closest to describing the lock itself. Under 3.16.1(p), the sponsor should determine the data management steps needed before analysis, which may differ for IDMC, interim, and final analyses, and should document that they were completed. Under 3.16.1(r), edit access to the data acquisition tools should be restricted before data are provided for final analysis and, where applicable, before unblinding. Neither clause lists checklist rows. Their content is left to the sponsor’s procedures, which is why no single industry checklist can be called the regulatory one.

Under lock-week pressure, administrative closeout tasks tend to get mixed in with data-integrity gates. Endpoint owners should rank each row by whether an unresolved item could change an analysis result. A missing monitoring letter does not change an estimate. A missing core-lab transfer, an unreconciled death, or an unapproved coding list can. E6(R3) points the same way when it asks sponsors to focus quality control, including data review, on data of higher criticality and relevant metadata (3.16.1(b)).

For each external endpoint stream (central laboratory, centrally read imaging, ECG, IRT, and eCOA), “complete” has three separate meanings, and the checklist should record each one:

1. Received. Every transfer the data flow specifies has arrived. EMA’s guideline (section 4.7) expects the sponsor to describe which data are transferred, in what format, who has access, when transfers happen, and what is done to the data, such as validation, reconciliation, verification, and review. That description is the yardstick for “all expected data.” The eCF/SCDM audit-trail position paper treats data changed during migration from source to sponsor (corrupt, dropped, or partially transferred data) as a reviewable risk, so the receipt row should point to the final transfer log, not an email.

2. Reconciled. The external records match the clinical database on the keys the DMP defines. GCDMP’s final-lock standard names electronic laboratory data, IVRS, ePRO, and ECG as examples of external data that must be received, complete, and reconciled. Where an IRT holds clinical data such as stratification factors, EMA’s annex on IRT (A5.2.3) expects those data to be source-verified and/or reconciled with the same data in the data acquisition tool. Conflicts that arise during collection are covered in our eCOA and EDC reconciliation guide. At lock, the question is narrower: has the final reconciliation output been reviewed, and has every remaining difference been dispositioned?

3. Available to the investigator where appropriate. E6(R3) 3.16.1(k) expects investigators to have timely access during the trial to relevant external data, such as central laboratory and centrally read imaging data, so they can make decisions about participants. The exception is data that would unblind the investigator, which the protocol should address. A large external transfer that arrives only in lock week is a cue to check whether that access existed earlier. It is not a new review step the guideline adds at lock.

The second endpoint-critical block is reconciliation between the clinical database and any separate safety database. SCDM describes it as a comparison of key safety variables between the two databases. It is iterative across the study, with timing set by data receipt, safety-update schedules, and interim and final reports. Before lock, SCDM’s procedure expects confirmation that all expected SAE information has arrived and that every event was reconciled, followed by written notification that reconciliation is complete. Inconsistencies that cannot be resolved go into a data handling report or its equivalent. SCDM suggests reconciling items such as:

• Protocol, investigator, participant identification, and randomization number.

• Event number, diagnosis, verbatim term, and coded or preferred term.

• Onset date, resolution date, date of death, and outcome.

• Severity, causality assessment, and action taken with study drug.

Two further points from the same guidance shape the lock decision. First, some discrepancies are acceptable. Wording may differ slightly, or start dates may differ because an event began as non-serious, so the goal is explained concordance, not a report with zero differences. Second, sponsors should set a cutoff after which no SAEs are added to the clinical database, even if the safety database keeps receiving follow-up. Without a documented cutoff, reconciliation never formally ends.

The table below is a starting structure for the endpoint-critical rows, not a regulator-mandated list. GCDMP notes that some checklist elements are specific to the organization, study, and data system. Each row names the item, the artifact that evidences it, the usual signer, and the source of the expectation:

GCDMP’s final-lock standard for queries is simple: all of them are resolved. In lock week it is tempting to treat that as a closure-count target. Two E6(R3) clauses limit how hard a sponsor can push. The sponsor should not change data entered by the investigator or participants unless the change is justified, agreed in advance by the investigator, and documented (3.16.1(i)). Corrections, including to participant-entered data, should be justified and supported by source records from around the time of original entry (3.16.1(j)). A query closed by a back-end edit, or answered by a site under pressure to produce a value, can harm the endpoint more than a documented missing value. Our guide to wording endpoint queries without leading the respondent covers how to phrase the query itself.

Sometimes a site cannot answer a diary query, for example because the participant made no entry and no other record exists. The defensible resolution is to close the query with a response that says so and leave the value missing. Before accepting that answer for an eCOA gap, confirm that no entries are still stored on a device awaiting upload; our article on offline eCOA entries explains which time and record count. Late values follow the same discipline as late visits: record them as they happened rather than backdating them (see recording a late visit without backdating).

The statistical consequence of a missing value is then handled by the rules the statistical analysis plan pre-specifies for that endpoint, not decided at lock. The checklist exists to block the silent path: an open query, then a lock, then a value that becomes missing with no recorded decision. File the disposition list with the lock documentation so a reviewer can trace each missing endpoint value back to a query response.

Medical coding needs the same closure. GCDMP expects the coding list to be reviewed for completeness and consistency and approved by a medical monitor or safety surveillance team, where applicable, before final lock. The FDA/MHRA paper lists medical coding among the topics a data management plan should address. SCDM’s SAE guidance adds a sequencing point: coding of adverse-event verbatim terms should be complete when the final SAE reconciliation starts, because coded terms are among the reconciled items. It also helps if the approval record identifies the coding-list version it covers, so that any later recode shows up as a change.

Audit trails let an inspector reconstruct who changed what, when, and why. FDA’s October 2024 Q&A guidance on electronic systems, records, and signatures in clinical investigations (Q12) says they allow “reconstruction of significant details about clinical investigation conduct and source data collection.” On review, the guidance is deliberately risk-based. Periodic review “may be helpful,” and “the decision to review audit trails should be based on a risk assessment of the clinical investigation, considering the systems, procedures, and controls in place.” Availability, by contrast, is not optional: all audit trail documentation on the creation, modification, and deletion of electronic records must be available for FDA inspection. The guidance never uses the term “database lock,” so any lock-specific review duty is an inference from these record-integrity expectations, not a named FDA requirement.

EMA’s guideline is more prescriptive about process. Section 6.2.2 expects procedures for risk-based, trial-specific audit-trail review, with review focused on critical data and carried out proactively and on an ongoing basis unless justified. Neither regulator asks for a line-by-line read of every audit-trail entry at lock. A proportionate pre-lock review targets the changes most able to move an endpoint or an analysis population.

The eCF/SCDM industry position paper on audit-trail review provides a usable taxonomy. Its use cases translate directly into lock-week checks:

• Changes to critical data (use case 2.2): inclusion/exclusion criteria, primary efficacy data, key secondary data, safety data, and other critical data as defined in risk-based monitoring.

• Changes after key timepoints (2.3): the paper’s examples are changes after database locks, which before a final lock means any earlier interim or soft lock, and changes after a participant’s study disposition status is marked complete.

• Excessive changes (2.4): unusually high volumes of change within the database during the study, for instance concentrated at one site compared with others.

• Late changes (2.5): changes made long after initial data entry or after the source was obtained.

• Missing PI signatures (3.2) and transfer problems (4.2): these overlap with the signature and external-data rows above and can be checked from the same logs.

FDA’s Q12 adds one blinding-specific expectation for the lock checklist. Regulated entities should retain audit-trail information on individual access to systems or files that contain unblinding information, so the integrity of the blind can be verified throughout the investigation. Record what was reviewed, which signals were found, and how each was explained or corrected, and keep that record with the lock documentation.

Back to MET-402. Ten days before the planned final lock, the lead data manager, project biostatistician, clinical operations lead, and medical monitor meet to decide each open item. The proposals and counts below are illustrative; what matters is the decision logic and the record each decision leaves.

1. Imaging transfer, two weeks late. Proposal: lock on schedule and load imaging later. Decision: lock blocked. GCDMP’s final-lock standard requires expected external data to be received, complete, and reconciled, and the imaging score is a co-primary endpoint. Locking without it leaves two bad options: unlock later to load it, or declare fit for analysis a database that lacks a primary endpoint. The team re-baselines the lock date to the confirmed transfer date plus time to reconcile and disposition differences, and records the reason on the checklist.

2. Death in the safety database, absent from EDC. The safety specialist suggests the death may fall outside the protocol’s adverse-event collection period. Decision: lock blocked until the discrepancy is researched and documented. Under SCDM’s SAE guidance, if the visit has been monitored the site is queried for the missing event page. An SAE is added to the clinical database only after the data are monitored against source and the site update is signed and dated, and death certificates, discharge summaries, or autopsy reports can corroborate it. If the collection period or the documented SAE cutoff genuinely excludes the event, the result is an explained difference in the reconciliation record, not a silent omission. The biostatistician also checks disposition: a death that prevents later imaging or biomarker assessments should be handled the way the estimand and SAP already specify, not decided now.

3. 38 open diary queries. Proposal: postpone the lock until every diary value is recovered. Decision: no date change for this item alone, but every query closes before lock. The data manager and biostatistician triage the queries. Those on items that feed endpoints or analyses named in the SAP go to sites first. Where a site confirms that no entry was made and no other record exists, the query closes with that response and the value stays missing. Nothing is imputed into the database; missing values are handled at analysis by the SAP’s pre-specified methods. The disposition list goes into the lock file.

4. Four months of unsigned casebooks at the top-enrolling site. Proposal: have the PI sign everything outstanding in one session. Decision: lock blocked until signatures are current, and the gap is documented as a finding. GCDMP expects PI electronic signatures before final lock. The FDA/MHRA paper says final sign-off should occur before data lock and that the investigator should know about all corrections before final sign-off. One session can produce the signatures but cannot make them timely; EMA section 6.3 says a single signature immediately before lock will rarely be sufficient and that batch signing undermines timely review. The monitor arranges a working review with the PI covering adverse events, endpoint data, and corrections since the last signature. The team documents the signing gap and its corrective action rather than presenting late signatures as routine.

5. Coding list not approved. Proposal: lock now and let the medical monitor approve coding during programming. Decision: lock blocked. GCDMP places coding-list approval among the tasks completed before final lock. A recode after lock either requires an unlock or produces safety tables that no longer match the locked database. The medical monitor completes the review, and the approval record names the coding-list version it covers.

The same decisions in summary form:

Once every row is evidenced, the lock itself is a short sequence of documented acts. Under GCDMP’s minimum requirements, every lock should follow a documented approval process with approval or acknowledgement by relevant study personnel. Its examples are the data manager, biostatisticians, a monitoring representative, and a clinical/scientific representative. Edit access is removed only after the necessary approvals, the removal date is documented, and team members are notified when the lock occurs. A typical division of what each approver confirms:

• Data management: expected data received and reconciled, all queries closed, final edit-check and listing reviews done, and the data quality audit and its error rate documented.

• Biostatistics: data transformations and derivations the analysis depends on are traceable (E6(R3) 3.16.2(c)), criteria for including participants in analysis sets are pre-defined (3.16.2(d)), and IRT stratification reconciliation has been reviewed.

• Monitoring: required investigator signatures are current, and site issues affecting data are resolved or documented.

• Clinical/scientific, often the medical monitor: coding list approved and SAE reconciliation complete with its written notification.

After approval, write access is removed, and two records then matter. The first is proof of the lock date. The FDA/MHRA paper says audit trails or system logs generated by the database should be available to confirm the date of the actual lock, that the data extraction method should be validated, and that the resulting datasets should be stored securely. The second is the investigator’s copy. EMA’s guideline (section 6.6) notes that access may be amended to read-only as part of the lock process. Before the investigator’s read-only access is revoked, a complete copy including the audit trail should be made available to the investigator. Where a service provider hosts the data, the copy should not be routed through the sponsor, and the investigator needs enough time to review it before access ends.

In a blinded study, the order of the final steps is where bias control happens. The FDA/MHRA paper states that unblinding should come after lock, SAP finalization, and review of subject populations for analysis. GCDMP adds that documented authorization should precede both final database release and unblinding. E6(R3) expects the sponsor’s unblinding procedures to record who was unblinded, when, and for what purpose, who remains blinded, and the safeguards in place (3.16.1(g)). Our SAP article covers what the plan must fix before unblinding; the diagram below shows only the gating.

flowchart TD
    A["Endpoint-critical rows evidenced: external data, SAE reconciliation, queries, coding, signatures"] --> B["Documented approvals: data management, biostatistics, monitoring, clinical"]
    B --> C["Edit access removed; removal date documented; system log confirms lock date"]
    C --> D["Investigator read-only access; complete copy with audit trail provided before access ends"]
    C --> G["Documented authorization for database release and unblinding"]
    S["SAP finalized"] --> G
    P["Review of subject populations for analysis"] --> G
    G --> H["Unblinding and final analysis"]

A final lock should ideally be final. GCDMP discourages unlocking but accepts that it happens often enough for organizations to need predefined policies. Its guidance comes down to three rules:

• Unlock only for errors that matter. The database should be unlocked only for data errors relating to safety or efficacy parameters that may affect the statistical analysis and the study’s conclusions. Not every post-lock error has to be corrected in the database; GCDMP notes that most large clinical databases are not completely free of errors.

• Log what you do not fix. Other errors can be documented in the statistical or clinical report, or in a database error log listing each error, the action taken, the reason the database was not unlocked, and who decided not to unlock it.

• Control the window. Get documented authorization before unlocking and restore access only to authorized people. Record the notification, a clear definition of each change, the implementation date, and checks that only the authorized changes were made. Any changes made during the window must be captured in the audit trail. Relock using the same or similar notification and approval process as the initial lock.

After unblinding, the bar rises. E6(R3) 3.16.2(e) says changes made to data after unblinding should be clearly documented and justified, occur only in exceptional circumstances, be authorized by the investigator and reflected in the audit trail, and be reported in the clinical trial report. The FDA/MHRA paper gives the reason any unlock needs strict control: for example, to prevent bias after unblinding of the data.

A lock is finished when someone who was not in the room can find the evidence for the decision. GCDMP expects lock documentation to include the reasons for any interim locks, the signed checklist, and documentation of the tasks that make up the lock, such as final data receipt and SAE reconciliation, each with a completion date and the signature or initials of the person responsible. ICH E6(R3) treats the checklist as an essential record (Appendix C.3.1(d)), and the FDA/MHRA paper expects evidence of each completed action to be available, not just the ticked checklist.

A practical lock file for MET-402 would hold:

• The signed lock checklist, with the SOP and DMP versions it was built from and each row’s owner, date, and signature or initials.

• Final external transfer logs and reconciliation outputs for central lab, imaging, ECG, IRT, and eCOA, with dispositioned differences.

• SAE reconciliation listings, the written completion notification, and any data handling report for unresolved differences.

• The approved coding list and its approval record.

• Query status at lock and the disposition list for queries closed without new data.

• Investigator signature status at lock, plus documentation of the signing gap and its corrective action.

• The targeted audit-trail review record.

• Lock approvals, the documented edit-access removal date, and the system log confirming the lock date.

• Evidence that investigators received complete copies of their data, including audit trails.

• Release and unblinding authorizations, plus any unlock requests, error-log entries, and relock approvals.

Where each artifact sits in the TMF depends on the sponsor’s index. Our guide to TMF Reference Model zones shows how to file endpoint decisions so they can be retrieved, and the ICH E6(R3) implementation checklist places the lock among the other data-governance controls the guideline expects.

For MET-402, the answer is that the lock does not happen on schedule. The date moves to the imaging transfer plus reconciliation time. The death and the coding list are resolved first, the PI’s signatures are brought current with the gap documented, and the diary queries close with recorded dispositions. Each step leaves a record an inspector can follow.