Biopharma executives regularly face a series of decisions beyond their original professional competency. This is a requirement for biopharma executives’ success and I imagine therein lies much of the appeal of the job. In all 21st century management, decisions are accompanied by choices in the use of information technology, and this is no less true in biopharma clinical development. This supplement covers a sampling of the myriad issues in using IT to support the process of human testing of new drugs.

IT decisions should be like any other decisions you are making – they must first be cast in the mold of your business strategy and business conditions. Both strategy and conditions vary widely from company to company, even when the companies may seem so similar in purpose and objectives. (This is why “benchmarking” is so dangerous.) As these circumstances vary, so do the parameters upon which IT decisions must be based. The issues are different and so too are the resolutions, depending on how your company is funded, staffed, experienced, pipelined, partnered, organized and led. Indeed, IT is entwined with company strategy and business conditions in a Gordian Knot of inseparable implications.

Biopharma execs are often impeded by their own backgrounds – commonly either academic or laboratory-based. Clinical research is unfamiliar territory and may appear to be misleadingly “simple” compared to bench science and the “genius of discovery”. While the cry of “eureka!” may be hard to hear during the long years of clinical trials, the science and rigor in clinical research are no less important to bringing a discovery into medical practice. So the first challenge for biopharma execs is to put the right people in charge of clinical development – those who understand and respect it. It may seem odd, but this is the first step to effective use of IT in clinical research.

Decision, decisions; Choices, choices

Managing IT for any purpose encompasses infrastructure, platforms (hardware/software), networking and security, quality management and validation, user support and maintenance, and the software applications which your staff actually use. In clinical development, there is a wide range of applications which can be employed, and for which a biopharma must determine which of these it really needs and when. A sampling of such applications include:

• Data handling (EDC, ePRO, CDMS)

• Trial conduct (CTMS, IVRS, study portals)

• Safety surveillance and reporting (AES)

• Submission preparation (submission manufacturing systems)

• “Infrastructure” (document management, data warehouse).

Too many biopharmas jump right into this list, like do-it-yourselfers at a big-box hardware store, and start watching vendor demos and freaking out at the price tags. The place to start instead is the business strategy: how are you going to run clinical trials, when, and why?

The first constellation of choices revolves around how you will resource your clinical development. Are you going to outsource most or all of the functions (a common approach for young companies)? Are you going to selectively outsource by function (keep data management in house but outsource site monitoring, or vice versa?), and what about project management? If you choose to operate functions internally, are you staffed appropriately? Are you willing to bear the cost and maintenance of these staff? Can you find the staff you need?

What do your partners use in the way of IT? Most biopharmas have all kinds of partners — companies you are licensing to, licensing from, using for key development services (radiographic readings, core labs, patient recruitment, clinical supply packaging), and so on. Do your partners offer technology systems you can leverage, or do you have a more efficient strategy? How do you pull together these multiple sources of data?

And where is your business at this moment, or next year, or in five years? Are you heading for submission? Quickly? Ever?

Each of these questions, each of these choices, dramatically alter the appropriateness, ROI and operational impact of any particular clinical IT application choice. Ultimately it comes down to a practical, essential business question: how do you control your clinical development process? And some executives would add, how do I have control and flexibility simultaneously? How do I have both rigor (compliance) and the creativity of entrepreneurial nimbleness? And of course, how do I do this on a limited budget?

Three Areas to Focus On

It is probably helpful for a biopharma executive to focus at first on three main areas of clinical research IT, what I will call control, product data, and safety.

Control, in this context, means knowing how your trial(s) — not your subjects or your product — are doing: are they on time, on budget, experiencing bottlenecks? Are they experiencing site performance issues, compliance issues, supply issues? Are your partners performing as expected? What changes need to be made? These questions are naturals for IT support. In the pharma world the application used is some kind of CTMS (clinical trials management system). Often, small young companies will avoid this arena, because the best known applications are big and expensive, and the small ones may not be robust or mature enough, or may have been developed for a customer’s situation too dissimilar from your own.

