Case study: Filing CDMO Documents Into a Veeva Vault eTMF While the Taxonomy Keeps Moving

On 12 February 2021 the MHRA published its GCP inspection metrics for April 2018 to March 2019. Two of the critical findings describe the problem this case study is about. At one pharmaceutical company, essential documents held by vendors had never been defined in the TMF plan or index. At a CRO, eTMF naming was inconsistent and "document descriptions were not reflective of the contents", so inspectors had to open files to learn what they were.

Both failures happen where documents arrive from outside the sponsor. We built the platform that handles that point for a global pharma sponsor. Contract development and manufacturing organisations (CDMOs) drop documents into a shared space. The platform does the eTMF document classification into the sponsor's Veeva Vault eTMF. It also extracts custom fields and writes free-text fields the way the sponsor's experts would. The design choice that matters most is the taxonomy: the eTMF owners change it in real time, and no model or classifier is retrained.

The situation: documents from outside, a file that must be complete at all times

The sponsor runs its trial master file in Veeva Vault. Veeva said in June 2023 that more than 450 biopharma companies used its eTMF product. The sponsor works with CDMOs, and CDMOs that make or pack investigational product generate exactly the records GCP calls essential.

The list is explicit. The essential records table in ICH E6(R3) Appendix C includes samples of the labels on investigational product containers, shipping records, and certificates of analysis for product shipped. It marks the certificates of analysis as records that should generally be in place before the trial starts. In the US, 21 CFR 312.57(a) requires the sponsor to keep records of each shipment of investigational drug, including its batch or code mark.

So volume scales with batches, shipments, studies and countries, not with the TMF team. Each document lands in the shared space, not the eTMF. Someone has to read it, pick its artifact, fill in the fields and write a searchable description. Hexaware's account of a global CRO put reading, classification and quality checks at 15 to 25 minutes per document.

Three things break here, and all three are documented in public.

Timeliness. Article 57 of the Clinical Trials Regulation, applicable since 31 January 2022, says the TMF shall "at all times" contain the essential documents. EMA's TMF guideline reads that as filing in a timely manner, with filing timelines defined in procedures or TMF plans. It singles out arrangements with several parties as the hard case, which is what a CDMO shared space is.

Findability. The MHRA findings above show what happens when names and descriptions do not match content: inspectors cannot find things.

A moving taxonomy. The TMF Reference Model, now maintained by CDISC and renamed the TMF Standard Model, went through five versions between June 2015 and August 2023: v3.0, v3.1.0, v3.2.0, v3.3 and v3.3.1. CDISC itself says the model is not intended to be used "off-the-shelf". Sponsors adapt it and add their own sub-artifacts. The taxonomy a classifier must follow is the sponsor's own, and it moves.

What we built

We built a clinical trial document processing and management platform, fully integrated with Veeva Vault. It does four things.

1. It works from the shared space where CDMOs drop documents. That space is its intake.
2. It classifies each document into the sponsor's eTMF. The architecture lets the eTMF owners update the taxonomy in real time, without retraining models or classifiers.
3. It extracts custom fields. These are the sponsor's own metadata, not only the standard ones.
4. It enriches and writes free-text fields the way the company's subject-matter experts would. These are the descriptive fields people search on.

Integration matters because the eTMF is the record. A parallel store people work from instead is what the MHRA calls a shadow TMF, and it appears in the same findings. EMA's TMF guideline wants any upload from one system into the sponsor's eTMF to be robust and validated. ICH E6(R3) section 4.3.4(e) says the same of interfaces between systems.

Custom fields matter because standard fields do not describe a sponsor's process. Veeva's documentation for its built-in classifier, TMF Bot, reports extraction metrics for study, study country and site. Sponsors define more than that, and EMA's TMF guideline asks for metadata to be formally defined and consistent.

Free text matters because it is how people find a document without opening it. The CRO finding above was about exactly that.

What it achieved, and what the numbers in this market measure

The platform is shipped. CDMO documents are classified into the eTMF with custom fields extracted and free text written, and a taxonomy change takes effect without a retraining cycle.

We publish no accuracy, volume or time-saved figures here. The public figures in this market deserve a close read, because each measures something different.

Three cautions follow. First, right-first-time and classification accuracy are different quantities, and the Phlexglobal mid-sized pharma page does not define its term. Second, a figure above a confidence threshold leaves out the documents below it. Veeva itself notes that the threshold is not the same as accuracy. Third, scope matters. Hexaware's page lists 143 document classes covering 80% of TMF filings, beside classification into more than 4,000 categories, and does not say how the two relate.

