Waife & Associates » Archived Columns

13 Feb 2007

Clinical Research Technology News (Winter 1998)

Vision Quest

This year, 1997, may be a turning point for clinical research technology, much as it is for technology in general. In the information technology marketplace, the twin impact of falling hardware prices and hyper-attention on the Internet is changing the way some companies view the role technology can and should play in their enterprise. We in clinical research look at these same trends and wonder what potential advantage may be in the offing lower costs, greater efficiencies, realization of long-delayed promises?

The possibility of the new is juxtaposed to the failing of the old. Familiar software vendors in the clinical research marketplace are weakening, merging, or failing. These failures reflect the nature of our marketplace: clinical research is specialized enough, and yes, small enough, that product vendors cannot profitably survive. Only integrators or custom developers, carefully managed, can really provide the value solution clinical research customers require. “Off-the-shelf” software can be enormously valuable; what we need to figure out is how to nourish those companies of value sufficiently to ensure their building blocks are available for us.

New companies are emerging, which may represent real value or may simply be instruments of new technology the Internet “hammer” looking for some “nails” to hammer flat. The test of real value ultimately lies with us, the users and designers of systems which enable clinical research to be done faster, more efficiently, with better quality.

In this turmoil, we need vision to bring us to a useful path. Vision can come from us, or from the vendors, or perhaps from both in concert. Vendors in our industry for the most part have been consistently technology-driven, rather than product-driven, meaning that users need to work hard to adapt their products to their particular real-life situations. New technologies like the Internet, or groupware, or Java, mean more product “push” and less application “pull”.

The best assurance that your use of technology will be successful is the creation of a pragmatic, comprehensive vision of what the value of your business or function is, how it needs to evolve in the next decade, and the right tools to realize that vision.

Some pharmaceutical service organizations are beginning to demonstrate the creative and useful implementation of technology for their customers. Some CROs and SMOs already have, or are in the process of implementing, strategies which will help with inter-company communications, timely status reporting, patient recruitment, document retrieval and transmission, and the collection and cleaning of clinical data.

Research sponsors are also slowly beginning to realize that they have a responsibility to lead the process of improving clinical research for all. Bringing electronic data collection or clarification tools to the site community is a good beginning. Much hard work has gone into international standardization efforts, and the FDA’s leadership has been invaluable in the U.S. in ensuring that technology can accelerate the submission and review process. What we need is a parallel effort to reduce the enormous inefficiency in the industry where each company (and each department in each company) has its own, distinct, immutable ways of collecting essentially similar or identical data for each trial.

An industry vision, rather than a vendor vision or a company vision, might be helpful. An example which we are beginning to discuss is the creation of a “Clinical Data Utility” a means by which today’s more ubiquitous wide-area networking, less expensive hardware, easier connectivity, and appropriate software functionality could be combined into a universal service for gathering and cleaning clinical data from investigative sites. This could provide efficiencies at least as powerful as what we are beginning to see in electronic submissions, and significantly improve the operations of all participating investigative sites.

A clinical data utility is just one example of the greater vision we need in applying technology to the clinical research process. All of us have the potential to contribute, in a year of technology turmoil.

Implementing Technology, Part I: Critical Success Factors(1997)

13 Feb 2007

(Below is the Column from the Winter issue, January 1997)

Implementing Technology, Part I: Critical Success Factors

The theme of this column is that information technology will be a primary source of competitive advantage for sponsors and sites in the coming years. But before you go out and buy some software, you should have a good understanding of your primary business objectives, how you do your work today and where are the major sources of delay and cost, where technology can help and what the options are, and how to evaluate the vendors who will become important players in your business.

Critical Success Factors: Know Your Business

Table I lists what most system professionals agree to be the critical success factors for implementing new information technologies. The first success factor is to understand how the proposed use, or felt need, for a particular technology application fits with the overall business strategy of your company. Some projects may be pursued because they are someone’s favorite idea, or because competitors are using it. But if your business doesn’t have a critical need for it, there may be some other application more important for you. For instance, if you work at an investigative site whose business depends on enrolling patients on a timely basis, it may be much more important for you to deploy a patient recruitment application than a clinical data repository. On the other hand, if your site specializes in a therapeutic area with a large and stable patient base, you may not have a compelling need to computerize your patient information and your IT opportunity may lie elsewhere.