But in our experience, obtaining control over clinical trial conduct through information is as important, or may be more so, to a young company than the traditional focus on patient data handling. What is particularly challenging, besides the complexity of managing information from diverse partner data sources, is that the design for the kind of system your company needs must come from your clinical staff (not data managers or IT staff), and your clinical staff may be your least pharma-experienced.

I use the term product data handling to be as generic as possible in referring to your patient/subject data as it relates to the effects of your product (drug, biologic, device, combination thereof). This encompasses traditional CRF data, but these days increasingly includes relevant “non-clinical” data, PRO data (“patient-reported outcomes”), images (radiographic, pictorial, motion video), and more. This is often where a biopharma starts its clinical IT journey, particularly since this is where people with “data” in their title seem to reside, and where most executives are more willing to spend dollars on technology.

Handling product data for all biopharmas is increasingly focused on usability – both for the end user (the site) and the business (i.e., for accelerated decision-making). This means access, rapid startup, and ease of reporting. When seeking to control and analyze product data, it is harder and harder in 2007 to accept a paper-based, backend-heavy application strategy. Thus a traditional CDMS gets hard to justify, especially considering the time to start up and staff the necessary support, and to run the accompanying paper processing. But are newer approaches (EDC plus an analytical backend, versus a storage-oriented backend) too risky for a new company? These newer approaches may be actually more appropriate for a new company: a) they are easier to implement in a “blank slate” environment; and b) the risk, such as it exists, is likely to be more than offset by timely data and the facilitation of interim analyses. Regardless, a number of critical staffing, process and infrastructure decisions have to be made to implement an effective data handling approach. Again, a business’ priorities should guide these choices.

Conservatism finds a home in young biopharmas when considering the monitoring and reporting of patient safety. Fortunately, a handful of similar software applications are available to choose from in this area, and because the number of your staff who will be using them is likely to be small, the cost of these applications are quite reasonable. Here the choices are much easier: pick an application, buy it and use it. Complex resourcing algorithms are not necessary; ROI pales in comparison to the cost of a safety crisis.

Nonetheless it is surprising how often biopharma executives (who have the most to lose, personally and professionally, by a safety crisis) will balk at the cost and perceived complexity of owning a safety monitoring and reporting tool. This is particularly ironic for those companies who are counting on multiple indications for their compound or biologic, and must have the means to detect safety indicators across the development stream to ensure an acceptable safety profile. Once again, the business strategy and the supporting IT needs are intertwined.

Just a Taste

This overview of control, product data, and safety is just the beginning of the IT issues which require decisions in support of clinical development. There is much else to consider, including where and how you equip your infrastructure, on what platforms, under appropriate quality management systems and with compliant validation. The key is that biopharma executives should not abdicate their involvement in these decisions because the issues seem too technical or too narrow. Precisely because of their inextricable connection to the business decisions executives are responsible for, clinical IT choices must be made with the help of senior management.

Innumerable issues must be considered and resolved as you prioritize your IT needs, schedule IT adoption, select your vendors and shoulder the mighty work of implementing these tools with your staff (or new staff), under the correct governance model, with efficiency, flexibility and compliance. Trying to cut through the Gordian Knot will lead to your operations falling in pieces. Embrace the conundrum and you will learn much about the complexity of clinical development, and through such learning will come excellence in biopharma leadership.

Many of the readers of this magazine are clinical research monitors. For many of you, the technology revolution in clinical research has been a runaway train and you’ve been the tracks. Far too often, in the process of introducing electronic data capture (EDC), electronic patient-reported outcomes (ePRO), or a new clinical trial management system (CTMS), sponsors take the shortcut that runs across your backs.

How do sponsors do this? The shortcuts take many forms. It starts with not involving monitors and their management in the initial EDC and CTMS decisions, except perhaps in the most perfunctory manner. This is rooted in the tradition of running the vendor selection teams from the IT or data management organizations. Despite being well into the 21st century, these groups continue their historical narrow view of any tools which have something to do with “data”, and monitors are not in that view.

But the shortcuts further downstream are more insidious. Sponsors, and the CROs they depend on, find ways to skimp on end-user training, user mentoring, and internal monitoring expertise. The need for detailed planning for, and documentation of, changed work processes which intelligently and sensitively respond to monitoring realities is either not recognized as important, or silently understood to be too expensive. And the widespread outsourcing of monitors, while offering many advantages to sponsors, CROs and the many monitors who choose this work style, is too often a serious mis-match with technology use.

