DICOM Correction Item



November 4, 1999

DICOM CORRECTION PACKET 6

This package contains Correction Proposals CP 130, CP 131, CP 133, CP 134, CP 135, CP 143, CP 146, CP 152, CP 154, CP 155, CP 156, CP 168, CP 169, CP 170, CP 171, CP 172, CP 173, CP 175, and CP 177

File: cpack 006.doc

DICOM Correction Item

|Correction Number CP-130 |

|Log Summary: Specify DT VR matching for Query/Retreive |

|Type of Modification |Name of Standard |

|Clarification by addition of items |PS 3.4 - 1999 |

|Rationale for Correction |

|PS 3.4 does not specify a mechanism for matching the Date Time (DT) VR. |

|This has not been a problem because few attributes use the DT VR, but proposed IODs may, since DT has several potential |

|advantages, including the optional inclusion of timezone information, and the unambiguous ability to match a date/time range. |

|Also, whether or not single value date and time matching is by string or by meaning is unclear. This is therefore clarified by a|

|note to indicate that matching is by meaning. |

|Sections of documents affected |

|See below ... |

|Correction Wording: |

C.2.2.2.1 Single Value Matching

If the value specified for a Key Attribute in a request is non-zero length and if it is:

a) ; not a date or time or date and time, contains no wild card characters

b) ; a date or time or date and time, contains a single date or time or date and time with no "-"

then single value matching shall be performed. Only entities with values which match exactly the value specified in the request shall match. This matching is case-sensitive.

Notes: 1.This definition implies that dates or times or dates and times are matched by their meaning, not as literal strings. For example:

- the DT “19980128103000.0000” matches “19980128103000”

- the DT “19980128103000GMT” matches “19980128073000GMT-3”

- the TM “2230” matches “223000”

- the TM “223000” matches the deprecated ACR/NEMA 2.0 form “22:30:00”

- the DA “19980128” matches the deprecated ACR/NEMA 2.0 form “1998.01.28”

2.If an application is concerned about how single value matching of dates and times is performed by another application, it may consider using range matching instead, which is always performed by meaning, with both values in the range the same.

C.2.2.2.5 Range Matching

If the Attribute is a date, then:

a); A string of the form " - " shall match all occurrences of dates which fall between and inclusive

b); A string of the form "- " shall match all occurrences of dates prior to and including

c); A string of the form " -" shall match all occurrences of and subsequent dates

If the Attribute is a time, then:

a); A string of the form " - " shall match all occurrences of times which fall between and inclusive

b); A string of the form "- " shall match all occurrences of times prior to and including

c); A string of the form " -" shall match all occurrences of and subsequent times

If the Attribute is a date and time, then:

a); A string of the form " - " shall match all moments in time which fall between and inclusive

b); A string of the form "- " shall match all moments in time prior to and including

c); A string of the form " -" shall match all moments in time subsequent to and including

d) The timezone, if present in the Value of the Attribute, shall be taken into account for the purposes of the match.

Range matching is not defined for types of Attributes other than dates and times.

DICOM Correction Proposal Form

|Correction Number CP-131 |

|Log Summary: Timezone specification in SOP Common |

|Type of Modification |Name of Standard |

|Addition of feature |PS 3.3,3.6-1999 |

|Rationale for Correction |

|The DT Value Representation is defined in Local Time, and may contain an offset from Coordinated Universal Time. |

|This offset is very important for applications for which timing relationship between SOP Instances is critical (e.g. to avoid |

|daylight saving dependency). |

|Currently, only DA and TM Value Representations are used by the Standard. Therefore, no mechanism to get from Coordinated |

|Universal Time is available. |

|It is not realistic to change the VR encoding rules of DA and TM to add a timezone. Though it would be possible to specify a |

|mechanism to specify a timezone for individual attributes, this would be unwieldy. Accordingly the proposal here specifies |

|timezone information that applies to all DA and TM (and DT without an explicit timezone) Attributes. |

|Sections of documents affected |

|PS 3.3, section C.12.1 |

|PS 3.6, section 6 |

|Correction Wording: |

PS 3.3 Change :

C.12.1 SOP Common Module

in the table C.12.1, add the following :

|Attribute Name |Tag |Type |Attribute Description |

|Timezone Offset From UTC |(0008,0201) |3 |Contains the offset from UTC to the timezone for all DA and TM|

| | | |Attributes present in this SOP Instance. |

| | | |Encoded as an ASCII string in the format “&ZZZZ”. The |

| | | |components of this string, from left to right, are & = “+” or |

| | | |“-”, and ZZZZ = Hours and Minutes of offset. |

| | | |Notes: 1. This encoding is the same as described in PS 3.5 |

| | | |for the DT Value Representation. |

| | | |2. This Attribute does not apply to values with a DT Value |

| | | |Representation, which may contain an explicitly encoded |

| | | |timezone. |

| | | |Time earlier than UTC is expressed as a negative offset. |

| | | |Example: |

| | | |UTC = 5.00 a.m. |

| | | |Local Time = 3.00 a.m. |

| | | |Offset = -0200 |

| | | |Note: If Local Time = 1.00 a.m. and Offset = -0200, then UTC |

| | | |= 11.00 p.m. (23.00) the day before. |

| | | |The local timezone offset is undefined if this Attribute is |

| | | |absent. |

Change in PS 3.6

6 Registry of DICOM Data Elements

Add the following Data Elements :

|Tag |Name |VR |VM |

|(0008,0201) |Timezone Offset From UTC |SH |1 |

DICOM Correction Item

|Correction Number CP-133 |

|Log Summary: Add support for associating contours in Bifurcated RT Structures |

|Type of Modification: |Name of Standard |

|Extension |PS 3.3-1999 |

| |PS 3.6-1999 |

|Rationale for Correction: |

| |

|The RT Structure Set object provides capability for storing bifurcated patient structures, but does not provide a mechanism to |

|identify which structure contours belong to which branch of the structure. |

| |

|This proposal addresses this deficiency by adding optional attributes that identify attached contours within a structure. |

|Sections of document affected: |

| |

|DICOM 1999 Part 3 (Information Object Definitions), Section C.8.8.6 (ROI Contour Module) |

|DICOM 1999 Part 6 (Data Dictionary) |

|Correction Wording: |

| |

| |

|In DICOM 1999 Part 3, Table C.8.8.6-1 (ROI Contour Module), the following new attributes should be added immediately following |

|the Contour Sequence (3006,0040) attribute: |

| |

|>>Contour Number (3006,0048) 3 Identification number of the contour. The |

|value of Contour Number (3006,0048) shall |

|be unique within the Contour Sequence |

|(3006,0040) in which it is defined. No |

|semantics or ordering shall be inferred from |

|this attribute. |

| |

|>>Attached Contours (3006,0049) 3 List of Contour Number (3006,0048) defining |

|lower-numbered contour(s) to which the current contour is connected. |

| |

| |

|In DICOM 1999 Part 6 (Data Dictionary), two new attributes should be added: |

| |

|(3006,0048) Contour Number IS 1 |

|(3006,0049) Attached Contours IS 1-n |

DICOM Correction Item

|Correction Number CP-134 |

|Log Summary: Add Instance Number to DICOM RT Objects |

|Type of Modification: |Name of Standard |

|Extension |PS 3.3-1999 |

|Rationale for Correction: |

| |

|Change Proposal 99 (Extended Query Retrieve Model) requires that the Attribute Instance Number (0020, 0013), formerly Image |

|Number, be added as an optional attribute in all Composite non-image objects that do not already contain it. |

| |

|This proposal implements this requirement in existing DICOM objects RT Dose, RT Structure Set, and RT Plan. |

|Sections of document affected: |

| |

|DICOM 1999 Part 3 (Information Object Definitions), Sections C.8.8.2 (RT Image Module), C.8.8.3 (RT Dose Module), C.8.8.5 |

|(Structure Set Module), and C.8.8.9 (RT General Plan Module). |

|Correction Wording: |

| |

|In DICOM 1999 Part 3 Section C.8.8.2.5 (Single frame and multi-frame images), the text "Image Number" should be changed to |

|"Instance Number". |

| |

| |

|In DICOM 1999 Part 3 Table C.8.8.3-1 (RT Dose Module), the following new attribute should be added immediately following the |

|Dose Type (3004,0004) attribute: |

| |

|Instance Number (0020,0013) 3 A number that identifies this object instance. |

| |

| |

|In DICOM 1999 Part 3 Table C.8.8.5-1 (Structure Set Module), the following new attribute should be added immediately following |

|the Structure Set Description (3006,0006) attribute: |

| |

|Instance Number (0020,0013) 3 A number that identifies this object instance. |

| |

| |

|In DICOM 1999 Part 3 Table C.8.8.9-1 (RT General Plan Module), the following new attribute should be added immediately following|

|the RT Plan Description (300A,0004) attribute: |

| |

|Instance Number (0020,0013) 3 A number that identifies this object instance. |

DICOM Correction Item

|Correction Number CP-135 |

|Log Summary: Add Compensator Type to RT Plan object |

|Type of Modification: |Name of Standard |

|Extension |PS 3.3-1999 |

| |PS 3.6-1999 |

|Rationale for Correction: |

| |

|The RT Plan object does not provide a mechanism to identify whether treatment compensators are implemented as standard (fixed) |

|compensators, or implemented dynamically using collimator leaves or jaws. |

| |

|This proposal introduces an optional attribute to convey this information. |

|Sections of document affected: |

| |

|DICOM 1999 Part 3 (Information Object Definitions), Section C.8.8.14 (RT Beams Module) |

|DICOM 1999 Part 6 (Data Dictionary) |

|Correction Wording: |

| |

|In DICOM 1999 Part 3, Table C.8.8.14-1 (RT Beams Module), the following new attribute should be added immediately following the |

|Compensator Number (300A,00E4) attribute: |

| |

|Compensator Type (300A,00EE) 3 Type of compensator (if any). Defined Terms: |

|STANDARD = physical (static) compensator |

|DYNAMIC = moving Beam Limiting Device |

|(collimator) simulating physical compensator |

| |

| |

| |

|In DICOM 1999 Part 6 (Data Dictionary), a new attribute should be added: |

| |

|(300A,00EE) Compensator Type CS 1 |

DICOM Correction Item

|Correction Number CP-143 |

