Monday, May 25, 2009

Strike Up The Band(width)!

When I first became active in the PACS world, I adopted a goal from my senior partner/mentor: "Sit here, read there". This was to apply to every site, every examination in our enterprise. Today, we have met that goal, both with our group-owned system, and with PACS provided by the hospitals. I can indeed sit at any site within our realm, and for that matter, at any broadband-connected computer, anywhere, and peek at any particular study that takes my fancy. When you think about it, that is quite an achievement.

All of this interconnection requires, well, a connection! That would be the various networks and portals into the Internet. As I have pointed out in a previous post, aptly titled Disconnected!, when the network is down, thus PACS is down, and therefore the whole department sits idle except for extreme emergency cases.

We are feeling the pressure of the network in another way. One of our hospitals has somewhat suboptimal internet connections to the outside world. We have tossed blame back and forth as to why their web-based PACS can be viewed but slowly at remote sites, and why our web-based PACS (both Amicas, by the way) crawls when viewed from within their walls. Trying to view the Agfa Impax of the other hospital system from within the problematic facility is just that, trying.

As yet, we have no good reason for this to be happening. The IT folks at the institution in question have switched us back and forth on various lines and channels, this one having no net-nanny or port-blocking, that one having X speed, another having yet more different parameters. All we know is that the situation is deteriorating rapidly, and we have to do something. To use the buzz-words that get everyone's attention, our ability to deliver health-care is being impaired, and this needs to be fixed.

At this point, our main option is to buy our own network. Our system lives in a neutral spot, external to all hospitals. We are on the brink of purchasing Metro Ethernet lines, also called MetroE's, with point-to-point access for our system. This would also give us direct, very rapid access to our own PACS, and should significantly improve the connection to the hospitals, at least we expect it to do so. At a cost of tens of thousands of dollars per year, we don't want to do this and see no benefits!

There might be one last option. Our state is participating in the Rural Health Care Pilot Program (RHCPP) which is designed to link under-served primarily rural hospitals with fiber optic broadband. The network-challenged hospital has apparently signed on to this initiative, and anticipates a great boost in service. However, I'm not sure we would qualify to participate:

Palmetto State Providers Network ($7.9 million)—This project will connect healthcare providers to a fiber optic backbone to enhance simulation training, remote intensive care unit monitoring, and medical education in South Carolina.

I suppose we could sign up to read from any rural hospitals that are properly equipped to transmit out to us. That would be a win-win situation.

In the meantime, we're about to spend a lot of cash for some local bandwidth. At least one part of the economy will be stimulated. . .

1 comment :

Anonymous said...

Hi Dalai,

We have many rural hospitals in Maine using Agfa PAC's. Usually the Wide-Area-Network (WAN) connection and/or configuration is to blame for these types of problems. We have been moving our T1 (1.54Mbps) sites to Time Warner Metro Ethernet and have seen VERY imprsssed with the increases in throughput. We still have a couple sites on T1's; which have the ability to literally bring down the Agfa Impax system when these sites send multiple large studies (Mammo's, Echo's, etc) at a time. The problem being.... (at least on the Agfa software; I'm assuming a similar situation) the software only allows for so many copy jobs, when many copy jobs are taken by large studies from slow sites then EVERYONE feels the pain! This is because Impax has a limited number of copy threads. The solution really is to get these sites the adequate bandwidth they need to not tie up the core servers very long; that way copy processes can move on to handle other copy jobs. I'm not saying this is your problem but I have seen this situation bring a Job Queue from 50 entries to 300+ entries in no time!

Also, if the PAC's workstations being used is running a multitude of network software (PAC's, RIS, Voice Rec, etc) simultaneously then the following TCP/IP patch might help them:

Microsoft is now restricting the number of half-open connections which can cause pauses, hang-ups, and delays on PAC's workstations. We saw this occur on our Impax stations once Context Server and Voice dictation (not even voice rec) was installed....

Finally, unreliable connections can wreak havoc on PAC's; any lost packets can cause serious probems. Impax (and possibly others) use UDP packets for copy/move job signaling; if these UDP packets are lost then serious system degradation will occur!

Good luck