DICOM Part 3
 
PS 3.3-2003

Digital Imaging and Communications in Medicine (DICOM) Part 3: Information Object Definitions

Published by

National Electrical Manufacturers Association

1300 N. 17th Street Rosslyn, Virginia 22209 USA

© Copyright 2003 by the National Electrical Manufacturers Association. All rights including translation into other languages, reserved under the Universal Copyright Convention, the Berne Convention or the Protection of Literacy and Artistic Works, and the International and Pan American Copyright Conventions.

-Standard -

PS 3.3 - 2003 Page 2

NOTICE AND DISCLAIMER

The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.

NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.

NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller’s products or services by virtue of this standard or guide.

In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.

NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety–related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.

PS 3.3 -2003
Page 3
CONTENTS
NOTICE AND DISCLAIMER 2
CONTENTS 3
FOREWORD 19
Scope and field of application 21
Normative references 21
Definitions 23
REFERENCE MODEL DEFINITIONS23
SERVICE CONVENTIONS DEFINITIONS 23
DICOM INTRODUCTION AND OVERVIEW DEFINITIONS23
DICOM SERVICE CLASS SPECIFICATIONS23
DICOM DATA STRUCTURES AND ENCODING 24
DICOM MESSAGE EXCHANGE 24
DICOM UPPER LAYER SERVICE 24
DICOM INFORMATION OBJECT 24
CHARACTER HANDLING DEFINITIONS 25
RADIOTHERAPY 26
MACROS 26
DICOM GRAYSCALE STANDARD DISPLAY FUNCTION26
CODES AND CONTROLLED TERMINOLOGY DEFINITIONS:26
REFERENCE MODEL SECURITY ARCHITECTURE DEFINITIONS27
SECURITY DEFINITIONS27
DICOM SECURITY PROFILES 27
Symbols and abbreviations 28
5 Conventions29
ENTITY-RELATIONSHIP MODEL 29
ENTITY 29
RELATIONSHIP29
SEQUENCES 30
TRIPLET ENCODING OF STRUCTURED DATA (RETIRED) 32
ATTRIBUTE MACROS32
DICOM information model 33
INFORMATION OBJECT DEFINITION34
COMPOSITE IOD 34
NORMALIZED IOD 34
ATTRIBUTES 34
ON-LINE COMMUNICATION AND MEDIA STORAGE SERVICES 35
DIMSE-C SERVICES35
DIMSE-N SERVICES35
DIMSE SERVICE GROUP 35
PS 3.3 -2003
Page 4
SERVICE-OBJECT PAIR (SOP) CLASS 35
NORMALIZED AND COMPOSITE SOP CLASSES35
ASSOCIATION NEGOTIATION 35
SERVICE CLASS SPECIFICATION 36
DICOM model of the real-world 36
DICOM INFORMATION MODEL 42
ORGANIZATION OF ANNEXES A, B AND C42
EXTENSION OF THE DICOM MODEL OF THE REAL-WORLD 42
Definition of the Extensions of the DICOM Real-World Model 43
PATIENT 43
SERVICE EPISODE43
IMAGING SERVICE REQUEST 43
PROCEDURE TYPE 44
REQUESTED PROCEDURE44
SCHEDULED PROCEDURE STEP 44
PROCEDURE PLAN 45
PROTOCOL 45
MODALITY PERFORMED PROCEDURE STEP 45
GENERAL PURPOSE SCHEDULED PROCEDURE STEP 45
GENERAL PURPOSE PERFORMED PROCEDURE STEP46
WORKITEM46
EXTENSION OF THE DICOM MODEL OF THE REAL-WORLD FOR THE GENERAL PURPOSE WORKLIST 46
ORGANIZING LARGE SETS OF INFORMATION49
CONCATENATION 49
DIMENSION ORGANIZATION49
EXTENSION OF THE DICOM MODEL OF THE REAL WORLD FOR CLINICAL TRIALS50
Clinical Trial Information Entities 51
Clinical Trial Sponsor 51
Clinical Trial Protocol51
Clinical Trial Subject 51
Clinical Trial Site51
Clinical Trial Time Point52
Clinical Trial Coordinating Center 52
Encoding of Coded Entry Data 53
CODE VALUE 53
CODING SCHEME DESIGNATOR AND CODING SCHEME VERSION53
CODE MEANING 54
MAPPING RESOURCE54
CONTEXT GROUP VERSION 55
CONTEXT IDENTIFIER 55
CONTEXT GROUP EXTENSIONS55
STANDARD ATTRIBUTE SETS FOR CODE SEQUENCE ATTRIBUTES 55
TEMPLATE IDENTIFICATION MACRO 56
10 MISCELLANEOUS MACROS 57
PERSON IDENTIFICATION MACRO 57
Annex A Composite information object definitions (Normative)59
ELEMENTS OF AN INFORMATION OBJECT DEFINITION 59
PS 3.3 -2003
Page 5
IOD Description59
IOD Entity-Relationship Model59
PATIENT IE60
STUDY IE60
SERIES IE 61
EQUIPMENT IE61
FRAME OF REFERENCE IE 61
IMAGE IE 61
OVERLAY IE 62
CURVE IE 62
MODALITY LUT IE62
VOI LUT IE 62
PRESENTATION STATE IE 63
WAVEFORM IE63
SR DOCUMENT IE 63
MR Spectroscopy IE 63
Raw Data IE 63
IOD Module Table and Functional Group Macro Table63
MANDATORY MODULES 64
CONDITIONAL MODULES64
USER OPTION MODULES64
Overview of the Composite IOD Module Content64
COMPUTED RADIOGRAPHY IMAGE INFORMATION OBJECT DEFINITION 76
CR Image IOD Description 76
CR Image IOD Entity-Relationship Model 76
CR Image IOD Module Table76
COMPUTED TOMOGRAPHY IMAGE INFORMATION OBJECT DEFINITION 76
CT Image IOD Description76
CT image IOD Entity-Relationship Model 77
CT Image IOD Module Table 77
MAGNETIC RESONANCE IMAGE INFORMATION OBJECT DEFINITION77
MR Image IOD Description 77
MR image IOD Entity-Relationship Model 77
MR Image IOD Module Table 78
NUCLEAR MEDICINE IMAGE INFORMATION OBJECT DEFINITION78
NM Image IOD Description 78
NM Image IOD Entity-Relationship Model 78
NM Image IOD Module Table (Retired) 78
NM Image IOD Module Table 79
ULTRASOUND IMAGE INFORMATION OBJECT DEFINITION 80
US Image IOD Description80
US Image IOD Entity-Relationship Model80
US Image IOD Module Table (Retired)80
US Image IOD Module Table81
Mutually Exclusive IEs 82
ULTRASOUND MULTI-FRAME IMAGE INFORMATION OBJECT DEFINITION 82
US Image IOD Description82
US Multi-Frame Image IOD Entity-Relationship Model 82
US Image IOD Module Table (Retired)82
US Multi-Frame Image IOD Module Table 83
Mutually Exclusive IEs 84
SECONDARY CAPTURE IMAGE INFORMATION OBJECT DEFINITION84
SC Image Information Objection Definition84
PS 3.3 -2003
Page 6
SC Image IOD Description84
SC Image IOD Entity-Relationship Model84
SC Image IOD Module Table 85
Multi-frame Single Bit SC Image Information Object Definition 85
Multi-frame Single Bit SC Image IOD Description 85
Multi-frame Single Bit SC Image IOD Entity-Relationship Model 85
SC Image IOD Module Table 86
Multi-frame Single Bit SC Image IOD Content Constraints 86
Multi-frame Grayscale Byte SC Image Information Object Definition87
Multi-frame Grayscale Byte Image IOD Description 87
Multi-frame Grayscale Byte SC Image IOD Entity-Relationship Model 87
Multi-frame Grayscale Byte SC Image IOD Module Table 87
Multi-frame Grayscale Byte SC Image IOD Content Constraints 88
Multi-frame Grayscale Word SC Image Information Object Definition 88
Multi-frame Grayscale Word SC Image IOD Description88
Multi-frame Grayscale Word SC Image IOD Entity-Relationship Model88
Multi-frame Grayscale Word SC Image IOD Module Table89
Multi-frame Grayscale Word SC Image IOD Content Constraints89
Multi-frame True Color SC Image Information Object Definition 90
Multi-frame True Color Image IOD Description 90
Multi-frame True Color SC Image IOD Entity-Relationship Model 90
Multi-frame True Color SC Image IOD Module Table90
Multi-frame True Color SC Image IOD Content Constraints90
STANDALONE OVERLAY INFORMATION OBJECT DEFINITION91
Standalone Overlay IOD Description 91
Standalone Overlay IOD Entity-Relationship Model 91
Standalone Overlay IOD Module Table 91
STANDALONE CURVE INFORMATION OBJECT DEFINITION 92
Standalone Curve IOD Description92
Standalone Curve IOD Entity-Relationship Model92
Standalone Curve IOD Module Table92
BASIC STUDY DESCRIPTOR INFORMATION OBJECT DEFINITION93
Basic Study Descriptor IOD Description 93
Basic Study Descriptor Entity-Relationship Model 93
Basic Study Descriptor IOD Module Table 93
STANDALONE MODALITY LUT INFORMATION OBJECT DEFINITION94
Standalone Modality LUT IOD Description 94
Standalone Modality LUT IOD Entity-Relationship Model 94
Standalone Modality LUT IOD Module Table 94
STANDALONE VOI LUT INFORMATION OBJECT DEFINITION 94
Standalone VOI LUT IOD Description 94
Standalone VOI LUT IOD Entity-Relationship Model 94
Standalone VOI LUT IOD Module Table 95
X-RAY ANGIOGRAPHIC IMAGE INFORMATION OBJECT DEFINITION96
XA Image IOD Description96
XA Image IOD Entity-Relationship Model96
XA Image IOD Module Table 97
X-RAY ANGIOGRAPHIC BI-PLANE IMAGE INFORMATION OBJECT DEFINITION (RETIRED)98
X-RAY RF IMAGE INFORMATION OBJECT DEFINITION98
XRF Image IOD Description 98
XRF Image IOD Entity-Relationship Model 98
XRF Image IOD Module Table98
PS 3.3 -2003
Page 7
RT IMAGE INFORMATION OBJECT DEFINITION 100
RT Image IOD Description100
RT Image IOD entity-relationship model100
RT Image IOD Module Table 101
RT DOSE INFORMATION OBJECT DEFINITION 103
RT Dose IOD Description 103
RT Dose IOD entity-relationship model 103
RT Dose IOD Module Table104
RT STRUCTURE SET INFORMATION OBJECT DEFINITION 105
RT Structure Set IOD Description105
RT Structure Set IOD entity-relationship model105
RT Structure Set IOD Module Table 106
RT PLAN INFORMATION OBJECT DEFINITION 107
RT Plan IOD Description107
RT Plan IOD entity-relationship model 107
RT Plan IOD Module Table108
RT FRACTION SCHEME MODULE 108
RT PRESCRIPTION MODULE 109
RT TOLERANCE TABLES MODULE 109
RT PATIENT SETUP MODULE109
POSITRON EMISSION TOMOGRAPHY IMAGE INFORMATION OBJECT DEFINITION 110
PET Image IOD Description110
PET Image IOD Entity-Relationship Model110
PET Image IOD Module Table110
STANDALONE PET CURVE INFORMATION OBJECT DEFINITION 111
Standalone PET Curve IOD Description111
Standalone PET Curve IOD Entity-Relationship Model111
Standalone PET Curve IOD Module Table111
STORED PRINT INFORMATION OBJECT DEFINITION111
IOD Description111
Stored Print IOD Entity-Relationship Model112
IOD Module Table 112
HARDCOPY GRAYSCALE IMAGE INFORMATION OBJECT DEFINITION 112
IOD Description112
Hardcopy Grayscale Image IOD Entity-Relationship Model112
IOD Module Table 113
HARDCOPY COLOR IMAGE INFORMATION OBJECT DEFINITION 113
IOD Description113
Hardcopy Color Image IOD Entity-Relationship Model 113
IOD Module Table 114
DIGITAL X-RAY IMAGE INFORMATION OBJECT DEFINITION114
DX Image IOD Description114
DX Image IOD Entity-Relationship Model115
DX Image IOD Module Table115
Overlay Plane Module116
DIGITAL MAMMOGRAPHY X-RAY IMAGE INFORMATION OBJECT DEFINITION 117
Digital Mammography X-Ray Image IOD Description 117
Digital Mammography X-Ray Image IOD Module Table 117
Overlay Plane Module119
DIGITAL INTRA-ORAL X-RAY IMAGE INFORMATION OBJECT DEFINITION119
Digital Intra-oral X-Ray Image IOD Description 119
Digital Intra-oral X-Ray Image IOD Module Table 120
PS 3.3 -2003
Page 8
Overlay Plane Module121
RT BEAMS TREATMENT RECORD INFORMATION OBJECT DEFINITION 121
RT Beams Treatment Record IOD Description 121
RT Beams Treatment Record IOD entity-relationship model 121
RT Beams Treatment Record IOD Module Table 123
RT BRACHY TREATMENT RECORD INFORMATION OBJECT DEFINITION123
RT Brachy Treatment Record IOD Description 123
RT Brachy Treatment Record IOD entity-relationship model 123
RT Brachy Treatment Record IOD Module Table 125
RT TREATMENT SUMMARY RECORD INFORMATION OBJECT DEFINITION 125
RT Treatment Summary Record IOD Description 125
RT Treatment Summary Record IOD entity-relationship model 125
RT Treatment Summary Record IOD Module Table 126
VISIBLE LIGHT IMAGE INFORMATION OBJECT DEFINITIONS 127
VL Endoscopic Image Information Object Definition 127
VL Endoscopic Image IOD Description127
VL Endoscopic Image IOD Entity-Relationship Model127
VL Endoscopic Image IOD Content Constraints127
VL Microscopic Image Information Object Definition128
VL Microscopic Image IOD Description 128
VL Microscopic Image IOD Entity-Relationship Model 128
VL Microscopic Image IOD Content Constraints 128
VL Slide-Coordinates Microscopic Image Information Object Definition 129
VL Slide-Coordinates Microscopic Image IOD Description 129
VL Slide-Coordinates Microscopic Image IOD Entity-Relationship Model 129
VL Slide-Coordinates Microscopic Image IOD Content Constraints 129
VL Photographic Image Information Object Definition130
VL Photographic Image IOD Description 130
VL Photographic Image IOD Entity-Relationship Model 130
VL Photographic Image IOD Content Constraints 130
GRAYSCALE SOFTCOPY PRESENTATION STATE INFORMATION OBJECT DEFINITION131
Grayscale Softcopy Presentation State IOD Description 131
Grayscale Softcopy Presentation State IOD Module Table132
WAVEFORM INFORMATION OBJECT DEFINITIONS 134
Waveform IOD Entity-Relationship Model134
Basic Voice Audio Information Object Definition 134
Basic Voice Audio IOD Description 134
Basic Voice Audio IOD Entity-Relationship Model 134
Basic Voice Audio IOD Module Table134
Basic Voice Audio IOD Content Constraints135
12-Lead Electrocardiogram Information Object Definition 135
12-Lead ECG IOD Description 135
12-Lead ECG IOD Entity-Relationship Model135
12-Lead ECG IOD Module Table135
12-Lead ECG IOD Content Constraints136
General Electrocardiogram Information Object Definition138
General ECG IOD Description 138
General ECG IOD Entity-Relationship Model 138
General ECG IOD Module Table 138
General ECG IOD Content Constraints 138
Ambulatory Electrocardiogram Information Object Definition 139
Ambulatory ECG IOD Description 139
Ambulatory ECG IOD Entity-Relationship Model139
Ambulatory ECG IOD Module Table139
PS 3.3 -2003
Page 9
Ambulatory ECG IOD Content Constraints140
Hemodynamic Information Object Definition 140
HemodynamicIOD Description 140
Hemodynamic IOD Entity-Relationship Model140
Hemodynamic IOD Module Table140
Hemodynamic IOD Content Constraints141
Basic Cardiac Electrophysiology Information Object Definition 142
Basic Cardiac EP IOD Description 142
Basic Cardiac EP IOD Entity-Relationship Model 142
Basic Cardiac EP IOD Module Table143
Basic Cardiac EP IOD Content Constraints143
STRUCTURED REPORT DOCUMENT INFORMATION OBJECT DEFINITIONS145
Basic Text SR Information Object Definition 145
Basic Text SR Information Object Description145
Basic Text SR IOD Entity-Relationship Model145
Basic Text SR IOD Module Table 145
Enhanced SR Information Object Definition146
Enhanced SR Information Object Description 146
Enhanced SR IOD Entity-Relationship Model 147
Enhanced SR IOD Module Table 147
Comprehensive SR Information Object Definition148
Comprehensive SR Information Object Description 148
Comprehensive SR IOD Entity-Relationship Model 149
Comprehensive SR IOD Module Table 149
Key Object Selection Document Information Object Definition 151
Key Object Selection Document Information Object Description 151
Key Object Selection Document IOD Entity-Relationship Model151
Key Object Selection Document IOD Module Table151
Mammography CAD SR Information Object Definition 152
Mammography CAD SR Information Object Description152
Mammography CAD SR IOD Entity-Relationship Model152
Mammography CAD SR IOD Module Table 152
Chest CAD SR Information Object Definition 154
Chest CAD SR Information Object Description 154
Chest CAD SR IOD Entity-Relationship Model154
Chest CAD SR IOD Module Table155
ENHANCED MR INFORMATION OBJECT DEFINITIONS 156
Relationship between Enhanced MR IODs 156
Enhanced MR Image Information Object Definition 158
Enhanced MR Image IOD Description158
Enhanced MR Image Entity-Relationship Model 158
Enhanced MR Image IOD Module Table 158
Enhanced MR Image Functional Group Macros160
MR Spectroscopy Information Object Definition 161
MR Spectroscopy IOD Description 161
MR Spectroscopy entity-relationship model161
MR Spectroscopy IOD Module Table 162
MR Spectroscopy Functional Group Macros 163
RAW DATA INFORMATION OBJECT DEFINITION 164
Raw Data IOD Description 164
Raw Data entity-relationship model164
Raw Data IOD Module Table 165
Annex B Normalized Information Object Definitions (Normative)166
PATIENT INFORMATION OBJECT DEFINITION 166
PS 3.3 -2003
Page 10
IOD description 166
Patient IOD modules 166
VISIT INFORMATION OBJECT DEFINITION166
IOD description 166
IOD modules 166
STUDY INFORMATION OBJECT DEFINITION 167
IOD description 167
IOD modules 167
STUDY COMPONENT INFORMATION OBJECT DEFINITION167
IOD description 167
IOD modules 168
RESULTS INFORMATION OBJECT DEFINITION168
IOD description 168
IOD modules 168
INTERPRETATION INFORMATION OBJECT DEFINITION 169
IOD description 169
IOD modules 169
BASIC FILM SESSION INFORMATION OBJECT DEFINITION 169
IOD description 169
IOD modules 170
BASIC FILM BOX INFORMATION OBJECT DEFINITION170
IOD description 170
IOD modules 170
BASIC IMAGE BOX INFORMATION OBJECT DEFINITION 170
IOD description 170
IOD modules 170
BASIC ANNOTATION BOX INFORMATION OBJECT DEFINITION 171
IOD description 171
IOD modules 171
PRINT JOB INFORMATION OBJECT DEFINITION171
IOD description 171
IOD modules 171
PRINTER INFORMATION OBJECT DEFINITION171
IOD description 171
IOD modules 171
VOI LUT BOX INFORMATION OBJECT DEFINITION (RETIRED) 171
IMAGE OVERLAY BOX INFORMATION OBJECT DEFINITION (RETIRED)172
STORAGE COMMITMENT INFORMATION OBJECT DEFINITION172
Storage Commitment IOD Description 172
Storage Commitment IOD Modules 172
PRINT QUEUE INFORMATION OBJECT DEFINITION172
IOD Description172
IOD Modules 172
MODALITY PERFORMED PROCEDURE STEP INFORMATION OBJECT DEFINITION 172
IOD Description172
IOD Modules 173
PRESENTATION LUT INFORMATION OBJECT DEFINITION 173
IOD Description173
IOD Modules 173
PULL PRINT REQUEST INFORMATION OBJECT DEFINITION 174
PS 3.3 -2003
Page 11
IOD description 174
IOD module table 174
PRINTER CONFIGURATION INFORMATION OBJECT DEFINITION 174
IOD Description174
IOD Modules 174
BASIC PRINT IMAGE OVERLAY BOX INFORMATION OBJECT DEFINITION 175
IOD Description 175
IOD Modules175
GENERAL PURPOSE SCHEDULED PROCEDURE STEP INFORMATION OBJECT DEFINITION 175
IOD Description175
IOD Modules 175
GENERAL PURPOSE PERFORMED PROCEDURE STEP INFORMATION OBJECT DEFINITION 175
IOD Description175
IOD Modules 176
Annex C INFORMATION MODULE DEFINITIONS (NORMATIVE) 177
ELEMENTS OF A MODULE DEFINITION177
Module Description 177
Module Definition 177
Attribute Name 177
Attribute Tag177
Type Designation 177
Attribute Definition 178
Attribute Descriptions178
PATIENT MODULES178
Patient Relationship Module 178
Patient Identification Module179
Patient Demographic Module180
Patient Medical Module181
VISIT MODULES 182
Visit Relationship Module182
Visit Identification Module 182
Visit Status Module 183
Visit Admission Module183
Visit Discharge Module 184
Visit Scheduling Module184
STUDY MODULES184
Study Relationship Module 185
Study Identification Module185
Study Classification Module186
Study Scheduling Module 186
Study Acquisition Module187
Study Read Module 188
Study Component Module 189
Study Component Relationship Module 190
Study Component Acquisition Module190
Scheduled Procedure Step Module 191
Requested Procedure Module 192
Imaging Service Request Module 193
Performed Procedure Step Relationship 195
Performed Procedure Step Information 197
Image Acquisition Results198
PS 3.3 -2003
Page 12
Radiation Dose 199
Billing and Material Management Codes 201
General Purpose Scheduled Procedure Step Relationship Module 202
General Purpose Scheduled Procedure Step Information Module203
General Purpose Performed Procedure Step Relationship Module207
General Purpose Performed Procedure Step Information Module209
General Purpose Results210
RESULTS MODULES 211
Results Relationship Module 211
Results Identification Module 211
Results Impressions Module211
INTERPRETATION MODULES 212
Interpretation Relationship Module 212
Interpretation Identification Module212
Interpretation State Module213
Interpretation Recording Module 213
Interpretation Transcription Module 213
Interpretation Approval Module214
COMMON COMPOSITE IMAGE IOD MODULES 214
Common Patient IE Modules 214
Patient Module 214
Specimen Identification Module 215
Clinical Trial Subject Module 216
Common Study IE Modules 218
General Study Module 218
Patient Study Module 219
Clinical Trial Study Module 220
Common Series IE Modules 220
General Series Module 220
Clinical Trial Series Module 225
Common Frame Of Reference Information Entity Modules225
Frame Of Reference Module225
Synchronization Module 226
Common Equipment IE Modules 228
General Equipment Module 228
Common Image IE Modules 230
General Image Module230
Image Plane Module 236
Image Pixel Module237
Contrast/Bolus Module244
Cine Module 245
Multi-Frame Module 246
Bi-Plane Sequence Module (Retired) 247
Bi-Plane Image Module (Retired)247
Frame Pointers Module247
Mask Module 248
Display Shutter Module 249
Device 255
Therapy 256
Acquisition Context Module257
Bitmap Display Shutter Module259
Multi-frame Functional Groups Module261
Multi-frame Dimension Module 281
Physiological Synchronization287
Supplemental Palette Color Lookup Table Module 293
PS 3.3 -2003
Page 13
Patient Summary Module293
Study Content Module 293
Palette Color Lookup Table Module 295
Palette Color Lookup Table UID 296
Segmented Palette Color Lookup Table Data 296
MODALITY SPECIFIC MODULES299
Computed Radiography Modules 299
CR Series Module 299
CR Image Module 300
CT Modules302
CT Image Module302
MR Modules 305
MR Image Module 305
Nuclear Medicine Modules310
NM Series Module (Retired)310
NM Equipment Module (Retired) 310
NM Image Module (Retired)310
NM SPECT Acquisition Image Module (Retired) 310
NM Multi-gated Acquisition Image Module (Retired) 310
NM/PET Patient Orientation Module 311
NM Image Pixel Module 312
NM Multi-frame Module 313
NM Image Module 319
NM Isotope Module 324
NM Detector Module 327
NM TOMO Acquisition Module330
NM Multi-gated Acquisition Module 331
NM Phase Module333
NM Reconstruction Module334
Ultrasound Modules 336
US Frame of Reference Module (Retired) 336
US Region Calibration (Retired) 336
US Image Module (Retired) 336
US Frame of Reference Module 336
US Region Calibration Module338
US Image Module 346
Secondary Capture Modules 359
SC Equipment Module 359
SC Image Module360
SC Multi-frame Image Module 360
SC Multi-frame Vector Module 363
X-Ray Modules365
X-Ray Image Module 365
X-Ray Acquisition Module 369
X-Ray Collimator 371
X-Ray Table Module 373
XA Positioner Module374
XRF Positioner Module 378
X-Ray Tomography Acquisition Module379
X-Ray Acquisition Dose Module 379
X-Ray Generation Module383
X-Ray Filtration Module384
X-Ray Grid Module385
Radiotherapy Modules 386
RT Series Module 386
PS 3.3 -2003
Page 14
RT Image Module388
RT Dose Module 397
RT DVH Module 400
Structure Set Module 402
ROI Contour Module 406
RT Dose ROI Module 408
RT ROI Observations Module 409
RT General Plan Module411
RT Prescription Module413
RT Tolerance Tables Module416
RT Patient Setup Module 417
RT Fraction Scheme Module 419
RT Beams Module 423
RT Brachy Application Setups Module 440
Approval Module 450
RT General Treatment Record Module451
RT Treatment Machine Record Module452
Measured Dose Reference Record Module 452
Calculated Dose Reference Record Module 453
RT Beams Session Record Module454
RT Brachy Session Record Module465
RT Treatment Summary Record Module 474
PET Information Module Definitions 477
PET Series Module 477
PET Isotope Module486
PET Multi-gated Acquisition Module 487
PET Image Module488
PET Curve Module 494
Hardcopy Modules 498
Hardcopy Equipment Module498
Hardcopy Grayscale Image Module498
Hardcopy Color Image Module 499
DX Modules500
DX Series Module 500
DX Anatomy Imaged Module 503
DX Image Module505
DX Detector Module 511
DX Positioning Module 519
Mammography Series Module 522
Mammography Image Module 523
Intra-oral Series Module524
Intra-oral Image Module 525
VL Modules 527
VL Image Module 527
Slide Coordinates Module 529
Enhanced MR Image 532
Enhanced MR Image Module532
MR Image and Spectroscopy Instance Macro 534
MR Image Description Macro538
MR Pulse Sequence Module548
Enhanced MR Image Functional Group Macros552
MR Spectroscopy Modules 568
MR Spectroscopy Module 568
MR Spectroscopy Pulse Sequence Module573
MR Spectroscopy Functional Group Macros 575
MR Spectroscopy Data Module 578
PS 3.3 -2003
Page 15
OVERLAYS 581
Overlay identification module581
Overlay plane module 581
Overlay Attribute Descriptions583
Multi-frame Overlay Module583
Multi-Frame Overlay Attribute Descriptions 584
Bi-Plane Overlay Module (Retired) 584
Basic Print Image Overlay Box Module 584
Overlay or Image Magnification 586
CURVE, GRAPHIC AND WAVEFORM587
Curve identification module587
Curve module588
CURVE ATTRIBUTE DESCRIPTIONS 589
Audio module 591
AUDIO SYNCHRONIZATION 592
Displayed Area Module593
Graphic Annotation Module 598
GRAPHIC ANNOTATION ATTRIBUTE DESCRIPTIONS601
Spatial Transformation Module 604
Graphic Layer Module605
Waveform Identification Module 606
Waveform Module 607
Waveform Attribute Descriptions 610
Waveform Annotation Module 613
Waveform Annotation Attribute Descriptions615
LOOK UP TABLES 617
Modality LUT module 617
LUT Attribute Descriptions 618
VOI LUT module 619
LUT Attribute Descriptions 619
LUT identification module 622
Presentation LUT Module623
Image Histogram Module624
Image Histogram Attribute Descriptions 624
Softcopy Presentation LUT Module 625
Softcopy Presentation LUT Attributes 626
Overlay/Curve Activation Module628
Softcopy VOI LUT module 630
Presentation Series Module631
Presentation State Module632
GENERAL MODULES635
SOP Common Module 635
SOP Common Attribute Descriptions638
PRINT MANAGEMENT SPECIFIC MODULES 651
Basic Film Session Presentation Module 651
Basic Film Session Relationship Module651
Basic Film Box Presentation Module 653
Image display format 656
Basic Film Box Relationship Module 658
Image Box Pixel Presentation Module 659
Image Position661
Image Box Relationship Module (Retired) 662
Basic Annotation Presentation Module662
Print Job Module 662
PS 3.3 -2003
Page 16
Printer Module663
Printer Status Info and Execution Status Info 664
Image Overlay Box Presentation Module (Retired) 667
Image Overlay Box Relationship Module (Retired) 667
Print Request Module 667
Printer Configuration Module 669
STORAGE COMMITMENT MODULE 672
Storage Commitment Attribute Description673
Failure Reason 673
QUEUE MANAGEMENT SPECIFIC MODULES 673
General Queue Module673
Print Queue Module 674
STORED PRINT SPECIFIC MODULES 675
Printer Characteristics Module675
Film Box Module 676
Image Box List Module 677
Annotation List Module 678
Image Overlay Box List Module 678
Presentation LUT List Module680
SR DOCUMENT MODULES 680
SR Document Series Module 680
SR DOCUMENT GENERAL MODULE681
SOP Instance Reference Macro 684
Identical Documents Sequence 685
Current Requested Procedure Evidence Sequence and Pertinent Other Evidence Sequence 686
SR Document Content Module 686
Concept Name Code Sequence 696
Continuity of Content 696
SR Content Tree Example (Informative) 697
OBSERVATION CONTEXT ENCODING698
Key Object Selection Modules 700
Key Object Document Series Module700
Key Object Document Module 700
CONTENT MACROS702
Numeric Measurement Macro702
Code Macro 702
Composite Object Reference Macro 703
Image Reference Macro703
Waveform Reference Macro 704
Waveform Reference Macro Attribute Descriptions 704
Spatial Coordinates Macro 704
Spatial Coordinates Macro Attribute Descriptions705
Temporal Coordinates Macro705
Temporal CoordinatesMacro Attribute Descriptions706
RAW DATA SPECIFIC MODULES 707
Raw Data Module 707
Raw Data708
Annex D Codes and Controlled Terminology (Informative) 709
Annex E Explanation of patient orientation (Normative) 711
Annex F Basic Directory Information Object Definition (Normative)723
SCOPE OF THE BASIC DIRECTORY INFORMATION IOD723
PS 3.3 -2003
Page 17
BASIC DIRECTORY IOD OVERVIEW724
Basic directory IOD organization 724
Example of a directory 726
ILLUSTRATION OF THE OVERALL DIRECTORY ORGANIZATION 726
EXAMPLE OF A DICOM DIR FILE STRUCTURE728
BASIC DIRECTORY INFORMATION OBJECT DEFINITION 730
Module table730
Modules of the basic directory information object 730
FILE-SET IDENTIFICATION MODULE 730
DIRECTORY INFORMATION MODULE 731
BASIC DIRECTORY IOD INFORMATION MODEL734
DEFINITION OF SPECIFIC DIRECTORY RECORDS 736
Patient Directory Record Definition738
Study Directory record definition738
Series Directory Record Definition739
Image directory record definition 740
Standalone overlay directory record definition 740
Standalone modality LUT directory record definition741
Standalone VOI LUT directory record definition 741
Standalone curve directory record definition 741
Topic directory record definition742
Visit directory record definition742
Results directory record definition 743
Interpretation directory record definition 743
Study component directory record definition 744
Print Queue Directory Record Definition745
Film session directory record definition 745
Film box directory record definition 745
Basic image box directory record definition 745
Stored Print Directory Record Definition745
RT Dose Directory Record Definition 746
RT Structure Set Directory Record Definition747
RT Plan Directory Record Definition747
RT Treatment Record Directory Record Definition748
Presentation State Directory Record Definition 748
Waveform Directory Record Definition 749
SR Document Directory Record Definition 750
Key Object Document Directory Record Definition 751
SPECIAL DIRECTORY RECORDS 751
Private directory record definition 751
Multi-referenced file directory record definition752
ICON IMAGE KEY DEFINITION 752
Annex G Integration of Modality Worklist and Modality Performed Procedure Step in the Original DICOM Standard (Informative) 754
Annex H Retired 757
Annex I Retired758
Annex J Waveforms (Informative) 759
DOMAIN OF APPLICATION759
USE CASES759
TIME SYNCHRONIZATION FRAME OF REFERENCE 760
WAVEFORM ACQUISITION MODEL 760
PS 3.3 -2003
Page 18
WAVEFORM INFORMATION MODEL 761
HARMONIZATION WITH HL7762
HL7 Waveform Observation762
Channel Definition 763
Timing764
Waveform Data 764
Annotation 764
HARMONIZATION WITH SCP-ECG764
Annex K SR Encoding Example (Informative) 766
Annex L Mammography CAD (Informative)774
MAMMOGRAPHY CAD SR CONTENT TREE STRUCTURE 774
MAMMOGRAPHY CAD SR OBSERVATION CONTEXT ENCODING 776
MAMMOGRAPHY CAD SR EXAMPLES 777
Example 1: Calcification and Mass Detection with No Findings777
Example 2: Calcification and Mass Detection with Findings 779
Example 3: Calcification and Mass Detection, Temporal Differencing with Findings794
Annex M Chest CAD (Informative) 806
Chest CAD SR Content Tree Structure 806
Chest CAD SR Observation Context Encoding 807
Chest CAD SR Examples 808
Example 1: Lung Nodule Detection with No Findings 808
Example 2: Lung Nodule Detection with Findings and Anatomy/Pathology Interpretation809
Example 3: Lung Nodule Detection, Temporal Differencing with Findings 814
Example 4: Lung Nodule Detection in Chest Radiograph, Spatially Correlated with CT 817
Annex N Explanation of Grouping Criteria for Multi-frame Functional Group IODs (Informative) 822
Annex O. Clinical Trial Identification Workflow Examples (Informative) 824
EXAMPLE USE-CASE 824
Annex P Index 825