|Log Summary: Palette Color Lookup Table clarifications |

|Type of Modification |Name of Standard |

|Clarification |PS 3.3,3.5,3.6-1999 |

|Rationale for Correction |

|Several problems have been identified with Palette Color Lookup Table encoding. |

|The VR of the Red/Green/Blue Palette Color Lookup Table Descriptors (0028,1101), (0028,1102), (0028,1103) are defined in PS 3.6 |

|Section 6 to be US/US or US/SS, yet have a Value Multiplicity of 3 (not two). In PS 3.3 C.7.6.3.1.5 the first value is defined |

|to be the number of entries, the second the first stored pixel value mapped, and the third the number of bits in the LUT |

|entries. |

|When encoding in Explicit VR, only one VR, US or SS can be specified, not different VRs for different values. |

|There is no description of how or when to chose SS or US VR. The VR of the second value (first stored pixel value mapped) can be|

|determined by Pixel Representation (0028,0103). |

|However, a signed pixel representation makes no sense for the other values. |

|Specifically, if the number of entries (first value of the descriptor) was encoded as SS then the table size would be limited to|

|less than 215-1, except for the special case of zero that is defined to be 216 in PS 3.3 C.7.6.3.1.5. |

|The changes proposed here specify the VR to be US or SS depending on Pixel Representation (0028,0103), but define the first and |

|third values to always be interpreted as unsigned regardless of the actual VR. They are consistent with the changes to other |

|LUTs defined in Supplement 33, and do not rpeclude the use of signed pixel data with palette color LUTs. |

|The wording of PS 3.3 C.7.6.3.1.5 incorrectly refers to the first or last entry rather than value mapped in some cases and does |

|not include the case where the value is equal to the first value mapped plus the number of entries. |

|PS 3.3 C.7.6.3.1 is not explicit when it defines how 16 bit palette color tables should be used to store 8 bit data. This leads |

|to confusion on the part of implementers who create and parse such images. The statement in C.7.6.3.1.5 implies that padding |

|should not be used but the text of C.7.6.3.1.6 specifies what value to use when padding the data, a direct contradiction. |

|Finally, Supplement 5 which revised the ultrasound objects and the definition of Palette Color LUTS in the Image Pixel Module |

|changed the definition of encoding of Palette Color LUT Data in PS 3.5-1993 Annex A to specify always OW for all Transfer |

|Syntaxes and added a VR or OW to the existing US/SS specified in PS 3.6-1993. Note that a 64k LUT cannot be encoded in an |

|explicit VR of US or SS since the VL field is restricted to 16 bits. |

|This means that PS 3.5 and PS 3.6 are in conflict, since the Palette Color LUT Data elements cannot be encoded as other than OW.|

|Here the US and SS VRs in PS 3.6-1998 are removed. |

|Also, for cases where the Palette Color LUT Data elementsare used without the Palette Color Module (eg. in Secondary Capture |

|objects), the possibility of packing 8 bit table values into bytes needs to be made consistent with the definition of other LUTs|

|(Modality LUT, VOI LUT) though the VR remains OW and not OB (otherwise the byte order would be different for explicit VR |

|big-endian transfer syntax). |

|Note that this change does not affect an implementation creating or reading LUT Data in the default Implicit VR Transfer Syntax |

|since the byte order of OW or OB or US or SS is always little endian. |

|Sections of documents affected |

|PS 3.3-1999 C.7.6.3.1 |

|PS 3.5-1999 Annex A |

|PS 3.6-1999 Section 6 |

|Correction Wording: |

Amend PS 3.3-1998 Section C.7.6.3.1 to revise definition of Palette Color LUT Descriptors

C.7.6.3.1.5 Palette Color Lookup Table Descriptor

The three values of Palette Color Lookup Table Descriptor (0028,1101-1103) describe the format of the Lookup Table Data in the corresponding Data Element (0028,1201-1203) or (0028,1221-1223).

The first value is the number of entries in the lookup table. When the number of table entries is equal to 216 then this value shall be 0.

The second value is the first stored pixel value mapped. This pixel value is mapped to the first entry in the Lookup Table Data. All image pixel values less than the first entry value mapped are also mapped to the first entry in the Lookup Table Data. An image pixel value one greater than the first entry value mapped is mapped to the second entry in the Lookup Table Data. Subsequent image pixel values are mapped to the subsequent entries in the Lookup Table Data up to an image pixel value equal to number of entries + first entry value mapped - 1 which is mapped to the last entry in the Lookup Table Data. Image pixel values greater than or equal to number of entries + first entry value mapped are also mapped to the last entry in the Lookup Table Data.

The third value specifies the number of bits for each entry in the Lookup Table Data. It shall take the value of 8 or 16. The LUT Data shall be stored in a format equivalent to 8 or 16 bits allocated where the high bit is equal to bits allocated-1.

When the Palette Color Lookup Table Descriptor (0028,1101-1103) are used as part of the Palette Color Lookup Table Module, the third value shall be equal to 16.

Note: A value of 16 indicates the Lookup Table Data will range from (0,0,0) minimum intensity to (65535,65535,65535) maximum intensity.

Note: Since the Palette Color Lookup Table Descriptor (0028,1101-1103) Attributes are multi-valued, in an Explicit VR Transfer Syntax, only one value representation (US or SS) may be specified, even though the first and third values are always by definition interpreted as unsigned. The explicit VR actually used is dictated by the VR needed to represent the second value, which will be consistent with Pixel Representation (0028,0103).

C.7.6.3.1.6 Palette Color Lookup Table Data

Palette Color Lookup Table Data (0028,1201-1203) contain the lookup table data corresponding to the Lookup Table Descriptor (0028,1101-1103). If padding is required to complete a full word, the padding value shall be 0.

Palette color values must always be scaled across the full range of available intensities. This is indicated by the fact that there are no bits stored and high bit values for palette color data.

Note: For example, if there are 16 bits per entry specified and only 8 bits of value are truly used then the 8 bit intensities from 0 to 255 must be scaled to the corresponding 16 bit intensities from 0 to 65535. To do this for 8 bit values, simply replicate the value in both the most and least significant bytes.

These lookup tables shall be used only when there is a single sample per pixel (single image plane) in the image.

...

Amend PS 3.5-1998 Section A to include notes to clarify Palette Color LUT Data VRs.

A.1 DICOM implicit VR little endian transfer syntax

⎯ Data Elements (0028,1201), (0028,1202),(0028,1203) Red, Green, Blue Palette Lookup Table Data have the Value Representation OW and shall be encoded in Little Endian.

Note: Previous versions of the Standard either did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.6 (1996). The actual encoding of the values and their byte order would be identical in each case.

⎯ Data Elements (0028,1101), (0028,1102),(0028,1103) Red, Green, Blue Palette Lookup Table Descriptor have the Value Representation SS or US (depending on rules specified in the IOD in PS 3.3), and shall be encoded in Little Endian. The first and third values are always interpreted as unsigned, regardless of the Value Representation.

A.2 DICOM little endian transfer syntax (explicit VR)

⎯ Data Elements (0028,1201), (0028,1202),(0028,1203) Red, Green, Blue Palette Lookup Table Data have the Value Representation OW and shall be encoded in Little Endian.

Note: Previous versions of the Standard either did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.6 (1996). The actual encoding of the values and their byte order would be identical in each case, though the explicitly encoded VR field would be different. However, an explicit VR of US or SS cannot be used to encode a table of 216 elements, since the Value Length is restricted to 16 bits.

⎯ Data Elements (0028,1101), (0028,1102),(0028,1103) Red, Green, Blue Palette Lookup Table Descriptor have the Value Representation SS or US (depending on rules specified in the IOD in PS 3.3), and shall be encoded in Little Endian. The first and third values are always interpreted as unsigned, regardless of the Value Representation.

A.3 DICOM big endian transfer syntax (explicit VR)

⎯ Data Elements (0028,1201), (0028,1202),(0028,1203) Red, Green, Blue Palette Lookup Table Data have the Value Representation OW and shall be encoded in Big Endian.

Note: Previous versions of the Standard either did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.6 (1996). The actual encoding of the values and their byte order would be identical in each case, though the explicitly encoded VR field would be different. However, an explicit VR of US or SS cannot be used to encode a table of 216 elements, since the Value Length is restricted to 16 bits.

⎯ Data Elements (0028,1101), (0028,1102),(0028,1103) Red, Green, Blue Palette Lookup Table Descriptor have the Value Representation SS or US (depending on rules specified in the IOD in PS 3.3), and shall be encoded in Big Endian. The first and third values are always interpreted as unsigned, regardless of the Value Representation.

A.4 Transfer syntaxes for encapsulation of encoded pixel data

⎯ Data Elements (0028,1201), (0028,1202),(0028,1203) Red, Green, Blue Palette Lookup Table Data have the Value Representation OW and shall be encoded in Little Endian.

Note: Previous versions of the Standard either did not specify the encoding of these Data Elements in this Part, but specified a VR of US or SS in PS 3.6 (1993), or specified OW in this Part but a VR of US, SS or OW in PS 3.6 (1996). The actual encoding of the values and their byte order would be identical in each case, though the explicitly encoded VR field would be different. However, an explicit VR of US or SS cannot be used to encode a table of 216 elements, since the Value Length is restricted to 16 bits.

⎯ Data Elements (0028,1101), (0028,1102),(0028,1103) Red, Green, Blue Palette Lookup Table Descriptor have the Value Representation SS or US (depending on rules specified in the IOD in PS 3.3), and shall be encoded in Little Endian. The first and third values are always interpreted as unsigned, regardless of the Value Representation.

Amend PS 3.6-1998 Section 6 to revise (50xx,3000) VR.

6 Registry of DICOM data elements

|(0028,1101) |Red Palette Color Lookup Table Descriptor |US\US or SS\US |3 | |

| | |US or SS | | |

|(0028,1102) |Green Palette Color Lookup Table Descriptor |US\US or SS\US |3 | |

| | |US or SS | | |

|(0028,1103) |Blue Palette Color Lookup Table Descriptor |US\US or SS\US |3 | |

| | |US or SS | | |

|(0028,1201) |Red Palette Color Lookup Table Data |US or SS |1-n | |

| | |or OW |1 | |

|(0028,1202) |Green Palette Color Lookup Table Data |US or SS |1-n | |

