C.12 General Modules

C.12 General Modules
Prev	C Information Module Definitions (Normative)	Next

The SOP Common Module shall be mandatory for all DICOM IODs.

C.12.1 SOP Common Module

Table C.12-1 defines the Attributes that are required for proper functioning and identification of the associated SOP Instances. They do not specify any semantics about the Real-World Object represented by the IOD.

Table C.12-1. SOP Common Module Attributes

Attribute Name	Tag	Type	Attribute Description
SOP Class UID	(0008,0016)	1	Uniquely identifies the SOP Class. See Section C.12.1.1.1 for further explanation. See also PS3.4.
SOP Instance UID	(0008,0018)	1	Uniquely identifies the SOP Instance. See Section C.12.1.1.1 for further explanation. See also PS3.4.
Specific Character Set	(0008,0005)	1C	Character Set that expands or replaces the Basic Graphic Set. Required if an expanded or replacement character set is used. See Section C.12.1.1.2 for Defined Terms.
Instance Creation Date	(0008,0012)	3	Date the SOP Instance was created. This is the date that the SOP Instance UID was assigned, and does not change during subsequent coercion of the instance.
Instance Creation Time	(0008,0013)	3	Time the SOP Instance was created. This is the time that the SOP Instance UID was assigned, and does not change during subsequent coercion of the instance.
Instance Coercion DateTime	(0008,0015)	3	Date and time that the SOP Instance was last coerced by a Storage SCP (see PS3.4).
Instance Creator UID	(0008,0014)	3	Uniquely identifies device that created the SOP Instance.
Related General SOP Class UID	(0008,001A)	3	Uniquely identifies a Related General SOP Class for the SOP Class of this Instance. See PS3.4.
Original Specialized SOP Class UID	(0008,001B)	3	The SOP Class in which the Instance was originally encoded that has been replaced during a fall-back conversion to the current Related General SOP Class. See PS3.4.
Coding Scheme Identification Sequence	(0008,0110)	3	Sequence of items that map values of Coding Scheme Designator (0008,0102) to an external coding system registration, or to a private or local coding scheme. One or more Items are permitted in this Sequence.
>Coding Scheme Designator	(0008,0102)	1	The value of a Coding Scheme Designator, used in this SOP Instance, which is being mapped.
>Coding Scheme Registry	(0008,0112)	1C	The name of the external registry where further definition of the identified coding scheme may be obtained. Required if coding scheme is registered. Defined Terms: HL7
>Coding Scheme UID	(0008,010C)	1C	The coding scheme UID identifier. Required if coding scheme is identified by an ISO 8824 object identifier compatible with the UI VR.
>Coding Scheme External ID	(0008,0114)	2C	The coding scheme identifier as defined in an external registry. Required if coding scheme is registered and Coding Scheme UID (0008,010C) is not present.
>Coding Scheme Name	(0008,0115)	3	The coding scheme full common name
>Coding Scheme Version	(0008,0103)	3	The coding scheme version associated with the Coding Scheme Designator (0008,0102).
>Coding Scheme Responsible Organization	(0008,0116)	3	Name of the organization responsible for the Coding Scheme. May include organizational contact information.
Context Group Identification Sequence	(0008,0123)	3	Sequence of items that map values of Context Identifier (0008,010F) to an external, private or local Context Group. One or more Items are permitted in this Sequence.
>Context Identifier	(0008,010F)	1	The identifier of the Context Group. See Section 8.6.
>Context UID	(0008,0117)	3	The unique identifier of the Context Group. See Section 8.6.
>Mapping Resource	(0008,0105)	1	The identifier of the Mapping Resource that defines the Context Group. See Section 8.4.
>Context Group Version	(0008,0106)	1	The identifier of the version of the Context Group. See Section 8.5.
Mapping Resource Identification Sequence	(0008,0124)	3	Sequence of items that map values of Mapping Resource (0008,0105) to an external, private or local Mapping Resource. One or more Items are permitted in this Sequence.
>Mapping Resource	(0008,0105)	1	The identifier of the Mapping Resource. See Section 8.4.
>Mapping Resource UID	(0008,0118)	3	The unique identifier of the Mapping Resource
>Mapping Resource Name	(0008,0122)	3	The name of the Mapping Resource. See Section 8.4.
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, and for all DT Attributes present in this SOP Instance that do not contain an explicitly encoded timezone offset. See Section C.12.1.1.8 The local timezone offset is undefined if this Attribute is absent.
Contributing Equipment Sequence	(0018,A001)	3	Sequence of Items containing descriptive attributes of related equipment that has contributed to the acquisition, creation or modification of the composite instance. One or more Items are permitted in this Sequence. See Section C.12.1.1.5 for further explanation.
>Purpose of Reference Code Sequence	(0040,A170)	1	Describes the purpose for which the related equipment is being referenced. Only a single Item shall be included in this Sequence. See Section C.12.1.1.5 for further explanation.
>>Include Table 8.8-1 “Code Sequence Macro Attributes”			Defined CID 7005 “Contributing Equipment Purposes of Reference”.
>Manufacturer	(0008,0070)	1	Manufacturer of the equipment that contributed to the composite instance.
>Institution Name	(0008,0080)	3	Institution where the equipment that contributed to the composite instance is located.
>Institution Address	(0008,0081)	3	Address of the institution where the equipment that contributed to the composite instance is located.
>Station Name	(0008,1010)	3	User defined name identifying the machine that contributed to the composite instance.
>Institutional Department Name	(0008,1040)	3	Department in the institution where the equipment that contributed to the composite instance is located.
>Operators' Name	(0008,1070)	3	Name(s) of the operator(s) of the contributing equipment.
>Operator Identification Sequence	(0008,1072)	3	Identification of the operator(s) of the contributing equipment. One or more Items are permitted in this Sequence. The number and order of Items shall correspond to the number and order of values of Operators' Name (0008,1070), if present.
>>Include Table 10-1 “Person Identification Macro Attributes Description”
>Manufacturer's Model Name	(0008,1090)	3	Manufacturer's model name of the equipment that contributed to the composite instance.
>Device Serial Number	(0018,1000)	3	Manufacturer's serial number of the equipment that contributed to the composite instance.
>Software Versions	(0018,1020)	3	Manufacturer's designation of the software version of the equipment that contributed to the composite instance. See Section C.7.5.1.1.3.
>Spatial Resolution	(0018,1050)	3	The inherent limiting resolution in mm of the acquisition equipment for high contrast objects for the data gathering and reconstruction technique chosen. If variable across the images of the series, the value at the image center.
>Date of Last Calibration	(0018,1200)	3	Date when the image acquisition device calibration was last changed in any way. Multiple entries may be used for additional calibrations at other times. See Section C.7.5.1.1.1 for further explanation.
>Time of Last Calibration	(0018,1201)	3	Time when the image acquisition device calibration was last changed in any way. Multiple entries may be used. See Section C.7.5.1.1.1 for further explanation.
>Contribution DateTime	(0018,A002)	3	The Date & Time when the equipment contributed to the composite instance.
>Contribution Description	(0018,A003)	3	Description of the contribution the equipment made to the composite instance.
Instance Number	(0020,0013)	3	A number that identifies this Composite object instance.
SOP Instance Status	(0100,0410)	3	A flag that indicates the storage status of the SOP Instance. Enumerated Values: NS Not Specified; implies that this SOP Instance has no special storage status, and hence no special actions need be taken OR Original; implies that this is the primary SOP instance for the purpose of storage, but that it has not yet been authorized for diagnostic use AO Authorized Original; implies that this is the primary SOP instance for the purpose of storage, which has been authorized for diagnostic use AC Authorized Copy; implies that this is a copy of an Authorized Original SOP Instance; any copies of an Authorized Original should be given the status of Authorized Copy Note Proper use of these flags is specified in Security Profiles. Implementations that do not conform to such Security Profiles may not necessarily handle these flags properly.
SOP Authorization DateTime	(0100,0420)	3	The date and time when the SOP Instance Status (0100,0410) was set to AO.
SOP Authorization Comment	(0100,0424)	3	Any comments associated with the setting of the SOP Instance Status (0100,0410) to AO.
Authorization Equipment Certification Number	(0100,0426)	3	The certification number issued to the Application Entity that set the SOP Instance Status (0100,0410) to AO.
Include Table C.12-6 “Digital Signatures Macro Attributes”
Encrypted Attributes Sequence	(0400,0500)	1C	Sequence of Items containing encrypted DICOM data. One or more Items shall be included in this Sequence. Required if application level confidentiality is needed and certain recipients are allowed to decrypt all or portions of the Encrypted Attributes Data Set. See Section C.12.1.1.4.1.
>Encrypted Content Transfer Syntax UID	(0400,0510)	1	Transfer Syntax used to encode the encrypted content. Only Transfer Syntaxes that explicitly include the VR and use Little Endian encoding shall be used.
>Encrypted Content	(0400,0520)	1	Encrypted data. See Section C.12.1.1.4.2.
Original Attributes Sequence	(0400,0561)	3	Sequence of Items containing all attributes that were removed or replaced by other values in the main data set. One or more Items are permitted in this Sequence.
>Source of Previous Values	(0400,0564)	2	The source that provided the SOP Instance prior to the removal or replacement of the values. For example, this might be the Institution from which imported SOP Instances were received.
>Attribute Modification DateTime	(0400,0562)	1	Date and time the attributes were removed and/or replaced.
>Modifying System	(0400,0563)	1	Identification of the system that removed and/or replaced the attributes.
>Reason for the Attribute Modification	(0400,0565)	1	Reason for the attribute modification. Defined Terms: COERCE Replace values of attributes such as Patient Name, ID, Accession Number, for example, during import of media from an external institution, or reconciliation against a master patient index. CORRECT Replace incorrect values, such as Patient Name or ID, for example, when incorrect worklist item was chosen or operator input error.
>Modified Attributes Sequence	(0400,0550)	1	Sequence that contains all the Attributes, with their previous values, that were modified or removed from the main data set. Only a single Item shall be included in this Sequence.
>>Any Attribute from the main data set that was modified or removed.		1	May include Sequence Attributes and their Items.
HL7 Structured Document Reference Sequence	(0040,A390)	1C	Sequence of items defining mapping between HL7 Instance Identifiers of unencapsulated HL7 Structured Documents referenced from the current SOP Instance as if they were DICOM Composite SOP Class Instances defined by SOP Class and Instance UID pairs. May also define a means of accessing the Documents. One or more Items shall be included in this Sequence. See Section C.12.1.1.6. Required if unencapsulated HL7 Structured Documents are referenced within the Instance. Every such document so referenced is required to have a corresponding Item in this Sequence.
>Include Table 10-11 “SOP Instance Reference Macro Attributes”
>HL7 Instance Identifier	(0040,E001)	1	Instance Identifier of the referenced HL7 Structured Document, encoded as a UID (OID or UUID), concatenated with a caret ("^") and Extension value (if Extension is present in Instance Identifier).
>Retrieve URI	(0040,E010)	3	Retrieval access path to HL7 Structured Document. Includes fully specified scheme, authority, path, and query in accordance with[RFC3986]. Note The VR of this attribute has changed from UT to UR.
Longitudinal Temporal Information Modified	(0028,0303)	3	Indicates whether or not the date and time attributes in the instance have been modified during de-identification. Enumerated Values: UNMODIFIED MODIFIED REMOVED See PS3.15.
Query/Retrieve View	(0008,0053)	1C	The view requested during the C-MOVE operation that resulted in the transfer of this instance. Enumerated Values: CLASSIC ENHANCED Required if the instance has ever been converted from its source form as the result of a C-MOVE operation with a specific view.
Conversion Source Attributes Sequence	(0020,9172)	1C	The set of images or other composite SOP Instances that were converted to this instance. If this instance was converted from a specific frame in the source instance, the reference shall include the Frame Number. One or more Items shall be included in this Sequence. Required if this instance was created by conversion, and Conversion Source Attributes Sequence (0020,9172) is not present in an Item of Shared Functional Groups Sequence (5200,9229) or Per-Frame Functional Groups Sequence (5200,9230).
>Include Table 10-3 “Image SOP Instance Reference Macro Attributes”
Content Qualification	(0018,9004)	3	Content Qualification Indicator Enumerated Values: PRODUCT RESEARCH SERVICE See Section C.8.13.2.1.1 for further explanation.
Private Data Element Characteristics Sequence	(0008,0300)	3	Characteristics of Private Data Elements within or referenced in the current SOP Instance. See Section C.12.1.1.7. One or more Items are permitted in this Sequence.
>Private Group Reference	(0008,0301)	1	Odd group number within which the Private Data Element block is reserved.
>Private Creator Reference	(0008,0302)	1	The value of the Private Creator Data Element value used to reserve the block of Private Data Elements whose characteristics are described in this Item. Note Private blocks are identified by their Private Creator Data Element value, rather than their numeric block number, since instances may be modified and numeric block numbers reassigned but the Private Creator Data Element value, which is required to be unique within a Group of Private Data Elements, will be preserved.
>Private Data Element Definition Sequence	(0008,0310)	3	Description of individual private Data Elements. One or more Items are permitted in this Sequence.
>>Private Data Element	(0008,0308)	1	Element Number used to identify the Data Element within the reserved block. The value of this attribute represents the last two digits of the Data Element tag; i.e., the value of xx in (gggg,00xx) where gggg is the Private Group Reference (0008,0301).
>>Private Data Element Value Multiplicity	(0008,0309)	1	Value Multiplicity (VM) of the Data Element. See Section C.12.1.1.7.1.
>>Private Data Element Value Representation	(0008,030A)	1	Value Representation (VR) of the Data Element.
>>Private Data Element Number of Items	(0008,030B)	1C	Number of items allowed in a sequence Data Element. Required if the value of Private Data Element Value Representation (0008,030A) is SQ. See Section C.12.1.1.7.2.
>>Private Data Element Keyword	(0008,030D)	1	Keyword for the Data Element (in the sense of the keywords provided in PS3.6).
>>Private Data Element Name	(0008,030C)	1	Name for referring to the Data Element.
>>Private Data Element Description	(0008,030E)	3	Description of the purpose and/or proper usage of the Data Element.
>>Private Data Element Encoding	(0008,030F)	3	Description of how the Data Element value contents are encoded.
>>Retrieve URI	(0040,E010)	3	Retrieval access path to associated documentation. Includes fully specified scheme, authority, path, and query in accordance with [RFC3986].
>Block Identifying Information Status	(0008,0303)	1	Specifies whether some or all of the Private Data Elements in the block are safe from identity leakage as defined by PS3.15 Section E.3.10 Retain Safe Private Option. Enumerated Values: SAFE no data elements within the block contain identifying information UNSAFE all data elements within the block may contain identifying information MIXED some data elements within the block may contain identifying information
>Nonidentifying Private Elements	(0008,0304)	1C	List of Private Data Elements in block that do not contain identifying information (are safe from identity leakage). Elements are identified by the lowest 8-bits of the attribute tag (i.e. with a value from 0000H to 00FFH) within the block, stored as an unsigned short integer. Multiple values shall be in increasing order and a given value shall be listed at most once. Required if Block Identifying Information Status (0008,0303) equals MIXED.
>Deidentification Action Sequence	(0008,0305)	3	Actions to be performed on element within the block that are not safe from identify leakage. One or more Items are permitted in this Sequence.
>>Identifying Private Elements	(0008,0306)	1	List of Private Data Elements in block that may contain identifying information (are unsafe from identity leakage).. Elements are identified by the lowest 8-bits of the attribute tag (i.e. with a value from 0000H to 00FFH) within the block, stored as an unsigned short integer. Multiple values shall be in increasing order and a given value shall be listed at most once.
>>Deidentification Action	(0008,0307)	1	Recommended action to be performed during de-identification on elements listed in Identifying Private Elements (0008,0306) within this Item. Note A specific type of action is suggested in order to minimize the impact of de-identification on the behavior of recipients that use the Private Data Elements. Enumerated Values: D replace with a non-zero length value that may be a dummy value and consistent with the VR Z replace with a zero length value, or a non-zero length value that may be a dummy value and consistent with the VR X remove U replace with a non-zero length UID that is internally consistent within a set of Instance Note No C (clean) action is specified, since replacement with values of similar meaning known not to contain identifying information and consistent with the VR requires an understanding of the meaning of the value of the element. Whether or not to clean rather than remove or replace values is at the discretion of the implementer. No suggested dummy value is provided, since the encoding of the value would depend on the VR of the data element. Further explanation of these actions can be found in PS3.15 Section E.3.1 Clean Pixel Data Option.

