Proposal for a new DICOM Storage Standard – Part 5

  • Category All DICOM Storage Standard
  • Date Published Nov 29, 2019
  • Written by Harry Solomon
  • Share This Article
Part 5 – Additional use cases and features

Previous blog posts of this series:

  • Part 1 discussed the use case of PACS migration
  • Part 2 proposed a DICOM Media Exchange interface between the PACS and the archive data
  • Part 3 showed how an Enhanced DICOMDIR facilitates exchanging the archive database
  • Part 4 addresses standardizing journaled updates for performance optimization

The resulting architecture for PACS migration under this proposal is shown in the figure:

During migration, the new PACS reads the Enhanced DICOMDIR file to construct its database. There is no need to move the DICOM image object files, nor to interfere with the ongoing department operations through the old PACS (as would occur if the archive needs to be moved using DICOM Query/Retrieve).

While PACS migration is by far the most important use case addressed by this proposal, once the architecture to support it is in place, additional features and capabilities are enabled, with additional benefits to the user organization.

Perhaps most important from an IT management perspective is that the image archive data has a clean interface at the file system level. All the tools available for general business IT management of file systems are thus available for the image archive. The archive file set can be distributed to multiple servers, it can be replicated, it could be migrated to the cloud to take advantage of expandable capacity – all without involving the PACS. In fact, as many of these tools are designed to improve throughput, reliability, and/or cost efficiency, those benefits can be applied to the image archive at the discretion of the user organization. The user organization truly owns the image archive.

A secondary benefit comes with the read-only access to the archive DICOM file set. This provides an alternate path to the archive for research applications, such as “radiomics” and machine learning, which require access to extensive file sets. While such apps can come through the PACS, the PACS architecture is optimized for the data use patterns of routine department clinical operations, not those of research apps. Further, the system throughput capacity of PACS can be severely impacted by research data access. Thus for “big data” operations, a file read paradigm directly from the archive files is often more efficient than DICOM network protocol retrieval (either classic DICOM, or the newer DICOMweb mechanisms) which must be mediated by another application.

But please don’t misunderstand that defining a standard for direct access to the archive files opens it up to be read by any arbitrary applications! These are patient records, and every organization has policies and procedures to prevent unapproved applications to be installed and given access to patient data. The file system has access authorization mechanisms which certainly need to be managed in accordance with institutional policy. In fact, managing such authorization in the file system, which can be integrated with the enterprise user authorization mechanisms, may be easier and more effective than managing it in the PACS, which typically has only very rudimentary access controls (such as known IP addresses). We should expect that applications provided access to the archive file set would be thoroughly vetted to ensure patient privacy, as well as conformance to the DICOM Standard.

Separation at a clear file system boundary also facilitates moving the archive file set to the cloud, should the user organization want to do that. It is much simpler implementing cloud-based storage than cloud-based applications-plus-storage. Provisioning applications involves a deep understanding of performance of the PACS workflow application, the database, and the file system, each of which may need to be configured and managed separately in the cloud. A substantial portion of the benefits of cloud deployment can be achieved by focusing simply on the archive data set and its performance requirements.

I want to add a final word about safety and reliability. Functions critical to the healthcare mission of an organization, such as access to archived images, should be designed to minimize single points of failure, such that there are multiple paths to accomplish the function under failure or emergency situations. Such reliable access to the images is a key element of patient safety, ensuring timely access to information needed for clinical decisions and treatments. At a system level, separation of the PACS application from the archive data set allows such an alternate path to access the images in the event of a PACS failure. Razvan Costea-Barlutiu has also recently posted a blog article about the importance of such separation for disaster recovery.

In the next post I will discuss the economics and politics of this proposal – who wins, who loses, and the path forward.

Harry Solomon is an interoperability consultant for Laitek, Inc., and past Co-Chair of the DICOM Standards Committee. He has been involved in the development of DICOM since 1993, and has taught graduate courses in healthcare interoperability and standards at Northwestern University and at Oregon Health & Science University.