Judging from the inquiries we have received in the past year, biopharma companies both experienced and naïve are looking beyond traditional clinical data management systems (CDMS), or even CDMS plus electronic data capture (EDC). They are looking to something new, which may be a new dawn over the mountaintops of data processing in clinical trials. Or, it may look like Wyoming after the strip miners have left.

I am talking about the much misunderstood phrase, “clinical data warehousing” (CDW). And like any other clinical IT initiative, CDW has been hijacked by technologists, and/or a lack of follow-through from the sincere business–side visionaries who leave the job of implementing innovation to others.

To briefly set the scene, we know that CDMS have been used to store clinical trial data for several decades now. Although this was the first area in clinical development to be widely computerized, many other uses of computers have since developed, and thus we have a plethora of individual, or “silo’ed” applications: trials management systems, EDC, electronic patient diaries, document management systems, and more. This multiplex of applications has also been a common development in other industries and even other sectors of biopharma companies, and one solution in recent years to try and pull these threads together is to build a common place to store the data generated by these applications – a “warehouse”.

It’s not the warehouse, it’s what you get out of it
Casting this change in terms of a “warehouse” places the technical emphasis on data storage, which while technically important, is totally subservient to what you need the data for, to how you are going to use it. Yet most people start with designing the shelf space and forgetting about the aisles and the doors needed to get the data out, and more so, where the data is going to be sent and why. This is not to say that the warehouse architecture question is trivial, but rather than it is premature until a dozen other questions have been answered by the business first.

Getting the data out is often called “data mining”, which mixes the metaphor immediately, and gives me permission to mix the metaphors for the rest of this column! Tools (or building blocks) for data warehousing and mining have been around for years, and successful data mining in healthcare has been used for a decade in health claims analysis and even pharma marketing. The key point is that mining data does not have to happen in a warehouse; indeed successful (i.e., meeting a business need) mining can be done on the databases you have right now, even those scattered about the enterprise.

You have to ask why
So the first question we ask our clients inquiring about a CDW is “why?”. It should be the first question asked of every new process or technology change, and yet at least half the time it is never asked: instead we start from a new technology or process fad, and look around for a reason for it much later. Even in this column, instead of talking about all the possibilities of CDW (which we will later on), I want to talk about why one would do warehousing in clinical development first.

Exploring this question with clients has often revealed very limited perspectives on what the felt need really is:
“I wish I had better reports from my clinical data.”
“I wish SAS export was easier, or earlier, or more direct, in the trial flow.”
“I wish all my documents were in one place.”
“Everybody else is doing it so I think maybe we should too.”
In other words, people are very much in need of better reporting, which may mean some data mining, but is unlikely to mean something requiring the sophistication of a data warehousing effort.

As I write this column, the scandal surrounding the FBI’s huge new software tool that doesn’t work is making the news. The following quote from an FBI spokesman sums up the data warehousing dilemma beautifully:
“The Investigative Data Warehouse, while perhaps a useful tool, does not manage case workflow and does not substitute for an effective case management system. Consequently, the FBI continues to lack critical tools necessary to maximize the performance of both its criminal investigative and national security missions¡¦”
You need to change only a couple of words and this could be some pharma’s sad CDW story three years from now unless it’s done right and done well.

Dawn on the Mountaintop
So now let’s look at why a clinical data warehouse may be a terrific idea for biopharmas if done correctly. We have proposed for many years that acquiring applications in individual actions, without regard to each other, may maximize the value to a very narrow function but is costly to the enterprise and highly inefficient. In addition, the dominance of CDMS orientation has a) held back EDC adoption for years, b) distracted clinical development personnel from the importance of trial management also, rather than only data management, c) and has kept an entire profession (data managers) from seeing above the trees.

For any biopharma examining how they do data management in 2005 (and many companies are), it is very appropriate to be considering an “EDC + repository” strategy rather than a traditional CDMS. The extensive traditional CDMS functions have little or no usefulness when an effective EDC “front end” is applied (assuming the EDC tool is working well). But how should the “back end” repository be architected, what should we expect from it, and what else can it do?

Some of the repository architecture guidelines come from work being done by CDISC and is also influenced by regulatory compliance issues, the guidelines for which are also in flux. But staying above the “data model” level for the moment, what some kind of repository does is begin to enable the “write once, ready many” paradigm that technologists have preached (and some industries have come close to) for many years. In clinical research, this means significant efficiencies on both the trial management side (how many times do you enter the investigator’s address today, and how do you know it is correct?) and the data integration side (getting central lab data, ePRO data, drug safety and CRF data in a location, or reportable, so that an integrated view is available for the human mind to collate). Once you start thinking this way, the best benefit of CDW is to break down the acronym silos of CDMS, CTMS, EDMS, EDC, EPD, IVRS, AES.

The Path to the View
So if we want to get the mountaintop, which path should we take? Some CDMS vendors will say they can offer it all to you, so “stay within our world”. Other choices may be more productive sooner, but are by definition innovative and therefore riskier — risky not being a usually appealing word to pharma operations. As we used to preach about EDC for years, however, if you wait until it isn’t risky any more, you will be far behind your rivals. We see this now in EDC, with earlier adopters flying ahead of those who waited (although some early adopters are no farther along than they were in the mid 90’s). Finding the sweet spot between “bleeding edge” and “failing follower” is always the challenge.

One thing is clear: the path begins with understanding why, before any vendor walks in the door, before the project itself gets the wrong name. Maybe what you really need is simply better reporting from the databases you already have. Maybe you need a more innovative approach to analysis. And just maybe, you need (and almost certainly can benefit from) a new approach to clinical data processing.

For clinical operations folks, there are two important implications to prepare for:

Changes like this will be a new distraction to you and your colleagues

You need to be proactive and get involved in these decisions: don’t let Informatics or CDM do this in a vacuum, which continues to happen way too often.
A new day will dawn when data processing is re-invented and the silos torn down. Our approach so far seems to be to build more buildings on the farm instead, with only a steam shovel available to tear the sides off when we need to get something out. We need to avoid strip mining the future by first considering the reasons behind business change.