Note

If Issuer of Patient ID (0010,0021) is included in the Modified Attribute Sequence, the context of the prior Patient ID (0010,0020) can be more precisely identified.

C.12.1.1 SOP Common Attribute Descriptions

C.12.1.1.1 SOP Class UID, SOP Instance UID

The SOP Class UID and SOP Instance UID Attributes are defined for all DICOM IODs. However, they are only encoded in Composite IODs with the Type equal to 1. See Section C.1.2.3. When encoded they shall be equal to their respective Attributes in the DIMSE Services and the File Meta Information header (see PS3.10 Media Storage).

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, LT, UC or UT. See PS3.5.

If the Attribute Specific Character Set (0008,0005) is not present or has only a single value, Code Extension techniques are not used. Defined Terms for the Attribute Specific Character Set (0008,0005), when single valued, are derived from the International Registration Number as per ISO 2375 (e.g., ISO_IR 100 for Latin alphabet No. 1). See Table C.12-2.

Table C.12-2. Defined Terms for Single-Byte Character Sets Without Code Extensions

Character Set Description	Defined Term	ISO Registration Number	Number of Characters	Code Element	Character Set
Default repertoire	none	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 1	ISO_IR 100	ISO-IR 100	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 1	ISO_IR 100	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 2	ISO_IR 101	ISO-IR 101	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 2	ISO_IR 101	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 3	ISO_IR 109	ISO-IR 109	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 3	ISO_IR 109	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 4	ISO_IR 110	ISO-IR 110	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 4	ISO_IR 110	ISO-IR 6	94	G0	ISO 646
Cyrillic	ISO_IR 144	ISO-IR 144	96	G1	Supplementary set of ISO 8859
Cyrillic	ISO_IR 144	ISO-IR 6	94	G0	ISO 646
Arabic	ISO_IR 127	ISO-IR 127	96	G1	Supplementary set of ISO 8859
Arabic	ISO_IR 127	ISO-IR 6	94	G0	ISO 646
Greek	ISO_IR 126	ISO-IR 126	96	G1	Supplementary set of ISO 8859
Greek	ISO_IR 126	ISO-IR 6	94	G0	ISO 646
Hebrew	ISO_IR 138	ISO-IR 138	96	G1	Supplementary set of ISO 8859
Hebrew	ISO_IR 138	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 5	ISO_IR 148	ISO-IR 148	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 5	ISO_IR 148	ISO-IR 6	94	G0	ISO 646
Japanese	ISO_IR 13	ISO-IR 13	94	G1	JIS X 0201: Katakana
Japanese	ISO_IR 13	ISO-IR 14	94	G0	JIS X 0201: Romaji
Thai	ISO_IR 166	ISO-IR 166	88	G1	TIS 620-2533 (1990)
Thai	ISO_IR 166	ISO-IR 6	94	G0	ISO 646

