Is That an Edsel or a Porsche that Just Pulled Up?

Does everyone remember the Edsel, the big-nosed, problem-plagued Ford named after the company chairman’s son? While we would never mistake such a car for the latest Porsche 911, many of us live in fear that we cannot tell which best represents the clinical information technology that just pulled into our driveway for a test drive. This is more than an amusing metaphor: it stands between us and the future of more efficient clinical trials. The choice is not so simple when shouldering the responsibility of processing the data upon which your company’s future may rest.

What’s the Problem?

Technology innovation is proceeding at least twice as fast as the clinical research industry is adopting it. Is that a problem? For the vendors, yes. For the sponsor who wants to be innovative, possibly. For the industry as a whole, not necessarily. Innovative sponsors must understand that the technology they saw at the wireless Internet tradeshow yesterday is not available as a clinical research product today. Cautious sponsors must understand that vendors, by their nature, will pursue the latest technological advance. Vendors must understand that the clinical research industry, by its nature, will take its time in changing its ways. Quite a dilemma.

Your old car (paper-based clinical trials) isn’t necessarily a bad car. It gets you where you want to go. When you put enough mechanics on it, you can lock a database in 48 hours. You can “get there” (choosing effective investigators, keeping track of trial progress, storing the program data, preparing submissions) well enough. And if not well enough, well, the pain you know is not worse than the perceived pain of change.

On the other hand, the Porsche sure is pretty out there in the driveway — why not buy it now? Well, for one thing, the technology seems to change weekly; the best solution may be just around the corner. And anyway, there are too many vendors, too many choices, all nearly the same. Plus, you don’t have the resources to evaluate what’s out there, understand your internal status quo, or manage the project. If that weren’t bad enough, you don’t have the budget, or even understand how the Porsche should be paid for.

So, fine, why not keep the old car? For several important reasons. You know you can do better. You’ve got much farther to travel, much faster, with more passengers, than the ol’ buggy can handle. Your staff don’t want to drive it anymore (or don’t know how). Your mechanic won’t fix it anymore; the dealer closed. Your competitor bought the Porsche, and then he moved to a better neighborhood.

Why should a clinical research organization adopt leading-edge IT? Because you probably have:

the need for high-throughput capacity

the need to retain your employees

the need to stay competitive.

Besides, the Porsche is a better car. It has many usability and efficiency advantages. It enables you to do things you could never do before. It leads to better, exciting uses of technology, by providing a platform for information integration, and therefore higher usefulness of that information. Great, but we usually feel we cannot afford to be wrong — we can’t risk that Porsche turning into a latter-day Edsel.

Control Over Risk

Sponsors, properly, want control over risk. But they do not have enough resources in IT or clinical operations to handle change management, work process change, project management, IT infrastructure issues, metrics, SOPs, and all the other requirements for successful application implementation. What is the answer? There are several possibilities.

One answer is to “stage” innovation. Think carefully about all the choices in front of you. Which is more important – your CDMS or your Data Warehouse? Which is more important — study startup or data cleaning?

Another answer is to use Metrics, and use them properly. Sponsors too often apply old technology or paper metrics to electronic processes. The result is that metrics targets are set unreasonably, out of context with a baseline (because the baseline is unknown!). Knowing your current performance (through Metrics) is essential to knowing where the innovation is worth the pain of implementation.

Another answer often assumed to be clever is to offload much of the difficulties onto the Vendor. Here you need to be careful: are you creating an unhealthy dependency or a controlled one? This strategy does provide opportunity for flexibility, if properly controlled. This comes back to the issue of internal resources. Perhaps a third-party can help by “being you”, virtually.

Understanding Vendors