More mysteriously, why do sponsors take these shortcuts? The damaging irony is that monitors are primary users of CTMS and EDC systems – much more so than the IT and data management folks (or even project management folks, in the case of CTMS), who are selecting these tools, the vendors, and the processes which will be used to apply them. CTMS systems, for instance, are notoriously disappointing at most sponsors. They are powerful software applications, but too often the “data” they produce is known to be inaccurate, untimely, costly to collect, and at worst, misleading. The failure of these CTMS implementations is rooted in the causes cited above: not including monitors in the planning of the project, insufficient training, and the failure to grapple with the inherent challenges of expecting outsourced staff to effectively use an in-sourced tool. Unfortunately, it is also rooted in the application design itself; no one who has been a monitor would have ever come up with the interfaces, architectures and reporting mechanisms of common CTMS systems.

With a CTMS, bypassing monitors is all the more serious, because monitors are not only primary users, they are the primary source of the data in most CTMS designs (understandably). It is monitors who are expected to enter the core actions, events and facts which roll up to the beautiful charts for executive management at the end of the month. But the accuracy and timeliness of that data is undermined by shortcuts in training, user support, and staffing strategies.

EDC is similarly plagued. While sites may be the most important user of electronic data capture, monitors are not far behind in importance, and indeed they are expected to be the primary support for the sites themselves. And yet how much do we invest in monitor training and support in our overall EDC implementation projects? In story after story from sponsor after sponsor, we hear sheepish admissions that the study timeline, the project budget, clinical operations resistance, or interdepartmental politics got in the way of the best-laid plans for monitor preparation. In every one of these stories, the result has been frustrated sites and study managers, angry monitors, and watered-down benefits from the costly technology innovation. In the still common situations where the enterprise is skeptical of innovation (and down at the operational level where the real work gets done, the resistance is high in the heat of trial execution), this lack of support for monitors adds to the obstacles to speedy change.

What it Takes

What it takes to pave straight roads to research process change is straightforward. The cost and time for training and supporting monitors, help desks, and all those affected by the technology introduction must be planned for, committed to by upper management, and then executed though to the end, by professional trainers (ideally in-house) – not shortcut, not skimped, not put off to next year, not sloughed off to so-called “super-users” (the ultimate cop-out, if not backed up by ubiquitous support). Note that it is not just training that is needed – something most companies assume to be a one-time effort – but ongoing support through staff identified as coaches, mentors or similar specialization.

It also means not short-circuiting clinical involvement when acquiring, budgeting for, or changing tactics in the software acquisition itself. The path may seem shorter to avoid involving those unused to technology selection, but the consequences of skipping along this shortcut will eventually be a “Bridge Out” sign in your path.

e-Ready or Just e-Willing?

The most common shortcut to “e-readiness” is for the sponsor to look at monitoring preparation and say, “hey, let’s outsource it along with everything else”. Let’s find CROs who promise that their staff already know EDC or use a CTMS. Job done; on to the next issue. There is no stopping the use of outsourced or contract monitors, or full-service outsourcing of all trial functions (nor should there be), but sponsors must re-examine the value proposition, and the cost-benefit assumptions about CRO usage they have made for many years, if and when new technologies are expected to be a linchpin in the clinical plan.

Most CROs are savvy enough to tell their customers they are ready and even eager to use electronic tools. They may even be sincere in describing themselves as “e-ready”. But in some cases this has become a new source of sponsor disappointment: the monitors who show up in a state of “e-readiness” may have used EDC once in 1997, or the CTMS they are used to may have been designed for a CRO’s business, instead of a sponsor’s, and thus has considerably different functionality and interfaces. Similarly, you may be assured by a support vendor that their Help Desk is EDC savvy, or clinical research savvy, and the assertion is taken at face value but fails in the execution. Too often, sponsors don’t discover these gaps in readiness until the investigator meeting, or some time after the first monitoring visit, when the knowledge chasm is too wide to be hidden and very dangerous to cross. So then another shortcut is taken: let’s use an online tool to train users in the online tools – what could be more modern? It’s not that e-learning doesn’t work, it is that when sponsors don’t think through what the information and support needs are, they will continue to rely on shortcuts wherever they can be found.

