Материал: part10

6.2 The DICOM Media Storage Model​

TheDICOMMediaStorageModelispresentedbyFigure6.2-1andexpandsontheGeneralDICOMCommunicationModelintroduced​ 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.​

DICOM Application Entity

BOUNDARY: Application Services

Abstract services providing access to the data structures of the underlying layer;

Relies on DICOM info; Objects and Media Storage Service Classes

Basic Directory

Service / Object Pairs;

Application-specific

Information Objects

(e.g. Images, Results, etc.)

BOUNDARY: DICOM File Services

Abstract services providing access to the data structures of the underlying layer;

Ensures media format and physical media independence

Media Format Layer

BOUNDARY: Physical Media Access Services

Abstract services providing access to the data structures of the underlying layer;

Physical Storage Media Specific

Physical Media Format Layer

Figure 6.2-1. DICOM Media Storage Model​

The DICOM Media Storage Model includes three layers, which are described in the following sections.​

6.2.1 Physical Media Layer​

Physical media characteristics are defined at the Physical Media Layer. Such characteristics include the physical media form factor,​ dimension,mechanicalcharacteristicsandrecordingproperties.ThisLayeralsodefinestheorganizationandgroupingoftherecorded​ bits.​

Note​

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.​

- Standard -​

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. PS3.12 and its annexes specify several Physical Media choices. PS3.11 defines a number of Applic-​ ationProfilesthatselectspecificPhysicalMediadependingontherequirementsofspecificmedicalimagingapplications.​

6.2.2 Media Format Layer​

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​ associatedwiththe31/2inchfloppydiskarethedatastructuresusedbytheoperatingsystemsofvariouspersonalcomputer​ 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.​

6.2.3 DICOM Data Format Layer​

The DICOM Data Format Layer includes the following 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.​

6.2.3.1 DICOM SOP Classes​

DICOM SOP Classes and associated Information Object Definitions (IODs) are used to convey specific medical imaging information​ at the Data Format Layer. 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.​

PS3.4 defines a number of SOP Classes that may be used for Media Storage in Annex I. 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.​

6.2.3.2 Concept of the DICOM File Format​

The encapsulation of a DICOM Data Set in a File shall follow the specifications of Section 7 of this Part. These encapsulation rules​ defineaDICOMFileFormatabletocontaininaFileanyDICOMDataSet.FilesareidentifiedbyFileIDs.Nosemanticsshallbeinferred​ 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.​

- Standard -​

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 encapsu-​ lation rules define a mechanism for creating a Secure DICOM File by encapsulating an unprotected DICOM File as payload within a​ secure envelope.​

6.2.3.3 DICOM Medical Information Directory​

InadditiontotheDICOMImageandImagerelatedSOPClasses(e.g.,results,patients)otherSOPClassestailoredformediastorage​ maybeusedtoprovidereferences(ordirectories)basedonmedicalinformation,thusfacilitatingaccesstotheclinicalimaginginform-​ ation. 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.​

6.2.4 DICOM Media Storage Application Profiles​

A Media Storage Application Profile defines a selection of choices at the various layers of the DICOM Media Storage Model that are​ applicabletoaspecificneedorcontextinwhichthemediainterchangeisintendedtobeperformed.Suchchoicesareformallyspecified​ as a Media Storage Application Profile in order to ensure interoperability between implementations conforming to the same Media​ StorageApplicationProfile.Itfacilitatesconformancestatementsthatallowuserstoassessinteroperabilityofdifferentimplementations.​

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 ap-​ plication;​

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 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;​

c.​TheselectionofaspecificMediaFormatdefinition.ThisisdonebyreferencetoPS3.12thatspecifytheselectedPhysicalMedium,​ 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 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;​

f.​ Other choices facilitating interoperability such as specific limits (e.g., maximum file sizes, if necessary, support of options, if any).​

ThecompletedefinitionandstructureofaMediaStorageApplicationProfilesisspecifiedbyPS3.11.AnumberofStandardApplication​ Profiles corresponding to different needs are included in PS3.11.​

6.2.5 Media Storage and The DICOM Standard Structure​

Figure 6.2-2 provides an overview of the relationship between the functional areas identified by the DICOM Media Storage Model in-​ troduced 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.​

- Standard -​

Figure 6.2-2. Media Storage and DICOM Parts​

- Standard -​

- Standard -​