The PACS or RIS/PACS environment that seems to hum along problem-free and productively most of the time is likely benefiting from three characteristics of the successful PACS operation: a good systems administrator and/or staff, sufficient network infrastructure (bandwidth), and an indepth understanding of radiology workflow and radiologist needs (versus radiologist wants).
KNOW PACS INTIMATELY
Being oblivious to the inner workings of your PC may not get you into trouble, but this dispensation does not apply to a PACS. Here, problems can be hard to track down if your understanding of the technology is only superficial. To avoid costly downtime, the PACS administrator or staff must have a fundamental understanding of how a PACS operates. Knowing your way around the graphical user interface is not enough.
The knowledgeable PACS administrator appreciates, for example, that when a user hits the image send button, images do not magically leave the PACS workstation and head to their destination. Rather, pushing SEND triggers a chain of sophisticated IT transactions in the PACS server architecture—a call to the main PACS server, from which the main server issues a move request command, and so on—that results in the images arriving at designated workstation server.
An intimate understanding of PACS architecture can help in tracking down and repairing any problems that arise.
The well versed PACS administrator and staff should also possess a fundamental understanding of database structures and DICOM attributes (e.g., study instance unique identifier, series instance UID, negotiable service-object pair classes). In addition, responsible PACS administrators ensure regular PACS upkeep through daily monitoring of all server activity and maintenance of queues and workstations, including defragmentation and database rebuilds.
USE ‘PROPER PIPE' FOR IMAGE VOLUME
Multi-unit multimodality centers that produce prolific quantities of images on a daily basis should expect slowdowns, bottlenecks, and crashes if their network bandwidth is insufficient. It's always tempting to blame the PACS vendor when things like this happen, but you should realize that establishing a sufficiently robust IT infrastructure that will cope with your image volume is the healthcare center's responsibility. An imaging site that wants to push hundreds of megabytes worth of images per day, for example, should not attempt to use an enterpriselevel PACS in an environment with only T1 lines.
Similarly, imaging operations that add substantial capacity without accommodating the extra image load on the system are headed for trouble. A good example would be adding such modalities as mammography, a new digital ultrasound, or a 64-slice CT scanner. In the latter case, it's instructive to point out that a conventional CT may produce 100 slices per case or 2000 slices per day during a 20-patient scanning day, whereas a single 64-slice CT case can generate over 10,000 slices!
Suddenly, staff ask why things are moving so much more slowly. Well, they've increased their image distribution by a factor of 10 overnight! Another scenario could be one in which new imaging sites are added to an imaging center group using a network whose bandwidth was suitable only for its former workload. While time trials may show a five-minute transit time from a center to the PACS archive, this doesn't take into account simultaneous transmissions from other sites. Studies enter a queue in which five-minute transmissions are added one on top of another, sometimes resulting in a relatively more important study entering the queue behind studies that arrived earlier.
A successful PACS environment also will have good router and switch configurations to address DICOM's intense demand on network negotiations.
Communication speed problems can arise when switches and routers are operating in auto-negotiate mode. For instance, if I'm an imaging system that can negotiate a communication speed of 10 Mbps when my maximum speed is 100 Mbps, every time another device asks to transmit to me, I will indicate that the device could connect to me at 10 Mbps, and we then may set a common communication speed of 10 Mbps to complete data packet transfers. With DICOM, that approach can reduce image transmission speed to less than 10% when switches and routers are configured for auto-negotiate.
