Clinical Research Technology 2003

It has been eighteen months since this column has reviewed developments among the clinical research IT vendors and their applications. Much has happened since – not so much in terms of technical functionality, but in the configuration of the vendors and the apparent areas of interest among sponsors and CROs.

The state of the clinical research IT vendors remains one of constant change, but in most cases this tumult has had surprisingly little impact on their customers’ ability to derive value from their applications. What is clear from the sponsor community is that, despite a general slowdown in purchasing of all kinds in 2002, the need for updating and innovation in their clinical research IT is stronger than ever.

Markets & Vendors

EDC While there has been steady vendor turmoil in the electronic data capture market, there has also been steady progress in functionality and sponsor acceptance. The percent of trials using EDC is continuing to rise, even though several circumstances mitigate against this trend: the rise and fall of individual vendors, the persistent inadequacies of vendor offerings, the slow pace of internal change at sponsors in order to use EDC properly, and the failure of sponsors to document objectively why EDC is advantageous, particularly in financial terms.

Phase Forward has lengthened its lead in the EDC marketplace since last we wrote, this despite the major challenges in incorporating the ClinSoft CDMS and AES product lines. The “second tier” of vendors all reported acute financial distress in early 2003: CB Technologies filed for bankruptcy, Datatrak was delisted by NASDAQ, and Etrials Worldwide (newly formed by merging Araccel – itself a merger of Technilogix/MiniDoc/Onsite Systems – with Etrials, Inc.) found itself undercapitalized and slashing salaries. This has left some sponsors at a loss as to where to turn, and has given EDC skeptics fuel to fan the flames of EDC’s evanescence. Such observers confuse the management and financial misfortunes of these companies with the value of their products and services; throughout EDC’s history, it has been the immaturity of the vendors and the sponsors trying to use them that has caused repeated corporate failures, not some essential flaw in the technology principle.

As older second tier vendors falter, there is another phalanx of newer vendors ready to take their place. We can only hope they are not sacrificing themselves on the same fatal sword, but instead have learned from those before them. From what we have observed, we are unconvinced. Meanwhile, increasingly we see CROs acquiring, adopting or developing their own EDC tools, and offering them to sponsors wary of having to make a vendor choice. For at least the short-term, this is likely to be a very large source of EDC trials.

There are still too many vendors, but the technology is coalescing around some version of Internet-based tools, with or without offline options, with or without XML, usually with an eye to CDISC standards. While most observers assume the EDC market will consolidate, there seems to be an insatiable desire among entrepreneurs to start yet another EDC vendor. Meanwhile, those sponsors who are steady in their own focus, who are getting their company to understand electronic clinical trials, are moving ahead, with or without yesterday’s vendor.

CDMS It has been striking to us in our practice to see how much interest there is in acquiring new clinical data management systems – an arena thought passé with the advent of EDC. In truth, all of the acquisition situations we have seen always do include EDC as a component of CDM, which is a welcome maturation of both market segments and the industry’s attitude towards them.

The continuing need for upgrading or acquiring back-end data repositories is a reflection of several factors: dissatisfaction with smaller or less robust vendor offerings; the final death of legacy systems, now expiring because of a failure to be 21 CFR 11 compliant (if for no other reason); the growing dissatisfaction of smaller companies (who have outsourced CDM services) with the idea that their data repository is not internal; and the grinding competition facing CROs who need to constantly upgrade their offerings.

In this market niche, Phase Forward’s Clintrial and Oracle’s Oracle Clinical remain the dominant applications, with few new compelling ideas being offered by other vendors except a proposition based on price.

AES Fortunately for the tired IT manager, and lucky for the pharmacovigilance executive, the adverse event tracking and reporting market is highly stable, still being led by the three major vendors – Phase Forward (Clintrace), Aris Global (ARISg), and Relsys (Argus). Since we last wrote, each has enhanced their products to accommodate the new European requirement to report Individual Case Safety Reports electronically using the ICH’s E2B format.

In addition, vendors are offering the external gateway products required to transmit these reports to the European authority according to the ICH’s ESTRI standard. Several sponsors, especially those with joint marketing agreements with other sponsors, are planning to use these standards to exchange safety data with each other.

