If you are in the market for an electronic Trial Master File system (eTMF solution), 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 an extensive focus on functionality.
I know a lot about eTMF requirements. 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).
But guess what? If that is how you are trying to decide to choose your eTMF solution, I am pretty sure you’re doing it wrong in my (apparently not so) humble opinion, of course.
I can already hear the gasps. But before you drag me to the gallows, let me explain the reason for my heresy.
Better yet, let’s think this through together.
Thinking about Dominant Design for eTMF Solutions
When you buy a car, does your list include that it needs a steering wheel and must have headlights? Of course not, because you can reasonably assume any car 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.
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.
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 solution are, by now, very well understood. This set of capabilities may even be approaching a level of standardization that there is a dominant design evolving, which includes certain familiar requirements:
- Support of the TMF Reference Model
- The ability to create new TMF files and documents from templates
- Compliance with 21 CFR Part 11
- Support for electronic signatures
- A complete audit trail
- The ability to export and archive studies
You get the idea. There is a set of capabilities that every eTMF solution 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.
Think Beyond eTMF Features
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?
Note: I could include vendor qualities, but I am focused on the product itself for this discussion.
These are the real points of differentiation between the applications available today, and these are the areas where Agatha, as a vendor, focus. 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 delivers higher value. And, if an application costs less, it — obviously — delivers higher value.
Comparing costs is easy. You just need the subscription or license cost 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 the total cost of ownership.
And comparing the time required for implementation is pretty 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 solution. Because with an accepted definition of what an eTMF solution does, you really want to decide based on how well it does it, how fast it does it, and how much it costs to do it.