Note

To use the single-byte code table of JIS X0201, the value of attribute Specific Character Set (0008,0005), value 1 should be ISO_IR 13. This means that ISO-IR 13 is designated as the G1 code element, which is invoked in the GR area. It should be understood that, in addition, ISO-IR 14 is designated as the G0 code element and this is invoked in the GL area.

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 PS3.5. In order to indicate the presence of Code Extension, the Defined Terms for the repertoires have the prefix "ISO 2022", e.g., ISO 2022 IR 100 for the Latin Alphabet No. 1. See Table C.12-3 and Table C.12-4. Table C.12-3 describes single-byte character sets for value 1 to value n of the attribute Specific Character Set (0008,0005), and Table C.12-4 describes multi-byte character sets for value 2 to value n of the attribute Specific Character Set (0008,0005).

Note

A prefix other than "ISO 2022" may be needed in the future if other Code Extension techniques are adopted.

The same character set shall not be used more than once in Specific Character Set (0008,0005).

Note

For example, the values "ISO 2022 IR 100\ISO 2022 IR 100" or "ISO_IR 100\ISO 2022 IR 100" are redundant and not permitted.

Table C.12-3. Defined Terms for Single-Byte Character Sets with Code Extensions

Character Set Description	Defined Term	Standard for Code Extension	ESC Sequence	ISO Registration Number	Number of Characters	Code Element	Character Set
Default repertoire	ISO 2022 IR 6	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 1	ISO 2022 IR 100	ISO 2022	ESC 02/13 04/01	ISO-IR 100	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 1	ISO 2022 IR 100	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 2	ISO 2022 IR 101	ISO 2022	ESC 02/13 04/02	ISO-IR 101	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 2	ISO 2022 IR 101	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 3	ISO 2022 IR 109	ISO 2022	ESC 02/13 04/03	ISO-IR 109	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 3	ISO 2022 IR 109	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 4	ISO 2022 IR 110	ISO 2022	ESC 02/13 04/04	ISO-IR 110	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 4	ISO 2022 IR 110	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Cyrillic	ISO 2022 IR 144	ISO 2022	ESC 02/13 04/12	ISO-IR 144	96	G1	Supplementary set of ISO 8859
Cyrillic	ISO 2022 IR 144	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Arabic	ISO 2022 IR 127	ISO 2022	ESC 02/13 04/07	ISO-IR 127	96	G1	Supplementary set of ISO 8859
Arabic	ISO 2022 IR 127	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Greek	ISO 2022 IR 126	ISO 2022	ESC 02/13 04/06	ISO-IR 126	96	G1	Supplementary set of ISO 8859
Greek	ISO 2022 IR 126	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Hebrew	ISO 2022 IR 138	ISO 2022	ESC 02/13 04/08	ISO-IR 138	96	G1	Supplementary set of ISO 8859
Hebrew	ISO 2022 IR 138	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Latin alphabet No. 5	ISO 2022 IR 148	ISO 2022	ESC 02/13 04/13	ISO-IR 148	96	G1	Supplementary set of ISO 8859
Latin alphabet No. 5	ISO 2022 IR 148	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646
Japanese	ISO 2022 IR 13	ISO 2022	ESC 02/0 9 04/09	ISO-IR 13	94	G1	JIS X 0201: Katakana
Japanese	ISO 2022 IR 13	ISO 2022	ESC 02/08 04/10	ISO-IR 14	94	G0	JIS X 0201: Romaji
Thai	ISO 2022 IR 166	ISO 2022	ESC 02/13 05/04	ISO-IR 166	88	G1	TIS 620-2533 (1990)
Thai	ISO 2022 IR 166	ISO 2022	ESC 02/08 04/02	ISO-IR 6	94	G0	ISO 646