CTMS No such luck in the clinical trials management software space, which remains the most confused, fragmented, yet critical component of the clinical research IT world. Since last we wrote, many new vendors have offered up applications which serve users all across the spectrum from individual investigators to large pharma planning departments. It is hard to find two applications in this space which cover the same set of users or needs. This is one significant clinical research IT component where companies still seriously consider building their own, and understandably so.

The most commonly used application amongst large pharma, Impact, which had been offered by FW Pharma Systems, a spinoff from a UK applications company, was recently purchased by the Perceptive Informatics unit of the CRO Parexel. It remains to be seen how well this will play out in the market. Siebel Systems, best know for its salesforce applications (“CRM” – customer relationship management), is beginning to make inroads in this space as well, as they try to evolve a custom application into a standard one at a reasonable price. The stock price and financial woes of the parent company may have an impact. Besides these leaders, primarily focused on large customers, sponsors and CROs have a myriad of choices, including designing their own.

EPD The electronic patient diary space shares characteristics with the EDC market (vendor upheaval) and CTMS (different sponsors with different needs). This space is increasingly hard to describe: does one include IVRS (interactive voice response) in the same market as handheld PDAs? Are tools for investigator-administered questionnaires (implemented through Tablet PCs or touchscreen computers) in the same market? How do we categorize specialized little hardware, or wearable devices? Are we talking about “real time” patient experience, patient-reported outcomes without regard to timing, or investigator recording of “soft” patient experience?

With such a breadth of uses in clinical research for soft patient data, one almost faces a scenario of one vendor per niche. In the generally accepted definition of EPD (handheld PDAs to be used by patients outside of the clinic in “real life”), there are a handful of key competitors – invivodata, Etrials Worldwide, PHT, CRF Box, Clinitrac and others – who have all worked hard to improve their offerings over the past year and to keep up with rapidly changing technology. For instance, now that a Palm Zire can be had for under a hundred dollars, the old objection to EPDs that the hardware is too costly no longer applies.

Vendor turmoil plagues the EPD space as well, although less dramatically than in EDC. PHT has struggled for years with very high management turnover; Etrials Worldwide’s troubles were mentioned above, and who knows how this will affect its EPD offerings, which are secondary to its EDC work.

The exciting development in the EPD space is the growing recognition among sponsors and regulatory agencies that a) paper diaries are not reliable instruments, and b) electronic diaries can help sponsors prove things they could never really prove before. This development provides hope that this pocket of clinical research inefficiency may yet be eliminated.

Other Niches

There are at least two other interesting spaces to watch in the clinical research IT market. One is the area which used to be called “trial simulation” or “CATD” (computer-assisted trial design). Companies like Silico Insights, Spotfire, Cytel, Pharsight and Innaphase, among others, are all trying to apply creative conceptions of statistical analysis, scenario theory, pharmacogenomics, and untapped sponsor data to try and refine the preclinical and clinical development program for maximum efficiency and more rapid decision-making.

The other space is much more down-to-earth and mature: that of eSubmissions. Those vendors (usually document management suppliers originally) such as Liquent, Documentum, and CDC Solutions are rapidly adapting their tools to the requirements of the CTD (Common Technical Document).

Sponsors Still Hungry

Despite the economic constraints on the biopharmaceutical industry felt throughout the last 18 months, or perhaps because of them, sponsors remain hungry for improvement in their operational efficiency across the board. Many hope this efficiency can be gained in part through information technology. For every company whose plans have become less ambitious, there is another who is pushing themselves more aggressively to modernize. The projects may take longer to be approved, and their scope may be trimmed back or implementation stretched out, but the march forward is inexorable. Every biopharma still has so far to go in making clinical research more efficient and effective, we will see continuous investments in information technology, as a collateral component of these efforts, for years to come.

The more thoughtful of sponsors and CROs recognize that individual application decisions can no longer be made independently of other application choices. The need for integrating data amongst these applications, reducing re-entry and reconciliation, and gaining synergistic benefits from all this IT investment, are all driving more and more sponsors to try to develop a strategy or roadmap that can rationalize the purchases. This is an excellent approach, as long as the roadmap is iterative and not an excuse for rigidity or political control.

The keys to success in technology adoption remain the same: know why you are acquiring the particular technology; remember that the effort has much more to do with process than software functionality; and get your organization accustomed to a work environment of continuous technology change.

