Three eTMF quality checks that catch the most audit findings

Most TMF inspection findings aren't surprises. When we look at the documents flagged across customer trials over the last two years, the same three patterns show up over and over. None of them require a clever auditor. All of them are catchable at upload time — months before the inspector lands.

Here are the three, in the order they show up most often, with what we do about each.

1. Missing or mismatched signatures

The single most common finding: a signed document where the signature page is missing, or where the signatory's printed name doesn't match the role they're signing in. A clinical research agreement signed by someone who isn't a delegated signatory. A protocol amendment with a date earlier than the IRB approval that authorised it.

What we check on upload:

• Pages count — does the document have a final signature page where the template expects one?
• Signature blocks — are all expected signatories present? We extract the typed names and roles and compare against a maintained delegation log.
• Date sanity — does the signature date sit within the window of the underlying authorisation?

This catches roughly 60% of inspection-type findings before the document is filed.

2. Version drift between TMF and source-of-truth

The CRA finalised monitoring report v1.3. The investigator pulled v1.1 from a shared drive and signed that one. Both end up in the TMF, possibly in different sections. The audit trail looks fine until somebody asks which version was actually approved.

The systemic fix is one source of truth, not three. The tactical fix is a check that fires whenever two versions of the "same" document land in different artefact slots, regardless of who uploaded which. We hash document text and surface the conflict to the document owner immediately, with a clear "which version is the official one?" prompt.

3. Filing-against-protocol-version mismatches

This one is subtle. The protocol amends to v3.0. The site continues to file source documents and informed consents referring to v2.0 because the new ICF hasn't been re-consented yet. Strictly speaking that's correct — until the day the patient is re-consented and the next visit's documents need to flip to v3.0. It's easy to miss the boundary, and it's the kind of thing inspectors catch by sampling.

The check we run: every uploaded patient-facing document must reference an active protocol version on the day the document is dated. If the site filed against an outdated version, we flag it for review against the re-consent log. This isn't a hard block, because there are legitimate reasons to file against a prior version, but it forces a conscious decision rather than a quiet drift.

Why the timing matters

All three of these checks are doable at lock time. They're also miserable to do at lock time, because by then you have a backlog and a deadline. Running them at upload — automatically, in the background, surfaced to whoever owns the document — turns a dreaded final-mile push into a steady drip of small fixes throughout the trial. The team's experience of the TMF changes from "the thing we have to clean up" to "the thing that's clean."

If you'd like to talk through how this works in your protocol, we're happy to walk through it.

Further reading: the EMA TMF guidance and the DIA TMF Reference Model are the two canonical sources for what should be in there in the first place.