Bigger isn’t better, smaller isn’t better. Only better is better.

The past year has seen considerable turmoil in the vendor spaces generally considered “clinical IT”: EDC, CTMS, ePRO. While there continues to be new vendors (which in the EDC space is somehow miraculous), the notable occurrences have been changes in ownership and/or near bankruptcies. For those of you not keeping score at home:

• Oracle, now has not one but two CTMS’, having inherited Siebel’s eClinical as a side-effect of the Siebel parent acquisition (their other CTMS being the acquired SiteWorks).

• PF acquired a collection of what marketers call “line extensions”, including LabPas for Phase I studies (the company was called Green Mountain Logic), and Clarix for IWRS (interactive web response), plus announcing various partnerships for imaging and such.

• Parexel (under the Perceptive Informatics umbrella) acquired ClinPhone, which gave them a trifecta of overlapping new stuff: like Oracle, they now have two CTMS’s (they already had IMPACT, and ClinPhone brings the very recently acquired TrialWorks); a second attempt at EDC (the old Datalabs, also very recently acquired by ClinPhone; SiteBase being Parexel’s first EDC go-around in the 1990’s); and of course more IVRS/IWRS capabilities, which was what Perceptive already offered, in addition to imaging.

• Meanwhile, Datatrak and etrials have their stock values teetering on the edge (again), while lots of new EDC players fearlessly turned a blind eye to history and entered the market fresh.

The question for clinical trial professionals, all of us increasingly dependent on the software made by these vendors, is, does any of this matter? In theory, of course, it matters very much. And even in practice I think it can matter; the question is whether it matters positively (as the “new” vendor incarnations will assure you), or negatively (as skeptics will automatically and unfairly assume). Let’s look at why it may or may not be good for you.

The Good

Merging eClinical vendors brings the potential for several improvements in clinical research IT:

• The more individual application niches (EDC, CTMS, IVRS, etc.) that one company owns software for holds out the hope that these tools can finally be meaningfully, functionally, integrated – a nirvana devoutly sought by all.

• Moving beyond getting current software to talk to each other, one company covering multiple niches could actually develop tools offering completely new functionality exploiting all the features we need from a singular design point-of-view.

• Bringing software under one roof could bring improved account servicing and coordinated project management.

• Fewer vendors is probably better, especially in the EDC space, considering the resources vendors commit to hacking their way through the forest of today’s multitudinous vendors.

• Theoretically, the acquirer is financially stronger, has more feet on the ground, and is administratively more competent.

• More revenue to the acquirer should further strengthen the acquirer.

• Sponsors look favorably at larger vendors as being more stable, long-term partners (although the average large trial budget is much larger than the annual income of almost any eClinical vendor).

Overall, the advantages of these mergers are mostly speculative, and so far we’ve seen more good intentions than tangible benefits from any of the moves in the eClinical marketspace.

The Bad

Few companies in any industry do mergers and acquisitions well. There is a myriad of personnel issues, financial structure compatibilities, product line clashes, strategic differences, executive egos, geographic considerations, and pricing turmoil which accompanies every such move, and clinical IT vendors are not immune. Most of these problems have plagued every clinical IT company maneuver in the past decade. A handful of companies have emerged stronger, albeit usually despite their suboptimal handling of the problems, while a larger number have been severely handicapped. So as new moves are announced, sponsors should view them first with trepidation and many, many questions.

Readers could flood the phone lines with their personal experiences dealing with newly merged or acquired vendors. And unfortunately these experiences are not speculative or theoretical, as the benefits are. The problems range from confused sales presentations, as product decisions twist in the wind, to serious stumbles in product strategy. Those who are closest to the customer – salespeople and project managers – are usually the most likely to leave for a more stable environment or be let go if they are substandard. And while this may make sense to the vendors, it hurts their customers the most.

But the worst of the merger mania is the false hope it creates that things will be different – that vendor performance is somehow by definition improved by being bigger and acquiring additional talent. This has not proven to be true. Instead, the biggest complaint of clinical IT users is that the owners comes and go, but the problems remain: poor project management; poor product quality:

• The project managers change often, and the new ones are not well trained

• The software has a fatal performance error in some obscure but critical, unexpected spot in the workflow, and the fix is months in coming

• Data goes missing, or those easy ad hoc reports are rocket science after all

• Pricing seems irrational, mysterious, opaque, and by default therefore, too high.

It’s nearly 2009, and this performance is simply unacceptable. And at no time has a larger, or re-financed, company made a difference in these ongoing flaws. Indeed these flaws continue to be exhibited by all clinical IT companies across the spectrum of size, age, nominal experience, or self-proclaimed innovation.

