Freeze, record lock, and database lock

Review status

Included in the proposed model: Freeze Decision, Scoped Lock, Lock Readiness Assessment, Database Lock Authorization, Database Lock, Reopen Authorization, Relock, Lock Exception, and Analysis Cut.

Settled proposal: the included Database Lock is the whole-study clinical-data decision for final analysis. It is not a calculated synonym for every form being locked. Subsets are handled through Scoped Locks or reproducible Data Cuts.

Open: exact prerequisites, exception authority, and unlock granularity. A product called “partial database lock” is deferred until a distinct clinical purpose and rules are approved.

Clinical meaning

Decision	Meaning
Freeze	Temporarily prevents data entry/correction while allowing declared cleaning or review work
Scoped lock	Prevents changes to a form, event, casebook, site, or declared data scope
Database lock	Sponsor confirms the stated study database is final for a defined analysis purpose
Reopen/unlock	Exceptional authorization to change previously locked data
Analysis cut	Reproducible dataset at a stated point while collection may continue

Signature, freeze, scoped lock, and database lock are independent. Their usual order is a study policy, not a universal truth.

Freeze Decision

Fields:

• study, site, subject, and clinical scope;
• exact design/data state;
• frozen by/at and authority;
• reason;
• operations still permitted;
• affected open queries and reviews;
• unfreeze authority; and
• later unfreeze reason/time.

A freeze commonly prevents data change while permitting query discussion, SDV, DMR, coding, and signature. The allowed operations must be declared, not assumed.

Scoped Lock

Fields:

• lock scope and included occurrences;
• requested/authorized/locked by and at;
• prerequisite assessment;
• exact data and design state;
• open exceptions;
• actions prohibited and still permitted;
• superseded prior freeze/signature references; and
• unlock/relock history.

Locking a parent scope does not ambiguously rewrite every child record. The lock carries an exact included-record inventory, and child editability is evaluated against all applicable locks.

Lock Readiness Assessment

Readiness is assessed against a named analysis/finalization purpose. Checks may include:

• all expected visits and CRFs accounted for;
• required queries closed or formally accepted;
• required SDV and DMR completed;
• changed-after-review records resolved;
• medical coding complete and current;
• external data received and reconciled;
• safety, laboratory, imaging, eCOA, and RTSM reconciliations complete where applicable;
• protocol-deviation candidates sent to the owning deviation-management process and required dispositions received;
• investigator signatures complete;
• amendment conflicts resolved;
• missing data and known discrepancies dispositioned;
• required extracts validated; and
• blinding protections confirmed.

Each check records result, evidence time, source, accountable reviewer, exception, and whether later change made the result stale.

For protocol deviations, the readiness check consumes the current disposition from the owning deviation-management process. EDC does not classify or close a deviation merely to pass lock readiness.

Database Lock

Field	Clinical meaning
Study and purpose	Whole-study final analysis
Data cutoff	Clinical and/or receipt cutoff applied
Whole-study scope	All in-scope countries, sites, subjects, external sources, and design versions for final analysis; exclusions require an approved readiness exception
Readiness assessment	Exact completed assessment and exceptions
Authorization	Required approvers, roles, decisions, and times
Lock time	Unambiguous effective time
Locked-data inventory	Reproducible data/design state
Delivery reference	Data cut/extract produced from the lock
Prior/subsequent lock	Recorded relationship across reopen and relock

The included Database Lock covers the whole study database for final analysis. A site, subject, or form may be locked earlier through a Scoped Lock. An interim or selected-population dataset is a Data Cut. Neither is called Database Lock in this model.

Database lock does not delete work history or make the study inaccessible. It restricts change and records a reproducible final state.

Reopen Authorization

Unlocking never removes the earlier lock. It creates a new authorization with:

• requested scope and exact data needing correction;
• reason and supporting evidence;
• requester and approvers;
• urgency and participant/result risk;
• impact on queries, reviews, coding, signatures, extracts, and analysis;
• permitted corrections;
• notification requirements;
• effective time; and
• required recleaning, re-signature, and relock steps.

After correction, the affected data must repeat applicable checks and evidence before relock. The new lock references the original lock and reopening authorization.

Status journeys

Scoped data control

Editable → Frozen → Unfrozen
Editable/Frozen → Locked → Reopened → Relocked

Database

Cleaning
→ Readiness under review
→ Authorized for lock
→ Locked
→ Reopened by exception
→ Recleaned / re-reviewed / re-signed
→ Relocked

Actions and refusals

Action	Refused when
Freeze scope	scope is already locked or actor lacks study authority
Unfreeze scope	no current freeze, insufficient authority, or lock still applies
Lock scope	required prerequisites fail without an approved exception
Authorize database lock	readiness evidence is stale/incomplete or scope is ambiguous
Lock database	authorization does not match current data/finalization state
Request reopen	requested data and reason are not identified
Approve reopen	impact assessment or accountable approval is missing
Correct reopened data	correction falls outside authorized scope
Relock	required recleaning/review/signature is incomplete

Business rules

1. Freeze and lock are recorded decisions, not overwritten booleans.
2. Every decision identifies exact scope, actor, authority, time, reason, and data/design state.
3. More restrictive applicable control wins for editability.
4. Open query discussion may continue under freeze only when policy permits it.
5. Locked data cannot change without an approved reopen authorization.
6. Reopen is limited to authorized scope and purpose.
7. Prior locks, signatures, reviews, and extracts remain in history after reopen.
8. Corrections identify and repeat all affected finalization work.
9. Database-lock authorization becomes stale if relevant data or readiness evidence changes before lock.
10. An analysis cut is reproducible and named but is not automatically database lock.
11. Every relock creates a new lock record and recorded history; it never edits the original lock time.
12. Whole-study final-analysis Database Lock, Scoped Lock, and Data Cut retain distinct meanings.

Evidence package

A database-lock evidence package includes readiness checks, exceptions, approvals, whole-study scope, data/design inventory, query/review/coding/signature summaries, reconciliation status, lock time, produced extract identifiers, and reopen/relock history.

Exceptions

• One locked subject needs an urgent safety correction.
• A central laboratory sends a corrected result after lock.
• A coding dictionary decision changes after final review.
• An amendment was not adopted by one locked casebook.
• A known discrepancy is accepted for analysis.
• A signature is missing for a withdrawn subject whose investigator left the site.
• An interim analysis cut must remain reproducible while collection continues.
• The database is reopened after unblinding; access and change require extra controls.
• A relock extract differs from the original by more than the authorized correction.