Three standard Query/Retrieve Information Models are defined in this Annex. Each Query/Retrieve Information Model is associated with a number of SOP Classes. The following three hierarchical Query/Retrieve Information Models are defined:
Patient Root
Study Root
Patient/Study Only
The Patient Root Query/Retrieve Information Model is based upon a four level hierarchy:
Patient
Study
Series
Composite Object Instance
The patient level is the top level and contains Attributes associated with the Patient Information Entity (IE) of the Composite IODs as defined in PS3.3. Patients IEs are modality independent.
The study level is below the patient level and contains Attributes associated with the Study IE of the Composite IODs as defined in PS3.3. A study belongs to a single patient. A single patient may have multiple studies. Study IEs are modality independent.
The series level is below the study level and contains Attributes associated with the Series, Frame of Reference and Equipment IEs of the Composite IODs as defined in PS3.3. A series belongs to a single study. A single study may have multiple series. Series IEs are modality dependent. To accommodate this modality dependence, the set of Optional Keys at the series level includes all Attributes defined at the series level from any Composite IOD defined in PS3.3.
The lowest level is the Composite Object Instance level and contains Attributes associated with the Composite object IE of the Composite IODs as defined in PS3.3. A Composite Object Instance belongs to a single series. A single series may contain multiple Composite Object Instances. Most composite object IEs are modality dependent. To accommodate this potential modality dependence, the set of Optional Keys at the Composite Object Instance level includes all Attributes defined at the Composite Object Instance level from any Composite IOD defined in PS3.3.
The Study Root Query/Retrieve Information Model is identical to the Patient Root Query/Retrieve Information Model except the top level is the study level. Attributes of patients are considered to be Attributes of studies.
Some optional Attributes that may be used in Query/Retrieve Information Models that are not Attributes of an Information Object Definition and, therefore, are not defined in PS3.3. These Attributes are defined in Table C.3-1.
Table C.3-1. Additional Query/Retrieve Attributes
|
Attribute Name |
Tag |
Attribute Description |
|---|---|---|
|
Number of Patient Related Studies |
(0020,1200) |
The number of studies that match the Patient level Query/Retrieve search criteria |
|
Number of Patient Related Series |
(0020,1202) |
The number of series that match the Patient level Query/Retrieve search criteria |
|
Number of Patient Related Instances |
(0020,1204) |
The number of Composite Object Instances that match the Patient level Query/Retrieve search criteria |
|
Number of Study Related Series |
(0020,1206) |
The number of series that match the Study level Query/Retrieve search criteria |
|
Number of Series Related Instances |
(0020,1209) |
The number of Composite Object Instances in a Series that match the Series level Query/Retrieve search criteria |
|
Number of Study Related Instances |
(0020,1208) |
The number of Composite Object Instances that match the Study level Query/Retrieve search criteria |
|
Modalities in Study |
(0008,0061) |
All of the distinct values used for Modality (0008,0060) in the Series of the Study. |
|
SOP Classes in Study |
(0008,0062) |
The SOP Classes contained in the Study. |
|
Alternate Representation Sequence |
(0008,3001) |
A Sequence of Items, each identifying an alternate encoding of an image that matches the Instance level Query/Retrieve search criteria (see Section C.6.1.1.5.1) |
If the SCP manages images in multiple alternate encodings, only one of the alternate encodings of an image is included in the number of object instances.
When Query/Retrieve View (0008,0053) is present with a value of "CLASSIC" or "ENHANCED" in a C-FIND, C-MOVE or C-GET Request Identifier, then the Information Model against which the query or retrieval is performed and any SOP Instances that are retrieved shall be returned, constructed or converted according to the requirements in this section.
There are no requirements with respect to when such instances are actually created or persisted, only that they be available on request. I.e., they may be created in advance (cached) or they may be created dynamically as required, as long as the process is deterministic in the sense that the same Attributes will be populated with the same values on successive queries and retrievals (including UIDs).
The UID generation process is required to be deterministic but it is important to remember that appending a suffix to an existing UID is not a valid approach to generating a new UID, unless the converter is the producer (owner of the root) of the original UID and knows that this is safe and the result will be unique.
The cross-references between original and converted instances contain sufficient information to recover UIDs in the alternative form.
All instances for a Patient known to the SCP shall be converted as necessary to maintain referential integrity and to avoid information loss.
It is not permitted to fail to include a subset of instances within this scope, for example, the presentation states or key object selection documents, in the "ENHANCED" view, in order to avoid the effort of creating new instances with updated references required to maintain referential integrity. In other words, the total "information content" of any view will be no less than that of the default view.
This does not mean that all instances need to be converted, since if they contain no such references, they can be left alone and included in the view. For example, a Classic single slice CT localizer image with no references can remain unchanged in the view as a CT Image Storage SOP Class with its existing SOP Instance UID and SOP Class and in its existing Series, and be referenced from converted instances, such as the axial images prescribed from it. An SCU cannot make any assumptions about what will or will not be converted, or in what order.
It is understood that the requirements of this section are applicable to a single SCP; it is not possible to require all SCPs that perform conversion to perform it the same way, or create the same UIDs, etc.
In addition to the general requirements in this section, specific requirements apply to the following types of instance created:
Enhanced (true or legacy converted) multi-frame images that are created from Classic single frame images
Classic single frame images that are created from Enhanced (true or legacy converted) multi-frame images
Instances that contain references to the SOP Instance UIDs or Series Instance UIDs corresponding to either the converted single frame images, or other instances with such references
The general requirements are that:
The new Composite Instance shall have a new SOP Instance UID.
The new Composite Instance shall be a valid SOP Instance (i.e., will comply with the IOD, Module and Attribute requirements for the Storage SOP Class).
- The new Composite Instance shall contain the Contributing Equipment Sequence (0018,A001). If the source Composite Instances already contain the Contributing Equipment Sequence with a consistent set of Item values (excluding Contribution DateTime (0018,A002)), then a new Item shall be appended to the copy of the sequence in the new Composite Instance; if the source Composite Instance does not contain the Contributing Equipment Sequence or the Item values (excluding Contribution DateTime (0018,A002)) differ between source instances, then Contributing Equipment Sequence shall be created, containing one new Item. In either case, the new Item shall describe the equipment that is creating the new Composite Instance, and the Purpose of Reference Code Sequence (0040,A170) within the Item shall be (ddddd1, DCM, "Enhanced Multi-frame Conversion Equipment") and the Contribution Description (0018,A003) shall be "Legacy Enhanced Image created from Classic Images", "Classic Image created from Enhanced Image", or "Updated UID references during Legacy Enhanced Classic conversion" as appropriate.
The new Composite Instance shall have the same Patient and Study level information as the source Instance, including the same Study Instance UID.
The new Composite Instance shall have the same spatial and temporal Frame of Reference information as the source instance, if present (e.g., the Frame of Reference UID shall be the same).
The new Composite Instance shall be placed in a new Series (together with other new Composite Instances that share the same, new Series level information), with a new Series Instance UID. The Series Date (0008,0021) and Series Time (0008,0031) of all the Instances in the new Series shall be the earliest of the values in the source Composite Instances, if present.
The new Series Date and Time shall NOT be that of when the conversion was performed, but shall reflect the values in the source images.
There is no standard requirement or mechanism defined to change or preserve other Series level Attributes, such as Series Number or Series Description. This is left to the discretion of the implementer, particularly in cases where instances from different Series are merged.
The new Composite Instance shall have the same Items and Values of Request Attributes Sequence (0040,0275) as the source Composite Instances, if Request Attributes Sequence (0040,0275) is present in any of the source Composite Instances.
If the new Composite Instance contains references to another entity for the same Patient (including, but not limited to, references to SOP Instances, Series, Studies or Frames of Reference), and the target of those references is also converted, then the references shall be changed to refer to the converted entity.
For example, if the source instance refers to an instance in a Series, and the referenced instance is also converted, and hence placed in a new Series, then both the SOP Instance UID and the Series Reference UID in the hierarchical reference to the instance will need to be updated, as will the SOP Class UID of the referenced instance, if that has changed, as it likely will have.
The overall intent is to maintain referential integrity within the converted set of instances, within the scope of the same Patient. Since it is likely that most if not all non-image instances for a patient will reference images that will be converted, this means that most if not all non-image instances will also have to be "converted", for the purpose of updating such references. This referential integrity is required regardless of whether the initial request is for a subset of instances for the patient only, or not.
The UIDs referenced in Conversion Source Attributes Sequence (0020,9172) are not converted, since by definition, these reference instances in the "other" view; they should not exist in the source, but will be inserted (or be replaced, if previously converted) during conversion.
The specific requirements for the conversion of single frame images to Enhanced Multi-frame images are:
The SOP Class of the new Composite Instance shall be the appropriate modality-specific Enhanced Image Storage SOP Class that is intended for de novo creation by an acquisition or post-processing device, unless the source images do not contain sufficient information to populate mandatory Attributes with standard Enumerated Values and Defined Terms or Coded Sequence Item values, in which case the appropriate modality-specific Legacy Converted Enhanced Image Storage SOP Class shall be used. The appropriate SOP Classes are defined in Table C.3.5-1.
For example, if the source images to be converted are of the CT Image Storage SOP Class, then the preferred new SOP Class is the Enhanced CT Image Storage SOP Class, but if this is not possible, the Legacy Converted Enhanced CT Image Storage SOP Class is used.
It is not intended that images from different modalities be combined in the same new Composite Instance. For example, it is not expected that CT and PET images would be combined in the same Instance, since the technique Attributes and the pixel data characteristics are quite distinct.
It is expected that as many single frame images will be combined into a single multi-frame image as is sensible, given the constrains on what Attributes must be identical as defined in this section, and depending on the type of images and the size of the resulting object. Different implementations may make different choices in this respect. For example, an application might choose to combine only images in the same Series, or with the same slice spacing, or the same values for Image Type, or with the same Image Orientation (Patient).
The new Composite Instance shall not be contained in a Concatenation. This means that it shall not contain a Concatenation UID (0020,9161) Attribute or other Concatenation Attributes. If the existing Composite Instance contains such Attributes, they shall not be included in the new Composite Instance.
The new Composite Instance contains only one set of Attributes for the Image Pixel Module, hence the contents of the Image Pixel Module shall either be identical in all source images, or the Pixel Data for each frame shall be converted as necessary to match the Image Pixel Module of the new Composite Instance.
In particular this means that the values of Rows, Columns, Bits Stored, Bits Allocated, High Bit, Pixel Representation, Samples per Pixel, Photometric Interpretation and Planar Configuration applicable to all of the frames needs to be the same. In special cases, such as where Bits Stored is less than Bits Allocated but varies per frame, it may be safe to use the largest value for all the frames and ensure that any unused high bits are appropriately masked before encoding. It is not expected that source images with different numbers of Rows and Columns will be combined (by padding the periphery of images smaller than the largest); quite apart from not being the intended use case, this has the potential to greatly expand the size of the instance, and might also require adjustment of the Image Position (Patient) values.
Special attention should be given to the Pixel Padding Value and associated Attributes, in case these vary per frame in the source images, in which case the Pixel Data for some frames may need to be modified to be consistent with all the other frames.
It is possible to change the Image Pixel Module Attributes related to compressed Transfer Syntaxes (including lossy or irreversible compression) during conversion.
All mandatory Attributes of all mandatory Modules and Functional Group Macros of the SOP Class of the new Composite Instance shall be populated as required by the IOD. In this context, "mandatory" means either required or conditional where the condition is satisfied.
For example, if the source images to be converted are of the CT Image Storage SOP Class, and the new Composite Instance is of the Legacy Converted Enhanced CT Image Storage SOP Class, then it is required that the Pixel Measures Functional Group be populated from Pixel Spacing, that the Plane Position (Patient) Functional Group be populated from Image Position (Patient), etc. In addition, if Body Part Examined is present in the source images with a standard value, then the condition for the inclusion of the Frame Anatomy Functional Group is satisfied, and the value therein needs to be converted to the appropriate Anatomic Region Sequence code.
All optional Attributes, Modules and Functional Group Macros for which corresponding information is present in the source images in standard Attributes shall also be populated.
All Attributes of the Overlay Module shall be removed and converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation); if the Overlay uses high bits in the Pixel Data (7FE0,0010) these shall be extracted and encoded in Overlay Data (60xx,3000) in the Presentation State and shall be set to zero in the Pixel Data (7FE0,0010) Attribute in the converted image.
The extraction of Overlays from multiple frames may lead to a proliferation of GSPS Instances (one per converted frame), unless the converter recognizes commonality in the binary values of overlay bit planes and factors it out into fewer GSPS objects that each apply to multiple frames.
All Attributes of the Curve Module (retired, but formerly defined in DICOM) shall be removed; they may be converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation) or a Waveform as appropriate, but this is not required.
All Attributes of the Graphic Annotation Sequence (0070,0001) (not defined in Classic image IODs, but sometimes used in a Standard Extended SOP Class) shall be removed; they may be converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation), but this is not required.
All remaining Attributes in the source images (i.e., those that have not been used to populate mandatory or optional Attributes in Modules and Functional Groups), including Private Attributes, shall be copied into the top-level Data Set or the Unassigned Shared Converted Attributes Sequence (0020,9170) if they are present in all of the source images for the new Composite Instance, have the same number of values, and have the same values, otherwise they shall be copied into the Unassigned Per-Frame Converted Attributes Sequence (0020,9171).
The semantics of Private Attributes, or Standard Attributes used in a Standard Extended SOP Class, might not be maintained, being unknown to the converting application; for example, referential integrity of UIDs in Private Attributes might not be updated.
The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Reference Functional Group Macro.
The specific requirements for the conversion of Enhanced Multi-frame images to Classic single frame images are:
The SOP Class of the new Composite Instance shall be the appropriate modality-specific (Classic) Image Storage SOP Class that is intended for de novo creation by an acquisition or post-processing device.
For example, if the source images to be converted are of the Enhanced CT Image Storage SOP Class or the Legacy Converted Enhanced CT Image Storage SOP Class, then the new SOP Class is the CT Image Storage SOP Class.
All mandatory Attributes of the IOD of the SOP Class of the new Composite Instance shall be populated. In this context, "mandatory" means either required or conditional where the condition is satisfied.
For example, if the source images to be converted are of the Legacy Converted Enhanced CT Image Storage SOP Class, and the new Composite Instance is of the CT Image Storage SOP Class, then it is required that Pixel Spacing be populated from the Pixel Measures Functional Group, that Image Position (Patient) be populated from the Plane Position (Patient) Functional Group, etc.
All optional Attributes in Modules of the IOD for which corresponding information is present in the source images shall also be populated.
All remaining Attributes in the source images (i.e., those that have not been used to populate mandatory or optional Attributes in Modules), including Private Attributes, shall be copied from the top-level Data Set and the Shared Functional Group Macro and the corresponding Item of the Per-Frame Functional Group Macro into the top-level Data Set of the new Composite Instance, including those in the Unassigned Shared Converted Attributes Sequence (0020,9170) and the corresponding Item of the Unassigned Per-Frame Converted Attributes Sequence (0020,9171) (which will result in a Standard Extended SOP Class).
Identifying Attributes, such as Series Number or Series Description, will be present in the Unassigned functional groups, and UIDs will be present in the Conversion Source Attributes Sequence, allowing, for example, the original Series organization to be recovered, whether or not a single Series was previously converted into a single Legacy Converted instance or it was split or merged with other Series.
The integrity of the set of Private Attributes recovered in this manner cannot be guaranteed to result in the correct function of any applications that depend on them, but the expectation is that this will be no better or worse than the impact of storing instances with private Attributes on any Storage SCP that may or may not reorganize and/or selectively preserve Private Attributes.
The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) in the SOP Common Module.
The specific requirements for the conversion of other instances are:
The new Composite Instance shall be an instance of the same SOP Class as the source Composite Instance.
The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) in the SOP Common Module.
Table C.3.5-1. Modality-Specific SOP Class Conversions
|
Classic |
True Enhanced |
Legacy Converted Enhanced |
|---|---|---|
|
CT Image Storage |
Enhanced CT Image Storage |
Legacy Converted Enhanced CT Image Storage |
|
MR Image Storage |
Enhanced MR Image Storage |
Legacy Converted Enhanced MR Image Storage |
|
PET Image Storage |
Enhanced PET Image Storage |
Legacy Converted Enhanced PET Image Storage |