15.12.2012 Views

Digital Imaging and Communications in Medicine (DICOM)

Digital Imaging and Communications in Medicine (DICOM)

Digital Imaging and Communications in Medicine (DICOM)

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

320<br />

Chapter 15 Disaster PACS Plann<strong>in</strong>g <strong>and</strong> Management<br />

post-Katr<strong>in</strong>a Louisiana, we did not yet have fully supported <strong>DICOM</strong> network<br />

security. But we had, <strong>in</strong> addition to many st<strong>and</strong>ard ones, a proprietary <strong>DICOM</strong><br />

compression algorithm that was never publicly published or disclosed. Sett<strong>in</strong>g<br />

the system to this compression worked just like encryption: had anyone <strong>in</strong>tercepted<br />

our compressed transaction, he would not have been able to decipher it<br />

with any known technique. Always know your options.<br />

15.2.3<br />

Archiv<strong>in</strong>g<br />

Def<strong>in</strong>itely, you need to secure your data archive. Creat<strong>in</strong>g another local copy<br />

might solve this problem only partially. Another option would be archive outsourc<strong>in</strong>g.<br />

It would cut your local operational costs, it would save space, <strong>and</strong> it<br />

would, most importantly, store your backup archive copy remotely to m<strong>in</strong>imize<br />

the chances of it be<strong>in</strong>g destroyed by the same disaster strik<strong>in</strong>g your build<strong>in</strong>g.<br />

However, please keep <strong>in</strong> m<strong>in</strong>d that storage outsourc<strong>in</strong>g, especially on a large<br />

scale is more expensive than stor<strong>in</strong>g data locally. It also makes you dependent<br />

on your remote archiv<strong>in</strong>g company, so chose it carefully. Pay particular attention<br />

to any contract term<strong>in</strong>ation issues so that the company won’t disappear<br />

with all your data. The network (between local <strong>and</strong> remote archives) becomes<br />

your major po<strong>in</strong>t of failure. Ensure that you plan carefully for other emergency<br />

solutions, such as dispatch<strong>in</strong>g remote data back to you on hard drives.<br />

By far, the best archiv<strong>in</strong>g solution is the solution that can be distributed<br />

among several <strong>in</strong>dependent locations so that your PACS identifies the correct<br />

location automatically. In other words, the best archive looks more like a datasaturated<br />

network, where it really does not matter where the data resides as<br />

long as it is known where it can currently be found. Most of us use this simple<br />

approach all the time when we divide our <strong>DICOM</strong> data storage <strong>in</strong>to teach<strong>in</strong>g<br />

archives, 3D cardiology cases, perfusion studies, <strong>and</strong> whatever else; it is<br />

much faster to retrieve it from a small dedicated server than to pull everyth<strong>in</strong>g<br />

from a crowded <strong>and</strong> bottlenecked central archive. Centralized PACS archives<br />

are dangerous <strong>and</strong> <strong>in</strong>efficient. If all cell phones worked from a s<strong>in</strong>gle tower, we<br />

wouldn’t have any cell phones.<br />

15.2.4<br />

Disaster-Proof PACS Design<br />

F<strong>in</strong>ally <strong>and</strong> most critically, your ability to survive any extreme event will depend<br />

directly on your PACS granularity. What is the smallest subset of your<br />

system that can function <strong>in</strong>dependently as a stable, self-sufficient PACS?<br />

In the majority of cases, PACS are not granular at all. They are rigidly embedded<br />

<strong>in</strong>to hospitals, spread over several floors or even build<strong>in</strong>gs, <strong>and</strong> stati-

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!