Sponsors will also turn to the software vendors themselves for this training and support; they all offer it and who knows their product better? They certainly know their product, but they don’t know you. This “generic” systems training produces generic results: your staff will know what button to push, but not much about how to use these tools for the benefit of your trial and your clinical development productivity.

Following what is perceived as a shorter path to the target, sponsors are responsible for the primary failing of outsourcing in the technology context: they are not considering what it implies, and what will cost, to rely on contract employees, or generic training, or the spare time of super-users, for the success of EDC or the usefulness of CTMS data. In this way, sponsors carry a complex change management project to the brink of success, and realize they took shortcuts to nowhere.

We can only hope that sponsors reform their approach to training and resourcing when introducing new technologies now and in the future. Instead of the light ahead being that of an oncoming train, you should insist that the next light you see will only be one of knowledge, respect, and intelligent strategy.

How to write about information technology in the global scene of clinical research? Well, the Internet took care of that, didn’t it? Someone in Ecuador can bid on an item on eBay, posted by someone from Slovakia, so what can be more global than that? End of topic. Hmm, perhaps not.

It appears that biopharma’s global use of information technology in clinical research is no more advanced than its global approach to clinical research in general, and while that might seem logical, biopharma’s “globalness” is much less advanced than the technology it could be using (or even might be using) to support it.

In part, biopharma’s use of technology varies in parallel to the individual company’s approach to being global. At one extreme is the company which has multiple, heavily-staffed, clinical development centers around the world. Such a company must rely heavily on computer technology (modern or not) to even function. Companies which are more in the middle of the spectrum – what could be called “hub-and-spoke”, where there is a primary company site and other country locations are quite small – also need technology in order to effectively tie together the many threads of the clinical research organization. Even if a company is essentially “mono-national”, most any company still finds itself running trials in multiple countries, and thus face certain technology challenges. The same can be said for CRO’s, since they range from the tiniest, serving only their local patron sponsor, to the huge multinationals who teeter on the edge of fragmentation in process consistency.

Running global trials, or running a global organization, raises common challenges to effective use of technology, as well as providing needs and opportunities for great benefits.

The least technical factor can have quite an impact – basic cultural variations. For instance, we are familiar with how investigator sites differ importantly among the US, Europe, Japan, India and all the many new countries where trials are being conducted. Sites vary in staffing (are there are study coordinators available to enter EDC or CTMS data?), technical equipment (are Internet — versus intranet – connections available? Is there a local printer? Does the site need a computer provided?), and connections (is wireless more ubiquitous in a country than wired connections, is Internet access really universal?). For instance, so-called “provisioning rates” (how often hardware or a high-speed connection must be provided to a site) varies widely even across a single border in the same region of the world, or indeed, within a country. And sites can differ widely on their expectation of whether a sponsor-provided computer or ePRO PDA is supposed to be returned to the sponsor or retained by the site after the study close. These become very sensitive situations which are not necessarily best addressed by single worldwide practices.

But subtler cultural variations will impact clinical technology success. Countries and cultures who historically feel they are treated unequally will be particularly sensitive to situations like date fields in a form which only accept one date format (the order of year, month and day), or form instructions which use English vernacular which is too idiomatic or culture-specific (even a Canadian or Australian can react negatively to an “Americanism” in wording). This kind of reaction can undermine the benefits and performance of the tool being used: if a CTMS relies on a Web-based Portal which is designed based on “first-world”, high-web-use user conventions and language, and is expected to be used in developing countries or places with low-web-consumer practices, the Portal may simply be under- or un-utilized and thus deny critical information to the study team. In such a situation, the ability to localize the Portal design, or the eCRF in and EDC study, would be an important consideration.

Data entry practices will vary globally, not only at sites but among sponsor/CRO field monitors. It is less true, but still true, that in some countries Principal Investigators may be the only ones entering data into an EDC eCRF. This in turn will dictate a very different pattern of frequency and quality which has to set a different set of expectations for the sponsor’s workflow, even within the same study. Another example is the variation of electronic health record (EHR) use around the world. Some countries are more advanced than others, and more standardized, or intend to be. This may be one of the most important challenges to eClinical trials in coming years.

