Export data

Exports is where study data leaves the system: data exports, closeout and inspection packages, site copies and server-built documents (casebooks, audit logs, registers). Every export here is reproducible: the same parameters give a byte-equivalent result, and every file comes with a checksum and an audit-trail record.

Who and when

Data manager — the main owner of the screen: the “run exports” permission (export.run); the history is visible to holders of “see exports” (export.read). Monitor and the coordinator hold export.run for printing and registers — their files are on their own screens. Investigator receives a copy of their site’s data.

Extra permissions for specific exports: with the audit trail — audit.read; unblinded — data.unblinded.read on the chosen scope; the inspection packet — audit.read and access.read.

The task comes up whenever data is needed outside the system: for statistics and analysis, for handing over to the sponsor or another system, for an interim snapshot and at database close.

Before you start

• The study has a published design version (tabular datasets take all forms of the published version by default).
• Decide whether the export should be blinded (the default) or unblinded, and whether you need a snapshot as of a specific moment.
• For the final package — an active hard lock: it is built in the closeout wizard, see Lock the data.
• Open Exports (the “Control & closeout” group of the study navigation), the Data export tab.

Steps

0:000:00

Export console: what to export, scope and blinding — plus the journal of every run

1. In What to export choose an option (the default is CDISC ODM 1.3.2 — snapshot; all options are in the table below). For tabular datasets tick the File formats and Forms (by default All forms of the published version).

2. Choose the Blinding: a blinded export (the default) or unblinded — the second option is visible only to holders of the unblinded-data permission on the chosen scope.

3. If needed, expand Snapshot and scope (its header shows the current values, by default “current data · Entire study”): set the Scope — the whole study or a site — and the As-of instant. The moment is entered in your time zone, with the resulting UTC moment shown next to it; Freeze now fills in the current one.

4. Click Run export. The job is queued and built in the background — the console stays fully usable.

5. When the row in the journal becomes completed, click Download. Details expands the export contents, the file retention period and the full SHA-256 checksum (Copy — for verification).

Retry or cancel an export

• A failed job (failed) is restarted with Retry — a retry is idempotent (same parameters → same result).
• A job that is queued or running can be stopped with Cancel (export.run, like launching): a mistakenly launched export — especially an unblinded one — is stopped rather than completed. Cancellation is terminal: it cannot be retried, run a new export.

Assemble an inspection packet

On the Inspection packet tab click Assemble inspection packet (export.run, audit.read and access.read). It is built by the same background pipeline and downloaded from the journal; contents — see Inspection packet.

What happens

• An export is a background job with statuses queued → running → completed / failed / cancelled. The console tracks progress itself.
• Launch, cancellation (export.cancelled) and every download are written to the audit trail: who, when, and which exact artefact they received. Downloading an unblinded export is flagged in the audit trail separately.
• In the journal, blinded runs show “blinded masked” in the Blinding column; every run shows its parameters, record counts and retention period.
• Once the retention period expires, the file is no longer issued.

If it doesn’t work

• No Exports screen or “Run export” button — you lack export.run / export.read on the study. Exports are the data manager’s area; ask your administrator.
• No “with audit trail” option — you lack audit.read; an export with the audit trail requires the permission to read the audit.
• Unblinded profile rejected — the person launching it lacks data.unblinded.read on the chosen scope. The platform never quietly hands out a masked file disguised as unblinded.
• Download refused — an unblinded artefact requires data.unblinded.read from the downloader too; a package with the audit trail — audit.read; an inspection packet — access.read.
• The file is no longer issued (EXPORT_EXPIRED) — the artefact’s retention period has expired. Run the export again with the same parameters (and the same snapshot moment if you need the same result).
• Cancel does nothing (EXPORT_NOT_CANCELLABLE) — the job has already completed, failed or been cancelled.
• The final package won’t build (EXPORT_REQUIRES_HARD_LOCK) — there is no active hard lock on the scope.
• “Select at least one format and one form” — for tabular datasets tick formats and forms.

Next

Lock the dataThe closeout wizard: final package, site copies, archiving.

Documents and certified copiesServer-built PDF/A documents, SHA-256, document language, site copy.

Blinding and privacyHow blinded values are masked in every channel.

Run a protocol amendmentThe export profile is tied to the design version.

