“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.

There are more myths than truths about using IT in global trials.

Conducting clinical trials globally is an essential component of any biopharma’s clinical development plan. Large or small, regardless of therapeutic specialization or Phase, clinical trials are increasingly conceived and implemented with subjects literally from around the world. One can confidently argue that such a strategy would be impossible without today’s information technology – from the basics of email to the most sophisticated clinical supply resourcing algorithms. Certainly electronic data capture is at the heart of most global trials, and some means of keeping tabs on global trial management through technology is also essential, be it simple spreadsheets or elaborate tracking systems.

Nonetheless, there is another truism about the use of information technology in global trials: there are more myths than truths about using IT in global trials. This column will touch on just a few examples.

Let’s start with one of the most common: computer technology can’t be used in the developing world where all our trials are. This is one of the enduring and inexplicable myths. It is the worst sort of first-world arrogance that we assume developing countries don’t know what the Internet is. In fact, many developing countries have benefited, if that is the word, from getting such a late start in telecommunications. When the world’s high-tech Help Desks are located in Hyderabad and Sofia, and the high-speed wireless infrastructure is better in Eastern than Western Europe (and much better than most North American city neighborhoods), you realize how mythological this statement is. Talk to monitors who work in the developing world and they will tell you how they wish their home office had such a good connection. EDC vendors have claimed their tools have been used successfully in over 100 countries. The hardware is increasingly ubiquitous at lower and lower costs. Certainly, many sponsors find that it may still be necessary to “drop in” high speed connections to their desired investigative sites, but this too is decreasingly necessary. When you realize some of the largest sellers on eBay are in countries like Malaysia, and eBay’s buyers come from literally all over the world, how do we in pharma justify such snobbery or ignorance?

Let’s start balancing the myths right away: the clinical IT vendors have laid the groundwork for your global use of their software. Alas, not quite so. While several vendors have very broad exposure to countries all over the world, this by no means translates automatically into local execution excellence. They are as likely to be discovering the right and wrong ways to get connected (or in the case of ePRO, move hardware in and out) in real time on your trial’s nickel, as they are able to come to you with the answers in hand from the beginning. The failings are particularly acute when considering the areas where the vendors consistently underperform regardless of country – providing consistent, knowledgeable project managers, and providing a help desk service that does its work correctly, every time.

Well, then, let’s assume a global CRO is prepared for technology use in global trials. Unfortunately, this ain’t necessarily so at all. More often than not, a global CRO is in fact a poly-organization, not an integrated one. So their local office (like your local affiliate) should indeed be locally knowledgeable, but there are few mechanisms for this local knowledge to contribute to a single global management sophistication. Much like the false promise of “e-ready monitors”, “global CROs” are global only “on average,” in a very general sense, and it is in the particulars where global trial management matters. Technology is usually the last particular to be learned. Two examples: a famous mega-CRO assured a big pharma that it could handle a complex EDC-enabled global oncology trial, only to supply monitors and local project managers who were EDC naive. In another example, a “global” technology support service had to quote extremely high support prices for a trial because they needed to cover the risks of support in areas where they had never really worked – areas where most pharmas want to be doing trials.

Ok then, find a local CRO, and they’ll take of it. This may well be worse. Most local CROs simply are too small and inexperienced to offer much help in technology application to your trial. Their naivete translates into higher training costs and lower quality. Worse yet are those who offer you their own EDC or ePRO or CTMS tool, which in almost every instance will be missing key quality, performance and compliance characteristics. This is again caused by the fact that the tools were built for local studies, usually post-approval, and usually for a fatally unsophisticated small sponsor.

Non-US investigators won’t use pharma-supplied computer tools. Like the first myth, this could not be further from the truth. Those large pharmas with the most experience in global trials will tell you how the investigators in the least developed countries are the first to push back on sponsors to use EDC, trial and supply tracking, IVRS, and other tools. European investigators, both Western and Eastern, have historically been the pioneers in EDC and ePRO since the early 1990s. Latin American investigators were embracing early ePRO 15 years ago. And now as Japanese-based pharmas seek worldwide registrations, even the assumption that Japanese investigators require Kanji interfaces is no longer true.