Perhaps nothing is more important on a day-to-day basis in eClinical use globally than how end users are supported on basic technical and clinical questions and problems. How the sponsor designs and supports its users through a Help Desk service is critical to the success of EDC, ePRO and CTMS, or even geographically distributed adverse event tracking systems. We all have our favorite hate-the-Help-Desk anecdotes; the challenge for sponsors pursuing eClinical processes is to make sure they don’t generate new anecdotes!

Even application integration is more of a challenge when conducting trials globally. First, of course, is the challenge of speed and data integration of combining multiple instances or data stores of the same application. More difficult is integrating data sources from multiple countries and the CROs and other third-party sources (like core labs) usually used in global trials. More difficult still is considering the integration of disparate UI (user interface) approaches: it is easier to adjust a CTMS UI to local cultural conventions than eCRFs which are necessarily more driven by a concern for standards. As EDC and CTMS applications increasingly need to be integrated, these interfaces (and resulting data formats) may clash.

Last but not least, running global trials means juggling diverse regulatory requirements around the world. The challenges are myriad, such as ensuring your AES is generating all the different required reporting forms on the different reporting schedules, managing the differences in data collection conventions (such as race definitions), ensuring compatibility with eSubmissions requirements, fulfilling local patient privacy protection requirements, and more.

All of these situations perhaps could be addressed through a robust set of requirements developed by a multicultural working team. Certainly so, but of course this solution would be at least as challenging as the procedural questions raised above. As poorly designed as most requirements development efforts are, they particularly disappoint when trying to effectively and respectfully balance cultural differences, priority issues, and tight timelines.

Despite what Walt Disney may have led you to believe, when running global clinical trials with modern eClinical technologies, it is indeed still a large, diverse and hyper-sensitive world, after all. To realize the prodigious benefits of subject availability, disease distribution, market experience, and flexible labor pools, biopharmas will need to learn how to exploit information technology despite the global challenges.

IT & Clinical Development Strategy: The BioExec’s Gordian Knot

(published in BioExecutive International, December 2006)

Biopharma executives regularly face a series of decisions beyond their original professional competency. This is a requirement for biopharma executives’ success and I imagine therein lies much of the appeal of the job. In all 21st century management, decisions are accompanied by choices in the use of information technology, and this is no less true in biopharma clinical development. This supplement covers a sampling of the myriad issues in using IT to support the process of human testing of new drugs.

IT decisions should be like any other decisions you are making – they must first be cast in the mold of your business strategy and business conditions. Both strategy and conditions vary widely from company to company, even when the companies may seem so similar in purpose and objectives. (This is why “benchmarking” is so dangerous.) As these circumstances vary, so do the parameters upon which IT decisions must be based. The issues are different and so too are the resolutions, depending on how your company is funded, staffed, experienced, pipelined, partnered, organized and led. Indeed, IT is entwined with company strategy and business conditions in a Gordian Knot of inseparable implications.

Biopharma execs are often impeded by their own backgrounds – commonly either academic or laboratory-based. Clinical research is unfamiliar territory and may appear to be misleadingly “simple” compared to bench science and the “genius of discovery”. While the cry of “eureka!” may be hard to hear during the long years of clinical trials, the science and rigor in clinical research are no less important to bringing a discovery into medical practice. So the first challenge for biopharma execs is to put the right people in charge of clinical development – those who understand and respect it. It may seem odd, but this is the first step to effective use of IT in clinical research.

Decision, decisions; Choices, choices

Managing IT for any purpose encompasses infrastructure, platforms (hardware/software), networking and security, quality management and validation, user support and maintenance, and the software applications which your staff actually use. In clinical development, there is a wide range of applications which can be employed, and for which a biopharma must determine which of these it really needs and when. A sampling of such applications include:

Data handling (EDC, ePRO, CDMS)

Trial conduct (CTMS, IVRS, study portals)

Safety surveillance and reporting (AES)

Submission preparation (submission manufacturing systems)

“Infrastructure” (document management, data warehouse).

