Phlexglobal Blog

What To Know Before You Migrate a Trial Master File

Written by John Lazenby & Richard Shore | Jul 30, 2019 8:20:19 PM

Adapted from a March 2019 Phlexglobal webinar. For an in-depth look at the topic of migrating TMF data, view the webinar presented by Richard Shore and John Lazenby, available on-demand here

There are many sound reasons to migrate a Trial Master File (TMF), but doing so comes with a host of obstacles - ensuring data integrity and compliance, quality control (QC), managing legacy data, dealing with data from different sources and systems, to name a few.

Fortunately, there are new tools available to overcome these challenges, such as the TMF Reference Model (RM) 3.1 and the new RM Exchange Mechanism, along with proven industry best practices to help ensure a successful migration.

In this blog we’ll provide a high-level view into some (but not all) of the obstacles you are likely to encounter, to help you frame some of the questions you should be asking if you are considering conducting a TMF migration. We suggest reading this blog first and then registering for the webinar noted above, if you are interested in a deeper dive into the topic. And of course feel free to contact us with any questions you may have about TMF migrations.

 

Why Migrate A Trial Master File?

Before we dive into the why of migrating a TMF, let’s establish our definition of what we mean when we refer to data migration.

In this case, Wikipedia has a pretty good summary:

“Data Migration is the process of selecting, preparing, extracting and transforming data and permanently transferring it from one computer storage system to another. Additionally, the validation of migrated data for completeness and the decommissioning of legacy data storage are considered part of the entire data migration process.”

For our purposes in migrating Trial Master Files, we also include any migration from paper to electronic form in this definition. The permanent aspect of this description is also important to keep in mind, since the intention of a TMF migration is usually that the data will no longer reside in the source system.

There are many reasons why companies migrate a Trial Master File, including:

  • Implementing a new electronic Trial Master File (eTMF) system
  • Transferring a TMF from a Contract Research Organization (CRO) to the trial sponsor
  • Transferring a TMF from a CRO to another CRO (rare, but it does happen)
  • Acquiring or divesting a compound or molecule
  • Corporate mergers & acquisitions
  • Consolidating eTMF information (e.g. from Safety / Regulatory systems or EDC) into a core eTMF

In our experience over the years performing validated migration activity for hundreds of studies, we've supported organizations ranging from small biotechs to the industry’s largest sponsors and CROs. To provide a flavor of the different types, the following table offers a small sampling of the migrations Phlexglobal has successfully conducted over the years:

 

Project

Client & Timeline

Outcome

CRO Maturity Project

Trial Sponsor A: Ongoing TMF migrations from their CRO

2016 – Current

  • 14 Studies have been migrated – most at closed status from CRO exports (media, secure transfers)
  • Studies migrated into mapped TMF RM 3 (Reference Model version 3) structure
  • Successful ongoing migration project

Study Acquisition

Sponsor B: acquired two studies from Sponsor C

Mid 2018 – six-week turnaround

  • A successful migration of metadata and document content from a Veeva eTMF source system to the acquiring company’s eTMF, Phlexglobal’s PhlexTMF 4

eTMF System Migration

Multiple trial sponsors: Map, Import, and QC content to and from various eTMF platforms

2017-2019

  • Most recent migration was a remapping, successfully completed in five weeks

 

The first project, CRO Maturity, is one we’ve been executing for several years now for one of our sponsor clients. At study end, when their CROs provide quality-assured (QA’d) content back to them, we receive that content and conduct a standardized validated process to inspect content, prepare indexes, and map content via migration into their eTMF platform. This project tends to be quite complex as the source filing structures all vary. The destination filing structure is version 3 of TMF Reference Model.

We’re also getting an increased number of requests for the second type of project, Study Acquisition. As part of the acquisition process a study needs to be migrated between eTMF systems. Often there are not just one but several studies that are moving from one sponsor’s CRO or from sponsor’s own eTMF system.

As with the first project, there is a significant degree of complexity considering that the source system of the acquired study or studies is almost always different from the acquiring sponsor’s destination eTMF, and we are migrating both the content and the audit trail. In addition, these projects generally have extremely tight timelines, since the acquiring company is seeking to leverage that study data as quickly as possible.

The third example, eTMF System Migration, is another type of project where we’re seeing increased demand. These are usually driven by implementing a new eTMF system or bringing legacy data into an eTMF, and require a detailed mapping, import, and quality control process. The primary challenge here is that the source system varies across the board. It could be a CRO’s eTMF, it can be even a number of files in a file share.

Understand the Migration Details and You’ll Know the Obstacles

Below are summaries of three of the most common challenges we see when migrating a Trial Master File, regardless of the type of project.

1. Incomplete or Inconsistent Index From Source Systems – Or Even No Index At All

