From left, Mary Gathers, clinical systems analyst, Intermountain Health Care (IHC), Deanna Welch, corporate director of digital imaging services, IHC, Joe Boyce, MD, lead PACS informaticist, IHC, and Darin Day, PACS system administrator at Primary Children’s Medical Center.

Sometimes a project can fulfill several needs at once. This was the case with the project that originally was iintended to meet the imaging disaster backup and recovery needs of Intermountain Health Care (IHC), Salt Lake City. An ancillary benefit was that IHC also received a great vehicle for enterprise-wide image distribution.

IHC is a combination health plan, hospital system, and physician group now serving Utah and southern Idaho. It is organized into five regions having four or five hospitals each, along with numerous outpatient clinics and small, rural hospitals. Radiology images produced in and used by each region’s hospitals are stored on a single picture archiving and communications system (PACS) installed at a central location within the region. Not all hospitals, however, have PACS yet. All five regional PACS were manufactured by the same vendor; this standardization accords IHC various financial and operational benefits.

Once enterprise-wide image distribution commenced, traffic on the network mushroomed. Joe Boyce, MD, is medical informaticist for IHC’s urban northern region (based in Ogden, Utah) and is lead PACS informaticist for the entire health system. He says, “We were anticipating that day since we first began getting into PACS, and it was not just growth in PACS that we were anticipating. We were also expecting a lot of extra volume eventually going through the pipes as a result of our efforts to go paperless in as many locations and departments as possible. We have had ongoing efforts to scan paper documentation and put it all into electronic storage.” Still, while IHC could claim adequate network capacity to handle linking the five PACS, the organization did not automatically assume that there would be no slowdown of traffic as a result of the surge in data volume.

“At the onset of our preparations for enterprise-wide distribution, we had no clear picture of how much demand would be placed on our WAN by this,” Mary Gathers, clinical systems analyst at IHC’s headquarters in Salt Lake City, explains. “We would be producing a combined total of 700,000 imaging studies a year from the five regions and pulling them into one central location. We would then be pushing those images back out to every authorized clinical user requesting them. Our WAN was already supporting a lot of traffic generated by our hospital information system and all our other clinical systems, including laboratory information, operating-room management, and even our phone systems. For obvious reasons, there was concern that sending images along with all that other data through the infrastructure and its connections could, at peak demand times, slow down the entire clinical network.”


IHC, under Boyce’s leadership, organized a team to assess the situation and determine the impact that enterprise-wide PACS could have on the WAN. “We wanted to be sure that we would not be shooting ourselves in the foot by tying the PACS together,” he says. “To reassure ourselves that no harm would come to our other clinical or business data traveling down those same pipes, we first compiled spreadsheets to calculate the approximate volume load that we would have. We looked at how much PACS volume was currently produced by each region, what time of day the peaks were occurring, what kind of connections were being used to carry images from the individual hospitals to their regional centers, and how big their WAN connections were.”

At best the large hospitals had a 1-gigabit fiber-optic backbone with 100MB hubs. Within each region, the PACS facilities connected to one another and their central offices via transmission-link 3, digital-signal-level 3 lines rated at a minimum of 45MB each. The smaller hospitals, the outpatient clinics, and most IHC physician offices typically employed either T-carrier 1 lines or digital subscriber lines, with some using cable modems instead. “It was difficult to get vendors to tell us how much bandwidth we would honestly need to be able to connect the five PACS,” Gathers says. “They were more interested in selling us equipment to give us the maximum possible bandwidth and having us push everything out over OC3 lines, or whatever were the largest pipes that they could come up with, but all we wanted to know was whether it could be done with our existing setup.”


The answer that was eventually obtained indicated that the existing infrastructure could handle the volume generated by the five PACS in an enterprise-wide distribution scheme. IHC executives concluded, however, that the network would be much better off if the data files were first compressed before traversing the network. “Some of us were worried that compression might result in images that were of less-than-adequate quality when they were viewed on a typical monitor,” Boyce says. “The concern was that our users would see a definable difference between compressed and uncompressed images that would affect certain diagnostic findings.” This prompted IHC to obtain samples of compressed images and make side-by-side comparisons of them with uncompressed versions of the same studies. Potential users quickly became convinced that there were no significant differences between the two types for review use.

“Our confidence also was boosted by work formally looking into this very issue and coming to the same conclusion that we had informally,” Boyce says. Concerns over the possible effects of compression turned out to be of lesser consequence than workplace environmental factors, such as monitor quality and light in a room. “Our initial thought was to turn to the same vendor that had supplied all of our PACS installations,” Boyce says. “We assumed that this would be the easiest and most satisfactory way to accomplish this, since there would be no connectivity issues involved, what with the systems having a common origin. Then we discovered that our PACS vendor’s products did not really support image compression. That forced us to look at other potential solutions.”

IHC sought proposals from several vendors before settling on a web-based overlay product that was installed in July 2002. Images acquired by each regional PACS are sent via the DICOM protocol to IHC’s central data center into the vendor’s web-based image server. The data center manages three servers, one to receive images and serve them up to clinical users (production server), a second server that is a mirror of the first providing full redundancy, and a third server for test and validation tasks. The Windows 2000-based production server stores the DICOM data for a period of 7 days, providing a level of redundancy to the regional PACS. In addition, the production servers utilize Joint Photographic Experts Group 2000 compression protocol to produce a second copy of the data for clinical distribution. With annualized study volume of 700,000-plus radiological studies per year, and thousands of clinician requests per day, IHC relies heavily on its SAN for productivity, scaleability, and performance.