Note

If the attribute Specific Character Set (0008,0005) has more than one value and value 1 is empty, it is assumed that value 1 is ISO 2022 IR 6.

Table C.12-4. Defined Terms for Multi-Byte Character Sets with Code Extensions

Character Set Description	Defined Term	Standard for Code Extension	ESC Sequence	ISO Registration Number	Number of Characters	Code Element	Character Set
Japanese	ISO 2022 IR 87	ISO 2022	ESC 02/04 04/02	ISO-IR 87	942	G0	JIS X 0208:Kanji
Japanese	ISO 2022 IR 159	ISO 2022	ESC 02/04 02/08 04/04	ISO-IR 159	942	G0	JIS X 0212: Supplementary Kanji set
Korean	ISO 2022 IR 149	ISO 2022	ESC 02/04 02/09 04/03	ISO-IR 149	942	G1	KS X 1001: Hangul and Hanja
Simplified Chinese	ISO 2022 IR 58	ISO 2022	ESC 02/04 02/09 04/01	ISO-IR 58	6,763	G1	GB 2312-80 China Association for Standardization

There are multi-byte character sets that prohibit the use of Code Extension Techniques. The following multi-byte character sets prohibit the use of Code Extension Techniques:

The Unicode character set used in ISO 10464, when encoded in UTF
The GB18030 character set, when encoded per the rules of GB18030
The GBK character set encoded per the rules of GBK

These character sets may only be specified as value 1 in the Specific Character Set (0008,0005) attribute and there shall only be one value. The minimal length UTF-8 encoding shall always be used for ISO 10646.

Note