Nonetheless, beware the global-is-easy myths also: software is a universal language, so training can be universal. This is not true as applied to the content, language or method. Different cultures demand different training approaches. If you seek to meet the EDC user certification requirement robustly, for instance, you may need to translate your training. In some countries, local regulations are forcing parts of training (like data privacy) to be locally specific. And if “universal training” means “via the web”, unfortunately you are likely to know even less about the true uptake of your training, because the use of English as a second language (or cultural barriers) will inhibit questions by attendees and prevent you from evaluating true understanding.

And then there is perhaps the ultimate myth about technology in global clinical development: using technology will enable me to off-shore my development to solve my problems. Big IT companies and big CROs with lots of dollars at stake are counting on the off-shoring of most clinical operations functions to amortize their off-shore investments, off of your dollars (or euros). But if you can’t execute locally – either in your home offices or in your affiliates under your direct management, what makes you think you can execute 12 timezones away with non-native-English speakers? Talk to the companies who outsourced first, ahead of the curve: they are bringing the business back, because no amount of “follow the sun” technology could replace the burden of long-distance project management.

So what is true among these myths? Global trials are essential, and they are hard work. Information technology is never a quick fix, it is only an enabler, and even then, it is only excellence in management and execution that makes the technology help your global trial work. Go global, not loco. There is no free lunch, no matter what cuisine it is served in. Get past the myths and discover the truths of effective global development, one trial at a time.

“Like the “old” Internet, social networking’s value to clinical development will take some time to realize.”

Given the trendy and transient nature of technology fads, I thought I would try and write about social networking’s potential in clinical research before anyone beat me to it. The potential for the technology platform and principles of use which underlie social networking to empower parts of the clinical development process is definitely strong. Unfortunately perhaps, pharma’s track record in adopting new information technology, in the clinical phase at least, is abysmally slow.

Social networking, for those who don’t have teenagers and are over 35, is the most ubiquitous manifestation of “Web 2.0”, where the Internet takes over key elements of our personal and business transactions in elemental fashion, instead of being only a tool in the corner of the room we take out and use like a super-powerful hammer. Social networking is the generic term for sites like Facebook and MySpace, the latter of which in particular is being broadly exploited by those in need of networking (public relations agencies, job-seekers, politicians, real estate agents), for whom it provides literally an exponential benefit. The concern, for clinical research professionals, as it was with the “old” Internet or any other IT innovation, is how is social networking relevant to our work, how do we properly control its use without undermining its benefits, how do we exploit it in unexpected ways that are directly beneficial to the special work we do?

Superficially, the interface and functionality of social networking sites may seem familiar and crude to a corporate user. These tools supply an email analogue, bulletin boards, news feeds, multimedia sharing, document exchange, and other features which corporate users are used to having in a more silo’ed and structured fashion. For the inventors and initial beneficiaries of social networking, those attributes are secondary – they are handy extras to use on a site which is really designed for, well, networking. This is networking in the sense of “old boy networks”; it’s about creating networks gloriously independent of, and unimaginably more specific than, the “old boys” – a truly democratizing (and at the same time, fragmenting) revolution in connecting people, literally worldwide.

Our colleagues in the discovery side of pharma have been exploiting early forms of social networking for some years, such as sharing “wikis” on various specific topics. (A wiki is defined as “a website or similar online resource which allows users to add and edit content collectively”.) Wikis seek to organize information better than the sharing of “blogs” (usually linear writings of a single person on potentially multiple unrelated topics) or discussion forums (originally called “bboards” in the early days and later “threads” – especially if you were/are a Lotus Notes user). None of these Web 1.0 media contain the basis of social networking’s power: the endless linking, de-linking and re-connecting of individuals around the world at digital speeds based on having something in common.

By its nature, social networking is at first glance very problematic for application to clinical research. Clinical research must live in a regulated environment and adhere to the rules of science, not randomness. While serendipity may be at the heart of most of biopharma’s success in the largest sense, we try to avoid serendipity in the details! But what if this essentially new medium can be controlled or steered in a manner which we can benefit from? We need to learn from pharma’s initial rejection of the Internet (a sometimes vociferous rejection whose echoes can still be heard in the corridors of our companies) and suspend our knee-jerk compliance fears until we’ve explored the possibilities fully. Let’s look at two of these possibilities: patient recruitment and trials management.

