Skip to main content

Advertisement

ADVERTISEMENT

Ready for a software upgrade?

Anybody with a computer knows that software updates and upgrades are a fact of life, whether it's the umpteenth iTunes patch you've installed this year or a major revision of your document imaging software.

Simple updates or patches for many applications are released monthly (or even weekly) and installed without too much fuss by most users, whether on a personal PC or on an enterprise-wide scale. Major upgrades, however, are another matter. Moving from one generation of software to the next version can significantly impact operations and functionality, and can involve substantial costs.

For behavioral healthcare agencies with limited IT resources and budgets, upgrading software can be a daunting prospect—one reason that many organizations rely on older (and sometimes heavily customized) applications.

“Behavioral healthcare is a field that is very comfortable using older software,” says Erin Audette, senior consultant at Brown Consulting in Toledo, Ohio. “There is a natural resistance to change, but these organizations also have concerns about the cost of the upgrade and the cost of the training involved.”

The decision to upgrade to the latest version of software, whether an electronic medical record (EMR) system or Microsoft Windows, should be based on a thoughtful weighing of the value of the new functionality against the cost of deployment. With careful planning and testing, an upgrade can be well worth the time and money.

Risk aversion

Upgrading mission-critical software can be a risky proposition. Applications are seldom perfect, and vendors typically release dozens of patches and updates to fix bugs they missed during the development process.

The migration from Windows XP to Windows Vista is a good example. Vista's early bugs caused problems for some corporate users, and a few even stepped back to XP until the issues were resolved.

Cost is another reason many behavioral healthcare agencies delay software upgrades, Audette points out, adding that organizations should perform a cost-benefit analysis to determine if the update's new features will increase productivity or efficiency. Audette says providers need to ask, “Will the software provide an improvement in the quality of care to their clients, and will it allow them to keep better records and to better track quality outcomes?”

The software itself isn't the only factor impacting the upgrade's total cost. Time and costs are involved in training staff to use the updated features/system, and there could be costs associated with problems that occur during or after implementation. The new software could require a hardware upgrade, further complicating the process and making it more expensive.

Software customization also can impact the decision to upgrade. If you've heavily modified an application, upgrades will be more complicated because changes you've made in the source code won't be reflected in the new version. That was the case for the Center for Behavioral Health (CBH) in Bloomington, Indiana, which recently merged with Quinco Behavioral Health Systems of Indiana and Centerstone of Tennessee.

CBH had greatly customized its third-party EMR system. Yet “the more customization you do, the more likely the upgrade won't work because you changed something in the architecture that doesn't flow the way it used to,” says Dennis Morrison, PhD, CEO of the Centerstone Research Institute and former CEO of CBH. “It became increasingly difficult for us to do upgrades, and eventually we determined it was not worth the effort to continue upgrading.”

Plan and test

If your agency decides to move forward with an upgrade, careful planning and a robust testing program can help ensure a smooth transition.

The timing of the upgrade is important. One way to avoid potential upgrade headaches is to wait for your vendor to release the first set of software patches for the new version. This will help you avoid some of the compatibility problems that plagued early adopters of Windows Vista and will make the transition easier for your staff.

“No matter what the software is, whether it's an application or Windows, people will wait for the 1.1 release,” observes Paul Kirsch, marketing manager at The Echo Group, a vendor of enterprise software applications for the behavioral healthcare space. “That philosophy is always out there, to see what patches are released before adoption.”

Well before deployment of the new software is set to begin, inventory your software and hardware assets, and make sure that you are using all of your contracted software licenses. These steps will help make sure that all of your computers are able to use the program and that you aren't paying for licenses that you won't use. In addition, set up an implementation plan with a schedule broken down into simple components. Educate staff on what the software will do for them, and solicit their feedback.

“If there is a major new functionality, you may need to change your work flows or update your documentation,” Kirsch notes. “And you want to make sure you are training your people on that before releasing it to the masses.”

Perhaps the most important part of the upgrade process is setting up a test environment to ensure that the new software will work on your hardware, and that interfaces to other applications still function in the new environment. Create basic work flows and test plans, and have staff work through them on the updated software.

“It's very important to set up a pilot program with the software company,” Audette advises. “You need a test environment where the clinicians can log in and use the system without impacting your actual data.”

A vendor can help coordinate this testing phase. If the software is hosted under an application service provider (ASP) model, make sure the vendor can establish a test environment where you use your own data.

“We really had to wring out any of those issues in the test phase,” Dr. Morrison recalls. “We had a multidisciplinary team that oversaw the health record system. As the upgrades came in, the team would bring that software up on the test server and report what effect the new functions had on the items we had customized.”

It's also important to test the system with multiple users logging on at the same time. While this process is not entirely reflective of real-world conditions, it can help identify speed or performance issues that could arise when dozens of staffers access the system at once.

“When you go into full production, you never know how the system will respond with a full load on it,” notes Dr. Morrison. “Minor changes can have cumulative effects when hundreds of people hit the system at the same time.”

Make sure to schedule the upgrade during a down period or over a weekend to give the IT staff time to work through any glitches. “If your billing cycle requires bills to go out on Friday, you wouldn't do an upgrade on Thursday night,” Kirsch points out. He adds that it's important that the entire organization, not just the IT department, take ownership of the upgrade process. Clinical staff should be involved in making the decision to upgrade the software and testing the new system.

“A lot of organizations look at this as the IT department's job to upgrade the software,” explains Kirsch, “but the IT staffers don't know the details of how the system is really supposed to work. Their jobs aren't going to be interrupted if it doesn't function properly.”

Brian Albright is a freelance writer. Behavioral Healthcare 2008 October;28(10):28-29

Advertisement

Advertisement

Advertisement