When Fallon Clinic wanted to implement Epicare, an electronic medical record application from Epic Systems Corp., the healthcare organization realized it would need to overhaul its network. Worcester, Mass.-based Fallon supports some 26 sites and up to 280 doctors throughout central Massachusetts and could no longer depend on homegrown methods and lightweight connections to keep the network up and application performance optimized. Susan Paul, the IT infrastructure director, recently talked to Network World Senior Editor Denise Dubie about the $24 million investment her organization made to revamp its network and where Fallon stands today.
When Fallon Clinic wanted to implement EpicCare, an electronic medical record application from Epic Systems Corp., the healthcare organization realized it would need to overhaul its network. Worcester, Mass.-based Fallon supports some 26 sites and up to 280 doctors throughout central Massachusetts and could no longer depend on homegrown methods and lightweight connections to keep the network up and application performance optimized. Susan Paul, the IT infrastructure director, recently talked to Network World Senior Editor Denise Dubie about the $1.5 million investment her organization made to revamp its network and where Fallon stands today.
First tell me a bit about yourself and your network at Fallon.
I am the director of IT infrastructure for Fallon. Fallon Clinic has about 26 sites scattered throughout central Massachusetts that connect back to our data center in Worcester. We have approximately 260 to 280 doctors who service those sites. Over the past three or four years we have been planning out an implementation of electronic medical record (EMR) application and as a result of that we needed to do a lot of bolstering of the infrastructure because it was pretty old and had been not well cared for, let’s say, in the past.
What areas needed to be pumped up to support the EMR application?
We’re a Cisco shop, and we needed to migrate from a shared hub to a switched LAN at each one of the sites. We upgraded with Verizon from a small frame relay connection, a 256Kbps connection to 10Mbps Ethernet-like transparent LAN service connection to each site. We also put in a full back up line to each site so if our primary lines went down the backup would take over. We installed new computers, and obviously we were bringing in new servers. I also recognized that we needed upgrade how we monitored service levels.
How many servers and desktops do you support?
We have 130 servers, both Windows and Unix, and about 2,600 Windows desktops. The 26 sites are connected to each other via 10Mbps Verizon wide-area connections, and then tied back to the Worcester data center over a 100Mbps connection. The EpicCare application is running on a Citrix farm implementation using HP Titanium servers running AIX. That entire infrastructure runs at the data center so it was critical that we have a really solid network in place to be able to get the application out to all the sites.
Do you mean service-level agreement monitoring and reporting?
We have right now an SLA with Epicare for uptime of about 100%, and that’s why we have so much failover. The Epicare server is clustered, so we have a disaster recovery site if that cluster goes down. As we were planning, I realized I needed to have in place a system that would provide monitoring, capacity planning, trending so that we would be able to understand problems were starting to happen before we got a phone call from a user that we had a problem.
What product did you implement to report on SLAs?
We put in software from Heroix about a year ago after an RFP process. We picked it because it was very easy to use. We selected it basically because it’s ease of use, flexibility in configuration as well as flexibility in presentation and reporting.
How was Heroix easy to use?
Heroix has a central console that populated itself automatically. We could also modify or customize the central console design. One of the reasons this appealed to us is because we do have 24-hour operations, and we have data center operators that are there overnight. We wanted to give them the ability to be able to look at a high-level picture of the network and see if there was an issue at one of the sites. Then they could drill down into that site to understand what the issue was so if a page didn’t go out they would be able to page the person responsible or needed to fix the problem. There was a lot of customization and it was very flexible with how it would present the data to us. It also learned our network quickly.
How is the Epicare application doing with revamped network?
We are in phase two of our roll out. The first phase was practice management, rolling out scheduling and billing to all of the sites. We had a homegrown application running on a mainframe that captured patient data such as labs and medications and telephone message dictations so we have been slowly converting that off of the mainframe into Epicare. We are at the end of the phase two and ready to go into phase three, which is rolling out Epicare to all the sites. And it has been performing great. The nice thing about the network upgrade is that it now works behind the scenes. The network will fail-over to the backup and no one even experiences a hiccup. We’ve had it happen a few times and it’s been totally transparent to our end users.
How did you balance upgrading the network and rolling out new applications without disrupting services?
It required a lot of planning. As we were upgrading the network, we brought the new services online and kept the old services for a period of time. On the LAN, we would bring a site down at night and bring it up the next day on the new switched network. We would never do a big bang because you are guaranteed to have a problem without having a failover in place. It’s been about a three-year effort, so it definitely didn’t happen overnight.
