Technology
e-Newsletter
Intelligence Unit Special Reports Special Events Subscribe Sponsored Departments Follow Us

Twitter Facebook LinkedIn RSS

Does Your Hospital Have the PACS It Will Need Five Years From Now?

Carrie Vaughan, for HealthLeaders Media, December 1, 2009

For the November issue of HealthLeaders magazine, I spoke with two large health systems about their strategy regarding PACS and what healthcare organizations should be doing to prepare for an interoperable healthcare system where this information will need to be exchanged with other providers (PACS: The Next Generation, November 2009). The University of Utah Health Science Center, which recently converted to an iSite PACS from Andover, MA-based Philips Healthcare, and Iowa Health System, which switched to a PACS from San Francisco-based McKesson Corp., shared their strategies to improve speed, stability, and access to their PACS while increasing storage and clinical functionality, as well.

I was curious about smaller, community hospitals' strategy, so I contacted John Rousseau, director of the radiology department at Alice Peck Day Memorial Hospital in Lebanon, NH. In 2007, his hospital, which serves more than 20 communities in New Hampshire and Vermont, implemented a Web-based PACS system from Boston-based AMICAS Inc. that has roughly 300 users. Here's what he had to say regarding his PACS strategy.

HealthLeaders Media: What is your history with PACS?
Rousseau: Our PACS system was implemented in 2007. Prior to that, we had no PACS system in place. We had some workstation software that we used to forward images to our radiologists' homes and a couple of e-film licenses that we used to make CDs. We were looking for a vendor that would allow us to integrate one PACS system for community hospitals that had disparate RIS systems. We implemented a Web-based PACS system that we deployed using three spoke servers at the other hospitals that forward images to our main server. This workflow allows for each hospital to have their interfaces and modalities point to the spoke server, and then the study is forwarded to the hub server over a wide area network. In the event that the main server goes down, the spoke can still continue to operate locally. Our main storage is a storage area network, which we find attractive for its reliability and scalability. As we move forward, it's our hope to also migrate our disaster recovery back ups onto spinning disk. At this time, we're using a worm drive that can store 30 gigabytes per disk and, as we've grown, we realize that we've outgrown our 80 disk library very quickly.

Comments are moderated. Please be patient.