Материал: part10

•​Validate that the contents are of the appropriate SOP Classes.​

•​Validate that DICOM File Format files created for HTTP requests and responses do not contain such malicious content.​

Note​

For example, it may be appropriate for an archive that stores and retrieves PS3.10 Files to verify and validate both input​ and output, rather than store and retrieve files without checking the content.​

The proper response to a validation failure depends upon the purpose of the application. Validation might be performed on input,​ output, or both.​

Note​

Forexample,anarchivemaychoosetosanitizeSOPInstancesuponreceipt,sanitizeSOPInstancesuponretrieval,validate​ the structure and fail storage requests for SOP Instances that fail validation, or other behavior based on the product purpose​ andthethreatenvironment.ThisbehaviorisnotspecifiedbyDICOMbecausetheproductpurposeandthethreatenvironment​ are highly dependent upon the application.​

An implementation shall describe in its Conformance Statement its behavior with respect to sanitization of the preamble and any​ other validation performed.​

- Standard -​

8 DICOM File Service​

TheDICOMFileServicespecifiesanabstractviewoffilesfromthepointofviewofaserviceuserintheDataFormatLayer.Constraining​ access to the content of files by Application Entities through such a DICOM File Service ensures independence of the Data Format​ Layer functions from specific Media Format and Physical Media selections.​

Note​

This DICOM File Service definition is abstract in the sense that it is only the specification of a boundary. Its focus is limited​ to the aspects directly related to the access to the data structures of the Media Format Layer (not the specifications of the​ data structures themselves). Even though the DICOM File Service may be described by means of a number of abstract​ primitives such as read, write, delete, etc., it is not intended to be the definition of an Application Programming Interface​ (API).​

TheDICOMFileServicespecifiedforMediaStorageoffersabasicservice,simpleenoughtobesupportedbyawiderangeofcommonly​ available Media Format (or file systems), but rich enough to provide the key functions to effectively manage files and access their​ content. The following sections specify the minimum mandatory requirements that shall be met by any physical media and associated​ media format to comply with the DICOM Media Storage model.​

Note​

It is acceptable that a specific Media Format offers more file services than those specified in the DICOM File Service. Such​ servicesmaybeinternaltoanimplementation(i.e.,notvisiblethroughthedatastructuresontheStorageMedia).Theirusage​ 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 an Information Object, the extension of such services in a manner that​ jeopardizes interoperability should not be done (e.g., File IDs longer than specified in the DICOM File Service).​

8.1 File-set​

The DICOM File Service offers the ability to create and access one or more files in a File-set. A File-set is a collection of files that​ share a common naming space within which File IDs (see Section 8.2) are unique. No semantics is attached to the order of Files​ within a File-set.​

Note​

1.​The DICOM File Service does not require that Files within a File-set be simultaneously accessible (e.g., sequentially​ accessed media such as tapes are supported).​

2.​The DICOM File Service does not explicitly include the notion of distributing a File-set or a File across multiple​ "volumes/physical medium". However the transparent support by the Media Format Layer of such a feature is not pre-​ cluded.​

A File ID naming space (corresponding to a File-set) shall be associated with an appropriate feature of a Media Format defined​ structure. This mapping shall be specified in PS3.12 for each Media Format specification (this is integral to the specification of the​ relationship between any specific Media Format services and the DICOM File Services defined in this Part).​

Note​

An example of such a relationship is to map the File ID naming space to a volume in a personal computer Media Format or​ a partition in a workstation File System on a removable medium. Another example is to map the File ID naming space to a​ directory and its tree of sub-directories. In this case it could offer the possibility of supporting multiple File-sets (one per dir-​ ectory) on the same physical medium. Each File-set would have its own DICOMDIR File. To ensure interoperability, PS3.12​ shall specify these specific mapping rules between the directories and the File ID naming space of a File-set (including the​ rules to unambiguously locate the DICOMDIR File).​

A single File with the File ID DICOMDIR shall be included in each File-set.​

Each File-set shall be uniquely identified by a File-set UID that shall be registered according to the UID registration rules specified in​ PS3.5. When Files are added or removed from a File-set, the File-set UID shall not change.​

- Standard -​

AFile-setmayalsobeidentifiedbyaFile-setID,whichprovidesasimple(butpossiblynotgloballyunique)humanreadablereference.​ A File-set ID is string of zero (0) to sixteen (16) characters from the subset of the G0 repertoire of ISO 8859 (see Section 8.5). A File-​ set ID may be associated or mapped to an appropriate identifier at the Media Format Layer.​

