Documents and certified copies
In X7 Insight every file that leaves the system is built by the server — not by the browser’s print dialog. A subject casebook, an audit log, a CRF blank, a query register — all of them are produced by the same mechanism: you click a button, the server assembles the document in the background and hands you the file. The result does not depend on the browser, window size or print settings — the document is identical for everyone who requests it with the same parameters.
Such a copy is called a certified copy: a copy whose fidelity and accuracy are demonstrated by the very process that creates it. The platform is designed for the requirements of ICH E6(R3) and the EMA GCP guide (2023) regarding certified copies of electronic records.
How a document is built
Section titled “How a document is built”-
Click the document button — for example, “Casebook (PDF)” on the “Subject documents” page. The button schedules the build and shows that the document is being prepared.
-
The server assembles the document in the background. The screen stays usable; large documents (casebooks, packages) are assembled through a queue.
-
The finished file is downloaded automatically — by the same button press. If the download fails, the document is not lost: it sits in the study’s Exports journal.
Every document is a row in the Exports journal: document type, parameters, author, time, status and the file’s SHA-256 checksum. Every download is additionally recorded in the audit trail: who received which file, and when. The result is a verifiable chain “data → document → checksum → recipient”.
What is inside a document
Section titled “What is inside a document”Documents are for people, not machine dumps:
- headers and footers — “Page X of Y”, the document title, the system and the moment of generation;
- the “Certified copy” mark — the file was assembled by the server from database records, and its checksum is recorded in the exports journal and the audit trail;
- the moment of generation — in UTC, and in the site’s time zone when it is known: the moment is unambiguous for a reader in any time zone;
- values in words — decoded code lists, units, statuses as words; machine identifiers are not shown in the body.
Files for printing and on-screen reading are PDF/A (ISO 19005, the long-term preservation format) with PDF/UA-1 accessibility tags: the document is readable by screen readers and looks the same years later. The subject casebook is PDF/A-3: the same file embeds a machine-readable JSON source, so the printed copy lives in one carrier together with the data it was assembled from.
Which documents exist
Section titled “Which documents exist”| Document | Where the button is |
|---|---|
| Subject casebook (PDF) | Subject card → “Subject documents” |
| Subject audit log (PDF) | Subject card → “Subject documents” |
| Audit trail (XLSX / PDF / CSV) | “Audit trail” screen — with the current filters |
| CRF blank (PDF) | “Design” → version document buttons |
| Annotated CRF — aCRF (PDF) | “Design” → version document buttons |
| Specification (PDF / Excel) | “Design” → version document buttons |
| Deployment report (ZIP) | “Design” → version document buttons |
| SDV report, query register (XLSX / PDF) | “SDV”, “Queries”, “Monitoring” screens — with the screen’s filters |
| Site data copy (ZIP) | “Locks” → “Site data copies” |
Details live on the pages of the respective screens (see the links below).
Document language
Section titled “Document language”The language is chosen when the document is requested — for example, on the “Subject documents” page. If no language is chosen, the document is assembled in the study’s primary language. It is a property of the document itself, not of whoever clicked the button: two users with different interface languages get the same file.
Who may build documents
Section titled “Who may build documents”A file leaving the system is an export. Therefore:
- clinical documents (casebook, audit log, registers, the site copy) are built by whoever holds the right to run exports in that area — usually the monitor, the data manager, and the investigator for their own site. A sponsor auditor with view-only access does not build documents: they read the data on screen, and the data manager prepares inspection materials;
- design documents (CRF blank, aCRF, specification) carry no clinical data and are available to anyone who can read the study design — no export right needed. The deployment report carries the version’s lifecycle log and requires the rights to read the audit trail and run exports.
How to verify a copy
Section titled “How to verify a copy”-
Open the study’s Exports journal — the document’s row carries its SHA-256 checksum (the full hash is copied in one click).
-
Compute the checksum of the downloaded file:
certutil -hashfile <file> SHA256on Windows orsha256sum <file>on Linux/macOS. -
A match means the file is exactly the one recorded in the journal and the audit. A mismatch means the file was damaged in transit: download it again from the journal.
The site data copy
Section titled “The site data copy”The EMA GCP guide (2023, §6.6) expects the investigator to be able to obtain a certified copy of their own site’s data at any time. In X7 Insight this is the “Site data copies” step of the closeout wizard (the “Locks” screen):
- the copy is built per site and contains only that site’s subjects and events — casebooks, the site’s audit trail, queries with threads, signatures and the CDISC tabular datasets;
- no lock is required: the copy can be built at any moment in the study’s life;
- the wizard shows each site’s latest copy — who built it and when, whether it was downloaded — and warns when no fresh copy exists after a hard lock: before access is revoked, the site must receive its data.
Verifying a package as a recipient
Section titled “Verifying a package as a recipient”Closeout and inspection packages can additionally be verified offline, without access to the system. The package includes a README with instructions; verification runs as:
python -m x7core.tools.verify_package <package.zip>The command compares every file’s SHA-256 against the package manifest (no extra or missing files), validates the manifest against its schema and recomputes the audit hash chain from the audit trail inside the package. The verdict is printed in words; exit code 0 means the package checks out, 1 means a divergence. Blinded values travel masked inside the package, so chain links carrying a mask are not recomputed — their count is reported separately.