The more enlightened and savvy vendors in the clinical IT marketplace understand many of the dilemmas you face, to a certain extent. An answer to control over risk which they have come up with is the “rent” or “lease” business model, which in a way puts them in a role sponsors feel they can recognize — a CRO-like model, where the vendor does everything and “just” delivers the data or information. This may be acceptable to you, but it can also be dangerous: it permits you to avoid real process change, so the real benefits of innovation are not achieved. It also leaves the vendors in a potentially fragile position, where they can be tossed aside at any moment. And yet vendors are very interested in this model. In today’s marketplace, where all vendors need to attract funding from investors, bankers or the public markets, they need to have both growing current income (usually at unrealistic rates), plus recurring revenue of some significance. The rent/lease model is the result.

Does It Matter?

Over the next 5 years, maybe we shouldn’t care so much about the strategic adoption of clinical IT. Perhaps it is sufficient for individual “champions” within sponsors to get their projects to use innovative IT-based processes, and succeed or fail individually, while core functions remain “safe” in (increasingly) old technologies and processes. Once the road is “clear”, you can crystallize operations around the proven path. But will it ever be clear, or do we instead have to learn to be ever-changing?

The pressures on clinical development are likely to overcome this “safe choice”. The pace of clinical IT change is very different from that of drug technology change, or the pace of change in how your company markets its products. You can’t stay isolated even if you wanted to: the lines are blurring between Development and Discovery, and between Development and Marketing, and you in clinical research can’t be pushing paper around in the middle.

What Should We Do?

We need to accept that business life means constantly changing (and investing in) technology. Learn to live with it: create a change management culture in your company. Control risks through knowledge — especially of yourself: your costs, your strengths and weaknesses. Understand that process change is the more important critical success factor — more important than the technology platform or the vendor choice.

So is that an Edsel or a Porsche in the driveway? You can’t wait to find out, because by the time you know for sure, there will already be a better car idling outside. In the end, you have to get out there and drive. Worst case, if it turns out to be an Edsel, it’s still faster than walking. In the best case, you will have created a stimulating, more efficient, more competitive, and more attractive work environment for clinical research in your company.

The Skeleton in the Closet

What’s the biggest problem in conducting clinical trials today? That question would make for a lively debate! Readers of this column will assume I will point to data cleaning, or trials management. But there is a skeleton in the Clinical Operations closet, a problem we all have but rarely do much about. It’s an insidious cause of delay, enormous financial cost, frustration and inefficiency. I’m talking about patient recruitment.

Every one of you know patient recruitment problems wreak havoc on nearly every clinical program. In a survey conducted by our company, executives reported at least 50% of their trials encountered “significant” delays, with an average delay of 110 days ¡© nearly four, costly, months. Obviously, the more complex the protocol, the more rare the disease, or more broad the claims sought to be proved, the situation gets worse.

What was distressing in our research was the almost universal lack of proactive planning at sponsors to anticipate patient recruitment problems and the appropriate interventions to correct them. Nearly everyone admitted that recuitment problems were treated exclusively in “rescue mode”, in a crisis mindset. And yet, going in, we already know we’re going to have problems half the time.

A Growing Problem

Patient recruitment is likely to become an even bigger challenge in the near future because of:

the huge increase in drug candidates to be tested, driven by improved discovery techniques and genomics (“gene-tailored” drugs are likely to mean that multiple variants of the same compound need trials, on populations genetically screened)

a continuing increase in the number of trials, number of patients, and complexity of trials per compound, driven by global registration, multiple indications, drug interaction concerns, and the seeking of a competitive labeling edge

more and more players (SMOs, enrollment consultants, AMCs, managed care, CROs) seeking to mine the same well-known pool of patients

more and more compounds tackling new, harder-to-reach patient populations.

Diffuse Responsibility

Aggravating this problem is the diffuse responsibility for patient recuitment. When it comes to data cleaning problems, for better or worse most companies can point to their data manager and demand an answer. In many companies,

the responsibility for the performance of patient enrollment is diffuse, in the hands of managers with many other responsibilities of which enrollment is just one. Indeed, many players may get involved in helping (or not) with patient enrollment, which leads to lots of “helpers” but no single accountability.