More details

What to export

Option	What it is
CDISC ODM 1.3.2 — snapshot (default)	The open standard for exchanging clinical study data: the study data as of the run; the XML file arrives in an archive.
CDISC ODM 1.3.2 — with audit trail (Transactional)	The same ODM in Transactional mode: the trail is added to the data — who changed what, when and why. Requires the permission to read the audit.
CDISC tabular datasets	One file per selected form: Dataset-JSON 1.1 (and NDJSON), Define-XML 2.1, CSV, XLSX and SAS XPT v5 transport. Formats and forms are selectable.
Core snapshot (JSON, the internal X7 format)	A full snapshot of the study data in a single JSON file — for analysis and archiving. The audit trail can be included too.

CDISC ODM carries meaningful OIDs, the subject code as the subject key, sites, users, signatures, units and statuses (the x7 namespace extension has its own XSD). The schemas are inside the archive, so the recipient validates odm.xml offline. These are data exchange standards, not SDTM/ADaM: mapping to the sponsor’s domains is a task for the study specification.

Tabular datasets are flat tables, “one row = one form item-group record”, with subject/visit/form keys and a column per field; R, SAS and Excel read them. Define-XML 2.1 describes every dataset in the archive and is always included.

As-of snapshot and reproducibility

A snapshot reconstructs the data as of the given moment from the audit trail, not “whatever was read in time”. So an export is consistent even during active entry, and the same snapshot always gives the same result — the foundation of a submission package and of an inspection. To compare repeated exports, keep the same moment, profile and scope.

Exports without a fixed moment may differ, among other things, because of new audit events of the export itself. Before the final set, check signatures and hard-lock readiness per your SOP; the signed-forms counter in the console refers to the available study snapshot, not to any chosen profile. Interim exports do not require the whole database to be signed.

Blinding

The export blinding is chosen explicitly — blinded (the default) or unblinded. There is no “mask by the launcher’s permissions” mode in the interface: the profile is always clear from the journal row. Blinded values in a blinded export are masked at the core level.

Unblinded export — dual control

An unblinded export requires both the unblinded-data permission and an explicit choice of the unblinded profile. If the launcher lacks the unblinding permission, the unblinded profile is rejected. The permission is required of both the launcher and the downloader. Masking happens at the core level and cannot be bypassed, not even by a module.

The final package

The final package is a self-contained ZIP so you can take the study data without contacting the vendor. It contains:

• every subject’s casebook — a certified PDF/A-3 copy with the electronic signature register, change history and queries;
• CDISC ODM 1.3.2 (Transactional) — the data with the audit trail and schemas for offline validation;
• CDISC tabular datasets with Define-XML;
• the audit trail — a CSV with every field of the hash-chain link, human-readable XLSX and PDF, and a chain check;
• queries — the register with message texts and threads;
• the signature register;
• aCRF and specification of every published design version;
• the history of permission grants and the user event log;
• a README and manifest.json with the SHA-256 of every file — the copy is complete and verifiable offline.

The final package is built in the closeout wizard (the Locks screen, the “Final package” step; the Data export tab links to it with Open Locks) under an active hard lock and requires export.run and audit.read. A completed package is a mandatory condition for archiving the study (see Lock the data).

Site data copies

The Site data copies panel of the same wizard builds a certified copy of one site’s data (EMA 2023 §6.6): casebooks, the site’s audit trail, queries, signatures and tabular datasets — only its own subjects and events. A copy is built at any time and without a lock: the investigator gets up-to-date data of their site without waiting for database close. The wizard shows each site’s latest copy — who built it and when, whether it was downloaded — and warns if there is no fresh copy after the hard lock. More in Documents and certified copies.

The inspection packet

The inspector works in read-only mode and runs no exports — the data manager prepares the materials, and the hand-over is recorded in the audit trail.

Download audit and package verification

Together with the manifest, the download audit forms a verifiable chain data → export → file → recipient — exactly what an inspection asks for.

How a recipient checks integrity

A single file is checked against the SHA-256 from the Exports journal (how — see Documents and certified copies). A closeout or inspection package is verified as a whole offline with python -m x7core.tools.verify_package <package.zip>: every file’s checksum against the manifest, the manifest schema and a recomputation of the audit hash chain — with a verdict in words.