Depending on the type of directory record, relevant information is encoded into it in order to allow the processing application to retrieve it for any processing. Besides the root record which carries information about the overall file (meta-information), there are essentially four types of information each of the directory records can manage ("patient", "study", "series" and "image") although not all these directory record types need to be present. The Basic Directory IOD structure on which DICOMDIR file is based on is organized as essentially a hierarchy of "directory records" starting with a "root directory record" which is then linked to one or more child "directory records" and these themselves may in turn have a reference to other lower level directory records. It is interesting to note that the DICOMDIR file itself is a valid DICOM file (uses the "Basic Directory IOD" structure) and information is encoded into it using the "Explicit VR Little Endian Transfer Syntax (UID=1.2.840.10008.1.2.1)" as no negotiation is permitted as mentioned earlier. No modification is permitted to the actual contents of the files or images that are referenced by the DICOMDIR file.
Please also note that the DICOM standard stipulates that only modification of the DICOMDIR file is permitted. And when creating a DICOMDIR file, the application plays the role of a "File Set Creator", and when updating a DICOMDIR file plays the role of a "File Set Updater". For instance, any application that reads a DICOMDIR file plays the role of a "File Set Reader". The primary roles involved during storage media-related operations are File Set Creator (FSC), File Set Reader (FSR) and File Set Updater (FSU).
Just like roles such as "Service Class User (SCU)" and "Service Class Provider (SCP)" which the actors play during composite and normalized DICOM operations, applications play various roles during media storage operations as well. Unlike the commands involved during composite and normalized operations, association negotiation to negotiate transfer syntaxes, etc is not feasible, and the roles played by the various actors are therefore predefined. These operations at their core handle data essentially as serialized files. In addition to both composite and normalized DICOM operations which deal with aspects such as sending, receiving and printing of DICOM images, there is another category of operations called "storage media operations" which deal with reading or encoding content from and to storage media. If you recall my earlier tutorial on DICOM association/negotiations, I mentioned that DICOM applications take on different roles when performing any DICOM-related operations. This tutorial also assumes that you know the basics of C# or any equivalent object-oriented language such as Java or C++. NET and C# - Making Sense of the DICOM File” to understand the structure of a DICOM file. You may also want to look at my other tutorial titled “DICOM Basics using. If you are totally new to DICOM, please have a quick look at my earlier article titled “Introduction to the DICOM Standard” for a quick introduction to the standard.
Make dicomdir file series#
This is part of my series of articles on the DICOM standard.
Make dicomdir file how to#
In this short tutorial, we will look at how to create DICOM directories and also cover some additional theory to solidify our understanding of this area.
In that article, we also explored how to read and display information contained in these special files using a.
This is a continuation of my previous tutorial in which we looked at what a DICOMDIR file is, and also reviewed the role these special files play in the overall media management aspects related to DICOM processing.