| | |or OW |1 | |

|(0028,1203) |Blue Palette Color Lookup Table Data |US or SS |1-n | |

| | |or OW |1 | |

DICOM Correction Item

|Correction Number CP-146 |

|Log Summary: Clarification of Query/Retrieve Behavior |

|Type of Modification |Name of Standard |

| |PS 3.4,3.7-1999 |

|Rationale for Correction |

|Several problems have been identified with the Q/R Service Class. |

|1. PS 3.4 Section C.4.1.1.3.2 specifies attributes that shall be present in a C-FIND response identifier, including the mutually|

|alternative Retrieve AE Title Data Element or the Storage Media File-Set ID/Storage Media File Set UID Data Elements. |

|It is not entirely clear that the SCP shall always provide these Attributes in the response and they should never be included in|

|the request. A note is added to clarify this. |

|Also it is made more clear that Retrieve AE Title Data Element or the Storage Media File-Set ID/Storage Media File Set UID are |

|potentially mutually exclusive. |

| |

|2. The requirements for the presence or absence of an Identifier in a C-Move or C-Get Response are in conflict: |

|- in PS 3.7 Section 9.1.4.1 describing the C-Move Parameters and Section 9.1.3.1 describing the C-Get Parameters, the Identifier|

|in the Response/Confirmation is specified as User Optional with its contents and rules defined in PS 3.4. This is consistent |

|with the separation of layer definition between Part 4 and Part 7 but is potentially confusing. |

|- in PS 3.4 Sections C.4.2.1.4 and C.4.3.1.3 it states both the C-Move/C-Get requests and responses contain an Identifier |

|- in PS 3.4 Sections C.4.2.1.4.2 and C.4.3.1.3.2 it states that an identifier in a C-Move/C-Get responses shall conditionally |

|contain the Failed SOP Class UID List if sub-operations failed, and be absent otherwise |

|It is proposed here that all these sections specify Conditional, not User Optional or Required. |

| |

|3. PS 3.4 Section C.6 implies that at the IMAGE level in a C-MOVE or C-GET, a list of SOP Instance UIDs may be specified for |

|retrieval. This is also suggested by the plural "SOP Instance UIDs" in C.4.2.1.4.1 and C.4.3.1.3.1. This is further implied by |

|the description of additional behavior that is possible for relational retrievals in C.4.2.2.2.1 and C.4.3.2.2.1. |

|Unfortunately, the descriptions of the baseline behavior of SCU (C.4.2.2.1 and C.4.3.2.1) and SCP (C.4.2.3.1 and C.4.3.3.1) are |

|in conflict. The SCU behavior states that a list of UIDs may be specified at the level of the retrieve, whereas the SCP behavior|

|states that a suboperations may be initiated only for a list of SOP Instance UIDs. |

|Even though SOP Instance UID in PS 3.6-1998 has a VM of 1, this VM doesn't apply since the rules for List of UID matching |

|specified in PS 3.4-1998 C.2.2.2.2 already imply that the dictionary VM is overridden for query/retrieve. |

|What is not clearly stated is that, for the baseline behavior, a List of UIDs or other non-single matching may be specified at |

|the lowest level of the C-MOVE or C-GET, but that may be any level of the model, not just the IMAGE level. |

|It is proposed here that this be clarified with notes to C.4.2.1.4.1 and C.4.3.1.3.1 and C.6.1.1.6 and C.6.2.1.5. |

|Sections of documents affected |

|PS 3.4 Sections C.4, C.6 |

|PS 3.7 Section 9.1 |

|Correction Wording: |

Amend PS 3.4 Section C.4.1.1.3.2 to clarify C_FIND response contents.

C.4.1.1.3.2 Response Identifier Structure

The C-FIND response shall not contain Attributes that were not in the request or specified in this section.

An Identifier in a C-FIND response shall contain:

— Key Attributes with values corresponding to Key Attributes contained in the Identifier of the request.

— Query/Retrieve Level, element (0008,0052) which defines the level of the query. The Query/Retrieve level shall be equal to the level specified in the request.

— Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute is required if expanded or replacement character sets are used.

The C-FIND SCP is required to support either or both the Retrieve AE Title Data Element or the Storage Media File-Set ID/Storage Media File Set UID Data Elements. An Identifier in a C-FIND response shall contain:

...

Amend PS 3.4 Section C.4.2 and C.4.3 to clarify C_MOVE and C-GET Identifiers.

C.4.2.1.4 Identifier

Both t The C-MOVE request and response shall contain an Identifier. The C-MOVE response shall conditionally contain an Identifier as required in C.4.2.1.4.2.

Note: The Identifier is specified as U in the definition of the C-MOVE primitive in PS 3.7 but is specialized for use with this service.

C.4.2.1.4.1 Request Identifier Structure

An Identifier in a C-MOVE request shall contain:

— the Query/Retrieve Level (0008,0052) which defines the level of the retrieval

— Unique Key Attributes which may include Patient ID (0010,0020), Study Instance UIDs (0020,000D), Series Instance UIDs (0020,000E), and the SOP Instance UIDs (0008,0018)

The Unique Keys at each level of the hierarchy and the values allowable for the level of the retrieval shall be defined in the SOP Class definition for the Query/Retrieve Information Model.

Note: In the Baseline behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching, but only Single Value Matching value may be specified for Patient ID (0010,0020).

C.4.2.1.4.2 Response Identifier Structure

The Failed SOP Instance UID List (0008,0058) specifies a list of UIDs of the C-STORE sub-operation SOP Instances for which this C-MOVE operation has failed. An Identifier in a C-MOVE response shall conditionally contain the Failed SOP Instance UID List (0008,0058) based on the C-MOVE response status value. If no C-STORE sub-operation failed, Failed SOP Instance UID List (0008,0058) is absent and therefore no Data Set shall be sent in the C-MOVE response.

The Identifier in a C-MOVE response with a status of:

— Canceled, Failed, Refused, or Warning shall contain the Failed SOP Instance UID List Attribute

— Pending shall not contain the Failed SOP Instance UID List Attribute (no Data Set)

...

C.4.2.2.1 Baseline Behavior of SCU

An SCU conveys the following semantics with a C-MOVE request:

— The SCU shall supply a single value in the Unique Key Attribute for each level above the Query/Retrieve level. For the level of retrieve, the SCU shall supply at least one UID unique key if the level of retrieve is above the STUDY level, and may shall supply one UID, or a list of UIDs if a retrieval of several items is desired and the retrieve level is STUDY, SERIES or IMAGE. The SCU shall also supply a move destination. The move destination shall be the DICOM Application Entity Title of a DICOM Application Entity capable of serving as the SCP of the Storage Service Class.

...

C.4.2.3.1 Baseline Behavior of SCP

An SCP conveys the following semantics with a C-MOVE response:

...

— The SCP shall initiate C-STORE sub-operations over the new Association for all stored SOP Instances related to the Patient ID, List of Study Instance UIDs, List of Series Instance UIDs, or List of SOP Instance UIDs depending on the Query/Retrieve level specified in the C-MOVE request.

...

C.4.3.1.3 Identifier

Both t The C-GET request and response shall contain an Identifier. The C-GET response shall conditionally contain an Identifier as required in C.4.3.1.3.2.

Note: The Identifier is specified as U in the definition of the C-GET primitive in PS 3.7 but is specialized for use with this service.

C.4.3.1.3.1 Request Identifier Structure

An Identifier in a C-GET request shall contain:

— the Query/Retrieve Level (0008,0052) which defines the level of the retrieval

— Unique Key Attributes which may include Patient ID (0010,0020), Study Instance UID (0020,000D) Series Instance UID (0020,000E), and SOP Instance UIDs (0008,0018)

The Unique Keys at each level of the hierarchy and the values allowable for the level of the retrieval shall be defined in the SOP Class definition for the Query/Retrieve Information Model.

Note: In the Baseline behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching, but only Single Value Matching value may be specified for Patient ID (0010,0020).

C.4.3.1.3.2 Response Identifier Structure

The Failed SOP Instance UID List (0008,0058) specifies a list of UIDs of the C-STORE sub-operation SOP Instances for which this C-GET operation has failed. An Identifier in a C-GET response shall conditionally contain the Failed SOP Instance UID List (0008,0058) based on the C-GET response. If no C-STORE sub-operation failed, Failed SOP Instance UID List (0008,0058) is absent and therefore no Data Set shall be sent in the C-GET response.

The Identifier in a C-GET response with a status of:

— Canceled, Failed, Refused, or Warning shall contain the Failed SOP Instance UID List Attribute

— Pending shall not contain the Failed SOP Instance UID List Attribute (no Data Set)

C.4.3.2.1 Baseline Behavior of SCU

An SCU conveys the following semantics with a C-GET request:

...

— The SCU shall supply a single value in the Unique Key Attribute for each level above the Query/Retrieve level. For the level of retrieve, the SCU shall supply at least one UID unique key if the level of retrieve is above the STUDY level, and may shall supply one UID, or a list of UIDs if a retrieval of several items is desired and the retrieve level is STUDY, SERIES or IMAGE.

...

C.4.3.3.1 Baseline Behavior of SCP

An SCP conveys the following semantics with a C-GET response:

...

— The SCP shall initiate C-STORE sub-operations over the same Association for all stored SOP Instances related to the Patient ID, List of Study Instance UIDs, List of Series Instance UIDs, or List of SOP Instance UIDs depending on the Query/Retrieve level specified in the C-GET request.

...

Amend PS 3.4 Section C.6.1.1.6 and C.6.2.1.5 to Key Attribute matching for IMAGE level.

C.6.1 Patient Root SOP Class Group

...

C.6.1.1.6 Scope of the GET and MOVE Commands and Sub-Operations

A C-MOVE or C-GET request may be performed to any level of the Query/Retrieve Model. However, the transfer of Stored SOP Instances shall always take place at the Image level. A C-MOVE or C-GET where the Query/Retrieve level is the:

— PATIENT level indicates that all images related to a Patient shall be transferred.

— STUDY level indicates that all images related to a Study shall be transferred.

— SERIES level indicates that all images related to a Series shall be transferred.

— IMAGE level indicates that selected individual images shall be transferred.

Note: In the Baseline behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching, but only Single Value Matching value may be specified for Patient ID (0010,0020).

