What this is, and who it is for
The document register holds a study's own documents (the protocol, its amendments, plans, the consent form, regulatory correspondence) and the documents of a site, with their versions, so the exact document in force on a given date can be produced. This page is the reference; the steps are on Manage documents.
Where to find it
Study → Documents (the study level, outside any workspace) for the study's documents, and Study → Sites → a site → Documents for the documents of one site. Reading needs document.read; uploading and editing document.write; approving and archiving document.manage.
Held by: Organization Admin, Project Manager, Data Manager, Regulatory Manager (document.write).
Held by: Organization Admin, Project Manager, Regulatory Manager (document.manage).
A document can be registered while the study is still in Setup: the protocol is uploaded there, before any Live data exists. Registering and editing a document is a metadata write, the kind the study's own details and documents belong to, which is not a Live-data write and so is not held back by the lack of Live data.
What you can do
Register a document (choose the file, its type, a title, a version label and, for a site document, the site), add a new version of it, change its details, approve it, archive it, preview it where the browser can show it, and download any version.
Every option
Document types
| Type | Typical use |
|---|---|
protocol | The study protocol |
protocol_amendment | An amendment to it |
investigator_brochure | |
icf | The informed consent form |
crf_specification | The eCRF specification |
data_management_plan | |
monitoring_plan | |
statistical_analysis_plan | |
sop | A standard operating procedure |
training_material | |
regulatory_document | Submissions and correspondence |
site_document | Site-specific documents |
other | Anything else |
What a register entry holds
Type, title, optional description, version label, status, and for the current version the file name, size, content type and a SHA-256 checksum. A document belongs to the study and may also belong to one site. A document tied to a site also carries the workspace (UAT or Live) its site is in; a study-level document belongs to no workspace.
Statuses
| Status | Meaning |
|---|---|
| draft | Uploaded, not yet controlled |
| approved | The version in force |
| archived | Superseded or withdrawn, kept |
Nothing is deleted.
Versions
Uploading a replacement adds a version; it never overwrites. The register shows the current version, and every earlier version stays retrievable.
Files
| Rule | Value |
|---|---|
| Largest file | 100 MB by default (DOCUMENT_MAX_UPLOAD_BYTES) |
| Accepted types | PDF; PNG, JPEG, GIF, WebP and TIFF images; Word, Excel and PowerPoint (old and new formats); plain text and CSV; ZIP |
| Checked by content, not only by name | The first bytes of the stored file must match what its extension and declared type promise: a PDF must carry a PDF header, an image its signature, an Office file the compound-file or ZIP signature, a text file no binary bytes. A program (a Windows, Linux or macOS executable) is refused under any name with 422 and the reason content_mismatch; no document or version is created, nothing is written to the audit trail and the stored object is removed |
| Previewed inline | PDF and common images; everything else downloads |
| Where files go | Directly between the browser and the object store with a short-lived, single-purpose link; they do not pass through the application. The server sees the bytes when the document is registered |
A browser may declare a CSV file as an Excel type; the extension decides when it is known. A .doc and a .docx are accepted in either container.
What the system records
Every upload, new version, change of details, approval, archive, download and preview is written to the audit trail in the same transaction (document.uploaded, document.version_added, document.metadata_updated, document.approved, document.archived, document.downloaded, document.previewed), with who and when. The content check is a refusal, not an event: a refused file leaves no trace in the register.
What you cannot do, and why
- Upload a program or a file that is not what its name says. See the content check above.
- Upload a file over the limit or of a type not on the list.
- Delete or overwrite a document. Versions are added; documents are archived.
- Sign a document electronically. Electronic signatures apply to records of participants, delegations and version sign-offs, not to documents in the register.
- Find out who read a document. Downloads and previews are audited, but there is no read receipt and no distribution list.
- Use it as an eTMF. There is no TMF reference model structure, no expected-document checklist and no completeness scoring.
- Upload the same file twice without noticing. Nothing warns about a duplicate upload.
Compliance Q&A
Yes. A new file is a new version of the same document; every version keeps its file, its checksum and who added it, and the audit trail records each action. The version in force on a date can be produced from the history.
Evidence: server/src/modules/study/documents (use-cases.tsa version is added, never overwritten)audit events document.*
The first bytes of every file are compared with its extension and declared type, and a program is refused under any name.
Limits: this is a signature check, not a malware scan. A file with the right header and harmful content inside is not detected here; scanning uploads for malware is a control your organization or hosting adds.
Evidence: server/src/modules/study/documents/domain/file-signature.tsserver/tests (document content check, 40 unit cases)
No. It keeps documents and their versions, but it has no TMF reference model, no completeness check against an expected-document list and no acknowledgement tracking. Keep your TMF in a TMF system and use this register for the documents the study needs in the system.