Managing the Trial Master File
An eTMF Technology Guide
TABLE OF CONTENTS
“In the US, there is no specific requirement from FDA for companies to prepare a trial master file, but if the regulatory authority requires ICH GCP to be followed, then there is consequently a requirement to create and maintain a trial master file.” – Trial Master File (TMF): FDA Expectations From Sponsors And Sites<top>
Three Generations of eTMF SystemsThe need for software-based systems to manage Life Sciences companies’ content came to the fore in the 1990s. The catalyst was the intersection of two evolutionary developments. The first was the emergence of a class of software called document management systems, which went beyond the management of data to the management of semi-structured and unstructured content, like documents and files. The second development was the issuance of regulatory requirements by the regulatory authorities that oversee the development of medicines and medical devices, which in the USA took the form of 21 CFR Part 11. Along with similar regulations in Canada, the EU, and Asia, this body of rules dictates how electronic records and documents need to be managed, including stipulations regarding access controls, version management, and audit trails.
The First Generation eTMF Systems
The emergence of these rules and the availability of a new software class – document management systems such as FileNet, OpenText, and Documentum – created new systems for Life Sciences companies. One of these new systems was the first generation of software for managing trial master file content (along with parallel software for many other processes).
With costs in the millions of dollars and the need to be custom-built on a document management platform, only large companies could afford these first-generation systems. That first generation was installed within those companies’ data centers (on-premises), so the initiative also included extensive IT resources and commitment.
Even with high costs and complexity, the biggest companies forged ahead with first-generation eTMF systems because the need to manage this type of content in compliance with requirements was so great.
Second Generation eTMF Systems
The second generation of eTMF systems emerged in the early 2000s and was characterized by two shifts. The first was the emergence of modular, packaged solutions, pre-configured to meet the basic requirements of the eTMF process. An eTMF solution could now be bought “off the shelf” instead of custom-built.
The second shift was a move to additional platforms, in particular Microsoft SharePoint. At the time, SharePoint was installed in most large companies, so it did not require a new platform.
Two things did not change between the first and second generation eTMF systems:
- They were built on top of large software platforms, so they remained complex and costly. Therefore, they were suitable for larger pharmaceutical, biotechnology (biotech), and medical device companies (along with the CROs who manage trials for them).
- They still took a long time to bring into production, typically six months or more.
Third Generation eTMF Systems
In 2007, Veeva emerged as a new vendor in the Life Sciences space, and it represented a new, third generation of software for managing content for Life Sciences companies. The defining characteristic of this generation was the move to the cloud.
With this shift, pharmaceutical, biotech, and medical device companies could implement an eTMF system without installing software in their data center, which meant no dependence on the internal IT department. This radically simplified the process for implementing an eTMF software solution.
Veeva’s approach did not change other aspects of the model, however. eTMF solutions and the related solutions offered by this generation of vendors still depended on a “platform” mindset: a base content management system configured extensively to the customer’s needs.
As with prior generations, the process begins with “Requirements Gathering” followed by “workshops” to review the system configurations made to address the requirements. After the system is fully configured – a process of several months – the validation process would be undertaken, an extensive process because every system reflects a unique combination of configurations.
Third-generation eTMF systems also reflect their forebears in terms of the user interface and ease of use. They rely excessively on lists and folders and still have a distinct SharePoint or Documentum look and feel. This results in an obstacle to user adoption, especially among newer generations of users reared on consumer software applications that require no training before use (think Facebook and Instagram).
The result is a cloud-based system that removes the need for IT to provision a system internally, but a system that remains complex, expensive, and takes a long time to implement.
1 Cloud-basedEarlier generations of TMF solutions were based on complex software platforms that you installed “on-premises,” that is, in your own server environment. That created huge costs and complexity, and today is a non-starter. A 4G eTMF application must be cloud-based, so there is no installation on your part. All you need is a log-in and password.
2 Subscription-basedSoftware used to be licensed with a one-time, perpetual license. Your license costs were all upfront in that model, and vendors were not incentivized to invest in you as a customer. Today, software is provided on an annual subscription basis, a much better arrangement because the vendor has to earn your business each year.
3 Follows the TMF Reference ModelThe Trial Master File Reference Model (TMF RM) Working Group was formed in 2009 by the Drug Information Association (DIA) Document and Records Management Community. The Reference Model provides a standardized taxonomy and metadata and outlines a reference definition of TMF content using standard nomenclature. While most organizations will not use the full reference model — they will add additional items and ignore items not relevant to their studies – the Reference Model dramatically simplifies the initial set-up of an eTMF system.
4 Ready-to-UseEarlier systems for managing TMF content were based on the idea that you would configure a system extensively based on your own processes. This created long implementation times of six months up to a year to get into production. Today, TMF management processes are so standardized that most of the functionality can be preconfigured and ready to go. A 4G eTMF application should be ready to use in two to three weeks.
5 PrevalidatedA 4G eTMF is prevalidated so that scripts have been run against the core functionality, and proof of that validation process is available to you. That reduces the validation process immensely because all that is left for you to do is run a final user acceptance test set. With that step plus the vendor’s validation process, the system is fully qualified.
6 Easy to useNo, I mean really, truly easy to use with a modern user interface. A 4G eTMF should look like an application your kids would enjoy using, not one your parents used. It should leverage modern navigation and user interface features and be completely compatible with use on mobile devices. If a solution you are looking at looks like SharePoint circa 1995, move on.
7 Include eSignatures and Audit TrailsThis is not a differentiator for a 4G eTMF because eSignatures and audit trails are fundamental regulatory compliance requirements. But we do not want to miss the point that, of course, any modern TMF application must address the regulatory rules for the US, EU, Canada, Japan, and any other countries where your studies may execute.
8 Integrate with trial sitesClinical study sites produce files and documents throughout a study process, and the process of reviewing and collecting these items from the site is usually a bottleneck. A 4G eTMF application must give sites a way to provide content access to study monitors and CRAs to streamline the process.
9 A REST APIAn eTMF application must include the ability to exchange items with other systems. The Trial Master File is just one of many processes and structures involved in managing clinical trials. For that reason, it is essential that the TMF can easily integrate with and exchange information with other systems. The hallmark of a modern 4G/eTMF is its “REST” API interface architecture, which is the current standard and easiest way to integrate systems. You do NOT want a custom connector between two systems, which inevitably adds cost and complexity.
10 Import, export, and archiveStudies start, stop, and sometimes get interrupted. The eTMF must be able to take in a set of TMF files that have already been created and to recognize and categorize them. Equally important is the need to “lockdown” a study file as a permanent archive and export it in a complete structure (for example, a Zip file containing PDFs) for transportation to another system or location. <top>
Choosing a Fourth Generation eTMF: Focus on Value, Not Features
If you are in the market for an electronic Trial Master File system (eTMF), it is almost certain you have made a list of requirements that leads with compliance, functionality, ease-of-use, and cost. And if I had my way, I would stop you right there, on requirement number 23 in the “Security” section. I have probably seen more than 1000 RFPs (requests for proposals) for trial master file solutions that focus on these four elements, with a considerable focus on functionality.
I know a lot about eTMF requirements because, to be honest, responding to 200 line items, each with a discrete functional requirement (“ability to render a PDF”) or compliance requirement (“include an audit trail”) and requiring me to say whether it is out of the box, a configuration, or customization is not my favorite way to spend a Sunday evening (binge-watching The Queen’s Gambit would be a nice alternative, for example).
When you buy a car, do you include on your list that it needs a steering wheel and must include headlights? Of course not, because you can reasonably assume any vehicle will indeed be steerable and legal to drive. Instead, you focus on the DIFFERENTIATORS between vehicles that matter TO YOU, such as all-wheel drive, gas or electric, and (of course) the number of cup holders.
That’s because there is an acceptable minimum standard for a car that includes specific elements, a concept called a “dominant design.” When a product or technology becomes mature, there is an evolution into a dominant design. For example, the QWERTY configuration is the assumed layout of the keys when you shop for a keyboard because it evolved as the dominant design, even if it is not the most efficient.
In a modern 4G/TMF, it is the coordination of processes, more than the management of documents, that is critical.
Another example: What you think of as the screw-shaped bottom of a light bulb is the “Edison Screw,” which is how most light bulbs – incandescent, LED, or perhaps fuel-cell-based – have been secured in place since 1880. It is not necessarily the best interface. It is just the dominant design for that interface, and once a dominant design has evolved, it tends to be hard to displace.
What’s my point? I think the features that comprise an eTMF application are, by now, very well understood.
This set of capabilities may even be approaching a level of standardization that constitutes a dominant design,
comprising a core set of requirements:
- Compliance with 21 CFR Part 11
- The ability to create new TMF files and documents from templates
- Views and reports based on document types and metadata
- Auto naming and auto-numbering of documents based on a configurable naming convention
- Access controls at the TMF, folder, and item level based on roles
- The ability to determine at any time “what’s missing” in terms of TMF items not yet added
- The ability to route items for review and approval
- Notifications of assigned tasks, due dates, and overdue items
- Support for electronic signatures
- A complete audit trail
This is not a comprehensive list, but you get the idea. The point is, there is a set of capabilities that every eTMF – of every generation – must-have. If you are looking for an eTMF, it is fair to assume that any application on the market will have these core capabilities.
A Better Basis of Comparison
So if it is not about features, how should one choose an eTMF? I would argue that it should be based on answers to three questions:
- How easy is it for new users to start using the application?
- How quickly can the application be implemented?
- How much does it cost, including software and services?
These are the real points of differentiation between the applications available today, and these are the areas where Agatha, as a vendor, is focused. And the reason we focus here is that these factors drive value. If users adopt new software effectively, it is more utilized and delivers higher value. If a system is faster to bring into production, it provides higher value. And, if an application costs less, it — obviously — delivers higher value.
Comparing costs is easy. You need the subscription or license price and any services that are required. Add these up, add the time required from team members to get trained and to get the system into production, and you have a first cut at a total cost of ownership.
Comparing the time required for implementation is easy too. Just ask other customers how long it took.
For the ease-of-use factor, a little more work is required. And the best way to ascertain that is to get your hands on the software and try it out. I’ve written about the need for “more than a sandbox.” Instead, demand a trial period to put the application to the test with different types of users. See how easily they learn to navigate the application and complete basic tasks.
With the total cost of ownership, the time to implement the application, and the ease-of-use factor evaluated, you should be ready to choose your new eTMF application. With an accepted definition of what an eTMF does, you want to decide based on how well it does it, how fast it does it, and how much it costs to do it.
The “ Requirements First” ModelWhat drives that approach is a basic assumption: the functionality of the system should be based on an existing process, perhaps manual, that you already have in place. So the project team collects “requirements” – that is, the functionality needed to replicate your existing process – and the technical team makes the system work that way. It sounds fine, but frankly, it is backward. With a modern 4G/TMF, the organization should adapt to the functionality in the system. Why? Because the system reflects accumulated knowledge from many organizations and has “best practices” baked in. It is safe to assume that the system has more wisdom built into it than the ideas of your team’s home-grown process. The value of an “off-the-shelf” system is lower cost and proven functionality, and high dependability. The more you modify it, the less it delivers on those measures. Start with what the system does, not what you want it to do because of how you operate today. I may be overstating this. Of course, you will configure the system for access and basic workflow processes, such as who reviews and approves documents. But I will stand my ground that you should NOT start the implementation project with requirements; you should start with the system’s functionality. So how does that work?
Taking the Agile ApproachThe implementation approach to a 4G/TMF is not based on a structured, “waterfall” project plan with separate, sequential stages. Instead, it starts with a review of the application’s functionality and then reviews the areas that need to be configured. In a series of “sprints,” the team will review configurations that have been made, identify any additional configurations or adjustments, and then repeat the cycle. (For IT folks, this reflects the “Agile” methodology.) Graphically, it will look like a spiral, with overlapping loops of review, identification, and configuration. The project may still end with training and validation, but the training step may be superfluous because the team will learn the system during the sprints. Look for a project plan that is measured in two to three weeks, not months. A plan that reflects Agile methodology principles and language, such as sprints. Look for a simple user acceptance test step, not an elaborate validation plan. And lastly, look for a project team that seems focused on executing with enthusiasm, urgency, and momentum. A 4G/TMF project, like the application itself, should be simple and easy to understand. And ideally, a little fun. But if the plan looks like it would be more appropriate to undertake to build a high-rise building, run, don’t walk away. Because frankly, it does not have to be that hard. We are talking about a TMF application, not rocket science. And it has been done before…perhaps 10,000 times. <top>
Download the Guide to 4th Generation eTMF SystemsTrying to wrap your head around how a modern electronic trial master file system should work? Our in-depth guide is packed with information to help you understand what to look for when the time is right to purchase your eTMF system.
Interested in seeing how Agatha’s applications can help you improve your clinical and quality processes? Take it for a test drive.