This section defines the DICOM Media Storage Model used by DICOM Application Entities for the purpose of communication through the interchange of removable storage media. Specifically, this Section provides a model to clarify a number of concepts for digital imaging and communications and introduces key terms used throughout the DICOM Standard. This model has been used to partition the DICOM Standard into separate parts related to storage media interchange.
Figure 6.1-1 presents the general communication model of DICOM which spans network and storage media interchange communications. The DICOM Application Entities may rely on either one of the following boundaries:
a. the OSI Upper Layer Service, which provides independence from specific physical networking communication support
b. the DICOM File Service, which provides access to Storage Media independently from specific physical media storage formats and file structures.
Figure 6.1-1 General DICOM Communication Model
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.
Figure 6.2-1 DICOM Media Storage Model
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.
Notes: 1. An example of a Physical Media Layer in the personal computer environment is the 3 1/2 inch floppy disk, double sided, high density.
2. The specification of one or more specific Physical Media for a given application is beyond the scope of this Part of the DICOM Standard. PS 3.12 of the DICOM Standard and its annexes specify several Physical Media choices. PS 3.11 defines a number of Application Profiles which 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. PS 3.12 of the DICOM Standard 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:
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.
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 inter-operability 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:
a. The description of the need addressed by the Application Profile (e.g., cardiac, echography, angiography) and its context of application;
b. 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 PS 3.4 of the DICOM Standard. 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;
c. The selection of a specific Media Format definition. This is done by reference to PS 3.12 of the DICOM Standard 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;
d. The selection of appropriate Transfer Syntaxes;
e. The selection of a specific Security Profile. This is done by reference to PS 3.15 of the DICOM Standard which 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;
f. 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 PS 3.11. A number of Standard Application Profiles corresponding to different needs are included in PS 3.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.
Figure 6.2-2Media Storage and DICOM Parts