Discovering Our Subjects

How is social networking different from a Web portal – a “Web 1.0” concept which is still very underutilized in clinical research? Web portals can have all the same functionality accessible to us through a single screen, albeit only with the design and support of lots of IT resources. Social networking’s distinguishing characteristic for us, in this context, is its “discovery” component. Discovery goes beyond the Web 1.0 concepts of “push” (subscribing to news feeds to your desktop) and “pull” (EDC, to use a clinical research example). A recent Wall Street Journal news item about social networking developments gave a great example of discovery: a new Indian restaurant in the suburbs used MySpace and the town’s “network” to discover who had listed Indian food as something they liked. The network was set up in such a way that the restaurant could make itself known to these eager diners, and the result was a level of targeted communication previously impossible to achieve in an open marketplace.

Taking off from this example, an obvious, immediately applicable, use of social networking is for subject recruitment – the most notorious shortfall in clinical research today. Investigative sites, research businesses, academic centers, and CROs can and should all be looking to exploit this new medium to make that essential, informed connection between we researchers and the subjects we require, the patients who can benefit. It is not costly, it is fresh, and the more it is used in daily life, the more likely this can be used in clinical study recruitment. This is much like what happened with the initial objections to Internet-based EDC: the argument that “the study coordinators will never use the Internet” gave way when pharmas realized the coordinators all went home at night to shop on eBay.

But like the “old” Internet, social networking’s value to clinical development will take some time. Fortunately, positive feedback loops in social networking (so-called “viral” networking) operates at Internet speed, so as people tell other people that listing a medical condition or disease interest on Facebook (or wherever) leads to rapid contact with new therapeutic opportunities (in clinical trials), more people will include this information in their profile (certainly the motivated ones, who are those we are looking for in the first place).

Note that all this does is bring a potential subject to the awareness of the site (but of course, that’s all most any patient recruitment scheme does). All of the rigor of informed consent, protocol inclusion/exclusion criteria, and proper site procedures and approvals will still apply. Subject protection and study design rigor are not affected by the magic of MySpace, but making the first step faster and more efficient would be a great boon.

Communicating with Our Faces

Maybe, although not necessarily, social networking will prove to be a more used (usable, accessible, worthwhile) means of communication in clinical trial conduct, at all levels: sponsor to subject, investigator to subject, sponsor to investigator, and more. And perhaps this technology or format will be more useful internally at pharma as well, replacing more static or IT-maintained study portals for the study team. As always, all of these audiences need both general education (on the disease, on the study protocol, on procedures) and news (status updates, alerts to changes, good developments and bad, progress and performance metrics). This is what needs work before social networking makes sense for clinical research: we aren’t dating or job-hunting, we’re trying to learn. Can social networking help us learn? Maybe so.

Is a social networking “wall” better than a dashboard for communicating study metrics? Intrinsically, from a technical standpoint, it is probably worse, but if people use it more – read it sooner, report to it sooner, gain insight from it faster – then it won’t matter. The ultimate value of social networking (in general and in clinical research) will always come to “what’s in it for me”. Since today’s highly complex CTMS’ (clinical trials management systems) are notoriously underutilized at great investment costs, trying something new (and much cheaper) has to be worth the experiment.

The lessons we’ve learned from other clinical IT innovations apply here:

Implementation is more problematic than technology

Getting data out is more valuable than getting data in

Governance and control of how the technology is applied is crucial to success.

I can hear the objections already, so let me list some now. Any tool which adds more email to our day is a disaster. Bulletin boards are filled with recipes and fatuous exchanges about last night’s TV episodes. We’ve already spent years developing “e-Rooms” full of “shared” documents no one is reading. Absolutely true. The only point of social networking is if its unique dimension adds more value than it destroys.

