Thinking customization? Proceed with caution

It seems long ago that behavioral health providers first were challenged to implement clinical automation. The focus was on transitioning from handwritten clinical documentation to data entry on computers, with the ultimate goal of going paperless. Given that this was so new at the time, one of the primary concerns was figuring out how to get staff buy-in for the idea of using computers to document treatment.

One widely used strategy to support the implementation and adoption of new clinical applications was to customize them. The customization process consisted of negotiating with the software vendor to develop functionality outside of the standard application. The thinking among providers was that if the computer screen looked as close as possible to the paper document, staff would be more comfortable in the transition to using computers.

Further, many staffers didn’t have adequate keyboarding skills and were new to computers, so it made sense to keep documentation and supporting business processes as familiar as possible to ease staff gently into clinical automation. Because many vendors were still relatively new to behavioral health and had a vested interest in growing their client bases while developing their applications, they were often amenable to providers who made requests for software customizations.  

Then and now, any decision to customize presents a greater degree of risk. The primary risk is that resource needs will increase due to the added complexity of system implementation, greater need for support, greater testing and maintenance requirements, and a higher cost of system acquisition. However, many behavioral health providers took the risk of customizing their software platforms in the past because they had the benefit of higher levels of grant funding, more technology staffing resources, and fewer systems-related insurance and regulatory requirements. There were other reasons too: a wider range of clinical systems were available, providers generally hosted systems onsite, and some types of patient data were specially protected by Federal law or state requirements. This idea of integrating HIT across providers for purposes of electronic patient data exchange was still very much in the future—all data exchange was manual.

For all of these reasons, behavioral health providers—and much of medicine—were essentially able to develop HIT and systems to fit “their way” of doing business, both culturally and clinically.

The end of the “have it your way” era?

In today’s world of HIT, the idea of customizing software so you can “have it your way” is virtually a thing of the past. The momentum of change today is driven by broad efforts to achieve Meaningful Use stages, provide more accountable and cost-efficient care, implement reliable interoperability of customer data, and reduce EHR implementation and support costs primarily through the use of cloud-based enterprise systems.  

The dramatically increased need for common and certified EHR functionality to meet Meaningful Use requirements, together with the efficiencies of cloud-based application models continues to drive developers toward the creation of more standardized, cloud-based, and configurable EHRs and other products (see Figure 1).

Instead of customizing your own server-based copy of software, vendors are more and more likely to recommend configurable, “out of the box” EHRs and other applications. Although behavioral health professionals (with the exception of eligible providers) cannot presently qualify for federal Meaningful Use incentives, most vendors and much of the medical world have to meet these requirements in any EHRs they adopt.

Accountable care has emerged as a force that is transforming the way healthcare is organized.¹ Providers engaging in partnerships geared toward increasing care quality and reducing care costs need access to the interoperable electronic patient records. And there’s an imperative for behavioral health to be a part of this integrated healthcare information system. The National Council for Behavioral Health, various states, and other entities are heavily engaged in developing the infrastructure necessary to meet this imperative. Recently launched Federal and state efforts are chipping away at the legal and technological hurdles that stand in the way of better integrating systems and sharing of behavioral and physical health information.²
    

Configurability can mean lower costs, easier upgrades

Clearly, standardized and interoperable applications are here to stay. Behavioral health providers who are weighing the risks of customizing must, in addition to the factors mentioned above, consider that vendors facing more standards requirements are increasingly reluctant to support aging or customized versions. Such versions complicate their ability to develop, test, and release increasingly frequent software upgrades that providers depend on to get the latest features, meet time-sensitive requirements, or expand consumer and patient access to personal records, wellness information, or other resources.

While customization is generally less attractive than before, cloud-based EHRs offer robust solutions that are often less expensive to own. Because these applications are designed to meet the needs of a wide range of users, vendors are providing highly configurable capabilities that can be readily adapted to meet a range of particular needs in fields that include behavioral health.³ The capability to configure a program specific progress note or develop questions for an assessment tool within the framework of an enterprise application is fairly standard. The difference between customization and configuration in many current applications—beyond the added cost, of course—boils down to the difference between coding and developing a customized set of features versus configuring similar features using a vendor-supplied configuration “wizard” or menu.⁴  

Some exceptions to the rule

So, a question: In this changing landscape where vendors are increasingly focused on standardization and “out of the box applications” offer improved configurability, are there any circumstances in which customization remains a viable option today?  

Some providers may still consider customization at the behest of an entrenched workforce or exceptional culture, or face unique circumstances where specific state or regulatory requirements impose demands that are beyond the configurability of ‘out of the box’ applications. Or, an “out of the box” application might closely fit many of an organization’s needs, yet be lacking a few vital capabilities. Rather than search for a third-party application to fill the gap, the organization may elect to purchase a customization rather than having to select and integrate a third-party application. 

But these situations are less common. The momentum of change continues to make customization more costly and difficult to justify.  

As software applications continue to proliferate in more areas of behavioral health organizations, they come to impact nearly every function. For this reason, it is logical to involve these functions as stakeholders when an organization considers purchasing and implementing a new enterprise application. Anyone who develops, manages, or reviews the data that an enterprise application produces should be involved in discussions regarding application replacements or upgrades. Such involvement is especially valuable when it comes to determining whether a customization is truly needed and financially justified.

If you lead or serve a provider organization that is considering customizing an enterprise application, I encourage you to do three things:

• First, benchmark. Instead of emphasizing how an application must be made to work differently to support “your way,” select a cross-functional team to consult with similar organizations that use the same application to see how they tackled similar problems.
•  Second, evaluate how using an application’s configurability, together with some process reengineering, could offer a better long-term solution than a commitment to customizing and testing update after update of a major enterprise application.  
• Third, understand your vendor’s own IT roadmaps and product development strategies. Current trends in the environments of healthcare, healthcare regulation, and health IT point to greater levels of standardization, not only in process, quality, and outcome measures, but specifically in key performance and certification requirements for EHRs and related enterprise applications (i.e., Meaningful Use, interoperable care-coordination and health records, clean and compliant claims, etc.).  

If your organization has always been one of those “we do it our way because that’s how we’ve always done it” shops, today’s environment gives you a perfect excuse to reconsider the cost and value of being different. Customizing enterprise applications probably isn’t as wise as it used to be.

Harrison White, LCSW, CPHIT, CPEHR is employed by Gateway Foundation as a Senior Business Application Analyst.