Chicken, Egg, or Just Plain Chicken?

There is much discussion now about the uptake or technology adoption curve of electronic data capture (EDC) and other advanced information technologies for clinical research. Is the uptake of EDC in fact “slow”, as many analysts contend (which begs the question of what should be judged “slow” in the first place)? Or is it instead unbalanced, with some companies leaping ahead and others staying on the sidelines? There are several confounding variables: for instance, use and commitment are not the same thing. We clearly do not know enough about the thoughts and behaviors of the total universe of clinical IT decision-makers to answer why one company is farther along than another. Yet sponsors and vendors alike would love to know the answer.

This situation strikes me as a series of “chicken and egg” arguments. Which comes first:

The technology or the user?

Use or commitment?

Proof of success or experimentation?

There is no question that today’s information technology for clinical research is superior to that of five or ten years ago. And yet companies were adopting innovative technologies for their time fifteen years ago – like remote data entry or third-party clinical data management systems. What made those companies (or individuals) risk-takers? Clearly, today’s exciting technologies, and rapid technology change, are stimulating creative thought among both sponsors and vendors, and without the technology (the Internet being an obvious example), many applications or functions could not exist. On the other hand, notable clinical research software such as Clintrial¢â and Impact¢â were highly influenced in their development by key early adopters. Indeed the involvement of these sponsors was essential to their early success. So which comes first, the technology or the user?

In today’s EDC market, there is a big difference between use and commitment. There are companies who are well-known users of EDC in relatively high volume, yet they are uncertain as to their vendor, technology or strategy choices. At the same time, there are companies who are quite vocal, even at the executive level, about their commitment to EDC, but whose volume of EDC use is still very modest. Can a sponsor ever really increase the use of a technology significantly without widespread management commitment? Can commitment lead to widespread use without someone taking on the hard operational job of actually getting the software implemented? Which comes first?

And then there is the fundamental question of change itself – why and when do some people change behavior when that choice is new and unproven, and why do some people never change? In clinical research IT, we are grateful to those companies, or individual managers within them, who took on new technologies as an experiment, or as an expression of faith or optimism, or because of unusual in-depth knowledge, or because of a recognition that this was the first step on the right path.

Process change in clinical research is plagued, on the other hand, by those for whom no amount of “proof” will make them budge from the way they have always done work. How will the uptake of newer information technologies accelerate if too many companies wait for the proof of success? As we often say to clients, if you wait until someone else proves to you that new technology works, you’re already too far behind: not only has your competitor used the new technology successfully, they have started to learn how to use a new process successfully – a skill every company desperately needs to stay competitive in an increasingly difficult business climate.A recent survey we conducted among top 10 pharma in regards to the adoption of EDC bore out these chicken-and-egg conundrums. Here were ten companies all of similar size, in the same business, doing clinical trials according to the same regulations, in many of the same therapeutic areas and following the same basic principles of clinical research. And yet we found companies who have used some sort of EDC for years and some who still haven’t (and are proud of it). We found companies who have used many vendors and technologies but do not seem to be making progress in committing to EDC as a clinical research pillar. We found other companies whose executives have apparently set very aggressive goals for EDC penetration in total trials over the next 3-5 years, and yet these companies have barely begun the process of learning about EDC and its impact on the trials process.

The companies who refuse to change, or still want to wait before using innovative clinical research IT in the year 2002, strike us as those who are contemplating neither the chicken nor the egg, but rather are just plain chicken. We worry more about those companies with lots of commitment and not much use. Unless these companies get started with these new technologies, in an appropriately organized and well-planned implementation process, their executives will be sorely disappointed. Will these companies then conclude it was the technology’s problem all along, or will they recognize the failure of their implementation planning? On this answer hinges the acceleration of efficient clinical research. It never really matters whether it is the chicken or the egg; it’s the growth of the flock that counts.

Get with the Program!

To one who is of a certain age, the phrase “get with the program!” was an urgent admonition to join the revolution. There’s a revolution needed now, to implement a hardly radical idea: that clinical people and data people should work together to apply technology to drug development.