Managing 5 TB of storage requires systems with robust functionality. Enterprise storage systems must be scalable to handle the anticipated growth from digital imaging, secure and disaster tolerant, and based on open standards to integrate into any network. IHC chose storage area networks as a way to help consolidate and more easily manage the large amounts of storage while reducing the cost of ownership. IHC utilized an IBM SAN, which currently handles a total of 21 TB of storage, and is accessed by no less than 15 mission critical applications. The SAN is comprised of 3 separate IBM TotalStorage Enterprise Storage Servers (ESS) systems which assures maximum reliability.

“The results-review system is a tool that provides laboratory values, radiology reports, progress notes, and other key information contained in our electronic medical record,” Boyce says. “We intend it to be a one-stop shop for the physicians in that it provides a clickable link to the diagnostic image.” Because the linkage of the five PACS is web-based, installation was fairly simple, involving use of little more than standard web servers with software that was downloaded directly from the vendor’s web site. “It was not necessary for the vendor’s people to be present while we installed,” Boyce says. “We had the system up and running in a couple of days.”

Gathers adds, “One thing that made the installation so nice is that we did not have to connect Health Level 7 (HL7) interfaces. Basically, what we are doing is taking validated images from a system that already has HL7 interfaces connected to our radiology information system and then moving them through a Digital Imaging and Communications in Medicine (DICOM) interface, plugging into the web-based product’s storage-area network. All we needed were DICOM point-to-point connections from the central core system. Afterward, that acted as a network gateway that automatically pushed images out to the individual regions.” The web overlay product had no limits on the number of allowed DICOM associations, and Gathers indicates that IHC is taking full advantage of that. “Thus far, we’ve connected 30 systems from across the state and have seen no problems with it,” she says.

Since installation occurred only a few months ago, Boyce reports that traffic congestion, if any is to materialize, will not be a factor for some time. “Because we are just in the early phases, we have not yet seen the full volume of traffic going out, although right now we are getting full volume coming in,” he says; “however, we now have in place the necessary software to monitor traffic and determine how much WAN capacity we are consuming. We plan next to install software that will allow us to segment and perform load-balancing and prioritization on those WAN connections. I think that we are going to be in very good shape when all is said and done.” The web-based solution was offered by a fairly young company. Boyce says, “The vendor clearly had a good product and implementation plan that showed a keen awareness of the setup and operational issues involved. Their well-written and concise reply to our request for proposal, demonstrated that they understood what we were trying to do and how we worked. It also had a major East Coast medical center that it could point to as an example of a successful and satisfied user of the product.” Another reason that IHC opted to use this vendor was that the product would permit IHC to kill a second bird with the same stone.

“In addition, we had enterprise-wide distribution needs that would be difficult to meet with our current system,” Boyce explains. “While our five PACS have functioned well for our radiologists and key clinical users within the hospital setting, the fact remains that each PACS gives users access to only one copy of each image in the archive when that image is more than 30 days old. I was deeply troubled by this. It was my strong belief that we needed to have at least a second copy of the image maintained safely at some other location so that, in the event of a fire in the server room or some other catastrophic occurrence, users would still be able to obtain the images that they requested from the system.”

Boyce has worked as a NASA flight surgeon and at a US Department of Energy nuclear testing facility. In both positions, the necessity of avoiding the potential of single-point failure within systems was clear. For example, he says, “The space shuttle has four computers running on one operating system and a fifth computer that is totally separate, with a different operating system and software. Three of the four computers have to agree or the fifth computer takes over. We wanted our imaging distribution to take that same kind of approach: to be totally redundant, not just another web server with a second copy of data sitting in the same regional data center. I wanted it to be at a completely separate location far away from the other system, with completely separate power supplies.”

Thanks to the web-based overlay product, IHC now has triple-point redundancy of images. Boyce says, “In addition to the image in the PACS archive, there also is a copy on the network gateway, and there is another on the separate web system that we obtained from the PACS vendor for local use.” Gathers indicates that IHC is in the process of enhancing its image-protection capabilities by creating a tape backup library, which eventually will evolve into a hierarchical storage-management system.


IHC began implementing its web-based PACS overlay shortly after acquiring it. Installations, initially performed at one hospital per month and now at one per quarter, have been a challenge because of the number of users who must be trained. To address this, IHC established a front-line support team that provides comprehensive instruction to a selected group of each facility’s users, with the expectation that these trainees will then be available to answer questions from their departmental colleagues who are attempting to master the operation of the system. This approach has worked because, Boyce says, “Training for clinical users is fairly straightforward. Most of what they need to know is self-taught. We simply download a Java” engine from the vendor’s web site, and the user then follows the interactive tutorials. It also helps significantly that the tool set on the user’s desktop is fairly similar to the one employed by the PACS vendor.”

Although the web-based overlay is simple to use, it is sophisticated enough to serve as a stand-alone PACS. Boyce notes that IHC will evaluate using the web-based overlay for the health system’s dozen or so rural hospitals that remain without PACS. Whatever course IHC elects, the enterprise can take comfort in knowing that its earlier investments in network infrastructure are now paying off.

Rich Smith is a contributing writer for Decisions in Axis Imaging News.