Digital Imaging and Communications in Medicine (DICOM)

236
Chapter 10 DICOM Media: Files, Folders, and DICOMDIRs
3. M-DELETE: to delete existing files based on their File ID.
4. M-INQUIRE FILE-SET: to inquire about free space availability for creating
new files within the File Set.
5. M-INQUIRE FILE: to inquire about the date and time of file creation (or
last update if applicable) for any file within the File Set.
As you can see, everything in this list is really transparent: media storage
M-services manage files and file space. Consequently, any DICOM AE may
take one or more of the following three concept roles:
1. File Set Creator (FSC): the AE uses M-WRITE to create the DICOMDIR File
and zero or more DICOM files (if there are no DICOM files, you can still have
DICOMDIR with an empty file list).
2. File Set Reader (FSR): the AE uses M-READ to access one or more files in a
file set. An FSR must not modify any of the files of the File Set (including
the DICOMDIR File).
3. File Set Updater (FSU): the AE uses M-READ, M-WRITE, and M-DELETE.
It reads, but must not modify, the content of any of the DICOM files in a
File Set except for the DICOMDIR File. It may create additional files by
means of an M-WRITE, or delete existing files in a File Set by means of an
M-DELETE.
Simple, isn’t it? One or more of the three concept roles makes seven possible
combinations that DICOM software can support.
Note that although FSU is not generally allowed to modify file contents, it
is often implemented as a “delete-write” pair. You delete the entire old file and
write its new version, even if the difference between the two was in a single
character. The delete-write combination is conceptually simple, and it always
works. Some file media will not let you modify the file content, so you really
need to overwrite the file completely even for a minute change. This means that
FSU often equals FSC + FSR, provided it can do M-DELETE to remove the old
file version.
It is worthwhile to compare DICOM media storage services to DICOM networking
because they follow the same framework. Look at Fig. 75. Both in networking
and file management scenarios, DICOM applications communicate if
they have matching application profiles:
1. AEs on a DICOM network are communicating based on the supported SOP
classes (such as Verification or Storage, which we studied in Chap. 7). If two
AEs support identical SOPs and their SCU-SCP roles match, then their profiles
match and the AEs can talk. For example, two AEs could support Verification
SOPs with one acting as the Verification SCU and the other as the
Verification SCP), then their profiles match and the AEs can talk (see 7.10).
In networking, application profiles are negotiated during the association
establishment process: roles, SOPs, Transfer Syntaxes, and other options are
compared by the communicating AEs, and the best match is selected when
possible.