DICOM Working Group 33 Data Archive and Management has been meeting in biweekly telecons since February and has received and discussed presentations by several stakeholders. Although there have been no formal votes, as of the end of May I can report that we seem to have achieved consensus on the approach we will take in a new addition to the DICOM Standard.

Laitek’s initial proposal to WG-33 (as I described in previous blog posts) was for a standard that would support migration by making all archive data application independent. It had three major components – a standard file system storage of DICOM object files, an index of the archived files with their metadata (we had called this “Enhanced DICOMDIR”), and a mechanism in the index to store updated metadata (such as corrected patient name and ID) that had not been propagated down into the stored DICOM objects. This was admittedly a long-term project; although new systems could be designed to the standard immediately, it would take years (possibly a decade or more, based on past experience) for a substantial portion of the PACS/VNAs installations to transition to such a standard.

WG-33 has basically agreed with those three components, but has taken the tack of using them in a way that can be more readily applied to current systems. The key element is the need for a standardized index of the total contents of the PACS/VNA, or a large subset thereof. Indeed, there are a number of use cases beyond migration, especially in PACS audit and quality control, and in clinical research, where having such an index would be useful. Of course, the DICOM Query Service (Cu2011FIND), or the equivalent DICOMweb QIDO service, provides a basic capability to retrieve a list of archive contents, but it does not operate at the scale of the entire archive. C-FIND was designed for basically querying for a few studies at a time, and has a number of performance drawbacks and limitations when obtaining large scale sets of metadata. In fact, most PACS systems implement restrictions to preclude just such large queries.

The WG-33 consensus is to specify a new index information object, which I will continue to call Enhanced DICOMDIR until such time as WG-33 settles on a name. This file (or set of files) could be created under a variety of conditions, for example, prior to a migration, or for a particular research project, or even as part of a weekly database checkpoint/backup. Since the file may rapidly become out of date, it would be timestamped so that a user could later request records that have changed since that timestamp. There should therefore be some number of parameters that control the set of study data indexed, such as study date, revision date of the metadata, or modalities in the study.

Once we have the Enhanced DICOMDIR index of the contents of the archive, we must be able to access the DICOM objects. That can certainly be done using DICOM Retrieve (C-MOVE) or DICOMweb WADO network protocols, but as with Query, there are performance drawbacks and limitations when dealing with the scale of an entire archive. For PACS migration, research, and range of other uses, direct access to the DICOM objects via the file system is needed. Some PACS store all, or at least some, of their archived objects in DICOM Part 10 file format, well established for interchange using CDs or other media. The index needs to point to such files if they are available for direct read; this is similar to the classic DICOMDIR index file for media exchange, which has a pointer to each DICOM object file. Of course, if the PACS does not store DICOM objects in a standard file format, the index would not point to them, and they would be retrieved using the Study / Series / Instance UIDs through the network protocol.

Finally, the content of the Enhanced DICOMDIR must account for updated metadata that has not been propagated down into the stored DICOM objects. This is needed simply in recognition that PACS systems typically keep such updates in their databases, and update the objects when they are retrieved. So, an application that uses direct file access via a pointer in the index file would also need to get the current metadata from the Enhanced DICOMDIR and apply it to the objects it reads.

This approach to updated metadata might be said to be “descriptive”, in contrast to the original proposal which could be called “prescriptive”. That is, while the original proposal would prescribe how things should be in future systems, the revised approach simply describes the way things are in current systems. The issue of whether this separation of current metadata from the images has safety concerns (see this prior blog post) is mooted, as we are not prescribing such separation, merely describing the current state of the art which has presumably already addressed such safety concerns.

WG-33 will now begin to focus on the details of this approach, which will involve a number of interesting decisions on various technical options – how this might work in a cloud environment, how closely to align to HL7 FHIR, how to accommodate image compression and encryption, etc.

Author 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. Contact him at hsolomon@laitek.com or harry.solomon@ieee.org.