Buy A New Technology or Further Develop Legacy Systems
Lately, technology security has taken center stage as health organizations face increased challenges of maintaining the security of patient health information (PHI). While securing data is of concern, determining the most applicable and cost-efficient technology is the most important priority.
Accelerating digital transformation and leveraging emerging technologies have become a fundamental imperative for hospitals, health systems and physician groups. Technology executives seek to leverage today’s disruptive technology applications to improve the performance of legacy systems or purchase enhancing technologies to reduce cost or improve operational performance.
Provider organizations are pursuing strategies for reimagining their core systems that involve modernizing and revitalizing, while also being on the lookout for less expensive and more efficient new technologies. The overarching objective of any Information Technology (IT) initiative is to transform the foundation of technology to be more agile, intuitive and responsive to meet today’s clinical and financial needs while laying the foundation for tomorrow.
With the rapid advancement of supportive technologies such as web and cloud computing gaining increased visibility as an enterprise initiative, there lies a question for healthcare leaders: should providers develop new technology capabilities as an internal project, or should they be sourced from a specialized external vendor—or both?
The classic method for evaluating the pros and cons of a technology “buy-versus-build decision” are outlined below by Michael Dunne, Senior Vice President of Creative Executions.1
The Pros and Cons of Internal Development
Pros: The advantages of building:
Satisfy unique needs—The main benefit of building a custom solution is that you are free to build whatever you want and can accommodate very specific requirements of stakeholders. You are not dependent on a vendor’s choices and direction in product development.
Employ insider insight—A homegrown solution also makes it easy to capitalize on your IT department’s familiarity with the principal lines of businesses, stakeholders and processes to expedite delivery of a solution that meets expectations.
Utilize familiar tools—When building an internal technology, there may be opportunities to leverage technologies already in place. This can lower costs and time-to-deployment for IT, and help end users get accustomed to systems (by resembling standard tools).
Maintain control and accountability—When the system breaks down, you know how to fix it.
Cons: The issues with building:
Resource constraints—Without expertise, many mistakes can be made throughout the development process, monopolizing resources and causing headaches. Building robust rules and constraint engines can be very demanding for non-experts. Many well-intentioned teams that utilize the homegrown route end up with no system at all.
Trailing innovation—Insufficient time and focus make it nearly impossible to build a solution that incorporates all the latest technological advances, so you may end up missing out on must-haves and latest developments in mobility, analytics, knowledge management or rich visualization.
Limited tactical solutions—Many solutions built by internal teams are designed to address specific and current realities. These solutions can be difficult to grow and evolve when new requirements arise down the road from existing or different sets of stakeholders.
Maintenance costs—with all the time and effort required to maintain a solution internally, it can be challenging—if not impossible—to upgrade features adequately in a way that satisfies changing business needs in a timely fashion.
The Pros and Cons of Working With a Technology Solution Vendor
Pros: The advantages of buying:
Access critical technologies—Technology vendors live and breathe their specialty, so they are better equipped to deliver a system that promotes scalable growth by leveraging expertise in their particularl fields (e.g., constraint engines, rules engines, knowledge and content management and pricing execution).
Enjoy the latest innovations—Taking advantage of the latest technology developments is a no-brainer, especially if they’ve been tested by large, demanding enterprise organizations.
Expand functional breadth—Working with a technology vendor means you profit from the ability to bundle key, complementary features with your configuration solution, like connectivity with other systems.
Improve system growth potential—A well-built, prepackaged solution that comfortably covers existing business practices is also likely to be flexible and receiving enhancements to keep abreast of the most recent trends. Hence, you can do more than solve just a set of current problems and be better prepared for future contingencies.
Offload maintenance burden—Let your software vendors and contractors take care of upgrades and maintenance so that you can focus on your core business issues.
Utilize expert resources—Independent technology and integration vendors possess a wealth of institutional knowledge and skills, both technical and business best practices that make it much simpler to expand and modernize your solution over time.
Cons: Issues with buying:
Loss of control—When you work with a vendor, the vendor manages the process for making changes or updates to the system. Also, a vendor may assume a significant proportion of responsibility for the initial implementation. Be sure to get a clear understanding of the solution roadmap and enhancement schedule before committing to a vendor.
End-user acceptance—As with any new solution, it is important to get buy-in from all affected stakeholders before you implement, otherwise getting adoption can be a challenge. Look and feel, system usability and intuitiveness of features to end users are all important issues to explore.
Vendor lock-in—Changing vendors after deployment is not an easy task, so it is important to weigh your options carefully and make the right choice upfront.
Vendor instability—A vendor’s viability should be determined before a commitment is made. Ideally, you want someone who can demonstrate longevity, a good track record and can provide references.
The most important measure in a buy-versus-build decision is the degree of customization required. Each organization needs to decide their unique tipping-point where the customization of a pre-built technology will take more time or be more expensive than internal or contracted development.
When a technology application must meet unique needs, like those that exist in a healthcare provider’s organization, a purchased solution typically is the preferred approach. However, even with a purchased solution, the degree of customization required to make it usable ultimately creates a custom application. This emerging design has evolved into a buy-plus-build scenario.
Over the last 15 years, healthcare computing technology has suitably changed to address most of the traditional reasons for not building internally. Therefore, the purchased technology methods have transformed into a buy plus build process. In their article in Healthcare Informatics titled Is it really “Buy vs. Build”? Jason Kreuter Ph.D., Allison Stover, and Peter Basch M.D. outline five reasons why to buy plus build has become so prevalent.2
- Integration — New technologies have eased the formerly complicated 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 used 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. Also, 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
- Core competency — The concern that application development is not 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 plus 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 innovate and adapt 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 cannot; the product is used by other hospitals who may not want to change their practice workflows.
The buy versus build methodology has morphed into more of a buy-plus-build process. This is due to the scope and complexity of launching purchased software that must meet the requirements for rapidly changing rules and regulations, driving patient satisfaction and improving bottom line financial performance.
The long-term impact on a provider’s organization warrants careful consideration so that technology decisions are made with the strategy that ultimately will have the most positive effect on the entire enterprise. While it takes substantial time and effort from technology leaders and stakeholders to make the most appropriate decision buy, build or both, the costs of making a poor decision can be catastrophic. On the other hand, the benefits of making the right decision can positively affect a hospital’s bottom line for decades to come.
Phil C. Solomon is the publisher of Revenue Cycle News, a healthcare business information blog and serves as the Vice President of Global Services for MiraMed, a healthcare revenue cycle outsourcing company. As an executive leader, he is responsible for creating and executing sales and marketing strategies which drive new business development and client engagement. Phil has over 25 years’ experience consulting on a broad range of healthcare initiatives for clinical and revenue cycle performance improvement. He has worked with industry’s largest health systems developing executable strategies for revenue enhancement, expense reduction, and clinical transformation. He can be reached at firstname.lastname@example.org
- Adopting CPQ? Does it make more sense to build or buy? Michael Dunne, Senior Vice President of Creative Executions http://webcache.googleusercontent.com/search?q=cache:5wfREbIJLAQJ:www.determine.com/blog/entry/do-you-build-or-buy-when-adopting-cpq+&cd=2&hl=en&ct=clnk&gl=us#.V0W5bDUrLVc
- Healthcare Informatics, Is it really “Buy vs. Build”? Jason Kreuter Ph.D., Allison Stover, and Peter Basch M.D. http://www.healthcare-informatics.com/article/it-really-buy-vs-build?page=2