PS 3.3 - 2003 Page 19

FOREWORD

The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee to develop a standard for Digital Imaging and Communications in Medicine (DICOM). This DICOM Standard was developed according to the NEMA procedures.

This standard is developed in liaison with other standardization organizations including CEN TC251 in Europe and JIRA in Japan, with review also by other organizations including IEEE, HL7 and ANSI in the USA.

The DICOM Standard is structured as a multi-part document using the guidelines established in the following document: ⎯ ISO/IEC Directives, 1989 Part 3 : Drafting and Presentation of International Standards. This document is one part of the DICOM Standard which consists of the following parts: PS 3.1: Introduction and Overview PS 3.2: Conformance

PS 3.3: Information Object Definitions PS 3.4: Service Class Specifications

PS 3.5: Data Structures and Encoding PS 3.6: Data Dictionary

PS 3.7: Message Exchange PS 3.8: Network Communication Support for Message Exchange

PS 3.9: Retired PS 3.10: Media Storage and File Format for Media Interchange

PS 3.11: Media Storage Application Profiles PS 3.12: Formats and Physical Media

PS 3.13: Retired PS 3.14: Grayscale Standard Display Function

PS 3.15: Security Profiles PS 3.16: Content Mapping Resource

PS 3.3 - 2003 Page 20

These parts are related but independent documents. Their development level and approval status may differ. Additional parts may be added to this multi-part standard. PS 3.1 should be used as the base reference for the current parts of this standard.

PS 3.3 - 2003 Page 21

1 Scope and field of application

This Part of the DICOM Standard specifies the set of Information Object Definitions (IODs) which provide an abstract definition of real-world objects applicable to communication of digital medical information. For each IOD, this Part specifies:

⎯ any necessary information for the semantic description of the IOD

⎯ relationships to associated real-world objects relevant to the IOD

⎯ Attributes which describe the characteristics of the IOD

For each IOD, this Part does not specify:

⎯ the nature of any Service Class Definition intended to reference the IOD

⎯ the nature of any interactions which result in the usage of the IOD

This Part is related to other parts of the DICOM Standard in that:

 PS 3.4, Service Class Specifications, specifies application level services by grouping DIMSE services with IODs as defined in this Part;

 PS 3.5, Data Structure and Semantics, defines the data encoding used in the DIMSE Protocol when applied to IODs defined in this Part;

 PS 3.6, Data Dictionary, contains an index by Tag of all IOD Attributes defined in this Part. This index includes the Value Representation and Value Multiplicity for each Attribute;

 PS 3.7, Message Exchange Protocol, defines the DIMSE Services and Protocol which may be applied to IODs defined in this Part.

2 Normative references

The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.

ISO/IEC Directives, 1989 Part 3 - Drafting and Presentation of International Standards

ISO 7498-1, Information Processing Systems - Open Systems Interconnection - Basic Reference Model

ISO/TR 8509, Information Processing Systems - Open Systems Interconnection - Service Conventions

ISO/IEC 2022:1994 Information technology - Character code structure and extension techniques.

AIUM and NEMA Standard for Real-Time Display of Thermal and Mechanical Acoustic Output Indices on Diagnostic Ultrasound Equipment.

PS 3.3 - 2003 Page 22

IEC Standard 61217, Radiotherapy Equipment - Coordinates, Movements and Scales (Reference CEI/IEC 61217: 1996)

ICRU Report 50, Prescribing, Recording, and Reporting Photon Beam Therapy, International Commission on Radiation Units and Measurements, 1993

Breast Imaging Reporting and Data System (BI-RADS), 3rd Edition 1998, American College of Radiology.

ISO 3950-1984, Dentistry - Designation system for teeth and areas of the oral cavity.

ITU-T Recommendation G.711 (1988) - Pulse code modulation (PCM) of voice frequencies

TIS 620-2533 (1990) Thai Characters Code for Information Interchange

ITU-T Recommendation X.509 (03/00), Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks

Note: ITU-T Recommendation X.509 is similar to ISO/IEC 9594-8 1990. However, the ITU-T recommendation is the more familiar form, and was revised in 1993 and 2000, with two sets of corrections in 2001. ITU-T was formerly known as CCITT.

ISO/IEC 10118-3:1998, Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions (RIPEMD-160 reference) Note: The draft RIPEMD-160 specification and sample code are also available at

ftp://ftp.esat.kuleuven.ac.be/pub/bosselae/ripemd

