Is it really "Buy vs. Build"?

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.

Classic reasoning

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.

Knowledge transfer — In modern standards-compliant development, knowledge transfer is not as labor intensive as in the past. Keeping track of changes in a custom application is facilitated with code tracking tools such as Visual Source Safe or the open-source Concurrent Versions System. If open-source applications are capable of combining the efforts of thousands of independent developers into one coherent product, it is clearly possible to successfully transfer application knowledge in a funded organization. Knowledge transfer can be eased by defining a development mindset that employs detailed documentation and re-usable code, and discourages programmers from "falling in love" with their own code.
Core competency — The concern that application development isn't currently a hospital's core competency is correct. However, the field of medical informatics was created by, and in, the hospital. Over time, the field transitioned out of the hospital and to the vendor. Why shouldn't healthcare systems leverage their vast clinical and organizational knowledge base to make some clinical application development a core competency? In fact, vendors have purchased hospital-developed software in the past. McKesson Horizon Expert Orders, for example, was developed by Vanderbilt University Hospital and Microsoft's recent purchase of Azyxxi from MedStar Health proves that a hospital system can develop a quality product (build+build).

Total Cost of Ownership (TCO) — Mark Twain popularized Benjamin Disraeli's statement, "There are three kinds of lies: lies, damn lies, and statistics." TCO studies are no exception. It is well known that the time period dramatically affects the cost analysis. What will be the savings in 10 to 15 years — a scale easily obtainable given the lifespan of healthcare IT systems? What is the cost when the organization wants to change clinical practice workflow that necessitates vendor customization to the system? What happens to a system that is no longer actively maintained if the vendor goes out of business?

Application Maintenance — Diverse healthcare organizations need to constantly change and innovate to stay ahead in their marketplace. It stands to reason that an application will need to be updated to reflect the practice and practice workflow changes. A custom application is capable of changing in-step with the hospital's changes — an evolutionary process rather than an abrupt process, which can be a dramatic and disruptive shock to a hospital. A packaged product seldom makes timely and dramatic shifts in the application because they can't; the product is used by other hospitals who may not want to change their practice workflows.

Packaged software implementations will likely continue to grow in complexity as implementations have transformed to buy+build. For large organizations, application implementation has become a Herculean task as evidenced by many failed installs. The degree of complexity will increase because as clinicians learn the potential of information technology to improve patient care and their financial bottom line, they will demand more and more software customization.

What to do?

The question that faces a modern hospital is not the decision to buy and implement commercial off-the-shelf vs. build your own from scratch, but rather, buy and customize (buy+build), or build and customize (build+build). Either way, IT departments will continue to need developers and clinical informaticians to ensure that products work optimally for their clinicians.

Jason Kreuter Ph.D., is associate director, MedStar e-Health; Allison Stover is a healthcare consultant; and Peter Basch M.D., is medical director, MedStar e-Health.