Lock the data

A database lock is a controlled freeze of study data before export and archiving. It goes in two steps — Soft lock, then Hard lock as the final state — and always relies on the data cleaning report.

Who and when

Data manager — with the permissions “apply soft and hard locks” (lock.apply.soft / lock.apply.hard), “release locks” (lock.release.soft / lock.release.hard) and “see locks” (lock.read) on the study. The final package requires the permission to run exports (export.run) and to read the audit trail.

The task comes up at the end of the study (database close), and selectively when a site, subject or form must be frozen for a review.

Before you start

• Enrollment and data collection are over: the study is in Closed status (set by whoever manages the study status).
• If the study went through an amendment, all subjects have been moved to the current design version — see Run a protocol amendment.
• The investigator has signed the casebooks — a hard lock is recommended only after that.
• Open the Locks screen (the “Control & closeout” group of the study navigation). At the top is the Study closeout wizard; below it, in the Tools area, are Data cleaning and the lock journal.

Steps

0:000:00

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

The Study closeout wizard shows the whole path and marks where you are; what the current step needs appears right below it.

1. Close data collection — move the study to Closed with the status card right under the wizard (the same one as on the Overview): close subject enrollment, then the study. Entry of new data stops. If you cannot change the study status, the step explains who does it.

2. Data cleaning — apply a soft lock over the whole study (Apply soft lock…): entry is frozen while you clean. Then open the report (To the cleaning report) and resolve every item — each row leads to where it is fixed. The report items are listed under More details.

3. Hard lock — click Apply hard lock…, give a reason and confirm in “Apply a hard database lock?” with Apply hard lock. The server requires a clean report and a soft lock over the whole study; otherwise tick Lock without waiting for cleaning and justify it with the reason.

4. Final package — click Build final package under the wizard; without it the study cannot be archived. The wizard waits for the package itself; download it on the Exports screen.

5. Site copies — give every site a fresh certified copy of its data (EMA 2023 §6.6): in the Site data copies panel click Produce a copy for the site.

6. Archive — click Archive study. The dialog shows the archiving conditions with their current state; confirm.

Lock part of the study

1. On the Locks screen click Apply lock….

2. In What to lock choose Entire study, Site … or Enter a technical path…. For a site you can narrow the scope: Subject (or Whole site), then Visit (or Whole subject) and Form. A whole visit cannot be locked — choose a form of the visit or lock the whole subject.

3. Choose the Lock level — soft or hard. For a hard lock the dialog shows lock readiness for the chosen scope.

4. Give a reason and click Apply. A hard lock asks for a separate confirmation listing the consequences.

Release a lock

1. In the lock journal (filter Active) click Release in the lock’s row.

2. Give a reason — without it a release cannot be performed, not even via the API.

3. Confirm. For a hard lock the dialog warns that releasing reopens the closed database.

What happens

• Applying and releasing a lock are written to the audit trail with the reason; when the hard-lock gate is overridden, the reason is kept as the justification for locking with open items.
• Under Soft lock entry and edits in the scope are forbidden for everyone; SDV continues.
• Under Hard lock all changes are forbidden, SDV verification included.
• A released lock stays in the journal as Released (filter Released). Releasing a hard lock reopens the database: the closure snapshot loses its force, and a new one is needed before closing again.
• Archiving is a terminal, audited transition: the study becomes Archived, and the wizard reports that all closeout steps are done.

If it doesn’t work

• Hard lock rejected: “Data is not ready for a hard lock” (LOCK_NOT_READY) — the cleaning report has open items or there is no soft lock over the whole study. Resolve the items and apply a soft lock — or deliberately override the gate with a reason.
• Override without a reason (OVERRIDE_REASON_REQUIRED) — with Lock without waiting for cleaning ticked, the reason is mandatory.
• Releasing a site lock did not reopen entry — a higher-level (study) lock is in force. The screen shows the effective combined coverage; release the higher lock.
• No “Release” button, hint “You need the permission to release locks here” — you lack lock.release.soft / lock.release.hard on that scope.
• Only the category list instead of report counts — you lack lock.read; the cleaning report is visible to those who can read the study’s locks.
• “Build final package” unavailable — the package is built after the hard lock (step 3) and requires the export permission and audit-trail read access.
• Archiving refuses — one condition is not met: the study is closed, an active hard lock over the whole study, a linked completed final package.