IETF RFC 2437, PKCS #1 RSA Cryptography Specifications Version 2.0 Note: The RSA Encryption Standard is also defined in informative annex A of ISO/IEC 9796, and in Normative Annex A of the CEN/TC251 European Prestandard prENV 12388:1996.

ISO 7498-2, Information processing systems – Open Systems Interconnection – Basic reference Model – Part 2: Security Architecture

ECMA 235, The ECMA GSS-API Mechanism

FIPS PUB 46, Data Encryption Standard

FIPS PUB 81, DES Modes of Operation

IETF, Internet X.509 Public Key Infrastructure; Time Stamp Protocols; March 2000 ISO 8825-1, Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

RFC-2313, PKCS #1: RSA Encryption, Version 1.5, March 1998.

RFC-2630, Cryptographic Message Syntax, June 1999

ANSI X9.52, American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.

PS 3.3 - 2003 Page 23

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 REFERENCE MODEL DEFINITIONS

This Part of the Standard is based on the concepts developed in ISO 7498-1 and makes use of the following terms defined in it:

a. Application Entity

b.Service or Layer Service

This Part of the Standard makes use of the following terms defined in ISO 7498-2:

a. Data Confidentiality

Note: The definition is “the property that information is not made available or disclosed to unauthorized individuals, entities or processes.”

b.
Data Origin Authentication Note: The definition is “the corroboration that the source of data received is as claimed.”
c.
Data Integrity

Note: The definition is “the property that data has not been altered or destroyed in an unauthorized manner.”

d. Key Management

Note: The definition is “the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy.”

3.2 SERVICE CONVENTIONS DEFINITIONS

This Part of the Standard makes use of the following terms defined in ISO/TR 8509:

a. Primitive

3.3 DICOM INTRODUCTION AND OVERVIEW DEFINITIONS

This Part of the Standard makes use of the following terms defined in PS 3.1:

a.
Attribute
b.
Command
c.
Data Dictionary
d.
Message

3.4 DICOM SERVICE CLASS SPECIFICATIONS

This Part of the Standard makes use of the following terms defined in PS 3.4:

I. Preformatted Color Image

3.5 DICOM DATA STRUCTURES AND ENCODING

This Part of the Standard makes use of the following terms defined in PS 3.5:

a.
Data Element
b.
Data Element Tag
c.
Data Element Type
d.
Data Set
e.
Defined Term
f.
Enumerated Value
g.
Sequence of Items
h.
Unique Identifier (UID)

3.6 DICOM MESSAGE EXCHANGE

This Part of the Standard makes use of the following terms defined in PS 3.7:

a.
DICOM Message Service Element (DIMSE)
b.
DIMSE-N Services
c.
DIMSE-C Services

3.7 DICOM UPPER LAYER SERVICE

This Part of the Standard makes use of the following terms defined in PS 3.8:

a. DICOM Upper Layer Service

3.8 DICOM INFORMATION OBJECT

The following definitions are commonly used in this part of the Standard:

  1. Attribute tag: A unique identifier for an Attribute of an Information Object composed of an ordered pair of numbers (a Group Number followed by an Element number).
  2. Composite IOD: an Information Object Definition which represents parts of several entities in the DICOM Application Model. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.
  3. Derived image: an image in which the pixel data was constructed from pixel data of one or more other images (source images).

PS 3.3 - 2003 Page 25

  1. DICOM information model: an Entity-Relationship diagram which is used to model the relationships between the Information Object Definitions representing classes of Real-World Objects defined by the DICOM Application Model.
  2. DICOM application model: an Entity-Relationship diagram used to model the relationships between Real-World Objects which are within the area of interest of the DICOM Standard.
  3. Information entity: that portion of information defined by a Composite IOD which is related to one specific class of Real-World Object. There is a one-to-one correspondence between Information Entities and entities in the DICOM Application Model.
  4. Information object definition (IOD): a data abstraction of a class of similar Real-World Objects which defines the nature and Attributes relevant to the class of Real-World Objects represented.
  5. Module: A set of Attributes within an Information Entity or Normalized IOD which are logically related to each other.
  6. Multi-frame image: Image that contains multiple two-dimensional pixel planes.
  1. Normalized IOD: an Information Object Definition which represents a single entity in the DICOM Application Model. Such an IOD includes Attributes which are only inherent in the Real-World Object that the IOD represents.
  2. Cine run: A set of temporally related frames acquired at constant or variable frame rates. This term incorporates the general class of serialography.

Note: A Cine run is typically encoded as a multi-frame image.

3.8.12 Specialization: Specialization is the replacement of the Type, value range and/or description of an Attribute in a general Module of an IOD, by its Type, value range and/or description defined in a modality-specific Module of an IOD.

Note: The same Attribute may be present in multiple Modules in the same IOD but not specified to be “Specialized”.

  1. Functional Group: A set of logically related Attributes that are likely to vary together. May be used in Multi-frame IODs to describe parameters which change on a per frame basis.
  2. Code Sequence Attribute: Attribute that (usually) includes the string "Code Sequence" in the Attribute Name and has a VR of SQ (Sequence of Items). Its purpose is to encode concepts using code values and optional text meanings from coding schemes. Sections 8.1 through 8.8 specify the Attributes of which the Sequence Items (Attribute Sets) of Code Sequence Attributes are constructed.
  3. CHARACTER HANDLING DEFINITIONS

This part of the standard makes use of the following terms defined in ISO/IEC 2011:1994: PS 3.3 - 2003 Page 26

3.10 RADIOTHERAPY

This Part of the Standard is based on the concepts developed in IEC 61217 and makes use of the following terms defined in it:

3.11 MACROS

  1. Attribute Macro: a set of Attributes that are described in a single table that is referenced by multiple Module or other tables.
  2. DICOM GRAYSCALE STANDARD DISPLAY FUNCTION

This Part of the Standard makes use of the following terms defined in PS 3.14:

a. P-Value

Note: The definition is "A device independent value defined in a perceptually linear grayscale space. The output of the DICOM Presentation LUT is P-Values, i.e. the pixel value after all DICOM defined grayscale transformations have been applied. P-Values are the input to a Standardized Display System."

3.13 CODES AND CONTROLLED TERMINOLOGY DEFINITIONS:

This Part of the Standard makes use of the following terms defined in PS 3.16:

a.
Baseline Context Group Identifier (BCID)
b.
Defined Context Group Identifier (DCID)
c.
Context Group
d.
Context Group Version
e.
Context ID (CID)
f.
Mapping Resource
g.
Relationship Type
h.
DICOM Content Mapping Resource (DCMR)
i.
Template
j.
Template ID (TID)
k.
Value Set
l.
Baseline Template Identifier (BTID)

PS 3.3 - 2003 Page 27

m.
Defined Template Identifier (DTID)
n.
Coding schemes

3.14 REFERENCE MODEL SECURITY ARCHITECTURE DEFINITIONS

This Part of the Standard makes use of the following terms defined in ISO 7498-2:

a. Digital Signature

Note: The definition is “Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of that unit and protect against forgery e.g. by the recipient.”

a. Data Confidentiality

Note: The definition is “the property that information is not made available or disclosed to unauthorized individuals, entities or processes.”

b.
Data Origin Authentication Note: The definition is “the corroboration that the source of data received is as claimed.”
c.
Data Integrity Note: The definition is “the property that data has not been altered or destroyed in an unauthorized manner.”
d.
Key Management

Note: The definition is “the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy.”

3.15 SECURITY DEFINITIONS

This Part of the Standard makes use of the following terms defined in ECMA 235:

a. Security Context

Note: The definition is “security information that represents, or will represent a Security Association to an initiator or acceptor that has formed, or is attempting to form such an association.”

3.16 DICOM SECURITY PROFILES

This part of the Standard makes use of the following terms defined in PS 3.15:

a.
Message Authentication Code
b.
Certificate

PS 3.3 - 2003 Page 28

4 Symbols and abbreviations

The following symbols and abbreviations are used in this Part of the Standard.

ACR ASCII AEANSI BEVBrachyBRHC CCCEN TC251

CCIR Chest CAD

CTV CWDICOM DIMSE DIMSE-C DIMSE-N DRRDVHEPI EPID GTV GyHISPP HL7 ICRU IEIEC IEEE IOD ISO ITU-T

JIRA LUTMAC Mammography CAD

MeV

American College of Radiology American Standard Code for Information Interchange Application Entity American National Standards Institute Beam’s-eye view Brachytherapy Bottom Right Hand Corner Counter-clockwise Comite European de Normalisation-Technical Committee 251-Medical

Informatics Consultative Committee, International Radio Computer-Aided Detection and/or Computer-Aided Diagnosis for chest

radiography Clinical target volume Clockwise Digital Imaging and Communications in Medicine DICOM Message Service Element DICOM Message Service Element-Composite DICOM Message Service Element-Normalized Digitally-reconstructed radiograph Dose-volume histogram Electronic Portal Image Electronic Portal Imaging Device Gross tumor volume Gray Healthcare Information Standards Planning Panel Health Level 7 International Commission on Radiation Units Information Entity International Electrotechnical Commission Institute of Electrical and Electronics Engineers Information Object Definition International Standards Organization International Telecommunications Union – Telecommunications

Standardization Sector Japan Industries Association of Radiation Apparatus Lookup Table Message Authentication Code Computer-Aided Detection and/or Computer-Aided Diagnosis for

Mammography Mega electron Volt

MLC MSDS MUMVNEMA OSI PTV R&V ROI RTSADSCP SCU SIDSOPSSDTLHC UID

PS 3.3 - 2003 Page 29

Multileaf (multi-element) collimator Healthcare Message Standard Developers Sub-Committee Monitor unit Megavolt National Electrical Manufacturers Association Open Systems Interconnection Planning target volume Record and verify Region of interest Radiotherapy Source-axis distance Service Class Provider Service Class User Source-image distance Service-Object Pair Source-skin distance Top Left Hand Corner Unique Identifier

5 Conventions

5.1 ENTITY-RELATIONSHIP MODEL

5.1.1 ENTITY

An entity is used in an Entity-Relationship (E-R) model to represent a Real-World Object, class of Real-World Objects, or DICOM data representation (such as an IOD or Module). An entity is depicted as shown in Figure 5.1-1.

Entity Name

Figure 5.1-1 ENTITY CONVENTION

5.1.2 RELATIONSHIP

A relationship, which defines how entities are related, is depicted as a diamond within this Part of the DICOM Standard as shown in Figure 5.1-2.

PS 3.3 - 2003 Page 30

Figure 5.1-2 RELATIONSHIP CONVENTION

The relationship is read from source to destination entity as indicated by the arrows. The a and b show the source and destination cardinality of the relationship respectively. The following cardinalities are

In a relationship where (a = 1-n, b = 1-n) the values of the source and destination cardinalities may be different. The value "n" simply denotes one or more.

Note: DICOM has added the use of arrows to the E-R diagramming conventions often used in other literature. This has been done to avoid the possibility of inferring an incorrect relationship which can result from reading a relationship in the reverse order of that intended. For example, a relationship "Cat Catches Mouse" could be read "Mouse Catches Cat" if the arrows were not present.

A relationship may be bi-directional (i.e. the relationship is true in both directions). In such a case, the convention used is arrows pointing toward both the source and the destination entities.

5.2 SEQUENCES

Certain Tables in this Standard describe Sequences of Items by using the symbol: '>'. The symbol '>' precedes the Attribute (or Module) Name of the members of an Item. All marked Attributes (or Modules) belong to the generic description of an Item which may be repeated to form a Sequence of Items. This Sequence of Items is nested in the Attribute (or Module) which precedes in the table the first member marked with a '>'.

Note: The following table describes the "Referenced Series Sequences" Attribute as a Sequence of one or more Items where each Item contains the three Attributes marked by a '>'. The Sequence of Items is nested inside the value of the Referenced Series Sequence Attribute. The following Attribute (not marked) is not part of the Items of the Sequence.

PS 3.3 - 2003 Page 31

....

Modality

This notation may be used to create nested hierarchical structures by using '>>' at the second level of nesting and so on.

The Type of the Sequence attribute defines whether the Sequence attribute itself must be present, and the Attribute Description of the Sequence attribute may define whether and how many Items shall be present in the Sequence. The Types of the attributes of the Data Set included in the Sequence, including any conditionality, are specified within the scope of each Data Set, i.e., for each Item present in the Sequence. See PS 3.5.

Notes: 1. Some sections of the Standard often include Attributes within a Sequence of Items under the condition that a Sequence Item is present. For example, as shown in the following table, Requested Procedure ID (0040,1001) has Type 1C and is included under the condition that “Required if Sequence Item is present”:

2. The condition may be omitted since it is redundant with the Type of the Sequence attribute. The above example may be equivalently specified without the conditions, as illustrated in the following table:

PS 3.3 - 2003 Page 32

5.3 TRIPLET ENCODING OF STRUCTURED DATA (RETIRED)

This section has been retired. See Section 8.

5.4 ATTRIBUTE MACROS

Some tables contain references to Attribute Macros. This convention is used in cases where the same Attributes are used in multiple tables or multiple places in one Module. The reference means that the Attributes of the Attribute Macro shall be included in the Module in place of the row that contains the reference to the Attribute Macro.

In some cases, the Attribute Macro is used in a Sequence (the VR of the Data Element in which the Attribute is encoded is SQ, see PS 3.5). When this is done, the reference is preceded by one or more ">" characters. The number of ">" characters indicates the level in the sequence that all of the Attributes in the Attribute Macro occupy.

There may be specialization of the description of the Attributes in the Attribute Macro. In these cases, this specialization is described in the Description column of the Module.

When Attribute Macros are invoked in the definition of Normalized Objects in PS3.3 the specified Requirement Types and Conditions do not apply. In PS3.4 Requirement Types and Conditions have to be specified for both SCU and SCP with each invocation of an Attribute Macro.

Following is an example of this convention.

Table 5.4-1 is an example of a Module table using the Attribute Macro convention.

Table 5.4-1 Example Module Table

Table 5.4-2 is an example of the Attribute Macro referenced in Table 5.4-1.

Table 5.4-2 Example Macro

The contents of the Example Module Table, if it had not been described with the Example Macro would have been as shown in Table 5.4-3

Table 5.4-3 Example Module Table without the Use of an Attribute Macro

PS 3.3 - 2003 Page 33

6 DICOM information model

The DICOM Information Model defines the structure and organization of the information related to the communication of medical images. Figure 6-1 shows the relationships between the major structures of the DICOM Information Model.

Service Class Specification

1

specifies related n

SOP Class(es) 1

defined as 1

1

1 1 Information

Service Group applied to an Object

Definition 1

1 is a group of contains

n

n DIMSE Services or Media StorageAttributes

Services

Figure 6-1MAJOR STRUCTURES OF DICOM INFORMATION MODEL

PS 3.3 - 2003 Page 34

6.1 INFORMATION OBJECT DEFINITION

An Information Object Definition (IOD) is an object-oriented abstract data model used to specify information about Real-World Objects. An IOD provides communicating Application Entities with a common view of the information to be exchanged.

An IOD does not represent a specific instance of a Real-World Object, but rather a class of Real-World Objects which share the same properties. An IOD used to generally represent a single class of Real-World Objects is called a Normalized Information Object. An IOD which includes information about related Real-World Objects is called a Composite Information Object.

6.1.1 COMPOSITE IOD

A Composite IOD is an Information Object Definition which represents parts of several entities included in the DICOM Model of the Real-World. This Model is introduced in Section 7. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.

These related Real-World Objects provide a complete context for the exchanged information. When an instance of a Composite IOD is communicated, this entire context is exchanged between Application Entities. Relationships between Composite IOD Instances shall be conveyed in this contextual information.

The Composite IODs are specified in Annex A.

6.1.2 NORMALIZED IOD

A Normalized IOD is an Information Object Definition which generally represents a single entity in the DICOM Model of the Real-World.

In this Standard, strict definition of Normalized Object Definitions has not been applied. Application of strict definitions would often result in unnecessary complexity and reduced performance of implementations for several applications.

Note: An example is the Print Queue IOD. Attributes from the Basic and Referenced Print Management IODs

are combined in the Print Queue IOD. This allows an SCP to provide all relevant information in a single

N-Get Service Element. Otherwise several Service Elements would be required to return the attributes

from individual Normalized IODs. This requires less network traffic to convey the information, thus

improving system performance.

The Print Queue IOD has been classified as a Normalized IOD to allow operations by DIMSE-N Services since most devices which support the Print Queue Management SOP Class also support the Basic Print Management Meta SOP Class in which the DIMSE-N Service Elements are used. This facilitates efficient implementations of the Print Queue Management SOP Class.

When an instance of a Normalized IOD is communicated, the context for that instance is not actually exchanged. Instead, the context is provided through the use of pointers to related Normalized IOD Instances.

The Normalized IODs are specified in Annex B.

6.2 ATTRIBUTES

The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules which represent a higher level of semantics documented in the Module Specifications found in Annex C.

Attributes are encoded as Data Elements using the rules, the Value Representation and the Value Multiplicity concepts specified in PS 3.5. For specific Data Elements, the Value Representation and Value Multiplicity are specified in the Data Dictionary in PS 3.6.

PS 3.3 - 2003 Page 35

When multiple modules containing the same Attributes(s) are included in an IOD, the Attribute shall be encoded only once into a Data Element.

6.3 ON-LINE COMMUNICATION AND MEDIA STORAGE SERVICES

For on-line communication the DIMSE Services allow a DICOM Application Entity to invoke an operation or notification across a network or a point-to-point interface. DIMSE Services are defined in PS 3.7.

For media storage interchange, Media Storage Services allow a DICOM Application Entity to invoke media storage related operations.

Note: These Media Storage Services are discussed in PS 3.10.

6.3.1 DIMSE-C SERVICES

DIMSE-C Services are services applicable only to a Composite IOD. DIMSE-C Services provide only operation services.

6.3.2 DIMSE-N SERVICES

DIMSE-N Services are services applicable only to a Normalized IOD. DIMSE-N Services provide both operation and notification services.

6.4 DIMSE SERVICE GROUP

A DIMSE Service Group specifies one or more operations/notifications defined in PS 3.7 which are applicable to an IOD.

DIMSE Service Groups are defined in PS 3.4 in the specification of a Service-Object Pair Class.

6.5 SERVICE-OBJECT PAIR (SOP) CLASS

A Service-Object Pair (SOP) Class is defined by the union of an IOD and a DIMSE Service Group. The SOP Class definition contains the rules and semantics which may restrict the use of the services in the DIMSE Service Group and/or the Attributes of the IOD.

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction. This negotiation is performed at association establishment time as described in PS

3.7. An extended negotiation allows Application Entities to further agree on specific options within a SOP Class.

Note: The SOP Class as defined in the DICOM Information Model is equivalent in ISO/OSI terminology to the

Managed Object Class. Readers familiar with object oriented terminology will recognize the SOP Class

operations (and notifications) as comprising the methods of an object class.

6.5.1 NORMALIZED AND COMPOSITE SOP CLASSES

DICOM defines two types of SOP Classes, Normalized and Composite. Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services. Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services.

Note: SOP Class Specifications play a central role for defining DICOM conformance requirements. It allows

DICOM Application Entities to select a well-defined application level subset of the DICOM V3.0 Standard

to which they may claim conformance. See PS 3.2.

6.6 ASSOCIATION NEGOTIATION

Association establishment is the first phase of communication between peer DICOM compliant Application Entities. The Application Entities shall use association establishment to negotiate which SOP Classes can be exchanged and how this data will be encoded.

PS 3.3 - 2003 Page 36

Association Negotiation is defined in PS 3.7.

6.7 SERVICE CLASS SPECIFICATION