The ISO standards for 10646 now prohibit the use of anything but the minimum length encoding for UTF-8. UTF-8 permits multiple different encodings, but when used to encode Unicode characters in accordance with ISO 10646-1 and 10646-2 (with extensions) only the minimal encodings are legal.
The representation for the characters in the DICOM Default Character Repertoire is the same single byte value for the Default Character Repertoire, ISO 10646 in UTF-8, GB18030 and GBK. It is also the 7-bit US-ASCII encoding.
The GBK character set is a subset of the GB18030 character set, which is restricted in its one- and two-byte code points. In this subset, the GBK character set follows the exactly same encoding rules of GB18030.

Table C.12-5. Defined Terms for Multi-Byte Character Sets Without Code Extensions

Character Set Description	Defined Term
Unicode in UTF-8	ISO_IR 192
GB18030	GB18030
GBK	GBK

C.12.1.1.3 Digital Signatures Macro

This Macro allows Digital Signatures to be included in a DICOM Data Set for the purpose of insuring the integrity of the Data Set, and to authenticate the sources of the Data Set. Table C.12-6 defines the Attributes needed to embed a Digital Signature in a Data Set. This Macro may appear in individual sequence items as well as in the main Data Set of the SOP Instance.

Note

Each Item of a Sequence of Items is a Data Set. Thus, individual Sequence items may incorporate their own Digital Signatures in addition to any Digital Signatures added to the Data Set in which the Sequence appears.
The inclusion of this Macro in Sequence Items, other than as specified in this Part of the Standard, may be specified in an application-defined Standard Extended SOP Class or Private SOP Class (see PS3.2).

Table C.12-6. Digital Signatures Macro Attributes

Attribute Name	Tag	Type	Attribute Description
MAC Parameters Sequence	(4FFE,0001)	3	A sequence of items that describe the parameters used to calculate a MAC for use in Digital Signatures. One or more Items shall be included in this Sequence.
>MAC ID Number	(0400,0005)	1	A number, unique within this SOP Instance, used to identify this MAC Parameters Sequence (4FFE,0001) item from an Item of the Digital Signatures Sequence (FFFA,FFFA).
>MAC Calculation Transfer Syntax UID	(0400,0010)	1	The Transfer Syntax UID used to encode the values of the Data Elements included in the MAC calculation. Only Transfer Syntaxes that explicitly include the VR and use Little Endian encoding shall be used. Note Certain Transfer Syntaxes, particularly those that are used with compressed data, allow the fragmentation of the pixel data to change. If such fragmentation changes, Digital Signatures generated with such Transfer Syntaxes could become invalid.
>MAC Algorithm	(0400,0015)	1	The algorithm used in generating the MAC to be encrypted to form the Digital Signature. Defined Terms: RIPEMD160 MD5 SHA1 SHA256 SHA384 SHA512 Note Digital Signature Security Profiles (see PS3.15) may require the use of a restricted subset of these terms.
>Data Elements Signed	(0400,0020)	1	A list of Data Element Tags in the order they appear in the Data Set that identify the Data Elements used in creating the MAC for the Digital Signature. See Section C.12.1.1.3.1.1.
Digital Signatures Sequence	(FFFA,FFFA)	3	Sequence holding Digital Signatures. One or more Items are permitted in this Sequence.
>MAC ID Number	(0400,0005)	1	A number used to identify which MAC Parameters Sequence item was used in the calculation of this Digital Signature.
>Digital Signature UID	(0400,0100)	1	A UID that can be used to uniquely reference this signature.
>Digital Signature DateTime	(0400,0105)	1	The date and time the Digital Signature was created. The time shall include an offset (i.e., time zone indication) from Coordinated Universal Time. Note This is not a certified timestamp, and hence is not completely verifiable. An application can compare this date and time with those of other signatures and the validity date of the certificate to gain confidence in the veracity of this date and time.
>Certificate Type	(0400,0110)	1	The type of certificate used in (0400,0115). Defined Terms: X509_1993_SIG Note Digital Signature Security Profiles (see PS3.15) may require the use of a restricted subset of these terms.
>Certificate of Signer	(0400,0115)	1	A certificate that holds the identity of the entity producing this Digital Signature, that entity's public key or key identifier, and the algorithm and associated parameters with which that public key is to be used. Algorithms allowed are specified in Digital Signature Security Profiles (see PS3.15). Note As technology advances, additional encryption algorithms may be allowed in future versions. Implementations should take this possibility into account. When symmetric encryption is used, the certificate merely identifies which key was used by which entity, but not the actual key itself. Some other means (e.g., a trusted third party) must be used to obtain the key.
>Signature	(0400,0120)	1	The MAC generated as described in Section C.12.1.1.3.1.1 and encrypted using the algorithm, parameters, and private key associated with the Certificate of the Signer (0400,0115). See Section C.12.1.1.3.1.2.
>Certified Timestamp Type	(0400,0305)	1C	The type of certified timestamp used in Certified Timestamp (0400,0310). Required if Certified Timestamp (0400,0310) is present. Defined Terms: CMS_TSP Internet X.509 Public Key Infrastructure Time Stamp Protocol Note Digital Signature Security Profiles (see PS3.15) may require the use of a restricted subset of these terms.
>Certified Timestamp	(0400,0310)	3	A certified timestamp of the Digital Signature (0400,0120) Attribute Value, which shall be obtained when the Digital Signature is created. See Section C.12.1.1.3.1.3.
>Digital Signature Purpose Code Sequence	(0400,0401)	3	The purpose of this Digital Signature. Only a single Item is permitted in this Sequence.
>>Include Table 8.8-1 “Code Sequence Macro Attributes”			Baseline CID 7007 “Signature Purpose”.

C.12.1.1.3.1 Digital Signature Attribute Descriptions

C.12.1.1.3.1.1 Data Elements Signed

The Data Elements Signed Attribute shall list the Tags of the Data Elements that are included in the MAC calculation. The Tags listed shall reference Data Elements at the same level as the Mac Parameters Sequence (4FFE,0001) Data Element in which the Data Elements Signed Attribute appears. Tags included in Data Elements Signed shall be listed in the order in which they appear within the Data Set.

The following Data Elements shall not be included either implicitly or explicitly in the list of Tags in Data Elements Signed, nor included as part of the MAC calculation:

