Those of you who have been following this blog will know that DICOM Working Group 33 has produced a complete draft of additions to DICOM for a PACS inventory feature supporting migration. The work, designated DICOM Supplement 223, has now been released for formal Public Comment. This is the last step before it goes to ballot by the members of the DICOM Standards Committee. DICOM has set an extended period for comment through June 1 to include the SIIM Annual Meeting, where we expect to have some good discussions.
DICOM Supplements can be daunting, and this one especially so due to its size – 80 pages, touching on six parts of the DICOM Standard. However, in this and the next few posts I will take you on a guided tour in bite-sized pieces. I’ll point out some of the issues, and the discussions that went on about them. I hope you will follow along, and ask questions and comment. Time to dig in!
“The Table of Contents is your friend” – open up to it in Sup223 (on the second page). Each Part of DICOM is highlighted in yellow, and individual changes are identified in red italics, such as:
- Add ZIP, TAR, GZIP and IHE to Section 2 Normative References
- Add Inventory to Section 7.13 DICOM Model of the Real World for Non-Patient-Related Information
- Add new section for Inventory IOD to Annex A Composite Information Object Definitions
- Add Inventory to Annex GG Non-Patient Object Storage Service Class
- Add Inventory Query/Retrieve Service Class
On this tour we are going to start at the end, with the u2018Explanatory Information Annex’ that will be included in DICOM Part 17. This annex is intended to be a sort of guidebook to the topic of inventories in DICOM, and we will follow it in this series of blog posts. But before we dive in, let’s look at the Table of Contents for that annex, and we see it has the following major sections:
- XXXX.1 The DICOM Data Management Environment
- XXXX.2 The Inventory IOD
- XXXX.3 Related Services
- XXXX.4 Use cases
- XXXX.5 Security considerations
- XXXX.6 Operational considerations
After a little background, this Part 17 guide starts at the center of the proposal, the Inventory Information Object Definition. It then builds around it the network services that use that information object, and describes the use cases are supported by these technical components. Security is always a consideration, and has some particular issues with PACS inventories. Finally, the guide looks at various operational and implementation considerations.
In today’s blog, we will look at the overview, beginning on page 57 of Sup223.
The DICOM Data Management Environment
While the centrality of the PACS in the operations of a radiology department seems obvious to us now, it was not so in the early days of DICOM. Certainly, the petabyte scale of many contemporary PACS was not a concern a quarter century ago. Sup223 is a major step within DICOM to begin addressing enterprise-scale management of imaging repositories. And none too soon, as data set sizes are increasing, and healthcare providers are consolidating into larger organizations with growing archives.
Many enterprise data management tools are tailored to a specific technology – e.g., a particular database management system or data storage system. But tools and data are also needed to manage repository data at the DICOM application level, one aspect of which is the ability to obtain an inventory of repository contents in a standard format. Such a standard format supports critical enterprise level health data applications, such as PACS data migration management, that require deeper understanding of the data content than generic data management tools can achieve.
The Overview of the Inventory IOD
The Inventory Information Object Definition specifies a structure capable of encoding an inventory of all studies, series, and instances in a repository. In that sense it is similar to the DICOMDIR file placed on DICOM exchange media, but the encoding uses standard Sequence Value Representation attributes rather than the idiosyncratic DICOMDIR record structure.
The inventory information model shown in Figure 1 follows the Study Root model used in classic DICOM Query/Retrieve, rather than the Patient Root model. Patient and Imaging Service Request (order and accession) data elements are treated as attributes of the study. The inventory is therefore organized by study, rather than by patient. Within the inventory is a sequence of study record items, within each of those items is a sequence of series record items, and within each of those is a sequence of instance record items. Each “record” is a set of key attributes used for managing the entities in a repository, for responding to queries, and identifying the mechanisms for accessing the stored objects.
Figure 1. Inventory Information Model
Those of you familiar with IHE Radiology profiles may be saying “Wait – the relationship between the Study and Imaging Service Requests shouldn’t be 1:1, that doesn’t accommodate the Group Case for a single study done in response to two related orders.” True, but even IHE profiles are based on the basic DICOM General Study Module, which supports only a single Accession Number. A more complex relationship between Study and Imaging Service Requests is handled by the attributes in the General Series Module and is not explicitly modeled in this diagram. This model supports the vast majority of studies that have just one Accession Number, and the others can be accommodated in the series-level record.
Next topic (coming in the next blog) – scoping the inventory to a subset of studies. The astute student will read ahead in the textbook (i.e., Sup223).
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 firstname.lastname@example.org or email@example.com.