Reach database lock

Goal

Record that an exact clinical data scope is final for analysis under declared prerequisites, exceptions, and approvals.

Candidate lock scope

A CandidateLockScope identifies:

• Study, cohort, participant, or data scope;
• Protocol and data-collection definition versions;
• clinical-data snapshot;
• included external-data transfers;
• terminology and coding releases;
• applicable reconciliation definitions;
• proposed lock time.

Readiness inputs

DatabaseLockReadiness
├── data-entry completeness
├── open Data Queries
├── validation findings
├── external-data reconciliation
├── safety reconciliation
├── medical coding completion
├── protocol deviation assessment
├── investigator signatures
├── review and freeze decisions
└── explicit exceptions

Readiness is an assessment. It does not close queries, approve coding, reconcile Safety Cases, or sign Casebooks.

Lock behaviour

dataFinalization.lock({
  scope: candidateLockScope,
  readiness: verifiedReadiness,
  exceptions: approvedExceptions,
  approvals: requiredApprovals,
}): DatabaseLocked;

Rules to verify

• The locked scope and snapshot are exact and immutable.
• Every unresolved prerequisite has an authorized exception or blocks lock.
• Lock does not erase prior freeze/review decisions.
• Reopening supersedes the Lock Decision and records reason and authority.
• Downstream analysis objects identify the exact lock/snapshot they use.
• A reopened scope explicitly invalidates affected analysis outputs.

Product review questions

• Is database lock one Study-wide decision or may scopes lock independently?
• Which owner approves each type of exception?
• Does new safety information require clinical database reopen?
• What changes are permitted after lock without reopening?