...

C.6.2 Study Root SOP Class Group

...

C.6.2.1.5 Scope of The GET and MOVE Commands and Sub-Operations

A C-MOVE or C-GET request may be performed to any level of the Query/Retrieve Model. However, the transfer of Stored SOP Instances shall always take place at the Image level. A C-MOVE or C-GET where the Query/Retrieve level is the:

— STUDY level indicates that all images related to a Study shall be transferred

— SERIES level indicates that all images related to a Series shall be transferred

— IMAGE level indicates that selected individual images shall be transferred

Note: In the Baseline behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching,

Amend PS 3.7 Section 9.1.4.1 and 9.1.3.1 to clarify C_MOVE and C-GET response Identifier.

9.1.3.1 C-GET parameters

See Table 9.1-3.

Table 9.1-3

C-GET PARAMETERS

|DIMSE-C Parameter Name |Req/Ind |Rsp/Conf |CnclReq/CnclInd |

|Message ID |M |⎯ |⎯ |

|Message ID Being Responded To |⎯ |M |M |

|Affected SOP Class UID |M |U(=) |⎯ |

|Priority |M |⎯ |⎯ |

|Identifier |M |U |⎯ |

|Status |⎯ |M |⎯ |

|Number of Remaining Sub-operations |⎯ |C |⎯ |

|Number of Completed Sub-operations |⎯ |C |⎯ |

|Number of Failed Sub-operations |⎯ |C |⎯ |

|Number of Warning Sub-operations |⎯ |C |⎯ |

...

9.1.3.1.5 Identifier

...

In the response/confirmation, this is a list of Attributes which provide status information about the C-GET operation. The list of Attributes allowed and the rules which define the usage of the Identifier are specified in PS 3.4.

Note: The Identifier is specified as U in the Response/Confirmation, but Services defined in PS 3.4 that uses this primitive may impose mandatory or conditional requirements on its presence.

...

9.1.4.1 C-MOVE parameters

See Table 9.1-4.

Table 9.1-4

C-MOVE PARAMETERS

|DIMSE-C Parameter Name |Req/Ind |Rsp/Conf |CnclReq/CnclInd |

|Message ID |M |⎯ |⎯ |

|Message ID Being Responded To |⎯ |M |M |

|Affected SOP Class UID |M |U(=) |⎯ |

|Priority |M |⎯ |⎯ |

|Move Destination |M |⎯ |⎯ |

|Identifier |M |U |⎯ |

|Status |⎯ |M |⎯ |

|Number of Remaining Sub-operations |⎯ |C |⎯ |

|Number of Completed Sub-operations |⎯ |C |⎯ |

|Number of Failed Sub-operations |⎯ |C |⎯ |

|Number of Warning Sub-operations |⎯ |C |⎯ |

...

9.1.4.1.6 Identifier

...

In the response/confirmation, this is a list of Attributes which provide status information about the C-MOVE operation. The list of Attributes allowed and the rules which define the usage of the Identifier are specified in PS 3.4.

Note: The Identifier is specified as U in the Response/Confirmation, but Services defined in PS 3.4 that uses this primitive may impose mandatory or conditional requirements on its presence.

DICOM Correction Item

|Correction Number CP-152 |

|Log Summary: Clarification of meaning Type 2 for patient info and accession number |

|Type of Modification: |Name of Standard |

|Clarification |PS 3.3-1999 |

|Rationale for Correction |

|Patient information (ID and Name) as well as the accession number are defined as Type 2 attributes. That means that they can be |

|sent with a length of "0" when unknown. Receiving objects without proper identification creates serious issues for the |

|receivers, i.e. images can not be found ("orphan images") and/or a radiologist cannot do his diagnosis because he cannot tie it |

|to a proper accession number. |

|Often, implementations are not even providing Type 2 attributes at all. The standard clarifies that Type 2 attributes are |

|required unless unknown, i.e. in normal circumstances they should always be provided. |

|Sections of documents affected |

|PS 3.5 |

|Correction wording: |

|Add note to PS 3.5 7.4.3: (definition of Type 2 Required Data Elements) |

|Note: The intent of Type 2 elements is to allow a zero length to be conveyed when the operator or application does not know its |

|value or has a specific reason for not specifying its value. It is the intent that the device should support these Attributes. |

DICOM Correction Item

|Correction Number CP-154 |

|Log Summary: Multibyte Character set clarifications |

|Type of Modification |Name of Standard |

|Clarification |PS 3.3,3.5-1998 |

|Rationale for Correction |

|The default character repertoire or the character repertoire specified by value 1 of Attribute Specific Character Set |

|(0008,0005) may be extended using the Code Extension techniques specified by ISO/IEC 2022. The related Specific Character Sets |

|shall be specified by value 2 to n of the Attribute Specific Character Set (0008,0005). ISO/IEC introduces the concepts code |

|elements (G0,G1,G2 and G3) and the area in which the code elements are invoked (GL or GR). |

|There are certain restrictions in DICOM. One of these restrictions is that the Graphic Character sets G0 and G1 shall be |

|invoked in GL and GR respectively, Code elements G0 and G1 always have shift status, and code elements G2 and G3 are not used. |

|The questions arise when we take a look at tables C.12-3 and C.12-4 in PS3.3. Defined terms for character sets are specified |

|here, and also one ESC sequence and one code element per ISO registration number. |

|Question 1: What is the meaning and intent of this table? Does this table only specify the assumed initial states and associated|

|ESC sequences, or does this table also restrict the allowed ESC sequences to the ones listed? |

| |

|If this table list the allowed ESC sequence, then there’s an inconsistency with PS3.5 Annex H in which additional ESC sequences|

|are used to designate the character sets to other code elements. E.g. ISO-IR 87 and ISO-IR 159 may be designated to G1, and |

|table C.12-4 only lists code element G0 for this character set. In this case Annex H should be clarified. |

| |

|If this table list only the ESC sequences associated with the initial state, and other ESC sequences are allowed, then an |

|additional note would be helpful to make implementers aware that the list in the table is not exhaustive, and more details may |

|be found in PS3.5, and ISO/IEC 2022. |

|Question 2: In PS3.5 section 6.1.2.5.3. the requirement is defined that the default character repertoire shall be active in some|

|listed instances. Switching is needed in front of and after the “=” and “^” characters. But what is meant by: “the default |

|character repertoire”? Is this both the G0 and G1 code element of the default character repertoire, or just the G0 code element?|

|This should be clearly defined. |

|The proposed clarifications are written based on the following assumptions: |

|The ESC sequences listed in tables C.12-3 and C.12-4 are the only ESC sequences allowed for these character repertoires in DICOM|

|Both the G0 and G1 code element of the default character repertoire shall be active at the listed instances. If a default |

|character repertoire does not have a G1 code element, then the G1 code element is undefined in the listed instances. |

|Code Extension techniques are also applicable to UT (Unlimited Text) |

|Sections of documents affected |

| |

|PS 3.3, section C.12.1.1.2 |

|PS 3.5 Section 6.1.2.2: Extension or replacement of the default character repertoire |

|PS 3.5 Section 6.1.2.3: Encoding of character repertoires |

|PS 3.5 Section 6.1.2.4: Code Extension Techniques |

|PS 3.5 Section 6.1.2.5.2: Restrictions for Code Extension |

|PS 3.5 Section 6.1.2.5.3: Requirements |

|PS 3.5 Section 6.1.2.5.4: Levels of Implementation and Initial Designation |

|PS 3.5 Section H.1 |

|PS 3.5 Section H.2 |

|PS 3.5 Section H.3.1 |

|PS 3.5 Section H.3.2 |

|Correction Wording: |

Item: Amend PS 3.3 Section C.12.1.1.2

C.12.1.1.2 Specific Character Set

Specific Character Set (0008,0005) identifies the Character Set that expands or replaces the Basic Graphic Set (ISO 646) for values of Data Elements that have Value Representation of SH,LO,ST,PN ,or LT or UT. See PS 3.5.

......

If the attribute Specific Character Set (0008,0005) has more than one value, Code Extension techniques are used and Escape Sequences may be encountered in all character sets.

Requirements for the use of Code Extension techniques are specified in PS 3.5.

Item: Amend PS 3.3 Section C.12.1.1.2 Table C.12-4 Title:

C.12.1.1.2 Specific Character Set

Table C.12-4 DEFINED TERMS FOR MULTIPLE-BYTE MULTI-BYTE CHARACTER SETS WITH CODE EXTENSIONS

Item: Amend PS 3.5 Section 6.1.2.2: Add UT (Unlimited Text)

6.1.2.2 Extension or replacement of the default character repertoire

....

For Data Elements with Value Representations of SH (Short String), LO (Long String), ST (Short Text), LT (Long Text), or PN (Person Name), or UT (Unlimited Text) the default character repertoire may be extended or replaced (these Value Representations are described in more detail in Section 6.2). If such an extension or replacement is used, the relevant "Specific Character Set" shall be defined as an attribute of the SOP Common Module (0008,0005) (see PS 3.3) and shall be stated in the Conformance Statement. PS 3.2 gives conformance guidelines.

Item: Amend PS 3.5 Section 6.1.2.3:

6.1.2.3 Encoding of character repertoires

The 7-bit default character repertoire can be replaced for use in Value Representations SH, LO, ST, LT, and PN, and UT with one of the single-byte codes defined in PS3.3.

Item: Amend PS 3.5 Section 6.1.2.3:

Note: Considerations on the Handling of Unsupported Character Sets:

In DICOM, character sets are not negotiated between Application Entities but are indicated by a conditional attribute of the SOP Common Module. Therefore, implementations may be confronted with character sets that are unknown to them. The machine should print or display such characters by replacing all unknown characters with the four characters "\nnn", where "nnn" is the three digit octal representation of each byte.

An example of this for an ASCII based machine would be as follows:

Character String: Günther

Encoded representation: 04/07 15/12 06/14 07/04 06/08 06/05 07/02

ASCII based machine: G\374nther

Implementations may also encounter Control Characters which are unknown. The implementations should also replace each Control Character with the four characters “\nnn”, where “nnn” is the three digit octal representation of each byte. Implementations may also encounter Control Characters of which they have no means to print or display. The machine may print or display such Control Character by replacing the Control Character with the four characters "\nnn", where "nnn" is the three digit octal representation of each byte.