Why does such an obvious idea require a revolution to adopt it? Why, indeed. When the clinical development process is affected so profoundly, as occurs when implementing new information technology, why shouldn’t everyone involved in clinical development “get with the program”? And yet, at most of our sponsor clients, we find repeatedly that the introduction of process change exposes strong feelings on both sides of the clinical/data divide. Almost always, there are emotions just below the surface that come racing out ¡© mistrust, skepticism, disrespect, power plays, fear, resistance.

These emotions must be dealt with openly and effectively, or the attempt to implement the new technology (and therefore a new process) will have caused more harm than good. Yet few companies have either the will or the skill to overcome these interdepartmental conflicts. Which is a shame, and wasteful of resources, because after all, both “sides” are working toward the same goal.

Certainly, we can understand why clinical affairs folks and biometrics folks are different. Clinical people tend to have a clinical background. They are responsible for the therapeutic science of the candidate product, they deal directly with investigators, and may also have responsibility for the medical evaluation of safety issues or the manufacture and availability of drug supply. Their crises tend to be interpersonal ¡© focused around investigator identification, patient recruitment, drug supply availability, controlling the study budgets, and managing the legion of outsourcers used in trial conduct.

Data people tend to have a biostatistics, database or programming background. They are responsible for the integrity and quality of the data upon which the product’s submission and approval rests. They are responsible for the statistical integrity of the analyses upon which approval hinges. Their crises tend to be technical ones ¡© glitches in the way data has been entered or stored, difficulties in integrating data inputs from third parties, problems with tracking the status of cleaned and verified data. And, therefore, in most organizations, data people are responsible for the software which moves and stores and processes and spits out the information that consummates the clinical development effort.

Looking at these two groups in this way, one can see their differences well, and it is said that knowledge is the first step toward understanding and cooperation. But clearly this is not sufficient, for I am sure all sponsors and CROs would say that of course they understand these things, and of course these groups cooperate effectively or we’d never get anything done!

And yet with just the right trigger, those divisive emotions come to the fore. And technology is a wonderfully divisive trigger. Do these examples sound familiar?

The head of clinical development says her processes need revamping with technology, but does not give a clear charter to clinical operations or biometrics to get the work done. Each go their separate ways. Clinical does some research and brings in a vendor they like; the data management team is affronted because they weren’t included. They think their processes are fine as they are, and anyway, they know data and think Clinical is naïve.

Multiple clinical teams inside a large sponsor pursue various IT initiatives independently, and while they are meeting their individual needs, they risk great inefficiency on an enterprise level. So corporate IT decides to get things “under control”, determine “preferred vendor” lists, and issues proclamations that any technical innovation has to go through them. Clinical is consequently outraged.

Or more simply, one side or the other takes the lead on a project, doesn’t involve the other (or barely does so), but needs the other in the end to get the software used successfully. The implementation process is set back six months while ruffled feathers are smoothed, the uninvolved side comes up to speed, and the vendor has either changed management or issued a new release!

Everybody Get Together

These examples all occur within environments where, in the abstract, the company would deny there is any clinical/data divide. No matter how much team-building has been done or how many interdepartmental off-sites have been held, it seems that clinical and data people are ready to not cooperate when faced with a significant process change. And process change is naturally perceived by all as a lot of work (it is), a threat (it needn’t be), and a distraction (it shouldn’t be).

Companies must make sure they are not just paying lip service to interdepartmental unity. Executive leadership must be held personally accountable for effective cooperation. Equally important, specific understanding of each other’s work processes, such as through process mapping exercises, and specific documentation of work handoffs and responsibilities, can help define precisely the interdependence that will lead to cooperation. In addition, common Metrics to which both sides’ work contributes can be helpful in unifying all of clinical development.

Innovation in drug development processes through software is here to stay. It won’t be successful without your organization crossing the clinical/data divide. Get with the program, and together you can make your work easier and more productive.

Helping the Help Desk

Of the many delightful and painfully true Dilbert cartoons, one of them features “the boss” asking Dogbert why he wants the job of being their network administrator. Dogbert replies, “I don’t like people. This is a good opportunity to annoy idiots such as yourself for my own entertainment”. The boss naturally replies, “Wow. You’re perfect. Can you start tomorrow?” This cartoon captures both sides of the Help Desk quandary: users feel the technologists are out to get them, and the technologists think the users are ill-trained.Helping the Help Desk

