The DICOM Media Storage Model is presented by Figure 6.2-1 and expands on the General DICOM Communication Model introduced earlier in Section 6.1.
The DICOM Media Storage Model focuses on the aspects directly related to data interchange through removable storage media. It pertains to the data structures and associated rules used at different layers to achieve interoperability through media interchange. The Services identified in this Model are simple boundaries between functional layers.
Note
It is not within the scope of this Standard to specify Application Programming Interfaces at these boundaries.
The DICOM Media Storage Model includes three layers, which are described in the following sections.
Physical media characteristics are defined at the Physical Media Layer. Such characteristics include the physical media form factor, dimension, mechanical characteristics and recording properties. This Layer also defines the organization and grouping of the recorded bits.
Note
-
An example of a Physical Media Layer in the personal computer environment is the 3 1/2 inch floppy disk, double sided, high density.
-
The specification of one or more specific Physical Media for a given application is beyond the scope of this Part of the DICOM Standard. PS3.12 and its annexes specify several Physical Media choices. PS3.11 defines a number of Application Profiles that select specific Physical Media depending on the requirements of specific medical imaging applications.
At the Media Format Layer, Physical Media bit streams are organized into specific structures. Data file structures and associated directory structures are defined to allow efficient access and management of the physical media space.
Note
This layer is often specific to a given operating system environment. An example of such a Media Format Layer definition associated with the 3 1/2 inch floppy disk are the data structures used by the operating systems of various personal computer file systems. PS3.12 and its annexes specify several Media Format choices.
Media Formats supported by the DICOM Standard are selected to support the minimum requirements specified by the DICOM File Service as specified in Section 8 of this Part. Constraining access to the File content through such a DICOM File Service ensures that the DICOM Data Format Layer is independent from Media Format and Physical Media selection.
The DICOM Data Format Layer includes four elements of specification:
-
DICOM Media Storage SOP Classes and associated Information Object Definitions;
-
The DICOM File Format;
-
The Secure DICOM File Format;
-
The DICOM Media Storage Directory SOP Class;
-
DICOM Media Storage Application Profiles;
-
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 PS3.3 and PS3.4. 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.
Note
PS3.4 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 PS3.3.
The structure and encoding of a Data Set representing the data associated with a SOP Class shall follow PS3.5. The specification of Transfer Syntaxes that may be used to encode such a Data Set, is also defined in PS3.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 PS3.4. Instances of this SOP Class are conveyed in the File with a File ID of DICOMDIR.
A Media Storage Application Profile defines a selection of choices at the various layers of the DICOM Media Storage Model that are applicable to a specific need or context in which the media interchange is intended to be performed. Such choices are formally specified as a Media Storage Application Profile in order to ensure interoperability between implementations conforming to the same Media Storage Application Profile. It facilitates conformance statements that allow users to assess interoperability of different implementations.
Media Storage Application Profiles shall include:
-
The description of the need addressed by the Application Profile (e.g., cardiac, echography, angiography) and its context of application;
-
The selection, at the Data Format Layer, of a number of specific IODs and associated SOP Classes. For standard DICOM SOP Classes, this shall be done by reference to PS3.4. These SOP Classes, like any other DICOM SOP Classes are assigned a unique registered UID. For each SOP Class it shall be stated if its support is required or optional within the context of this profile;
-
The selection of a specific Media Format definition. This is done by reference to PS3.12 that specify the selected Physical Medium, a specific associated Media Format and the mapping of this Media Format (or file system) services onto the DICOM File Service;
-
The selection of appropriate Transfer Syntaxes;
-
The selection of a specific Security Profile. This is done by reference to PS3.15 that specifies the cryptographic algorithms to be used to encapsulate the DICOM Files of the DICOM File Set into Secure DICOM Files. If a Media Storage Application Profile selects no Security Profile, then the Application Profile is unsecure and the Secure DICOM File Format shall not be used with that Application Profile;
-
Other choices facilitating interoperability such as specific limits (e.g., maximum file sizes, if necessary, support of options, if any).
The complete definition and structure of a Media Storage Application Profiles is specified by PS3.11. A number of Standard Application Profiles corresponding to different needs are included in PS3.11.
Figure 6.2-2 provides an overview of the relationship between the functional areas identified by the DICOM Media Storage Model introduced in Section 6.2 and the various Parts of the DICOM Standard related to Media Storage. A number of Parts of the DICOM Standard are common between Network Communication and Media Interchange.
