A Data Set represents an instance of a real world Information Object. A Data Set is constructed of Data Elements. Data Elements contain the encoded Values of Attributes of that object. The specific content and semantics of these Attributes are specified in Information Object Definitions (see PS 3.3).
The construction, characteristics, and encoding of a Data Set and its Data Elements are discussed in this section. Pixel Data, Overlays, and Curves are Data Elements whose interpretation depends on other related elements.
A Data Element is uniquely identified by a Data Element Tag. The Data Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at most once in a Data Set.
Note: A Data Element Tag may occur again within Nested Data Sets (see Section 7.5).
Two types of Data Elements are defined:
⎯ Standard Data Elements have an even Group Number that is not (0000,eeee), (0002,eeee), (0004,eeee), or (0006,eeee).
Note: Usage of these groups is reserved for DIMSE Commands (see PS 3.7) and DICOM File Formats.
⎯ Private Data Elements have an odd Group Number that is not (0001,eeee), (0003,eeee), (0005,eeee), (0007,eeee), or (FFFF,eeee). Private Data Elements are discussed further in Section 7.8.
Note: Although similar or related Data Elements often have the same Group Number; a Data Group does not convey any semantic meaning beginning with DICOM Version 3.0.
A Data Element shall have one of three structures. Two of these structures contain the VR of the Data Element (Explicit VR) but differ in the way their lengths are expressed, while the other structure does not contain the VR (Implicit VR). All three structures contain the Data Element Tag, Value Length and Value for the Data Element. See Figure 7.1-1.
Implicit and Explicit VR Data Elements shall not coexist in a Data Set and Data Sets nested within it (see Section 7.5). Whether a Data Set uses Explicit or Implicit VR, among other characteristics, is determined by the negotiated Transfer Syntax (see Section 10 and Annex A).
Note: VRs are not contained in Data Elements when using DICOM Default Transfer Syntax (DICOM Implicit VR Little Endian Transfer Syntax).
[pic]Figure 7.1-1 DICOM DATA SET AND DATA ELEMENT STRUCTURES
A Data Element is made up of fields. Three fields are common to all three Data Element structures; these are the Data Element Tag, Value Length, and Value Field. A fourth field, Value Representation, is only present in the two Explicit VR Data Element structures. The Data Element structures are defined in Sections 7.1.2. and 7.1.3. The definitions of the fields are:
Data Element Tag: An ordered pair of 16-bit unsigned integers representing the Group Number followed by Element Number.
Value Representation: A two-byte character string containing the VR of the Data Element. The VR for a given Data Element Tag shall be as defined by the Data Dictionary as specified in PS 3.6. The two character VR shall be encoded using characters from the DICOM default character set.
Value Length: Either:
⎯ a 16 or 32-bit (dependent on VR and whether VR is explicit or implicit) unsigned integer containing the Explicit Length of the Value Field as the number of bytes (even) that make up the Value. It does not include the length of the Data Element Tag, Value Representation, and Value Length Fields.
⎯ a 32-bit Length Field set to Undefined Length (FFFFFFFFH). Undefined Lengths may be used for Data Elements having the Value Representation (VR) Sequence of Items (SQ) and Unknown (UN). For Data Elements with Value Representation OW or OB Undefined Length may be used depending on the negotiated Transfer Syntax (see Section 10 and Annex A).
Note: The decoder of a Data Set should support both Explicit and Undefined Lengths for VRs of SQ and UN and, when applicable, for VRs of OW and OB.
Value Field: An even number of bytes containing the Value(s) of the Data Element.
The data type of Value(s) stored in this field is specified by the Data Element's VR. The VR for a given Data Element Tag can be determined using the Data Dictionary in PS 3.6, or using the VR Field if it is contained explicitly within the Data Element. The VR of Standard Data Elements shall agree with those specified in the Data Dictionary.
The Value Multiplicity specifies how many Values with this VR can be placed in the Value Field. If the VM is greater than one, multiple values shall be delimited within the Value Field as defined previously in Section 6.4. The VMs of Standard Data Elements are specified in the Data Dictionary in PS 3.6.
Value Fields with Undefined Length are delimited through the use of Sequence Delimitation Items and Item Delimitation Data Elements which are described further in Section 7.5.
When using the Explicit VR structures, the Data Element shall be constructed of four consecutive fields: Data Element Tag, VR, Value Length, and Value. Depending on the VR of the Data Element, the Data Element will be structured in one of two ways:
⎯ for VRs of OB, OW, OF, SQ and UN the 16 bits following the two character VR Field are reserved for use by later versions of the DICOM Standard. These reserved bytes shall be set to 0000H and shall not be used or decoded (Table 7.1-1). The Value Length Field is a 32-bit unsigned integer. If the Value Field has an Explicit Length, then the Value Length Field shall contain a value equal to the length (in bytes) of the Value Field. Otherwise, the Value Field has an Undefined Length and a Sequence Delimitation Item marks the end of the Value Field.
⎯ for VRs of UT the 16 bits following the two character VR Field are reserved for use by later versions of the DICOM Standard. These reserved bytes shall be set to 0000H and shall not be used or decoded. The Value Length Field is a 32-bit unsigned integer. The Value Field is required to have an Explicit Length, that is the Value Length Field shall contain a value equal to the length (in bytes) of the Value Field.
Note: VRs of UT may not have an Undefined Length, ie. a Value Length of FFFFFFFFH.
⎯ for all other VRs the Value Length Field is the 16-bit unsigned integer following the two character VR Field (Table 7.1-2). The value of the Value Length Field shall equal the length of the Value Field.
Table 7.1-1 DATA ELEMENT WITH EXPLICIT VR OF OB, OW, OF, SQ, UT OR UN
|Group Number (16-bit unsigned integer)||Element Number (16-bit unsigned integer)||VR (2 byte character string) of "OB", "OW", “OF”, “SQ”, “UT” or "UN"||Reserved (2 bytes) set to a value of 0000H||32-bit unsigned integer||Even number of bytes containing the Data Element Value(s) encoded according to the VR and negotiated Transfer Syntax. Delimited with Sequence Delimitation Item if of Undefined Length.|
|2 bytes||2 bytes||2 bytes||2 bytes||4 bytes||'Value Length' bytes if of Explicit Length|
Table 7.1-2 DATA ELEMENT WITH EXPLICIT VR OTHER THAN AS SHOWN IN TABLE 7.1-1
|Group Number (16-bit unsigned integer)||Element Number (16-bit unsigned integer)||VR (2 byte character string)||(16-bit unsigned integer)||Even number of bytes containing the Data Element Value(s) encoded according to the VR and negotiated Transfer Syntax.|
|2 bytes||2 bytes||2 bytes||2 bytes||'Value Length' bytes|
When using the Implicit VR structure the Data Element shall be constructed of three consecutive fields: Data Element Tag, Value Length, and Value (see Table 7.1-3). If the Value Field has an Explicit Length then the Value Length Field shall contain a value equal to the length (in bytes) of the Value Field. Otherwise, the Value Field has an Undefined Length and a Sequence Delimitation Item marks the end of the Value Field.
Table 7.1-3Data element with implicit VR
|Group Number (16-bit unsigned integer)||Element Number (16-bit unsigned integer)||32-bit unsigned integer||Even number of bytes containing the Data Elements Value encoded according to the VR specified in PS 3.6 and the negotiated Transfer Syntax. Delimited with Sequence Delimitation Item if of Undefined Length.|
|2 bytes||2 bytes||4 bytes||'Value Length' bytes or Undefined Length|
Group Length (gggg,0000) Standard Data Elements have been retired. See PS 3.5 2007.
All implementations shall be able to parse Group Length elements, and may discard and not insert or re-insert them; if present they shall be consistent with the encoding of the dataset even if the transfer syntax is changed resulting in a change in the actual length of a group of elements. No implementation shall require the presence of Group Length elements.
Notes: 1. Elements in groups 0, 2, 4 and 6 are not Standard Data Elements. Mandatory requirements for Group Length for groups 0 and 2 are specified elsewhere in the standard.
2. It is recommended that Group Length elements be removed during storage or transfer in order to avoid the risk of inconsistencies arising during coercion of data element values and changes in transfer syntax.
Another component of the encoding of a Data Set that shall be agreed upon by communicating Application Entities is the Byte Ordering.
Little Endian byte ordering is defined as follows:
⎯ In a binary number consisting of multiple bytes (e.g. a 32-bit unsigned integer value, the Group Number, the Element Number, etc.), the least significant byte shall be encoded first; with the remaining bytes encoded in increasing order of significance.
⎯ In a character string consisting of multiple 8-bit single byte codes, the characters will be encoded in the order of occurrence in the string (left to right).
Big Endian byte ordering is defined as follows:
⎯ In a binary number consisting of multiple bytes, the most significant byte shall be encoded first; with the remaining bytes encoded in decreasing order of significance.
⎯ In a character string consisting of multiple 8-bit single byte codes, the characters will be encoded in the order of occurrence in the string (left to right).
Note: The packing of bits within values of OB or OW Value representation for Pixel Data and Overlay Data is described in Section 8.
Byte ordering is a component of an agreed upon Transfer Syntax (see Section 10). The default DICOM Transfer Syntax, which shall be supported by all AEs, uses Little Endian encoding and is specified in Annex A.1. Alternate Transfer Syntaxes, some of which use Big Endian encoding, are also specified in Annex A.
Note: The Command Set structure as specified in PS 3.7 is encoded using the Little Endian Implicit VR Transfer Syntax.
In the default case of Little Endian encoding, Big Endian Machines interpreting Data Sets shall do 'byte swapping' before interpreting or operating on certain Data Elements. The Data Elements affected are all those having VRs that are multiple byte Values and that are not a character string of 8-bit single byte codes. VRs constructed of a string of characters of 8-bit single byte codes are really constructed of a string of individual bytes, and are therefore not affected by byte ordering. The VRs that are not a string of characters and consist of multiple bytes are:
⎯ 2-byte US, SS, OW and each component of AT
⎯ 4-byte OF, UL, SL, and FL
⎯ 8 byte FD
Note: For the above VRs, the multiple bytes are presented in increasing order of significance when in Little Endian format. For example, an 8-byte Data Element with VR of FD, might be written in hexadecimal as 68AF4B2CH, but encoded in Little Endian would be 2C4BAF68H.
An attribute, encoded as a Data Element, may or may not be required in a Data Set, depending on that Attribute's Data Element Type.
The Data Element Type of an Attribute of an Information Object Definition or an Attribute of a SOP Class Definition is used to specify whether that Attribute is mandatory or optional. The Data Element Type also indicates if an Attribute is conditional (only mandatory under certain conditions). The Data Element Types of Attributes of Composite IODs are specified in PS 3.3. The Data Element Types of Attributes of Normalized IODs are specified as Attributes of SOP Classes in PS 3.4.
IODs and SOP Classes define Type 1 Data Elements that shall be included and are mandatory elements. The Value Field shall contain valid data as defined by the elements VR and VM as specified in PS 3.6. The Length of the Value Field shall not be zero. Absence of a valid Value in a Type 1 Data Element is a protocol violation.
Note: For data elements with a string (CS, SH, LO) rather than binary, text or sequence Value Representation, and for which multiple Values are allowed, the presence of a single Value is sufficient to satisfy the Type 1 requirement, unless specified otherwise in the Attribute description, and other Values may be empty, unless otherwise specified by the IOD. The presence of one or more delimiter (BACKSLASH) characters alone, without any Values, is not sufficient to satisfy the Type 1 requirement, since even though the Value Length is greater than zero, there is no valid Value present.
IODs and SOP Classes define Data Elements that shall be included under certain specified conditions. Type 1C elements have the same requirements as Type 1 elements under these conditions. It is a protocol violation if the specified conditions are met and the Data Element is not included.
When the specified conditions are not met, Type 1C elements shall not be included in the Data Set.
IODs and SOP Classes define Type 2 Data Elements that shall be included and are mandatory Data Elements. However, it is permissible that if a Value for a Type 2 element is unknown it can be encoded with zero Value Length and no Value. If the Value is known the Value Field shall contain that value as defined by the elements VR and VM as specified in PS 3.6. These Data Elements shall be included in the Data Set and their absence is a protocol violation.
Note: The intent of Type 2 Data 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 Data Elements.
IODs and SOP Classes define Type 2C elements that have the same requirements as Type 2 elements under certain specified conditions. It is a protocol violation if the specified conditions are met and the Data Element is not included.
When the specified conditions are not met, Type 2C elements shall not be included in the Data Set.
Note: An example of a Type 2C Data Element is Inversion Time (0018,0082). For several SOP Class Definitions, this Data Element is required only if the Scanning Sequence (0018,0020) has the Value “IR.” It is not required otherwise. See PS 3.3.
IODs and SOP Classes define Type 3 Data Elements that are optional Data Elements. Absence of a Type 3 element from a Data Set does not convey any significance and is not a protocol violation. Type 3 elements may also be encoded with zero length and no Value. The meaning of a zero length Type 3 Data Element shall be precisely the same as that element being absent from the Data Set.
When an IOD defines a Sequence Data Element (see Section 7.5), the Type of the Sequence attribute defines whether the Sequence attribute itself must be present, and the Attribute Description of the Sequence attribute may define whether and how many Items shall be present in the Sequence. The Types of the attributes of the Data Set included in the Sequence, including any conditionality, are specified within the scope of each Data Set, i.e., for each Item present in the Sequence.
Notes: 1. The Type and Attribute Description of the Sequence determines whether Items are present; conditionality constraints on Data Elements of the Items cannot force an Item to be present.
2. Historically, many IODs declared Type 1 and Type 2 Data Elements of the Sequence to be Type 1C and Type 2C, respectively, with the condition that an Item is present. This is exactly the same as simply defining them as Type 1 and Type 2.
3. In particular, the conditionality constraint “Required if Sequence is sent” on the Type 1C or Type 2C Data Elements subsidiary to a Type 2 or 3 Sequence attribute does not imply that an Item must be present in the Sequence. These conditions are meant to be equivalent to “Required if a Sequence Item is present”, and the conditionality is not strictly necessary. Any Type 2 or Type 3 Sequence attribute may be sent with zero length.
4. In particular, the conditionality constraint “Required if <name-of-parent-sequence-attribute> is sent” on the Type 1C or Type 2C Data Elements subsidiary to a Type 2 or 3 Sequence attribute does not imply that an Item must be present in the Sequence. These conditions are meant to be equivalent to “Required if a Sequence Item is present”, and the conditionality is not strictly necessary. Any Type 2 or Type 3 Sequence attribute may be sent with zero length.
The VR identified "SQ" shall be used for Data Elements with a Value consisting of a Sequence of zero or more Items, where each Item contains a set of Data Elements. SQ provides a flexible encoding scheme that may be used for simple structures of repeating sets of Data Elements, or the encoding of more complex Information Object Definitions often called folders. SQ Data Elements can also be used recursively to contain multi-level nested structures.
Items present in an SQ Data Element shall be an ordered set where each Item may be referenced by its ordinal position. Each Item shall be implicitly assigned an ordinal position starting with the value 1 for the first Item in the Sequence, and incremented by 1 with each subsequent Item. The last Item in the Sequence shall have an ordinal position equal to the number of Items in the Sequence.
Notes: 1. This clause implies that item ordering is preserved during transfer and storage.
2. An IOD or Module Definition may choose to not use this ordering property of a Data Element with VR of SQ. This is simply done by not specifying any specific semantics to the ordering of Items, or by not specifying usage of the referencing of Items by ordering position.
The definition of the Data Elements encapsulated in each Item is provided by the specification of the Data Element (or associated Attribute) of Value Representation SQ. Items in a sequence of Items may or may not contain the same set of Data Elements. Data Elements with a VR of SQ may contain multiple Items but shall always have a Value Multiplicity of one (ie. a single Sequence).
There are three special SQ related Data Elements that are not ruled by the VR encoding rules conveyed by the Transfer Syntax. They shall be encoded as Implicit VR. These special Data Elements are Item (FFFE,E000), Item Delimitation Item (FFFE,E00D), and Sequence Delimitation Item (FFFE,E0DD). However, the Data Set within the Value Field of the Data Element Item (FFFE,E000) shall be encoded according to the rules conveyed by the Transfer Syntax.
Each Item of a Data Element of Value Representation SQ shall be encoded as a DICOM Standard Data Element with a specific Data Element Tag of Value (FFFE,E000). The Item Tag is followed by a 4 byte Item Length field encoded in one of the following two ways:
a) Explicit Length: The number of bytes (even) contained in the Sequence Item Value (following but not including the Item Length Field) is encoded as a 32-bit unsigned integer value (see Section 7.1). This length shall include the total length of all Data Elements conveyed by this Item. This Item Length shall be equal to 00000000H if the Item contains no Data Set.
b) Undefined Length: The Item Length Field shall contain the value FFFFFFFFH to indicate an undefined Item length. It shall be used in conjunction with an Item Delimitation Data Element. This Item Delimitation Data Element has a Data Element Tag of (FFFE,E00D) and shall follow the Data Elements encapsulated in the Item. No Value shall be present in the Item Delimitation Data Element and its Length shall be 00000000H.
The encoder of a Data Set may choose either one of the two ways of encoding. Both ways of encoding shall be supported by decoders of Data Sets. Data Element Tags (FFFF,eeee) are reserved by this standard and shall not be used.
Each Item Value shall contain a DICOM Data Set composed of Data Elements. Within the context of each Item, these Data Elements shall be ordered by increasing Data Element Tag value and appear only once (as Data Set is defined in Section 7.1). There is no relationship between the ordering of the Data Elements contained within an Item and the ordering of the Data Element Tag of SQ Value Representation that contains that Item. One or more Data Elements in an Item may be of Value Representation SQ, thus allowing for recursion.
Data Elements with a group of 0000, 0002, 0004 and 0006 shall not be present within Sequence Items.
Note: The use of Transfer Syntax UID (0002,0010) in particular is forbidden, since were it to differ from the Transfer Syntax of the enclosing dataset then a change in encoding would be implied, which is not allowed.
Section 7.8 specifies rules for incorporating Private Data Elements into Sequence Items.
Delimitation of the last Item of a Sequence of Items, encapsulated in a Data Element of Value Representation SQ, shall be in one of the two following ways:
a) Explicit Length: The number of bytes (even) contained in the Data Element Value (following but not including the Data Element Length Field) is encoded as a 32-bit unsigned integer value (see Section 7.1). This length shall include the total length resulting from the sequence of zero or more items conveyed by this Data Element. This Data Element Length shall be equal to 00000000H if the sequence of Items contains zero Items.
b) Undefined Length: The Data Element Length Field shall contain a Value FFFFFFFFH to indicate an Undefined Sequence length. It shall be used in conjunction with a Sequence Delimitation Item. A Sequence Delimitation Item shall be included after the last Item in the sequence. Its Item Tag shall be (FFFE,E0DD) with an Item Length of 00000000H. No Value shall be present.
The encoder of a Sequence of Items may choose either one of the two ways of encoding. Both ways of encoding shall be supported by decoders of the Sequence of Items.
Note: The Sequence Delimitation Item Tag (FFFE,E0DD) is different from the Item Delimitation Tag (FFFE,E00D) introduced above in that it indicates the end of a Sequence of Items whose Length was left undefined. If an undefined length Item is the last Item of a Sequence of Items of undefined length, then an Item Delimitation Tag will be followed by a Sequence Delimitation Tag.
For an example of an SQ Data Element of Explicit Length encapsulating Items of Explicit Length see Table 7.5-1.
For an example of an SQ Data Element of Undefined Length encapsulating Items of Explicit Length see Table 7.5-2.
For an example of an SQ Data Element of Undefined Length encapsulating Items of both Explicit and Undefined Length see Table 7.5-3.
Table 7.5-1 EXAMPLE OF A DATA ELEMENT WITH IMPLICIT VR DEFINED AS A SEQUENCE OF ITEMS (VR = SQ) WITH THREE ITEMS OF EXPLICIT LENGTH
|Data Element Tag||Data Element Length||Data Element Value|
|(gggg, eeee) with VR of SQ||00000F00H||First Item||Second Item||Third Item|
|Item Tag (FFFE, E000)||Item Length 0000 04F8H||Item Value Data Set||Item Tag (FFFE, E000)||Item Length 0000 04F8H||Item Value Data Set||Item Tag (FFFE, E000)||Item Length 0000 04F8H||Item Value Data Set|
|4 bytes||4 bytes||4 bytes||4 bytes||04F8H bytes||4 bytes||4 bytes||04F8H bytes||4 bytes||4 bytes||04F8H bytes|
Table 7.5-2 EXAMPLE OF A DATA ELEMENT WITH EXPLICIT VR DEFINED AS A SEQUENCE OF ITEMS (VR = SQ) OF UNDEFINED LENGTH, CONTAINING TWO ITEMS OF EXPLICIT LENGTH
|Data Element Tag||Value Representation||Data Element Length||Data Element Value|
|(gggg, eeee) with VR of SQ||SQ||0000H Reserved||FFFF FFFFH un-defined length||First Item||Second Item||Sequence Delimitation Item|
|First Item||Second Item||Sequence Delimitation Item|
|(gggg, eeee) with VR of SQ||FFFF FFFFH un-defined length||Item Tag (FFFE, E000||Item Length 0000 17B6H||Item Value Data Set||Item Tag (FFFE, E000)|
|525-line NTSC||Full||30||33.33 ms||480||720|
|625-line PAL||Full||25||40.0 ms||576||720|
Notes: 1. Although different combinations of values for Rows and Columns values are possible while respecting the maximum values listed above, it is recommended that the typical 4:3 ratio of image width to height be maintained in order to avoid image deformation by MPEG2 decoders. A common way to maintain the ratio of width to height is to pad the image with black areas on either side.
2. "Half" definition of pictures (240x352 and 288x352 for NTSC and PAL, respectively) are always supported by decoders.
3. MP@ML allows for various different display and pixel aspect ratios, including the use of square pixels, and the use of non-square pixels with display aspect ratios of 4:3 and 16:9. DICOM specifies no additional restrictions beyond what is provided for in MP@ML. All permutations allowed by MP@ML are valid and are require to be supported by all DICOM decoders.
4. The actual frame rate for NTSC MPEG2 is approximately 29.97 frames/sec.
5. The nominal Frame Time is supplied for the purpose of inclusion on the DICOM Cine Module Attributes, and should be calculated from the actual frame rate.
One fragment shall contain the whole stream.
Notes: 1. If a video stream exceeds the maximum length of one fragment, it may be sent as multiple SOP Instances.
2. This constraint limits the length of the compressed bit stream to no longer than 2 32 -2 bytes.
The Basic Offset Table shall be empty (present but zero length).
Note: The Basic Offset Table is not used because MPEG2 contains its own mechanism for describing navigation of frames. To enable decoding of only a part of the sequence, MPEG2 manages a header in any group of pictures (GOP) containing a time_code – a 25-bit integer containing the following: drop_frame_flag, time_code_hours, time_code_minutes, marker_bit, time_code_seconds and time_code_pictures.
Any audio components present within the MPEG bit stream shall comply with the following restrictions:
- CBR MPEG-1 LAYER III (MP3) Audio Standard
- up to 24 bits
- 32 kHz, 44.1 kHz or 48 kHz for the main channel (the complementary channels can be sampled at the half rate, as defined in the Standard)
- one main mono or stereo channel, and optionally one or more complementary channel(s)
Note : Although MPEG describes each channel as including up to 5 signals (e.g. for surround effects), it is recommended to limit each of the two channels to 2 signals each one (stereo).
An encapsulated Data Set shall only include the Specific Character Set (0008,0005) data element if the Attribute Specific Character Set is defined in the IOD for that sequence of items.
Note: An encapsulated Data Set does not include the Specific Character Set data element unless the Specific Character Set Attribute is defined as part of the IOD for that sequence.
If an encapsulated Data Set includes the Specific Character Set Attribute, it shall apply only to the encapsulated Data Set. If the Attribute Specific Character Set is not explicitly included in an encapsulated Data Set, then the Specific Character Set value of the encapsulating Data Set applies.
Multiple Overlay Planes and Curves are often associated with a single Image (see PS 3.3). Standard Data Elements with even Group Numbers (5000-501E,eeee) represent Curves, while elements with even Group Numbers (6000-601E,eeee) represent Overlay Planes. Both of these ranges of Group numbers are known as Repeating Groups. This use of group numbers is a remnant of versions of this standard prior to V3.0 that associated a semantic meaning with particular Groups.
In each of these ranges of Group Numbers, Standard Data Elements that have identical Element Numbers have the same meaning within each Group (and the same VR, VM, and Data Element Type). The notation (50xx,eeee) and (60xx,eeee) are used for the Group Number in Data Element Tags when referring to a common Data Element across these groups (see PS 3.6). Groups (50xx,eeee) and (60xx,eeee) are called Repeating Groups because of these characteristics.
Repeating Groups shall only be allowed in the even Groups (6000-601E,eeee) and even Groups (5000- 501E,eeee) cases. In the future, Data Elements with VRs of SQ shall be used to serve a similar purpose.
Note: Private Groups in the odd Groups (5001-501F,eeee) and (6001-601F,eeee) may still be used, but there is no implication of repeating semantics, nor any implied shadowing of the standard repeating groups.
Certain Data Elements are no longer supported beginning with Version 3.0 of this standard. These Data Elements are retired and are denoted as such (RET) in the VR column in PS 3.6. Implementations may continue to support these Data Elements for the purpose of backward compatibility with versions of this standard prior to V3.0, but this is not a requirement of this standard. If a retired Data Element is used it must contain valid data as specified in versions of this standard prior to V3.0. Any other use of a retired Data Element, and its associated Data Element Tag, is reserved by this standard. Retired Data Element Tags shall not be redefined in later versions of this standard.
Implementations may require communication of information that cannot be contained in Standard Data Elements. Private Data Elements are intended to be used to contain such information. Such Private Data Elements shall not change the semantics of the Information Object Definition or SOP Class Definition.
Private Data Elements have the same structure as Standard Data Elements specified earlier in Section 7.1 (i.e., Data Element Tag field, optional VR field, length field, and value field). The Group Number used in the Element Tag of Private Data Elements shall be an odd number. Private Data Elements shall be contained in the Data Set in increasing numeric order of Data Element Tag. The Value Field of a Private data element shall have one of the VRs specified by this standard in Section 6.2.
For each Information Object Definition or SOP Class Definition, certain Data Elements are required (Data Element Type 1, 1C, 2, or 2C) as specified in PS 3.3 and PS 3.4. Private Data Elements shall not be used in place of required Standard Data Elements.
It is possible that multiple implementors may define Private Elements with the same (odd) group number. To avoid conflicts, Private Elements shall be assigned Private Data Element Tags according to the following rules.
Note: The versions of this standard prior to V3.0 described shadow groups. These were groups with a group number one greater than the standard groups. Elimination of conflicts in Private Data Element Tags have made this distinction obsolete and this terminology has been retired.
Note: The versions of this standard prior to V3.0 specified private group element numbers (gggg,10FF- 7FFF) reserved for manufacturers and private group element numbers (gggg, 8100-FFFF) reserved for users. Elimination of conflicts in Private Data Element Tags has made this distinction obsolete and this specification has been retired.
Since each Item within a sequence is a self contained Data Set (see Section 7.5 on the nesting of Data Sets via Sequences of Items), any Item which contains Private Data Elements shall also have Private Creator Data Elements reserving blocks of Elements for those Private Data Elements. The scope of the reservation is just within the Item. Items do not inherit the Private Data Element reservations made by Private Creator Data Elements in the Data Set in which the Item is nested.
Note: If a sequence is itself a Private Data Element and the Items within the sequence also have Private Data Elements, then there will be Private Creator Data Elements both outside the sequence and within the sequence Items.
Note: Different Items may reserve the same block of Private Data Elements for different private creators. This is necessary to allow the nesting of Data Sets collected from multiple sources into folders.
The Value Representations used for Private Data Elements shall be the same as those VRs specified for Standard Data Elements in Section 6.2. The encoding shall conform to the requirements for those VRs and shall be in accordance with the negotiated Transfer Syntax. A Private Data Element with SQ VR (a Private Data Sequence) may include Items with both Standard and Private Data Elements. Standard Data Elements used within a Private Data Sequence shall use the VRs as defined in PS 3.6 for those data elements.
The semantics of Standard Data Elements within a Private Data Sequence, and the definition of Attribute Values, are implementation dependent.
For a Standard Extended SOP Class the Attributes (07FE,0010) Pixel Data, (5400,1010) Waveform Data, and (60xx,3000) Overlay Data shall not be included within a Private Sequence Item, nor within a standard Sequence Item nested directly or indirectly within a Private Sequence Item.