Of the many delightful and painfully true Dilbert cartoons, one of them features “the boss” asking Dogbert why he wants the job of being their network administrator. Dogbert replies, “I don’t like people. This is a good opportunity to annoy idiots such as yourself for my own entertainment”. The boss naturally replies, “Wow. You’re perfect. Can you start tomorrow?” This cartoon captures both sides of the Help Desk quandary: users feel the technologists are out to get them, and the technologists think the users are ill-trained.

We all have our stories: the endless wait times, only to find out there is another number to call; or the long wait only to find out your problem is “not their fault, call the other vendor”; or the person who is happy to help but hasn’t been trained on your protocol or software. I’ve personally spent days trying to get “user-installable” software successfully installed. And yet more and more technology is purposefully designed to put more of the support burden on the user, much like the healthcare system discharges patients from the hospital as rapidly as possible and puts the burden of care on the family.

This is one of the not-so-hidden weak spots in the underbelly of information technology, and as we use more and more software applications in clinical research, this object of derision is no longer at arm’s length. Indeed, software is increasingly the work environment for all participants in clinical research, from sponsor employees to sites to patients. As electronic data capture (EDC) and electronic trials management (ETM), or even just web-based connectivity schemes become crucial to trial conduct, the jokes about the Help Desk are going to fall flat.

Common Causes

What are the common causes of Help Desk frustration? As with many implementation issues, it often begins with a lack of awareness on the customer side, and insufficient resources or maturity on the vendor side. Poor planning results in unclear definitions of who is supposed to support what. What are the responsibilities of the software vendor (or network services vendor) and what are the issues the sponsor must (and should) support.

Help Desk plans must anticipate the levels of support required and who and when calls are escalated. A common failing is that so-called “third-level” or even “second-level” support is handled by the vendor’s engineers. Too often, these engineers have neither the time nor the training to be handling user problems when they are also programming the software’s next release!

There are other causes of Help Desk failures. Implementation planning must be sure to include the unexpected — indeed, the unexpected is the essence of what a Help Desk is designed to solve. Too often, help desk staff are trained simply in the same material the user is trained in, instead of the vendor and user getting together and applying experience and anticipation to imagine the problems users are likely to encounter. And then there is staff turnover to consider — even if the initial training is adequate, if there are no provisions for handling changes in the Help Desk staffing, then problems will assuredly occur.

Some empathy is in order. A day on the Help Desk can be excruciatingly boring, punctuated with very occasional calls of high crisis, either real or unnecessary, with a very upset caller. Help Desk staff, while having to meet the necessary technical requirements, must also be able to work effectively interpersonally in these unusual conditions.

Issues to Resolve

There are also some service issues to resolve. Do you need a Help Desk which is multilingual? If so, what languages are really needed? Do you need knowledgeable support available across multiple timezones? Do you need a Help Desk available to answer questions “24×7” (24 hours a day, 7 days a week). It’s easy to ask for this, but it may be expensive and counterproductive, so you should challenge your assumptions heartily before proceeding.

Very important to EDC support is the difference between support for the software and support for the protocol. Certainly most sponsors want software calls to go to the Help Desk and clinical questions to go the CRA or Project Manager. What will you do when a clinical question comes to the software Help Desk (and it will), or vice versa? These contingencies and their resolution need to be articulated clearly.

Possible Solutions

There are several things that can be done to help the Help Desk. First, a clear service level agreement (SLA) must be negotiated and written between the parties, which should spell out all expectations, responsibilities and escalation procedures. Second, your vendor and perhaps your own Help Desk should use one of the many available off-the-shelf software packages for call tracking, including an issues database that all parties can learn from. Third, if you decide neither you nor the vendor can provide adequate support, there are third-party businesses established to provide Help Desk support on an outsourced basis.

Importantly, the CRA also has a potential role to play, especially when the site is using EDC or trials management software. As the sponsor’s most visible and personal representative, the CRA can nip site frustrations in the bud through reassurance and advocacy. This means that CRAs need to take a special interest in and responsibility for the functionality and performance of software which involves them. It implies a more proactive role than being just another user, and while it may seem like an extra burden to the already burdened CRA, it is also both self-protective and job enhancing.

