Database lock

A database lock is a controlled freeze of study data before export and archiving. It is handled by the data manager (the lock.apply / lock.release permission in the study). The process goes in two steps — a soft lock for the final review, then a hard lock as the final state — and always relies on a readiness checklist.

Everything is gathered on the study page → Locks (the Lock Console). At the top, the page guides you with the closeout wizard — step by step from closing collection to the archive; below, in the Tools zone, are the targeted operations: the readiness report, applying and releasing locks.

0:000:00

Lock console: freezing clean data — scope, level and a mandatory reason

1. Study “Closed”readiness report
2. Soft lockfinal cleaning
3. Hard lockfinal package
4. Archive

The database-closeout path: from ending collection to the archive. Locks are neutral (slate) — a freeze, not an “error”.

The closeout wizard: five steps

The “Study closeout” card shows the whole path and marks where you are. Each step links to the relevant screen; the next open step is highlighted.

1. Close data collection — move the study to the “Closed” status on the lifecycle card of the Overview screen: entry of new subjects and visits stops, and the final cleaning begins.

2. Data cleaning — a summary of the “dirt” across the study: open queries, values awaiting SDV, invalidated (broken) signatures, empty required fields. Each number is a link to the screen where it gets resolved. This is the same readiness report described below.

3. Hard lock — a full lock of the entire study against a clean readiness report (or with a deliberate gate override with a reason) — see “Hard lock”.

4. Closeout export — build the final package; it also gates archival (see Export).

5. Archive — the terminal step: archiving the closed database (a hard lock on the whole scope and a completed final package are required) — see “Final step: study archiving”.

The wizard is a map, not a lock

The wizard adds no new requirements — it merely shows the same gates the server checks, in the right order. Every step is still performed with the ordinary tools below, and each one is audited.

Readiness checklist (pre-lock)

Before freezing data, the Locks page shows a “Data cleaning” (lock readiness) card — a live report for the selected scope. It counts unresolved items by category:

Item	What it means
Open queries	unclosed queries in this scope
Awaiting SDV	values requiring source verification but not yet verified
Invalidated signatures	signatures that dropped after a data change — the forms need re-signing
Empty required fields	required fields left blank
Uncoded terms	verbatims awaiting medical coding (module widget)

If every item is zero, the card reports: “Scope is clean — ready for hard lock”. If something remains — “The scope has unresolved items — clear them before the hard lock”.

Un-migrated subjects are also part of readiness

If an amendment went through for the study, make sure all subjects are moved to the current design version before you close the database. Migration is performed in the Amendments section and must be completed before the final lock.

The checklist is recomputed on the fly: close queries, finish SDV, re-sign forms — and the numbers go down. The readiness report requires the lock.read permission; without it, the Lock Console simply lists the categories without showing counts.

Soft and hard lock

A lock comes in two levels, and the difference between them is fundamental.

• Soft lock — a reversible freeze for the final review;
• Hard lock — the final state before export;
• Released — the lock is removed (the lock.release permission + a reason).

Both levels are neutral (slate): a lock breaks nothing and raises no alarm — it merely holds changes back.

Soft lock

• Data entry in the scope is forbidden for everyone.
• SDV verification stays allowed — the lock freezes values, and verification does not change them.
• It is released without escalation, by an ordinary lock.release.

A soft lock is a freeze for the duration of the final review. Found something to fix — release the soft lock, correct it, apply it again.

Hard lock

• Data entry is forbidden, including SDV verification.
• It can only be removed by a targeted unlock with a mandatory reason.
• It is the final state before export and archiving.

A hard lock is a final, audited step

A hard lock freezes the data completely and is recommended only after the PI has signed all casebooks. Applying a hard lock requires a confirmation listing the consequences. The server will not let a hard lock be applied while the scope is not clean per the readiness checklist and is not covered by a soft lock — or it will require a deliberate gate override with a reason that is recorded in the audit as justification.

How to lock data

1. In the Lock Console, click “Apply lock”.

2. Choose the scope: the whole study, a specific site, or an arbitrary path by hand. Locks are hierarchical — a lock on the study covers all sites and subjects under it.

3. Choose the level — soft or hard. For a hard lock, the pre-lock readiness for the selected scope is shown right in the dialog.

4. Specify a reason and confirm. For a hard lock there is a separate confirmation listing the consequences.

Unlock

Removing a lock always requires a mandatory reason — this is a platform-level rule, not just an interface one: without a reason an unlock cannot be performed even via the API.

Removing a hard lock reopens the closed database

A targeted unlock of a hard lock invalidates the closeout snapshot: a new snapshot will be required before re-closing. Use it only for late findings — remove the lock from a single form, correct the value (with a reason for change), close queries, re-sign if needed, and lock again. This entire loop is visible in the audit as a coherent story.

The lock hierarchy works like an access scope: if a lock is applied to the study, removing the lock on an individual site will not “open” entry — the Lock Console shows the effective aggregate coverage. Re-applying the same lock is a safe operation with no effect.

Final step: study archiving

When the database is finally closed, the study can be archived — a terminal transition under audit. The button appears in the Lock Console when the whole study scope is covered by a valid hard lock. The server checks three archiving gates:

• study status — closed;
• a valid hard lock on the entire study scope;
• a linked, completed final package (closeout export).

The archiving dialog shows these gates with their current state, so a rejection is not a surprise. Building the final package is covered in the Export section.

Next

Electronic signatureInvalidated signatures block hard-lock readiness.

QueriesOpen queries are the first item on the readiness checklist.

ExportThe final package is a mandatory archiving gate.

Medical codingUncoded terms appear on the readiness checklist.