Table I.

Critical Success Factors

For Implementing Technology

Put technology use in the context of your competitive advantage

Analyze your business processes — workflow and dataflow

Discover and document your process costs — in time and dollars

Leadership: top-down and bottom-up

Involve your users up-front, and train them well

Know your politics

Know your people

Build an adequate technology infrastructure

Use cost-effective prototyping

Commitment & follow-through

Having identified an important application area, you need to understand what it is you are computerizing — often referred to as process or workflow analysis. Process analysis at a relatively high level can help you understand what part of your operations are the most resource-intensive, and therefore perhaps most likely to benefit from technology. Let’s say you work in a clinical monitoring group at a pharmaceutical company: it is likely you will find considerable time is spent in cleaning and clarifying data on CRFs.

Then you need to look more closely at how that data cleaning process works — who hands off to whom, how many people are involved in each step, what are the physical or virtual distances between them, how long does each step usually take? To each answer, challenge the situation — ask why, repeatedly.

It may also be revealing to determine if the people involved in the process understand it themselves. Often we find that even in a small organization, people make assumptions about their work – what is a priority, what their “internal customer” needs – that turn out to be incorrect.

Process effectiveness is particularly crucial in clinical research as critical functions are increasingly outsourced, often to multiple players. A clinical development project may depend the most on how well you coordinate and integrate the various vendors, service providers and internal departments who participate.

Ideally, you can quantify process steps, and entire strategies, in terms of their dollar cost to your company. Very few pharmaceutical companies have made the commitment to understand the costs of how they operate. This can mean that you assume a particular technique or process is effective, perhaps because “it’s always been done that way,” without knowing what it really costs you. If you can benchmark your performance against those who do similar work, you will have some context in which to compare your findings.

Leadership

Implementing a new technology application can have powerful effects — good and bad — on an organization. The success of the project often comes down to leadership: from the top, bottom and middle of the organization. One can debate endlessly about whether top-down or bottom-up initiative is more powerful, or long lasting. Of course both is ideal. When a project is led from the top, you have the advantages of financial commitment, management oversight, and perhaps strategic alignment. But a project led only from the top will fail because actual application users will not see the need, or perhaps actively resist the initiative.

Within large pharmaceutical companies, we often see a technology initiative begin with a middle-level manager. The advantage is that she may have some discretionary funds, whatever she does will be necessarily small and therefore unobtrusive, and she is close to the real users and the real need. Where technology initiatives have failed is that this manager doesn’t articulate the strategic benefit of what she has demonstrated to her boss, and the project does not get further funding. This is another reason why every technology project must keep in mind both the end user’s needs and the corporate strategic advantage.

Whether top-down or bottom-up, a successful technology implementation project needs an internal champion. They are the ones who infect others with their enthusiasm and persevere over inertia. The most important role of the champion is to clone herself: sometimes a project fails when the champion leaves the scene, and no one else had really bought into the project.

Politics

Internal corporate politics & personalities can have a great influence on technology implementation. We have often seen technology projects delayed for years because of interdisciplinary rivalries between data management, clinical monitoring and biostatistics, or because of competition or conflict between therapeutic areas at a large company. This is where the internal champion can have a great impact. Often, by involving the source of greatest opposition into the project early on, the team can defuse the objections and these folks become your strongest advocates. Many times when implementing electronic data collection at an investigative site, for instance, we’re told of a study nurse who would “never” use a computer. Yet they end up the staunchest defenders of the concept because they are on the frontline of operations where the technology can best help.

Nonetheless, there is no doubt that implementing technology changes people’s roles in the organization. Electronic data collection, for instance, changes the role of the data manager, the CRA, the CRC, the investigator, and even the patient. Change of this nature can be threatening, or seem illogical, or put a person “out of their depth” based on their professional training. These changes need to be documented and openly discussed, and alternatives should be explored which respect the current and future contributions of each staff member. Involving end users in the project early on, and taking special care in their training, can do much to alleviate these concerns.

Examples

Why have I spent so much time on this “touchy feely” topic in a technology column? Because time and again it has been painfully proven how important people and process are to getting the business benefit out of new software.

