Toward a new DICOM Standard for PACS/VNA – Inventory Service

Toward a new DICOM Standard for PACS/VNA – Inventory Service

  • Category All DICOM Storage Standard
  • Date Published Jul 29, 2020
  • Written by LAITEK
  • Share This Article

At its meeting on July 8, DICOM Working Group 33 Data Archive and Management approved a New Work Item Proposal to be submitted to the DICOM Standards Committee. This NWIP is based on the Enhanced DICOMDIR concept described in my last blog post, an inventory of all the studies, series and images in an archive with their metadata.

WG-33 is now working through the technical issues associated with that concept. One of those issues is how the production of the inventory is initiated. While creation of the inventory could certainly be invoked by a function in the PACS/VNA administrative user interface, there is a consensus in WG-33 that this should also be available as a standard DICOM network service.

Production of the inventory would be functionally equivalent (more or less) to a DICOM Query C-FIND that returns as a response the entire PACS database. Cu2011FIND, however, has several deficiencies with regard to producing the inventory. First, it is a synchronous service, where the responses return on the same network connection as the query; the connection must remain open for the duration of producing and returning the inventory. A large enterprise-scale archive may have on the order of ten million studies, and producing an inventory at the rate of 10 studies per second would take two weeks. Therefore, the inventory must be produced using an asynchronous mechanism, where the network connection is closed while the PACS creates the inventory, and then a new connection is opened for it to report when it is done.

Another aspect of inventory production requiring asynchronous operation is that it must not interfere with clinical operations of the archive. Extracting the inventory will involve substantial disk I/O, paging through the entire database, which could hobble clinical operations if not appropriately prioritized below clinical needs. This will necessarily make production occur over an even longer extended period.

A subtle feature of typical implementations of Cu2011FIND further makes it unsuitable for a migration inventory. Query processing excludes content not within clinical workflow, in particular, images rejected (marked not for clinical use) by a quality control function. Even though they may be excluded from clinical Query responses, they must be included in an inventory for migration as there are legal reasons for their retention in the archive; those legal requirements don’t go away simply because the archive data is moved to another system.

What would an asynchronous network service look like? For an example, let’s look at the other asynchronous service implemented by PACS, Storage Commitment. There the client (modality) sends a request for guaranteed safe storage of images to the PACS (the Nu2011ACTION message), and the PACS responds when it is done (the Nu2011EVENTu2011REPORT). For the inventory service, the request should (like a Cu2011FIND Query) allow constraining parameters, e.g., studies within a date range, or studies with a particular modality type. The PACS would store the inventory as a DICOM non-patient object (see DICOM Part 3 Section 7.13), possibly as a DICOM Part 10 file accessible through a network filesystem, and in the task completion message would provide the access details for that object. [Future blog posts will discuss the structure of the Enhanced DICOMDIR inventory object and access mechanisms.]

One feature not present in Storage Commitment, but which would be important for the inventory service which may take days or weeks to complete, would be a progress status (percent completion) indication. Such a capability is part of the DICOM Unified Procedure Step Service.

Just because the inventory service is defined as a standard DICOM interface that does not mean that the PACS needs to process such requests from any client. As with all DICOM network capabilities, the server can set security permissions on which external applications can invoke the service. Such authorizations, while not standardized in DICOM, are certainly permitted, and even necessary in any real-world PACS/VNA deployment.

WG-33 continues to meet bi-weekly to discuss the details of the DICOM specification. New participants are welcome to sign up at https://www.dicomstandard.org/participate/.

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.