Computed Radiography ImageCIOD
CT ImageCIOD
MR ImageCIOD
Nuclear Medicine ImageCIOD
Ultrasound ImageCIOD
Ultrasound Multi-frame ImageCIOD
Secondary Capture ImageCIOD
Multi-frame Single Bit Secondary Capture ImageCIOD
Multi-frame Grayscale Byte Secondary Capture ImageCIOD
Multi-frame Grayscale Word Secondary Capture ImageCIOD
Multi-frame True Color Secondary Capture ImageCIOD
X-Ray Angiographic ImageCIOD
X-Ray Radiofluoroscopic ImageCIOD
RT ImageCIOD
RT DoseCIOD
RT Structure SetCIOD
RT PlanCIOD
PatientMModule - Patient
(0008,1120) Referenced Patient Sequence3Sequence
(0010,0010) Patient's Name2Person Name
(0010,0020) Patient ID2Long String
(0010,0021) Issuer of Patient ID3Long String
(0010,0022) Type of Patient ID3Code String
(0010,0024) Issuer of Patient ID Qualifiers Sequence3Sequence
(0010,0026) Source Patient Group Identification Sequence3Sequence
(0010,0027) Group of Patients Identification Sequence3Sequence
(0010,0030) Patient's Birth Date2Date
(0010,0032) Patient's Birth Time3Time
(0010,0033) Patient's Birth Date in Alternative Calendar3Long String
(0010,0034) Patient's Death Date in Alternative Calendar3Long String
(0010,0035) Patient's Alternative Calendar1CCode String
(0010,0040) Patient's Sex2Code String
(0010,0200) Quality Control Subject3Code String
(0010,0212) Strain Description3Unlimited Characters
(0010,0213) Strain Nomenclature3Long String
(0010,0216) Strain Stock Sequence3Sequence
(0010,0218) Strain Additional Information3Unlimited Text
(0010,0219) Strain Code Sequence3Sequence
(0010,0221) Genetic Modifications Sequence3Sequence
(0010,1001) Other Patient Names3Person Name
(0010,1002) Other Patient IDs Sequence3Sequence
(0010,1100) Referenced Patient Photo Sequence3Sequence
(0010,2160) Ethnic Group3Short String
(0010,2201) Patient Species Description1CLong String
(0010,2202) Patient Species Code Sequence1CSequence
(0010,2292) Patient Breed Description2CLong String
(0010,2293) Patient Breed Code Sequence2CSequence
(0010,2294) Breed Registration Sequence2CSequence
(0010,2297) Responsible Person2CPerson Name
(0010,2298) Responsible Person Role1CCode String
(0010,2299) Responsible Organization2CLong String
(0010,4000) Patient Comments3Long Text
(0012,0062) Patient Identity Removed3Code String
(0012,0063) De-identification Method1CLong String
(0012,0064) De-identification Method Code Sequence1CSequence
Clinical Trial SubjectUModule - Patient
General StudyMModule - Study
Patient StudyUModule - Study
Clinical Trial StudyUModule - Study
RT SeriesMModule - Series
Clinical Trial SeriesUModule - Series
Frame of ReferenceUModule - Frame of Reference
General EquipmentMModule - Equipment
RT General PlanMModule - Plan
RT PrescriptionUModule - Plan
RT Tolerance TablesUModule - Plan
RT Patient SetupUModule - Plan
RT Fraction SchemeUModule - Plan
RT BeamsCModule - Plan
RT Brachy Application SetupsCModule - Plan
ApprovalUModule - Plan
General ReferenceUModule - Plan
SOP CommonMModule - Plan
Common Instance ReferenceUModule - Plan
Positron Emission Tomography ImageCIOD
Digital X-Ray ImageCIOD
Digital Mammography X-Ray ImageCIOD
Digital Intra-Oral X-Ray ImageCIOD
RT Beams Treatment RecordCIOD
RT Brachy Treatment RecordCIOD
RT Treatment Summary RecordCIOD
VL Endoscopic ImageCIOD
VL Microscopic ImageCIOD
VL Slide-Coordinates Microscopic ImageCIOD
VL Photographic ImageCIOD
Video Endoscopic ImageCIOD
Video Microscopic ImageCIOD
Video Photographic ImageCIOD
VL Whole Slide Microscopy ImageCIOD
Real-Time Video Endoscopic ImageCIOD
Real-Time Video Photographic ImageCIOD
Dermoscopic Photography ImageCIOD
Grayscale Softcopy Presentation StateCIOD
Color Softcopy Presentation StateCIOD
Pseudo-Color Softcopy Presentation StateCIOD
Blending Softcopy Presentation StateCIOD
Basic Structured DisplayCIOD
XA/XRF Grayscale Softcopy Presentation StateCIOD
Advanced Blending Presentation StateCIOD
Variable Modality LUT Softcopy Presentation StateCIOD
Basic Voice Audio WaveformCIOD
12-Lead ECGCIOD
General ECGCIOD
Ambulatory ECGCIOD
Hemodynamic WaveformCIOD
Basic Cardiac Electrophysiology WaveformCIOD
Arterial Pulse WaveformCIOD
Respiratory WaveformCIOD
General Audio WaveformCIOD
Real-Time Audio WaveformCIOD
Routine Scalp ElectroencephalogramCIOD
ElectromyogramCIOD
ElectrooculogramCIOD
Sleep ElectroencephalogramCIOD
Multi-channel Respiratory WaveformCIOD
Body Position WaveformCIOD
General 32-bit ECGCIOD
Basic Text SRCIOD
Enhanced SRCIOD
Comprehensive SRCIOD
Key Object Selection DocumentCIOD
Mammography CAD SRCIOD
Chest CAD SRCIOD
Procedure LogCIOD
X-Ray Radiation Dose SRCIOD
Spectacle Prescription ReportCIOD
Colon CAD SRCIOD
Macular Grid Thickness and Volume ReportCIOD
Implantation Plan SR DocumentCIOD
Comprehensive 3D SRCIOD
Radiopharmaceutical Radiation Dose SRCIOD
Extensible SRCIOD
Acquisition Context SRCIOD
Simplified Adult Echo SRCIOD
Patient Radiation Dose SRCIOD
Planned Imaging Agent Administration SRCIOD
Performed Imaging Agent Administration SRCIOD
Rendition Selection DocumentCIOD
Enhanced X-Ray Radiation Dose SRCIOD
Enhanced MR ImageCIOD
MR SpectroscopyCIOD
Enhanced MR Color ImageCIOD
Raw DataCIOD
Enhanced CT ImageCIOD
Spatial RegistrationCIOD
Deformable Spatial RegistrationCIOD
Spatial FiducialsCIOD
Ophthalmic Photography 8 Bit ImageCIOD
Ophthalmic Photography 16 Bit ImageCIOD
Stereometric RelationshipCIOD
Hanging ProtocolCIOD
Encapsulated PDFCIOD
Encapsulated CDACIOD
Real World Value MappingCIOD
Enhanced XA ImageCIOD
Enhanced XRF ImageCIOD
RT Ion PlanCIOD
RT Ion Beams Treatment RecordCIOD
SegmentationCIOD
Ophthalmic Tomography ImageCIOD
X-Ray 3D Angiographic ImageCIOD
X-Ray 3D Craniofacial ImageCIOD
Breast Tomosynthesis ImageCIOD
Enhanced PET ImageCIOD
Surface SegmentationCIOD
Color PaletteCIOD
Enhanced US VolumeCIOD
Lensometry MeasurementsCIOD
Autorefraction MeasurementsCIOD
Keratometry MeasurementsCIOD
Subjective Refraction MeasurementsCIOD
Visual Acuity MeasurementsCIOD
Ophthalmic Axial MeasurementsCIOD
Intraocular Lens CalculationsCIOD
Generic Implant TemplateCIOD
Implant Assembly TemplateCIOD
Implant Template GroupCIOD
RT Beams Delivery InstructionCIOD
Ophthalmic Visual Field Static Perimetry MeasurementsCIOD
Intravascular Optical Coherence Tomography ImageCIOD
Ophthalmic Thickness MapCIOD
Surface Scan MeshCIOD
Surface Scan Point CloudCIOD
Legacy Converted Enhanced CT ImageCIOD
Legacy Converted Enhanced MR ImageCIOD
Legacy Converted Enhanced PET ImageCIOD
Corneal Topography MapCIOD
Breast Projection X-Ray ImageCIOD
Parametric MapCIOD
Wide Field Ophthalmic Photography Stereographic Projection ImageCIOD
Wide Field Ophthalmic Photography 3D Coordinates ImageCIOD
Tractography ResultsCIOD
RT Brachy Application Setup Delivery InstructionCIOD
Planar MPR Volumetric Presentation StateCIOD
Volume Rendering Volumetric Presentation StateCIOD
Content Assessment ResultsCIOD
CT Performed Procedure ProtocolCIOD
CT Defined Procedure ProtocolCIOD
Protocol ApprovalCIOD
XA Performed Procedure ProtocolCIOD
XA Defined Procedure ProtocolCIOD
Ophthalmic Optical Coherence Tomography En Face ImageCIOD
Ophthalmic Optical Coherence Tomography B-scan Volume AnalysisCIOD
Encapsulated STLCIOD
Encapsulated OBJCIOD
Encapsulated MTLCIOD
RT Physician IntentCIOD
RT Segment AnnotationCIOD
RT Radiation SetCIOD
C-Arm Photon-Electron RadiationCIOD
Tomotherapeutic RadiationCIOD
Robotic-Arm RadiationCIOD
RT Radiation Record SetCIOD
RT Radiation Salvage RecordCIOD
C-Arm Photon-Electron Radiation RecordCIOD
Tomotherapeutic Radiation RecordCIOD
Robotic-Arm Radiation RecordCIOD
RT Radiation Set Delivery InstructionCIOD
RT Treatment PreparationCIOD
Enhanced RT ImageCIOD
Enhanced Continuous RT ImageCIOD
RT Patient Position Acquisition InstructionCIOD
Microscopy Bulk Simple AnnotationsCIOD
InventoryCIOD
Photoacoustic ImageCIOD
Confocal Microscopy ImageCIOD
Confocal Microscopy Tiled Pyramidal ImageCIOD
Basic DirectoryCIOD

