Build or buy critical eClinical applications?

According to IDC, over half of all clinical-trial application software is developed by in-house programmers or by outside contractors for specific use – the highest proportion among all pharma R&D segments. Although the reasons behind this strong reliance on custom software are not known, company-specific SOPs and stringent regulatory standards for clinical research are probably strong motivators. However, as I will illustrate, inadequate information during the build-or-buy decision process can lead to inaccurate cost estimates, especially for proprietary tools.

The eClinical build-or-buy decision process must be collaborative and interdisciplinary to avoid underestimates of the effort required to build or the cost to buy. Consider a toolset for collaborative authoring of extensible clinical protocols. Also known as eprotocols or structured protocols, bona fide extensible protocols are structured models of knowledge that, in their simplest manifestation, are used to write protocols. In order to function as intended, an extensible protocol-authoring application must be able to interpret natural-language information, structure it according to internal SOPs and external data standards, and then use (and reuse) it to create documents, such as protocols. At face value, a custom user interface atop an off-the-shelf XML editor linked to a custom-programmed database might seem sufficient to create extensible protocols, but as has been described elsewhere (Beitz 2006), the result – an XML-based document template – is a superficial solution that offers limited functionality and efficiency gains. In order to achieve important operational benefits, an external (to the document) protocol knowledge model is needed; features that will be demanded by end-users, such as logic-based dynamic content and document quality checks, must also be programmed and made to work within the authoring environment. With these additional requirements, the build vs. buy calculus is other than a trivial one favoring build. A close collaboration between IT professionals and end-users is necessary but insufficient in order to capture realistic application requirements. If an organization has historically been unable to align these functions, it is not realistic to expect such alignment to occur during an application development project. In such cases, buying and configuring should be the default response to a perceived technology need, as custom software will be doomed to failure from the outset.

Purchasers may demand explicit itemization of anticipated expenses from vendors, greatly aiding buy decisions. Conversely, the costs of developing, maintaining, implementing and supporting in-house applications must be estimated and require multi-constituency agreement. It is important to have itemized build-requirements lists to guide estimate generation. The following items deserve particular scrutiny. Have infrastructure costs been fairly estimated? Hardware, if needed, is expensive to purchase and depreciates rapidly. Enabling-software licenses are recurring charges that may be cost-ineffective if not distributed over multiple applications. Can internal staff maintain and service a custom application in the absence of an external vendor? For instance, developers must be willing and capable of keeping applications current with changing industry data interchange standards. Have the full costs of end-user training been considered? For critical eClinical tools, user training means ongoing, dedicated, live support. What about indirect project development costs – such as technical risk? In-house development of an eClinical application may be capably supported by a surfeit of clinical domain experts, but do in-house IT personnel have the necessary skills? Can IT dispassionately assess its own expertise? Will IT be capable of and willing to reliably predict the a priori risk of project failure (including significant launch delay)?

It is easy to overlook direct and indirect costs of custom software when making a build or buy decision. When a fair accounting of costs and benefits of custom-built versus off-the-shelf, configurable eClinical applications suggests a buy decision, purchasers should look for solutions that are highly configurable, that are serviced by reliable, customer-focused vendors, and that conform to industry data interchange standards to facilitate vendor-neutral, seamless communication between IT systems.

BIO

Frederic J. Cohen joined Fast Track Systems in April 2007. He has been involved in pharmaceutical R&D, licensing, and business strategy for 12 years and medical research for 20 years. Cohen is particularly interested in strategies and tactics designed to improve industrial research productivity.

Key points

• Inadequate information during the build-or-buy decision process can lead to inaccurate cost estimates.
• The decision process must be collaborative and interdisciplinary.
• Use itemized build-requirement lists to guide estimate generation.
• Pay particular attention to infrastructure, maintain and service, user support and training, and indirect costs, such as technical risk.
• When buying, look for solutions that are highly configurable and that use industry-wide data standards to facilitate data interchange between systems.

Reference: Beitz, C. The case for eprotocols technologies adoption. Future Pharmaceuticals 2006 2;48-50.