TALK TO AN EXPERT TODAY
United States
2024 Hickory Road suite 208, Homewood, IL 60430, USA
United Kingdom
10 John Street, London WC1N 2EB, UK
Romania
Strada Republicii 87, Cluj-Napoca, Romania
The first blog post of this series discussed the new operational problem for PACS admins – replacement of an older PACS and migration to a new system. The second post discussed a system architecture for a solution based on a standard DICOM interface between a PACS front end and a DICOM compliant file set; this would allow the data to be transitioned to the new PACS without needing to move it. This post discusses the second major hurdle in migration, creating the archive database in the new PACS.
Every PACS needs to have a database of the images in the archive to support queries and retrieval. In normal operations, this database is built incrementally; as each DICOM object is received, the PACS extracts relevant metadata attributes from the object and records them in the database for efficient search. The nature of PACS databases varies widely across products, and is often considered the proprietary “sauce” that distinguishes one from another.
When migrating to a new PACS, reprocessing each individual object in the archive to enter it into the database is possible, but costly. While the architecture of a DICOM standard media storage interface may avoid moving the data, the PACS would still need to read each object. It would be nice to just get a database dump from the old PACS, and load it into the new one, but the disparities between the proprietary formats makes that technically problematic. Even more problematic is the business proposition – the incumbent PACS vendor is unlikely to give up the keys to their proprietary database in in order to facilitate their replacement by another vendor!
But all is not lost. In the prior blog post of this series we noted that one of the key features of DICOM Media Storage Services is the DICOMDIR file. This is a mini-database in a standard non-proprietary format, which provides an index to all the files in the exchanged DICOM object data set with sufficient metadata for basic searches. With a DICOMDIR for the entire archive, the new PACS can process it to construct its own database, rather than reading each DICOM object file.
Unfortunately, we probably cannot use the existing DICOMDIR specification for our use case. DICOMDIR was designed 25 years ago for use with a limited data set, basically what could fit on a recordable CD (typically a single patient’s data). While conceptually appropriate, it is not what we need from a technical perspective for exchanging an entire archive. For an enterprise level data set we would need an Enhanced DICOMDIR, something we actually envisioned a quarter century ago when we defined DICOMDIR as holding the Basic Directory Information Object. As a side note, much of the work in DICOM over the past 15 years has been developing second generation enhanced information object definitions, and an Enhanced DICOMDIR would certainly fit that pattern.
So what would be in an Enhanced DICOMDIR? The floor is open for proposals, which would need to be evaluated by a DICOM working group when this proposal moves forward. I would suggest a few critical items. First, sufficient metadata must be present to allow a functional PACS database to be constituted from the DICOMDIR without needing to read the individual object files. Second, much as large archives are partitioned to separate storage servers, the Enhanced Directory should be partitionable to track the archive storage. Third, file references should allow study, series, and image unique identifiers (UIDs) to be used as folder and file names (which the current DICOMDIR does not allow).
Beyond these basics are some other possibilities that may be more controversial, and which would need significant discussion. One might be to use the DICOMDIR to journal updates that have not yet been propagated to the individual DICOM objects. This will be the subject of my next blog post.
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.
2024 Hickory Road suite 208, Homewood, IL 60430, USA
10 John Street, London WC1N 2EB, UK
Strada Republicii 87, Cluj-Napoca, Romania