Built with by Innolitics, a team of medical imaging software developers.

Data synced with official DICOM standard on 18 April 2024. The DICOM Standard is under continuous maintenance, and the current official version is available at http://www.dicomstandard.org/current/. DICOM Parts 3, 4, and 6, © NEMA. Please note that the most recent PDF version of the standard is the official reference, and should checked when making technical decisions.

Type of Patient ID Attribute

Tag(0010,0022)
TypeOptional (3)
KeywordTypeOfPatientID
Value Multiplicity1
Value RepresentationCode String (CS)

The type of identifier in the Patient ID (0010,0020).

Defined Terms:

TEXT

RFID

BARCODE

Note

  1. The identifier is coded as a string regardless of the type, not as a binary value.

  2. When this Attribute has a value of BARCODE, Patient ID (0010,0020) may or may not have the same value as Barcode Value (2200,0005) in the SOP Common Module, if present.

SOP Common Module

C.12.1 SOP Common Module

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

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, corrected or converted by a Storage SCP (see Section B.4.1.3 “Coercion of Attributes” in PS3.4).

Instance Creator UID

(0008,0014)

3

Uniquely identifies device that created the SOP Instance.

Note

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

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.

Synthetic Data

(0008,001C)

3

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

  1. Since synthetic data may be intended for use in training or testing, the data may be otherwise indistinguishable from acquired patient data. For example, the value of Manufacturer's Model Name (0008,1090) in the Equipment Module may reflect the model, whose output the instance is simulating, even though such a model did not create this instance. Similarly, the value of KVP (0018,0060) may reflect the technique being simulated even though no x-rays were involved.

  2. The equipment that synthesized the data may be recorded as additional Item(s) of the Contributing Equipment Sequence (0018,A001) in the SOP Common Module. The Purpose of Reference code value of (109100, DCM, "Synthesizing Equipment") can be used.

  3. The use of this Attribute to indicate synthetic data is not restricted to images, since any type of SOP Instance may be created artificially