A Service Class Specification defines a group of one or more SOP Classes related to a specific function which is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules which allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to SOP Classes as either a Service Class User (SCU) or Service Class Provider (SCP).

Service Class Specifications are defined in PS 3.4.

Note: Such interaction between peer Application Entities work on a 'client/server model'. The SCU acts as the

'client', while the SCP acts as the 'server'. The SCU/SCP roles are determined during association

establishment.

7 DICOM model of the real-world

Figures 7-1a, 7-1b and 7-3 depict the DICOM view of the Real-World which identifies the relevant Real-World Objects and their relationships within the scope of the DICOM Standard. It provides a common framework to ensure consistency between the various Information Objects defined by the DICOM Standard.

Note: The relationship between study and result is complex, involving other Real-World Objects (e.g. the interpreting physician). This Standard does not model these objects.

1

1

Figure 7-1aDICOM MODEL OF THE REAL-WORLD

PS 3.3 - 2003 Page 38

Image Overlay Lookup Table

1

is presented by

1-n

0-n 1-n

uses

1-n 0-n Printer Image Box uses

1

1-n

1-n 0-1 Relates to Presentation LUT

maintains

contains

0-1

1

1-n 0-1 1

Relates to

Film Box

Print Queue Prints

Contains

1-n 1-n1

0-n

0-n

contains

contains

Annotation

0-n

1

Film Session

Print Job

0-1 1

Issues

0-1 1

Issues

Figure 7-1b DICOM MODEL OF THE REAL-WORLD - PRINT

1

1

Figure 7-2aDICOM INFORMATION MODEL Figure 7-2b DICOM INFORMATION MODEL - PRINT

PS 3.3 - 2003 Page 41

Study IOD

1

references

0-n

0-n

0-n

0-n

0-n

0-n

RT Image IOD RT Dose IOD RT Structure Set

RT Plan IOD

IOD

1

0-n

0-n 0-n

0-n 0-1

0-n 1

references

references

references

0-n 0-1 0-n

references

0-n

RT Treatment 0-n 1

1

Record IOD

references

1

0-n

references

0-n 1

references

references

Figure 7-2c DICOM INFORMATION MODEL - RADIOTHERAPY

Figure 7-3. MODEL OF THE REAL WORLD FOR THE PURPOSE OF MODALITY-IS INTERFACE

7.1 DICOM INFORMATION MODEL

The DICOM Information Model is derived from the DICOM Model of the Real-World. The DICOM Information Model presented by Figures 7-2a, 7-2b and 7-2c identify the various IODs specified by this Standard and their relationships. There is not always a one-to-one correspondence between DICOM Information Object Definitions and Real-World Objects. For example a Composite IOD contains Attributes of multiple real-world objects such as series, equipment, frame of reference, study and patient.

The entities in Figures 7-2a, 7-2b and 7-2c correspond to IODs defined in Annexes A through C.

7.2 ORGANIZATION OF ANNEXES A, B AND C

Annex A defines Composite IOD's (e.g. Images, Curves, Overlays) acquired on a number of Modalities (e.g. CT, MR, NM, US, CR, Secondary Capture). These Composite IOD's reference Modules found in Annex C.

Annex B defines Normalized IODs (e.g. Patient, Study, Results, Film Session, Print Job) for a number of Service Classes specified in PS 3.4. These Normalized IODs reference Module definitions found in Annex

C.

7.3 EXTENSION OF THE DICOM MODEL OF THE REAL-WORLD

For the purpose of the Basic Worklist Management Service Class and the Modality Performed Procedure Step SOP Classes an enhancement of the original DICOM Model of the Real-World is made, as depicted in Figure 7-3.

PS 3.3 - 2003 Page 43

Annex G discusses the relationship of this extension to the original DICOM model of the real world.

Figure 7-3 is an abstract description of the real world objects invoked in the Modality-IS Interface. It is not to be seen as a database scheme for an implementation.

Note: The real world model depicted in Figure 7.3 is influenced by the ISIS (Information System - Imaging System) Model. The ISIS Model is being developed by the DICOM Committee, the College of American Pathologists Image Exchange Committee (CAP-IEC), CEN/TC251/WG4/PT4-020: Modality-Information System Interface Project Team, and Health Level Seven (HL7) as the Real World Model for the domain of the Information System - Imaging System interface. The ISIS model is a common mapping of CEN/TC251/WG3/PT-022, CEN/TC251/WG4/PT-020, HL7, CAP-IEC, and ACR-NEMA DICOM Real-World-Models. The semantics of the objects and their attributes in this Standard are described in the ISIS model. This supplement uses only the subset of the ISIS Model that contains objects relevant to the Worklist. The ISIS Model ensures consistency with PT-022, CAP-IEC, and HL7.

7.3.1 Definition of the Extensions of the DICOM Real-World Model

7.3.1.1 PATIENT

A Patient is a person receiving, or registered to receive, healthcare services.

7.3.1.2 SERVICE EPISODE

A Service Episode is a collection of events, aggregated during an interval bounded by start and stop times (e.g. an outpatient visit or a hospitalization). The definition of the start time, stop time, and included events of a Service Episode is entirely arbitrary. A Service Episode is the context in which the treatment or management of an arbitrary subset of a Patient’s medical conditions occurs. In the context of imaging services, a Service Episode may involve one or more Healthcare Organizations (administrative entities that authorize Healthcare Providers to provide services within their legal administrative domain, e.g. hospitals, private physician’s offices, multispecialty clinics, nursing homes). A subset of Service Episode, the Facility Episode, is the collection of events that fall under the accountability of a particular Healthcare Organization. A Service Episode identifies the Certified Health Care Providers who have been delegated responsibility by one or more Healthcare Organizations to provide healthcare services to the Patient. One or more Certified Healthcare Providers (Organizations or individual persons, e.g. physician group practices, individual physicians, technologists, nurses) may be accountable for the healthcare services provided in a Service Episode. The Certified Health Care Providers are accountable to one or more Healthcare Organizations and to the Patient for the outcomes of the services provided. A Service Episode may be associated with one or more physical locations (e.g. different rooms, departments, buildings, or cities). One or more DICOM Visits may be associated with a Service Episode.

Notes: 1. The Service Episode is defined both in the ISIS model and in this extension of the DICOM model of the real world, to ensure consistency with PT3-022, CAP-IEC and HL7. The DICOM Visit is a part of the Service Episode. The Service Episode describes several administrative aspects of healthcare, while the DICOM Visit is limited to the description of one visit of a Patient to a facility.

2. In the context of the Modality Worklist SOP Class, only the DICOM Visit is of relevance, the Service Episode Modules are not defined.

7.3.1.3 IMAGING SERVICE REQUEST

An Imaging Service Request is a set of one or more Requested Procedures selected from a list of Procedure Types. An Imaging Service Request is submitted by one authorized imaging service requester to one authorized imaging service provider in the context of one Service Episode. An Imaging Service Request includes pertinent specific and general information. Each instance of an Imaging Service Request carries the information common to one or more Requested Procedures requested at the same moment. An Imaging Service Request may be associated with one or more DICOM Visits. The existence of an Imaging Service Request will typically result in the creation of one or more Imaging Service Reports and the distribution of Imaging Service Reports to one or more destinations.

PS 3.3 - 2003 Page 44

In the context of the Modality Worklist the information provided by the Imaging Service Request aims at performing one or more imaging procedures, i.e. at acquiring new images. In the context of the General Purpose Worklist the information provided by the Imaging Service Request supports a more general kind of request, e.g. reporting, requesting an image processing procedure on an existing examination, etc.

7.3.1.4 PROCEDURE TYPE

A Procedure Type identifies a class of procedures. In the context of imaging services, a Procedure Type is an item in a catalog of imaging procedures that can be requested and reported upon in an imaging service facility. An instance of a Procedure Type typically has a name and one or more other identifiers. A Procedure Type is associated with one or more Procedure Plans.

Note: The information content of this entity relates to the general identification of a Procedure Type rather than

to its decomposition into the protocol(s) required to perform a specific instance of a Requested Procedure

for a particular Patient.

7.3.1.5 REQUESTED PROCEDURE

A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. This Procedure Plan is defined by the imaging service provider on the basis of the Procedure Plan templates associated with the considered Procedure Type. An Imaging Service Request may include requests for several different Requested Procedures. The purpose of this entity is to establish the association between Imaging Service Requests and Procedure Types, to convey the information that belongs to this association and to establish the relationships between Requested Procedures and the other entities that are needed to describe them. A single Requested Procedure of one Procedure Type is the smallest unit of service that can be requested, reported, coded and billed. Performance of one instance of a Requested Procedure is specified by exactly one Procedure Plan. A Requested Procedure leads to one or more Scheduled Procedure Steps involving Protocols as specified by a Procedure Plan. A Requested Procedure may be associated with one or more DICOM Visits. A Requested Procedure may involve one or more pieces of equipment.

7.3.1.6 SCHEDULED PROCEDURE STEP

A Modality Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plan for a Requested Procedure. A Modality Scheduled Procedure Step prescribes Protocol which may be identified by one or more protocol codes. A Modality Scheduled Procedure Step involves equipment (e.g. imaging Modality equipment, anesthesia equipment, surgical equipment, transportation equipment), human resources, consumable supplies, location, and time (e.g. start time, stop time, duration). While in the context of imaging services the scheduling of a Modality Scheduled Procedure Step might include only a general designation of imaging Modality that could be satisfied by multiple pieces of the same equipment type, the performance of one instance of a Modality Scheduled Procedure Step involves one and only one piece of imaging Modality equipment.

The performance of a Modality Scheduled Procedure Step may result in the creation of zero or more Modality Performed Procedure Step instances.

Notes: 1. The Procedure Step entity is provided to support management of the logistical aspects of procedures

(e.g. materials management, human resources, scheduling). The full definition of the contents of Procedure Steps and protocols according to which they are performed is implementation dependent and is beyond the scope of this Standard.

2. A Modality Scheduled Procedure Step may contribute to more than one Requested Procedure (e.g. a Modality Scheduled Procedure Step requiring an intravenous iodine contrast injection might be shared by an intravenous pyelogram and a CT examination). However, for billing purposes an instance of a Modality Scheduled Procedure Step is typically considered to be a part of only one Requested Procedure.

PS 3.3 - 2003 Page 45

7.3.1.7 PROCEDURE PLAN

A Procedure Plan is a specification that defines the set of Protocols that must be done in order to perform the Scheduled Procedure Steps of a Requested Procedure. Each Scheduled Procedure Step is preformed according to a single Protcol which may be identified by one or more Protocol Codes. The Protocols actually performed during a Procedure Step may differ from those prescribed in the related Procedure Plan. Audit of actually performed Protocols versus the prescribed Procedure Plan is an important element of quality control, but is not specified by this Standard.

Note: The fact that Protocols Codes are in a given order in a Procedure Plan is not evident in Figure 7.3. However, the order of Protocols is represented at the syntax level (i.e. as the sequence of items present in the Protocol Code Sequence (0040,0008)).

7.3.1.8 PROTOCOL

A Protocol is a specification of actions prescribed by a Procedure Plan to perform a specific Procedure Step. A Scheduled Procedure Step contains only one Protocol which may be conveyed by one or more Protocol Codes. Typically, the code or codes identifying a Protocol instance would be selected from a catalog of protocols. Multiple Protocols may not exist in one Scheduled Procedure Step.

7.3.1.9 MODALITY PERFORMED PROCEDURE STEP

A Performed Procedure Step is an arbitrarily defined unit of service that has actually been performed (not just scheduled). Logically it corresponds to a Scheduled Procedure Step, but real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.

Note: For example, two or more Scheduled Procedure Steps, Requested Procedures or Imaging Service Requests may have been generated by different Referring Physicians but may be satisfied be a single Performed Procedure Step at the discretion of a Performing Physician or Operator. Alternatively, a single Scheduled Procedure Step may need to be satisfied by multiple Performed Procedure Steps on different types or instances of equipment, due to clinical need or failure conditions, or over extended periods of time.

It contains information describing the type of procedure actually performed. This information is represented by the Performed Protocol that may be defined by one or more Protocol Codes.

A Requested Procedure results in the creation of zero or more Performed Procedure Steps.

A Scheduled Procedure Step results in the creation of zero or more Performed Procedure Steps.

The Performed Procedure Step contains information about it’s state (e.g. in progress, discontinued or completed).

A Modality Performed Procedure Step is a Performed Procedure Step that results from the acquisition of images from a Patient or other Imaging Subject on a Modality.

It contains information describing the performance of a step of an imaging procedure, including data about the performance of the procedure itself, radiation dose values to which the patient has been exposed if ionizing radiation is in use, and data for billing and material management.

The Modality Performed Procedure Step contains references to zero or more Series of Images and other Composite SOP Instances that may be created as part of the procedure step. A particular Series is part of only one Modality Performed Procedure Step.

7.3.1.10 GENERAL PURPOSE SCHEDULED PROCEDURE STEP

A General Purpose Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plans of one or more Requested Procedures. A General Purpose Scheduled Procedure Step prescribes one Workitem that describes the procedure step to be performed. A General PS 3.3 - 2003 Page 46

Purpose Scheduled Procedure Step involves applications, human resources, location, and time resources (e.g. start time, stop time, duration).

Notes: 1. In this section, application is the generic term used to designate software applications and pieces of devices.

2. The status of a general Purpose Scheduled Procedure Step must not be confused with the status of the Requested Procedure or Imaging Service Request to which it belongs. One General Purpose Scheduled Procedure Step may be completed, but that does not imply that also the related Requested Procedure has reached its completion.

A General Purpose Scheduled Procedure Step contains references to Composite SOP Instances or Performed Procedure Steps, which denote the information to be used for the performance of the General Purpose Scheduled Procedure Step.

7.3.1.11 GENERAL PURPOSE PERFORMED PROCEDURE STEP

A general Purpose Performed Procedure step is an arbitrarily defined unit of service that has actually been performed ( not just scheduled ). Normally it corresponds to one General Purpose Scheduled Procedure step, but real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.

Note: For example, two or more General Purpose Scheduled Procedure Steps, Requested Procedures or

Imaging Service Requests may have been generated by different Referring Physicians but may be

satisfied by a single General Purpose Performed Procedure Step at the discretion of a Performing

Physician or Operator. Alternatively, a single General Purpose Scheduled Procedure step may need to

be satisfied by multiple General Purpose Performed Procedure Steps on different types or instances of

equipment, due to clinical need or failure conditions, or over extended periods of time.

It contains information describing the type of procedure actually performed.

A Requested Procedure results in the creation of zero or more General Purpose Performed Procedure Steps.

A General Purpose Scheduled Procedure Step results in the creation of zero or more General Purpose Performed Procedure Steps.

The General Purpose Performed Procedure Step contains information about its state.

It contains information describing the performance of the general purpose procedure step of a procedure.

The General Purpose Performed Procedure step contains references to zero or more Composite SOP Instances that have been created as part of the procedure step.

7.3.1.12 WORKITEM

A Workitem is one of the tasks prescribed by a Procedure Plan to perform an instance of a Requested Procedure. Each General Purpose Scheduled Procedure Step will contain exactly one Workitem. The code identifying a Workitem instance would be selected from a catalog of workitem types, for example with the value of Image Processing or Interpretation.

7.4 EXTENSION OF THE DICOM MODEL OF THE REAL-WORLD FOR THE GENERAL PURPOSE WORKLIST

For the purpose of the General Purpose Worklist SOP Class in the Worklist Management Service Class an extension of the DICOM Model of the Real-World is made, as depicted in Figures 7.4.a and 7.4.b.

This subset of the real-world model covers the requirements for the General Purpose Worklist SOP Class in the Worklist Management Service Class.

Figures 7.4.a and 7.4.b are an abstract description of the real world objects involved in Workflow Management.

Figure 7.4.a Model of the real world for the purpose of General Purpose Worklist interface

1

0-n

Figure 7.4.b Model of the real world for the purpose of General Purpose Worklist interface

PS 3.3 - 2003 Page 49

7.5 ORGANIZING LARGE SETS OF INFORMATION

For the purpose of accommodating large sets of frames in Multi-frame Image SOP Instances the Real-World Entity Relationship Diagram has been extended to describe the relationships of these instances: Concatenation (see Section 7.5.1) and Dimension Organization (see Section 7.5.2). Figure 7-5.1 depicts the additions to Figure 7-2.

1,n 1

1,n

Spatially or 0,n temporallySeries defines

creates 1,n1 1

1

1

contains

Frame of Reference

1 0,n

contains Concatenation

contains

1

contains

0,n 0,n 1,n

Dimension 1 Specifies 1,n ImageOrganization organization(Multi-frame)of

Figure 7.5-1 EXTENSION OF THE REAL-WORLD MODEL WITH CONCATENATIONS AND DIMENSIONS

7.5.1 CONCATENATION

For implementation specific reasons (such as practical limits on the maximum size of an individual SOP Instance) the content of a multi-frame image may need to be split into more than one SOP Instance. These SOP Instances together form a Concatenation, which is a group of SOP Instances within a Series that is uniquely identified by the Concatenation UID (0020,9133).

7.5.2 DIMENSION ORGANIZATION

The Dimension Organization contains a set of dimensions. A dimension is a set of attributes which change on a per-frame basis in a manner which is known before the image is acquired, which are defined by the generating application and which are especially intended for presentation. Other attributes may PS 3.3 - 2003 Page 50

also change on a per-frame basis but if they are not present in the Dimension Organization, they are not considered significant as a dimension for organizational purposes.

Receiving applications can use the order of dimensions for guidance when presenting images. The first item of the Dimension Index Sequence shall be the slowest varying index.

Note: See Multi-frame Dimension Module section (C.7.6.17) for an example.

7.6 EXTENSION OF THE DICOM MODEL OF THE REAL WORLD FOR CLINICAL TRIALS

The DICOM Model of the Real World is extended for Clinical Trials with the addition of several objects whose relationships to each other and existing DICOM Real World objects are shown in Figure 7.6-1.

Attributes of the Clinical Trial Sponsor, Clinical Trial Protocol, Clinical Trial Subject, and Clinical Trial Site objects are represented in the Clinical Trial Subject Module within the Patient IOD. Attributes of the Clinical Trial Time Point object are represented in the Clinical Trial Study Module within the Study IOD. The Clinical Trial Coordinating Center attribute is represented in the Clinical Trial Series Module within Image IODs.

PS 3.3 - 2003 Page 51

Patient

Clinical Trial Sponsor

1

Figure 7.6-1 – DICOM MODEL OF THE REAL WORLD – CLINICAL TRIALS

7.6.1 Clinical Trial Information Entities

For the purpose of Clinical Trial Information, an extension of the DICOM Model of the Real World is made, as depicted in Figure 7.6-1.

7.6.1.1 Clinical Trial Sponsor

A Clinical Trial Sponsor identifies the agency, group, or institution responsible for conducting the clinical trial and for assigning a Protocol Identifier.

7.6.1.2 Clinical Trial Protocol

A Clinical Trial Protocol identifies the investigational Protocol in which the Subject has been enrolled. The Protocol has a Protocol Identifier and Protocol Name.

7.6.1.3 Clinical Trial Subject

A Clinical Trial Subject identifies the Patient who is enrolled as a Subject in the investigational Protocol.

7.6.1.4 Clinical Trial Site

A Clinical Trial Site identifies the location or institution at which the Subject is treated or evaluated and which is responsible for submitting clinical trial data. Images and/or clinical trial data may be collected for a given Subject at alternate institutions, e.g. follow-up scans at a satellite imaging center, but the Clinical PS 3.3 - 2003 Page 52

Trial Site represents the primary location for Patient management and data submission in the context of a clinical trial.

7.6.1.5 Clinical Trial Time Point

