Материал: part05

thatispresentbutempty.WhetherornotItemsmaybeempty(containnoDataElements)dependsontheIODdefinition​ of the Data Set for each Item, rather than the Type of the enclosing Sequence Data Element.​

7.4.4 Type 2C Conditional Data Elements​

IODs and SOP Classes define Type 2C elements that have the same requirements as Type 2 elements under certain specified con-​ ditions. 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​

AnexampleofaType2CDataElementisInversionTime(0018,0082).ForseveralSOPClassDefinitions,thisDataElement​ is required only if the Scanning Sequence (0018,0020) has the Value "IR." It is not required otherwise. See PS3.3.​

7.4.5 Type 3 Optional Data Elements​

IODs and SOP Classes define Type 3 Data Elements that are optional Data Elements. Absence of a Type 3 element from a Data Set​ doesnotconveyanysignificanceandisnotaprotocolviolation.Type3elementsmayalsobeencodedwithzerolengthandnoValue.​ The meaning of a zero length Type 3 Data Element shall be precisely the same as that element being absent from the Data Set.​

7.4.6 Data Element Types Within A Sequence​

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.​

Note​

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, re-​ spectively, 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 condi-​ tionality is not strictly necessary. Any Type 2 or Type 3 Sequence attribute may be sent with zero length.​

7.5 Nesting of Data Sets​

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.​

Note​

1.​This clause implies that item ordering is preserved during transfer and storage.​

- Standard -​

2.​An IOD or Module Definition may choose to not use this ordering property of a Data Element with VR of SQ. This is​ simplydonebynotspecifyinganyspecificsemanticstotheorderingofItems,orbynotspecifyingusageofthereferencing​ 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 (i.e., 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 Se-​ quence 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.​

7.5.1 Item Encoding Rules​

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)isencodedasa32-bitunsignedintegervalue(seeSection7.1).ThislengthshallincludethetotallengthofallDataElements​ 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​ DataElementanditsLengthshallbe00000000H.AnItemcontainingnoDataSetisencodedbyanItemDelimitationDataElement​ only.​

TheencoderofaDataSetmaychooseeitheroneofthetwowaysofencoding.Bothwaysofencodingshallbesupportedbydecoders​ 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 re-​ lationship 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 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 Data Set 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.​

7.5.2 Delimitation of The Sequence of 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​ fromthesequenceofzeroormoreitemsconveyedbythisDataElement.ThisDataElementLengthshallbeequalto00000000H​ 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​ Iteminthesequence.ItsItemTagshallbe(FFFE,E0DD)withanItemLengthof00000000H.NoValueshallbepresent.ASequence​ containing zero Items is encoded by a Sequence Delimitation Item only.​

- Standard -​

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​

TheSequenceDelimitationItemTag(FFFE,E0DD)isdifferentfromtheItemDelimitationTag(FFFE,E00D)introducedabove​ 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.​

ForanexampleofanSQDataElementofUndefinedLengthencapsulatingItemsofbothExplicitandUndefinedLengthseeTable7.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​

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​

Note​

The Data Set within the Item Values in Table 7.5-2 have VRs Explicitly defined.​

- Standard -​

Table 7.5-3. Example of a Data Element with Implicit VR Defined as a Sequence of Items (VR = SQ) of​ Undefined Length, Containing Two Items Where One Item is of Explicit Length and the Other Item is of​ Undefined Length​

7.5.3 Sequence Inheritance​

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 At-​ tribute 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 At-​ tribute Specific Character Set is not explicitly included in an encapsulated Data Set, then the Specific Character Set value of the en-​ capsulating Data Set applies.​

7.6 Repeating Groups​

Multiple Overlay Planes and Curves are often associated with a single Image (see PS3.3). Standard Data Elements with even Group​ Numbers(5000-501E,eeee)representCurves,whileelementswithevenGroupNumbers(6000-601E,eeee)representOverlayPlanes.​ Both of these ranges of Group numbers are known as Repeating Groups. This use of group numbers is a remnant of older versions​ of this Standard, which 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​ withineachGroup(andthesameVR,VM,andDataElementType).Thenotation(50xx,eeee)and(60xx,eeee)areusedfortheGroup​ Number in Data Element Tags when referring to a common Data Element across these groups (see PS3.6). Groups (50xx,eeee) and​ (60xx,eeee) are called Repeating Groups because of these characteristics.​

RepeatingGroupsshallonlybeallowedintheevenGroups(6000-601E,eeee)andevenGroups(5000-501E,eeee)cases.Inthefuture,​ 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.​

7.7 Retired Data Elements​

Certain Data Elements are no longer supported in the current Standard. These Data Elements are retired and are denoted as such​ (RET) in the VR column in PS3.6. Implementations may continue to support these Data Elements for the purpose of backward com-​ patibility with older versions of this Standard, but this is not a requirement of the current Standard. If a retired Data Element is used​

- Standard -​

it must contain valid data as specified in older versions of this Standard. 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.​

7.8 Private Data Elements​

ImplementationsmayrequirecommunicationofinformationthatcannotbecontainedinStandardDataElements.PrivateDataElements​ 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 PS3.3 and PS3.4. Private Data Elements shall not be used in place of required Standard Data Elements.​

7.8.1 Private Data Element Tags​

It is possible that multiple implementers 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.​

a.​Private Creator Data Elements numbered (gggg,0010-00FF) (gggg is odd) shall be used to reserve a block of Elements with​ Group Number gggg for use by an individual implementer. The implementer shall insert an identification code in the first unused​ (unassigned) Element in this series to reserve a block of Private Elements. The VR of the private identification code shall be LO​ (LongString)andtheVMshallbeequalto1.APrivateCreatoridentifiermaybeusedonlyoncewithinaGroup;reservingmultiple​ blocks of Elements in the same Group with the same identifier is not allowed. The Private Creator Data Elements shall only​ contain characters from the Default Character Repertoire and not an Extended or Replacement Character Repertoire, even​ though the LO VR is one that is affected by the Specific Character Set (0008,0005).​

Note​

i.​ If an implementer needs multiple repetitions of a private element, a private Sequence attribute (see Section 7.5)​ may be used to contain these multiple items.​

ii.​ An implementer may use the same Private Creator identifier for multiple Groups.​

b.​PrivateCreatorDataElement(gggg,0010),isaType1DataElementthatidentifiestheimplementerreservingelement(gggg,1000-​ 10FF), Private Creator Data Element (gggg,0011) identifies the implementer reserving elements (gggg,1100-11FF), and so on,​ until Private Creator Data Element (gggg,00FF) identifies the implementer reserving elements (gggg,FF00-FFFF).​

c.​Encoders of Private Data Elements shall be able to dynamically assign private data to any available (unreserved) block(s) within​ the Private group, and specify this assignment through the blocks corresponding Private Creator Data Element(s). Decoders of​ Private Data shall be able to accept reserved blocks with a given Private Creator identification code at any position within the​ Private group specified by the blocks corresponding Private Creator Data Element.​

Note​

1.​Older versions of this Standard 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.​

2.​Older versions of this Standard specified private group element numbers (gggg,10FF-7FFF) reserved for manufac-​ turers 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.​

3.​Therequirementsofthissectiondonotallowanyuseofelementsintheranges(gggg,0001-000F)and(gggg,0100-​ 0FFF) where gggg is odd.​

d.​Elements with Tags (0001,xxxx), (0003,xxxx), (0005,xxxx), (0007,xxxx) and (FFFF,xxxx) shall not be used.​

- Standard -​