In another Dilbert cartoon, Dogbert is now manning the Help Desk phones and tells a caller, “I’m the new ‘No Help Whatsoever Desk’. My job is to make sure you never call again.” Our job is to help make sure that first, calls to the Help Desk are indeed infrequent, and second, when they do come in, the user is truly helped, quickly and accurately.

We all have our stories: the endless wait times, only to find out there is another number to call; or the long wait only to find out your problem is “not their fault, call the other vendor”; or the person who is happy to help but hasn’t been trained on your protocol or software. I’ve personally spent days trying to get “user-installable” software successfully installed. And yet more and more technology is purposefully designed to put more of the support burden on the user, much like the healthcare system discharges patients from the hospital as rapidly as possible and puts the burden of care on the family.

This is one of the not-so-hidden weak spots in the underbelly of information technology, and as we use more and more software applications in clinical research, this object of derision is no longer at arm’s length. Indeed, software is increasingly the work environment for all participants in clinical research, from sponsor employees to sites to patients. As electronic data capture (EDC) and electronic trials management (ETM), or even just web-based connectivity schemes become crucial to trial conduct, the jokes about the Help Desk are going to fall flat.

Common Causes

What are the common causes of Help Desk frustration? As with many implementation issues, it often begins with a lack of awareness on the customer side, and insufficient resources or maturity on the vendor side. Poor planning results in unclear definitions of who is supposed to support what. What are the responsibilities of the software vendor (or network services vendor) and what are the issues the sponsor must (and should) support.

Help Desk plans must anticipate the levels of support required and who and when calls are escalated. A common failing is that so-called “third-level” or even “second-level” support is handled by the vendor’s engineers. Too often, these engineers have neither the time nor the training to be handling user problems when they are also programming the software’s next release!

There are other causes of Help Desk failures. Implementation planning must be sure to include the unexpected — indeed, the unexpected is the essence of what a Help Desk is designed to solve. Too often, help desk staff are trained simply in the same material the user is trained in, instead of the vendor and user getting together and applying experience and anticipation to imagine the problems users are likely to encounter. And then there is staff turnover to consider — even if the initial training is adequate, if there are no provisions for handling changes in the Help Desk staffing, then problems will assuredly occur.

Some empathy is in order. A day on the Help Desk can be excruciatingly boring, punctuated with very occasional calls of high crisis, either real or unnecessary, with a very upset caller. Help Desk staff, while having to meet the necessary technical requirements, must also be able to work effectively interpersonally in these unusual conditions.

Issues to Resolve

There are also some service issues to resolve. Do you need a Help Desk which is multilingual? If so, what languages are really needed? Do you need knowledgeable support available across multiple timezones? Do you need a Help Desk available to answer questions “24×7” (24 hours a day, 7 days a week). It’s easy to ask for this, but it may be expensive and counterproductive, so you should challenge your assumptions heartily before proceeding.

Very important to EDC support is the difference between support for the software and support for the protocol. Certainly most sponsors want software calls to go to the Help Desk and clinical questions to go the CRA or Project Manager. What will you do when a clinical question comes to the software Help Desk (and it will), or vice versa? These contingencies and their resolution need to be articulated clearly.

Possible Solutions

There are several things that can be done to help the Help Desk. First, a clear service level agreement (SLA) must be negotiated and written between the parties, which should spell out all expectations, responsibilities and escalation procedures. Second, your vendor and perhaps your own Help Desk should use one of the many available off-the-shelf software packages for call tracking, including an issues database that all parties can learn from. Third, if you decide neither you nor the vendor can provide adequate support, there are third-party businesses established to provide Help Desk support on an outsourced basis.

Importantly, the CRA also has a potential role to play, especially when the site is using EDC or trials management software. As the sponsor’s most visible and personal representative, the CRA can nip site frustrations in the bud through reassurance and advocacy. This means that CRAs need to take a special interest in and responsibility for the functionality and performance of software which involves them. It implies a more proactive role than being just another user, and while it may seem like an extra burden to the already burdened CRA, it is also both self-protective and job enhancing.

