Digital Imaging and Communications in Medicine (DICOM)

322
Chapter 15 Disaster PACS Planning and Management
8. Lightweight (order of 5 MB). The installation file, which can be relatively
quickly downloaded even on the slowest connection.
A system built from these self-sufficient blocks works as a completely decentralized,
distributed PACS network that is capable of correcting its own problems.
It is reliable by its definition and not by artificial reinforcements. If you still
like the word “redundancy”, please note that the classical definition of redundancy
is completely replaced here by the application/functional redundancy
definition: several modules can fail without affecting the rest. The remaining
modules, as supporting full PACS functionality, will be able to take some of the
workload from the failed modules.
This approach redefines many other standard ways of judging PACS reliability.
For example:
1. PACS downtime. In old PACS, this is the maximum time for the system to
be unavailable. But even a 0.1% downtime (a really exceptional number)
implies a workday per year of unavailable PACS, which can be a disaster.
In a modular system, downtime in its usual sense is highly improbable; all
individual modules would need to be destroyed. One will have to deal only
with partial PACS downtime – when some modules are down, but the rest
continue to do their jobs.
2. Business continuity. In a standard setup, business continuity is typically provided
by third parties, offering offsite data storage and alternative network
routing. In spite of all of this, the functional collapse of the entire PACS
implies the collapse of the standard business continuity model. You cannot
“continue” anything with a broken system. In the granular PACS, business
continuity can applied in “real time”. While the destroyed modules are
down, the remaining can accept additional responsibilities in compensation.
For example, if my workstation goes up in smoke, I can still use yours;
if our hospital is flooded, we can take the entire set of PACS tools on our
notebooks to our houses, or refuges, and so on.
Figure 93 shows our suggested system. In general, distributed clustered networks
are not new, and this PACS design is somewhat close to teleradiology.
But up to this point, we have not seen a real implementation of this design
brought to a hospital. PACS, as they are now, still need to evolve just like many
other commodity IT products, from Web browsers to email. Decentralized,
light, self-sufficient installations that can connect to each other on demand is
the only way to overcome historic PACS deficiencies and develop a system that
is adequate for our demanding medical imaging needs.