Reaching zero open queries feels like the finish line for database lock, but genuine lock readiness involves several other checks that teams sometimes discover late in the process after a lock date has already been communicated, and after finding a gap creates real schedule pressure. Here are six things worth checking well before that point.
Lab data, ePRO data, and other external sources need to be reconciled against the EDC before lock, and this reconciliation sometimes reveals discrepancies that weren't visible from the EDC's query status alone. Checking external reconciliation status early avoids discovering a gap only when it's time to actually lock.
Medical coding can lag behind data entry, and a study can show zero open queries while still having coding work outstanding. Confirming coding completion status specifically, separate from general query status, catches this before it becomes a lock-day surprise.
An unresolved or undocumented protocol deviation discovered during final review can delay lock while it's investigated and properly recorded. Checking deviation documentation status specifically, ahead of the final review, surfaces this earlier.
A missing visit or missing form that was simply never entered doesn't generate a query the same way an inconsistency does — it can be genuinely invisible in a query-focused readiness check. Confirming expected-versus-actual data completeness, not just query status, catches gaps that query counts alone miss.
Edit checks and validation logic sometimes need final review against the complete, near-final dataset to confirm they're behaving as intended at full scale — an issue that might not surface until data volume and patterns are close to final.
A lock date can be missed not because of a data issue at all, but because a required sign-off from a specific stakeholder — medical monitor, biostatistician hasn't actually been obtained, even though it was requested. Confirming actual sign-off status, not just that a request was sent, avoids this administrative delay.
| Readiness Area | Query Count Alone Misses | A Genuine Check Confirms |
|---|---|---|
| External data reconciliation | Discrepancies invisible from EDC alone | Explicit reconciliation status |
| Medical coding | Can lag behind query resolution | Coding completion confirmed separately |
| Protocol deviations | Documentation gaps invisible in query view | Deviations documented and closed |
| Data completeness | Missing entries don't always generate queries | Expected-vs-actual entry confirmed |
| Edit check behavior | Assumed correct from earlier testing | Reviewed against near-final dataset |
| Stakeholder sign-off | Requested doesn't mean obtained | Actual sign-off status confirmed |
A communicated lock date that slips because of a readiness gap discovered late creates real credibility cost with sponsors and stakeholders who were told a specific date. A more thorough readiness check, run earlier and covering more than query count alone, protects that timeline commitment.
Cloudbyz EDC is designed to track coding completion, deviation documentation, and data completeness as distinct, visible readiness signals alongside query status, rather than requiring a separate manual check for each. Because EDC shares its platform with CTMS, protocol deviation status can be cross-checked directly rather than reconciled manually from a separate system.
Zero open queries is a milestone, not the finish line. Genuine database lock readiness means checking coding, deviations, data completeness, and sign-off status specifically the things a query count alone doesn't reveal, and the things that create real schedule pressure when discovered too late.
See how Cloudbyz EDC supports comprehensive database lock readiness — book a demo