In another Dilbert cartoon, Dogbert is now manning the Help Desk phones and tells a caller, “I’m the new ‘No Help Whatsoever Desk’. My job is to make sure you never call again.” Our job is to help make sure that first, calls to the Help Desk are indeed infrequent, and second, when they do come in, the user is truly helped, quickly and accurately.

Return to Science, Return to Intimacy: Re-Connecting Site & Sponsor

There was a time, before most of us entered this profession, when drug research was done in an atmosphere of great intimacy between physicians — one who happened to work at the pharmaceutical company, and the other who usually was an old friend and colleague at a major teaching hospital. There were many things missing from this style of clinical research, there have been many major improvements since those days, and certainly no one is going back to that simpler, less sophisticated, less controlled and perhaps more dangerous time.

But many of the drugs and therapies we have long since taken for granted were developed in just this manner. And most importantly, several dramatic clinical pharmacology discoveries were made in these times, precisely because the physician researcher was personally seeing the trial patients, and was in close communication with his professional colleague at the sponsor. An observation, a phone call, a return to the lab, a new protocol, and all of sudden a lousy antihistamine becomes the prevention for seasickness.

How can we recapture the best of that atmosphere — the possibilities for scientific interchange that it embraced? I can’t count the number of investigators who have told me, “I miss that dialogue with the sponsor’s physician. Now all I see are young CRA’s who don’t know the disease and every visit there’s a new one who shows up, and we start the education again.” Of course there’s no question that clinical research is a business today, but business and science need not be incompatible. And today’s information technology, applied correctly, can be the answer.

IT Can Transform the Sponsor Site Relationship

Let’s look at some examples of how IT can improve the sponsor-site relationship. One of the most onerous interactions between the parties is the CRA’s site visit. It certainly isn’t intended to be unpleasant, but it often consists of hours of tedious document review and questions for CRA and study coordinator. Electronic Data Capture, a key clinical research technology initiative now increasingly accepted and practical, can reduce this pain by 80%, and turn adversaries into colleagues. While CRA visits may be of a similar frequency using EDC, the CRA can focus more on her scientific role, and have more time to discuss patient experience on the drug and disease management in general.

Electronic trials management (ETM) tools can significantly improve the sponsor-site relationship. By providing automatic and timely reporting of patient recruitment performance to the sponsor, ETM helps eliminate “nagging” the site for information. Through ETM reports on site quality, sponsors can review and reward strong performing sites in an informed manner. ETM and web-based “portals” can also provide a secure and focused channel for electronic interchange of questions and ideas in an appropriate manner. In today’s rapidly changing and highly competitive landscape, site insights need to be benefited from as soon as possible.

Electronic Patient Diaries (EPD) are another example of information technology contributing to the science of clinical research. Their ability to capture real patient experience on a drug enables sponsor and investigator to explore clinical questions never able to be answered before.

Creating Scientific Intimacy

Communication channels enabled by web portals or simple organized email can create sincere scientific exchange outside the trial context. Given sufficient value, physicians are active Internet users, and if a sponsor crafts a communication channel void of commercialization, all kinds of valuable dialogue will ensue. Not only will this help a sponsor’s marketing (the usual way in which a sponsor thinks about web channels), but such an effort also creates an informed community. Sponsors can see who is interested and what they are interested in, who has the patients and who has clinical insight. Sites will get connected to each other and find out who’s thinking about the same questions they are. They can get rapid access to the latest information, and have an opportunity to influence the direction of pharmaceutical research.

This scientific intimacy will be particularly important to the new wave of pharmacogenomic research. Physicians’ clinical insight will be the trigger for companies targeting genes that can lead to tailored or safer drugs. Instant, organized and analyzed communication with these physicians will provide important competitive advantage. Physicians willing to share this insight will demand high value information in return.

There is something of an “odor” around web portals and communities these days, the victim of over-ripe hype. Don’t let the Internet morning-after hangover obscure the value of this basic enabling technology to your research process.

Overcoming Selfishness

The key to any intimacy is overcoming our self interests. It’s OK for sponsors to think about most IT in selfish ways: how it saves them money in running their clinical research factory. But it’s also OK not to be embarassed to say that science is still important. Today’s technology tools can make it easier, faster and cheaper to restore the dialogue, and even perhaps the serendipity, that makes drug research unexpectedly and dramatically beneficial. And that’s a selfishness we can all share.