The Clinical Trial Time Point identifies an imaging Study within the context of an investigational protocol. A Time Point defines a set of studies that are grouped together as a clinical time point or submission in a clinical trial.

7.6.1.6 Clinical Trial Coordinating Center

The Clinical Trial Coordinating Center identifies the institution responsible for coordinating the collection, management, processing, and/or analysis of images and associated data for Subjects enrolled in a clinical trial. Within a given Clinical Trial Protocol, there may be multiple Clinical Trial Coordinating Centers, each handling different aspects of the clinical data submitted by the Clinical Trial Sites.

PS 3.3 - 2003 Page 53

8 Encoding of Coded Entry Data

The primary method of incorporating coded entry data in DICOM IODs is the Code Sequence Attribute. Code Sequence Attributes are encoded as a Sequence of Items using a macro which is described in this section. These Attributes typically include the string "Code Sequence" in the Attribute Name. Their purpose is to encode terms by using codes from coding schemes.

Note: In this Standard, Code Sequence Attributes are defined for a variety of concepts, for example: Primary

Anatomic Structure Sequence (0008,2228) and other Attributes to describe anatomy; and Interventional

Drug Code Sequence (0018,0029), to document administration of drugs that have special significance in

Imaging Procedures.

Each Item of a Code Sequence Attribute contains the triplet of Coding Scheme Designator, the Code Value, and Code Meaning. Other optional and conditional attributes may also be present.

For any particular Code Sequence Attributes, the range of codes that may be used for that attribute (the Value Set) may be suggested or constrained by specification of a Context Group. The Module or Template in which the attribute is used will specify whether or not the context group is baseline or defined. A Baseline Context Group lists codes for terms which are suggested and may be used, but are not required to be used. A Defined Context Group lists codes for terms which shall be used if the term is used.

Context Groups are defined in a Mapping Resource, such as the DICOM Content Mapping Resource (DCMR) specified in PS 3.16. Context Groups consist of lists of contextually related coded concepts, including the Code Value (0008,0100) and Coding Scheme Designator (0008,0102). Each concept is unqiue within the Context Group and identified by its Code Value (0008,0100) and Coding Scheme Deisgnator (0008,0102). The Context Group specification identifies whether it is extensible, i.e., whether it may be modified in an Application to use additional terms (see PS 3.16). Whether a Context Group is used as a Baseline or Defined Context Group is defined not in the mapping resource, but rather in the Template or Module in which the Code Sequence Attribute is used.

Context Groups are identified by labels referred to as Context Group Identifiers (CID).

8.1 CODE VALUE

The Code Value (0008,0100) is an identifier that is unambiguous within the Coding Scheme denoted by Coding Scheme Designator (0008,0102) and Coding Scheme Version (0008,0103).

Note: The Code Value is typically not a natural language string, e.g. “T-04000”.

8.2 CODING SCHEME DESIGNATOR AND CODING SCHEME VERSION

The attribute Coding Scheme Designator (0008,0102) identifies the coding scheme in which the code for a term is defined. Standard coding scheme designators used in DICOM information interchange are listed in PS 3.16. Other coding scheme designators, for both private and public coding schemes, may be used.

Further identification of the coding scheme designators used in a SOP Instance may be provided in the Coding Scheme Identification Sequence (0008,0110) (see Section C.12).

Notes: 1. Typical coding schemes used in DICOM include “DCM” for DICOM defined codes, “SNM3” for SNOMED version 3, “SRT” for SNOMED-RT, and “LN” for LOINC.

2. Coding scheme designators beginning with “99” and the coding scheme designator “L” are defined in HL7 V2 to be private or local coding schemes.

PS 3.3 - 2003 Page 54

  1. Most IODs that define the use of coded terms provide for the use of private codes and coding schemes through replacement of Baseline Context Groups or extension of Defined Context Groups. Systems supporting such private code use must provide a mechanism for the configuration of sets of Coding Scheme Designator, Code Value, and Code Meaning to support interoperation of the private codes with other systems.
  2. It is highly recommended that local or non-standard coding schemes be identified in the Coding Scheme Identification Sequence.

The attribute Coding Scheme Version (0008,0103) may be used to identify the version of a coding scheme if necessary to resolve ambiguity in the Code Value (0008,0100) or Code Meaning (0008,0104), or if the Code Value does not appear in all versions of the Coding Scheme identified by the Coding Scheme Designator.

In previous editions of the DICOM Standard, a provisional Coding Scheme Identifier of "99SDM" was used for SNOMED codes that were used in DICOM.

Consequently, when a Coding Scheme Designator (0008,0102) of “99SDM” is encountered, it shall be treated as equivalent to “SNM3” for the purpose of interpreting Code Value (0008,0100).

A Coding Scheme Designator (0008,0102) of “99SDM” or “SNM3” is defined to identify the SNOMED Version 3 Coding Scheme unambiguously, hence the condition for inclusion of Coding Scheme Version (0008,0103) is explicitly not satisfied.

8.3 CODE MEANING

The Code Meaning (0008,0104) is text which has meaning to a human and which conveys the meaning of the term defined by the combination of Code Value and Coding Scheme Designator. Though such a meaning can be “looked up” in the dictionary for the coding scheme, it is encoded for the convenience of applications that do not have access to such a dictionary.

It should be noted that for a particular Coding Scheme Designator (0008,0102) and Code Value (0008,0100), several alternative values for Code Meaning (0008,0104) may be defined. These may be synonyms in the same language or translations of the Coding Scheme into other languages. Hence the value of Code Meaning (0008,0104) shall never be used as a key, index or decision value, rather the combination of Coding Scheme Designator (0008,0102) and Code Value (0008,0100) may be used. Code Meaning (0008,0104) is a purely annotative, descriptive Attribute.

This does not imply that Code Meaning (0008,0104) can be filled with arbitrary free text. Available values from the Coding Scheme or translation in the chosen language shall be used.

8.4 MAPPING RESOURCE

The value of Mapping Resource (0008,0105) denotes the message/terminology Mapping Resource that specifies the Context Group that specifies the Value Set. The Defined Terms for the value of Mapping Resource (0008,0105) shall be:

“DCMR”= “DICOM Content Mapping Resource”, "SDM"= "SNOMED DICOM Microglossary" (Retired).

PS 3.16 specifies the DICOM Content Mapping Resource (DCMR).

Note: Unless otherwise specified, the DCMR is the source of all Context Groups and Templates specified in this Standard.

PS 3.3 - 2003 Page 55

8.5 CONTEXT GROUP VERSION

Context Group Version (0008,0106) conveys the version (as a datetime value) of the Context Group identified by Context Identifier (0008,010F).

8.6 CONTEXT IDENTIFIER

The value of Context Identifier (0008,010F) identifies the Context Group defined by Mapping Resource (0008,0105) from which the values of Code Value (0008,0100) and Code Meaning (0008,0104) were selected , or to which the Code Value (0008,0100) and Code Meaning (0008,0104) have been added as a private Context Group extension (see Section 8.7) .

Note: Privately defined Context Groups are not identified by Context Identifier and Mapping Resource.

8.7 CONTEXT GROUP EXTENSIONS

Context Group Extension Flag (0008,010B) may be used to designate a Code Value/Code Meaning pair as a selection from a private extension of a Context Group. If the Context Group Extension Flag is present, and has a value of “Y”, Context Group Extension Creator UID (0008,010D) shall be used to identify the person or organization who created the extension to the Context Group. Context Group Local Version (0008,0107) conveys an implementation-specific private version datetime of a Context Group that contains private extensions

Notes: 1. These Attributes provide the means for implementations to extend code sets conveniently, while preserving referential integrity with respect to the original Context Group Version.

2. The locally-defined (private) value of Context Group Local Version (0008,0107) typically would be a more recent date than the standard value of Context Group Version (0008,0106) specified in the standard message/terminology Mapping Resource that defines the Context Group.

8.8 STANDARD ATTRIBUTE SETS FOR CODE SEQUENCE ATTRIBUTES

Table 8.8-1 specifies the default set of Attributes encapsulated in the Items of Code Sequence Attributes. These Attributes comprise the Code Sequence Macro.

Note: The instruction “ Include ‘Code Sequence Macro’ Table 8.8-1” may be used in an Information Object

Definition as a concise way to indicate that the attributes of Table 8.8-1 are included in the specification

of the Attribute Set of a Sequence of items. Additional constraints on the Code Sequence Data Element

(such as a Context Group that defines the value set) may be appended to the “Include ‘Code Sequence

Macro’ Table 8.8-1” instruction.

The default specifications of this Section are overridden within the scope of a Sequence Item or Code Sequence Attribute or IOD by corresponding specifications defined within the scope of that Sequence Item or Code Sequence Attribute or IOD. Additional Attributes may also be specified by the instantiation of the macro.

The Basic Coded Entry Attributes fully define a Coded Entry. If it is desired to convey the list from which a code has been chosen, then the optional Enhanced Encoding Mode Attributes may also be sent.

Table 8.8-1 Common Attribute Set for Code Sequence Attributes(Invoked as “Code Sequence Macro”)

9 TEMPLATE IDENTIFICATION MACRO

A Template for SR Documents defines a set of constraints on the relationships and content (Value Types, Codes, etc.) of Content Items that reference such a Template. Specific Templates for SR Documents are defined either by the DICOM Standard or by users of the Standard for particular purposes.

The presence of a referenced Template reflects that the referenced Template was used in the creation of the associated Content Item. The use by the SR Storage SCP of Templates is beyond the scope of the DICOM Standard. Usage of Templates for SR Documents may improve comparability of essential data, facilitate data-entry and revisions, enable automatic processing and simplify presentation of information to the user.

PS 3.3 - 2003 Page 57

Table 9-1 specifies the set of Attributes that identify Templates. These Attributes comprise the Template Macro. Attribute Descriptions in Table 9-1 refer to similar attributes of the Code Sequence Macro in Section 8.8 of this Part.

Table 9-1 Template Identification Macro Attributes Description

10 MISCELLANEOUS MACROS

10.1 PERSON IDENTIFICATION MACRO

This Macro may be invoked to specify a coded representation of a person such as a healthcare worker, and the organization to which they are responsible.

Notes: 1. This macro is typically invoked within a Sequence Item used to identify an individual such as a physician or a device operator.

  1. The free-text name of the individual is not included in this Macro since there are already widely used specific Attributes to hold such values.
  2. No Baseline, Defined or Enumerated Context Groups are defined nor is any particular coding scheme specified. In practice, workers are usually identified by using a locally or nationally specific coding scheme. For example, a local Coding Scheme Designator might be used and the individual’s internal hospital ID number user in Code Value.
  3. The organization is specified by either a coded sequence or a free text name but not both.

Table 10-1 Person Identification Macro Attributes Description

PS 3.3 - 2003 Page 59

Annex A Composite information object definitions(Normative)

A.1 ELEMENTS OF AN INFORMATION OBJECT DEFINITION

Each Composite Information Object Definition is composed of the following Sections

a.
IOD Description
b.
IOD Entity-Relationship Model
c.
IOD Module Table
d.
Optionally, a Functional Group Macros Table used by the Multi-frame Functional Groups Module

Sections A.1.1 through A.1.3 of this document define the requirements of a) through d) above.

A.1.1 IOD Description

This Section provides a brief description of the IOD. Specifically, this description includes:

 The Real-World Object which is represented by the IOD

 Information as to the scope of the represented object if appropriate

A.1.2 IOD Entity-Relationship Model

This Section of an IOD provides the Entity-Relationship (E-R) Model which depicts the relationships of the components or Information Entities (IE) of the specified IOD. It forms an IOD specific information model. This E-R model provides the complete context of how the composite instance information shall be interpreted when a composite instance is exchanged between two DICOM Application Entities.

Even though composite instances are sent as discrete individual components, each Composite Instance IOD E-R Model requires that all composite instances that are part of a specific study shall share the same context. That is, all composite instances within a specific patient study share the same patient and study information; all composite instances within the same series share the same series information; etc.

Figure A.1-1 is the DICOM Composite Instance IOD Information Model. It applies to all of the Composite Instance IODs defined in Annex A. However, a subset of this model may be specified by each individual Composite Instance IOD to accurately define the context for specific composite instance exchange.

Sections A.1.2.1 through A.1.2.10 describe the Information Entities (IE) which comprise the Composite Instance IODs defined in this Annex.

Figure A.1-1DICOM COMPOSITE INSTANCE IOD INFORMATION MODEL

Each Series shall contain at least one Curve IE, VOI Lookup Table IE, Overlay IE, Modality LUT IE, Stored Print IE, Presentation State IE, SR Document IE or Image IE.

A.1.2.1 PATIENT IE

The Patient IE defines the characteristics of a patient who is the subject of one or more medical studies that produce medical images.

The Patient IE is modality independent.

A.1.2.2 STUDY IE

The Study IE defines the characteristics of a medical study performed on a patient. A study is a collection of one or more series of medical images, presentation states, SR documents, overlays and/or curves that are logically related for the purpose of diagnosing a patient. Each study is associated with exactly one patient.

A study may include composite instances that are created by a single modality, multiple modalities or by multiple devices of the same modality.

PS 3.3 - 2003 Page 61

The Study IE is modality independent.

A.1.2.3 SERIES IE

The Series IE defines the Attributes that are used to group composite instances into distinct logical sets. Each series is associated with exactly one Study.

The following criteria group composite instances into a specific series:

a.
All composite instances within a series must be of the same modality
b.
If a specific Composite Instance IOD specifies the support of a Frame of Reference IE, all composite instances within the series shall be spatially or temporally related to each other; therefore, each series is associated with exactly one Frame of Reference IE
c.
If a specific Composite Instance IOD specifies the support of the Equipment IE, all composite instances within the series shall be created by the same equipment; therefore, each series is associated with exactly one Equipment IE
d.
All composite instances within a series shall have the same series information

Overlays and Curves may be grouped into a Series with or without Images. The Equipment IE and Frame of Reference IE are irrelevant to the Overlay IE and Curve IE.

Presentation States shall be grouped into Series without Images (i.e. in a different Series from the Series containing the Images to which they refer). The Frame of Reference IE is irrelevant to the Presentation State IE.

Note: The Series containing Presentation States and the Series containing the Images to which they refer are both contained within the same Study.

Waveforms shall be grouped into Series without Images. A Frame of Reference IE may apply to both Waveform Series and Image Series.

SR Documents shall be grouped into Series without Images. The Frame of Reference IE does not apply to SR Document Series.

A.1.2.4 EQUIPMENT IE

The Equipment IE describes the particular device that produced the series of composite instances. A device may produce one or more series within a study. The Equipment IE does not describe the data acquisition or image creation Attributes used to generate the composite instances within a series. These Attributes are described in the composite instance specific IEs (e.g. the Image IE).

A.1.2.5 FRAME OF REFERENCE IE

The Frame of Reference IE identifies the coordinate system that conveys spatial and/or temporal information of composite instances in a series.

When present, a Frame of Reference IE may be related to one or more series. In this case, it provides the ability to spatially or temporally relate multiple series to each other.

A.1.2.6 IMAGE IE

The Image IE defines the Attributes that describe the pixel data of an image. The pixel data may be generated as a direct result of patient scanning (termed an Original Image) or the pixel data may be derived from the pixel data of one or more other images (termed a Derived Image). An image is defined by its image plane, pixel data characteristics, gray scale and/or color mapping characteristics, overlay planes and modality specific characteristics (acquisition parameters and image creation information).

An image is related to a single series within a single study.

PS 3.3 - 2003 Page 62

The pixel data within an Image IE may be represented as a single frame of pixels or as multiple frames of pixel data. The frames of a Multi-frame image (a cine run or the slices of a volume) are sequentially ordered and share a number of common properties. A few Attributes may vary between frames (eg.-Time, Angular Displacement, Slice Increment). All common Image IE Attributes refer to the first frame of a multiple frame image.

Overlay, Lookup Table and Curve data may be included within an Image IE only if this information is directly associated with the image.

A.1.2.7 OVERLAY IE

The Overlay IE defines the Attributes that describe an independent set of Overlay Planes. The Overlay IE may represent in a bit-map format, graphics or text and is used to indicate such items as region of interest, reference marks and annotations. These Overlay Planes may or may not be coincident with an image. If the Overlay Plane is coincident with an image, sufficient information shall be available to allow an overlay to be presented at a display station superimposed on a particular image with which it is associated. An Overlay IE shall be related to only one Series IE.

An Overlay Plane may be represented as a single frame (when associated with a single frame image) or as multiple frames of overlay planes (when associated with a Multi-frame image).

Notes: 1. Examples of independent overlay planes are:

a) line drawings which illustrate the equipment and patient setup prescribed

b) line drawings which represent anatomy, pointers and text

c) drawings showing the layout of images and text fields for filming formats

2. The Overlay IE is similar in concept to the 'Graphics Data Set' defined by earlier versions of this Standard.

A.1.2.8 CURVE IE

A Curve is used to represent graphical data that can be specified as a series of connected points. Curve data may or may not be superimposed on a coincident image. An independent Curve, like an independent Overlay, can exist as would an image without any Pixel Data. Curves can be used to specify multi-dimensional graphs, regions of interest, and annotation. Curve Data is not compressed in any of the DICOM Standard Transfer Syntaxes specified in PS 3.5.

Each curve is specified as a series of connected points. One or more Curves shall be described by using one or more even numbered Repeating Groups (5000-501E,eeee) whose attributes are described in the Curve Module. The Type of Data (50xx,0020) contained in the Curve shall be specified. For independent Curves, the Curve Identification Module is used to identify the Curve.

A.1.2.9 MODALITY LUT IE

The Modality LUT IE defines the Attributes that describe the transformation of manufacturer dependent pixel values into pixel values which are manufacturer independent (e.g. Hounsfield units for CT, Optical Density for film digitizers, etc.). The Modality LUT may be contained within an image, or a presentation state which references an image, or as a Standalone Modality LUT which references an image. When the transformation is linear, the Modality LUT is described by Rescale Slope (0028,1053) and Rescale Intercept (0028,1052). When the transformation is non-linear, the Modality LUT is described by Modality LUT Sequence (0028,3000).

A.1.2.10 VOI LUT IE

The VOI LUT IE defines the Attributes that describe the transformation of the modality pixel values into pixel values that are meaningful for print, display, etc. This transformation is applied after any Modality LUT. The VOI LUT may be contained within an image, or a presentation state that references an image, or as a Standalone VOI LUT which references an image. When the transformation is linear, the VOI LUT is described by the Window Center (0028,1050) and Window Width (0028,1051). When the transformation is non-linear, the VOI LUT is described by VOI LUT Sequence (0028,3010).

PS 3.3 - 2003 Page 63

A.1.2.11 PRESENTATION STATE IE

The Presentation State IE defines how a referenced image (or images) will be presented (e.g. displayed) in a device independent grayscale space (i.e. in P-Values), and what graphical annotations and spatial and grayscale contrast transformations will be applied to the referenced image pixel data.

A.1.2.12 WAVEFORM IE

The Waveform IE represents a multi-channel time-based digitized waveform. The waveform consists of measurements of some physical qualities (e.g., electrical voltage, pressure, gas concentration, or sound), sampled at constant time intervals. The measured qualities may originate, for example, in any of the following sources:

a.the anatomy of the patient,

b.
therapeutic equipment (e.g., a cardiac pacing signal or a radio frequency ablation signal),
c.
equipment for diagnostic synchronization (e.g., a clock or timing signal used between distinct devices),

d.the physician’s voice (e.g., a dictated report).

The sample data within a Waveform IE may represent one or more acquired channels. Several signal channels acquired at the same sampling rate can be multiplexed (by interleaving samples) in a single multiplex group. (See also Annex J.)

