Skip to content Skip to navigation

Thinking customization? Proceed with caution

August 15, 2013
by Harrison White
| Reprints

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.1 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.2
    

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.

Pages

Topics