The Length to End (0008,0001) or any Tag with an element number of 0000 (i.e., no data set or group lengths may be included in MAC calculations)
Tags with a group number less than 0008
Tags associated with Data Elements whose VR is UN
Tags of Data Elements whose VR is SQ, where any Data Element within that Sequence of Items has a VR of UN recursively
Tags with a group number of FFFA (e.g., the Digital Signatures Sequence)
MAC Parameters Sequence (4FFE,0001)
Data Set Trailing Padding (FFFC,FFFC)
Item Delimitation Item (FFFE,E00D)

Note

The Length to End and group lengths can change if non-signed Data Elements change, so it is not appropriate to include them in the MAC calculation.
Since the Data Element Tags that identify a sequence and the start of each item are included in the MAC calculation, there is no need to include the Item Delimitation Item Tags.

If any of the Data Element Tags in the list refer to a Sequence of Items, then the Tags of all Data Elements within all Items of that Sequence shall be implicitly included in the list of Data Elements Signed, except those disallowed above. This implicit list shall also include the Item Tag (FFFE,E000) Data Elements that separate the Sequence Items and the Sequence Delimitation Item (FFFE,E0DD).

Note

It is possible to sign individual items within a sequence by including the Digital Signatures Macro in that sequence item. In fact, this is a highly desirable feature, particular when used in the context of reports. The Digital Signatures Macro is applied at the Data Set level, and Sequences of Items are merely Data Sets embedded within a larger Data Set. Essentially, the Digital Signature Macro may be applied recursively.

An example of nesting Digital Signatures within Data Elements is illustrated in Figure C.12-1.

Figure C.12-1. Example of Nesting Digital Signatures (Informative)

In this example, there is main signature covering the pixel data and a few other Data Elements, plus two individually signed items within a sequence.

For Data Elements with a VR OB (e. g. pixel data) that have an undefined length (i.e., the data is encapsulated as described in PS3.5), the Item Data Element Tags that separate the fragments shall implicitly be included in the list of Data Elements Signed (i.e., a Data Element with a VR of OB is encoded in the same fashion as a Sequence of Items).

C.12.1.1.3.1.2 Signature

To generate the MAC, Data Elements referenced either explicitly or implicitly by the Tags in the Data Elements Signed list shall be encoded using the Transfer Syntax identified by the MAC Calculation Transfer Syntax UID (0400,0010) of the MAC Parameters Sequence item where the Data Elements Signed Attribute appears. Data shall be formed into a byte stream and presented to the MAC Algorithm for computation of the MAC according to the following rules:

For all Data Elements except those with a VR of SQ or with a VR of OB with an undefined length, all Data Element fields, including the Tag, the VR, the reserved field (if any), the Value Length, and the Value, shall be placed into the byte stream in the order encountered.

For Data Elements with a VR of SQ or with a VR of OB with an undefined length, the Tag, the VR, and the reserved field are placed into the byte stream. The Value Length shall not be included. This is followed by each Item Tag in the order encountered, without including the Value Length, followed by the contents of the Value for that item. In the case of an Item within a Data Element whose VR is SQ, these rules are applied recursively to all of the Data Elements within the Value of that Item. After all the Items have been incorporate into the byte stream, a Sequence Delimitation Item Tag (FFFE,E0DD) shall be added to the byte stream presented to the MAC Algorithm, regardless of whether or not it was originally present.

Note

Since the Value Length of Data Elements with a VR of SQ can be either explicit or undefined, the Value Lengths of such Data Elements are left out of the MAC calculation. Similarly, the Value Length of Data Elements with a VR of OB with an undefined length are also left out so that they are handled consistently. If such Data Elements do come with undefined lengths, including the Item Tags that separate the Items or fragments insures that Data Elements cannot be moved between Items or Fragments without compromising the Digital Signature. For those Data Elements with explicit lengths, if the length of an item changes, the added or removed portions would also impact the MAC calculation, so it is not necessary to include explicit lengths in the MAC calculation. It is possible that including the Value Lengths could make cryptanalysis easier.

After the fields of all the Data Elements in the Data Elements Signed list have been placed into the byte stream presented to the MAC Algorithm according to the above rules, all of the Data Elements within the Digital Signatures Sequence item except the Certificate of Signer (0400,0115), Signature (0400,0120), Certified Timestamp Type (0400,0305), and Certified Timestamp (0400,0310) shall also be encoded according to the above rules, and presented to the MAC algorithm (i.e., the Attributes of the Digital Signature Sequence Item for this particular Digital Signature are also implicitly included in the list of Data Elements Signed, except as noted above).

The resulting MAC code after processing this byte stream by the MAC Algorithm is then encrypted as specified in the Certificate of Signer and placed in the Value of the Signature Data Element.

Note

The Transfer Syntax used in the MAC calculation may differ from the Transfer Syntax used to exchange the Data Set.
Digital Signatures require explicit VR in order to calculate the MAC. An Application Entity that receives a Data Set with an implicit VR Transfer Syntax may not be able to verify Digital Signatures that include Private Data Elements or Data Elements unknown to that Application Entity. This also true of any Data Elements whose VR is UN. Without knowledge of the Value Representation, the receiving Application Entity would be unable to perform proper byte swapping or be able to properly parse sequences in order to generate a MAC.
If more than one entity signs, each Digital Signature would appear in its own Digital Signatures Sequence item. The Digital Signatures may or may not share the same MAC Parameters Sequence item.
The notion of a notary public (i.e., someone who verifies the identity of the signer) for Digital Signatures is partially filled by the authority that issued the Certificate of Signer.

C.12.1.1.3.1.3 Certified Timestamp

To generate a certified timestamp, the Value of the Signature (0400,0120) Attribute is sent to a third party, as specified by the protocol referred to by the Certified Timestamp Type (0400,0305) Attribute. The third party then generates and returns a certified timestamp in the form specified by that protocol. The certified timestamp returned by the third party is encoded as a stream of bytes in the Certified Timestamp Attribute.

Note

The timestamp protocol may be specified by a Profile in PS3.15.

C.12.1.1.4 Encrypted Attribute Descriptions

C.12.1.1.4.1 Encrypted Attributes Sequence

Each Item of the Encrypted Attributes Sequence (0400,0500) contains an encrypted DICOM Data Set containing a single instance of the Encrypted Attributes Data Set (Table C.12-7). It also contains encrypted content-encryption keys for one or more recipients. The encoding is based on the Enveloped-data Content Type of the Cryptographic Message Syntax defined in RFC 2630. It allows to encrypt the embedded Data Set for an arbitrary number of recipients using any of the three key management techniques supported by RFC 2630:

Key Transport: the content-encryption key is encrypted in the recipient's public key;
Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key, then the content-encryption key is encrypted in the pairwise symmetric key; and
Symmetric key-encryption Keys: the content-encryption key is encrypted in a previously distributed symmetric key-encryption key.

A recipient decodes the embedded Encrypted Attributes Data Set by decrypting one of the encrypted content-encryption keys, decrypting the encrypted Data Set with the recovered content-encryption key, and then decoding the DICOM Data Set using the Transfer Syntax specified in Encrypted Content Transfer Syntax UID (0400,0510).

Multiple Items may be present in the Encrypted Attributes Sequence. The different Items may contain Encrypted Attributes Data Sets with the same or different sets of Attributes and may contain encrypted content-encryption keys for the same or different sets of recipients. However, if the same Attribute is contained in more than one embedded Encrypted Attributes Data Set, the value of the Attribute must be identical in all embedded Encrypted Attributes Data Sets in which the Attribute is contained.

Note

If the Encrypted Attributes Sequence contains more than one Item, and a recipient holds the key for more than one of the items, the recipient may either decode any single one or more of the embedded Data Sets at its own discretion. Since the same Attribute is required to have the same value in all embedded Encrypted Attributes Data Sets, it is safe to "overlay" multiple embedded Encrypted Attributes Data Sets in an arbitrary order upon decoding.

C.12.1.1.4.2 Encrypted Content

Encrypted Content (0400,0520) contains an Enveloped-data content type of the cryptographic message syntax defined in RFC 2630. The encrypted content of the Enveloped-data content type is an instance of the Encrypted Attributes Data Set as shown in Table C.12-7 (i.e., it is a Sequence with a single Item), encoded with the Transfer Syntax specified by the Encrypted Content Transfer Syntax UID (0400,0510) Attribute. Figure C.12-2 shows an example of how the Encrypted Content is encoded. The exact use of this Data Set is defined in the Attribute Confidentiality Profiles in PS3.15.

Since the de-identified SOP Instance is a significantly altered version of the original Data Set, it is a new SOP Instance, with a SOP Instance UID that differs from the original Data Set.

Note

Content encryption may require that the content (the DICOM Data Set) be padded to a multiple of some block size. This shall be performed according to the Content-encryption Process defined in RFC-2630.
Any standard or private Transfer Syntax may be specified in Encrypted Content Transfer Syntax UID (0400,0510) unless encoding is performed in accordance with an Attribute Confidentiality Profile that specifies additional restrictions. In general, an application entity decoding the Encrypted Attributes Sequence may not assume any particular Transfer Syntax or set of Transfer Syntaxes to be used with Encrypted Content Transfer Syntax UID (0400,0510).
For certain applications it might be necessary to "blacken" (remove) identifying information that is burned in to the image pixel data. The Encrypted Attributes Data Set does not specify a means of restoring the original image information without the complete image pixel data being encoded inside the Modified Attributes Sequence (0400,0550). If access to the original, unmodified pixel data is required and the image pixel data cannot be replicated inside the Modified Attributes Sequence (0400,0550) due to resource considerations, the SOP Instance UID may be used to locate the original SOP Instance from which the de-identified version was derived.
There is no guarantee that the original SOP Instance can be reconstructed from the data in Encrypted Content. If access to the original data is required, the (de-encrypted) UIDs may be used to locate the original SOP Instance from which the de-identified version was derived.

Table C.12-7. Encrypted Attributes Data Set Attributes

Attribute Name	Tag	Type	Attribute Description
Modified Attributes Sequence	(0400,0550)	1	Sequence of Items containing all Attributes that were removed or replaced by "dummy values" in the main Data Set during de-identification of the SOP instance. Upon reversal of the de-identification process, the Attributes are copied back into the main Data Set, replacing any dummy values that might have been created. Only a single Item shall be included in this Sequence.
> Any Attribute from the main Data Set that was modified or removed during the de-identification process.	3

Attribute Name

Tag

Type

Attribute Description

Modified Attributes Sequence

(0400,0550)

Sequence of Items containing all Attributes that were removed or replaced by "dummy values" in the main Data Set during de-identification of the SOP instance. Upon reversal of the de-identification process, the Attributes are copied back into the main Data Set, replacing any dummy values that might have been created.

Only a single Item shall be included in this Sequence.

> Any Attribute from the main Data Set that was modified or removed during the de-identification process.

Figure C.12-2. Example of Encoding of Encrypted Attributes Data Set (Informative)

C.12.1.1.5 Contributing Equipment Sequence

Contributing Equipment Sequence (0018,A001) allows equipment that has contributed towards the creation of the composite instance to be described. The general class of contribution is denoted via a coded entry within the Purpose of Reference Code Sequence (0040,A170).

Note

For example, a post-processing application creating DERIVED images from ORIGINAL images would place its own identification within the General Equipment Module and identify the original acquisition equipment as an Item within the Contributing Equipment Sequence (0018,A001). Here, the value of Purpose of Reference Code Sequence (0040,A170) within the Item would be (109101, DCM, "Acquisition Equipment"). Image display applications wishing to annotate images with information related to the acquisition environment would prefer to extract such details from the Contributing Equipment Sequence rather than the General Equipment Module.
For example, an image fusion application would place its own identification within the General Equipment Module and identify each of the original acquisition equipment as separate Items within the Contributing Equipment Sequence (0018,A001). Here, the value of Purpose of Reference Code Sequence (0040,A170) within each Item would be (109101, DCM, "Acquisition Equipment").
For example, a post-processing application creating DERIVED images from other DERIVED images would place its own identification within the General Equipment Module and add the source equipment as an additional Item within the Contributing Equipment Sequence (0018,A001). Here, the value of Purpose of Reference Code Sequence (0040,A170) within the Item would be (109102, DCM, "Processing Equipment").
For example, a gateway device that coerces attributes of existing composite instances (without creating new composite instances) would retain information about the creating equipment within the General Equipment Module and provide its own identification as an Item within the Contributing Equipment Sequence (0018,A001). Here, the value of Purpose of Reference Code Sequence (0040,A170) within the Item would be (109103, DCM, "Modifying Equipment").
For example, equipment that has been used for de-identifying could retain information about the creating equipment within the General Equipment Module and provide its own identification, and that of its operator, as an Item within Contributing Equipment Sequence (0018,A001). Here, the value of Purpose of Reference Code Sequence (0040,A170) within the Item would be (109104, DCM, "De-identifying Equipment").