Public Controversies

Another compounding factor, perhaps short-term or cyclical, is the recent media publicity about possibly inappropriate incentives for investigators to accelerate patient participation in clinical trials. Although the obvious ethical violations reported are reprehensible, they represent a very small proportion of trial experiences. But this public scrutiny is likely to make more skittish the pharmaceutical customer who is already under-utilizing initiatives to accelerate enrollment.

Public controversy over the privacy of patient records is also likely to dampen enthusiasm (at least publicly) for the mining of patient databases for proactive patient recruitment. But this public debate will also likely help define the conditions under which such research is acceptable, which in the end will make the use of such resources easier and more accepted.

Today’s Inadequate Solutions

The methods for improving enrollment turned to in rescue mode by most pharmaceutical companies are first, financial incentives, and second, various forms of advertising. Begun when the crisis is already in full bloom, these initiatives are inefficient by definition. While sophisticated advertising (the type of intervention most commonly thought of and offered when people think “patient recruitment services”) can play an important role in reaching and motivating potential subjects in a responsible manner, these media approaches address only the last of four steps to improving patient recruitment:

First, design a protocol with a realistic chance of enrollment!

Second, pick sites who have proven they can recruit effectively

Third, know who the sites’ patients are and reach out to those who are appropriate, and

only Fourth, motivate appropriate candidates as required.

The Role of Information Technology

Well, what does this have to do with technology? A lot, as it happens. In the earliest stages of the problem, the new computer-based intelligence being applied to protocol design in various approaches may be very helpful. There are much simpler uses of technology that can help here, however; for instance, using groupware to distribute, edit, iterate and close quickly on the protocol outline. This in itself, with very little cost, reduce weeks from clinical development time.

Patient recruitment problems reinforce the Site-Centric view (as distinct from the CDM-Centric view) of clinical trials data processing that this column has continually advocated. By getting closer to your sites in all ways, including through data, you can gain confidence in and improve their ability to execute the recruitment plan. In turn, sites who concentrate on building tighter connections to their patient community (instead of on acquiring each other), will be more useful to the industry.

Information technology is the obvious underpinning of both of these points — getting to know in a meaningful, evaluative way, which investigators can responsibly deliver on what they promise; and knowing your patients well enough to use highly cost-effective outbound calling to contact interested subjects likely to meet the trial criteria. For instance, if you simply tapped the knowledge within your company (in a quick and timely fashion!) about the performance of investigators you yourselves have used, you can fight off that product manager who insists on using the high-profile thought leader with the terrible enrollment record.

In the near future, the industry will be putting great energy into figuring out how to responsibly use existing patient databases. And the Internet, while so far quite disappointing, according to our research, in having a meaningful impact on trial recuitment, does promise exciting possibilities as disease communities and other virtual patient pools form on the Web.

Patient recruitment is a source of at least as much delay as data cleaning. If you’ve got EDC on its feet and down the road, it’s time to pull this other skeleton out of the closet and acknowledge “yes, we have a problem.” It’s always the first step to recovery.

Technology 2000

As we start the new decade it is a good time once again to review the technology landscape in clinical research with a focus on available solutions and vendors. There has been a rapid turnover in companies, company names, management teams, and financial investments in this area. Sponsor adoption, on the other hand, remains on a more steady course, gratifying in its acceleration, but still cautious and evaluative. There is no question that every player in clinical research biopharma, CRO, SMO, site, lab are all more committed to information technology than ever. Many are seriously seeking how to use technology for competitive advantage.

This pace of adoption is still outflanked by the sweeping changes in technology platforms and application functionality. But the gap is smaller between innovative supplier and innovative adopter. The result enables us to shape a picture of where technology in clinical research is being used in 2000, with whom one can more safely do business, and the expected benefits, at least until the next IT revolution sweeps over us.

EDC