The Ugly

In the Sergio Leone film of the same name, the “ugly” characters were not necessarily “bad,” and so too the results of these vendor mergers and acquisitions might be good but ugly, or ugly but good when the film ends.

What continues to be ugly is the project management skills of the software vendors. Why does this matter to a software vendor? If they can get the product out the door, so what? Ah, but most software in the clinical IT space is offered in “ASP” (application service provider) mode. ASP services create the steady revenue stream and customer dependencies that build attractive public companies. So while vendors always say they are ready to support customer in-house adoption of their software and vendor independence, they are actually loathe to see it happen.

Clinical research IT vendors really do seem to be understanding the software functionality part of their business (something not true in the 90’s), and if they just stayed software vendors, that would be fine. But they, like CROs and consulting companies, are all hungry for the outsourcing dollar, greatly encouraged by biopharma’s willingness to budget and spend those dollars. So the money is coming in way ahead of the skill development, and this is where it is really ugly. Software vendors have not had the time, understanding or inclination to build the clinical development skills or basic data management/trial management expertise to execute reliably. One has to wonder if they should back off of what they don’t really know and let the industry they serve do what they (presumably) know.

What Are You Going to Do About It?

As always, sponsors are intimately entwined with the good, the bad and the ugly. Sponsors need to become much more savvy about what to expect from, and how to manage and monitor, their software vendors. They need to think hard about the cost of outsourcing in all its dimensions (full-service, EDC study builds, CTMS report writing, ePRO logistics, and everything in between), and not just assume the benefits are captured in moving around budget line items.

Sponsors can help the newly merged or expanded vendors greatly. I have long argued that in the small world of eClinical information technology, sponsors need to pick vendors and nurture them, not just sit back and excoriate them when they fail. But as the years go by and the vendors continue to come and go, these choices of whom to nurture, and when, and why, and for what, become harder and more mission-critical.

As enterprise decisions get made, necessarily, by enterprise-level managers, the decisions, necessarily, are made that much farther away from the front lines. Executives and professional contract managers think they are signing on a CRO partner when they pick a software vendor, and decide on the basis of similar criteria (or should we say instincts, or platitudes?). Unfortunately, while clinical IT vendors may try to sell to pharma customers as if they were CROs, theirs is actually still a software business, with engineering on the inside, wrapped in a shell of a very special kind of project management. And so these vendors survive by seducing an unprepared level of decision-maker, sticking the operational staff with the consequences.

Of course the vendors also have much to account for. They should be doing much more about the effectiveness of their internal operations in management across the board, in project leadership skills, in honest and timely communication with their customers, and so on. Like most mergers in all industries, little time or money is spent on the critical need to evaluate staff skills and workflow processes carefully for the best in hand. Vendors shouldn’t brag about these ownership changes if they don’t really know what has happened to their product, staff, or service capabilities.

What should be clear to anyone making a decision based on this generation of newly merged or emerging vendors is this: bigger isn’t better, smaller isn’t better. Only better is better. It still remains a case of caveat emptor, and we emptors have a lot to be wary of.

We all know how important it is for clinical research organizations to have well-developed, clearly documented, standardized procedures (SOPs), with supporting technology, in order to conduct our business effectively. Despite SOPs often being derided, we don’t think anyone would disagree that these procedures and systems are a key part of ensuring that a sponsor’s clinical development and drug safety complies with regulatory and ICH requirements and standards. Equally importantly, SOPs and technology documentation serve as the backbone for training clinical research personnel, governing the day-to-day activities of each functional group within the organization.

Increased regulatory scrutiny (or the promise thereof) has further pushed the focus on SOPs, with information technology often playing a key role in facilitating and enabling this compliance. However, the interpretation of what “compliance” exactly requires can become lost in translation; the lengths to which some groups have gone to comply with regulations may become counterproductive, and at times even unnecessary. One might call it….obsessive.

Some clinical research groups make Herculean efforts to achieve a perceived level of quality in their work that, in the end, actually surpasses any true need or business benefit. In fact, rather than addressing a real need, adopting over-burdensome, unnecessary quality assurance procedures can actually create more problems by decreasing productivity, creativity and personal responsibility for quality work. Tied to that, of course, is the way that technology can be used (or mis-used) to enable this unhealthy focus on perfection. Indeed, information technology is often a prime forum for misplaced quality obsessions. Not only do quality assurance professionals often misunderstand the meaning of essential concepts of technology quality (like “systems validation” and “21 CFR 11 compliance”), but quality can be misused in ways which obstruct technology acquisition and implementation (and return on investment) without justification. Most disturbing of all is that IT professionals themselves, in some biopharmas, are witting accomplices to these misjudgments.