Enumerated Values:

YES

NO

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.

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.

>Coding Scheme Resources Sequence

(0008,0109)

3

Resources related to the coding scheme.

One or more Items are permitted in this Sequence.

>>Coding Scheme URL Type

(0008,010A)

1

The type of the resource related to the coding scheme at the Coding Scheme URL (0008,010E).

Defined Terms:

DOC

The resource is human-readable information describing the coding scheme.

OWL

The resource contains an OWL file that contains a representation of the coding scheme.

CSV

The resource contains a comma separated value text file that contains a representation of the coding scheme.

FHIR

The resource is a FHIR CodingScheme, e.g., as would be referred to in the Coding.system element of a FHIR Coding resource.

>>Coding Scheme URL

(0008,010E)

1

A resource related to the coding scheme.

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”

DCID 7005 “Contributing Equipment Purpose 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.

>Institutional Department Type Code Sequence

(0008,1041)

3

A coded description of the type of Department or Service within the healthcare facility.

Only a single Item is permitted in this Sequence.

>>Include Table 8.8-1 “Code Sequence Macro Attributes”

BCID 7030 “Institutional Department/Unit/Service”.

>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”

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

>Date of Manufacture

(0018,1204)

3

The date the equipment that contributed to the Composite Instance was originally manufactured or re-manufactured (as opposed to refurbished).

