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.
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).
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.
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.
The key to avoiding this is locking in your communication speeds based upon the device's capabilities, thereby eliminating negotiation overhead. To reiterate, if I know that my server communicates at 100-full (i.e., 100 MB) and the switch sets at 100-full and that device at the other end of that switch communicates at 100-full, then I can lock that speed in. Negotiation no longer has to occur. The goal is to avoid having pieces of hardware negotiating communication speeds with each other. Having device software do this can help increase transmission speed significantly.
A robust PACS solution may present clinicians with an overwhelming array of features and functionality that can be configured flexibly to meet clinical demands. The key is not leaving it entirely up to the radiologist to maximize PACS operation-that's not the radiologist's job. Radiologists should concern themselves with reading studies, not the PACS user manual. PACS administrators should be attuned to what radiologists really need to complete their mission and not what radiologists say they want.
Radiologists may indicate a preference for a PACS option that has little impact on their productivity, whereas the knowledgeable PACS administrator can provide insight into features that increase efficiency and can help the radiologists develop new, more productive work habits.
Take configurable keys, or “hot keys,” for example. Many diagnosticians don't realize that a single keyboard key (e.g., F4) can be configured to accomplish a task that used to take several mouse-clicks, thereby helping reduce “mouse fatigue.” Similarly, radiologists can become complacent about their hanging protocols; the PACS staff can show them new ways to hang images that not only increase their satisfaction but also help them work more efficiently.
I knew a doctor who maintained such a simple PACS user preference configuration that it took him 20 times as many steps as it should have to finish a task. I implemented changes that made him twice as productive in 20- fold fewer steps. The upshot: The radiologist understood the rationale behind me changing his PACS setup and appreciated it, but he hadn't realized that he could have asked for a better way to do his job.
PACS administration needs to know the PACS better than any user, and it must also proactively seek ways to make primary users more productive. Waiting around for radiologists to make the first move is a losing strategy.
Obviously, running a successful PACS operation is a multifactorial endeavor. In my experience, serious deficiencies in PACS administration, IT bandwidth, and knowledge of radiological workflow almost always exert a drag on imaging center productivity. The good news: Even modest improvements in these areas are fairly straightforward if the center's PACS is strategically aligned with its priorities and if the budget accommodates them.