Next

Export dataThe final package is a mandatory archiving condition.

Sign dataInvalidated signatures block hard-lock readiness.

Manage queriesOpen queries are the first item of the cleaning report.

Documents and certified copiesThe site data copy: what it contains and when to issue it.

More details

The database closing path

1. Closedcleaning report
2. Soft lockfinal cleaning
3. Hard lockfinal package and site copies
4. Archived

The database closing path: from closing collection to the archive. A lock is a freeze, not an error.

The wizard adds no new requirements — it only shows the same gates the server checks, in the right order. Every step is still performed with the regular tools in the Tools area, and each is written to the audit trail. A step completed in advance is marked “done ahead”.

Data cleaning report

The Data cleaning card (lock readiness) is a live report for the selected scope. It counts open items by category; the data manager sees the same items under “Needs your action” on the study overview.

Item	Meaning
Open queries	unresolved queries in this scope
Awaiting source verification	values requiring SDV that are not yet verified
Signatures broken by edits	signatures invalidated by data changes — the forms must be re-signed
Unfilled required fields	required fields left empty
Awaiting coding	verbatims awaiting medical coding
No soft lock over the whole study	the hard lock is not preceded by a covering soft lock
Forms with data and no signature	forms the investigator has never signed
Signatures not matching the data	signatures whose checksum no longer matches the covered data
Checks that failed to evaluate	data checks that could not be run

When every item is zero, the card says “Data is clean — ready for a hard lock.” Otherwise — “There are open items — resolve them before a hard lock.” The report recalculates live: close queries, finish SDV, re-sign forms — and the numbers drop. If an item is fixed on a screen your role cannot open, the report tells you who holds the needed permission.

Soft and hard lock

Level	Data entry	SDV	Release
Soft lock	forbidden	allowed	without escalation, with reason
Hard lock	forbidden	forbidden	only selectively, with reason

A soft lock is a reversible freeze for the final review: the lock freezes values, and verification does not change them. A typical cycle: you find something to fix — release the soft lock, fix it, apply it again.

A hard lock is the final state before export and archiving. The server will not apply it until the scope is clean by the report and covered by a soft lock — or it requires a deliberate gate override with a reason that goes to the audit trail as the justification.

Both locks are neutral statuses: a lock “breaks” nothing and complains about nothing — it only holds changes back.

Unlocking and late findings

Releasing a lock always requires a mandatory reason — a platform-level rule, not just an interface one.

Releasing a hard lock reopens the closed database

The closure snapshot loses its force: a new one is needed before closing again. Use a selective unlock only for late findings — release the lock on one form, fix the value (with a reason for change), close the queries, re-sign if needed and lock again. The whole loop is visible in the audit trail as a connected history.

The lock hierarchy works like the access-scope hierarchy: a study lock covers every site and subject under it, and releasing a lock on a single site does not “open” entry if the study is locked. The Locks screen shows the effective combined coverage. Re-applying the same lock is a safe no-op.

Site data copies

The Site data copies panel shows each site’s latest copy — who built it and when, whether it was downloaded — and produces a new one in one click. A copy needs no lock and is available at any point in the study’s life. After a hard lock, a missing fresh copy is a warning: a site must receive its data before its access is removed. More in Documents and certified copies.

Archiving

Archiving is a terminal, audited transition. The server checks three conditions:

• the study is closed;
• an active hard lock over the whole study;
• a linked completed final package.

The archive dialog shows these conditions with their current state so a refusal never comes as a surprise. Building the final package is covered in Export data.