>Date of Installation

(0018,1205)

3

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.

>Device UID

(0018,1002)

3

Unique identifier of the contributing equipment.

Note

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

>UDI Sequence

(0018,100A)

3

Unique Device Identifier (UDI) of the contributing equipment.

One or more Items are permitted in this Sequence.

Note

  1. This is the UDI that corresponds to the entire contributing equipment as described by the other attributes in the Contributing Equipment Sequence Item. This is not intended to contain the UDIs of sub-components of the contributing equipment.

  2. Multiple Items may be present if the contributing equipment has UDIs issued by different Issuing Authorities.

>>Include Table 10.29-1 “UDI Macro Attributes”

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

Include Table C.12.1.1.9-1 “Original Attributes Macro Attributes”

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 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 Data Element 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 Section E.2 “Basic Application Level Confidentiality Profile” in PS3.15 and Section E.3.6 “Retain Longitudinal Temporal Information Options” in 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 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

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

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

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

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

  2. No suggested dummy value is provided, since the encoding of the value would depend on the VR of the Data Element.

  3. Further explanation of these actions can be found in PS3.15 Section E.3.1 Clean Pixel Data Option.

Instance Origin Status

(0400,0600)

3

Categorizes the locality of the entity from whence the Instance originated.

Enumerated Values:

LOCAL

Acquired or created in the local entity.

IMPORTED

Imported from an external entity.

Note

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

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

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

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

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

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

  7. A more detailed history of the handling of an Instance may be recorded in Contributing Equipment Sequence (0018,A001).

  8. This Attribute may need to be removed during de-identification. See Annex E “Attribute Confidentiality Profiles (Normative)” in PS3.15.

Barcode Value

(2200,0005)

3

Barcode interpreted from a scanned label.

Note

  1. In the case of a scanned patient label, this may be the same as Patient ID (0010,0020), but it is included in an Instance level Module rather than a Patient level Module since barcodes may also be used to identify lower level entities. This might be obtained by scanning the patient's wrist band, request form, or extracting a burned-in label from the image pixel data, for example.

  2. In the case of a scanned slide label, this may be the same as Container Identifier (0040,0512) in the Specimen Module.

Include Table 10.41-1 “General Procedure Protocol Reference Macro Attributes”


C.12.1.1 SOP Common Module 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.

Note

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

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

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

[ISO IR 100]

[ISO/IEC 8859-1]

ISO-IR 6

