In this two-part article, the authors examine the traditional question of buy vs. build in healthcare. Part 1 reviews the traditional buy vs. build argument and proposes a more nuanced approach of buy+build and build+build. Part 2, which will follow in our January issue, presents a real-world case study of the decision process Columbia, Md.-based MedStar Health underwent in deciding to build a clinical Web portal.
A mantra in healthcare information technology (IT), and in most IT organizations, is "don't build when you can buy!" This conventional wisdom is likely the legacy of the early "home-grown" healthcare applications of the 1970s. As these first systems aged, a legitimate concern arose that internally developed applications would decline as stakeholders either left or lost interest in maintaining the application.
Reasons not to build
- Integration — Inability to fully integrate the home-grown application with a vendor-supplied application (i.e., vendor lock-in).
- Knowledge Transfer — The concern that if/when application developers leave an organization, knowledge of the application will decline or be lost.
- Core Competency — Developing applications is not what the hospital organization does best. "We couldn't possibly develop something as robust and as feature-complete as the HIS vendor."
- Total Cost of Ownership (TCO) — The TCO of building your own application is higher than the TCO of a vendor-purchased application.
- Application Maintenance — In order to keep pace with changes in healthcare, a custom application will be an endless resource drain.
Classic reasoning matures
Classic reasoning is sometimes right. If an application has become a commodity, such as a word processor, then a packaged product is the logical choice. However, when an application must meet more unique needs, such as those that exist in a hospital, a packaged product may not provide the best approach. Packaged healthcare applications in clinical practice can take years to "get right." One could argue that by the time the implementation is truly over, the application has become a custom application. The degree of customization required to make it actually usable creates a custom application sitting on top of a standard framework (buy+build).
The important measure in a buy vs. build decision is the actual amount of customization required. Each organization needs to determine their own tipping point where the customization of an off-the-shelf product is more time consuming or expensive than internal or contracted development. Both tangible and intangible constraints need to be considered in this decision. Outside of healthcare, most industries consider internal application development as a routine option. This is because an internally designed system has the ability to intimately meet an organization's specific needs more so than an off-the-shelf application.
When internal development makes sense, healthcare can look to other industries for examples of success. Merrill Lynch recently sold a self-developed Web service tool to its own Web service vendor. One reason for the financial industry's success may be that that they simply can (and do) spend more than the healthcare industry on IT. Recent studies indicate that U.S. financial institutions will spend $118 billion on IT, whereas healthcare organizations will spend $23 billion, with $15.4 billion going to hospital IT. If financial institutions, whose core competency is finance and not software development, continue to consider and develop internal applications then healthcare can do the same.
Internal development matures
In the last 20 years, computing technology has sufficiently evolved to address most of the classic reasons not to build due to the fact that buy has become buy+build:
- Integration — New technologies have eased the formerly difficult integration among different healthcare applications. For example, Web services and XML (the basis for HL7 version 3) provide a mechanism for developers to design applications that can independently utilize, and be utilized by, other applications now or in the future. Inter-application integration is easier with custom-developed systems, whereas integrating packaged systems can be difficult because of their proprietary design. In addition, custom applications can evolve as clinical practice changes or as the hospital adds new systems.