When bad things happen…

When you look at the SOPs that certain functional groups have developed, you can’t help but wonder if some event happened in the corporation’s “childhood” to make them almost obsessively concerned with achieving perfection – to avoid mistakes or errors at all costs. This past experience may trigger what we’re calling “Obsessive Quality Disorder”. Perhaps an organization can experience the same kind of reaction to a negative experience (for example, receipt of an FDA Notice of Violation or Warning Letter) as an individual or a family experiencing a life-changing trauma. The parallels can be instructive.

For an individual or a family, the reaction to a negative experience can take many forms. One example is when children revert to a younger stage of development in reaction to a family transition or crisis. For example, a family moves to a new town, leaving many friends behind. Immediately or shortly after the move, the four-year-old daughter starts to have temper tantrums, something she has not done since she was two. If parents are insecure, they will create more of a problem by becoming overly reactive and anxious. They might miss the obvious connection between the geographic move and the regression, and instead look needlessly for more complicated explanations and solutions.

In personal psychology, the problem can go further. The definition of Obsessive Compulsive Disorder (“OCD”) is when people have repeating doubts about whether a situation is safe. People with OCD respond by obsessing often about whether things are orderly and symmetrical. In order to reduce the anxiety that bad things my happen (again), someone with OCD will act in compulsive ways by creating rituals (“policies and procedures”) that are meant to keep the feared event at bay.

The parallel corporate behavior shows up in clinical development. For instance, clinical data management departments might respond to an auditor’s observed deficiency by putting elaborate, cumbersome procedures in place to guarantee this “traumatic event” (the observation) will never happen again. Departmental subgroups might be added to implement these processes, and organizational charts end up ballooning to accommodate a new workforce devoted to ensuring (obsessively) that no step in a given process will ever go unverified.

Drug safety departments in particular are susceptible to embracing highly-detailed, complex and redundant procedures that focus on ensuring “quality” (which they translate into “compliance”). It’s not unusual to find personnel in these groups spending an inordinate amount of their day checking, double-checking and sometimes triple-checking what someone has already done before them in the process, with no other justification than “assurance”.

If one is able to investigate the root cause of this behavior, the phrase you find that best summarizes things is: “we don’t trust them” – “them” being either another department, a subordinate, a partner company, or even the co-worker sitting in the next cubicle. This subliminal atmosphere of mistrust and pursuit of perfection can actually negatively affect individuals’ performance, when people are constantly in fear of being “caught” making an error.

This is also where “OQD” is most disruptive to technology innovation. Very expensive, resource-consuming clinical IT projects have been delayed for months or years because of the inherent mistrust we are describing. It is not technical design, vendor failings, or even resistance to change among users which ultimately delayed these projects, but rather an intractable mistrust based on equally well-meaning but dysfunctional motivations.

Road to recovery

When an organization has obsessively over-treated a problem, the first step to “recovery” is to recognize that a problem or unhealthy situation exists. Taking a big step back and re-examining a department’s process isn’t always an easy thing to do, especially when there is a set of beliefs about quality that has been deeply ingrained within the organization.

Equally difficult are situations where those in upper levels of management are not willing to re-consider that procedures are overly “quality burdened”. In these instances, a significant effort by correctly empowered personnel need to help upper management re-examine the big picture, and find the balance between responsibility and fear.

One way to find the right balance is to use the wisdom of the people who actually do the work to create the solutions, rather than imposing something on them from other departments or from on high. When solutions are co-developed with the people who carry them out, there is generally more buy-in and better outcomes. This is most dramatic when comparing the mindset of an auditor or even an IT department liaison to that of the actual user of the process or technology in real work.

Prevention is better than intervention

Healthy companies, like healthy families, are able to respond to problems in a secure, reflective way, looking at the strengths and abilities of the people and systems that are in place, capitalizing on them, and adding only practices which are necessary to perform correctly, or use their energy for innovation. Healthy personalities are willing to make changes, even dramatic ones, which are consistent with the end goals, but give up on short-term targets that are no longer useful.

Regularly re-examining your department’s approach to quality is important to ensure that some level of “Obsessive Quality Disorder” isn’t unnecessarily preventing IT innovation and other efficiency initiatives intended to improve compliant clinical research. A little family therapy can go a long way to helping your company’s productivity.

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