Too many biopharmas jump right into this list, like do-it-yourselfers at a big-box hardware store, and start watching vendor demos and freaking out at the price tags. The place to start instead is the business strategy: how are you going to run clinical trials, when, and why?

The first constellation of choices revolves around how you will resource your clinical development. Are you going to outsource most or all of the functions (a common approach for young companies)? Are you going to selectively outsource by function (keep data management in house but outsource site monitoring, or vice versa?), and what about project management? If you choose to operate functions internally, are you staffed appropriately? Are you willing to bear the cost and maintenance of these staff? Can you find the staff you need?

What do your partners use in the way of IT? Most biopharmas have all kinds of partners — companies you are licensing to, licensing from, using for key development services (radiographic readings, core labs, patient recruitment, clinical supply packaging), and so on. Do your partners offer technology systems you can leverage, or do you have a more efficient strategy? How do you pull together these multiple sources of data?

And where is your business at this moment, or next year, or in five years? Are you heading for submission? Quickly? Ever?

Each of these questions, each of these choices, dramatically alter the appropriateness, ROI and operational impact of any particular clinical IT application choice. Ultimately it comes down to a practical, essential business question: how do you control your clinical development process? And some executives would add, how do I have control and flexibility simultaneously? How do I have both rigor (compliance) and the creativity of entrepreneurial nimbleness? And of course, how do I do this on a limited budget?

Three Areas to Focus On

It is probably helpful for a biopharma executive to focus at first on three main areas of clinical research IT, what I will call control, product data, and safety.

Control, in this context, means knowing how your trial(s) — not your subjects or your product — are doing: are they on time, on budget, experiencing bottlenecks? Are they experiencing site performance issues, compliance issues, supply issues? Are your partners performing as expected? What changes need to be made? These questions are naturals for IT support. In the pharma world the application used is some kind of CTMS (clinical trials management system). Often, small young companies will avoid this arena, because the best known applications are big and expensive, and the small ones may not be robust or mature enough, or may have been developed for a customer’s situation too dissimilar from your own.

But in our experience, obtaining control over clinical trial conduct through information is as important, or may be more so, to a young company than the traditional focus on patient data handling. What is particularly challenging, besides the complexity of managing information from diverse partner data sources, is that the design for the kind of system your company needs must come from your clinical staff (not data managers or IT staff), and your clinical staff may be your least pharma-experienced.

I use the term product data handling to be as generic as possible in referring to your patient/subject data as it relates to the effects of your product (drug, biologic, device, combination thereof). This encompasses traditional CRF data, but these days increasingly includes relevant “non-clinical” data, PRO data (“patient-reported outcomes”), images (radiographic, pictorial, motion video), and more. This is often where a biopharma starts its clinical IT journey, particularly since this is where people with “data” in their title seem to reside, and where most executives are more willing to spend dollars on technology.

Handling product data for all biopharmas is increasingly focused on usability – both for the end user (the site) and the business (i.e., for accelerated decision-making). This means access, rapid startup, and ease of reporting. When seeking to control and analyze product data, it is harder and harder in 2007 to accept a paper-based, backend-heavy application strategy. Thus a traditional CDMS gets hard to justify, especially considering the time to start up and staff the necessary support, and to run the accompanying paper processing. But are newer approaches (EDC plus an analytical backend, versus a storage-oriented backend) too risky for a new company? These newer approaches may be actually more appropriate for a new company: a) they are easier to implement in a “blank slate” environment; and b) the risk, such as it exists, is likely to be more than offset by timely data and the facilitation of interim analyses. Regardless, a number of critical staffing, process and infrastructure decisions have to be made to implement an effective data handling approach. Again, a business’ priorities should guide these choices.

Conservatism finds a home in young biopharmas when considering the monitoring and reporting of patient safety. Fortunately, a handful of similar software applications are available to choose from in this area, and because the number of your staff who will be using them is likely to be small, the cost of these applications are quite reasonable. Here the choices are much easier: pick an application, buy it and use it. Complex resourcing algorithms are not necessary; ROI pales in comparison to the cost of a safety crisis.