A.1.2.13 SR DOCUMENT IE

The SR Document IE defines the Attributes that describe the content of an SR Document. These include semantic context as well as Attributes related to document completion, verification and other characteristics. An SR Document SOP Instance is related to a single Series within a single Study.

A.1.2.14 MR Spectroscopy IE

The MR Spectroscopy IE defines the attributes that describe the data of a MR spectroscopy acquisition created by a magnetic resonance spectroscopy device.

A.1.2.15 Raw Data IE

The Raw Data IE defines the attributes that describe a data set that may be used for further processing to produce image data or other data.

Note: For example, raw data may be used with CT and MR systems to reconstruct sets of images or for MR to reconstruct spectroscopic data. The format of the raw data is vendor specific.

A.1.3 IOD Module Table and Functional Group Macro Table

This Section of each IOD defines in a tabular form the Modules comprising the IOD. The following information must be specified for each Module in the table:

⎯ The name of the Module or Functional Group

⎯ A reference to the Section in Annex C which defines the Module or Functional Group

⎯ The usage of the Module or Functional Group; whether it is:

⎯ Mandatory (see A.1.3.1) ⎯ Conditional (see A.1.3.2) ⎯ User Option (see A.1.3.3) The Modules referenced are defined in Annex C.

PS 3.3 - 2003 Page 64

A.1.3.1 MANDATORY MODULES

For each IOD, Mandatory Modules shall be supported per the definitions, semantics and requirements defined in Annex C.

A.1.3.2 CONDITIONAL MODULES

Conditional Modules are Mandatory Modules if specific conditions are met. If the specified conditions are not met, this Module shall not be supported; that is, no information defined in that Module shall be sent.

A.1.3.3 USER OPTION MODULES

User Option Modules may or may not be supported. If an optional Module is supported, the Attribute Types specified in the Modules in Annex C shall be supported.

A.1.4 Overview of the Composite IOD Module Content

Tables A.1-1 and A.1-2 provide an overview of the Modules used throughout the Composite IODs. This table is for informative purposes only. It is based on the IOD definitions found in the remaining Sections of Annex A that are normative.

PS 3.3 - 2003 Page 66

PS 3.3 - 2003 Page 67 PS 3.3 - 2003 Page 68

PS 3.3 - 2003 Page 69

* The notation next to M and U indicates a special condition for these modules. Refer to the corresponding Information Object Definitions in this Annex for details.

Notes: 1. The original US Image IOD and US multi-frame IOD, and the associated US and US multi-frame Storage SOP Class UID have been retired. New US and US multi-frame Image IODs are defined, as shown in Table A.1-1 which includes the Palette Color Lookup Table module.

2. The original NM Image IOD and the associated NM Storage SOP Class UID have been retired. A completely new NM Image IOD is defined, as shown in Table A.1-1.

* The notation next to M and U indicates a special condition for these modules. Refer to the corresponding Information Object Definitions in this Annex for details.

PS 3.3 - 2003 Page 76

A.2 COMPUTED RADIOGRAPHY IMAGE INFORMATION OBJECT DEFINITION

A.2.1 CR Image IOD Description

The Computed Radiography (CR) Image Information Object Definition specifies an image that has been created by a computed radiography imaging device.

Note: Digital Luminescence Radiography is an equivalent term for computed Radiography.

A.2.2 CR Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the CR Image IOD. The Frame of Reference IE, Overlay IE, Modality LUT IE, VOI LUT IE and Curve IE are not components of the CR Image IOD.

A.2.3 CR Image IOD Module Table

Table A.2-1 CR IMAGE IOD MODULES

A.3 COMPUTED TOMOGRAPHY IMAGE INFORMATION OBJECT DEFINITION

A.3.1 CT Image IOD Description

The Computed Tomography (CT) Image Information Object Definition (IOD) specifies an image that has been created by a computed tomography imaging device.

PS 3.3 - 2003 Page 77

A.3.2 CT image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the CT Image IOD. The Overlay IE, Modality LUT IE, VOI LUT IE and Curve IE are not components of the CT Image IOD.

A.3.3 CT Image IOD Module Table

Table A.3-1 CT IMAGE IOD MODULES

A.4 MAGNETIC RESONANCE IMAGE INFORMATION OBJECT DEFINITION

A.4.1 MR Image IOD Description

The Magnetic Resonance (MR) Image Information Object Definition (IOD) specifies an image that has been created by a magnetic resonance imaging device.

A.4.2 MR image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the MR Image IOD. The Overlay IE, Modality LUT IE, VOI LUT IE and Curve IE are not components of the MR Image IOD.

A.4.3 MR Image IOD Module Table

Table A.4-1 MR IMAGE IOD MODULES

A.5 NUCLEAR MEDICINE IMAGE INFORMATION OBJECT DEFINITION

A.5.1 NM Image IOD Description

The Nuclear Medicine (NM) Image Information Object Definition (IOD) specifies an image that has been created by a nuclear medicine imaging device. This includes data created by external detection devices that create images of the distribution of administered radioactive materials in the body. Depending on the specific radio pharmaceutical administered and the particular imaging procedure performed, problems involving changes in metabolism, function, or physiology can be investigated and various regional pathologies can be studied.

A.5.2 NM Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the NM Image IOD. The Modality LUT IE and VOI LUT IE are not components of the NM Image IOD.

A.5.3 NM Image IOD Module Table (Retired)

Section A.5.3 was defined in a previous version of the DICOM Standard. The Section is now retired.

PS 3.3 - 2003 Page 80

A.6 ULTRASOUND IMAGE INFORMATION OBJECT DEFINITION

A.6.1 US Image IOD Description

The Ultrasound (US) Image Information Object Definition specifies an image that has been created by an ultrasound imaging device.

A.6.2 US Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the US Image IOD. The Overlay IE, Modality LUT IE and VOI LUT IE are not components of the US Image IOD.

A.6.3 US Image IOD Module Table (Retired)

Section A.6.3 was defined in a previous version of the DICOM Standard. The Section is now retired.

Note: For the purpose of conveying ultrasound protocol data management information it is recommended that the Performed Protocol Code Sequence (0040,0260) be assigned the code value(s) of the performed ultrasound protocol, if any. The Baseline Context Group for these code values is Context ID 12001 (defined in PS 3.16).

PS 3.3 - 2003 Page 82

A.6.4.1 Mutually Exclusive IEs

The Image and Curve IEs are mutually exclusive. Each SOP Instance using this IOD shall contain exactly one of these IEs.

A.7 ULTRASOUND MULTI-FRAME IMAGE INFORMATION OBJECT DEFINITION

A.7.1 US Image IOD Description

The Ultrasound (US) Multi-frame Image Information Object Definition specifies a Multi-frame image that has been created by an ultrasound imaging device.

A.7.2 US Multi-Frame Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Application Information Model that directly reference the US Multi-frame Image IOD. The Overlay IE, Modality LUT IE and VOI LUT IE are not components of the US Multi-frame Image IOD.

A.7.3 US Image IOD Module Table (Retired)

Section A.7.3 was defined in a previous version of the DICOM Standard. The Section is now retired.

Note: For the purpose of conveying ultrasound protocol data management information it is recommended that the Performed Protocol Code Sequence (0040,0260) be assigned the code value(s) of the performed ultrasound protocol, if any. The Baseline Context Group for these code values is Context ID 12001 (defined in PS 3.16).

PS 3.3 - 2003 Page 84

A.7.4.1 Mutually Exclusive IEs

The Image and Curve IEs are mutually exclusive. Each SOP Instance using this IOD shall contain exactly one of these IEs.

A.8 SECONDARY CAPTURE IMAGE INFORMATION OBJECT DEFINITION

The Secondary Image (SC) Image Information Object Definition (IOD) specifies images that are converted from a non-DICOM format to a modality independent DICOM format.

Examples of types of equipment that create Secondary Capture Images include:

a.Video interfaces that convert an analog video signal into a digital image

b.
Digital interfaces that are commonly used to transfer non-DICOM digital images from an imaging device to a laser printer
c.
Film digitizers that convert an analog film image to digital data

d.Workstations that construct images that are sent out as a screen dump

e.
Scanned documents and other bitmap images including hand-drawings
f.
Synthesized images that are not modality-specific, such as cine-loops of 3D reconstructions

Originally, a single, relatively unconstrained, single-frame SC Image IOD was defined in the DICOM Standard. Though this IOD is retained and not retired since it is in common use, more specific IODs for particular categories of application are also defined.

The following IODs are all multi-frame. A single frame image is encoded as a multi-frame image with only one frame. The multi-frame SC IODs consist of:

-
Multi-frame Single Bit Secondary Capture Image IOD
-
Multi-frame Grayscale Byte Secondary Capture Image IOD
-
Multi-frame Grayscale Word Secondary Capture Image IOD
-
Multi-frame True Color Secondary Capture Image IOD

A.8.1 SC Image Information Objection Definition

A.8.1.1 SC Image IOD Description

The Secondary Image (SC) Image Information Object Definition (IOD) specifies single-frame images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format.

Note: The use of this IOD is deprecated, and other more specific SC Image IODs should be used.

A.8.1.2 SC Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Secondary Capture Image IOD. The Frame of Reference IE and Curve IE are not components of this IOD.

A.8.2 Multi-frame Single Bit SC Image Information Object Definition

A.8.2.1 Multi-frame Single Bit SC Image IOD Description

The Multi-frame Single Bit Secondary Capture (SC) Image Information Object Definition (IOD) specifies images that are converted from a non-DICOM format to a modality independent DICOM format.

This IOD is typically used for scanned documents and bitmap images of hand drawings.

A.8.2.2 Multi-frame Single Bit SC Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Secondary Capture Image family of IODs. The Frame of Reference IE, Overlay IE, Modality LUT IE, VOI LUT IE and Curve IE are not components of this IOD.

A.8.2.3 SC Image IOD Module Table

Table A.8-2 MULTI-FRAME SINGLE BIT SC IMAGE IOD MODULES

A.8.2.4 Multi-frame Single Bit SC Image IOD Content Constraints

In the Image Pixel Module, the following constraints apply:

-Samples per Pixel (0028,0002) shall be 1

-Photometric Interpretation (0028,0004) shall be MONOCHROME2

-
Bits Allocated (0028,0100) shall be 1
-
Bits Stored (0028,0101) shall be 1

-High Bit (0028,0102) shall be 0

-Pixel Representation (0028,0103) shall be 0

-Planar Configuration (0028,0006) shall not be present

Note: As a consequence of these attribute values, single bit pixels are packed eight to a byte as defined by the encoding rules in PS 3.5.

The VOI LUT module shall not be present.

The Overlay module shall not be present.

PS 3.3 - 2003 Page 87

A.8.3 Multi-frame Grayscale Byte SC Image Information Object Definition

A.8.3.1 Multi-frame Grayscale Byte Image IOD Description

The Multi-frame Grayscale Byte Secondary Capture (SC) Image Information Object Definition (IOD) specifies Grayscale Byte images that are converted from a non-DICOM format to a modality independent DICOM format.

This IOD is typically used for screen captured images for modalities that have pixel values of 8 bits, but may also be appropriate for scanned grayscale documents.

A.8.3.2 Multi-frame Grayscale Byte SC Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Secondary Capture Image family of IODs. The Frame of Reference IE, Overlay IE, Modality LUT IE and Curve IE are not components of this IOD.

A.8.3.3 Multi-frame Grayscale Byte SC Image IOD Module Table

Table A.8-3 MULTI-FRAME GRAYSCALE BYTE SC IMAGE IOD MODULES

PS 3.3 - 2003 Page 88

A.8.3.4 Multi-frame Grayscale Byte SC Image IOD Content Constraints

The VOI LUT module is required if the VOI LUT stage is not an identity transformation. Support for both window and LUT is mandatory. The output grayscale space is defined to be in P-Values.

Note: If the VOI LUT module is absent, then the stored pixel values are in P-Values.

In the Image Pixel Module, the following constraints apply:

-Samples per Pixel (0028,0002) shall be 1

-Photometric Interpretation (0028,0004) shall be MONOCHROME2

-
Bits Allocated (0028,0100) shall be 8
-
Bits Stored (0028,0101) shall be 8

-High Bit (0028,0102) shall be 7

-Pixel Representation (0028,0103) shall be 0

-Planar Configuration (0028,0006) shall not be present The Overlay module shall not be present.

A.8.4 Multi-frame Grayscale Word SC Image Information Object Definition

A.8.4.1 Multi-frame Grayscale Word SC Image IOD Description

The Multi-frame Grayscale Word Secondary Capture (SC) Image Information Object Definition (IOD) specifies Grayscale Word images that are converted from a non-DICOM format to a modality independent DICOM format.

This IOD is typically used for screen captured images for modalities that have pixel values greater than 8 bits.

A.8.4.2 Multi-frame Grayscale Word SC Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Secondary Capture Image family of IODs. The Frame of Reference IE, Overlay IE, Modality LUT IE and Curve IE are not components this IOD.

A.8.4.3 Multi-frame Grayscale Word SC Image IOD Module Table

Table A.8-4 MULTI-FRAME GRAYSCALE WORD SC IMAGE IOD MODULES

A.8.4.4 Multi-frame Grayscale Word SC Image IOD Content Constraints

The VOI LUT module is required if the VOI LUT stage is not an identity transformation. Support for both window and LUT is mandatory. The output grayscale space is defined to be in P-Values.

Note: If the VOI LUT module is absent, then the stored pixel values are in P-Values.

In the Image Pixel Module, the following constraints apply:

-Samples per Pixel (0028,0002) shall be 1

-Photometric Interpretation (0028,0004) shall be MONOCHROME2

-Bits Allocated (0028,0100) shall be 16

- Bits Stored (0028,0101) shall be greater than or equal to 9 and less than or equal to 16

-High Bit (0028,0102) shall be one less than Bits Stored (0028,0101)

-Pixel Representation (0028,0103) shall be 0

-Planar Configuration (0028,0006) shall not be present PS 3.3 - 2003 Page 90

The Overlay module shall not be present. Unused high bits shall be filled with zeroes.

A.8.5 Multi-frame True Color SC Image Information Object Definition

A.8.5.1 Multi-frame True Color Image IOD Description

The Multi-frame True Color Secondary Capture (SC) Image Information Object Definition (IOD) specifies True Color images that are converted from a non-DICOM format to a modality independent DICOM format.

This IOD is typically used for screen captured or synthetic images where true color is used, but may also be appropriate for scanned color documents.

A.8.5.2 Multi-frame True Color SC Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Secondary Capture Image family of IODs. The Frame of Reference IE, Overlay IE, Modality LUT IE, VOI LUT IE and Curve IE are not components of the this IOD.

A.8.5.3 Multi-frame True Color SC Image IOD Module Table

Table A.8-5 MULTI-FRAME TRUE COLOR SC IMAGE IOD MODULES

A.8.5.4 Multi-frame True Color SC Image IOD Content Constraints

The VOI LUT module shall not be present.

PS 3.3 - 2003 Page 91

In the Image Pixel Module, the following constraints apply:

-Samples per Pixel (0028,0002) shall be 3

-Photometric Interpretation (0028,0004) shall be RGB for uncompressed or lossless compressed transfer syntaxes, and YBR_FULL_422 for lossy compressed transfer syntaxes

Note: Future lossless and lossy transfer syntaxes may lead to the need for new definitions and choices for Photometric Interpretation, such as the proposed RC T (Reversible Color Transformation) used in JPEG 2000.

-
Bits Allocated (0028,0100) shall be 8
-
Bits Stored (0028,0101) shall be 8

-High Bit (0028,0102) shall be 7

-Pixel Representation (0028,0103) shall be 0

- Planar Configuration (0028,0006) shall be 0 (color-by-pixel) if Photometric Interpretation

(0028,0004) is RGB The Overlay module shall not be present.

A.9 STANDALONE OVERLAY INFORMATION OBJECT DEFINITION

A.9.1 Standalone Overlay IOD Description

A Standalone Overlay IOD is the specification of an overlay that may be related to an Image, but also may have its own existence within a Series. The Standalone Overlay IOD is modality independent. It provides a mechanism to convey bit-mapped text, graphical information, etc. included in a Series.

A.9.2 Standalone Overlay IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Standalone Overlay IOD. The Frame of Reference IE, Image IE, Modality LUT IE, VOI LUT IE and Curve IE are not components of the Standalone Overlay IOD.

A.9.3 Standalone Overlay IOD Module Table

Table A.9-1 STANDALONE OVERLAY IOD MODULES

PS 3.3 - 2003 Page 92

Note: The Attribute Overlay Data (60xx,3000) allows for overlay data to be encoded in the pixel data in Group 7FE0H. For this Standalone Overlay IOD, Group 7FE0H does not exist and therefore the overlay data is contained in the Overlay Data Attribute.

A.10 STANDALONE CURVE INFORMATION OBJECT DEFINITION

A.10.1 Standalone Curve IOD Description

A Standalone Curve IOD is the specification of an curve that may be related to an Image, but also may have its own existence within a Series. The Standalone Curve IOD is modality independent.

A.10.2 Standalone Curve IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Standalone Curve IOD. The Frame of Reference IE, Overlay IE, Modality LUT IE, VOI LUT IE and Image IE are not components of the Standalone Curve IOD.

A.10.3 Standalone Curve IOD Module Table

Table A.10-1 STANDALONE CURVE IOD MODULES

PS 3.3 - 2003 Page 93

A.11 BASIC STUDY DESCRIPTOR INFORMATION OBJECT DEFINITION

A.11.1 Basic Study Descriptor IOD Description

A Basic Study Descriptor IOD is the specification of an abstract information model of summary information for a Study, which may be exchanged between connecting devices that claim conformance to the DICOM Standard. This Basic Study Descriptor is intended to be modality independent. It is intended to provide a simple "directory" for a study to explicitly convey references to the content of a study.

A.11.2 Basic Study Descriptor Entity-Relationship Model

The E-R model for the Basic Study Descriptor Information Object Definition is shown in Figure A.11-1.

1

n

Figure A.11-1 BASIC STUDY DESCRIPTOR INFORMATION OBJECT DEFINITION E-R MODEL

A.11.3 Basic Study Descriptor IOD Module Table

Table A.11-1 BASIC STUDY DESCRIPTOR IOD MODULE TABLE

PS 3.3 - 2003 Page 94

A.12 STANDALONE MODALITY LUT INFORMATION OBJECT DEFINITION

A.12.1 Standalone Modality LUT IOD Description

The Standalone Modality LUT IOD specifies one or more Modality LUTs that are related to an Image.

A.12.2 Standalone Modality LUT IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Standalone Modality LUT IOD. The Frame of Reference IE, Overlay IE, Curve IE, VOI LUT IE and Image IE are not components of the Standalone Modality LUT IOD.

A.12.3 Standalone Modality LUT IOD Module Table

Table A.12-1 STANDALONE MODALITY LUT IOD MODULES

A.13 STANDALONE VOI LUT INFORMATION OBJECT DEFINITION

A.13.1 Standalone VOI LUT IOD Description

The Standalone VOI LUT IOD specifies one or more VOI LUTs that are related to an Image.

A.13.2 Standalone VOI LUT IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Standalone VOI LUT IOD. The Frame of Reference IE, Overlay IE, Curve IE, Modality LUT IE and Image IE are not components of the Standalone VOI LUT IOD.

PS 3.3 - 2003 Page 96

A.14 X-RAY ANGIOGRAPHIC IMAGE INFORMATION OBJECT DEFINITION

A.14.1 XA Image IOD Description

This Section defines the Information Object for single plane X-Ray Angiographic Imaging that includes those data elements and information objects necessary for the interchange of digital X-Ray Angiographic data. This includes images of the heart and all blood vessels.