Note​

1.​Continuing with the personal computer Media Format example used first in the previous note, a File-set ID may be​ defined to be identical to a volume label.​

2.​Non-DICOM Files (Files with a content not formatted according to the requirements of this Part of the DICOM Standard)​ may be present in a File-set. Such files should not contain the DICOM File Meta Information specified in Table 7.1-1​ and may not be referenced by the DICOM Media Storage Directory (see Section 8.6).​

A File-set Descriptor File (a "readme" file) may also be attached to a File-set. See PS3.3 for a detailed specification of the Basic Dir-​ ectory IOD.​

8.2 File IDs​

Files are identified by a File ID that is unique within the context of a File-set. A File ID is an ordered sequence of File ID Components.​ AFileIDmaycontainonetoeightcomponents.EachComponentisastringofonetoeightcharactersfromasubsetoftheG0repertoire​ of ISO 8859 (see Section 8.5)​

Such a structure for File IDs (a sequence of components) allows the DICOM File Service to organize file selection in a hierarchical​ mode.NoconventionsaredefinedbytheDICOMStandardfortheuseofthestructureofFileIDscomponentsandtheircontent(except​ for the reserved File ID DICOMDIR, see Section 8.6). Furthermore, no semantics shall be conveyed by the structure and content of​ such File IDs. This implies that when a File ID is assigned to any File in a File-set, the creating DICOM Application Entity may choose​ tostructuretheFileIDasitwishes.AnyotherAEreadingexistingfilesorcreatingnewfilesshallnotberequiredtoknowanysemantics​ the original creator may have associated with such a structure.​

The File ID used to access a File through the abstract DICOM File Service is not necessarily the sole file identifier. The interchange​ Media Format (file system) may allow multiple file names to address the same physical file. Any use of alternate file names is beyond​ the scope of the DICOM Standard.​

Note​

1.​ADICOMFileIDisequivalenttothecommonlyusedconceptof"pathname"concatenatedwitha"filename".Anexample​ of a valid DICOM File ID with four components shown separated by backslashes is:SUBDIR1\SUBDIR2\SUBDIR3\AB-​ CDEFGH​

2.​As specified in the DICOM Storage Media Model, no semantics is attached to File ID content and structure as it relates​ to the DICOM Information Objects stored in these files. If used, the hierarchical structure simply provides a means to​ organize the Files of a File-set and facilitate their selection.​

3.​The DICOM File Service does not specify any "separator" between the Components of the File ID. This is a Value​ Representation issue that may be addressed in a specific manner by each Media Format Layer. In DICOM IODs, File​ ID Components are generally handled as multiple Values and separated by "backslashes". There is no requirement that​ Media Format Layers use this separator.​

4.​DICOM files stored on interchange media may have an alternate file name or link that uses less restricted file names,​ such as a filename extension (e.g., ".dcm" in accordance with RFC3240).​

8.3 File Management Roles and Services​

When DICOM Application Entities participate in the exchange of information by the interchange of Storage Media, they perform​ through the DICOM File Service a number of Media Storage Services:​

a.​M-WRITE, to create new files in a File-set and assign them a File ID;​

b.​M-READ to read existing files based on their File ID;​

c.​M-DELETE to delete existing files based on their File ID;​

- Standard -​

d.​M-INQUIRE FILE-SET to inquire free space available for creating new files within the File-set;​

e.​M-INQUIRE FILE to inquire date and time of file creation (or last update if applicable) for any file within the File-set.​

A DICOM Application Entity may take one or more of the following three roles:​

a.​File-setCreator(FSC).SuchanApplicationEntity,exercisesthisrolebymeansofM-WRITEOperationstocreatetheDICOMDIR​ File (see Section 8.6) and zero or more DICOM Files;​

b.​File-set Reader (FSR). Such an Application Entity, exercises this role by means of M-READ Operations to access one or more​ Files in a File-set. A File-set Reader shall not modify any of the files of the File-set (including the DICOMDIR File);​

c.​File-setUpdater(FSU).SuchanApplicationEntity,exercisesthisrolebymeansofM-READ,M-WRITE,andM-DELETEOperations.​ It reads, but shall not modify, the content of any of the DICOM files in a File-set except for the DICOMDIR File. It may create​ additional Files by means of an M-WRITE or delete existing Files in a File-set by means of an M-DELETE.​

