DICOMDIR and Media Interchange

[update 24 March 2023: Latest releases of HRZ software can be found on HRZ website - www.hrzkit.com]

DICOMDIR, Have you heard this term? What does it mean? Do I need this in my system? Lots of questions. Let's try to answer some.

Here's a list with quick information about DICOMDIR:

1. Standard DICOM CD/DVD should have a file named DICOMDIR in its root directory.
2. The DICOMDIR file has in it records that hold paths to DICOM files on the media.
3. DICOMDIR is a DICOM Object holding a sequence of DICOMDIR records nodes each having a type like PATIENT, STUDY, SERIES and IMAGE
4. The DICOMDIR file include key attributes from the data on the media such as Patient Name, Patient ID, Study ID, Study Date.
5. The file names of DICOM files on a standard DICOM CD/DVD should be capital alphanumeric up to 8 characters with no suffix.
6. The CD/DVD may include other files that are not DICOM. The DICOMDIR file does not reference them.
7. The mandatory elements of the DICOMDIR nodes are not 1-2-1 with the mandatory elements in the DICOM Objects. For example Study ID which is Type 2 in DICOM Image objects is Type 1 in DICOMDIR STUDY Record. So when creating your DICOM images if you intend to create DICOMDIR for them, add these elements too.

There are two ways DICOM application can collaborate with one another. They can communicate over TCP/IP network connection or they can exchange files over some physical media.

The first figure in the DIOM standard makes sense eventually

The picture above, which is by the way the first figure in the DICOM standard (page 10 of chapter 1), explains that very well although when I first looked at thirteen years ago it it didn't mean anything to me.
It is worth staying a bit longer on this figure because it has a lot of valuable information in it so lets work it top to bottom.

At a first view, ignoring its content and looking only at the shape, it looks like some kind of humanoid robot with flat oval head walking on two clumsy legs made of crude blocks. Well, at least that's what I see.

The oval head that reads "Medical Information" is representing your application data. 

The gray body box is your DICOM implementation (e.g. using the RZDCX toolkit) taking its data and putting it into DICOM Objects encoded properly. Then it is ready to be shared or sent to other applications, not yours, that can read the data and make useful things with it because that application too, just like your application, speaks the same language - DICOM!

Now comes the split between the two legs. The DICOM Objects can be either be written into DICOM files and then take the right side (or the left foot if this robot is facing us) through some physical media like a CD, DVD and USB, or it can take the left side and be sent over a TCP/IP network connection using DICOM commands like C-STORE.

This post is about the right side, exchanging physical media.. I've already discussed part of it, the DICOM File Meta Header, when talking about DICOM Transfer Syntax. 

Let's say we got a CD from someone that tells us there's DICOM files on this CD with the information of the patient we are looking for. If we have no more information then that, we need to open the CD, look at every file on it and check if its a DICOM file, read it, figure out what's in it and decide if this is what we are looking for. Doable but slow, specially with slow media like CD, But, when this CD is made according to the standard, there's a better way. All we need to do then is to read the DICOMDIR file, find the record in it with our patient's ID and get from there the references to the DICOM files that we are looking for on the CD. The DICOMDIR is exactly what it names suggests. Its a directory record with information about DICOM files on the media. Because search actions on CD's are much slower then on a hard drive, using the DICOMDIR should theoretically shorten the time required to find and display to the user the information on the media.

With RZDCX I try to make things easier by providing the very basic API to carry out the task. Many times ease of use considerations supersede complete options and flexibility because I take the decision to implement the DICOM internals in a certain way that will be most integrative and still correct. When I take such decisions its because I assume that RZDCX users want to focus on the their strengths and count on RZDCX to do the right thing DICOM-wise. This prolog is made to explain the very thin API of the DICOMDIR Implementation class DCXDICOMDIR.

The DCXDICOMDIR class has methods to search and iterate over the different records within the DICOMDIR file. So for example to go over all the patients in the media you use the getPatientIterator method and get back an object iterator where each DCXOBJ in it is one DICOMDIR patient record.

To create a DICOMDIR use ScanAndCreate. This method scans a directory for DICOM files and writes a DICOMDIR file in its root. Before calling it, make sure your files are named properly. I use the following naming convention:

• Create a directory PA001 for every patient
• Inside PA001 create a directory ST001 for every study
• Inside ST001 create a directory SE001 for every series
• Inside SE001 create the DICOM files and name them IM000001, IM000002 ...

Remember not to use prefixes and keep your filenames to 8 characters long, capital with alphabetic first letter. Here's a short code from the new DICOMIZER that crates a valid DICOMDIR:

        private void CreateDICOMDIR(string SourceFolder)

        {

            try

            {

                DCXDICOMDIRClass dir = new DCXDICOMDIRClass();

                dir.ScanAndCreate(SourceFolder, APPLICATION_PROFILE.AP_GENERAL_PURPOSE, "RZ DICOMIZER", false);

            }

            catch (Exception ex)

            {

                MessageBox.Show(ex.Message);   

            }

        }