This Application Profile is based on the Media Storage Service Class (see PS 3.4).
Table I.3-1STD-DVD-MPEG2-MPML and STD-DVD-SEC-MPEG2-MPML SOP Classes and Transfer Syntaxes
|Information Object Definition||Service Object Pair Class UID||Transfer Syntax and UID||FSC Requirement||FSR Requirement|
|Basic Directory||1.2.840.10008.1.3.10||Explicit VR Little Endian Uncompressed 1.2.840.10008.1.2.1||Mandatory||Mandatory|
|Multi-frame Composite IODs for which a Media Storage SOP Class is defined in PS 3.4||See PS 3.4||MPEG2 MP@ML Image Compression 1.2.840.10008.1.2.4.100||Defined in Conformance Statement||Mandatory for all SOP Classes defined in Conformance Statement|
The STD-DVD-MPEG2-MPML and STD-DVD-SEC-MPEG2-MPML application profiles require any of the 120 mm DVD media other than DVD-RAM, as defined in PS 3.12.
Conformant Application Entities shall include in the DICOMDIR File the Basic Directory IOD containing Directory Records at the Patient and the subsidiary Study and Series levels, appropriate to the SOP Classes in the File Set.
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory Records.
Note: DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for each patient directory record in one File Set.
File Set Creators and Updaters are required to generate the mandatory elements specified in PS 3.3.
Table I.3-2 specifies the additional associated keys. At each directory record level other additional data elements can be added, but it is not required that File Set Readers be able to use them as keys. Refer to the Basic Directory IOD in PS 3.3.
Table I.3-2STD-DVD-MPEG2-MPML and STD-DVD-SEC-MPEG2-MPML Additional DICOMDIR Keys
|Key Attribute||Tag||Directory Record Type||Type||Notes|
|Patient’s Birth Date||(0010,0030)||PATIENT||1C||Required if present in any objects referenced by subordinate records with a non-zero length value.|
|Patient’s Sex||(0010,0040)||PATIENT||1C||Required if present in any objects referenced by subordinate records with a non-zero length value.|
|Institution Name||(0008,0080)||SERIES||1C||Required if present in any objects referenced by subordinate records with a non-zero length value.|
|Institution Address||(0008,0081)||SERIES||1C||Required if present in any objects referenced by subordinate records with a non-zero length value.|
|Performing Physicians’ Name||(0008,1050)||SERIES||1C||Required if present in any objects referenced by subordinate records with a non-zero length value.|
|Image Type||(0008,0008)||IMAGE||1C||Required if present in image object.|
|Lossy Image Compression Ratio||(0028,2112)||IMAGE||1C||Required if present in image object with a non-zero length value.|
Note: The requirements with respect to the mandatory DICOMDIR keys in PS 3.3 imply that either these attributes are present in the Image IOD, or they are in some other way supplied by the File-set Creator. These attributes are (0010,0020) Patient ID, (0008,0020) Study Date, (0008,0030) Study Time, (0020,0010) Study ID, (0020,0011) Series Number, and (0020,0013) Instance Number.
The STD-DVD-SEC-MPEG2-MPML application profiles require that all DICOM Files in the File-set including the DICOMDIR be Secure DICOM Files encapsulated in accordance with the requirements of the Basic DICOM Media Security Profile as defined in PS 3.15.
Note: These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or digital signature) to ensure Integrity or carry the same originators’ signatures.
It is desirable that consumer DVD players (and computer software for playing conventional DVD movies) be able to play the video data that is encoded on the DICOM DVD. The MPEG2 bit stream that is “encapsulated” by the DICOM Transfer Syntax is potentially re-usable by such applications, if the appropriate UDF structure is created to share the same extent between the DICOM file and the file format and folder structure used by the consumer DVD Video format. Alternatively, the bit stream could be duplicated and both sets of files present on the same piece of media.
This profile does not require this, nor specify which approach to take. Specifically, this profile does not require that a DVD Video file and folder structure be present, though it is recommended.