Note​

Although a File-set Updater (FSU) may include the functions corresponding to a File-set Creator (FSC) and a File-set​ Reader (FSR), it is not required that implementations supporting an FSU role also support an FSC or an FSR role.​

The use of the concept of roles in DICOM Conformance Statements will result in a more precise expression of the capabilities of im-​ plementations supporting DICOM Media Storage. Conforming implementations shall support one of the following choices:​

a.​File-set Creator,​

b.​File-set Reader,​

c.​File-set Creator and File-set Reader,​

d.​File-set Updater,​

e.​File-set Updater and File-set Creator,​

f.​ File-set Updater and File-set Reader,​

g.​File-set Updater, File-set Creator and File-set Reader.​

Based on the roles supported by a DICOM Application Entity, the DICOM File Service shall support the Media Operations defined in​ Table 8.3-1.​

Table 8.3-1. Media Operations and Roles​

Note​

1.​Media Preparation is outside the scope of this Part of the DICOM Standard. However it is assumed to be performed by​ the FS Creator.​

- Standard -​

2.​TheDICOMFileServicedoesnotrequirethatfileupdatecapabilities(e.g.,append)besupportedbyeveryMediaFormat​ Definition selected. The non-support of such file update capabilities to the DICOMDIR File may simply result in having​ to delete and create a new file in order to keep the directory information consistent.​

3.​If the content of a file needs to be updated or changed by an FSU, it is considered by this Part of the DICOM Standard​ as an M-DELETE Operation followed by an M-WRITE Operation. The FSU is responsible for ensuring the internal​ consistency of the File and its conformance to PS3.10 and the specific SOP Class stored, exactly as if the FSU was​ creating a new File. In particular, if an FSU implementation needs to update the file content but is not able to recognize​ and fully process the content of the File Preamble (see Section 7.1), it may consider setting the first four bytes of the​ Preamble to "DICM" followed by 124 bytes to 00H. This would avoid introducing inconsistencies between the content​ of the File Preamble and the remainder of the file content. An example of this situation may occur when a TIFF IFD 0​ Offset in the File Preamble points at a further TIFF IFD embedded in the DICOM Data Set, and the update operation​ changes the location of this embedded TIFF IFD.​

8.4 File Content Access​

The DICOM File Service offers the ability to access the content of any File of a File-set. The File content is an ordered string of zero​ or more bytes, where the first byte is at the beginning of the file and the last byte at the end of the File.​

Note​

This File content definition as an ordered string of bytes is related to the view provided at the DICOM File Service level. It​ may not correspond to the physical ordering of bytes of data on a specific medium.​

The DICOM File Service shall manage the delimitation of the end of the File by ensuring the user of the File Service that read access​ beyond the last byte will be detected and reported to the DICOM File Service user. This delimitation function is performed by the​ Media Format Layer.​

The DICOM File Service shall offer the ability:​

a.​for an FSR or FSU to perform an M-READ to read zero or more bytes of the content of a File;​

b.​for an FSC or FSU to perform an M-WRITE to write one or more bytes making the content of a File.​

Note​

The DICOM File Service does not require any specific capability for the selective read access or write access of the content​ of a file (e.g., seek or append). However it does not restrict specific Media Format definitions to support such features.​

8.5 Character Set​

File IDs and File-set IDs shall be character strings made of characters from a subset of the G0 repertoire of ISO 8859. The following​ characters form this subset:​

A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z (uppercase)​

1, 2, 3, 4, 5, 6, 7, 8, 9, 0 and _ (underscore)​

Note​

1.​This is the character set defined for Control Strings (Value Representation CS - see PS3.5) except that SPACE is not​ included.​

2.​This character set is selected to limit characters in File IDs and File-set IDs to those that do not conflict with reserved​ characters and delimiters in the file systems defined in PS3.12. Component delimiters or other required demarcations​ defined in PS3.12 are not part of File IDs or File-set IDs​

8.6 Reserved DICOMDIR File ID​

A single File with a File ID, DICOMDIR, shall exist as a member of every File-set. This File ID is made of a single Component (see​ Section 8.2 for the File ID structure). It contains the DICOM Media Storage Directory (see PS3.3 for detailed specification of the Basic​

- Standard -​