While my company has been preparing the Sixth Edition of The EDC Report, we are struck at the incredible turnover in the companies seeking to deliver electronic data capture solutions. Literally dozens of companies (or at least their names) have come and gone, and at least a dozen new companies have appeared in the last year. The disappearances are due to failed execution (in product vision, in marketing, in management), but particularly due to a poor understanding of your needs and where you need to go. The new companies are driven mostly by the seeming ease of creating applications with Internet technology; it enables one to produce a pretty nice product shell very rapidly, but there is a long way from that demo to a viable clinical trials data partner.

As the Internet is adopted with surprising speed by nearly all business sectors, the inevitability of using it as a platform for conducting clinical trials is becoming more accepted, not the least by the FDA itself. “The Guidance”, i.e. 21 CFR 11 as it now exists and its proposed amendments, has validated the EDC approach and eliminated an important regulatory objection for sponsors and CROs alike.

Two things remain important for readers to consider: a) when do you need to use EDC and how should you prepare yourself to use it effectively?; and b) are your vendors exhibiting the ability to execute, and do you know how to handle it if they don’t? Organizational preparedness for EDC is more important for you to spend time and resources on than staring endlessly at vendor demos.

Some of the current crop of vendors in EDC are demonstrating meaningful leadership in Internet-based solutions, and now even traditional CDM vendors have products which are likley to be quite useful for their customers. Many other new vendors have come out or will soon do so and may be worth a look.

CDM

While most sponsors have made their difficult choice for a third-party CDM already, choosing sides in the Domain vs. Oracle Clinical war primarily, many CROs and SMOs are still catching up, believing they need to move away from simply delivering SAS datasets to having a relational DBMS in-house. This may or may not be true. Sponsor-oriented CDMS’s require a major internalization effort; EDC tools, with their data repositories, libraries of design elements, and coding dictionaries, may obviate the need for a CDMS at the CRO/SMO level.

Meanwhile, the significant development is that all three major vendors are all offering Internet-based EDC tightly integrated with their CDMS’s. As of this writing, these products are all in an early release state, but the significance of having an Internet EDC tool written by and within your CDM vendor’s framework is a powerful option to consider. The question is whether a CDM vendor can learn the site-centric focus and per-trial business model that makes this successful for you and them.

EPD

As long-time advocates of exploiting the use of handheld devices for Patient Diaries, trashing the totally unreliable paper-based method of patient-recorded data, and designing new studies never before possible on real patient experience, we are gratified to see the explosion of new Electronic Patient Diary vendors, driven primarily by the low-cost/high-function platform provided by Palm OS and Windows CE machines. EPDs are a highly significant advance in clinical research, both investigational and post-launch. Several companies are taking a more public stance as EPD companies specifically, while several other new companies, primarily formed for EDC, also tend to mention they have EPDs as well. But patient diary trials are a specialty unto themselves, and it may be best to first talk to those who have experience with them.

ETM (sponsor/CRO/site)

Electronic Trials Management remains the most underserved yet critically important application area in clinical research. Much less progress has been made on this front in the past year. No new sponsor-side tool which would be easier to use, more valuable to individual staff, and well integrated with other sponsor systems has yet been released. There are a couple of solutions on the site side and they are planned for enhancement. Again, EDC vendors come into play, because they usually represent the most recently developed product vision, and several of them offer a modicum of ETM functionality and “intend” to offer more. CROs/SMOs remain the forgotten niche ¡© they are the companies most in need of a comprehensive system that merges sponsor and site project management concerns with tools that help them run their unique business. This niche apparently remains too small for a pajkaged product to be developed for CROs specifically; custom development remains the best option.

How would like to pay for this?

The issue most troubling to vendor and customer alike when it comes to clinical research IT these days, is how would like to pay for this? Both sides are foundering in a sea of alternatives and it is not clear to anyone where we will land. Should we pay for this (be it EDC, CDM, EPD or ETM) per user, per enterprise, per study, per “click”? Presumably one pricing model will not fit all. But I cannot exaggerate the importance of finding an answer to this question. The survival of the vendors that you need to be successful, that you need by your side to handle the throughput in clinical research today, depends on a clear understanding and articulation of how you should reasonably pay for and budget for these systems. For all the good work industry and vendors have been doing cooperatively on data standards, I am certain that answering the pricing question is much more important to the future of clinical IT.

