All health care organizations own a lot of legacy standalone clinical systems running on aged operating systems and old hardware. I have 20 specialty clinical systems still running Windows NT and Window 2000. If I did not have a 64-bit virtual environment to manage and protect these systems, my computer environment would be pretty much a nasty mess.
Network “rubber room”
First, I would need separate, standalone hardware for each legacy system; that would take up space and power in the computer room. Next, I would need what I refer to as a “network rubber room” to protect the rest of my network and other systems from my Windows NT and Windows 2000 servers, which no longer receive security patch updates from Microsoft.
Finally, I would need to put these servers on a separate network backbone or minimally, a restricted subnet, with a firewall appliance and intrusion-protection appliances between it and the rest of the health care organization’s network. My network team would have to run monitoring software to ensure that all the known viruses in the Microsoft OS world weren’t finding ways around the firewall and intrusion protection. If a virus did get through to my legacy standalone server, my only choice would be to pull the systems off the network and rebuild it from scratch or a backup. This, of course, would generate a significant amount of downtime, which is never a good thing for a high-availability healthcare data center system.
The virtual server environment prevents all that. I have 20 legacy servers running in their own unique environments as virtual clients on a 64-bit Intel Corp. blade server running Windows 2008 R2 Enterprise Server in a virtual clustered environment.
The first question people ask when I explain this is, “Why are you running Windows NT and Windows 2000 systems?” My reply is, “I really don’t have a choice.” The vendors who design and build these systems tend to run them forever. Even if I had security patches, I would need vendor approval before applying them. This would include any new drivers and dynamic link libraries as well.
For a health care CIO, Windows Terminal Servers and Citrix Systems Inc. farms also fall within this category. That’s because the front-end client software for these legacy systems requires legacy restrictions as well. For example, let’s say you have an enterprise lab system running on Hewlett-Packard Co. Unix high-availability servers using Oracle Corp. Real Application Clustering (RAC), and the front end of this system has restrictions on the PC versions; the OS software, including approved Microsoft security patches; the Internet Explorer version; and the version of Citrix that can be used. Trying to manage the lab system’s fat client on a thousand different laptops and PCs would be time- and labor-intensive. Instead, a good choice would be a virtual Citrix farm serving the lab system with all of its unique restrictions, running virtual clients under a Windows 2008 R2 virtual cluster on a 64-bit Intel blade server.
The cost of such a virtual server is less than the cost of standalone Citrix servers, but the real savings come in being able to manage the front-end systems centrally in a virtual Citrix environment. This environment saves money on the PC hardware side of the equation as well. Instead of spending money on high-end PCs and laptops, I can use less-expensive PC or laptops -- even thin client hardware -- as the front end, and still provide the end user with a high-performance application experience.
You may find others in the IT community who will state that Citrix servers and Microsoft Terminal Servers -- now known as RDS -- are not good candidates for virtual servers because they are resource-hungry. I have had good results with [implementing] Citrix servers in a virtual environment. Performance has been excellent, especially using 64-bit Intel servers. The features of a virtual environment complement the Citrix management features, and make overall system management easier
Labor requirements and flexibility
Labor and the ability to manage systems centrally are virtualization's key saving points on which a health care CIO should focus.
Flexibility is another requirement you can satisfy with virtualization. Let’s use the same example of the client/server lab system with physician order entry and real-time interfaces to an electronic health record (EHR) system. The lab system runs Unix and Oracle RAC, and the front end is a Visual Basic Version 2 (VB2) application that requires Internet Explorer 6 and the Windows XP operating system.
You end up purchasing a thousand PCs and laptops with a downgrade option for the operating systems to run XP but with 4 GB memory, a large hard drive and a 3.2 GHz processor to accommodate the fat client. You install and roll out the lab systems, and everything works great.
Then, senior management decides to purchase a state-of-the-art client/server EHR system that also has unique front-end requirements. But the EHR system requires Windows 7, Internet Explorer 8 and .NET Version 3.5. What do you do now when your end users tell you they want both systems running on the thousand clinical PCs and laptops you had purchased for the lab system?
You could run virtual machines on the laptops, and users could switch between operating systems whenever they needed to access one system or the other. Personally, I don’t think that would go over well with physicians. Basically, you have no choice but to offer one or both of these client options, and run them under a Citrix or a Microsoft RDS environment. This kind of problem is much more prevalent in health care than in most businesses.
Al Gallant is the director of technical services at Dartmouth-Hitchcock Medical Center in Lebanon, N.H. Let us know what you think about the story; email firstname.lastname@example.org.
This was first published in March 2010