The XA IOD share a significant amount of common information with the XRF IOD. The differences between the two IODs are that the XRF Image IOD includes a tomography module; and the two IODs utilize different methods to specify positioner angles. The XRF Image IOD contains a single column angulation Data Element that uses an equipment based coordinate system, while XA Image IOD c-arm positioner angles are specified in a patient based coordinate system. RF applications that support a patient-based coordinate system with cranial/caudal, LAO/RAO angles may utilize the XA IOD.

The XA IOD is also applicable to clinical areas other than angiography (e.g. Interventional Procedures, Myelography, Biopsy/Localization, and Neurology).

Note: 1. For the purpose of X-Ray Angiography (XA), this IOD can be used to encode a single frame image, or a Cine Run encoded in a single multi-frame image.

  1. A typical study might include all the images generated between the time a patient gets on and gets off the procedure table. As several separable diagnostic or therapeutic processes may occur during a single study (e.g., pre-intervention CA, left ventriculography, and post-intervention CA), a series may be defined as comprising a set of images (single or Multi-Frame) associated with one such process within a study.
  2. This IOD can be used to encode a single plane acquisition, or one plane of a biplane acquisition.

A.14.2 XA Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Application Information Model that directly reference the X-Ray Angiographic Image IOD, with exception of the Frame of Reference and Modality LUT entities, which are not used. Additionally, "Image" in Figure A.1-1 may represent a Single Frame or a Multi-Frame image. A frame denotes a two-dimensional organization of pixels recorded as a single exposure.

PS 3.3 - 2003 Page 98

  1. X-RAY ANGIOGRAPHIC BI-PLANE IMAGE INFORMATION OBJECT DEFINITION (RETIRED)
  2. X-RAY RF IMAGE INFORMATION OBJECT DEFINITION

A.16.1 XRF Image IOD Description

The focus for this X-Ray RF Image IOD (XRF IOD) is to address the requirements for image transfer found in general Radiofluoroscopic applications performed on a table with a column. For applications performed on X-Ray RF acquisition systems that support a patient based coordinate system with cranial/caudal, LAO/RAO angles, etc. the XA Image IOD may be used.

Note: An example of a case where the XA IOD may be preferred to the RF IOD are RF acquisition

system equipped with an X-Ray source and an image Receptor positioned by what is generally

called a c-arm (e.g. Interventional Procedures, Myelography, Biopsy, and Neurology).

This Section defines the Information Object for X-Ray Radiofluoroscopic Imaging that includes those data elements and information objects necessary for the interchange of digital X-Ray RF Image data. The XRF IOD is applicable to X-Ray acquisition systems equipped with an image receptor whose plane is parallel to the table plane where the patient is. This Table has in general the ability to be tilted. Furthermore the X-Ray source may be supported by a column that can be angulated to adjust the incidence of the X-Ray beam on the image receptor plan. An equipment based coordinated system is used to track these angles.

Notes: 1. For the purpose of X-Ray Radiofluoroscopy, this IOD can be used to encode a single frame image, or a cine run encoded in a single multi-frame image.

2. A typical study might include all the images generated between the time a patient gets on and gets off the procedure table. As several separable diagnostic or therapeutic processes may occur during a single study, a series may be defined as comprising a set of images (single or Multi-Frame) associated with one such process within a study.

A.16.2 XRF Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Application Information Model that directly reference the X-Ray RF Image IOD, with exception of the Frame of Reference entity that is not used. Additionally, "Image" in figure A.1-1 may represent a Single Frame or a Multi-Frame image. A frame denotes a two-dimensional organization of pixels recorded as a single exposure.

Note: When a Study (or Study Component) contains a number of Multi-frame images that do not need to be grouped under different Series, a single Series may be used with a series number containing an arbitrary value (e.g. 1).

  1. XRF Image IOD Module Table
  2. RT IMAGE INFORMATION OBJECT DEFINITION

Table A.16-1 - XRF IMAGE IOD MODULES

PS 3.3 - 2003 Page 100

A.17.1 RT Image IOD Description

The focus for this Radiotherapy Image IOD (RT Image IOD) is to address the requirements for image transfer found in general radiotherapy applications performed on conventional simulators, virtual simulators, and portal imaging devices. Such images have a conical imaging geometry and may either be acquired directly from the device, or digitized using a film digitizer. They may or may not have superimposed curves describing beam limiting device (collimator) openings, beam modifying devices, patient structures and target volumes. Numeric beam data parameters may also be recorded with the image, indicating the parameter values at the time the image was taken or created.

A.17.2 RT Image IOD entity-relationship model

The E-R model for the RT Image IOD is illustrated in Figure A.17-1.

1,n Series 1

Figure A.17-1—DICOM RT Image IOD information model

Notes: 1. The inclusion of the Multi-Frame module allows for the expression of time-dependent image series or multiple exposures of identical beam geometries (i.e. multiple exposure portal images). If a time-dependent series of images (such as port images or DRRs) is represented the Cine module is used to indicate this. This would subsequently allow analysis of patient movement during treatment. Multiple exposure images allow individual images of treatment ports and open field ports to be grouped into a single multi-frame image.

  1. The Modality LUT module has been included to allow the possibility of conversion between portal image pixel values and dose transmitted through the patient. The VOI LUT module has been included to allow the possibility of translation between stored pixel values (after the Modality LUT has been applied if specified) and display levels.
    1. The Curve module has been included to allow the possibility of storing one or more curves overlaid with a given image. Generally these curves would represent patient structures, target volumes, or beam limiting device (collimator) openings, although they could also be used to store other data such as axis information. Such curves would be stored in pixel units (i.e. the coordinates would represent pixel indices in the image data). For example, patient structures might have the following attribute assignments:
    2. Note that there is no facility for representing multi-frame curves (i.e. all curves are interpreted as being related to the first image frame in a multi-frame image). Curves other than patient structures might also be represented using the HIST, POLY or TABL curve types (see C.10.2.1).
  2. The Equipment module contains information describing the equipment used to acquire or generate the RT Image (such as a portal imager, conventional simulator or treatment planning system). However, the equipment attributes in the RT Image module describe the equipment on which the treatment has been or will be given, typically an electron accelerator.
  3. For RT Images that contain no relevant pixel data, such as BEV images without DRR information, Pixel Data (7FE0,0010) should be filled with a sequence of zeros.
  4. The Frame of Reference module has been included to allow the indication of spatial association of two or more RT Image instances (e.g. where the images have been acquired in the same frame of reference, or have been resampled to share the same frame of reference). If the Frame of Reference occurs within a SOP Instance within a given series, then all SOP Instances within that series will be spatially related. For example, two RT Images may share the same Frame of Reference if they are located on the same physical plane, as determined by the treatment machine Gantry Angle (300A,011E) and source to image plane distance specified by

RT Image SID (3002,0026).

PS 3.3 - 2003 Page 103

A.18 RT DOSE INFORMATION OBJECT DEFINITION

A.18.1 RT Dose IOD Description

The focus for this Radiotherapy Dose IOD (RT Dose IOD) is to address the requirements for transfer of dose distributions calculated by radiotherapy treatment planning systems. These distributions may be represented as 2D or 3D grids, as isodose curves, or as named or unnamed dose points scattered throughout the volume. This IOD may also contain dose-volume histogram data, single or multi-frame overlays, audio annotations, and application-defined lookup tables. This IOD does not provide for definition of doses in beam or other coordinate systems. The application is responsible for transforming data in other, non-patient based coordinate systems to the patient based coordinate system described in C.7.6.2.1.1.

A.18.2 RT Dose IOD entity-relationship model

The E-R model for the RT Dose IOD is illustrated in Figure A.18-1.

Figure A.18-1—DICOM RT Dose IOD information model

A.18.3 RT Dose IOD Module Table Table A.18.3-1—RT DOSE IOD MODULES

Notes: 1. Within the RT Dose IOD, the RT Dose module supports 2D and 3D dose grids. The Structure Set, ROI Contour and RT Dose ROI modules together support isodose curves and points, and the RT DVH module supports dose-volume histogram data. They are not mutually exclusive: all four representations may be included in a single instance of the object or they may be included in any combination. Product Conformance Statements should clearly state which of these mechanisms is supported and under what conditions.

2. The RT Dose IOD has been defined as a composite IOD, separate from the RT Plan IOD. This has been done for the following reasons:

PS 3.3 - 2003 Page 105

–
to allow for the multiplicity of possible dose calculations using beam models for the same basic plan,
–
to avoid undesirable transmission of large amounts of data with the treatment plan, and
–
to accommodate the fact that CT Simulation and other “beam geometry” generating devices that use the RT Plan IOD do not have or require access to this data, either for transmission or storage.

A.19 RT STRUCTURE SET INFORMATION OBJECT DEFINITION

A.19.1 RT Structure Set IOD Description

The focus for this Radiotherapy Structure Set IOD (RT Structure Set IOD) is to address the requirements for transfer of patient structures and related data defined on CT scanners, virtual simulation workstations, treatment planning systems and similar devices. This IOD may also contain audio curve annotations.

A.19.2 RT Structure Set IOD entity-relationship model

The E-R model for the RT Structure Set IOD is illustrated in Figure A.19-1.

Figure A.19-1—DICOM RT Structure Set IOD information model

A.19.3 RT Structure Set IOD Module Table Table A.19.3-1—RT STRUCTURE SET IOD MODULES

PS 3.3 - 2003 Page 107

A.20 RT PLAN INFORMATION OBJECT DEFINITION

A.20.1 RT Plan IOD Description

The focus for this Radiotherapy Plan IOD (RT Plan IOD) is to address the requirements for transfer of treatment plans generated by manual entry, a virtual simulation system, or a treatment planning system before or during a course of treatment. Such plans may contain fractionation information, and define external beams and/or brachytherapy application setups. This IOD may also contain audio curve annotations.

A.20.2 RT Plan IOD entity-relationship model

The E-R model for the RT Plan IOD is illustrated in Figure A.20-1.

Figure A.20-1—DICOM RT Plan IOD information model

A.20.3 RT Plan IOD Module Table Table A.20.3-1—RT PLAN IOD MODULES

Note: The RT Structure Set referenced in Referenced Structure Set Sequence (300C,0060) of the RT General Plan Module may contain more than one item in the Referenced Frame of Reference Sequence (3006,0010) in the Structure Set Module. In this case, it is highly recommended that the Frame of Reference Module be supplied in the RT Plan object, to unambiguously specify the frame of reference of the RT Plan contents.

A.20.3.1 RT FRACTION SCHEME MODULE

The RT Fraction Scheme module is structured to be used together with the RT Beams or RT Brachy Application Setups module. If beams are referenced in the RT Fraction Scheme module, all such beams shall be included in the RT Beams module if it is present. Similarly, if brachy application setups are referenced in the RT Fraction Scheme module, all such setups shall be included in the RT Brachy Application Setups module if it is present. However, the RT Fraction

PS 3.3 - 2003 Page 109

Scheme module can be used without the RT Beams or RT Brachy Application Setups modules if no beams or brachy application setups are referenced, and the RT Beams or RT Brachy Application Setups modules can also be used without the RT Fraction Scheme module if no fraction scheme information is available.

A.20.3.2 RT PRESCRIPTION MODULE

The RT Prescription module provides for the inclusion of dose prescription information pertinent to the complete plan, which may comprise several fraction schemes, themselves consisting of many beams.

A.20.3.3 RT TOLERANCE TABLES MODULE

The RT Tolerance Tables module provides information concerning machine tolerances as they apply to the whole treatment plan. Tolerances are applied by reference to a tolerance table within the RT Tolerance Tables module for beams contained within the RT Beams module.

A.20.3.4 RT PATIENT SETUP MODULE

The RT Patient Setup module provides information concerning patient setup parameters and fixation devices as they apply to the whole treatment plan. Patient setup information within the RT Patient Setup module is referenced by beams contained within the RT Beams module.

PS 3.3 - 2003 Page 110

A.21 POSITRON EMISSION TOMOGRAPHY IMAGE INFORMATION OBJECT DEFINITION

A.21.1 PET Image IOD Description

The Positron Emission Tomography (PET) Image Information Object Definition specifies an image that has been created by a Positron Tomograph imaging device, including dedicated PET cameras and Nuclear Medicine imaging devices operating in coincidence mode. This includes data created by external detection devices that create images of the distribution of administered radioactive materials, specifically positron emitters, in the body. Depending on the specific radiopharmaceuticals administered and the particular imaging procedure performed, problems involving changes in metabolism, function, or physiology can be investigated and various region pathologies can be studied. For these problems, quantitation of image data in absolute activity and physiological units is important. In addition, the PET Image IOD specifies attenuation (transmission) images used for correction and anatomical reference of emission images.

A.21.2 PET Image IOD Entity-Relationship Model

The E-R model in Section A.1.2 of this part depicts those components of the DICOM Information Model that directly reference the PET Image IOD. The overlay IE, modality LUT IE, VOI LUT IE, and curve IE are not components of the PET Image IOD.

A.21.3 PET Image IOD Module Table

Table A.21.3-1 - PET IMAGE IOD MODULES

PS 3.3 - 2003 Page 111

A.22 STANDALONE PET CURVE INFORMATION OBJECT DEFINITION

A.22.1 Standalone PET Curve IOD Description

A standalone PET curve IOD is the specification of a PET curve that may be related to an image, but also may have its own existence within a PET Series.

A.22.2 Standalone PET Curve IOD Entity-Relationship Model

The E-R model in Section A.1.2 of this part depicts those components of the DICOM Information Model that directly reference the standalone PET curve IOD. The frame of reference IE, overlay IE, modality LUT IE, VOI LUT IE and Image IE are not components of the standalone PET curve IOD.

A.22.3 Standalone PET Curve IOD Module Table

Table A.22.3-1 - STANDALONE PET CURVE IOD MODULES

A.23 STORED PRINT INFORMATION OBJECT DEFINITION

A.23.1 IOD Description

The Stored Print IOD describes all the print parameters to print a single film. The Stored Print IOD contains one or more references to Image SOP Instances. There is a many to one relationship between the Stored Print IOD and the Printer IOD.

Images referenced by the Stored Print IOD shall be Preformatted Grayscale or Preformatted Color Images or other grayscale images where all grayscale transformations up to and including VOI LUT have been applied.

PS 3.3 - 2003 Page 112

A.23.2 Stored Print IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the Stored Print IOD. The Frame of Reference IE, Overlay IE, Curve IE, VOI LUT IE, and Modality LUT IE are not components of the Stored Print IOD.

A.23.3 IOD Module Table

Table A.23-1 STORED PRINT IOD MODULES

A.24 HARDCOPY GRAYSCALE IMAGE INFORMATION OBJECT DEFINITION

A.24.1 IOD Description

The Hardcopy Grayscale IOD is an abstraction of a printable 8 or 12 bit grayscale image where annotation, overlays, graphics may be burned in and where the LUT operations up to and including VOI LUT have already been performed.

Notes: 1. A hardcopy grayscale image corresponds with a Preformatted Grayscale Image (see PS 3.4) and is a specialization of the Secondary Capture Image.

2. The optional Annotation List and Image Overlay Box Modules in the Stored Print IOD provide additional overlay, graphic, and annotation information that will be burnt into the printed image only if both the SCU and SCP support the Attributes in these Modules. See the Pull Print Request N-CREATE Behavior Section in PS 3.4.

A.24.2 Hardcopy Grayscale Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that are related to the Hardcopy Grayscale Image IOD.

The Overlay Plane Module (C.9.2) was previously in this IOD. Its use in this IOD has been retired. See PS 3.3-1998.

A.25 HARDCOPY COLOR IMAGE INFORMATION OBJECT DEFINITION

A.25.1 IOD Description

The Hardcopy Color IOD is an abstraction of a printable 8 bit color image where annotation, overlays, and graphics may be burned in.

Note : A hardcopy color image corresponds with a Preformatted Color Image (see PS 3.4 ) and is a specialization of the Secondary Capture Image.

A.25.2 Hardcopy Color Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that are related to the Hardcopy Color Image IOD.

A.25.3 IOD Module Table

Table A.25-1 HARDCOPY COLOR IMAGE IOD MODULES

The Overlay Plane Module (C.9.2) was previously in this IOD. Its use in this IOD has been retired. See PS 3.3-1998.

A.26 DIGITAL X-RAY IMAGE INFORMATION OBJECT DEFINITION

A.26.1 DX Image IOD Description

The Digital X-Ray (DX) Image Information Object Definition specifies an image that has been created by a digital projection radiography imaging device.

Notes: 1. This includes but is not limited to: chest radiography, linear and multi-directional tomography, orthopantomography and skeletal radiography. Acquisition of image data may include but is not limited to: CCD-based sensors, stimulable phosphor imaging plates, amorphous selenium, scintillation based amorphous silicon and secondary capture of film-based images.

2. Specific IODs are defined for intra-oral radiography and mammography that further specialize the DX IOD.

A DX image shall consist of the result of a single X-Ray exposure, in order to ensure that the anatomical and orientation attributes are meaningful for the image, permitting safe annotation, appropriate image processing and appropriate dissemination.

Notes: 1. This requirement specifically deprecates the common film/screen and Computed Radiography practice of making multiple exposures on different areas of a cassette or plate by using lead occlusion between exposures. Such acquisitions could be separated and transformed into multiple DX images during an appropriate quality assurance step by an operator.

2. This requirement does not deprecate the acquisition of multiple paired structures during a single exposure, provided that they can be described by the relevant orientation Attributes. For example, an AP or PA projection of both hands side by side is typically obtained in a single exposure, and can be described by a Patient Orientation (0020,0020) of R\H or L\H since both hands are in the same traditional Anatomical Position. See Annex E.

The DX Image IOD is used in two SOP Classes as defined in PS 3.4 Storage Service Class, a SOP Class for storage of images intended for presentation, and a SOP Class for storage of

PS 3.3 - 2003 Page 115

images intended for further processing before presentation. These are distinguished by their SOP Class UID and by the Enumerated Value of the mandatory Attribute in the DX Series Module, Presentation Intent Type (0008,0068).

A.26.2 DX Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 depicts those components of the DICOM Information Model that directly reference the DX Image IOD.

A.26.3 DX Image IOD Module Table

Table A.26-1 DIGITAL X-RAY IMAGE IOD MODULES

Notes: 1. The Overlay Plane requirement is determined by the presence of “graphic annotation”. Graphic annotation includes user or machine drawn graphics or text (such as computer assisted diagnosis) to indicate regions of interest or descriptions. It specifically does not include patient or image identification or technique information that is defined in other Attributes of the IOD..

  1. The Device and Therapy Modules are User optional, though it is desirable that, if present, they are stored by an SCP. It is recognized that in some cases the digital image acquisition system will not have a user interface or direct connection that allows acquisition of these parameters, even if device or therapy have been used.
  2. The Frame of Reference, X-Ray Collimator, DX Positioning and DX Tomo Acquisition Modules are User optional, though it is desirable that, if present, they are stored by an SCP. It is recognized that in some cases the parameters of the mechanical devices used for collimation, positioning and tomography may not be available to a digital image acquisition system that is not integrated with the X-Ray generation and positioning system.
  3. The Acquisition Context Module is mandatory, but may be empty. The intent is that all Storage SCPs will preserve any information present, without requiring acquisition systems to be required to generate any contents, or requiring display systems to use the information for annotation (which is beyond the scope of DICOM).
  4. Expectations on what an SCP of a SOP Class based on this IOD will store may be determined by evaluating a Conformance Statement of the form defined in PS 3.2 that specifies the level of conformance to the Storage SOP Classes as defined in PS 3.4. For example, Level 2 (Full) conformance indicates that all standard and optional attributes will be stored and may be accessed.
  5. The Histogram Module may contain a single or multiple statistical representations of the pixel data used to derive the VOI LUT Module, or intended to be used to derive or replace the VOI LUT Module. The Histogram Module may contain statistics of a subset of the stored image pixel data (such as from a cropped area or region of interest that is not the full field of view) that are useful for deriving a better VOI LUT than might be derived from the statistics obtained from the entire stored pixel data.
  6. The Specimen Identification Module is User optional, because although its Attributes may be helpful for identification and correlation with Pathology Information Systems, much specimen radiography, including forensic radiography, is performed with conventional clinical X-Ray equipment that is not likely to support specific specimen identification features.
  7. The VOI LUT Module Attributes and behaviour are further specialized in the DX Image Module.

