“Every discipline deserves a tool that serves their operational excellence.”

For many years, I have been writing on, and presenting at conferences about, the biopharma industry’s frustrations with information technology for trials management. What has been referred to as the CTMS space has been filled only partially by applications ranging from the uselessly simplistic to the impossibly over-featured. I have advocated for simplicity of interface, clarity of purpose, and design informed by true clinical trial understanding, but I have contributed to the flawed thinking that one tool should do the job. I’ve learned that it’s true what they say: after pounding your head against the wall for years, it feels good when you stop.

I am fully aware of the ironic fact that in just the last year or so, we are finally seeing some progress, as evidenced by the feature/function set and business approaches of a few new CTMS offerings. But this progress is probably too little, too late. I’m beyond this now, and I hear from many biopharma clinical development groups who are also beyond frustration with the enormous complexity, time sink and cost of their enterprise CTMS implementations, or the inadequacies of the simpler tools from a handful of other earnest vendors. Large pharma is stuck – they spent millions on enterprise applications that do not contribute to operational execution but have exhausted organizational will to try again. Small biopharmas are bewildered by the functional gaps and lack of implementation credibility from the affordable vendors, and abdicate to their CROs, whose dirty little secret is that they aren’t much more automated in their trial management than their clients.

The primary failing of today’s CTMS tools is that they are all what good marketing analysts call “product out” tools – by which jargon is meant that they are products in search of a market, and in this case, they all found pharma trials management. Unfortunately, coming from customer relationship management, product supply management, salesforce automation, generic project management, investigator site budget tracking, or other non-research starting points guarantees a long and expensive road to clinical development relevance – a road whose expensive trip will be paid for from pharma’s pockets.

The Premise is Wrong

The reason why the road is long and expensive, the reason why perfectly good applications from another industry trip up so badly in our field, is that we all have been chasing the wrong concept: building an enterprise CTMS tool which can be everything to everybody in clinical development. We apparently cannot build or modify an application that can serve the candidate program planner and the regional monitor (and everyone in between) at the same time. Oh sure, I have the diagrams to show how we can do it conceptually, but after how many years of failure should we stop trying?

Further, the traditional approach to CTMS has the workflow wrong for the 21st century. The big enterprise applications were based on the assumption that all trials management has to build up from either direct input from a worker bee somewhere, or from some piece of paper. This made the application workflow helpfully linear. But with widespread use of IVRS/IWRS plus EDC/ePRO and other e-sources, there are electronic sources everywhere.

There is a related flaw: we have compartmentalized where a CTMS should be used in clinical development to reflect the silos in pharma research today – silos which continue to exist despite several creative attempts at tearing them down. (The failures of now-famous attempts to crash silos and merge apples and alligators, like combining data management and study management, is a topic for another day). We have assigned CTMS to either “clinical operations” (by which in this instance is meant study management or monitoring management), or to “project management” (by which in this instance is meant that black hole which is farthest from daily operational execution but somehow controls everyone’s budget). This too is a flawed premise: what a CTMS can do (if there was such a singular application) should be in the service of the clinical development endpoint: bringing therapeutics to submission, and studying their medical and health economics impact after approval. No one of the dozens of disciplines which contribute to this endpoint have more a claim than any other on what a CTMS should do or look like, or what compromises should be made in buying/building one.

To Every One Her Own Applet

This I think is exactly the point. Every discipline deserves a tool that serves their operational excellence. What serves one discipline well, from the standpoint of technical architecture, platform, look and feel, connectivity and access, may not serve anyone else well. Trying to make these needs come together is where the head pounding starts.

I suggest instead a radical turnaround. Bring the enterprise approach to building trials management applications to a halt. Embrace the silos (and the silos within the silos). Enable each of them, all of them, with an application which serves their daily work: something which enables a monitor, a study manager, a drug supply coordinator, a regulatory compliance manager, a document librarian, and a metrics analyst to do his or her work today, this morning. Everyone should have a tool which enables them to do something useful – making information accessible, storing it, retrieving it, sorting, counting, comparing, sending, combining, normalizing, visualizing. Everyone should be able to do these things with the information they create and need right now, on their own. I no longer care how they do it, but rather than they can do it.

But then what do we do with this Tower of Applet Babel? At last, we have found something useful for IT to do. It should not be the job, nor the burden, nor the punishment, of clinical development that they be prevented from individual operational performance because someone has an unachievable dream for a single CTMS for everyone. No, this is IT’s job – to make technology enable what the business needs.

To be sure, this is a big job. It is mostly uncharted waters, at least in our industry. But the pathway is straightforward: get to the enterprise view of multidisciplinary data through layers of applications, each of which serves an operational function well, but can produce information which can be tied together for an integrated view and analysis of clinical development’s status, progress and performance. I would say the tools and methods for integration and analysis are actually well understood; where we have failed is in creating an environment where the information we get to integrate is accurate or timely or operationally useful. We should not leave behind the idea that management of clinical development requires management information. What we need to recognize is that operational excellence is more important than feeding an integrated data-gobbling application monster.

The answer then is identifying, acquiring or building the applets that individual functions need, and challenging IT with the exciting task of bringing together the output into something useful to management. It’s the layered look, with each layer deriving unique daily value. Why should we do this? Because information generated and used by the disciplines in daily work turns into clinical development knowledge, which in turn informs our ability to produce the therapeutics that serve our patients. No more head pounding. Lots more operational achievement.