There are subtler implications of social networking that pharma may not enjoy. At present, most sponsors have to help sites find patients for studies, sometimes at considerable expense in advertising and other forms of outreach. If social networking makes it much easier for sites to find patients, is this another way that the power relationship between sponsor and site shifts away from the sponsor and to the site (like EDC shifting data possession to the site)? And there is already tension between patient self-advocacy on the one hand, and the scientific requirements for rigor on the other hand. Will the heightened level of information (and misinformation and disinformation) that social networking generates aggravate these tensions and interfere with successful research?

These are just some of the questions that must be answered before we know if this latest manifestation of technological creativity can be the catalyst for the quantum leap in clinical research performance that the 21st century needs so badly. Our space, our book, is far from full or finished; what is the power of endlessly connected people?

A current business buzzword seems to have increasing relevance to the relationship between clinical development functions and information technology departments: “transparency”. More and more, we hear clinical operations functions complain that they aren’t getting the information they need from IT or data management. We hear the same from data management about IT, or IT about clinical operations, for that matter. Each of us is the one who’s hard-working and well-meaning, and it’s the other guy who’s withholding information we need. If there is one message each group can agree on, it’s that “I can’t see you.”

Opaque and Obstinate

How does perceived opaqueness stand in the way of clinical IT? In at least four areas: Communication, Planning & Management, Requirements, and Performance. In each area, despite their diverse business impact, the underlying sentiments are common:

I don’t understand you

I don’t want you to understand

I don’t want you to know what I know

I don’t want you to judge us

I don’t think you are helping me

I think you are withholding what I need

I don’t trust you.

These are powerful sentiments, fundamental to human interaction, and turn what should be “only business” into the personal. What are we being opaque about? In the following examples, I will pick on IT, but with a little tweaking, you can apply them equally to IT’s customers in data management or clinical operations.

First, clinical groups will complain that IT is being opaque about, well, information technology! “I go to them and ask for something simple (sic), and all I get is a lot of technical mumbo-jumbo back”. Indeed, at a conference I once attended on the nature of professions in society, the very definition of a “profession” was proposed as “something which one group knows that everybody else doesn’t,” and it was pointed out that it was essential to a profession’s success to create a language (a vocabulary) which was impenetrable to those outside of the profession. IT professionals are masters of this technique (as are pharma’s physicians, scientists, statisticians, and regulatory affairs experts). So as in the famous line from the film Cool Hand Luke, what we’ve got here is a failure to communicate.

Second, and quite different, is the lack of transparency around the deliverables that groups are expecting from IT. For any given project, often as not, IT’s customers feel they have little or no visibility into progress, timing, potential risks, unforeseen stumbles, and the ultimate completion date. Closely related to this, and more inflammatory, is the question of how much something will cost, or how long it will take. The typical consequence of this opaqueness, driven by that list of sentiments itemized above, is a stalemate across the conference room table:

ClinOps is waiting for a set of reports to be programmed out of its CTMS tool, and IT says, “mumble-mumble-technical, so it’s not ready.” When will it be ready? “As soon as we can! – don’t you trust us?” Well, since you ask, no.

At worst, it ends in a game of executive “chicken”, where we find out which VP is more powerful (or cares about us) that week.

Opacity extends deeper, into the nature of the deliverables we are expecting from IT. Let’s take the example of requirements for a new software application. IT asks for our “requirements” and we (think) we tell them. The process IT uses for determining these requirements, prioritizing them, and applying them, is often unclear to the requestor – especially if the results of the requirements gathering aren’t recognizable to those who asked for it.

Support services for IT applications is another common source of opacity. Again, the technology’s users think it is obvious that what is required is to have any and all of its questions answered whenever they have them. The fact that this might not always be possible is somewhat acceptable – life is imperfect – but the reason for this imperfection escapes us. The procedures, capabilities, scope, challenges, obstacles and costs of providing near-perfect support is opaque; only the shortfall in performance is clear. And who’s to blame for the opacity? Generally speaking, it is the service provider who has the responsibility to explain themselves, no matter which side you are on.

All of this can be summarized as an opacity of performance. Common IT performance issues, such as meeting commitments of schedule and budget, or maintaining network uptime, or Help Desk response time and accuracy, cannot be understood if the reasons behind the performance shortfall are opaque, or if the expectations are unreasonable, or if (most typical), the communications come to a mistrusting standoff. This opacity itself is the worst performance of all.