A.26.4 Overlay Plane Module

If the Overlay Plane Module is present, any Overlays defined in that Module shall store the overlay data in Overlay Data (60xx,3000), and not any unused high bits in Pixel Data (7FE0,0010).

PS 3.3 - 2003 Page 117

A.27 DIGITAL MAMMOGRAPHY X-RAY IMAGE INFORMATION OBJECT DEFINITION

A.27.1 Digital Mammography X-Ray Image IOD Description

The Digital Mammography X-Ray Image Information Object Definition specifies an image that has been created by a digital mammography projection radiography imaging device.

Note: It meets all of the requirements of the DX IOD in A.26 in addition to those specified in this section.

The Digital Mammography Image IOD is used in two SOP Classes as defined in PS 3.4 Storage Service Class, a SOP Class for storage of images intended for presentation, and a SOP Class for storage of images intended for further processing before presentation. These are distinguished by their SOP Class UID and by the Enumerated Value of the mandatory Attribute in the DX Series Module, Presentation Intent Type (0008,0068).

  1. Digital Mammography X-Ray Image IOD Module Table
  2. Overlay Plane Module

If the Overlay Plane Module is present, any Overlays defined in that Module shall store the overlay data in Overlay Data (60xx,3000), and not any unused high bits in Pixel Data (7FE0,0010).

A.28 DIGITAL INTRA-ORAL X-RAY IMAGE INFORMATION OBJECT DEFINITION

A.28.1 Digital Intra-oral X-Ray Image IOD Description

The Digital Intra-oral X-Ray Image Information Object Definition specifies an image that has been created by an intra-oral projection radiography imaging device.

Note: It meets all of the requirements of the DX IOD in A.26 in addition to those specified in this section.

PS 3.3 - 2003 Page 120

The Digital Intra-oral X-Ray Image IOD is used in two SOP Classes as defined in PS 3.4 Storage Service Class, a SOP Class for storage of images intended for presentation, and a SOP Class for storage of images intended for further processing before presentation. These are distinguished by their SOP Class UID and by the Enumerated Value of the mandatory Attribute in the DX Series Module, Presentation Intent Type (0008,0068).

  1. Digital Intra-oral X-Ray Image IOD Module Table
  2. Overlay Plane Module

Table A.28-1 DIGITAL INTRA-ORAL X-RAY IMAGE IOD MODULES

If the Overlay Plane Module is present, any Overlays defined in that Module shall store the overlay data in Overlay Data (60xx,3000), and not any unused high bits in Pixel Data (7FE0,0010).

A.29 RT BEAMS TREATMENT RECORD INFORMATION OBJECT DEFINITION

A.29.1 RT Beams Treatment Record IOD Description

The focus for this Radiotherapy Beams Treatment Record IOD (RT Beams Treatment Record IOD) is to address the requirements for transfer of treatment session reports generated by a treatment verification system during a course of external beam treatment, with optional cumulative summary information. It may also be used for transfer of treatment information during delivery.

A.29.2 RT Beams Treatment Record IOD entity-relationship model

The E-R model for the RT Beams Treatment Record IOD is illustrated in Figure A.29-1.

PS 3.3 - 2003 Page 122

Patient 1

is the subject of

1,n

1

contains

1,n

Series

creates 1,n

1 1

Equipment contains

0,n

RT Beams Treatment Record

Figure A.29-1—DICOM RT Beams Treatment Record IOD information model A.30 RT BRACHY TREATMENT RECORD INFORMATION OBJECT DEFINITION

A.30.1 RT Brachy Treatment Record IOD Description

The focus for this Radiotherapy Brachy Treatment Record IOD (RT Brachy Treatment Record IOD) is to address the requirements for transfer of treatment session reports generated by a treatment verification system during a course of Brachytherapy treatment, with optional cumulative summary information. It may also be used for transfer of treatment information during delivery.

A.30.2 RT Brachy Treatment Record IOD entity-relationship model

The E-R model for the RT Brachy Treatment Record IOD is illustrated in Figure A.Y-1.

PS 3.3 - 2003 Page 124

Patient 1

is the subject of

1,n

1

contains

1,n

Series

creates 1,n

1 1

Equipment contains

0,n

RT Brachy Treatment Record

Figure A.30-1—DICOM RT Brachy Treatment Record IOD information model

  1. RT Brachy Treatment Record IOD Module Table Table A.30.3-1—RT Brachy Treatment Record IOD Modules
  2. RT TREATMENT SUMMARY RECORD INFORMATION OBJECT DEFINITION

A.31.1 RT Treatment Summary Record IOD Description

The focus for this Radiotherapy Treatment Summary Record IOD (RT Treatment Summary Record IOD) is to address the requirements for transfer of cumulative summary information, normally generated at the completion of a course of treatment.

A.31.2 RT Treatment Summary Record IOD entity-relationship model

The E-R model for the RT Treatment Summary Record IOD is illustrated in Figure A.31-1.

PS 3.3 - 2003 Page 126

Patient 1

is the subject of

1,n

1 contains 1,n

Series

creates 1,n

1 1 Equipment contains 0,nRT Treatment Summary Record

Figure A.31-1—DICOM RT Treatment Summary Record IOD information model

A.31.3 RT Treatment Summary Record IOD Module Table Table A.31.3-1—RT Treatment Summary Record IOD Modules

PS 3.3 - 2003 Page 127

A.32 VISIBLE LIGHT IMAGE INFORMATION OBJECT DEFINITIONS

A.32.1 VL Endoscopic Image Information Object Definition

A.32.1.1 VL Endoscopic Image IOD Description

The VL Endoscopic Image IOD specifies the Attributes of Single-frame VL Endoscopic Images.

A.32.1.2 VL Endoscopic Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 of this Part depicts those components of the DICOM Information Model that directly reference the VL Endoscopic Image IOD, with exception of the Curve, VOI LUT, Frame of Reference and Modality LUT entities, which are not used. Additionally, Image in figure A.1.2 of PS3.3 represents a Single Frame image. A frame denotes a two-dimensional organization of pixels recorded as a single exposure. Table A.32.1-1 specifies the Modules of the VL Endoscopic Image IOD.

Notes: 1. An endoscopic procedure might include multiple series of single frame endoscopic images as well as one or more additional series of related diagnostic images. The procedure might involve multiple Performed Procedure Steps, multiple endoscopes, and multiple anatomic regions and might be supervised, performed, and/or interpreted by one or more individuals.

2. Several distinct diagnostic or therapeutic processes might occur during an endoscopic procedure. For example: Endoscopic examination of duodenal mucosa, biopsy, lavage, or biliary stone removal.

Table A.32.1-1 VL ENDOSCOPIC IMAGE IOD MODULES

A.32.1.3 VL Endoscopic Image IOD Content Constraints

A.32.1.3.1 Modality

The value of Modality (0008,0060) shall be ES.

PS 3.3 - 2003 Page 128

A.32.2 VL Microscopic Image Information Object Definition

A.32.2.1 VL Microscopic Image IOD Description

The VL Microscopic Image IOD specifies the Attributes of Single-frame VL Microscopic Images. Slide Coordinates shall not be encoded with this IOD.

A.32.2.2 VL Microscopic Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 of this Part depicts those components of the DICOM Information Model that directly reference the VL Microscopic Image IOD, with exception of the Curve, VOI LUT, Frame of Reference and Modality LUT entities, which are not used. Additionally, Image in figure A.1.2 of PS3.3 represents a Single Frame image. A frame denotes a two-dimensional organization of pixels recorded as a single exposure. Table A.32.1-2 specifies the Modules of the VL Microscopic Image IOD.

Notes: 1. A microscopy procedure might include multiple series of single frame VL Microscopic Images as well as one or more additional series of related diagnostic images. The procedure might involve multiple Performed Procedure Steps, multiple microscopes, and multiple anatomic regions and might be supervised, performed, and/or interpreted by one or more individuals.

2. Several distinct diagnostic or therapeutic processes might occur during a single procedure. For example: Histologic staining of the same section with multiple special stains.

Table A.32.1-2 VL MICROSCOPIC IMAGE IOD MODULES

A.32.2.3 VL Microscopic Image IOD Content Constraints

A.32.2.3.1 Modality

The value of Modality (0008,0060) shall be GM.

PS 3.3 - 2003 Page 129

A.32.3 VL Slide-Coordinates Microscopic Image Information Object Definition

A.32.3.1 VL Slide-Coordinates Microscopic Image IOD Description

The VL Slide-Coordinates Microscopic Image IOD specifies the Attributes of VL Single-frame Slide-Coordinates Microscopic Images.

A.32.3.2 VL Slide-Coordinates Microscopic Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 of this Part depicts those components of the DICOM Information Model that directly reference the VL Slide-Coordinates Microscopic Image IOD, with exception of the Curve, VOI LUT, Frame of Reference and Modality LUT entities, which are not used. Additionally, Image in figure A.1.2 of PS3.3 represents a Single Frame image. A frame denotes a two-dimensional organization of pixels recorded as a single exposure. Table A.32.1-3 specifies the Modules of the VL Slide-Coordinates Microscopic Image IOD.

Notes: 1. A microscopic imaging procedure might include multiple series of single frame Microscopic Images as well as one or more additional series of related diagnostic images and might involve multiple Performed Procedure Steps, multiple Microscopes, and multiple anatomic regions. The procedure might be supervised, performed, and/or interpreted by one or more individuals.

2. Several distinct diagnostic or therapeutic processes might occur during a single procedure. For example: Histologic staining of the same section with multiple special stains.

Table A.32.1-3 VL SLIDE-COORDINATES MICROSCOPIC IMAGE IOD MODULES

A.32.3.3 VL Slide-Coordinates Microscopic Image IOD Content Constraints

A.32.3.3.1 Modality

The value of Modality (0008,0060) shall be SM.

PS 3.3 - 2003 Page 130

A.32.4 VL Photographic Image Information Object Definition

A.32.4.1 VL Photographic Image IOD Description

The VL Photographic Image IOD specifies the attributes of VL Single-frame photographic Images.

A.32.4.2 VL Photographic Image IOD Entity-Relationship Model

The E-R Model in Section A.1.2 of this Part depicts those components of the DICOM Information Model that directly reference the VL Photographic Image IOD, with exception of the Curve, VOI LUT, Frame of Reference and Modality LUT entities, which are not used. Additionally, Image in figure A.1.2 of PS3.3 represents a Single Frame image. A frame denotes a two-dimensional organization of pixels recorded as a single exposure. Table A.32.4-1 specifies the Modules of the VL Photographic Image IOD.

Notes: 1. A VL photographic imaging procedure might include multiple series of single frame VL Photographic images as well as one or more additional series of related diagnostic images. The procedure might involve multiple Performed Procedure Steps, multiple cameras, and multiple anatomic regions and might be supervised, performed, and/or interpreted by one or more individuals.

2. Several distinct diagnostic or therapeutic processes might occur during a single procedure.

Table A.32.4-1 VL PHOTOGRAPHIC IMAGE IOD MODULES

A.32.4.3 VL Photographic Image IOD Content Constraints

A.32.4.3.1 Modality

The value of Modality (0008,0060) shall be XC.

PS 3.3 - 2003 Page 131

A.33 GRAYSCALE SOFTCOPY PRESENTATION STATE INFORMATION OBJECT DEFINITION

A.33.1 Grayscale Softcopy Presentation State IOD Description

The Grayscale Softcopy Presentation State Information Object Definition (IOD) specifies information that may be used to present (display) images that are referenced from within the IOD.

It includes capabilities for specifying:

A.33.2 Grayscale Softcopy Presentation State IOD Module Table

Table A.33-1 Grayscale Softcopy Presentation State IOD MODULES

In the Grayscale Softcopy Presentation State IOD, the Presentation Series Module specializes some Attributes of the General Series Module, and the Presentation State Module specializes some Attributes of the Mask and Display Shutter Modules.

Notes: 1. Subtraction between different images is not supported.

  1. The Mask Module condition implies that it need not be supported by an SCP that supports presentation states only for single frame image storage SOP Classes, or instances of multi-frame image Storage SOP Classes that contain only one frame.
  2. The Display Shutter may be used to darken image areas that surround important information and exclude extraneous bright areas that increase glare and ambient lighting impairing image interpretation. For example, unexposed areas in a CR image might be obscured using the Display Shutter, rather than permanently replacing image pixels in those areas.
  3. This IOD does not support the storage of a multi-frame overlay in the IOD itself, but does support selective activation of multi-frame overlays within the referenced images via the Overlay/Curve Activation Module.

PS 3.3 - 2003 Page 134

A.34 WAVEFORM INFORMATION OBJECT DEFINITIONS

A.34.1 Waveform IOD Entity-Relationship Model

The Waveform E-R Model is shown in Figure A.34-1. This model applies to a variety of Waveform IODs.

Figure A.34-1 DICOM Waveform IOD Information Model

A.34.2 Basic Voice Audio Information Object Definition

A.34.2.1 Basic Voice Audio IOD Description

The Basic Voice Audio IOD is the specification of a digitized sound that has been acquired or created by an audio modality or by an audio acquisition function within an imaging modality. A typical use is report dictation.

A.34.2.2 Basic Voice Audio IOD Entity-Relationship Model

The E-R Model in Section A.34.1 of this Part applies to the Basic Voice Audio IOD.

A.34.2.3 Basic Voice Audio IOD Module Table

Table A.34.2-1 Basic Voice Audio IOD Modules

A.34.2.4 Basic Voice Audio IOD Content Constraints

A.34.2.4.1 Modality

The value of Modality (0008,0060) shall be AU.

A.34.2.4.2 Waveform Sequence

The number of Waveform Sequence (5400,0100) Items shall be one.

A.34.2.4.3 Number of Waveform Channels

The value of the Number of Waveform Channels (003A,0005) in the Waveform Sequence Item shall be 1 or 2.

A.34.2.4.4 Sampling Frequency

The value of the Sampling Frequency (003A,001A) in the Waveform Sequence Item shall be 8000.

A.34.2.4.5 Waveform Sample Interpretation

The value of the Waveform Sample Interpretation (5400,1006) in the Waveform Sequence Item shall be UB, MB, or AB.

A.34.3 12-Lead Electrocardiogram Information Object Definition

A.34.3.1 12-Lead ECG IOD Description

The 12-Lead Electrocardiogram (12-Lead ECG) IOD is the specification of digitized electrical signals from the patient cardiac conduction system collected on the body surface, which has been acquired by an ECG modality or by an ECG acquisition function within an imaging modality.

A.34.3.2 12-Lead ECG IOD Entity-Relationship Model

The E-R Model in Section A.34.1 of this Part applies to the 12-Lead ECG IOD.

A.34.3.3 12-Lead ECG IOD Module Table

Table A.34.3-1 12-Lead ECG IOD Modules

A.34.3.4 12-Lead ECG IOD Content Constraints

A.34.3.4.1 Modality

The value of Modality (0008,0060) shall be ECG.

A.34.3.4.2 Acquisition Context Module

For SOP Instances of ECG acquired in the cardiac catheterization lab, the Defined Template for Acquisition Context Sequence (0040,0555) is TID 3403. For routine resting or stress ECG, the Defined Template for Acquisition Context Sequence (0040,0555) is TID 3401.

A.34.3.4.3 Waveform Sequence

The number of Waveform Sequence (5400,0100) Items shall be between 1 and 5, inclusive.

A.34.3.4.4 Number of Waveform Channels

The value of the Number of Waveform Channels (003A,0005) in each Waveform Sequence Item shall be between 1 and 13, inclusive. The total number of channels encoded across all Items shall not exceed 13.

Note: This specialization provides for up to five Waveform Sequence Items (multiplex groups), with a total of 13 channels. This allows, for instance, encoding of four sets of three simultaneously recorded channels, the sets being acquired sequentially, plus one continuous channel for the duration of the other sets. This can be used to emulate the behavior of classical 12-lead ECG strip chart recorders with 4x3 presentation, plus a continuous lead II recording (see figure).

Multiplex Group 1 – leads I, II, III; time offset 0; duration 2.5 s Multiplex Group 2 – leads aVR, aVL, aVF; time offset 2.5 s; duration 2.5 s Multiplex Group 3 – leads V1, V2, V3; time offset 5.0 s; duration 2.5 s Multiplex Group 4 – leads V4, V5, V6; time offset 7.5 s; duration 2.5 s Multiplex Group 5 – lead II; time offset 0; duration 9.84 s

FIGURE A.34.3-1 12-Lead ECG Example (Informative)

A.34.3.4.5 Number of Waveform Samples

The value of the Number of Waveform Samples (003A,0010) in each Waveform Sequence Item shall be less than or equal to 16384.

Note: This allows over 16 seconds per channel at the maximum sampling frequency; if longer recordings are required, the General ECG IOD may be used.

A.34.3.4.6 Sampling Frequency

The value of the Sampling Frequency (003A,001A) in each Waveform Sequence Item shall be between 200 and 1000, inclusive.

A.34.3.4.7 Channel Source

The Baseline Context ID for the Channel Source Sequence (003A,0208) in each Channel Definition Sequence Item shall be CID 3001.

A.34.3.4.8 Waveform Sample Interpretation

The value of the Waveform Sample Interpretation (5400,1006) in each Waveform Sequence Item shall be SS.

A.34.3.4.9 Waveform Annotation Module

The Defined Context ID for the Concept Name Code Sequence (0040,A043) in the Waveform Annotation Sequence (0040,B020) shall be CID 3335. This Context Group supports the annotation of suppressed pacemaker spikes in the ECG waveform.

PS 3.3 - 2003 Page 138

A.34.4 General Electrocardiogram Information Object Definition

A.34.4.1 General ECG IOD Description

The General Electrocardiogram (ECG) IOD is the specification of digitized electrical signals from the patient cardiac conduction system collected on the body surface, which has been acquired by an ECG modality or by an ECG acquisition function within an imaging modality.

A.34.4.2 General ECG IOD Entity-Relationship Model

The E-R Model in Section A.34.1 of this Part applies to the General ECG IOD.

A.34.4.3 General ECG IOD Module Table

Table A.34.4-1 General ECG IOD Modules

A.34.4.4 General ECG IOD Content Constraints

A.34.4.4.1 Modality

The value of Modality (0008,0060) shall be ECG.

A.34.4.4.2 Waveform Sequence

The number of Waveform Sequence (5400,0100) Items shall be between 1 and 4, inclusive.

A.34.4.4.3 Number of Waveform Channels

The value of the Number of Waveform Channels (003A,0005) in each Waveform Sequence Item shall be between 1 and 24, inclusive.

A.34.4.4.4 Sampling Frequency

The value of the Sampling Frequency (003A,001A) in each Waveform Sequence Item shall be between 200 and 1000, inclusive.

PS 3.3 - 2003 Page 139

A.34.4.4.5 Channel Source

The Defined Context ID for the Channel Source Sequence (003A,0208) in each Channel Definition Sequence Item shall be CID 3001.