Data export and closeout packages

The Export Console (study page → Export Console) is where the data manager exports study data. Any export here is reproducible: identical parameters yield a byte-for-byte equivalent result, and each file comes with a checksum and an audit. Running an export requires the export.run permission, downloading requires export.download, and the export history is visible to those with export.read.

The Console splits the work into two tabs: Data export and Final package.

0:000:00

Export console: a reproducible dataset snapshot and the final package

Data export

An ordinary export assembles a reproducible snapshot of clinical data. It contains:

• a manifest with the sha256 of the canonical artifact — with it the recipient verifies offline that the file is neither corrupted nor tampered with;
• record counts (subjects, forms, fields, and optionally audit events);
• an “Include audit trail” option — add the change history to the export.

The core exports clinical data as canonical JSON and flat CSV (one dataset per form). The data model is aligned to the industry CDISC standard; exporting to specialized formats (for example, ODM-XML) is handled by a separate exporter module, if one is enabled.

1. On the Data export tab, enable “Include audit trail” if needed.

2. Click “Run export”. The job goes into the queue and is assembled in the background — the Console stays fully usable.

3. When the row moves to the completed status, a “Download” button appears. Next to it is a short sha256 you can copy for verification.

An export is a background job with statuses queued → running → completed / failed. The Console tracks execution itself; a failed job can be re-run with the “Retry” button — the retry is idempotent (same parameters → same result).

Cancelling an export

An export in the queued or running status can be cancelled with the button in the job row (the export.run permission, same as for starting): a run started by mistake — especially an unblinded package — is stopped rather than carried through. Cancellation is terminal (it cannot be retried — start a new export) and lands in the audit trail (export.cancelled).

Blinding profiles

Data blinding is enforced automatically. Blinded values are masked according to the permissions of whoever runs the export: if the runner has no permission for unblinded data, the snapshot comes out masked (in the list, such runs are marked blinded masked).

An unblinded export is dual-controlled

To get an unblinded export you need both the permission for unblinded data and an explicit choice of the unblinded profile. If the runner has no unblinding permission, the unblinded profile is rejected — the platform does not quietly hand over a masked file disguised as unblinded. Masking is performed at the core level and cannot be bypassed even by a module.

Final package

The final package is a self-contained ZIP for taking the study data without contacting the vendor. It contains:

• a full export of the data and the audit trail (canonical JSON and flat CSV);
• a print-ready HTML casebook of each subject with a register of electronic signatures;
• the query and signature registers as separate CSV files;
• a manifest.json with the sha256 of each file — the copy is complete and verifiable offline.

The snapshot of access and design versions (“who could see what, and which protocol version the data was collected under”) is part of the inspection package — see below.

The final package requires both the export.run and audit.read permissions (the package contains audit). Its parameters are minimal:

Parameter	Value
Blinding	blinded — masked (default), or unblinded — requires permission for unblinded data
As-of date	optional — reconstruct the state of the data on a specific date
Scope narrowing	optional — restrict the export to a site or part of the study

As-of date and reproducibility

An as-of date reconstructs the state of the data at the specified moment from the audit trail, not “whatever happened to be read”. So the export is consistent even during active entry, and the same as-of always yields the same result — this underpins the submission package and inspection.

A finished final package is a mandatory archiving gate for the study (see Database lock).

Inspection package

Besides the dataset and the final package, the run list may contain an inspection type — a package prepared for handing materials to a regulator’s inspector. It is assembled by the same background pipeline as the rest and downloaded with a single button just the same. The inspector works read-only and does not run exports — the data manager prepares the materials for them, and the fact of issuance is recorded in the audit.

Download audit

Every download is audited separately: who, when, and exactly which artifact was received. Together with the manifest, this gives a verifiable chain of data → export → file → recipient — exactly what an inspection asks for.

How the recipient checks integrity

Compare the sha256 from the manifest with the checksum of the downloaded file. A match proves that the file matches what is recorded in the audit. The Console lets you copy a run’s sha256 in one click.

Next

Blinding & privacyHow blinded values are masked in exports.

Database lockThe final package is a mandatory study-archiving gate.

Electronic signatureThe signature register is included in the final package's HTML casebooks.

AmendmentsThe export profile is tied to the design version.