Item: Amend PS 3.5 Section 6.1.2.4:

6.1.2.4 Code Extension Techniques

For Data Elements with Value Representation of SH (Short String), LO (Long String), ST (Short Text), LT (Long Text), UT (Unlimited Text), or PN (Person Name), the default character repertoire or the character repertoire specified by value 1 of Attribute Specific Character Set (0008,0005), may be extended using the Code Extension techniques specified by ISO/IEC 2022:1994.

Item: Amend PS 3.5 Section 6.1.2.5.2:

6.1.2.5.2 Restrictions for Code Extension

-- As code elements G0 and G1 always have shift status, Locking Shifts (SI,SO) are not required and shall not be used.

-- As code elements G2 and G3 are not used, Single Shifts (SS2 and SS3) cannot be used.

-- Only the ESC sequences specified in PS 3.3 shall be used to activate Code Elements.

Item: Amend PS 3.5 Section 6.1.2.5.3:

6.1.2.5.3 Requirements

...

If within a textual value a character set other than the one specified in value 1 of the Attribute Specific Character Set (0008,0005), or the default character repertoire if value 1 is missing, has been invoked, there shall be a switch to the character set specified in the value 1, or the default character repertoire if value 1 is missing, shall be active in the following instances:

⎯ before the end of line (i.e., before the CR and/or LF)

⎯ before the end of a page (i.e. before the FF)

⎯ before the end of a Data Element value (e.g. before the 05/12 character code which seperates separates multiple textual Data Element Values — 05/12 correponds corresponds to “\” (BACKSLASH) in the case of default repertoire IR-6 or (YEN SIGN) in the case of IR-14 ).

← before the “^” and “=” delimiters separating name components and name component groups in Data Elements with a VR of PN.

If within a textual value a character set other than the one specified in value 1 of the Attribute Specific Character Set (0008,0005), or the default character repertoire if value 1 is missing, is used, the Escape Sequence of this character set must be inserted explicitly in the following instances:

⎯ before the first use of the character set in the line

⎯ before the first use of the character set in the page

⎯ before the first use of the character set in the Data Element value

⎯ before the first use of the character set in the name component and name component group in Data Element with a VR of PN

Note: These two requirements allow an application to skip lines, values, or components in a textual data element and start the new line with a defined character set without the need to track the character set changes in the text skipped. A similar restriction appears in the RFC describing the use of multi-byte character sets over the Internet. An Escape Sequence switching to the value 1 or default Specific Character Set is not needed within a line, value or component if no Code Extensions are present. Neither is a switch needed to the value 1 or default Specific Character Set if this character set has only the G0 Code Element defined, and the G0 Code Element is still active.

Item: Amend PS 3.5 Section 6.1.2.5.4:

6.1.2.5.4 Levels of Implementaion and Initial Designation

...

c) Attribute Specific Character Set (0008,0005) multi-valued:

.....

Initial designation: One of the ISO 8859-defined character sets, or the 8-bit code table of JIS X 0201 specified by value 1 of the Attribute Specific Character Set (0008,0005),as G0 and G1. If value 1 of the Attribute Specific Character Set (0008,0005) is empty, ISO-IR6 (ASCII) is assumed.as G0, and G1 is undefined.

Item: Amend PS 3.5 Section H.1:

H.1 CHARACTER SETS FOR THE JAPANESE LANGUAGE

The purpose of this section is to explain the character sets for the Japanese language.

H.1.1 JIS X 0201

......

Escape Sequence for ISO/IEC 2022 (for reference) (For the Defined Terms, see PS 3.3)

| |ISO-IR 14 |ISO-IR 13 |

|G0 set |ESC 02/08 04/10 |ESC 02/08 04/09 |

|G1 set |ESC 02/09 04/10 |ESC 02/09 04/09 |

NOTES: 1. The table does not include the G2 and G3 sets that are not used in DICOM. See Section 6.1.2.5.1.

2. Defined Terms ISO_IR 13 and ISO 2022 IR 13 for the value of the Specific Character Set (0008,0005) support the G0 set for ISO-IR 14 and G1 set for ISO-IR 13. See PS 3.3.

(Note to the Editor: Please use bold-face type for the Escape Sequences of G0 set for ISO-IR 14 and G1 set for ISO-IR 13 like Supplement 9, if possible.)

H.1.2 JIS X 0208

......

Escape Sequence for ISO/IEC 2022 (for reference) (For the Defined Terms, see PS 3.3)

| |ISO-IR 87 |ISO-IR 159 |

|G0 set |ESC 02/04 04/02 |ESC 02/04 02/08 04/04 |

|G1 set |ESC 02/04 02/09 04/02 |ESC 02/04 02/09 04/04 |

NOTES: 1. The Escape Sequence for the designation function G0-DESIGNATE 94-SET, has first I byte 02/04 and second I byte 02/08. There is an exception to this: The second I byte 02/08 is omitted if the Final Byte is 04/00, 04/01 or 04/02. See ISO/IEC 2022.

2. The table does not include the G2 and G3 sets that are not used in DICOM. See Section 6.1.2.5.1.

3. Defined Term ISO 2022 IR 87 for the value of the Specific Character Set (0008,0005) supports the G0 set for ISO-IR 87, and Defined Term ISO 2022 IR 159 supports the G0 set for ISO-IR 159. See PS 3.3.

(Note to the Editor: Please use bold-face type for the Escape Sequences of G0 set for ISO-IR 87 and G0 set for ISO-IR 159 like Supplement 9, if possible.)

Item: Amend PS 3.5 Section H.2:

H.2 INTERNET PRACTICE

DICOM adopts the encoding method for Japanese character sets almost the same as the method for the Internet practice.

The major protocols for the Internet such as SMTP, NNTP and WWW HTTP adopt the encoding method for Japanese characters called “ISO-2022-JP” as described in RFC 1468, Japanese Character Encoding for Internet Messages. The method of encoding Japanese characters sets in the DICOM standard is almost the same as ISO-2022-JP, except for the following.

.....

Item: Amend PS 3.5 Section H.3.1:

H.3.1 Example 1: Value 1 of Attribute Specific Character Set (0008,0005) is not present.

Result of representation by an ASCII-based machine: An example of the display or print for the ASCII based machine that displays or prints the Control Character ESC (01/11) using \033:

