DICOM standards and applications-DICOM media storage functions and file formats

In the previous lecture, we introduced the network transmission function in DICOM standard, that is, using communication lines for DICOM information exchange. This section describes information exchange through storage media. Information such as images, diagnostic results, and inspection results is stored in storage media such as floppy disks and CDs to enable information exchange between different systems at different times, it can also save information for a long time.
Information exchange through media and information exchange through communication channels. They all use the DICOM message exchange mechanism. However, when information exchange is realized using the media, the two sides of the information exchange application system do not work at the same time, resulting in a difference with the network information exchange.
I. media storage model Overview
Considering media storage, the DICOM working model can be expanded to 1.
The DICOM general communication model shows that the media access model is hierarchical. The three layers are:
1. physical media layer
The physical media layer defines the physical characteristics of the media, such as physical media format parameters, dimensions, mechanical properties, storage properties, and the organization of bit stream information. For example, a 3.5 inch double-sided high-density floppy disk in a PC environment is a physical medium defined in the DICOM standard. The corresponding parameter description is the corresponding physical media layer, it should comply with ANSI x3.171, that is, the general 1.44m floppy disk.
2. Media Format Layer
The media format layer is determined by the operating system. It specifies the specific data organization form on the storage media and operations performed by the file system. It also defines the directory structure on the media. For example, a 3.5 inch floppy disk has different data structures in different operating systems. In MS-DOS and windows, it uses the media format is fat16 Format File Allocation Table, while in UNIX is used in the chain table consisting of Super blocks. Regardless of the media format, they should be able to provide at least DICOM file service functions, and restrict the permissions for direct operations on the file content through the file service, to ensure that the DICOM data format layer is independent of the media format and physical media selection.
3. DICOM data format Layer
The DICOM data format layer includes four aspects: DICOM media storage service/object pair (SOP) and associated information object definition, DICOM file format, DICOM media storage directory SOP, DICOM media storage application file. The following are detailed descriptions.
Ii. media storage SOP and information object definition IOD
The media storage service class defines a group of services that use storage media for data exchange. In general, there are two reasons for using storage media: first, images exchanged between two processes are temporarily stored in the media, but there is no further description about the processing, just transfer information. Second, the images used for printing are organized in the form of film sessions. The receiving process must process the print management information in the media. The status information about the progress of the printing task is also reflected on the storage media.
In this service class, a process plays a different role than in network conditions. In the network, the roles of both parties are SCP and SCU, while in the storage medium, they are only related to operations on the media. The media storage service class defines three roles: fileset creator (FSC), fileset reader (FSR), and fileset updator (FSU ), obviously, these names are all permitted operations.
The service elements used in the SOP classes in these services describe the operations performed on the SOP class instances managed as file sets or full file sets. The IOD used by these services defines that information must be stored in a file. This information can be a mixture of common and composite objects.
This service class only processes the storage of information in a file, regardless of its content. The exception is that there is a special SOP class. The directory Storage Class in the media storage processes information about the file set and directory (dicomdir.
Other SOPs in the media storage service class are the same as those in the patient management, research management, result management, and print management network storage service class for image data. Sop instances stored in files can be directly used after the services of the corresponding SOP class are accessed using the services of the media storage class.
Three directory structure
In addition to DICOM images and related SOP categories (such as diagnostic results and medical records), there are also other SOP categories for managing media storage. This SOP class is the media storage directory class defined in DICOM standard ps3.4. Their instances are the corresponding dicomdir files.
Many common storage media, such as 230 m, 650 m, and 2.3g, are specified in DICOM standards, multi-level Directory management is required for effective use. DICOM supports multi-level Directory management through DICOM-DIR files.
On a storage medium, DICOM file organization is performed at four levels: patient, study, sequence, and image. Patients, studies, and sequences have directory properties, which can be selected or omitted as needed, and images appear as final files.
The dicomdir file describes the hierarchical structure of DICOM files on the entire media, the file is linked in the form of a binary tree of the Child-brother node (see figure 2 ).
In this way, when you perform operations on any image file in the media, you only need to retrieve the directory file to obtain the location information of the file and then perform operations on the file.
The advantage of this organization is that it is independent from the implementation of a specific file system. As long as the file sub-system in the operating system can provide basic file operation functions, the logical patient-Image File hierarchy can be realized without the operating system's support for multi-level sub-directories.
Four file formats
The DICOM file provides a encapsulation method that encapsulates an SOP instance of the DICOM information object definition IOD in the form of a dataset in a file. The byte stream of the dataset is located after the DICOM object metadata. Each object contains a single SOP instance. This instance contains one or more frames.
1. DICOM file metadata
The object metadata includes the identity information of the encapsulated dataset. The file header consists of a predefined 128-byte boot plus a 4-byte DICOM prefix and the object metadata described in table 1. Each DICOM file has such a header.
The predefined file header can be flexibly applied according to the application file or the requirements of instances. The DICOM standard does not have any structural requirements for this predefined header with a fixed length. It does not have to have an identifier and length information like the DICOM data element in the structure. This is to make DICOM file data easy to be compatible with many common computer image formats. The DICOM file format must comply with this requirement regardless of whether the predefined header contains information. The content in the dataset should be consistent with the SOP class stated in the object metadata.
If the pre-defined header is not used by the application file and implementation instance, the 128 bytes should be set to 00 h to identify whether the 128 bytes contain application information. For example, this predefined header can be used to authorize a multimedia application to determine its operation permissions on images in DICOM datasets. In this way, two operations can be performed on the same file: a multimedia application with a predefined header, and a DICOM application that ignores the predefined header.
The DICOM four-byte prefix should contain the feature string dicm (uppercase and the font uses the ISO8859-G0 character set, which is commonly used ASCII encoding), which has no identifier and length information. The pre-defined header and suffix are a series of DICOM elements. They contain the identifier and length information. The specific meanings are shown in table 1.
2. dataset Encapsulation
In DICOM media storage applications, each file should contain a dataset that describes a unique SOP instance. This SOP instance belongs to a sop class and the corresponding iod, such as a study, sequence, or storage.
Just as a specific IOD can be defined as multiple frames, a file may contain more than one image frame, which is determined by the specific content in the SOP instance. The encoding used in the dataset must be the UID identifier of the transmission syntax in the DICOM file metadata.
The DICOM dataset does not contain its length information. The file end prompt provided by DICOM file service is the only sign of the end of the dataset.
3. Support for file management information
The DICOM file format does not contain file management information, so it does not overlap the function of the Media Format layer. If a specific DICOM application file is required, the media format layer should contain the following information:
Information of the file description table, statistics of file entries (such as creation time and date), application File Permission control, and physical permission control (such as write protection ). As we mentioned earlier, the media application layer is implemented and provided by the operating system.
The DICOM standard of the current version does not involve the control of media interaction security beyond the media and File Permission control service. The specified media format layer may support this security mechanism. Beyond the security management requirements of the physical media layer and media format layer, it will be reflected in the new DICOM standard for media storage.
5. media storage application files and available storage media
The media storage application file defines the application system's selection of different layers in the DICOM media storage model, in order to meet the special needs of using the media for information exchange. This option is described by the standardized media storage application file. The DICOM standard requires that the information exchange between different media files must follow the system's media storage application file. This consistent description allows users to select different actual systems to ensure interoperability between systems.
Media storage application files generally include the following:
(1) Use the application file to express the Requirement Description and context of the application.
(2) Select the data format layer.
(3) definition of the Media Format layer, which specifies how available physical media, media formats, and media formats (or file systems) services are mapped to DICOM file services.
(4) Select a reasonable transmission syntax.
(5) Other special restrictions that help with interoperability, such as the options supported by the maximum file length.
Finally, the following table lists the types and related content of the interchangeable storage media currently supported by the DICOM standard for your reference.