Trial Master File (eTMF)¶

For clinical trials, the Trial Master File is the collection of documents that proves the trial was conducted properly and the data are credible. Regulators expect it to be complete, contemporaneous, and readily available for years after the trial ends. The eTMF module manages that file: you create a trial, define its structure, receive TMF content transferred from a CRO, verify and QC every document against the industry reference model, measure completeness, and finally export or archive the locked file.

You'll use this module as a TMF manager building and receiving the file, a reviewer doing QC on received documents, and a Quality role holder attesting to transfers and authorising the final archive.

The TMF Reference Model¶

The whole module is organised around the CDISC/DIA TMF Reference Model — the industry-standard taxonomy of what a trial master file should contain. It's held as global, versioned reference data shared across all tenants:

• A model version is one release of the reference model, e.g. 3.3.1. A trial pins to a version when it's created and keeps resolving against it for its whole life.
• A zone is a top-level grouping (Trial Management, Regulatory, and so on — eleven in v3.3.1).
• A section is the second level within a zone.
• An artifact is a document type you file against — with an artifact number (e.g. 01.01.01), a definition, an inclusion level (Core or Recommended), and rules for which trials it applies to (sponsor vs investigator, drug vs device).
• Milestones are the study events (grouped into Start Up, Study Conduct, Close Out) that say by when each artifact is due.

Two vocabularies run across everything:

• TMF level: Trial, Country, or Site — the scope an artifact is filed at.
• TMF side: Sponsor TMF or Investigator TMF (ISF).

Create a trial¶

From Clinical trials, click New trial and fill in the study's identity:

1. Protocol number (unique in your organisation) and the study's title, sponsor, and therapeutic area.
2. Phase — Pre-clinical, Phase I–IV, or Other — and the EudraCT / CT number.
3. Study flags: Device study, Investigator-initiated, Blinded.
4. The retention basis — how long the file must be kept: 25 years (Reg (EU) 536/2014 Art 58), 15 years (Directive 2003/63/EC), 30 years (ATIMP traceability), or a custom period in years. QStack computes the retain-until date from this and the declared end of trial.
5. The TMF owner — the individual responsible for the file (EMA guideline §6.1).

A trial moves through Planning → Active → Completed → Archived (TMF locked). Archived is terminal — see Archive the file.

Define the trial's structure¶

Once the trial exists, build out the structure that its documents file against, inline on the trial detail page:

You can't delete a country, site, or party that transfers or filed artifacts already depend on — removing it would erase where the content came from. Deactivate a site instead when it closes.

Completeness¶

The Completeness page answers two questions: what should be in this file at all, and what should be here by now.

1. Click Generate the expected-artifact list. QStack builds the list of artifacts this trial should hold — every applicable artifact, once at trial level, once per country for country-level artifacts, and once per active site for site-level ones.
2. As you add countries and sites, use Refresh the expected list to fill in the new rows. Refreshing is additive — it never overwrites a decision you've already made.
3. The report groups expectations by zone, with tiles for Expected, Present, Overdue, Not yet due, Not applicable, and a percent complete.

Both the completeness report and its expected-artifact detail export to an Excel workbook, with overdue rows highlighted.

Receive a transfer from a CRO¶

Most TMF content arrives from a CRO as a bulk transfer. Receiving one is a four-step wizard — upload, review, commit, attest — and nothing is filed until you've reviewed it.

QStack reads two formats:

• eTMF-EMS package — the TMF RM Exchange Mechanism Standard: a ZIP containing an exchange.xml manifest and a zone/section/artifact folder tree. This is the preferred, fully-structured format.
• Metadata manifest (CSV/Excel) beside a folder of files — for CROs that can't produce an EMS package. It carries no audit trail or signatures, and files with no declared checksum are flagged as such rather than passed silently.

1. Upload. On Receive a transfer, pick the trial, the sending party, the format, and the package file. QStack stores it (recording its SHA-256) and runs a dry run — "Nothing is filed yet — every declared checksum is recomputed and every artifact resolved against the reference model first, and you review the result before committing." A package that can't be read is kept as Failed with the reason recorded.