94

G0

[ISO 646]

Latin alphabet No. 2

ISO_IR 101

ISO-IR 101

96

G1

[ISO IR 101]

[ISO/IEC 8859-2]

ISO-IR 6

94

G0

[ISO 646]

Latin alphabet No. 3

ISO_IR 109

ISO-IR 109

96

G1

[ISO IR 109]

[ISO/IEC 8859-3]

ISO-IR 6

94

G0

[ISO 646]

Latin alphabet No. 4

ISO_IR 110

ISO-IR 110

96

G1

[ISO IR 110]

[ISO/IEC 8859-4]

ISO-IR 6

94

G0

[ISO 646]

Cyrillic

ISO_IR 144

ISO-IR 144

96

G1

[ISO IR 144]

[ISO/IEC 8859-5]

ISO-IR 6

94

G0

[ISO 646]

Arabic

ISO_IR 127

ISO-IR 127

96

G1

[ISO IR 127]

[ISO/IEC 8859-6]

ISO-IR 6

94

G0

[ISO 646]

Greek

ISO_IR 126

ISO-IR 126

96

G1

[ISO IR 126]

[ISO/IEC 8859-7]

ISO-IR 6

94

G0

[ISO 646]

Hebrew

ISO_IR 138

ISO-IR 138

96

G1

[ISO IR 138]

[ISO/IEC 8859-8]

ISO-IR 6

94

G0

[ISO 646]

Latin alphabet No. 5

ISO_IR 148

ISO-IR 148

96

G1

[ISO IR 148]

[ISO/IEC 8859-9]

ISO-IR 6

94

G0

[ISO 646]

Latin alphabet No. 9

ISO_IR 203

ISO-IR 203

96

G1

[ISO IR 203]

[ISO/IEC 8859-15]

ISO-IR 6

94

G0

[ISO 646]

Japanese

ISO_IR 13

ISO-IR 13

94

G1

[ISO IR 13]

[JIS X 0201]: Katakana

ISO-IR 14

94

G0

[ISO IR 14]

[JIS X 0201]: Romaji

Thai

ISO_IR 166

ISO-IR 166

88

G1

[ISO IR 166]

[TIS 620-2533]

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

[ISO IR 100]

[ISO/IEC 8859-1]

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

[ISO IR 101]

[ISO/IEC 8859-2]

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

[ISO IR 109]

[ISO/IEC 8859-3]

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

[ISO IR 110]

[ISO/IEC 8859-4]

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

[ISO IR 144]

[ISO/IEC 8859-5]

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

[ISO IR 127]

[ISO/IEC 8859-6]

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

[ISO IR 126]

[ISO/IEC 8859-7]

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

[ISO IR 138]

[ISO/IEC 8859-8]

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

[ISO IR 148]

[ISO/IEC 8859-9]

ISO 2022

ESC 02/08 04/02

ISO-IR 6

94

G0

[ISO 646]

Latin alphabet No. 9

ISO 2022 IR 203

ISO 2022

ESC 02/13 06/02

ISO-IR 203

96

G1

[ISO IR 203]

[ISO/IEC 8859-15]

ISO 2022

ESC 02/08 04/02

ISO-IR 6

94

G0

[ISO 646]

Japanese

ISO 2022 IR 13

ISO 2022

ESC 02/09 04/09

ISO-IR 13

94

G1

[ISO IR 13]

[JIS X 0201]: Katakana

ISO 2022

ESC 02/08 04/10

ISO-IR 14

94

G0

[ISO IR 14]

[JIS X 0201]: Romaji

Thai

ISO 2022 IR 166

ISO 2022

ESC 02/13 05/04

ISO-IR 166

88

G1

[ISO IR 166]

[TIS 620-2533]

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

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]


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:

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

