eTMF Software for Sponsors and CROs: Why Your Completeness Number Lies

Why a trial master file breaks the software you buy for it

An inspection notice arrives for the study your filing depends on. The eTMF dashboard says 94 percent complete. Then someone opens the country file for Poland and finds a delegation of authority log signed by an investigator who left in month four, three versions of the laboratory manual with nothing recording which one superseded which, and monitoring visit reports for visits six through nine still sitting in a departed CRA's mailbox. That 94 percent was never a measure of completeness. It was a count of documents that happened to be filed, divided by a list somebody typed into a configuration screen at study start and never revisited.

ICH E6 expects a trial master file that permits evaluation of trial conduct and of the quality of the data produced. An inspector reads it as the story of how the trial was run. That story is told by which artifacts exist, when they were created relative to the events they document, and how they attach to a site, a country, a vendor and a milestone. A document repository with a folder tree holds pages. It does not hold the story, and the gap between the two is filled by a TMF team doing manual reconciliation for six weeks before every inspection.

Problem 1: expectedness is a calculation, not a folder structure

The DIA TMF Reference Model gives you zones, sections and artifacts, and almost every sponsor and CRO has modified it. The modification is not the hard part. The hard part is expectedness: which artifacts should exist right now, for this study, in this country, at this site, given where each of them sits in its own lifecycle. A site that has not activated should not be flagged for a missing monitoring visit report. A site that activated eleven weeks ago with no visit report on file is a finding in waiting. One number cannot represent both.

Veeva Vault eTMF models this properly and is the strongest product in the category. What sponsors run into is that expectedness rules are configuration inside a platform, so when your rules depend on facts the platform does not hold, for example a vendor's contracted scope, a local ethics requirement in one country, or a device study's technical documentation, the real truth migrates back into a spreadsheet sitting beside the system that was meant to hold it. Montrium eTMF Connect inherits the content model of SharePoint and Microsoft 365, which is comfortable for IT and awkward once a single study carries tens of thousands of artifacts with long version chains. Phlexglobal PhlexTMF comes from a TMF services heritage, which is genuinely useful if you want people to run the TMF for you and less useful if you want to own and change the rules yourself. Florence eBinders is excellent on the site side, where the investigator site file and remote monitoring access are the real problems, but it is not a sponsor-side portfolio view across studies. MasterControl treats TMF content as controlled quality documents, which is a different shape from study, country, site and vendor.

What a custom build does: it makes expectedness a rule engine sitting on a milestone timeline. Each artifact definition carries a trigger, an owner, a due offset and a scope, so the system generates the expected set continuously rather than once. Activate a site in Spain and 31 expected artifacts appear against that site with dates. Terminate a vendor and their expected set closes rather than sitting open forever, dragging your number down. This one change is usually what converts the TMF from a filing cabinet into an operational instrument, because now the weekly report tells a study manager what to chase this week instead of telling everyone the same 94 percent.

Problem 2: documents arrive from everyone except the people you employ

Sites email scans. Central labs post manuals to their own portal. Ethics committees send approvals as photographed paper in three languages. Couriers, translation vendors, IRT providers and imaging core labs each have a different transfer habit. Your CRAs upload from the field on a hotel connection. The result is duplicates, wrong site numbers, wrong study, and a filing queue that a coordinator works through by opening each PDF and reading it.

This is where AI does one concrete job, and it is not a chatbot. A classification and extraction pass reads the incoming document, proposes the artifact type against your index, pulls the site number, the document date, the version and whether a wet or electronic signature is present, then routes it to a human for one-click confirm. Across our regulated document projects, the no-touch confirmation rate settles around 80 to 90 percent after a few weeks of corrections, and the remaining 10 to 20 percent is exactly the interesting material a reviewer should be looking at anyway. A second model pass detects near-duplicates and probable supersedes, which is the failure mode that produces three laboratory manuals with no relationship between them. Every automated decision has to be recorded in the audit trail as a system action with the model version, because an inspector will ask who classified this and the honest answer needs to be reconstructable.

Problem 3: migration is the project, and everyone budgets it as a task

Legacy paper in offsite storage. A shared drive with 400,000 files. The previous CRO's system, which you can export from but not query. An acquired asset whose TMF lives in a third platform under a licence that ends in four months. Every eTMF programme we have seen run over budget ran over on migration, not on features.