Nonetheless it is surprising how often biopharma executives (who have the most to lose, personally and professionally, by a safety crisis) will balk at the cost and perceived complexity of owning a safety monitoring and reporting tool. This is particularly ironic for those companies who are counting on multiple indications for their compound or biologic, and must have the means to detect safety indicators across the development stream to ensure an acceptable safety profile. Once again, the business strategy and the supporting IT needs are intertwined.

Just a Taste

This overview of control, product data, and safety is just the beginning of the IT issues which require decisions in support of clinical development. There is much else to consider, including where and how you equip your infrastructure, on what platforms, under appropriate quality management systems and with compliant validation. The key is that biopharma executives should not abdicate their involvement in these decisions because the issues seem too technical or too narrow. Precisely because of their inextricable connection to the business decisions executives are responsible for, clinical IT choices must be made with the help of senior management.

Innumerable issues must be considered and resolved as you prioritize your IT needs, schedule IT adoption, select your vendors and shoulder the mighty work of implementing these tools with your staff (or new staff), under the correct governance model, with efficiency, flexibility and compliance. Trying to cut through the Gordian Knot will lead to your operations falling in pieces. Embrace the conundrum and you will learn much about the complexity of clinical development, and through such learning will come excellence in biopharma leadership.

“These days man knows the price of everything, and the value of nothing,” so said Oscar Wilde over a hundred years ago (referring to cynics), and so might complain many vendors of software written for the clinical trials industry. The yawning gap in perception between software vendor and research sponsor as to what clinical trials IT should cost is one of the most significant barriers to both widespread adoption and technology innovation.

Pricing of software has always been imprecise, in all industries. Software pricing has come under repeated, cyclical pressures as hardware platforms, code size, price of storage media, explosive growth of users, the Internet, connectivity innovations, and business model innovations have all upturned the assumptions of their time about how much software should cost. The starting point of the software pricing dilemma is that reproduction of software (assuming no customization) is for all practical purposes free, thus eliminating the classic basis for product pricing (“cost of goods sold”). So since the dawn of “packaged” or standard software, pricing has been a Wild West frontier.

In most markets other than clinical research software, pricing of software has become more normalized because the markets are large (meaning that there are a lot of buyers), the functionality develops to a point of understandable expectations, variability among offerings gets reduced around the mean, and in the end the market determines a typical or expected price point.

None of these factors help us in the clinical research market: the market is very small, there are not many buyers, functionality expectations (as distinct from functionality offered) can vary dramatically from buyer to buyer, and variability in pricing for comparable functionality can vary dramatically from vendor to vendor.

Pricing variability can be seen in all sectors of the small but highly differentiated clinical research IT market. In some of the niches for enterprise software, pricing can vary literally an order of magnitude depending on the vendor, on the moment in time (Is the vendor having a good year?), on market conditions (Is the vendor trying to capture market share or are they desperate for new business?), and on vendor maturity (Is the vendor naïve about how to stay in business?). Pricing variability is often a direct function of what expectations software vendors have set among their investors or stockholders (expectations of revenue metrics, of recurring cashflow, and of market size). Pricing variability is also rampant among vendors offering their software on a per-study basis or with a high proportion of services attached (such as in the EDC or ePRO markets). Often such bids from competing vendors are nearly indecipherable by customers. And this is where the frustration sets in.

The Impact of Pricing Problems

So what’s the problem with high variability in pricing? First there is the manifest confusion about what this “should” cost. With such high variability, how do biopharma customers of these software tools come to understand what is a “correct” or “fair” or “reasonable” price? There is a very real opportunity to overpay for this software. There is also the danger of paying so little that the software community cannot survive to provide what the customer needs. Worst of all, this variability brings attention to itself, and draws attention away from where biopharma customers should be focusing when making vendor selection – on vendor-sponsor fit, on service quality, on technical reliability, on functional suitability. Instead of staying focused on precise and efficient analysis of these latter factors, too often a clinical research software acquisition will get sidetracked by the wild distribution of pricing.