Note

  1. [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.

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

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

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

Character Set Description

Defined Term

Character Set

Unicode in UTF-8

ISO_IR 192

[ISO IR 192]

GB18030

GB18030

[GB 18030]

GBK

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 top level Data Set of the SOP Instance.

Note

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

For Defined Terms, see Table C.12.1.1.3.1.2-1, “Defined Terms for MAC Algorithm (0400,0015)”.

>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

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

BCID 7007 “Signature Purpose”.


C.12.1.1.3.1 Digital Signatures Macro 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

  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 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 Signatures 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 (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.

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

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

  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.

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)

Defined Term

Reference

RIPEMD160

[ISO/IEC 10118-3]

MD5

[RFC1321]

Note

See also security considerations in [RFC6151]. The use of MD5 is no longer recommended.

SHA1

[FIPS PUB 180-4]

SHA224

[FIPS PUB 180-4]

SHA256

[FIPS PUB 180-4]

SHA384

[FIPS PUB 180-4]

SHA512

[FIPS PUB 180-4]

SHA512_224

[FIPS PUB 180-4]

SHA512_256

[FIPS PUB 180-4]

SHA3_224

[FIPS PUB 202]

SHA3_256

[FIPS PUB 202]

SHA3_384

[FIPS PUB 202]

SHA3_512

[FIPS PUB 202]


Note

Security Profiles (see PS3.15) may restrict or extend the list of MAC algorithms that are permitted or required by a specific profile.

C.12.1.1.3.1.3 Certified Timestamp

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.

Note

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

C.12.1.1.4 Encrypted Attributes
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 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.

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

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 IETF STD 70 [RFC5652].

  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-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 top level Data Set during de-identification of the SOP Instance. Upon reversal of the de-identification process, the Attributes are copied back into the top level 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 top level Data Set that was modified or removed during the de-identification process.

3


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

Note

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

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

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

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

  5. 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").

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

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

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

Note

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

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

  1. This encoding is the same as described in PS3.5 for the offset component of the DT Value Representation.

  2. This Attribute does not apply to values with a DT Value Representation, that contains an explicitly encoded timezone offset.

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

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

C.12.1.1.9 Original Attributes Sequence and Instance Coercion DateTime

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.

Note

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

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

Attribute Name

Tag

Type

Attribute Description

Original Attributes Sequence

(0400,0561)

3

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.

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 replaced, added or removed.

>Modifying System

(0400,0563)

1

Identification of the system that replaced, added or removed the Attributes.

>Reason for the Attribute Modification

(0400,0565)

1

Reason for the Attribute modification.

Defined Terms:

COERCE

Replace, add or remove 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 or remove incorrect values, or add correct values, such as Patient Name or ID, for example, when incorrect worklist item was chosen or operator input error.

CONVERT

Replace, add, or remove values of Attributes during a conversion, for example, of private DICOM objects to a standard SOP Class.

>Modified Attributes Sequence

(0400,0550)

1

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.

Only a single Item shall be included in this Sequence.

>>Any Attribute from the top level Data Set that was modified or removed.

2

May include Sequence Attributes and their Items.

>Nonconforming Modified Attributes Sequence

(0400,0551)

3

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.

>>Include Table 10-20 “Selector Attribute Macro Attributes”

Pointer to Attribute in Modified Attributes Sequence (0400,0550) that had a nonconforming value.

>>Nonconforming Data Element Value

(0400,0552)

1

The original Value of the nonconforming Attribute.


C.12.1.1.9.1 Modified Attributes Sequence

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.

C.12.1.1.9.2 Nonconforming Modified Attributes Sequence

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

Note

  1. This is effectively the same as a pointer to the equivalent Attribute in the original top level Data Set.

  2. Characters in text Attributes non-conformant to the identified Specific Character Set (0008,0005) may be considered non-conformant to the VR.

  3. For example, if Body Part Examined (0018,0015) had a nonconforming value, the Nonconforming Modified Attributes Sequence (0400,0551) Item would have the Attributes:

    (0072,0026)

    00180015

    Selector Attribute

    (0072,0028)

    1

    Selector Value Number

    (0400,0552)

    ABDOMEN&PELVIS

    Nonconforming Data Element Value

  4. The Nonconforming Data Element Value (0400,0552) has Value Representation OB, which allows an arbitrary byte string to be encoded.