Perhaps the most critical component of a successful migration is an index. Ideally, there is some form of index from the source system or systems.

All too often, however, we come across the following:

  • No index. Which means we must create an index from scratch, adding significant time and effort to the migration.
  • Minimal information in the index. Similar to the above, although we can then usually derive content from where the files are stored, particularly if content is coming from a file share in a company's internal network - something that occurs quite often.
  • Multiple index formats such as HTML, XML, or Excel (the most common), or a hybrid. Each format adds its own challenges in deriving key information.
  • The index has more entries than the files we've received, or vice versa. This creates numerous interpretation challenges and judgment calls.
  • Character encoding issues. Think Korean/Japanese/European in one spreadsheet (it can be done!)

All of these add to the tremendous complexity of a migration project. To provide a bit more background, let’s take a closer look at the last two on the list.

A discrepancy between the index and the files provided occurs frequently, and comes to light as we conduct our checks on all the content to be migrated. Let's say the index lists a thousand documents, but within the folder structure that was supplied there are 1500 documents. Or perhaps some of the sites that were included in the content set provided to us weren't indexed at all. It’s critical to thoroughly understand the quality of the index and the quality of the content before migrating.

When you're consolidating an end-of-study index to provide for migration, the character and coding become very important – yet it’s an area that is often overlooked. This almost always becomes an issue for organizations working in more than one country, since each of those countries will likely be producing their index content with different types of character encoding, and in different languages. We frequently see that character and coding gets broken while the indexes have been prepped or QC'd before they're being shipped.

 

2. Missing/Inconsistent/Corrupted File Content

Once you have your index, you have to dig into the files. Let’s say the index lists a thousand documents. Each of these thousand documents might have other relational metadata; if it's based on the TMF Reference Model then it will likely be zoned into section artifacts and even subartifacts.

The real challenge comes in the different file formats and the different ways they can lose critical information. What we call “container” formats are becoming more common, and create significant challenges when migrating a Trial Master File.

Below are some examples of container formats and their variations, and the obstacles they raise to a successful migration:

Portfolio PDFs: a container format PDF which can contain other files, and which seems to be the most common type when providing correspondence for the TMF migration. It may contain many other PDFs that are emails that have been rendered when they were exported from the email system (usually Outlook).

In each of those PDFs contained within the portfolio, however, there may be more attachments, with even more PDFs within those attachments, and so on and so on. These container formats can thus present a big challenge because the index file may only reference one file, but in that container PDF there could be a thousand email messages. What’s more, there could be additional and essential content in many of emails.

Annotation Attachments: Occurs when organizations export PDFs from their email system in bulk to include all the correspondence related to the study – or perhaps for a date range for that site. This is an obstacle we come across frequently, since any attachments that were included in the original email are often lost, with the attachments converted into a filename or image with no underlying content.

Zip Files: Zip files are a popular option for providing large numbers of documents. These are, however, prone to problems including damaged files and/or corrupted content. This is where an initial inspection of the content being provided is so important. The more time that passes from when the original document was created, the harder it is to go back to the source and try to find a workable copy.

 

3. Missing or Incomplete Audit Trail

Audit trails are becoming more and more important in any kind of migration of eTMF content. Currently there’s no standard for audit trails; we see a mixture of different formats depending on the source system. Excel is the most common, but we also see XML and PDF. If a PDF, it’s generally used to contain what was in the larger spreadsheet file. We sometimes see that the audit trail is embedded in the index.

In other cases, there’s no audit trail provided at all. So it's important to find a way to get audit content from the source system or systems and find a way to link that back to documents. It's an area of focus right now among regulators and the industry, and we are seeing increased demand for this from our customers in terms of inspection-readiness.

 

There’s Much More Lurking Beneath the Surface of Every TMF Migration

As noted earlier, this blog is just a high-level view and represents just the tip of the massive iceberg that makes up a Trial Master File migration.

At Phlexglobal, our experience conducting hundreds of TMF migrations, including all manner of source and destination environments, has allowed us to develop a set of core best practices and Standard Operating Procedures (SOPs) that are the key to a successful migration. We go into these system-agnostic tools and processes in more detail in our webinar, and cover topics such as the importance of comprehensive migration reporting and evidence, and what you should know about your source and destination systems.

As you have seen, migrating a Trial Master File is not simple – but with the right knowledge and experience, you can ease the burden on your organization while achieving a successful migration.

Ready to Learn More?

 

Industry Guide

In this industry guide, Phlexglobal experts outline three important steps to take in order to properly execute a TMF Migration. 

On Demand Webinar 

Migration specialist Jonathan Lazenby and Richard Shore take an deep dive into TMF Migrations in this on-demand webinar.