The Hexaware deployment and the Phlexglobal benchmark in our library are useful comparisons for that reason. Both describe trained models that improve through feedback: user corrections at Hexaware, adjustments by more than 150 TMF experts at Phlexglobal. Neither says what happens the day a sponsor adds a new artifact.

What to measure instead, on your own documents:

• Agreement with your TMF specialists, artifact by artifact, on documents the system has not seen. An average hides the rare artifacts, which are the ones inspectors find.
• The defect rate your QC sample can defend. Accuracy sets how many misfiles exist; sample size sets how many you find. Our analysis of query and eTMF QC economics shows why a clean sample of a few hundred documents beats any vendor percentage.
• Field-level accuracy for each custom field, not one score for all metadata.
• How often experts edit the free text, and how much. That is the reviewer telemetry our piece on qualifying the human in the loop argues for.
• Time from CDMO drop to filed, against the timelines your TMF plan defines.
• Taxonomy change lead time: from an owner's edit to the first correct filing under the new entry, checking that old entries still route as before.

What makes the design work, and where it stops

Why retraining is the wrong unit of change

A trained classifier learns the taxonomy it was trained on. Veeva's FAQ puts it plainly: "the Bot can only predict a classification on which it has trained". A document of an untrained type is either not classified or misclassified. The model does not learn from users' reclassifications either, because training takes too long. Veeva's documentation gives about an hour to train on 3,000 documents and about 24 hours on 200,000, then up to two hours to deploy. Its auto-trained models refresh with each Vault release.

That is not a flaw in Veeva's design; it is how trained classifiers work. But a new, split or renamed artifact then waits for examples, a training run and a deployment. Hexaware's page names the human cost of the same problem: hiring extra experts to handle new document types.

Our architecture separates the taxonomy from training. The eTMF owners maintain the taxonomy, and the classification follows what they maintain. A new entry is usable when the owner adds it, not when enough examples have accumulated.

Real time is still change control

Real time does not mean untested. EMA's guideline on computerised systems in clinical trials covers eTMFs and wants trial-specific configuration pre-specified, documented and tested before release. ICH E6(R3) section 4.3.4(e) puts configuration in validation scope, as our reading of which E6(R3) clause governs a clinical AI model explains.

What changes is the size of the change. A taxonomy edit becomes a configuration change with a defined test, not a retraining project with a revalidation. Teams that skip the test have swapped a slow controlled process for a fast uncontrolled one.

What no design fixes

Four limits apply to any eTMF classification, ours included, and a buyer should test each.

Indistinguishable entries. If two taxonomy entries cannot be told apart from the document itself, nothing files them reliably; Veeva reports the same for its model. The fix is in the taxonomy, not the classifier.

Generated text needs review. Writing free text the way experts would is still writing. Someone has to sample it, and the sampling has to be recorded.

Blinding. EMA's TMF guideline warns that a TMF can hold unblinding information, and names randomisation codes as needing restricted access. Test that classification never files such a document where blinded staff can open it.

The model underneath can still change. Removing retraining from taxonomy changes does not remove model versions from change control. Our piece on model version control in a validated AI system covers that obligation.

One more boundary: filing a copy of a CDMO record does not make it a certified copy. Where a copy permanently replaces an original, ICH E6(R3) and EMA both require the certified-copy process.

The rules it had to satisfy, position current at 12 October 2026

No GCP text carries AI-specific requirements for an eTMF classifier. The obligations come from TMF and computerised-systems rules.

The EMA computerised-systems guideline is the one European GCP text that names AI. It puts AI in scope as an ordinary computerised system, and stops there.

What this means in practice

For the same result, work in this order, longest lead time first.

1. Write down the taxonomy you actually file against, and who owns it. EMA expects a defined TMF index. Agree who may change it and how. This takes longest because it is an organisational decision.
2. Put CDMO documents into the TMF plan. The MHRA vendor finding was a plan failure. Name each CDMO's artifacts, the drop location, the filing timeline and which date counts as receipt.
3. Build a labelled sample from your own documents. Have your TMF specialists file a sample of CDMO documents, rare artifacts included, and write the descriptions they would want. Everything else is scored against it.
4. Write the validation scope before the build. Cover intended use, risk and the configuration in scope under 4.3.4(e), and put a taxonomy-change test into change control.
5. Pilot and measure the six numbers listed above. Do not accept an average accuracy figure, ours or anyone's.
6. Set the QC sample on the measured defect rate. Decide what an inspector will be shown, and size the sample to defend it.

Three people sign: the TMF owner for the taxonomy and the plan, the system owner for the configuration, and QA for the validation and the sampling plan. If they cannot be named in the first meeting, the project is not ready to start.