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 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 PS 3.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 or UT. See PS 3.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
ISO-IR 6 94 G0 ISO 646
Latin alphabet No. 2 ISO_IR 101 ISO-IR 101 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Latin alphabet No. 3 ISO_IR 109 ISO-IR 109 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Latin alphabet No. 4 ISO_IR 110 ISO-IR 110 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Cyrillic ISO_IR 144 ISO-IR 144 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Arabic ISO_IR 127 ISO-IR 127 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Greek ISO_IR 126 ISO-IR 126 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Hebrew ISO_IR 138 ISO-IR 138 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Latin alphabet No. 5 ISO_IR 148 ISO-IR 148 96 G1 Supplementary set of ISO 8859
ISO-IR 6 94 G0 ISO 646
Japanese ISO_IR 13 ISO-IR 13 94 G1 JIS X 0201: Katakana
ISO-IR 14 94 G0 JIS X 0201: Romaji
Thai ISO_IR 166 ISO-IR 166 88 G1 TIS 620-2533 (1990)
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 PS 3.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 12-3 and Table 12-4. Table 12-3 describes single-byte character sets for value 1 to value n of the attribute Specific Character Set (0008,0005), and Table 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-3DEFINED 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 char-acters 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
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
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
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
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
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
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
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
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
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
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)
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-4DEFINED 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 char-acters 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
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

There are multi-byte character sets that prohibit the use of Code Extension Techniques. The Unicode character set used in ISO 10646, when encoded in UTF-8, and the GB18030 character set, encoded per the rules of GB18030, both prohibit the use of Code Extension Techniques. 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.

Notes: 1. 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.

2. 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, and GB18030. It is also the 7-bit US-ASCII encoding.

Table C.12-5DEFINED TERMS FOR MULTI-BYTE CHARACTER SETS WITHOUT CODE EXTENSIONS

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

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.

Notes: 1. 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.

2. 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-6DIGITAL 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. Notes: 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 PS 3.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 which 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 Term: X509_1993_SIG Note: Digital Signature Security Profiles (see PS 3.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 PS 3.15). Notes: 1. As technology advances, additional encryption algorithms may be allowed in future versions. Implementations should take this possibility into account. 2. 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.1and 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 the Certified Timestamp (0400,0310) Attribute. 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 PS 3.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 ‘Code Sequence Macro’ Table 8.8-1 Baseline CID 7007

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:

Notes: 1. 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.

2. Since the Data Element Tags identifying a sequence and which start 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).

Notes: 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 the following figure:

[pic]

Figure C.12-1Example 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 PS 3.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 cryptoanalysis 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.

Notes: 1. The Transfer Syntax used in the MAC calculation may differ from the Transfer Syntax used to exchange the Data Set.

2. Digital Signatures require explicit VR in order to calculate the MAC. An Application Entity which 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.

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

4. 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 PS 3.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 dataset 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:

A recipient decodes the embedded Encrypted Attributes Data Set by decrypting one of the encrypted content-encryption keys, decrypting the encrypted dataset with the recovered content-encryption key, and then decoding the DICOM dataset 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

The Encrypted Content (0400,0520) Attribute 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 PS 3.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: 1. 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.

2. 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).

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

4. 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-7ENCRYPTED 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 dataset during de-identification of the SOP instance. Upon reversal of the de-identification process, the Attributes are copied back into the main dataset, replacing any dummy values that might have been created. Only a single Item shall be included in this sequence.
> Any Attribute from the main dataset that was modified or removed during the de-identification process. 3

[pic]

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

C.12.1.1.5 Contributing Equipment Sequence

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

Notes: 1. For example, a post-processing application creating DERIVED images from ORIGINAL images would place its own identification within the Equipment Module and identify the original acquisition equipment as an Item within the Contributing Equipment Sequence (0018,A001). Here, the value of the 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 Equipment Module.

2. For example, an image fusion application would place its own identification within the Equipment Module and identify each of the original acquisition equipment as separate Items within the Contributing Equipment Sequence (0018,A001). Here, the value of the Purpose of Reference Code Sequence (0040,A170) within each Item would be (109101, DCM, ”Acquisition Equipment").

3. For example, a post-processing application creating DERIVED images from other DERIVED images would place its own identification within the Equipment Module and add the source equipment as an additional Item within the Contributing Equipment Sequence (0018,A001). Here, the value of the Purpose of Reference Code Sequence (0040,A170) within the Item would be (109102, DCM, ”Processing Equipment").

4. 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 Equipment Module and provide its own identification as an Item within the Contributing Equipment Sequence (0018,A001). Here, the value of the Purpose of Reference Code Sequence (0040,A170) within the Item would be (109103, DCM, ”Modifying Equipment").

5. For example, equipment that has been used for de-identifying could retain information about the creating equipment within the 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 the 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.

Notes: 1. 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

2. 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).

Notes: 1. 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.

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

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

4. 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).

5. See Figure C.12-3.

[pic]

Figure C.12-3 HL7 Structured Document References