Due to the influence of governmental rules, payment incentives, or simply end-user demand, health systems are being encouraged (and, in some cases, required) to provide additional support and services that at one time would have been unheard of. Beyond facilitating the clinical team’s interaction with the patient, healthcare organizations are now hiring software developers, server administrators, and other non-clinical roles in order to enable wayfinding applications, telemedicine venues, patient portals, and many other technology solutions.
When it comes to the pursuit of novel health information technology (IT), health systems often face a “build versus buy” dilemma. Do they take the time to build their technology in-house, or partner with a vendor? In this article, we’ll discuss the factors to weigh regarding technologies related to monitoring clinical care processes and reducing workflow inefficiencies. The pros and cons to be discussed will include:
BUILD VS BUY CHECKLIST FOR HEALTHCARE TECHNOLOGY
There is a large degree of flexibility that comes with building solutions internally. This approach puts the product design, development, deployment, and support under the supervision of local leadership. As complexity grows, this can become expensive to maintain for a single organization that may not have professional product teams. However, for many cases (especially proof of concepts), the control can be very effective and empowering when aligning to existing local needs and processes. This is especially true if there aren’t any external vendors that provide a desired product or service. It’s important to also acknowledge that external partners may allow some degree of customization, so it will be necessary to assess if the available modifications meet local requirements. For example, most EHR vendors facilitate building custom alerts. However, while they may allow customized text within the alert, they will invariably limit the adjustment of the design of the alert container itself.
EXAMPLE
At Children’s Hospital of Philadelphia (CHOP), an early adopter of the Epic Systems EHR, the clinical teams needed specialized asthma decision support and to create complex rules for immunization guideline adherence. They found the native EHR clinical decision support (CDS) at the time lacking given the limited flexibility. Innovative clinicians and engineers at CHOP, led by Drs. Bob Grundmeier and Alex Fiks, built the Care Assistant tool. According to Dr. Grundmeier, they built this custom application to “support [their] informatics research mission and [it] was useful for implementing clinical decision support in numerous clinical domains.” The successful implementation of this CDS application, which has also facilitated a variety of CDS research publications, is a testament to the value of building a local custom solution. However, the continued development of new technologies and industry standards (like SMART on FHIR and CDS Hooks) can raise questions about the future viability of custom-built applications.
Case Study: Why Build?Dr. Bob Grundmeier of Children’s Hospital of Philadelphia shared they built a custom solution to “support [their] informatics research mission and [it] was useful for implementing clinical decision support in numerous clinical domains.
When platforms are developed internally, there is inevitable learning that comes with this experience. This education can instill skills in the organization’s workforce that can extend beyond the product itself. This can be particularly aligned with the strategic mission of academic health systems that may have students or trainees that want to pursue the development of a specific product or service. Of course, learning in parallel to development often comes with relatively slow progress and potential missteps. As such, organizations with tight deadlines or high stakes outputs should take note.
EXAMPLE
One large health system used self-service Qlik dashboards to help monitor their quality initiatives and accompanying alerts and order sets. Their analytics team invested a significant amount of time creating robust interfaces and charting tools across a variety of projects. The organization did this in relatively little time because the team’s lead had developed these skills and applied his learnings across several domains within the organization. When this employee left the organization, not only did the dashboards become stale and, in some cases, non-functional over time, but some of the learnings had been lost with his departure. The health system later decided to de-prioritize re-learning the capabilities to develop and monitor those dashboards. It’s important to ensure that institutional knowledge like this gets codified and adopted broadly to prevent “brain drain.”
Building expertise in-house is slower than leveraging external expertise of existing vendor solutions
Any technology or product developed by a health system is ultimately owned by the health system. I haven’t come across hospital networks building technologies for this reason primarily. It’s worth considering that health systems usually aren’t well equipped to advertise, market, and sell these technologies. However, the byproduct of internal investments can result in future licenses or spin-outs if a diligent technology transfer department does their due diligence.
EXAMPLE
Health Catalyst is a large publicly traded company that developed a clinical data warehouse to help health systems analyze their processes. The technology, originally called Healthcare Quality Catalyst, was originally developed at Intermountain Healthcare to help them improve the use of their digital clinical data. The development of a multibillion dollar company was likely not top-of-mind in the nascent stages of this internal application, but it has ultimately delivered a financial windfall.
If there are underutilized resources with expertise to build out a product or service, then it may make sense to develop the project in-house. Academic centers with robust research departments may have staff with funding and the expertise to test technical hypotheses. These teams oftentimes function in parallel to IT teams, but likely require some level of ongoing support with implementation and maintenance. As opposed to an academic research organization, it is more unusual at a lean for-profit healthcare delivery organization to have excess resource capacity to dedicate to new experimental undertakings.
EXAMPLE
The University of Utah’s informatics applications group, headed by Dr. Ken Kawamoto, has developed a variety of award-winning EHR applications. These researchers and developers built internally adopted applications, like the neonatal hyperbilirubinemia tool, funded through either the health system itself and/or external grants. Since they are not nearly as complex as a product like an EHR system, focused standalone applications serve a focal user group within the organization while also answering research hypotheses.
As the complexity of clinical medicine increased, the specialization of medicine ensued. It’s difficult to find physicians who span primary care and surgery for example. Likewise, there is a similar delegation and specialization of skills when it comes to technology and tools used to deliver high quality healthcare. Rather than being experts in software development, database management, human factors, graphic design, and much more, health systems may increasingly unlock value by partnering with dedicated external teams that focus on tackling specific problems. Furthermore, a competitive commercial environment pushes those partners to innovate and evolve. Health systems can reap these benefits through lower costs and better tools. Internally developed and funded applications, on the other hand, are likely sheltered from this competitive atmosphere. As a result, end-users at the organization may experience subpar usability and product features with little customer support. Clinical process improvement tools that are developed in-house often cater to sophisticated end-users who are well-versed in the subject matter and requirements. Unfortunately in-house tools often lack the simplicity to be widely adopted and, therefore, unlock change throughout the organization.
EXAMPLE
At Phrase Health, we’ve built a team that’s dedicated to improving operational processes through the use of clinical data. These experiences have come from working with client organizations and stakeholders around the country while also engaging in NIH-funded research initiatives with leading health systems. Furthermore, the Phrase Health team’s experience spans clinical, informatics, engineering, operations, customer success, and design. It’s a diverse, talented team that would have been impossible for us to attract and fund as an internal tool.
Encouraging talented staff to explore workable prototypes and solutions can unlock real innovation and value for an organization’s personnel. However, the adoption of homegrown health IT solutions often requires the tedious, yet important task of maintenance, training, and support. Depending on the use case, this may require 24/7 availability of support to answer questions and address bugs. Similarly, technology is not a static entity and the underlying languages, frameworks, libraries, etc. continually evolve. Without proper maintenance and support, at best this leads to obsolescence of the technology and, at worst, this poses security vulnerabilities that must be addressed in near real-time. Finally, training is integral as an internal marketing strategy to ensure adoption and effectiveness. After all, it’s not helpful to develop an amazing tool if nobody knows how to use it or that it exists.
EXAMPLE
Phrase Health started as a research exploration within an academic health system. We were able to build and deploy the earliest versions of the software with minimal assistance. However, it became clear that our small research team didn’t have the resources to indefinitely take on the responsibility for support, training, and maintenance without a reliable funding source. Handing the software off from research to operations without a future plan to provide patching and updates was not a sustainable solution. After all, my home institution was dedicated to providing clinical care to sick patients rather than supporting a clinical process improvement software application. This ultimately led to our decision to spin out the company instead of shutting it down.
Experienced vendors decrease the implementation time it takes to return value, while also mitigating the risk of miscues during the utilization of clinical process improvement technologies. Effective vendors provide playbooks that can help identify stakeholders, define organizational goals, and monitor value over time to ensure executives’ expectations are being met. This prior knowledge not only accelerates gains from projects, but it facilitates quick wins which build credibility and visibility. Moreover, that knowledge also mitigates the possibility of costly risks and missteps that can delay timelines or even neutralize momentum around quality improvement efforts. After all, it’s easier to hold vendors accountable by cancelling contracts versus reassigning or firing internal employees for not meeting expectations.
EXAMPLE
The Phrase Health team enjoys working with our client sites for several reasons. I personally love how we unlock data and insights for our users. Rather than waiting for applications to be built from scratch or making sense of complex systems, end-users can focus their efforts on quality improvement cycles and optimization efforts. For example, an informatics team can spend more time carrying out their responsibilities of optimizing EHR build rather than exchanging emails with an analytics team regarding data requests.
Health systems have, largely out of necessity, expanded vertically across the healthcare delivery value chain. The HITECH Act thrust Chief Information Officers (CIOs) into managing large technical teams and solutions. However, as technology continues to accelerate and end-users (patients and staff) become increasingly used to seamless technical experiences, it will become even more difficult to keep up with competitive market forces of expert external companies.
Many health systems have identified that their patient-facing technologies require the same capabilities and simplicity that consumers experience with their iPhones, Gmail, or Netflix services. As a result, CIOs recognize the value in buying this combination of technical, clinical, and design expertise from the market. Clinical and IT staff increasingly expect the same experience from their process improvement tools.
Historically, the cost of a “build versus buy” decision is often calculated in terms of licensing fees or personnel. In my experience, however, the true value is reflected in the struggles for quality, IT, and clinical leaders to use their organization’s data to support process improvement. Widespread, easily accessed clinical process improvement data not only supports data-driven decision making, but a data-driven organizational culture. Teams that aren’t using that data or are only using it for a few high-profile initiatives are not acting on, or even discovering, several opportunities to provide better care. Dormant data and analytics will ultimately cost health systems far more than implementation and support costs as the healthcare industry continues to shift to value-based reimbursement. Furthermore, solutions like Phrase Health can oftentimes be cheaper than building out and maintaining custom homegrown solutions.
Based on the organizations I’ve worked for, partnered with, and spoken to, health systems often do not have reliable success achieving widespread clinical data access through homegrown applications, native EHR tools, or even some third party solutions because the platform is only usable for a few core users. I’ve not only witnessed Phrase Health transform organizations’ quality improvement processes, but have worked for one during the transformation. The Phrase team’s expertise in clinical process improvement leveled-up their current efforts by enabling dozens of users to regularly access that data at a fraction of the time with fewer resources. I’m partial to Phrase, but I’ll be the first to admit it will not be the right solution for every organization. That said, I do believe buying these solutions from the market merits consideration.
Shah, Nirav R, et al. “Build vs. Buy: What Should Health Systems Do?” NEJM Catalyst, catalyst.nejm.org/doi/full/10.1056/CAT.19.0615.