Virtual Lifesaver

NEED FOR THE HUMAN TOUCH
One factor to consider when performing a major technology migration is the human resources that will be required. Concurrent to rolling out these new technologies, we were adding many new systems and dramatically extending the reach of IT in clinical and nonclinical areas, both inside and outside of our hospitals and in new locations. The virtualization technologies don't decrease staffing because applications are still present--they just run more efficiently. If anything, we've needed more competent and specialized people to manage these new technologies in addition to training our existing staff.

What we're doing to increase our availability across our entire processor complex has a direct impact on patient care. Now that we have a VMware farm established, we don't have to run through the time-consuming due diligence for additional hardware and application space when a new project comes in. We're more agile, can turn on demand faster, and see ROI more quickly. Our staff can access patient data on a moment's notice, and therefore offer better quality of care.

After having implemented server virtualization, we found an excellent opportunity to boost capacity with it for our workflow automation projects. The information management staff handles myriad tasks such as printing reports, coordinating the input of outside agencies,, and data entry across all departments, including admissions, billing, emergency department management, lab, medical records, pharmacy, and quality management. The group uses a scripting tool called Boston WorkStation to help automate those time-consuming and repetitive tasks. We're not talking a few scripts here, but rather 400 scripts throughout the organization.

Efficiency comes with a price. As requests for automating tasks poured in, server space dwindled. Eventually, there were 200 scripts on one server, which filled that server's schedule and prevented staff from filling requests for additional scripts. To solve this problem, Christus placed the scripting projects in the virtualized environment and realized an immediate boost to the capacity.

Having a single virtual server per region has enabled Christus to spread out its scripting tasks, making them more manageable. Taking the "many hands makes light work" approach, an agency update that we need to download and disperse into our health information systems across all regions, which would have taken eight hours to complete with a typical standalone script, now takes a fraction of the time when split up among several virtual servers.

One of the most common data entry tasks that the information management department is asked to complete is to script in annual raises. With anywhere from 1,000 to 5,000 employees in any one region, such a job would require four to five people over a week of data entry work to accomplish. Using a script, we can accomplish this task in much less time. Often a single computer working approximately 24 hours can script the raises for an entire region's employees, ensuring that the most important resource of a hospital, the staff, is rewarded in a timely manner.

Being able to load additional scripts onto the virtual servers creates more opportunities for efficiencies with our workflow automation projects, as well as the system of shared functions within the projects themselves. We also have improved staff efficiency, data accuracy, and overall cost savings.

Although the Christus virtualization project went smoothly for a project of this complexity and size, there are still opportunities to share key lessons. These lessons can be categorized in the project life-cycle stages of planning, design, testing, migration, and transition to operations.

First and foremost, the time we spent planning and testing paid off. The study allowed us to glean key information regarding our biggest opportunities: payback and the ease to achieve the payback. As for design, the time we took to calculate the optimum virtualization farm configuration with regard to cost and performance also paid off.

Another success factor was spending the appropriate amount of time in the lab validating study findings and assumptions on migration and application performance, and ensuring that there was a quick way to swing production systems back to physical hardware in the event of a performance issue in order to isolate and troubleshoot the environment.

Achieving a mind-set with regard to application vendor support was important. In the early stages, we let a few vendors rattle our cages with statements regarding their lack of support for VMware. As we continued to push forward, we realized that most vendors didn't understand the technology, and the expertise actually lay with ourselves and our project implementation partner.

We pushed the vendors to provide evidence of why they couldn't support a virtualized environment. Most of the time, the vendors didn't have the experience with virtualization. That gave us an opportunity to prove the technology for them. After migrating more than 800 servers to the VMware farm, we've had only one issue that forced us to reverse the decision to virtualize the application.

Finally, don't under- or overestimate the consolidation ratios that can be achieved. Conduct careful observation of application performance during testing and deployment, and build flexibility into the deployment and migration plan to accommodate variances.

George Conklin is CIO, Mitch Lawrence is lead application analyst, and Mark Middleton is system director of IT architecture for Christus Health.

Continue to the sidebar:
Action Plan: Putting Virtualization In Project Life-Cycle Stages Of Planning