The approach that works is to inventory before you decide anything. Crawl the sources, hash and cluster, classify with the same model that will run in production, then produce a report showing what you actually have against what the reference model expects for those studies. That report is the artefact your quality lead uses to decide what gets migrated, what gets archived as-is with a documented rationale, and what is not TMF content at all, which is usually a surprising share of a shared drive. Migrating blind means paying to carry rubbish into a validated system, then paying again to explain it to an inspector.

Problem 4: you need three numbers, not one

Completeness is filed against expected. Timeliness is the gap between the document date and the filing date measured against your own SOP, and it is the number inspectors probe hardest, because a file that was assembled the month before an inspection tells its own story. Quality is the QC pass rate on reviewed artifacts, which only means anything if your QC sampling plan is defined and applied consistently. Reporting one blended percentage hides all three. Build the model so any of them can be sliced by study, country, site, vendor and TMF owner, and so the same figures can be regenerated for a date in the past, because the question at inspection is what the TMF looked like then, not what it looks like today.

Problem 5: privacy, blinding and who is allowed to see what

Consent forms arrive with patient initials and dates of birth on them. GDPR obligations differ from the redaction habit at a US site. A blinded study needs randomisation and unblinded pharmacy content walled off from the study team but retained. A CRO holds TMFs for competing sponsors in the same instance and cannot let one see the other. An inspector needs read access scoped to one study with every view logged. Access control here is not a role dropdown, it is a policy layer over study, country, site, artifact type and blinding status, and it has to be testable, because you will be asked to demonstrate it.

Validation is not the line item to cut

Anything holding TMF records is a regulated computerised system: 21 CFR Part 11 in the US, EU Annex 11 in Europe, and GAMP 5 as the practical framework. That means a validation plan, requirements traced to test scripts, installation, operational and performance qualification, documented change control and a periodic review. In our experience validation and its documentation add 15 to 25 percent on top of engineering cost, and a partner who quotes a regulated eTMF without that line has either done it before and hidden it, or has never done it. Ask which.

What this costs and how long it takes

A first release with your modified index, milestone-driven expectedness, ingestion including the classification pass, QC workflow and the three metric views runs $95,000 to $190,000 and ships in 14 to 20 weeks, based on Digital Heroes delivery experience. A validated platform adding legacy migration, per-country redaction, sponsor and vendor portals, e-signature and a defensible inspection export runs $260,000 to $650,000 phased over 9 to 15 months.

What drives the number up in this category specifically: the volume and mess of legacy content, since a million-file shared drive is a different project from a clean export. Multi-tenant separation if you are a CRO holding several sponsors. Electronic signature, because Part 11 signature manifestations have to be right rather than approximately right. The number of external feeds, since each vendor transfer is its own contract, format and failure mode. And translation handling, if your ethics documents arrive in nine languages and someone has to certify the English version. What keeps it down: scoping the first release to active studies only, leaving closed studies in their archive with a documented plan, and resisting the urge to rebuild the CTMS at the same time.

Build versus buy, and when licensing is the right call

Licence, and do not call us, if you are a small sponsor with one or two studies, no in-house quality function and no appetite to own validation. Veeva Vault eTMF or Florence will serve you better than anything you commission, and the per-study cost is rational at that volume. The same is true if your TMF is genuinely standard and your operations team is happy to work the way the product works.

Build when two or more of these hold. You run a materially modified index and are maintaining the real expectedness rules outside the system. You are a CRO and need one portfolio view across sponsors with hard separation. You are past roughly a dozen concurrent studies and per-study platform fees have overtaken a build. You have vendor and site feeds that nobody will change for you. Or you have TMFs in three systems after an acquisition and consolidation is now a board-level commitment with a date on it. The tipping point is not features, it is that your expectedness logic has become a piece of intellectual property and you cannot keep it in a spreadsheet.

How to choose a developer for a regulated eTMF

Ask them to whiteboard expectedness before you sign anything. Someone who has done this will draw artifact definitions, triggers, scope by country and site, and a lifecycle that opens and closes expected sets. Someone who draws documents and folders has built a file store and is about to learn ICH E6 on your budget.

Ask what validation deliverables they produce and who writes them. Requirements traceability matrix, IQ, OQ, PQ, change control and a periodic review procedure should come back without hesitation. Ask how they handle supersede chains and how the system reconstructs the TMF as of a past date, because that single question separates people who have faced an inspection from people who have read about one.

Ask who owns the code, the infrastructure accounts and the validation package, and get it in writing before kickoff. The validation documentation matters as much as the repository, because without it your next partner revalidates from zero. At Digital Heroes the client owns both from the first commit, and we would tell you to walk away from anyone who hedges on it.