Yamada^Tarou=\033$B;3ED\033(B^\033$BB@O:\033(B=\033$B$d$^$@\033(B^\033$B$?$m$&\033(B

Item: Amend PS 3.5 Section H.3.2:

H.3.2 Example 2: Value 1 of Attribute Specific Character Set (0008,0005) is ISO 2022 IR 13.

Result of representation by an ASCII-based machine: An example of the display or print for the ASCII based machine that displays or prints the Control Character ESC (01/11) using \033:

\324\3l7\300\336^\300\333\263=\033$B;3ED\033(J^\033$BB@O:\033(J=\033$B$d$^$@\033(J^\033$B$?$m$&\033(J

DICOM Correction Item

|Correction Number: CP-155 |

|Submission Abstract: Add support for ISO-IR 149 Korean character sets |

|Type of Change Proposal: |Name of Document: |

|Addition |PS 3.3-1999: Information Object Definitions, |

| |PS 3.5-1999: Data Structures and Encoding |

|Rationale for change: |

|Korea uses its own characters, Hangul, and Hangul needs to be used in DICOM. Hangul can be implemented easily in DICOM by |

|character encoding methods that PS 3.5 has defined. A Defined Term for Character set for Hangul needs to be added in Table |

|C.12-4 of PS 3.3 |

Sections of document affected/ Suggest Wording of Change:

Part 3

1. C.12.1.1.2 Specific Character Set

Add the following entry to Table C.12-4.

Table C.12-4

DEFINED TERMS FOR MULTIPLE-BYTE CHARACTER SETS WITH CODE EXTENSIONS

|Character Set |Defined Term |Standard for Code|ESC Sequence |ISO registration |Number of |Code element |Character Set |

|Description | |Extension | |number |characters | | |

|Korean |ISO 2022 IR 149|ISO 2022 |ESC 02/04 02/09 |ISO-IR 149 |942 | G1 |KS X 1001: |

| | | |04/03 | | | |Hangul and Hanja|

Part 5

1. Section 2

Add the following Hangul multi-byte character set to the end of section 2 “Normative references”:

KS X 1001-1997 Code for Information Interchange (Hangul and Hanja)

2. Section 6.1.2.4 Code Extension Techniques

Modify the Note to read:

2. Support for Japanese kanji (ideographic), hiragana (phonetic), and katakana(phonetic) characters, and Korean characters (Hangul) is defined in PS3.3. Definition of Chinese Korean, and other multi-byte character sets awaits consideration by the appropriate standards organizations.

3. Change the current Annex I to Annex J and add the followings as Annex I, “Character sets and person name value representation in the Korean language”.

Annex I

(Informative)

Character sets and person name value representation In the Korean Language

I.1 CHARACTER SETS FOR THE KOREAN LANGUAGE IN DICOM

KS X 1001 (registered as ISO-IR 149) is used as a Korean character set in DICOM. This character set is the one most broadly used for the representation of Korean characters. It can be encoded by ISO 2022 code extension techniques, and is registered in ISO 2375.

Escape Sequence (for reference) (see PS 3.3)

| |ISO-IR 149 |

|G0 set |ESC 02/04 02/08 04/03 |

|G1 set |ESC 02/04 02/09 04/03 |

Notes: 1. ISO-IR 149 is only used as a G1 set in DICOM.

2. The Korean character set (ISO IR 149) is invoked to the G1 area. This is different from the Japanese multi-byte character sets (ISO 2022 IR 87 and ISO 2022 IR 159) which use the G0 code area. Japan's choice of G0 is due to the adoption of an encoding method based on "ISO-2022-JP". ISO-2022-JP, the most familiar encoding method in Japan, and uses only the G0 code area. In Korea, most operating systems adopt an encoding method that invokes the Hangul character set (KS X 1001) in the G1 code area. So, the difference between code areas of Korean and Japanese character originates in convention, not a technical problem. Invocation of multi-byte character sets to the G1 area does not change the current DICOM normative requirements.

I.2 EXAMPLE OF PERSON NAME VALUE REPRESENTATION IN THE KOREAN LANGUAGE

Person names in the Korean language may be written in Hangul (phonetic characters), Hanja (ideographic characters), or English (single-byte characters). The three component groups should be written in the order of single-byte, ideographic, and phonetic (see Table 6.2-1).

(0008,0005) \ISO 2022 IR 149

[pic]

Character String:

Encoded representation:

04/08 06/15 06/14 06/07 05/14 04/07 06/09 06/12 06/04 06/15 06/14 06/07 03/13

01/11 02/04 02/09 04/03 15/11 15/03 05/14 01/11 02/04 02/09 04/03 13/01 12/14

13/04 13/07 03/13 01/11 02/04 02/09 04/03 12/08 10/11 05/14 01/11 02/04 02/09

04/03 11/01 14/06 11/05 11/15

Result of representation by an ASCII-based machine which displays 01/11 as \033:

Hong^Gildong=\033$)C\373\363^\033$)C\321\316\324\327=\033$)C\310\253^\033$)C\261\346\265\277

Notes: 1. The multi-byte character set (ISO-IR 149) and single-byte character set (ISO 646) can be used intermixed without any explicit escape sequence after the initial escape sequence. Once ISO 646 has been designated to the GL area and ISO-IR 149 to the GR area, each character set has different code area, thus can be used intermixed. The decoder will check the most significant bit of a character to know whether it is a two byte character in the GR area (high bit one) or a one byte character in the GL area (high bit zero).

2. In the above example of person name representation, explicit escape sequences precede each Hangul and Hanja string. These escape sequences are to meet the requirements of the code extension technique that specifies a switch to the default character repertoire before delimiters. In the previous example, it is assumed that the default character repertoire (ISO-646) is invoked to G0 code area and no character set to G1 area after delimiters (“^” and “=” signs). See 6.1.2.5.3 of PS 3.5.

I.3 EXAMPLE OF LONG TEXT VALUE REPRESENTATION IN THE KOREAN LANGUAGE WITHOUT EXPLICIT ESCAPE SEQUENCES BETWEEN CHARACTER SETS

Hangul (ISO IR 149) and ASCII (ISO 646) character sets can be used intermingled without explicit escape sequences between them. The Hangul character set ISO IR 149 is invoked to the G1 area, so this invocation doesn't affect the G0 area to which the ASCII character set has been invoked. The following is an example of a Long Text value representation which includes ASCII and Hangul character set.

(0008,0005) \ISO 2022 IR 149

[pic]

Once having invoked the ISO IR 149 character set to G1 area by the escape sequence in the head of line, one can use Hangul and ASCII intermixed in that line.

Table I-1.

CHARACTER SETS AND ESCAPE SEQUENCES USED IN THE EXAMPLES

|Character Set |Component Group |Value of |ISO |Standard for |ESC Sequence | |Character Set: |

|Descript-ion | |(0008,0005) |Registrat-ion |Code Extension | | |Purpose of Use |

| | |Defined Term |Number | | | | |

|Korean |First: |Value 1: |ISO-IR 6 | | |GL |ISO 646: |

| |Single-byte |none | | | | | |

| |Second: |Value 1: |ISO-IR 6 | | |GL |ISO 646: |

| |Ideographic |none | | | | |For delimiters |

| | |Value 2: |ISO-IR 149 |ISO 2022 |ESC 02/04 02/09|GR |KS X 1001: Hangul|

| | |ISO 2022 IR 149 | | |04/03 | |and Hanja |

| | | | | | | | |

| |Third: |Value 1: |ISO-IR 6 | | |GL |ISO 646: |

| |Phonetic |none | | | | |For delimiters |

| | |Value 2: |ISO-IR 149 |ISO 2022 |ESC 02/04 02/09|GR |KS X 1001: Hangul|

| | |ISO 2022 IR 149 | | |04/03 | |and Hanja |

| | | | | | | | |

DICOM Correction Item

|Correction Number: CP 156 |

|Log Summary: Clarify Image Pixel Attributes for Compressed Transfer Syntaxes |

|Type of Modification |Name of Standard |

|Clarification |DICOM Standard - 1999 |

|Rationale for Correction: |

| |

|The existing DICOM Standard states that for compressed image data the image object’s “Data Elements … shall contain values which|

|are consistent with the characteristics of the uncompressed pixel data …” (PS3.5 8.2.1 and 8.2.2 – 1999). This makes it vague |

|for cases where image data are converted from one photometric interpretation to another prior to the compression step in order |

|to enhance the compression ratio. For example, in the case where RGB data is converted to YBR FULL 422 data prior to JPEG |

|compression should the Data Elements indicate the state of the RGB data or of the YBR FULL 422 data? |

| |

|The correct approach should be that the Data Elements indicate the actual state of the compressed data stream. This will allow |

|proper decompression and interpretation of the decompressed output in cases where only the DICOM Data Elements indicate the |

|state of the compressed image data. |

|Sections of document affected: |

| |

|PS3.3 - 1999 |

|PS3.5 - 1999 |

|Correction Wording: |

| |

|Amend the last paragraph of PS3.5 Section 8.2.1 JPEG IMAGE COMPRESSION as follows: |

| |

|The use of the DICOM Encapsulated Format to support JPEG Compressed Pixel Data implies requires that the Data Elements which are|

|related to the Native Format Pixel Data encoding (e.g. Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits|

|Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the |

|characteristics of the uncompressed pixel data from which the compressed Data Stream was derived. The Pixel Data characteristics|

|included in the JPEG Interchange Format shall be used to decode the compressed data stream. |

|Notes: 1. These requirements were formerly specified in terms of the "uncompressed pixel data from which the compressed Data |

|Stream was derived". However, since the form of the "original" uncompressed data stream could vary between different |

|implementations, this requirement is now specified in terms of consistency with what is encapsulated. |

|When decompressing, should the characteristics explicitly specified in the compressed data stream (e.g. spatial subsampling or |

|number of components or planar configuration) be inconsistent with those specified in the DICOM Data Elements, those explicitly |

|specified in the compressed data stream should be used to control the decompression. The DICOM data elements, if inconsistent, |

|can be regarded as suggestions as to the form in which an uncompressed data set might be encoded. |

|2. Those characteristics not explicitly specified in the compressed data stream (e.g. color space which is not specified in the |

|JPEG Interchange Format), or implied by the definition of the compression scheme (e.g. always unsigned in JPEG), can therefore |

|be determined from the DICOM Data Element in the enclosing data set. For example a Photometric Intepretation of "YBR FULL 422" |

|would describe the color space that is commonly used to lossy compress images using JPEG. It is unusual to use an RGB color |

|space for lossy compression, since no advantage is taken of correlation between the red, green and blue components (e.g. of |

|luminance), and poor compression is achieved. |

|3. Should the compression process be incapable of encoding a particular form of pixel data representation (e.g. JPEG cannot |

|encode signed integers, only unsigned integers), then ideally only the appropriate form should be "fed" into the compression |

|process. However, for certain characteristics described in DICOM Data Elements but not explicitly described in the compressed |

|Data Stream (such as Pixel Representation), then the DICOM Data Element should be considered to describe what has been |

|compressed (e.g. the pixel data really is to be interpreted as signed if Pixel Representation so specifies). |

|4. DICOM Data Elements should not describe characteristics that are beyond the capability of the compression scheme used. For |

|example, JPEG lossy processes are limited to 12 bits, hence the value of Bits Stored should be 12 or less. Bits Allocated is |

|irrelevant, and is likely to be constrained by the Information Object Definition in PS 3.3 to values of 8 or 16. Also, JPEG |

|compressed data streams are always color-by-pixel and should be specified as such (a decoder can essentially ignore this element|

|however as the value for JPEG compressed data is already known). |

| |

|Amend the last paragraph of PS3.5 Section 8.2.2 RUN LENGTH ENCODING COMPRESSION as follows: |

| |

|The use of the DICOM Encapsulated Format to support RLE Compressed Pixel Data implies requires that the Data Elements which are |

|related to the Native Format Pixel Data encoding (e.g. Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits|

|Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the |

|characteristics of the uncompressed pixel data from which the compressed Data Stream was derived. |

|Notes: 1. These requirements were formerly specified in terms of the "uncompressed pixel data from which the compressed Data |

|Stream was derived". However, since the form of the "original" uncompressed data stream could vary between different |

|implementations, this requirement is now specified in terms of consistency with what is encapsulated. |

|2. Those characteristics not implied by the definition of the compression scheme (e.g. always color-by-plane in RLE), can |

|therefore be determined from the DICOM Data Element in the enclosing data set. For example a Photometric Intepretation of "YBR |

|FULL" would describe the color space that is commonly used to losslessly compress images using RLE. It is unusual to use an RGB |

|color space for RLE compression, since no advantage is taken of correlation between the red, green and blue components (e.g. of |

|luminance), and poor compression is achieved (note however that the conversion from RGB to YBR FULL is itself lossy. A new |

|photometric interpretation may be proposed in the future which allows lossless conversion from RGB and also results in better |

|RLE compression ratios). |

|3. DICOM Data Elements should not describe characteristics that are beyond the capability of the compression scheme used. For |

|example, RLE compressed data streams (using the algorithm mandated in the DICOM Standard) are always color-by-plane. |

| |

|Add this to PS3.3 Sections C.7.6.3.1.2 and C.8.5.6.1.2 Photometric Interpretation: |

| |

|See PS3.5 section 8.2 for restrictions imposed by the Transfer Syntax. |

DICOM Correction Item

|Correction Number CP- 168 |

|Log Summary: Non-Encoded Failure Status Code- Add No such Action Code |

|Type of Modification |Name of Standard |

|Clarification |PS 3.7 |

|Rationale for Correction |

|Section C.10.1.4.1.10 list the status: |

|" ⎯ no such action: the action type specified was not supported.” |

| |

|But section C.5 Failure Status Classes does not define an encoding for this status. |

|It is proposed to add this status to the list in Annex C. |

|Sections of documents affected |

|In PS 3.7, Section C.10.1.4.1.10 |

|Correction Wording: |

|In Section C, Status Type Encoding, add to the list of status: |

|Section 5.24 No such action type |

C.5.24 No such action type

|Status Field |Tag |VR |VM |Description of Field |

|Affected SOP Class UID |(0000,0002) |UI |1 |This optional field contains the SOP Class UID for which the |

| | | | |event type does not exist. |

|Status |(0000,0900) |US |1 |Confirmation status of the operation. The value of this |

| | | | |required field shall be set to 0123H. |

|Action Type ID |(0000,1008) |US |1 |This optional field contains the ID of the Action Type which |

| | | | |does not exist. |

DICOM Correction Item

|Correction Number CP-169 |

|Log Summary: Clarify viewing point for compensator data |

|Type of Modification: |Name of Standard |

|Clarification |PS 3.3-1998 |

|Rationale for Correction: |

| |

|The RT Plan object provides a mechanism for sending treatment compensator thickness or transmission data, using a |

|two-dimensional pixel grid in the IEC BEAM LIMITING DEVICE coordinate system. |

| |

|The Compensator Position (300A,00EA) specifies the corner of the grid, and the data is sent in row order. However, the viewing |

|direction when sending the data is not explicitly specified. |

|Sections of document affected: |

| |

|PS 3.3-1998 (Information Object Definitions), Section C.8.8.14 (RT Beams Module) |

|Correction Wording: |

| |

|In DICOM PS 3.3-1998, Section C.8.8.14 (RT Beams Module), Table C.8-46 (RT Beams Module Attributes), the phrase in bold should |

|be added in the following attributes: |

| |

|>>Compensator Transmission Data (300A,00EB) 1C A data stream of the pixel samples which comprise the compensator, expressed as |

|broad-beam transmission values (between 0 and 1) along a ray line passing through the pixel, at the beam energy specified by the|

|Nominal Beam Energy (300A,0114) of the first Control Point of the Control Point Sequence (300A,0111). The order of pixels sent |

|is left to right, top to bottom (upper left pixel, followed by the remainder of row 1, followed by the remainder of the columns)|

|when viewed from the radiation source. Required if Compensator Sequence (300A,00E3) is sent and Material ID (300A,00E1) is |

|zero-length. |

| |

|>>Compensator Thickness Data (300A,00EC) 1C A data stream of the pixel samples which comprise the compensator, expressed as |

|thicknesses (in mm) parallel to radiation beam axis. The order of pixels sent is left to right, top to bottom (upper left pixel,|

|followed by the remainder of row 1, followed by the remainder of the columns) when viewed from the radiation source. Required if|

|Compensator Sequence (300A,00E3) is sent and Material ID (300A,00E1) is non-zero length. |

DICOM Correction Item

|Correction Number CP-170 |

|Log Summary: Clarify use of Beam Number, Beam Label, and Beam Name attributes. |

|Type of Modification: |Name of Standard |

|Clarification |PS 3.3-1999 |

|Rationale for Correction: |

| |

|The RT Plan object provides the attribute Beam Number (300A,00C0) to associate attributes for the same beam that are found in |

|different modules. The attributes Beam Name (300A,00C2) and Beam Description (300A,00C3) are intended to be used by applications|

|to identify the beam using real-world names and descriptions. |

| |

|Radiotherapy equipment typically manages two real-world identifiers, a beam identifier (also known as a “Field ID”) and a text |

|beam name or description (also known as a “Field Name”). The intended mapping of these identifiers to the DICOM attributes |

|should be stated explicitly in the standard. |

|Sections of document affected: |

| |

|PS 3.3-1998 (Information Object Definitions), Section C.8.8.14 (RT Beams Module) |

|Correction Wording: |

| |

|In DICOM PS 3.3-1998, Section C.8.8.14 (RT Beams Module), add the following note as Note 1 immediately following the Table |

|C.8-46. Renumber the existing notes and update the references in the Table C.8-46. |

| |

|Notes: 1. Beam Number (300A,00C0) is provided to link related information across modules, and its value should not be required |

|to have any real-world interpretation. Beam Name (300A, 00C2), a Type 3 attribute, is intended to store the primary beam |

|identifier (often referred to as “field identifier”). Beam Description (300A,00C3), a Type 3 attribute, is intended to store |

|additional beam identifying information (often referred to as “field name”). Equipment requiring that both these attributes be |

|present should state this clearly in the Conformance Statement. |

DICOM Correction Item

|Correction Number CP-171 |

|Log Summary: Add support for translation of RT Imaging Devices |

|Type of Modification: |Name of Standard |

|Extension |PS 3.3-1999 |

|Rationale for Correction: |

| |

|The RT Image object provides a mechanism for specifying the coordinate system of the image acquired by an imaging device, by |

|specifying X-ray Image Receptor Angle (3002,000E), RT Image Orientation (3002,0010), and RT Image Position (3002,0012). |

| |

|However, some imaging devices appear to allow a translation of the IEC X-RAY IMAGE RECEPTOR coordinate system, as described by |

|IEC-1217. This needs to be modeled within DICOM. |

|Sections of document affected: |

| |

|PS 3.3-1999 (Information Object Definitions), Section C.8.8.2 (RT Image Module) |

|PS 3.6-1999 (Data Dictionary) Section 6 (Registry of DICOM data elements) |

|Correction Wording: |

| |

|In DICOM PS 3.3-1999, Section C.8.8.2 (RT Image Module), Table C.8-34 (RT Image Module Attributes) add the following attribute |

|immediately following RT Image Plane (3002,000C): |

| |

|X-Ray Image Receptor Translation (3002,000D) 3 Position in (x,y,z) coordinates of origin of IEC X-RAY IMAGE RECEPTOR System in |

|the IEC GANTRY coordinate system (mm). See Note 2. |

| |

|In DICOM PS 3.3-1999, Section C.8.8.2 (RT Image Module), add the following note (as Note 2) after the existing note at the end |

|of Table C.8-34 (RT Image Module Attributes): |

| |

|Notes: 2. The Z coordinate of the X-Ray Image Receptor Translation (3002,000D) will be equal to the Radiation Machine SAD |

|(3002,0022) minus the RT Image SID (3002,0026). If the image receptor is further from the beam source than the machine |

|isocenter, the Z coordinate will be negative (see IEC 1217). |

| |

|In DICOM PS 3.6-1999, Section 6 (Registry of DICOM data elements), add the following attribute: |

| |

|(3002,000D) X-Ray Image Receptor Translation DS 3 |

DICOM Change Item

|Log Summary: Change VRs to be consistent and remove group lengths from Part 6 |

|Type of Modification: |

|Clarification |

|Name of Document |Version Number |

|PS 3.5, 3.6 |1999 |

|Rationale for change |

|Part 6 defines several data elements with multiple Value Representations. The format of several items should be changed to |

|improve the readability. To avoid maintaining Part 6 with the Group Length attributes for every new group, remove all current |

|group lengths. Part 5 already specifies that the 0000 element is reserved for group length. |

|Modify Part 5: |

|7.2 Group length |

|The Group Length (gggg,0000) Standard Data Element shall be implicitly defined for all Data Element groups. It shall be an |

|optional (Type 3 Data Element Type) Data Element in DICOM V3.0 (see Section 7.4 for a description of Data Element Types). It |

|provides an optional optimization scheme in partial parsing of Data Sets by allowing the skipping of entire groups of Data |

|Elements. Implementations may or may not choose to encode explicit Group Length in a Data Set. All implementations shall be able|

|to accept or ignore such elements. |

| |

|Modify Part 6: |

| |

|Change Tag (50xx,200C), VR from “OW/OB” to “OW or OB” |

|Change Tag (50xx,3000), VR from “OW/OB” to “OW or OB” |

|Change Tag (7FE0,0010), VR from “OW/OB” to “OW or OB” |

| |

| |

| |

|Remove Elements: |

|0008,0000 Group Length VR=UL VM=1 |

|0010,0000 Group Length VR=UL VM=1 |

|0018,0000 Group Length VR=UL VM=1 |

|0020,0000 Group Length VR=UL VM=1 |

|0028,0000 Group Length VR=UL VM=1 |

|0032,0000 Group Length VR=UL VM=1 |

|0038,0000 Group Length VR=UL VM=1 |

|0040,0000 Group Length VR=UL VM=1 |

|0050,0000 Group Length VR=UL VM=1 |

|0054,0000 Group Length VR=UL VM=1 |

|0088,0000 Group Length VR=UL VM=1 |

|2000,0000 Group Length VR=UL VM=1 |

|2010,0000 Group Length VR=UL VM=1 |

|2020,0000 Group Length VR=UL VM=1 |

|2030,0000 Group Length VR=UL VM=1 |

|2040,0000 Group Length VR=UL VM=1 |

|2100,0000 Group Length VR=UL VM=1 |

|2110,0000 Group Length VR=UL VM=1 |

|4000,0000 Group Length VR=UL VM=1 |

|4008,0000 Group Length VR=UL VM=1 |

|50xx,0000 Group Length VR=UL VM=1 |

|60xx,0000 Group Length VR=UL VM=1 |

|7FE0,0000 Group Length VR=UL VM=1 |

|0002,0000 Group Length VR=UL VM=1 |

|0004,0000 Group Length VR=UL VM=1 |

DICOM Correction Item

|Correction Number CP- 173 |

|Log Summary: Presentation LUT Parameters: Basic Film Box versus Basic Film Session |

|Type of Modification |Name of Standard |

|Clarification |PS 3,3, 3.4 - 1999 |

|Rationale for Correction |

|1. - major - Supplement 22 Final Text states that Illumination and Reflected Ambient Light are attributes of Basic Film Box, |

|which was incorporated correctly into Part 3, but in Part 4 they are stated as attributes of Basic Film Session. See Table |

|H.4-2 and Section H.4.1.2.1.1. According to Supplement 22, they should be in Tables H.4-6, H.4-7, and Section H.4.2.2.1.1. |

|These two attributes make more sense to belong in Basic Film Box, where all the other attributes related to image |

|quality/consistency/appearance are, so Part 4 should be updated: see Table H.4-6. |

|2. - major – to be consistent with item 1, the reference to the Presentation LUT should be removed from the Film Session level |

|also, and remain at the Film Box and Image Box level. |

|3. - minor - In the 1999 Standard and Supplement 22 Final Text, the name of attribute (2010,0160) is Reflected Ambient Light in |

|most places, but Reflective Ambient Light in one: Part 4, Table H.4-2. This is a typographic error. |

|4. - minor - In the 1999 Standard and Supplement 22 Final Text, the names of attributes (0008,1150) and (0008,1155) under |

|Referenced Presentation LUT Sequence (2050,0500) are SOP Class UID and SOP Instance UID, respectively. This occurs in Part 4, |

|Tables H.4-2, H.4-6, H.4-7, H.4-10, H.4-12. According to Part 6, the attribute names are Referenced SOP Class UID and |

|Referenced SOP Instance UID, respectively. The same applies to Referenced Overlay Sequence (0008,1130) in Tables H.4-10 and |

|H.4-11. This is a typographic error. |

|Sections of documents affected |

|In PS 3.4, Section H.4.1.2.1.1, H.4.2.2.1.1, H.4.2.2.2.1, H.4.3.1.2.1.1, H.4.3.2.2.1.1, H.4.3.3.2.1.1 |

|In PS 3.3, Section C.13.2 |

|Correction Wording: |

Amend PS 3.4 Annex H as follows:

H.4.1.2.1 N-CREATE

The N-CREATE is used to create an instance of the Basic Film Session SOP Class.

H.4.1.2.1.1 Attributes

The Attribute list of the N-CREATE is defined as shown in Table H.4-2.

Table H.4-2

N-CREATE ATTRIBUTE LIST

|Attribute Name |Tag |Usage SCU/SCP |

|Number of Copies |(2000,0010) |U/M |

|Print Priority |(2000,0020) |U/M |

|Medium Type |(2000,0030) |U/M |

|Film Destination |(2000,0040) |U/M |

| | | |

|Referenced Presentation LUT Sequence |(2050,0500) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|>SOP Class UID |(0008,1150) |U/MC |

| | |(Required if sequence is present) |

|>SOP Instance UID |(0008,1155) |U/MC |

| | |(Required if sequence is present) |

|Film Session Label |(2000,0050) |U/U |

|… |… |… |

Notes: 1. The memory allocation Attribute allows the SCU to reserve sufficient memory to store the "working" film session hierarchy as well the "copied" film session hierarchy in the Print Job in order to prevent deadlock situations.

2. Owner ID (2100,0160) is a user option for the Basic Film Session. However, SCUs that also implement the Print Queue Management Service Class are required to supply Owner ID to successfully delete or re-prioritize Print Jobs in the printer queue (see section L.4.2.3.1).

3. Proposed Study Sequence (2130,0040) may be used to identify Stored Print Storage and Hardcopy Image SOP Instances created to store this Film Session

4. To meet requirements specified in PS 3.3, the Study Instance UID of the Stored Print Storage SOP Instance should be the same as the Study Instance UID in Proposed Study Sequence (2130,0040). New Series Instance and Image Instance UIDs will be supplied by the device that creates the Stored Print Storage SOP Instance.

The meaning of the Usage SCU/SCP is described in Section H.2.4.

Within the film session, the allocated memory is consumed as SOP Instances are created and is freed for reuse as SOP Instances are deleted. All the allocated memory shall be released following termination of the Association or deletion of the Film Session SOP Instance.

If the Illumination (2010,015E) and Reflected Ambient Light (2010,0160) values, respectively termed L0 and La, are not created, the following default values are recommended:

For transmissive film: L0 = 2000 cd/m2.

La = 10 cd/m2.

For reflective media: L0 = 150 cd/m2.



H.4.1.2.2 N-SET

The N-SET may be used to update an instance of the Basic Film Session SOP Class.

H.4.1.2.2.1 Attributes

All Attributes and usage in Table H.4-2 apply to N-SET.



H.4.2 Basic Film Box SOP Class



H.4.2.2.1 N-CREATE

The N-CREATE is used to create an instance of the Basic Film Box SOP Class.

H.4.2.2.1.1 Attributes

The Attribute list of the N-CREATE is shown in Table H.4-6.

Table H.4-6

N-CREATE ATTRIBUTE LIST

|Attribute Name |Tag |Usage SCU/SCP |

|Image Display Format |(2010,0010) |M/M |

|… |… |… |

|Configuration Information |(2010,0150) |U/M |

|Referenced Presentation LUT Sequence |(2050,0500) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|>Referenced SOP Class UID |(0008,1150) |U/MC |

| | |(Required if sequence is present) |

|>Referenced SOP Instance UID |(0008,1155) |U/MC) |

| | |(Required if sequence is present |

|Annotation Display Format ID |(2010,0030) |U/U |

|Smoothing Type |(2010,0080) |U/U |

|Border Density |(2010,0100) |U/U |

|Empty Image Density |(2010,0110) |U/U |

|Min Density |(2010,0120) |U/U |

|Trim |(2010,0140) |U/U |

|Illumination |(2010,015E) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|Reflective Ambient Light |(2010,0160) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|Requested Resolution ID |(2020,0050) |U/U |

The meaning of the Usage SCU/SCP is described in Section H.2.4.

Values for Referenced Presentation LUT Sequence override any Presentation LUT that may have been set at the Basic Film Session.

H.4.2.2.1.2 Status

The status values which are specific for this SOP Class are defined as follows:

|Status |Meaning |Code |

|Success |Film Box successfully created |0000 |

|Warning |Requested Min Density or Max Density outside of printer’s |B605 |

| |operating range. The printer will use its respective minimum | |

| |or maximum density value instead. | |

|Failure |There is an existing Film Box that has not been printed and |C616 |

| |N-ACTION at the Film Session level is not supported. A new | |

| |Film Box will not be created when a previous Film Box has not | |

| |been printed. | |



H.4.2.2.2 N-SET

The N-SET may be used to update the last created instance of the Basic Film Box SOP Class.

H.4.2.2.2.1 Attributes

The Attributes which may be updated are shown in Table H.4-7.

Table H.4-7

N-SET ATTRIBUTES

|Attribute Name |Tag |Usage SCU/SCP |

|Magnification Type |(2010,0060) |U/M |

|Max Density |(2010,0130) |U/M |

|Configuration Information |(2010,0150) |U/M |

|Referenced Presentation LUT Sequence |(2050,0500) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|>Referenced SOP Class UID |(0008,1150) |U/MC |

| | |(Required if sequence is present) |

|> Referenced SOP Instance UID |(0008,1155) |U/MC) |

| | |(Required if sequence is present |

|Smoothing Type |(2010,0080) |U/U |

|Border Density |(2010,0100) |U/U |

|Empty Image Density |(2010,0110) |U/U |

|Min Density |(2010,0120) |U/U |

|Illumination |(2010,015E) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|Reflective Ambient Light |(2010,0160) |U/MC |

| | |(Required if Presentation LUT is |

| | |supported) |

|Trim |(2010,0140) |U/U |

The meaning of the Usage SCU/SCP is described in Section H.2.4.

Values for Referenced Presentation LUT Sequence override any Presentation LUT that may have been set at the Basic Film Session.

Amend PS 3.3-1998 Annex C as follows:

C.13.2 Basic Film Session Relationship Module

Table C.13-2

BASIC FILM SESSION RELATIONSHIP MODULE ATTRIBUTES

|Attribute Name |Tag |Attribute Description |

|Referenced Film Box Sequence |(2000,0500) |A Sequence which provides references to a set of Film Box SOP |

| | |Class/Instance pairs. Zero or more Items may be included in this |

| | |Sequence. |

|>Referenced SOP Class UID |(0008,1150) |Uniquely identifies the referenced SOP Class. |

|>Referenced SOP Instance UID |(0008,1155) |Uniquely identifies the referenced SOP Instance. |

|Referenced Presentation LUT Sequence |(2050,0500) |A sequence that provides references to a Presentation LUT related SOP |

| | |Class/Instance pairs. Only a single Item shall be included in this |

| | |sequence. |

|>Referenced SOP Class UID |(0008,1150) |Uniquely identifies the referenced SOP Class. |

|>Referenced SOP Instance UID |(0008,1155) |Uniquely identifies the referenced SOP Instance. |

|Proposed Study Sequence |(2130,00A0) |Attributes that may be used to identify Stored Print Storage and |

| | |Hardcopy Image SOP Instances created to store this Film Session. |

DICOM Correction Item

|Log Summary: NM changing focal distance Collimator to Detector |

|Type of Modification |

|Clarification |

|Name of Document |Version Number |

|PS3.3 |1999 |

|Rationale for change |

|In section C.8.4.11.1.1, the Focal Distance (0018,1182) is defined with respect to the front face of the collimator. This should|

|have been referenced with respect to the front face of the detector, as was done with Radial Position (0018,1142). |

| |

|Note that with the current definition it is not possible to calculate the true focal distance because the thickness of the |

|collimator is not known. |

| |

|The Nuclear Medicine joint committee, WG3, approved this request at the last meeting (at RSNA ’98). |

|Sections of document affected |

|C.8.4.11.1.1 |

Suggested change:

The first sentence in section C.8.4.11.1.1 should read:

Focal Distance (0018,1182) for NM images is the focal distance, in mm for converging or diverging collimators, measured from the front face of the detector to the focus.

DICOM Correction Item

|Log Summary: Correct Results Interpretation Relationship Module |

|Type of Modification |

|Correction |

|Name of Document |Version Number |

|PS 3.3 |1999 |

|Rationale for change |

| |

|In the 1996 version of the standard, the relationship in the DICOM Information Model between Results IOD and Interpretation IOD |

|is 0-1 (see PS3.3 Figure 7-2). |

|In the Results Relationship Module (PS3.3 Table C.5-1), the Referenced Interpretation Sequence seems to imply multiple items are|

|allowed, but this conflicts Figure 7-2. |

| |

|In the 1998 version of the standard, the Referenced Interpretation Sequence is clarified to specify zero of more items are |

|allowed. The figure, now 7-2a, is not changed. |

| |

|Figure 7-2a should be changed to specify the relationship between Results IOD and Interpretation IOD to 0-n |

|Sections of document affected |

| |

|PS3.3 Figure 7-2a |

-----------------------

“¥”

匍畴祤䤠䑏഍敓⁥潎整഍敒畳瑬⁳佉ൄ爍晥牥湥散൳䤍瑮牥牰瑥瑡潩佉ൄㄍ渭഍ⴰ൮ㄍ഍ⴰ൮഍

Study IOD

See Note

Results IOD

references

Interpretation IOD

1-n

0-n

1

0-n

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download