Материал: part10

Directory IOD), which includes general information about the whole File-set. This general information is always present, but optionally​ the directory content may be left empty in environments where it would not be needed. If the DICOMDIR File does not exist in a File-​ set, the File-set does not conform to PS3.10. The DICOMDIR shall not reference Files outside of the File-set to which it belongs.​

Note​

1.​An example of the content of the DICOMDIR File may be found in Annex A.​

2.​IfonechoosestomaptheoriginofaFile-settoaspecificdirectorynodeinaspecificMediaFormat,theFileIDs,including​ the DICOMDIR File IDs, would be relative to this directory node path name.​

The DICOMDIR File shall use the Explicit VR Little Endian Transfer Syntax (UID=1.2.840.10008.1.2.1) to encode the Media Storage​ Directory SOP Class. The DICOMDIR File shall comply with the DICOM File Format specified in Section 7 of this Standard. In partic-​ ular the:​

a.​SOP Class UID in the File Meta Information (header of the DICOMDIR File) shall have the Value specified in PS3.4 of this​ Standard for the Media Storage Directory SOP Class;​

b.​SOP Instance UID in the File Meta Information (header of the DICOMDIR File) shall contain the File-set UID Value. The File-set​ UID is assigned by the Application Entity that created the File-set (FSC role, see Section 8.3) with zero or more DICOM Files.​ This File-set UID Value shall not be changed by any other Application Entities reading or updating the content of the File-set.​

Note​

1.​This policy reflects that a File-set is an abstraction of a "container" within which Files may be created or read. The File-​ set UID is related to the "container" not its content. A File-set in the DICOM File Service is intended to be mapped to a​ supporting feature of a selected Media Format (e.g., volume or partition).​

2.​The Standard does not prevent the making of duplicate copies of a File-set (i.e., a File-set with the same File-set UID).​ However, within a managed domain of File-sets, a domain specific policy may be used to prevent the creation of such​ duplicate File-sets.​

- Standard -​

- Standard -​

9 Conformance Requirements​

An implementation of PS3.10 shall:​

a.​haveaConformanceStatementbasedonaPS3.11ApplicationProfileinaccordancewiththeframeworkdefinedinPS3.2,which​ will include addressing the Security Requirements defined in Section 7.5;​

b.​meet the requirements of the DICOM File Format as specified in Section 7;​

c.​support the DICOM File Service as specified in Section 8, in one or more of the roles identified in Section 8.3;​ d.​perform the Media Operations defined in Table 8.3-1 according to the role supported;​

e.​support the DICOMDIR File with a content as specified in the Media Storage Directory SOP Class in PS3.4.​

- Standard -​

- Standard -​

A Example of DICOMDIR File Content​ (Informative)​

This Annex provides an example of a File content that is based on selected aspects of the example introduced in PS3.3 for the Basic​ Directory Information Object. This is not a normative Annex. It is only an illustration, which is simply intended to help the reader better​ understand the organization of a DICOM Directory stored in a DICOMDIR File.​

A.1 Simple Directory Content Example​

Table A.1-1 shows in a simplified manner, the content of a simple DICOMDIR File. Values of elements are noted between square​ brackets (e.g., [1.2.840.10008.34.7.6]). Byte Offsets are shown by symbolic Values noted between brackets (e.g., {1493}).​

Table A.1-1. Directory Content Example​

- Standard -​