DICOM PS3.3 2024e - Information Object Definitions |
---|
The SOP Common Module shall be mandatory for all DICOM IODs.
Table C.12-1 specifies the Attributes of the SOP Common Module, which 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
Uniquely identifies the SOP Class. See Section C.12.1.1.1 for further explanation. See also PS3.4. |
|||
Uniquely identifies the SOP Instance. See Section C.12.1.1.1 for further explanation. See also PS3.4. |
|||
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. |
|||
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. |
|||
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. |
|||
Date and time that the SOP Instance was last coerced, corrected or converted by a Storage SCP (see Section B.4.1.3 “Coercion of Attributes” in PS3.4). |
|||
Uniquely identifies device that created the SOP Instance. NoteThere is no requirement that the Instance Creator UID (0008,0014) be the same as the Device UID (0018,1002) in the General Equipment Module, though they may be. |
|||
Uniquely identifies a Related General SOP Class for the SOP Class of this Instance. See PS3.4. |
|||
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. |
|||
Whether or not some or all of the content of this instance was made artificially rather than being a faithful representation of acquired data. Note
If data with a Synthetic Data (0008,001C) Value of YES is used to derive other content then it is expected that this derived content will also have a Synthetic Data (0008,001C) Value of YES. |
|||
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. |
|||
The value of a Coding Scheme Designator, used in this SOP Instance, which is being mapped. |
|||
The name of the external registry where further definition of the identified coding scheme may be obtained. Required if coding scheme is registered. |
|||
The coding scheme UID identifier. Required if coding scheme is identified by an ISO 8824 object identifier compatible with the UI VR. |
|||
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. |
|||
The coding scheme version associated with the Coding Scheme Designator (0008,0102). |
|||
Name of the organization responsible for the Coding Scheme. May include organizational contact information. |
|||
The type of the resource related to the coding scheme at the Coding Scheme URL (0008,010E). Defined Terms:
|
|||
Sequence of Items that map values of Context Identifier (0008,010F) to an external, private or local Context Group. |
|||
The identifier of the Context Group. See Section 8.6. |
|||
The unique identifier of the Context Group. See Section 8.6. |
|||
The identifier of the Mapping Resource that defines the Context Group. See Section 8.4. |
|||
The identifier of the version of the Context Group. See Section 8.5. |
|||
Sequence of Items that map values of Mapping Resource (0008,0105) to an external, private or local Mapping Resource. |
|||
The identifier of the Mapping Resource. See Section 8.4. |
|||
The name of the Mapping Resource. See Section 8.4. |
|||
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. The local timezone offset is undefined if this Attribute is absent. |
|||
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. |
|||
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. |
|||
Manufacturer of the equipment that contributed to the Composite Instance. |
|||
Institution where the equipment that contributed to the Composite Instance is located. |
|||
Address of the institution where the equipment that contributed to the Composite Instance is located. |
|||
User defined name identifying the machine that contributed to the Composite Instance. |
|||
Department in the institution where the equipment that contributed to the Composite Instance is located. |
|||
A coded description of the type of Department or Service within the healthcare facility. |
|||
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” |
|||
Manufacturer's model name of the equipment that contributed to the Composite Instance. |
|||
Manufacturer's serial number of the equipment that contributed to the Composite Instance. |
|||
Manufacturer's designation of the software version of the equipment that contributed to the Composite Instance. See Section C.7.5.1.1.3. |
|||
The date the equipment that contributed to the Composite Instance was originally manufactured or re-manufactured (as opposed to refurbished). |
|||
The date the equipment that contributed to the Composite Instance was installed in its current location. The equipment may or may not have been used prior to installation in its current location. |
|||
Unique identifier of the contributing equipment. NoteThere is no requirement that this Device UID (0018,1002) be the same as the Instance Creator UID (0008,0014) in the SOP Common Module, though it may be. |
|||
Unique Device Identifier (UDI) of the contributing equipment. One or more Items are permitted in this Sequence. Note
|
|||
>>Include Table 10.29-1 “UDI Macro Attributes” |
|||
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 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 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. |
|||
The Date & Time when the equipment contributed to the Composite Instance. |
|||
Description of the contribution the equipment made to the Composite Instance. |
|||
A flag that indicates the storage status of the SOP Instance. Enumerated Values:
|
|||
The date and time when the SOP Instance Status (0100,0410) was set to AO. |
|||
Any comments associated with the setting of the SOP Instance Status (0100,0410) to AO. |
|||
The certification number issued to the Application Entity that set the SOP Instance Status (0100,0410) to AO. |
|||
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. |
|||
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 data. See Section C.12.1.1.4.2. |
|||
Include Table C.12.1.1.9-1 “Original Attributes Macro Attributes” |
|||
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 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” |
|||
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). |
|||
Retrieval access path to HL7 Structured Document. Includes fully specified scheme, authority, path, and query in accordance with[RFC3986]. |
|||
Indicates whether or not the date and time Attributes in the Instance have been modified during de-identification. See Section E.2 “Basic Application Level Confidentiality Profile” in PS3.15 and Section E.3.6 “Retain Longitudinal Temporal Information Options” in PS3.15 . |
|||
The view requested during the C-MOVE operation that resulted in the transfer of this Instance. Required if the Instance has ever been converted from its source form as the result of a C-MOVE operation with a specific view. |
|||
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 from a DICOM source, 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 Indicator See Section C.8.13.2.1.1 for further explanation. |
|||
Characteristics of Private Data Elements within or referenced in the current SOP Instance. See Section C.12.1.1.7. |
|||
Odd group number within which the Private Data Element block is reserved. |
|||
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. NotePrivate 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. |
|||
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). |
|||
Value Multiplicity (VM) of the Data Element. See Section C.12.1.1.7.1. |
|||
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. |
|||
Keyword for the Data Element (in the sense of the keywords provided in PS3.6). |
|||
Description of the purpose and/or proper usage of the Data Element. |
|||
Description of how the Data Element value contents are encoded. |
|||
Retrieval access path to associated documentation. Includes fully specified scheme, authority, path, and query in accordance with [RFC3986]. |
|||
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. |
|||
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 Date Element 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. |
|||
Actions to be performed on element within the block that are not safe from identify leakage. |
|||
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 Data Element 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. |
|||
Recommended action to be performed during de-identification on elements listed in Identifying Private Elements (0008,0306) within this Item. NoteA 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:
Note
|
|||
Categorizes the locality of the entity from whence the Instance originated. See Section C.12.1.1.10. |
|||
Barcode interpreted from a scanned label. Note
|
|||
Include Table 10.41-1 “General Procedure Protocol Reference Macro Attributes” |
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).
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.
The Specific Character Set value does not indicate the character set version in use at the time of SOP Instance creation. Updates to character sets designated by a Specific Character Set value are expected to be backward compatible.
This Standard does not specify the language associated with a specific character set. Language and character set selection are defined by local and regulatory requirements.
Table C.12-2. Defined Terms for Single-Byte Character Sets Without Code Extensions
[JIS X 0201]: Katakana |
|||||
[JIS X 0201]: Romaji |
|||||
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).
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).
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
[JIS X 0201]: Katakana |
|||||||
[JIS X 0201]: Romaji |
|||||||
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
[JIS X 0208]: Kanji |
|||||||
[JIS X 0212]: Supplementary Kanji set |
|||||||
[KS X 1001]: Hangul and Hanja |
|||||||
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/IEC 10646], when encoded in UTF
The [GB 18030] character set, when encoded per the rules of [GB 18030]
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/IEC 10646].
[ISO/IEC 10646] now prohibits 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/IEC 10646] in UTF-8, [GB 18030] and [GBK]. It is also the 7-bit US-ASCII encoding.
The [GBK] character set is a subset of the [GB 18030] 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 [GB 18030].
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 top level Data Set of the SOP Instance.
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
A Sequence of Items that describe the parameters used to calculate a MAC for use in Digital Signatures. |
|||
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). |
|||
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. |
|||
The algorithm used in generating the MAC to be encrypted to form the Digital Signature. For Defined Terms, see Table C.12.1.1.3.1.2-1, “Defined Terms for MAC Algorithm (0400,0015)”. |
|||
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. |
|||
A number used to identify which MAC Parameters Sequence Item was used in the calculation of this Digital Signature. |
|||
A UID that can be used to uniquely reference this signature. |
|||
The date and time the Digital Signature was created. The time shall include an offset (i.e., time zone indication) from Coordinated Universal Time. |
|||
The type of certificate used in (0400,0115). NoteDigital Signature Security Profiles (see PS3.15) may require the use of a restricted subset of these terms. |
|||
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
|
|||
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. |
|||
The type of certified timestamp used in Certified Timestamp (0400,0310). Required if Certified Timestamp (0400,0310) is present. NoteDigital Signature Security Profiles (see PS3.15) may require the use of a restricted subset of these terms. |
|||
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. |
|||
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 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)
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).
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 Signatures Macro may be applied recursively.
An example of nesting Digital Signatures within Data Elements is illustrated in Figure C.12-1.
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).
To generate the MAC, Data Elements referenced either explicitly or implicitly by the Tags in the Data Elements Signed (0400,0020) list shall be encoded using the Transfer Syntax identified by the MAC Calculation Transfer Syntax UID (0400,0010) of the MAC Parameters Sequence (0400,0010) Item where the Data Elements Signed (0400,0020) Attribute appears. Data shall be formed into a byte stream and presented to the algorithm specified by MAC Algorithm (0400,0015) 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.
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.
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.
Table C.12.1.1.3.1.2-1 lists the Defined Terms for MAC Algorithm (0400,0015).
Table C.12.1.1.3.1.2-1. Defined Terms for MAC Algorithm (0400,0015)
NoteSee also security considerations in [RFC6151]. The use of MD5 is no longer recommended. |
|
Security Profiles (see PS3.15) may restrict or extend the list of MAC algorithms that are permitted or required by a specific profile.
To generate a certified timestamp, the Value of the Signature (0400,0120) Attribute is transmitted 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.
The timestamp protocol may be specified by a Profile in PS3.15.
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 IETF STD 70 [RFC5652]. It allows to encrypt the embedded Data Set for an arbitrary number of recipients using any of the three key management techniques supported by IETF STD 70 [RFC5652]:
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.
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.
Encrypted Content (0400,0520) contains an Enveloped-data content type of the cryptographic message syntax defined in IETF STD 70 [RFC5652]. 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.
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 IETF STD 70 [RFC5652].
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
Contributing Equipment Sequence (0018,A001) allows equipment that has contributed towards the creation of the Composite Instance to be described. Equipment encompasses both hardware (such as an acquisition device or a film digitizer or a workstation) and software (such as a de-identification tool or an AI model). The general class of contribution is denoted via a coded entry within the Purpose of Reference Code Sequence (0040,A170).
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").
In the case of processing equipment, further information about the algorithm(s) used may be found in invocations of the Table 10-19 Algorithm Identification Macro Attributes, or in SR instances, TID 4019 Algorithm Identification.
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.
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 value 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).
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 HL7 Instance Identifier (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 [IHE RAD TF-1].
See Figure C.12-3.
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 are consistent.
Implementers are encouraged to describe all Private Data Elements in the Private Data Element Characteristics Sequence (0008,0300).
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.
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.
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).
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.
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.
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.
Every transfer of a SOP Instance may result in Attribute coercion (see Section B.4.1.3 “Coercion of Attributes” in PS3.4) by the receiving application. The receiving application may also detect and correct errors in SOP Instances to bring them into conformance with the SOP Class definition without changing the SOP Instance UID or creating a derived Instance (see status Warning in Section 9.1.1.1.9 “Status” in PS3.7 and Section B.2.3 “Statuses” in PS3.4.
When performing coercion, correction or conversion, the application may set Instance Coercion DateTime (0008,0015) to the current datetime. When performing such actions, the application may add an Item to the Original Attributes Sequence (0400,0561) describing the change and the prior values of replaced or removed Attributes. Any existing Items in the Original Attributes Sequence shall be preserved.
Attributes may also be coerced, corrected or converted outside the context of transfer (e.g., while being managed in a storage system). For example, see the IHE Patient Information Reconciliation Integration Profile [IHE RAD TF-1]. Such updates may also be recorded in the Instance Coercion DateTime (0008,0015) and Original Attributes Sequence (0400,0561).
If Patient ID (0010,0020) is included in the Modified Attributes Sequence (0400,0550), inclusion of Issuer of Patient ID (0010,0021), even if unchanged, or absent in the original, can more precisely identify the context of the replaced value.
Table C.12.1.1.9-1 defines the Attributes of the Original Attributes Sequence (0400,0561).
Table C.12.1.1.9-1. Original Attributes Macro Attributes
Sequence of Items containing all Attributes that were added, removed or replaced by other values in the top level Data Set. See Section C.12.1.1.9. |
|||
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. |
|||
Date and time the Attributes were replaced, added or removed. |
|||
Identification of the system that replaced, added or removed the Attributes. |
|||
Reason for the Attribute modification. Defined Terms:
|
|||
Sequence that contains all the Attributes, with their previous values, that were modified or removed from the top level Data Set. See Section C.12.1.1.9.1. |
|||
>>Any Attribute from the top level Data Set that was modified or removed. |
|||
Attributes that were replaced or removed from the Data Set because the values were not conformant to the Attribute's Value Representation or Value Multiplicity. See Section C.12.1.1.9.2. One or more Items are permitted in this Sequence, one Item for each nonconforming Attribute. |
|||
Pointer to Attribute in Modified Attributes Sequence (0400,0550) that had a nonconforming value. |
|||
Attributes that were replaced, added or removed shall be placed in the Modified Attributes Sequence (0400,0550) with their prior values. If an Attribute within a Sequence was replaced, added or removed, the entire prior value of the Sequence shall be placed in the Modified Attributes Sequence (0400,0550); this applies recursively up to the enclosing Sequence Attribute in the top level Data Set.
Attributes that were empty or absent and for which values have been added may be present in the Modified Attributes Sequence (0400,0550) with a zero length value.
If an Attribute was replaced, added or removed because its value was nonconforming to its Value Representation or Value Multiplicity, it shall be included in the Modified Attributes Sequence (0400,0550) with a zero length value.
Any Private Data Elements present in the Item shall be accompanied by their respective Private Data Element Creator Attribute.
If an Attribute Value was replaced or removed because its value was nonconforming to its Value Representation or Value Multiplicity, the original value (which was replaced by a zero length value in the Modified Attributes Sequence) may be recorded in the Nonconforming Modified Attributes Sequence (0400,0551).
The nonconforming Attribute is identified by the Attributes of the Selector Attribute Macro. Because a single Attribute is being identified, Selector Attribute (0072,0026) shall be present.
The Data Set to which the Selector Attribute Macro applies is the single Item of the Modified Attributes Sequence (0400,0550) within the same Item of the Original Attributes Sequence (0400,0561). Therefore, the Modified Attributes Sequence (0400,0550) is not identified in the Selector Sequence Pointer (0072,0052).
This is effectively the same as a pointer to the equivalent Attribute in the original top level Data Set.
Characters in text Attributes non-conformant to the identified Specific Character Set (0008,0005) may be considered non-conformant to the VR.
For example, if Body Part Examined (0018,0015) had a nonconforming value, the Nonconforming Modified Attributes Sequence (0400,0551) Item would have the Attributes:
The Nonconforming Data Element Value (0400,0552) has Value Representation OB, which allows an arbitrary byte string to be encoded.
Enumerated Values:
The interpretation of the meaning of local and imported are user-specific. The purpose of this Attribute is to provide a means of communicating a user-specific decision, not to attempt to achieve uniformity with respect to any particular organizational or geographical boundary around any particular organizational or geographical entity, be it an entity that is a device, system, facility, office, department, site, enterprise, region, nation, etc.
A typical pattern would be for an archive to set a value of LOCAL when receiving Instances on the network from a modality within the hospital but to set a value of IMPORTED when receiving Instances from an interchange media reader or an external network Instance sharing gateway. Displaying the value of this Attribute in a viewer then makes it apparent to a user whether or not an Instance is "one of their own". How a receiver determines whether or not the sender is local is not specified, but could, for example, be determined from the sender's AE Title.
When Instances are transported from one entity to another and then imported, it is expected that this Attribute be set to an appropriate value for the new context, overwriting any previous value. E.g., a value of LOCAL used within an archive at the site where the Instances were acquired would be coerced to a value of IMPORTED when those Instances were received by another site to which the patient had been transferred. Whether or not previous values of this Attribute are copied into Original Attributes Sequence (0400,0561) after coercion is not specified.
It is not expected (but nor is it prohibited) that this Attribute will be removed by an exporting entity, since it may be useful to a recipient to know whether or not the Instance was local to the previous entity or not. Similarly, a modality may populate this Attribute with a value of LOCAL after creating the images, but is not required to.
The round-trip case, e.g., when an image is acquired locally, exported, locally deleted and then re-imported may be challenging unless a local record is maintained. I.e., after acquisition, in the local archive it would be expected to be LOCAL. After re-importation without any local state, it may be hard to determine that it once was LOCAL. Other Attributes such as Institution Name may not be sufficient to reliably detect this.
A new SOP Instance UID (0008,0018) is not required when adding or coercing this Attribute, since a derived Instance is not being created. See Section C.12.4.1.1 Derivation Description and Section B.4.1.3 Coercion of Attributes in PS3.4 .
A more detailed history of the handling of an Instance may be recorded in Contributing Equipment Sequence (0018,A001).
This Attribute may need to be removed during de-identification. See Annex E “Attribute Confidentiality Profiles (Normative)” in PS3.15.
DICOM PS3.3 2024e - Information Object Definitions |
---|