Nearly one year ago, Secretary David Shulkin of the Department of Veterans Affairs (VA) announced that the VA’s electronic health record (EHR) is moving away from custom built software products and development in favor of commercial-off-the-shelf (COTS) solutions to provide for Veteran healthcare. This shift in the VA’s approach to software development represents a challenging decision: whether to build custom software systems from a general-purpose programming language, or whether to buy existing COTS solutions that seem to fit business needs and user requirements. In fact, many businesses outside government face this same difficult question, whether they are large corporations or small startups. It can be a dilemma to determine which route to choose.
The decision to build or buy is multifaceted and complex because all ramifications can never be fully foreseen and all the advantages and pitfalls cannot be predicted. When it comes to determining whether to build custom software or buy COTS, the answer for VA, and any business no matter what size, is always some combination of both. Rather than assuming the solutions are mutually exclusive, a better way to view the two possibilities is on a spectrum where choosing a solution that utilizes the right amount of both options portends the greatest likelihood of success.
WHEN TO LEAN TOWARDS A CUSTOM BUILD
If you are in the business of creating software. If you are in the business of building software, that is a good indication that creating a custom-built system is a viable solution. Growing and unforeseen costs associated with custom-built systems can be mitigated if you have in house resources performing maintenance and modifications. Although it will always be a significant time investment, doing the work yourself will be much less financially burdensome than paying an outside contractor.
If there are no COTS that suit your business needs and specific user requirements. The most attractive benefit of building your own software is that it is entirely customizable. When you start with a general-purpose programming language, no feature or user experience is off the table. However, the downside to manufacturing your own systems is that highly specific modifications add up quickly, and it is nearly impossible to predict the cost at the outset.
If you have stringent workflows that cannot be changed or adapted. COTS solutions almost always involve changes and adaptions in workflow dictated by the COTS product design. A custom build can cater to the specific environment of organizations where the workflow is unchangeable. However, if your organization can live with changing and adapting workflows to align with the workflow dictated by the COTS product, then you can offload much of the cost that comes with building your own system.
WHEN TO RELY PRIMARILY ON COTS
If you have seen the COTS product you are considering work successfully somewhere else. Another sign that COTS is the best solution for your organization is if there are examples of the COTS product you want to invest in working successfully somewhere else. With custom development, no matter how well thought out the plan or how skilled the developer, you can never be 100% certain that the buildout will be scalable, workable, and affordable.
If you have an inflexible budget. One of the biggest advantages of going with COTS solutions is that cost is more predictable. Going with COTS can reduce maintenance costs such as keeping up with standards and changes, as well as standard software sustainment such as security patches and upgrades. When buying COTS, the cost of keeping up with standards as they evolve is pushed to the COTS vendor, essentially diffusing the cost across all the vendor’s customers.
THE BEST DECISION
In VA’s case, the investment in their COTS solution—Intersystem’s HealthShare—has some marked advantages that will likely translate into cost benefits. Software engineers working to maintain VA’s legacy systems and modernization efforts can attest to how difficult and expensive it can be keeping up with changing standards and sustaining software security patches in custom development. With the adoption of HealthShare, the burden of ensuring compliance with standards of the new FHIR specification, new versions of CDA documents, and any other standards that might emerge falls on Intersystems rather than VA. Additionally, Intersystems is responsible for security patching and fixing basic bugs that may manifest in the system.
However, the decision to invest in COTS is never as straightforward as installing and flipping the “ON” switch. The implementation of most COTS tools today, including HealthShare’s implementation within the VA framework, require a significant amount of configuration and integration work. Considering the sheer magnitude of patient data involved in VA’s current EHR, the Veterans Information Systems Technology Architecture (VistA), and the frequent need for the system to talk to other EHRs with non-standard APIs, the ultimate success of HealthShare is largely dependent on the engineers performing the integration and maintenance.
Ultimately, it is impossible to choose between only using COTS or creating a standalone custom build because some level of both methods is required to set up a working system or EHR. Setting the dial at the precise point on the spectrum between COTS and custom development is the best way to ensure success for any EHR or software development project.