Email us : info@waife.com
Management Consulting for Clinical Research

Get with the Program (2001)

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.

 

Sorry, the comment form is closed at this time.