Transparent and Cooperative

What should IT (or ClinOps, or data management, if they are the guilty ones) do to make themselves visible? In many organizations, the dilemma of transparency is increasingly known but seems intractable: the connection between performance and trust is inseparable, and seemingly unfixable once it has descended into a dark negative loop. But misunderstanding is also a fundamental cause, and surely this is approachable, and redeemable.

We talk about international culture gaps freely, with justifiable sensitivity, but the interdepartmental culture gaps are somehow an unspeakable embarrassment, a source of angry stonewalling, something to be kept in the closet. And this does no one any favors. We can start by translating our professional vocabularies, and then move to comparing our everyday vocabularies – what does “on-time” or “commitment” mean to you? What does “easy to use” or “soon” or “expert” mean?

Most importantly, we need to open up our worlds to each other. Have you been to a store, or airline counter or hotel check-in desk these days, where the salesperson stops staring at their flat-panel computer screen, and turns it around to show you what she or he is looking at, as a way of explaining what you are buying (or why your plane is late)? It’s a rare but marvelous experience. The sharing is so unexpected that mistrust evaporates in an instant. That’s the power of transparency. Perhaps we should all, literally or metaphorically, turn our laptop screens around to face the person across the conference room table. Instead of stubborn confrontation, perhaps we can share our business secrets and see our common ground.

It’s baseball season again and I can’t help but use a baseball metaphor to highlight two disturbing trends in clinical IT adoption. Consider base running: the art of it (after hitting the ball in the first place), is to run “through the bag”, i.e., don’t slow up as you get near it so you can be thrown out by a strong infielder, and don’t overrun the bag so that you get picked off for going too far. Many sponsors are in danger of both errors, on the same play, by thinking too far ahead while not finishing the work they have already started.

How does this metaphor apply? Our current shortfall in successfully implementing useful and reliable clinical IT applications is a failure to run through the bag: we buy the software, we design an incomplete implementation, we run out of funding just short of the end – out at first base! Now think of the time you or your strategy staffers are spending dreaming of the intersection of pharma research and the world’s infant-state electronic health records: you just overran the base – out at first again!

Stopping Short

Despite what many executives might have been told, or senior middle managers sincerely believe, the usefulness and reliability of many clinical IT installations (EDC, CTMS, AES, ePRO, data warehousing) is consistently disappointing. It’s not to say that these applications and services are not working, or even that sponsors are not deriving value from them. But the shortfall between promise and potential on the one hand, and actual execution on the other hand, is remarkable. There are many examples:

–Adverse event systems whose report programming is still too complex

–ePRO instruments which take too long to translate into multiple languages

–EDC vendor project managers who understand little about clinical trials or the account they are serving

–Document management tools which require weeks of training and legions of “super-users”

–Clinical operations departments using multiple tools with pieces of the same data entered over and over again

–Safety departments who don’t trust their AES tools

–EDC users who simply buy the vendor’s services and change nothing internally, and are surprised that things go wrong.

The use, or disuse, of enterprise CTMS systems is probably the most egregious example. Walk into any company using a large-scale CTMS application and the refrain is the same: “yes, I enter data into the application every Friday like I am supposed to…but do you want to see the Excel spreadsheet I programmed that I really use to run my trial?” That enterprise CTMS in a big company cost hundreds of thousand of dollars and staff hours in configuration and training – why aren’t people using it for real work? Because these applications, originally conceived with good intentions, have long since left operational reality behind. Part of it is because it is so hard to develop a single program for trial management which meets all the diverse needs of the industry. Part of it is because the enterprise tools are all based on something other than clinical research: sales force automation, managing construction projects, financial portfolio management, investigator site payables, or generic workflow mapping. But ultimately it is we users, as purchasers of these tools, who allowed such disappointing outcomes. Examine how you are using your CTMS now, and compare it to the demo you first saw, or the requirements you first developed. Isn’t it remarkable that such an expensive and complex product does so little for you, after all that time and money?

Data warehousing and mining, the successor to our CDMS’ across the industry, is another example of clinical IT anticlimax. Go behind the conference presentations and you will find that little evidence of truly successful and complete data aggregation and data integration that these projects originally promised.

