Articles
Integrated eClinical Solutions Be Afraid, Be Very Afraid
By Timothy Pratt, PhD
Originally published in PharmaVOICE VIEW on E-Solutions, October 2006
Examining Integration
By now, you may well be asking yourself the question, "So what's the difference in practice?" The difference is probably best answered by examining what the intent of integration is, and why it is often less than successful.
The whole purpose of integrating systems is to increase efficiencies by making related software applications' data visible and usable to the system as a whole. The problem is that this is extraordinarily hard to do. Ask an IT person, who will tell you it is often very difficult to get disparate systems developed in isolation to reliably "talk" to one another. What this means in practice is that the integrated solution is often problematic, doesn't work as advertised, is susceptible to crashes and bugs when elements of the individual packages are updated, and so on. In addition, the promise of real-time data visibility and operations management often is not delivered in integrated solutions. Because the package components run as separate applications under a broad umbrella, the performance of the system as a whole is necessarily dependent on the lowest common denominator's performance. Many of the packaged applications were never designed to be interoperable with other systems; they run at different speeds, process and output data at different rates and in different ways, and generally behave independently rather than as a cohesive whole. Such component behavior is intrinsically inefficient and often requires periodic outside (human) intervention to control, obviating the automaticity and subsequent efficiency desired in the first instance.