This phenomenon is compounded by the increasing involvement and power of contracting/purchasing staff in the selection of research IT software. When only back-end enterprise scale software was being used, mostly the acquisition process (rightly or wrongly) would stay within the biopharma’s IT organization and budget. In today’s world of per-study and service-laden software licensing, clinical IT tool acquisition is often falling under the oversight of those who handle CRO contracts and the hiring of outsourced services. These folks (rightly or wrongly) will almost always let price dominate their decision-making – indeed they would assert it is their corporate function to do so.

The most damaging influences of the pricing confusion are many-fold:

Rampant cynicism, if not mistrust, of vendor pricing

Severe difficulties in projecting IT budgets, operational budgets, and/or trial costs (indeed, clinical development costs overall)

A stunting of vendor maturity growth as a by-product of sponsor manipulation

Perhaps worst of all, inhibition of software development innovation because of the manifest uncertainty vendors face in predicting their future cashflow.

The Vendor Answer: What Price Value?

In the Vendor Valhalla, there is a consummate answer to this dilemma: the price their tools command should equal the value they deliver to the customer. Value-based pricing has been the elusive goal of product and service vendors perhaps since the earliest beginnings of commerce. In some markets, economists would say value-based pricing operates quite efficiently: people buy small cars because the value of transportation to them lies in the efficiency or affordability with which the car moves them from point A to point B versus the alternatives (city bus, walking); people buy luxurious sporty cars because of the value they bring in personal satisfaction or status; people buy minivans because of the value of carrying family and friends in large numbers in relative comfort.

Value-based pricing for clinical research IT tools is hard to achieve. Gone (I hope) are the days when vendors sold their tools to biopharma on how many days faster a drug will get to market because of the use of their product. And yet, isn’t it true that switching from paper to EDC can (in theory) accelerate clinical development to the point that literally billions of dollars will be made sooner, and more billions to boot, as a result of faster submission? If this can be traced to the use of an EDC tool, what should the inventor, developer and provider of that tool be paid? If the robustness, ease-of-use, and cleverness of an adverse event tracking and reporting system enables a sponsor to identify post-marketing safety issues faster and more accurately, improving patient safety and fending off a damaging market withdrawal, what should that sponsor have paid for that software?

As much as vendors salivate at such “value propositions”, rare indeed are the instances where tools have been rewarded by the hands which used them. It doesn’t happen. And yet, we know the software is worth more than the CD it has been burned onto.

A Possible Response

Sponsors have at least two ways to contribute to the resolution of these dilemmas in a positive manner. One is relatively quick and simple, and ultimately limited, but still an advance: sponsors need to somewhat artificially create some normalization of this pricing by developing and applying basic “bid grids” and similar templates, especially when purchasing software through service-based models. This is directly akin to CRO bid processing, logically, and should allow sponsors to make the best use of the experience of their purchasing departments. More than that, it will enable clinical development staff to begin to structure the pricing evaluation component of vendor selection in something closer to an apples-to-apples comparison and help them understand where (vendor) costs come from.

But more importantly, sponsors are woefully behind in understanding how much their day-to-day operations truly cost, and the components of that cost, without which they cannot begin to judge what the value is of a tool which replaces, displaces or enhances those components. This is the heart of the problem from the biopharma side of the conundrum, and has always been a hindrance to the improvement of clinical development operations issues of all sorts.

Some Truths

Ultimately, there are two fundamental truths in small-market pricing that apply in particular to clinical research software. First of all, the ultimately “correct” price for software must meet two requirements:

It must seem fair to the biopharma sponsor

It must be able to keep the vendor in business.

Obviously, and painfully, to reach these twin goals requires a degree of openness, honesty, financial awareness and sophistication, that is mostly missing in our industry.

At the other end of the continuum from the quantifiable to the qualitative, there is another approach to pricing value which may be, in the short term, the most compelling: the value of necessity. In describing the role that EDC played in processing a huge amount of data from a large number of patients in a pivotal Phase III trial in a highly competitive product market, one sponsor memorably said that while using this vendor was enormously painful in many ways (and presumably not worth what they were paid), the sponsor could not have completed this trial and the subsequent submission any other way. The tool had been essential to meeting the business need.

This is value, in its purest form. If vendors can deliver this kind of benefit without the pain, and if sponsors can learn enough about their costs to understand what the tool did for them financially, the price of value will be clear to all, and willingly paid.