Indeed, there are so many examples that it makes one wonder whether there are inherent flaws in the thinking behind our clinical IT projects, or in their management, or in the vendors supplying software and services for them. Some common flaws come to mind:

–we do not know how to balance conflicting needs on the basis of operational practicality instead of team politics

–we do not budget sufficiently so that the project can “run through the bag”, so that we can’t afford the cost of configuration and training, and fixing mistakes and re-training

–we are impatient with multi-year projects and we are running too many such projects simultaneously

–we don’t dedicate to the project our best staff polymaths, who have the essential combination of operational, technical, interpersonal and leadership skills to keep the project focused and see it through.

What is common to both the CTMS and data storage stories is highly instructive: value has been derived, and good things have come from these projects, but in deep disproportion to the investment required. The most successful of these implementations recognized at some point (consciously or not) that, for instance, just getting everyone’s opinion on the investigator’s address and phone number in one single place in the enterprise is a useful step forward. Or that being able to make the simplest query across multiple EDC standalone trial databases begins to make up for killing off the CDMS dinosaur.

Success is in Simplicity

In the present state of clinical IT, vendors must supply, and users must demand, more business-useful functionality and improved levels of service. At the same time, the end-users who I am idolizing here are also responsible for the fix they find themselves in. As we try to get the most out of what we have, users must understand that simplicity is powerful and preferable.

We will get much more satisfaction from our service and software vendors if we are able to articulate clearly a reasonable set of functionality. We observed a project recently where a sponsor properly chastised a CTMS vendor for providing an unwieldy, complex tool for report generation. The sponsor proudly announced that they had taken matters into their hands and whittled down their trial status reporting needs to 48 reports! Forty-eight reports! Not a single biopharma employee on earth will read through, keep track of, learn from, or benefit from 48 tracking reports. It is this kind of sponsor-vendor interaction which led to the overly complex software and services we have in the first place. If you cannot manage your clinical trials by tracking far less than even a dozen parameters, you need to revisit your management skills.

Indeed, simplicity is at the heart of many of the problems we have described. If we aim for the fewest patient-reported scales, the best recruiting sites, the fewest fields with the minimum of edit checks on our eCRFs, the “vital few” metrics on CRO performance, then we will have a chance of a) getting a reliable tool or service to deliver what we need; and b) be able to execute our trial programs with greater efficiency and speed. Fewer sites to monitor, fewer datapoints to process, fewer vendors or CROs to manage – these all lead to better operational performance.

Take Back the Dialog

One thing that is clear is that many of those specifically charged with leading the future of clinical IT have left these problems behind them. They have run past the base in their enthusiasm for the “next big thing”, as if the shortfalls described above do not matter or are not recognized. They are chasing electronic medical records, ubiquitous wireless Internet, Web 2.0, SaaS, iPhones, arcane analytics, and every other technical trend. Yes indeed the future lies there, or beyond, and someone should be looking. But perhaps not quite so many of us. You cannot leave this generation’s work undone; if you do you will do just as bad a job when the next big thing shows up.

Our futures are being described by (and therefore, are in the hands of) those who are bored with EDC, CTMS and the traditional clinical IT niches. I will always remember the informatics VP of a big, famous pharma (no longer employed there!) who, having done one EDC study, said “OK, we’ve done that, what’s next?”. Funny, except he was serious, and he controlled the purse-strings. Users must take back the dialog from folks like these. Users are not bored with reliability, with applications that automatically generate the reports they need and make it easy to specify new ones ad hoc, with aggregation of disparate data sources into a single database for their clinical trial, or the integration of their existing, underused applications. There is so much to be done: a Grand Vision is not needed in the industry at the moment, execution is. We have much to gain from the tools (or the raw material for tools) and services that we have already purchased. If you’re bored with these problems, you’re in the wrong business.

By failing to get your clinical IT applications and services to work up to their potential, or by skipping the hard work and only strategizing about the future, you’re out at first base either way. In baseball and in business, it’s execution that wins the game, and it’s hard work regardless. To paraphrase Tom Hanks’ character in League of Their Own, “there’s no skpping in baseball.”

I want to