When Bad Things Happen to Good Software

Software has such power over our daily work life it commands our eyeballs and frustrates our souls that we are eager and joyous when something goes wrong. Finally, an outlet for our frustration! We yell at Help Desks, stick pins in vendor dolls, and send flaming emails to colleagues warning them of impending disaster.

I am entirely sympathetic to this attitude. I suspect that most software applications developed for clinical research are receiving this treatment as I write, and yet, I must admit they may not always be fairly criticized.

These days, there are a fair number of clinical research applications which, while not perfect, are probably pretty good. Good enough to carry significant process improvement on their backs; good enough to be deserving of wider adoption. Many things hold them back, including industry conservatism and poor vendor management, but the problem is probably not really the software.

The Avoidable Failures

So-called enterprise software, the kind used for mission-critical applications like data management, data collection, document management and submission, trials management, and knowledge management, is complex stuff. Most “enterprises”, by definition, approach their work somewhat differently, and further complicate matters by asking that these applications be adapted to their specific circumstances. Opportunities abound for failure.

How is this failure manifested? We hear of users not using the software, managers who can’t get the reports they need, installations which take way too long to finish and cost too much. We hear of hardware failures and network failures. We hear about Help Desks that can’t help, and training programs that don’t teach. We hear about multiple enterprise applications, each underpinning the operation of one particular department, that can’t talk to each other (neither the applications nor the departments!). We hear about applications carefully specified, acquired and implemented that lay dormant for years, unused and unbudgeted. We hear about cautious “pilot” implementations which fail fantastically, sinking all previously held expectations.

These are the failures we gleefully whisper to our colleagues, and in a flash, everyone in our intimate industry knows the score: another piece of software bites the dust.

Is all this failure necessary, deserved, or inevitable? I suspect most of it is not. Most of it is certainly not the fault of the software, some of it may be the fault of the vendor, but much of the fault lies within us in how we handled the research into, specification of, planning for, and implementation of that application.

Examples

Let’s look at a few examples.

A company implements a worldwide trials management system. It has lots of marvelous features (for management) which all depend on the timely and accurate input of data from users (not management). Management pounds on users to get that data in on a timely basis! For our reports! But the application does nothing for the user: it doesn’t make their job easier, in fact it makes it more onerous.

A pilot trial is designed to test the promised time-to-market savings of an EDC application. Because the company is afraid to use EDC in a “real” trial, it chooses a Phase I study. The result? No particular time saved an easily predicted result, since EDC’s substantial benefits accrue best in studies stretched across many sites, patients and visits. Nonetheless, the project team will report that EDC brought no benefit.

A company using a third-party CDM application thinks it’s got the support process figured out: it forms an internal Help Desk to field questions from its users first, with the intent of filtering the harder questions to the vendor’s Help Desk. But the vendor and the company haven’t really mapped out the process flow on this, and in any case mistrust each other deeply. The result? Savvy end users do an end run around their less-trained internal Help Desk and call the vendor Help Desk, who is under-manned with higher level engineers not expecting this flood of simple questions. Accusations fill the air like migrating geese.

These are bad things happening to good software. The fix is what we call “organizational preparedness” the responsibility of the buyer to understand what’s in store when they bring in an enterprise application: how their processes will change, how their employees’ roles will change, how to manage the vendor’s resources to ensure success. Often, vendors are ill-prepared to anticipate these needs, but usually they can respond if given a clear idea of what help is needed.

Shakespeare, of course, anticipated software and its problems: “Men at some time are masters of their fate. The fault, dear Brutus, is not in our stars, but in ourselves” (Julius Caesar). Do not go into the Forum of software implementation without being better prepared than your predecessors.

