Digital Imaging and Communications in Medicine (DICOM)

316
Chapter 15 Disaster PACS Planning and Management
PACS redundancy has been advertised as the only panacea to PACS reliability
problems. I agree with this partially, but let’s think for a moment what redundancy
could mean.
1. Increasing redundancy for a poorly designed system not only does not help,
but makes things much, much worse. Unfortunately, many of the commercial
PACS we deal with these days are too complex and error-prone to be
fixed by increasing their complexity. Adding wheels to a car won’t make it
run faster. In fact, it would make it impossible to drive.
2. Redundancy always penalizes efficiency. Redundant systems introduce many
additional tasks such as data synchronization, fail-over processing, redundant
component monitoring, and intercomponent communications, which
inevitably consume additional time and resources. If a system was not very
stable and efficient to begin with, then beefing it up with more spare parts
will likely yield negligible improvement (if any) at a significant cost.
3. In real life, redundancy is often sacrificed for budget. Anyone who has ever
been involved in PACS purchasing knows that buying an extra DICOM service
can become a major budget adventure in itself. The most vital PACS
parts (archival servers, for example) are also the most expensive. Moreover,
in addition to those one-time costs, redundancy also invariably increases
maintenance and support expenses. Coming to your PACS purchasing
committee and asking them to double their expenses has never been a particularly
viable option.
4. Redundancy does not really scale, and cannot be distributed. As we learned
from our hurricane experience, making PACS redundant within the same
area does not really solve the problem. Even when this area is affected
by a mere power outage, the redundancy won’t help. But if you want to
have a backup PACS server some 100 miles away from the main one, you
run into another problem set: networking, infrastructure, and remote
administration.
So what is the bottom-line? Classical component redundancy has very little to
do with overall PACS viability. It might secure the data, but it won’t secure the
process. We should take more lessons from Mother Nature, who never applies
this primitive replication redundancy to her most advanced creatures. Instead
of multiplying less-reliable components, we should really change the way they
work.
15.2
Extreme PACS
How can one have a PACS when even the phone lines are scarce and the network
is down? Or, better, is there any way to build a better PACS that would
at least partially survive any major disaster? There definitely is, but it involves
planning and major structural changes.