2. Review. The dry run writes one review row per declared artifact — without creating any documents — and for each it:

• Verifies integrity by recomputing every declared checksum. A mismatch or a missing file is a hard error that blocks that artifact: the file was altered or corrupted in transfer, and it can't be filed.
• Resolves classification against the trial's reference-model version and its countries and sites. Anything it can't resolve is marked needs mapping — QStack never guesses; you supply the artifact with the inline picker.
• Detects re-transfers — an item the trial already holds is proposed as a supersede, not a duplicate.

The review page shows stat tiles (declared, to import, to skip, needs mapping, checksum failures, filed) and a grid sorted worst-first, with a decision on each row. Bulk actions let you skip thousands of rows at once — but an artifact with an integrity or resolution problem can only ever be skipped, never bulk-imported.

3. Commit. Only a reviewed transfer with nothing blocked can be filed. Committing creates the TMF documents in one transaction — preserving the sender's own signatures and audit trail, retiring any predecessor a document supersedes — and lands every new document in Awaiting QC review. Filing creates the records; each one still has to pass QC before it counts as filed.

4. Attest. EMA §6.4 requires a transfer of TMF ownership to be documented, so a Quality role holder signs that the transfer was received and verified against its manifest — how many artifacts were declared, filed, skipped, and failing checksum. Only Quality role holders can sign this.

QC a received document¶

A received document sits in Awaiting QC review until someone reviews it. QC isn't a single "passed" tick — it's the EMA §4.2 / §5.1 checklist, each item recorded separately: correctly indexed, filed in the right place, filed in a timely manner, access appropriate, and — for a certified copy — congruent with the original, accurate metadata and filename, legible, source audit trail present, and certification approved.

• A pass requires every check ticked. Don't untick something you didn't verify — record a fail with findings instead.
• A fail requires findings describing what was wrong. The document moves to QC failed and waits for the sender to resend or for it to be rejected.
• Filing is a separate step from passing QC, so passing never silently completes the workflow.

A document's full lifecycle is Received → Awaiting QC review → QC passed / QC failed → Filed → Superseded / Obsolete / Rejected. Only a person record can perform QC.

Documents and integrity¶

The TMF document page shows the artifact and its scope, the files (each with a "checksum verified on receipt" badge and the sender's declared checksum), the provenance (which party and system it came from, its source identifier, and any predecessor it superseded), and the QC review. The sender's asserted signatures and audit trail are shown boxed and clearly labelled as coming from the sending system.

Export and archive the file¶

Export. From a trial you can export an eTMF-EMS package — a spec-conformant ZIP with an exchange.xml manifest carrying a SHA-256 for every file, in the standard transfer folder tree. It includes the QC-passed, filed, and superseded artifacts (superseded versions travel too, per EMA §3.5.2; rejected ones don't), and passes the senders' carried-in signatures on unchanged. The export form collects the transfer identifiers from your exchange agreement with the recipient, and — if you name a recipient — records an ownership transfer in the trial's archive log.

Archive. Archiving is the irreversible lock: the file becomes read-only and must remain available for the full retention period (≥25 years under Reg 536/2014 Art 58). QStack lets a trial archive only when it's Completed, has a declared end of trial, has no overdue-and-missing artifacts, and carries an authorise-for-release signature from a Quality role holder. Archiving transitions the trial to Archived, locks it, stamps the retain-until date, and writes to a tamper-evident, hash-chained archive log that also records every later access and any ownership transfer.

Who can do what¶

• Any signed-in user can create trials, edit structure, receive and review transfers, run QC (a QC reviewer must have a person record), and export.
• Attesting a transfer and authorising the archive are restricted to holders of an active Quality workflow role.
• Viewing restricted artifacts requires a per-trial access grant with the restricted flag set.
• Every trial is isolated to your organisation, and an archived trial is read-only for everyone.

What this module doesn't do¶

• It doesn't manage controlled SOPs — those live in Quality Documents. TMF documents are received records indexed to the reference model.
• It doesn't add signatures of its own to received content or exported packages — it preserves and passes on the originating system's signatures and audit trail.
• It doesn't guess classification: anything it can't resolve against the reference model or the trial's structure is held for a human to map.