Here are just a few examples from the experiences of companies beginning to implement electronic data collection (EDC):

The data is collected electronically at the site, but field monitors don’t have the electronic tools to review the data, so they revert to paper.

EDC is implemented by a sophisticated site with an electronic patient chart, but the sponsor’s clinical department insists on 100% source data verification on paper.

A clinical team is ready to pilot new EDC software in a small trial, but the QA department insists on a full system validation audit first.

A company deadlocks on technology implementation because one therapeutic area leader enthusiastically proves EDC is beneficial while another equally energetically rejects it.

The sponsor’s project team has worked for months to develop an EDC application they all think is great, but nobody obtained input from an investigative site and the application fails under real conditions.

In Part II of this article, we’ll look at the other critical success factors: building a technology infrastructure, and prototyping your solution, and suggest some cost-saving strategies for exploring and implementing technology in clinical research.

Waiting for Bill(1997)

13 Feb 2007

Waiting for Bill

Ambivalence may be one of the defining words of the late twentieth century. And it is particularly appropriate in describing the feelings of many clinical research professionals towards using computer technology in their work. We know we need to use it, we know it’s going to be great some day, but we wish it wasn’t so hard to get there.

At recent industry meetings, including The Executive Forum on Technology held in March, participants have expressed this ambivalence loud and clear. And ambivalence, as a psychologist knows, leads to frustration, anxiety and inaction.

If we divide, in a simplistic way, the universe of site-oriented clinical research software into two large constellations — trials management and electronic data collection — the ambivalence is clearly stronger regarding the latter. This is not to say that the choice of trials management IT solutions is clear (it depends entirely on each organization’s needs), but rather that there is considerable agreement on what functions need to be automated and integrated, and how. The primary questions in this constellation are: what platform do I use for trials management (the Microsoft products, Lotus Notes¢ç, Oracle)?; and do I adapt off-the-shelf applications or build my own on top of application development environments? Bruce Schatzmann describes the approach his company’s product takes in the first article following.

Ambivalence is much greater in the area of electronic data collection. One need only survey the many different processes sponsors have used to employ EDC (forgetting about the different technologies for a moment). Should data be entered directly into the computer at the bedside? Should the coordinator enter it daily or weekly? Should the sponsor or CRO’s CRA enter the data at the site? At the office? Can patients enter their diary directly?

Each player in the EDC process chain also has his or her ambivalence. The sponsor worries about putting “yet another” PC on their investigator’s desk. The CRO doesn’t want to do anything their customer might think is too innovative for their trial, or that might burden a trial on which margins and deadlines are already tight. The site is nervous about investing in its own technology for fear the customer will not approve. The article following from Quintiles tells us one story of “RDE caution”.

And yet, at the same conferences alluded to previously, it is clear that it is no longer a question of “should we” use EDC but “when” or “how”. The issues are not easy, and yet several large sponsors are now quietly making significant investments in EDC technology. And the large site networks are closely examining the process, quality and cost benefits of using “electronic source document” to empower their businesses.

When ambivalence reaches a peak like this, often we all wish “someone” would solve this dilemma for us. This syndrome I have called “Waiting for Bill”, as in Bill Gates. I’ve heard more than once the wish that Microsoft would come in to the clinical research arena with some dominant, cheap (partially annoying and undoubtedly buggy) product which would solve this ambivalence for us. It is tempting, and may yet happen; this issue is attracting business interest. In a more modest manner, the article by Rebecca Kush suggests how important it is for the industry to try and establish some standards in this area.

I suggest that each of us must evaluate, develop and implement technology solutions that provide tangible, short-term benefits within our own worlds, and try to solve the universe’s problems to the extent we have the time, goodwill and resources to do so. By all means, we need to avoid choosing solutions which one can easily predict will run afoul of a more standardized universe (choosing an obscure programming language, or a product architected for the wrong industry, for instance). The use of technology in this way is “self-justifying”, and at least in the short-term, does not depend on Bill or anyone else to decide how we are going to do our work. While we are waiting for Bill, the world will pass us by: other companies will beat us to market, other investigators will win the opportunities to research tomorrow’s therapies.

Implementing Technology, Part II: The Technology (1997)

13 Feb 2007