C.12.1.1.6 HL7 Structured Document Reference Sequence

The HL7 Structured Document Reference Sequence (0040,A390) identifies instances of Structured Documents defined under an HL7 standard. The HL7 standards that define such documents include the Clinical Document Architecture (CDA) and Structured Product Labeling (SPL) standards.

References to unencapsulated HL7 Structured Documents from within DICOM SOP Instances shall be encoded with a SOP Class UID and SOP Instance UID pair. The Abstract Syntax of an HL7 Structured Document is defined by its Hierarchical Message Description; the Object Identifier of the Hierarchical Message Description shall be used as the SOP Class UID for the Structured Document reference.

Note

The Hierarchical Message Description Object Identifiers are specified in the HL7 OID Registry ( http://hl7.org/oid). The HL7 OIDs for these types of documents are: CDA Release 1 2.16.840.1.113883.1.7.1 CDA Release 2 2.16.840.1.113883.1.7.2 SPL Release 1 2.16.840.1.113883.1.7.3
The Hierarchical Message Description Object Identifiers do not imply a network or media storage service, as do SOP Class UIDs. However, they do identify the Abstract Syntax, similar to SOP Class UIDs.

The HL7 Structured Document instances are natively identified by an attribute using the Instance Identifier (II) Data Type, as defined in HL7 v3 Data Types - Abstract Specification. A UID as defined by the DICOM UI Value Representation is a valid identifier under the II Data Type; however, an II attribute is not always encodable as a UID. Therefore a UID shall be constructed for use within the DICOM Data Set that can be mapped to the native instance identifier encoded as an HL7 II Data Type. This mapping is performed through the combination of the local Referenced SOP Instance UID (0008,1155) and the HL7 Instance Identifier (0040,E001) attributes in the HL7 Structured Document Reference Sequence (0040,A390).

Note

An HL7 II is not encodable as a UID if it exceeds 64 characters, or if it includes an extension. See HL7 v3 DT R1.
Even though an II may contain just a UID, applications should take care to use the II specified in HL7 Instance Identifier (0040,E001) to access the Structured Document. If the instance identifier used natively within the referenced document is encodable using the UI VR, i.e., it is an ISO 8824 OID up to 64 characters without an extension, it is recommended to be used as the Referenced SOP Instance UID within the current Instance.
The Referenced SOP Instance UID used to reference a particular HL7 Structured Document is not necessarily the same in all DICOM Instances. For example, two SR Documents may internally use different SOP Instance UIDs to reference the same HL7 Structured Document, but they will each contain a mapping to the same HL7 Instance Identifier as the external identifier.
The HL7 Instance Identifier is encoded in attribute (0040,E001) as a serialization of the UID and Extension (if any) separated by a caret character. This is the same format adopted in the IHE Cross-Enterprise Document Sharing (XDS) profile (see http://www.ihe.net/).
See Figure C.12-3.

Figure C.12-3. HL7 Structured Document References

C.12.1.1.7 Private Data Element Characteristics

The creator of the private Data Elements (identified by the value of Private Creator Reference (0008,0302) ) is responsible for managing the Private Data Element Tags associated with them and ensuring that the Private Data Element (0008,0308) and the Private Data Element Keyword (0008,030D) are a unique pair, and that the other associated details in the Data Element Definition Macro are consistent.

Implementers are encouraged to describe all Private Data Elements in the Private Data Element Characteristics Sequence (0008,0300).

Note

The Private Data Element Characteristics Sequence (0008,0300) may describe Data Elements that are referenced in the current SOP Instance (for example they may be identified as a Selector Attribute), but do not exist as actual Data Elements in the current SOP Instance.

C.12.1.1.7.1 Private Data Element Value Multiplicity

For data elements with a fixed multiplicity, this attribute shall contain a single integer value, e.g., 3.

For data elements with a variable multiplicity, this attribute contains either two or three values. The first value is the minimum multiplicity, the second value is the maximum multiplicity. If the maximum multiplicity is open-ended, 0 is used. The third value, if present, is the "stride", i.e. the increment between valid multiplicity values. A stride is used when values are added in sets, such as an x/y/z set of coordinate values that is recorded in triplets.If the stride is 1, the third value may be omitted. The stride is not permitted to be 0.

Examples:

VM of 1-3 is expressed as 1,3 or 1,3,1 meaning the multiplicity is permitted to be 1, 2 or 3
VM of 1-n is expressed as 1,0 or 1,0,1
VM of 0-n is expressed as 0,0 or 0,0,1
VM of 3-3n is expressed as 3,0,3

For a Private Data Element Value Representation (0008,030A) of SQ, the multiplicity shall be 1 and the allowed number of items in a sequence is recorded in Private Data Element Number of Items(0008,030B).

C.12.1.1.7.2 Private Data Element Number of Items

For sequences that permit a fixed number of Items, this attribute shall contain a single integer value, e.g., 3.

For sequences with a variable number of Items, this attribute contains two values. The first value is the minimum number of Items, the second value is the maximum number of Items. If the maximum number of Items is open-ended, 0 is used.

C.12.1.1.8 Timezone Offset From UTC

Encoded as an ASCII string in the format "&ZZXX". The components of this string, from left to right, are & = "+" or "-", and ZZ = Hours and XX = Minutes of offset. Leading space characters shall not be present.

The offset for UTC shall be +0000; -0000 shall not be used.

Note

This encoding is the same as described in PS3.5 for the offset component of the DT Value Representation.
This Attribute does not apply to values with a DT Value Representation, that contains an explicitly encoded timezone offset.
The corrected time may cross a 24 hour boundary. For example, if Local Time = 1.00 a.m. and Offset = +0200, then UTC = 11.00 p.m. (23.00) the day before.
The "+" sign may not be omitted.

Time earlier than UTC is expressed as a negative offset.

Note

For example:

UTC = 5.00 a.m.

Local Time = 3.00 a.m.

Offset = -0200

Prev	Up	Next
C.11.29 Presentation Animation Module	Home	C.12.2 Common Instance Reference Module