Out of Control

Our recent work with pharmaceutical sponsors has revealed a painful reality: too many clinical research departments are not in control of the technology that is their lifeblood. Clinical research today depends on a wide array of computer applications. Clinical data management, trials management, adverse event reporting, electronic data capture, and document management are just the high-level names. Underneath each category, in most companies, is a myriad of mini-applications and separate databases that never talk to each other. This creates that state most humans abhor: not being in control.

The recent Clinical Operations Retreat of The Clinical Research Executive Forum drove home this theme. When technology was discussed by clinical executives from nine pharmaceutical companies, the disconnect between the users of applications, and the design and management of those applications, was universal. What are the implications of this, and what can be done?

What does it mean to be “out of control” of your clinical applications?

The symptoms of this problem are legion. Consider if the following sound familiar to you:

your applications are hard to use

you don’t see the relevance of the application to your daily work, and therefore underutilize or ignore it, crippling its value and timeliness to the enterprise

you were oversold on the benefits of the application, which don’t match reality

you have too many new applications being implemented at once and you are desensitized to the next “top priority”

your priorities differ from those of corporate IT

different versions of your applications migrate forward, and no longer integrate (if they ever did)

your workflow is poorly understood and the application is a mismatch

you’re gathering data you don’t need and nobody uses

the vendors providing the applications can’t support your real-life situations, especially the scale of your worldwide operations

with the use and respect for the applications failing, you don’t have “real” (i.e., “true”) data, and therefore lack the “true” information on which to base decision-making in a timely manner.

How has this situation developed?

The primary cause of applications out of control is the “silo” structure and attitudes common in most companies. Although pharma has responded to this situation in the overall development process by universally moving to the interdepartmental “project team”, this spirit is rarely carried over into operational issues. Thus we see disconnects not only between corporate IT and development, but within development, between data management and clinical, and even within clinical, between monitors and medical staff.

Some of these causes may sound familiar to you:

the corporate IT perspective does not match the business unit need

IT (or data management) considers software applications their exclusive arena

users (including Sites!) aren’t consulted during requirements development, vendor selection, and rollout

clinical groups are too busy to provide input, or to take the time to learn new applications properly

vendors don’t recognize the internal problem at their customer, and don’t contribute to the solution (few understand real-life clinical operations)

users lack the computer expertise which could reduce dependence on other departments and assert requirements and feedback.

In addition, there are challenges to controlling software applications that are not due to interdepartmental gaps:

technology is always changing

resistance to change (on all sides)

executive skepticism (because of a history of failures or lack of financial justification) leading to under-funded implementation, staffing and training

company politics

company policies which are not adapted to the changed process created by the application.

What can be done?

What is out of control must be brought in control. The cases we have heard where some progress has been made on this issue all contain a single element: the clinical department establishes dedicated staff, liaisons, or better yet, a department, who is in control of clinical research IT. This department ideally is separate from data management (where it often lands), so it can represent a superset of interests that encompasses clinical, data management, regulatory and IT. This department’s charter is to empower the clinical development organization to properly and efficiently use technology to speed their work. The staff therefore needs both clinical and software expertise, and the executive must have direct line reporting to, and support from, senior management.

Other initiatives are also critical. Users must be taught how the information they are providing will be used ¡© why it is important to the business, and what they will get out of it. Hardware and network issues should not be forgotten. And vendors should be chosen as much for their understanding of clinical research as for what features their software has.

A clinical IT department is not a cure-all of course. Some of those who have had such departments for years complain of similar problems, because the group has become as out of touch with the user community as an outside department would. So for those who have these departments, renewed emphasis must be placed on bringing users and technologists together, preferably with the user having the final say. Through cognizant, visionary leadership in top clinical positions, these fatal gaps can be bridged. The investment in clinical IT applications is huge and growing. It is such a waste to see them out of control.