The DICOM Data Format Layer includes four elements of specification:
a. DICOM Media Storage SOP Classes and associated Information Object Definitions;
b. The DICOM File Format;
c. The Secure DICOM File Format;
d. The DICOM Media Storage Directory SOP Class;
e. DICOM Media Storage Application Profiles;
f. DICOM Security Profiles for Media Storage.
DICOM SOP Classes and associated Information Object Definitions (IODs) are used to convey specific medical imaging information at the Data Format Layer. SOP Classes and IODs used for Media Storage shall follow the framework established in PS 3.3 and PS 3.4 of the DICOM Standard. Examples of such IODs are modality images, patient information, results, etc.
The use of DICOM IODs in conjunction with Media Storage Services forms a number of Media Storage Service Object Pair Classes or SOP Classes. Media Storage Services (e.g., read, write, delete, etc.) shall be performed through the DICOM File Service. The content of the resulting DICOM Files shall be formatted according to the DICOM File Format as specified below.
Notes: 1. The concept of a SOP Class in the Media Storage context is equivalent to the concept of SOP Class introduced in PS 3.3 and PS 3.4 for network related operations (DIMSE Operations).
2. Both Composite and Normalized IODs and SOP Classes may be used in the Media Storage context.
PS 3.4 of the DICOM Standard defines a number of SOP Classes that may be used for Media Storage. These SOP Classes are based on DICOM Standard IODs that may be found in the Annexes to DICOM PS 3.3.
The structure and encoding of a Data Set representing the data associated with a SOP Class shall follow PS 3.5 of the DICOM Standard. The specification of Transfer Syntaxes that may be used to encode such a Data Set, is also defined in PS 3.5.
The encapsulation of a DICOM Data Set in a File shall follow the specifications of Section 7 of this Part. These encapsulation rules define a DICOM File Format able to contain in a File any DICOM Data set. Files are identified by File IDs. No semantics shall be inferred from these File IDs, nor from their structure.
Note: A medical imaging application acting as a creator of a DICOM File may use semantic information to generate a File ID, but readers of DICOM files should not rely on apparent semantic content of a File ID.
Data Set encapsulation shall be based on the DICOM File Service as specified in Section 8 of this Part.
Note: It is acceptable that a specific Media Format offers more file services than those specified in the DICOM File Service. Such services may be local or internal to an implementation. Their usage is beyond the scope of the DICOM Standard. However, in cases where such services are reflected in the file structures of the Media format Layer or in the Data Set encoding of an Information Object, the extension of such services in a manner that jeopardizes interoperability should not be done (e.g., File IDs longer than those specified in the DICOM File Service).
The encapsulation of a DICOM File in a Secure DICOM File shall follow the specifications of Section 7.4 of this Part. These encapsulation rules define a mechanism for creating a Secure DICOM File by encapsulating an unprotected DICOM File as payload within a secure envelope.
In addition to the DICOM Image and Image related SOP Classes (e.g., results, patients) other SOP Classes tailored for media storage may be used to provide references (or directories) based on medical information, thus facilitating access to the clinical imaging information. Such a SOP Class is the Media Storage Directory SOP Class as defined in PS 3.4 of the DICOM Standard. Instances of this SOP Class are conveyed in the File with a File ID of DICOMDIR.