DICOM PS3.17 2024c - Explanatory Information
DICOM Standards Committee
Table of Contents
-
Notice and Disclaimer
-
Foreword
-
1. Scope and Field of Application
-
2. Normative References
-
-
Bibliography
-
3. Definitions
-
-
Glossary
-
4. Symbols and Abbreviations
-
5. Conventions
-
A. Explanation of Patient Orientation (Normative)
-
B. Integration of Modality Worklist and Modality Performed Procedure Step in The Original DICOM Standard (Informative)
-
C. Waveforms (Informative)
-
-
C.1. Domain of Application
-
C.2. Use Cases
-
C.3. Time Synchronization Frame of Reference
-
C.4. Waveform Acquisition Model
-
C.5. Waveform Information Model
-
C.6. Harmonization With HL7
-
-
C.6.1. HL7 Waveform Observation
-
C.6.2. Channel Definition
-
C.6.3. Timing
-
C.6.4. Waveform Data
-
C.6.5. Annotation
-
C.7. Harmonization With SCP-ECG
-
D. SR Encoding Example (Informative)
-
E. Mammography CAD (Informative)
-
-
E.1. Mammography CAD SR Content Tree Structure
-
E.2. Mammography CAD SR Observation Context Encoding
-
E.3. Mammography CAD SR Examples
-
-
E.3.1. Example 1: Calcification and Mass Detection With No Findings
-
E.3.2. Example 2: Calcification and Mass Detection With Findings
-
E.3.3. Example 3: Calcification and Mass Detection, Temporal Differencing With Findings
-
E.4. CAD Operating Point
-
E.5. Mammography CAD SR and For Processing / For Presentation Images
-
F. Chest CAD (Informative)
-
-
F.1. Chest CAD SR Content Tree Structure
-
F.2. Chest CAD SR Observation Context Encoding
-
F.3. Chest CAD SR Examples
-
-
F.3.1. Example 1: Lung Nodule Detection With No Findings
-
F.3.2. Example 2: Lung Nodule Detection With Findings and Anatomy/pathology Interpretation
-
F.3.3. Example 3: Lung Nodule Detection, Temporal Differencing With Findings
-
F.3.4. Example 4: Lung Nodule Detection in Chest Radiograph, Spatially Correlated With CT
-
G. Explanation of Grouping Criteria For Multi-frame Functional Group IODs (Informative)
-
H. Clinical Trial Identification Workflow Examples (Informative)
-
-
H.1. Example Use-case
-
I. Ultrasound Templates (Informative)
-
-
I.1. SR Content Tree Structure
-
I.2. Procedure Summary
-
I.3. Multiple Fetuses
-
I.4. Explicitly Specifying Calculation Dependencies
-
I.5. Linking Measurements to Images, Coordinates
-
I.6. Ob Patterns
-
I.7. Selected Value
-
I.8. OB-GYN Examples
-
-
I.8.1. Example 1: OB-GYN Root with Observation Context
-
I.8.2. Example 2: OB-GYN Patient Characteristics and Procedure Summary
-
I.8.3. Example 3: OB-GYN Multiple Fetus
-
I.8.4. Example 4: Biophysical Profile
-
I.8.5. Example 5: Biometry Ratios
-
I.8.6. Example 6: Biometry
-
I.8.7. Example 7: Amniotic Sac
-
I.8.8. Example 8: OB-GYN Ovaries
-
I.8.9. Example 9: OB-GYN Follicles
-
I.8.10. Example 10: Pelvis and Uterus
-
J. Handling of Identifying Parameters (Informative)
-
-
J.1. Purpose of This Annex
-
J.2. Integrated Environment
-
-
J.2.1. Modality Conforms to Modality Worklist and MPPS SOP Classes
-
J.2.2. Modality Conforms Only to The Modality Worklist SOP Class
-
J.2.3. Modality Conforms Only to The MPPS SOP Class
-
J.3. Non-integrated Environment
-
J.4. One MPPS Is Created in Response to Two Or More Requested Procedures
-
-
J.4.1. Choose Or Create A Value For Study Instance UID and Accession Number
-
J.4.2. Replicate The Image IOD
-
J.5. MPPS SOP Instance Created by Another System (not the Modality)
-
J.6. Mapping of Study Instance UIDs to the Study SOP Instance UID
-
K. Ultrasound Staged Protocol Data Management (Informative)
-
-
K.1. Purpose of this Annex
-
K.2. Prerequisites For Support
-
K.3. Definition of a Staged Protocol Exam
-
K.4. Attributes Used in Staged Protocol Exams
-
K.5. Guidelines
-
-
K.5.1. Staged Protocol Exam Identification
-
K.5.2. Stage and View Identification
-
K.5.3. Extra-protocol Image Identification
-
K.5.4. Multiple Images of A Stage-view
-
K.5.5. Workflow Management of Staged Protocol Images
-
-
K.5.5.1. Uninterrupted Exams - Single MPPS
-
K.5.5.2. Interrupted Exams - Multiple MPPS
-
-
K.5.5.2.2. Scheduled Follow-up Stages
-
L. Hemodynamics Report Structure (Informative)
-
M. Vascular Ultrasound Reports (Informative)
-
-
M.1. Vascular Report Structure
-
M.2. Vascular Examples
-
-
M.2.1. Example 1: Renal Vessels
-
M.2.2. Example 2: Carotids Extracranial
-
N. Echocardiography Procedure Reports (Informative)
-
-
N.1. Echo Patterns
-
N.2. Measurement Terminology Composition
-
N.3. Illustrative Mapping to ASE Concepts
-
-
N.3.1. Aorta
-
N.3.2. Aortic Valve
-
N.3.3. Left Ventricle - Linear
-
N.3.4. Left Ventricle Volumes and Ejection Fraction
-
N.3.5. Left Ventricle Output
-
N.3.6. Left Ventricular Outflow Tract
-
N.3.7. Left Ventricle Mass
-
N.3.8. Left Ventricle Miscellaneous
-
N.3.9. Mitral Valve
-
N.3.10. Pulmonary Vein
-
N.3.11. Left Atrium / Appendage
-
N.3.12. Right Ventricle
-
N.3.13. Pulmonic Valve / Pulmonic Artery
-
N.3.14. Tricuspid Valve
-
N.3.15. Right Atrium / Inferior Vena Cava
-
N.3.16. Congenital/Pediatric
-
N.4. Encoding Examples
-
-
N.4.1. Example 1: Patient Characteristics
-
N.4.2. Example 2: LV Dimensions and Fractional Shortening
-
N.4.3. Example 3: Left Atrium / Aortic Root Ratio
-
N.4.4. Example 4: Pressures
-
N.4.5. Example 5: Cardiac Output
-
N.4.6. Example 6: Wall Scoring
-
N.5. IVUS Report
-
O. Registration (Informative)
-
-
O.1. Spatial Registration and Spatial Fiducials SOP Classes
-
O.2. Functional Use Cases
-
O.3. System Interaction
-
O.4. Overview of Encoding
-
O.5. Matrix Registration
-
O.6. Spatial Fiducials
-
P. Transforms and Mappings (Informative)
-
Q. Breast Imaging Report (Informative)
-
-
Q.1. Breast Imaging Report Content Tree Structure
-
Q.2. Breast Imaging Report Examples
-
-
Q.2.1. Example 1: Screening Mammogram With Negative Findings
-
Q.2.2. Example 2: Screening Mammogram With Negative Findings
-
Q.2.3. Example 3: Diagnostic Mammogram - Unilateral
-
Q.2.4. Example 4: Diagnostic Mammogram and Ultrasound - Unilateral
-
R. Configuration Use Cases (Informative)
-
-
R.1. Install A New Machine
-
-
R.1.1. Configure DHCP
-
R.1.2. Configure LDAP
-
-
R.1.2.1. Pre-configure
-
R.1.2.2. Updating Configuration During Installation
-
R.1.2.3. Configure Client Then Update Server
-
R.1.3. Distributed Update Propagation
-
R.2. Legacy Compatibility
-
R.3. Obtain Configuration of Other Devices
-
-
R.3.1. Find AE When Given Device Type
-
R.4. Device Start up
-
R.5. Shutdown
-
-
R.5.1. Shutdown
-
R.5.2. Online/offline
-
R.6. Time Synchronization
-
-
R.6.1. High Accuracy Time Synchronization
-
R.6.2. Ordinary Time Synchronization
-
R.6.3. Background
-
-
R.6.3.1. Unsynchronized Time
-
R.6.3.2. Network Synchronized Time
-
R.6.3.3. External Clocks
-
R.6.4. SNTP Restrictions
-
R.6.5. Implementation Considerations
-
S. Legacy Transition For Configuration Management (Informative)
-
-
S.1. Legacy Association Requester, Configuration Managed Association Acceptor
-
-
S.1.1. DHCP Server
-
S.1.2. DNS Server
-
S.1.3. LDAP Server
-
S.2. Managed Association Requester, Legacy Association Acceptor
-
-
S.2.1. DHCP Server
-
S.2.2. DNS Server
-
S.2.3. LDAP Server
-
S.3. No DDNS Support
-
S.4. Partially Managed Devices
-
S.5. Adding The First Managed Device to A Legacy Network
-
-
S.5.1. New Servers Required
-
S.5.2. NTP
-
S.5.3. Documenting Managed and Unmanaged Nodes (DHCP, DNS, and LDAP)
-
-
S.5.3.1. DHCP Documentation
-
S.5.3.2. DNS Documentation
-
S.5.3.3. LDAP Documentation
-
S.5.3.4. Descriptions of Other Devices
-
S.5.4. Description of This Device
-
S.6. Switching A Node From Unmanaged to Managed in A Mixed Network
-
-
S.6.1. DHCP and DNS
-
S.6.2. NTP
-
S.6.3. Association Acceptors On This Node
-
S.6.4. Association Requesters On Legacy Nodes
-
S.6.5. Association Requesters On Managed Nodes
-
T. Quantitative Analysis References (Informative)
-
-
T.1. Definition of Left and Right in the Case of Quantitative Arterial Analysis
-
T.2. Definition of Diameter Symmetry with Arterial Plaques
-
T.3. Wall Motion Regions
-
-
T.3.1. Landmark Based Wall Motion Regions
-
T.3.2. Centerline Wall Motion Region
-
T.3.4. Radial Based Wall Motion Region
-
T.4. Quantitative Arterial Analysis Reference Method
-
-
T.4.1. Computer Calculated Reference
-
T.4.2. Interpolated Reference
-
T.4.3. Mean Local Reference
-
T.5. Positions in Diameter Graphic
-
U. Ophthalmology Use Cases (Informative)
-
-
U.1. Ophthalmic Photography Use Cases
-
-
U.1.1. Routine N-spot Exam
-
U.1.2. Routine N-spot Exam With Exceptions
-
U.1.3. Routine Flourescein Exam
-
U.1.4. External Examination
-
U.1.5. External Examination With Intention
-
U.1.6. External Examination With Drug Application
-
U.1.7. Routine Stereo Camera Examination
-
U.1.8. Relative Image Position Definitions
-
U.2. Typical Sequence of Events
-
U.3. Ophthalmic Tomography Use Cases (Informative)
-
-
U.3.1. Anterior Chamber Tomography
-
-
U.3.1.1. Anterior Chamber Exam For Phakic Intraocular Lens Surgery Planning
-
U.3.1.2. Anterior Chamber Angle Exam
-
U.3.1.4. Corneal Exam
-
U.3.2. Posterior Segment Tomography
-
-
U.3.2.1. Retinal Nerve Fiber Layer Exam
-
U.3.2.2. Macular Exam
-
U.3.2.3. Angiographic Exams
-
U.3.2.4. 3D Reconstruction Exam
-
U.3.2.5. Transverse Imaging
-
V. Hanging Protocols (Informative)
-
-
V.1. Example Scenario
-
V.2. Hanging Protocol Internal Process Model
-
V.3. Chest X-Ray Hanging Protocol Example
-
-
V.3.1. Hanging Protocol Definition Module
-
V.3.2. Hanging Protocol Environment Module
-
V.3.3. Hanging Protocol Display Module
-
V.4. Neurosurgery Planning Hanging Protocol Example
-
-
V.4.1. Hanging Protocol Definition Module
-
V.4.2. Hanging Protocol Environment Module
-
V.4.3. Hanging Protocol Display Module
-
V.5. Hanging Protocol Query Example
-
V.6. Display Set Patient Orientation Example
-
W. Digital Signatures in Structured Reports Use Cases (Informative)
-
X. Dictation-based Reporting With Image References (Informative)
-
-
X.1. Basic Data Flows
-
-
X.1.1. Dictation/transcription Reporting
-
X.1.2. Reporting With Image References
-
X.1.3. Reporting With Annotated Images
-
X.2. Transcribed Diagnostic Imaging SR Instance Content
-
-
X.2.1. SR Header Content
-
X.2.2. Transcribed Text Data Format
-
X.2.3. Image Reference Format
-
X.3. Transcribed Diagnostic Imaging CDA Instance Content
-
-
X.3.1. CDA Header Content
-
X.3.2. Transcribed Text Content
-
X.3.3. Image References
-
X.3.4. Icons
-
X.3.5. Structured Entries
-
X.4.3. Using The WADO Reference For DICOM Network Protocol Retrievals
-
X.4. Simultaneous SR and CDA Instance Creation
-
-
X.4.1. Equivalence
-
X.4.2. Document Cross-reference
-
Y. VOI LUT Functions (Informative)
-
Z. X-Ray Isocenter Reference Transformations (Informative)
-
-
Z.1. Introduction
-
Z.2. Positioner Coordinate System Transformations
-
Z.3. Table Coordinate System Transformations
-
AA. Radiation Dose Reporting Use Cases (Informative)
-
-
AA.1. Purpose of This Annex
-
AA.2. Definitions
-
AA.3. Use Cases
-
-
AA.3.1. Basic Dose Reporting
-
AA.3.2. Dose Reporting For Manual Data Entry
-
AA.3.3. Dose Reporting Processing
-
AA.3.4. Dose Reporting Workflow Management (Retired)
-
BB. Printing (Informative)
-
-
BB.1. Example of Print Management SCU Session (Informative)
-
-
BB.1.1. Simple Example
-
BB.1.2. Advanced Example (Retired)
-
CC. Storage Commitment (Informative)
-
-
CC.1. Storage Commitment Examples (Informative)
-
-
CC.1.1. Push Model Example
-
CC.1.2. Pull Model Example (Retired)
-
CC.1.3. Remote Storage of Data by The SCP
-
CC.1.4. Storage Commitment in Conjunction With Use of Storage Media
-
DD. Worklists (Informative)
-
-
DD.1. Examples For The Usage of The Modality Worklist (Informative)
-
DD.2. General Purpose Worklist Example (Informative) (Retired)
-
EE. Relevant Patient Information Query (Informative)
-
-
EE.1. Relevant Patient Information Query Example (Informative)
-
FF. CT/MR Cardiovascular Analysis Report Templates (Informative)
-
-
FF.2. Template Structure
-
FF.3. Report Example
-
GG. JPIP Referenced Pixel Data Transfer Syntax Negotiation (Informative)
-
HH. Segmentation Encoding Example (Informative)
-
II. Use of Product Characteristics Attributes in Composite SOP Instances (Informative)
-
-
II.1. Contrast/bolus Module
-
II.2. Enhanced Contrast/bolus Module
-
II.3. Device Module
-
II.4. Intervention Module
-
JJ. Surface Mesh Representation (Informative)
-
-
JJ.1. Multi-Dimensional Vectors
-
JJ.2. Encoding Examples
-
KK. Use Cases For The Composite Instance Root Retrieval Classes (Informative)
-
-
KK.1. Clinical Review
-
-
KK.1.1. Retrieval Based On Report References
-
KK.1.2. Selective Retrieval Without References to Specific Slices
-
KK.2. Local Use - "Relevant Priors"
-
-
KK.2.1. Anatomic Sub-region
-
KK.2.2. Worklists
-
KK.3. Attribute Based Retrieval
-
KK.4. CAD & Data Mining Applications
-
KK.5. Independent WADO Server
-
LL. Example SCU Use of The Composite Instance Root Retrieval Classes (Informative)
-
-
LL.1. Retrieval of Entire Composite Instances
-
LL.2. Retrieval of Selected Frame Composite Instances From Multi-frame Objects
-
LL.3. Retrieval of Selected Frame Composite Instances From MPEG-2, MPEG-4 AVC/H.264 or HEVC/H.265 Video
-
MM. Considerations For Applications Creating New Images From Multi-frame Images
-
-
MM.1. Scope
-
MM.2. Frame Extraction Issues
-
-
MM.2.1. Number of Frames
-
MM.2.2. Start and End Times
-
MM.2.3. Time Interval versus Frame Increment Vector
-
MM.2.4. MPEG-2, MPEG-4 AVC/H.264 or HEVC/H.265
-
MM.2.5. JPEG 2000 Part 2 Multi-Component Transform
-
MM.2.6. Functional Groups For Enhanced CT, MR, etc.
-
MM.2.7. Nuclear Medicine Images
-
MM.2.8. A "Single Frame" Multi-frame Image
-
MM.3. Frame Numbers
-
MM.4. Consistency
-
MM.5. Time Synchronization
-
MM.6. Audio
-
MM.7. Private Attributes
-
NN. Specimen Identification and Management
-
-
NN.1. Pathology Workflow
-
NN.2. Basic Concepts and Definitions
-
-
NN.2.1. Specimen
-
NN.2.2. Containers
-
NN.3. Specimen Module
-
-
NN.3.1. Scope
-
NN.3.2. Relationship With The Laboratory Information System
-
NN.3.3. Case Level Information and The Accession Number
-
NN.3.4. Laboratory Workflows and Specimen Types
-
NN.3.5. Relationship Between Specimens and Containers
-
NN.3.6. Relationship Between Specimens and Images
-
NN.4. Specimen Identification Examples
-
-
NN.4.1. One Specimen Per Container
-
NN.4.2. Multiple Items From Same Block
-
NN.4.3. Items From Different Parts in The Same Block
-
NN.4.4. Items From Different Parts On The Same Slide
-
NN.4.5. Tissue Micro Array
-
NN.5. Structure of The Specimen Module
-
NN.6. Examples of Specimen Module Use
-
-
NN.6.1. Gross Specimen
-
NN.6.2. Slide
-
NN.7. Specimen Data in Pathology Imaging Workflow Management
-
-
NN.7.1. Modality Worklist
-
-
NN.7.1.1. MWL for Whole Slide Imaging
-
NN.7.2. Modality Performed Procedure Step
-
OO. Structured Display (Informative)
-
-
OO.1. Structured Display Use Cases
-
-
OO.1.1. Dentistry
-
OO.1.2. Ophthalmology
-
OO.1.3. Cardiology
-
OO.1.4. Radiology
-
PP. 3D Ultrasound Volumes (Informative)
-
-
PP.1. Purpose of This Annex
-
PP.2. 3D Ultrasound Clinical Use Cases
-
-
PP.2.1. Use Cases
-
PP.2.2. Hierarchy of Use Cases
-
PP.3. 3D Ultrasound Solutions in DICOM
-
-
PP.3.1. 3D Volume Data sets
-
PP.3.2. 2D Derived Images
-
PP.3.3. Physiological Waveforms Associated With 3D Volume Data sets
-
PP.3.4. Workflow Considerations
-
QQ. Enhanced US Data Type Blending Examples (Informative)
-
-
QQ.1. Enhanced US Volume Use of the Blending and Display Pipeline
-
-
QQ.1.1. Example 1 - Grayscale P-Values Output
-
QQ.1.2. Example 2 - Grayscale-only Color Output
-
QQ.1.3. Example 3 - Color Tissue (Pseudo-color) Mapping
-
QQ.1.4. Example 4 - Fixed Proportion Additive Grayscale Tissue and Color Flow
-
QQ.1.5. Example 5 - Threshold Based On Flow_velocity
-
QQ.1.6. Example 6 - Threshold Based On Flow_velocity and Flow_variance W/2d Color Mapping
-
QQ.1.7. Example 7 - Color Tissue / Velocity / Variance Mapping - Blending Considers Both Data Paths
-
RR. Ophthalmic Refractive Reports Use Cases (Informative)
-
-
RR.1. Introduction
-
RR.2. Reference Tables For Equivalent Visual Acuity Notations
-
-
RR.2.1. Background
-
RR.2.2. Notations
-
RR.2.3. Use of The Lookup Table
-
RR.2.4. Traditional Charts
-
RR.2.5. ETDRS Charts
-
SS. Colon CAD (Informative)
-
-
SS.1. Colon CAD SR Content Tree Structure
-
SS.2. Colon CAD SR Observation Context Encoding
-
SS.3. Colon CAD SR Examples
-
-
SS.3.1. Example 1: Colon Polyp Detection With No Findings
-
SS.3.2. Example 2: Colon Polyp Detection With Findings
-
SS.3.3. Example 3: Colon Polyp Detection, Temporal Differencing With Findings
-
TT. Stress Testing Report Template (Informative)
-
UU. Macular Grid Thickness and Volume Report Use Cases (Informative)
-
-
UU.1. Introduction
-
UU.2. Use of B-scan Images
-
UU.3. Use of Tissue Measurements
-
UU.4. Axial Measurements
-
UU.5. En Face Measurements
-
UU.6. Interpretation of OPT
-
VV. Pediatric, Fetal and Congenital Cardiac Ultrasound Reports (Informative)
-
-
VV.1. Content Structure
-
VV.2. Pediatric, Fetal and Congenital Cardiac Ultrasound Patterns
-
VV.3. Measurement Terminology Composition
-
WW. Audit Messages (Informative)
-
-
WW.1. Message Example
-
WW.2. Workflow Example
-
XX. Use Cases for Application Hosting
-
-
XX.1. Agent-Specific Post Processing
-
XX.2. Support For Multi-site Collaborative Research
-
XX.3. Screening Applications
-
XX.4. Modality-Specific Post Processing
-
XX.5. Measurement/Evidence Document Creation
-
XX.6. CAD Rendering
-
YY. Compound and Combined Graphic Objects in Presentation States (Informative)
-
-
YY.1. An Example of The Compound Graphic 'axis'
-
YY.2. An Example of Distance Line Defined As A Combined Graphic Object
-
ZZ. Implant Template Description
-
-
ZZ.1. Implant Mating
-
-
ZZ.1.1. Mating Features
-
ZZ.1.2. Mating Feature ID
-
ZZ.1.3. Mating Feature Sets
-
ZZ.1.4. Degrees of Freedom
-
ZZ.1.5. Implant Assembly Templates
-
ZZ.2. Planning Landmarks
-
ZZ.3. Implant Registration and Mating Example
-
-
ZZ.3.1. Degrees of Freedom
-
ZZ.4. Encoding Example
-
ZZ.5. Implant Template Versions and Derivation
-
AAA. Implantation Plan SR Document (Informative)
-
-
AAA.1. Implantation Plan SR Document Content Tree Structure
-
AAA.2. Relationship Between Implant Template and Implantation Plan
-
AAA.3. Implantation Plan SR Document Total Hip Replacement Example
-
AAA.4. Implantation Plan SR Document Dental Drilling Template Example
-
BBB. Unified Procedure Step in Radiotherapy (Informative)
-
-
BBB.1. Purpose of this Annex
-
BBB.2. Use Case Actors
-
BBB.3. Use Cases
-
-
BBB.3.1. Treatment Delivery Normal Flow - Internal Verification
-
-
BBB.3.1.1. Message Sequencing
-
BBB.3.1.2. Transactions and Message Flow
-
BBB.3.2. Treatment Delivery Normal Flow - External Verification
-
-
BBB.3.2.1. Message Sequencing
-
BBB.3.2.2. Transactions and Message Flow
-
BBB.3.3. Treatment-delivery With External Verification - Override Or Additional Info Required
-
-
BBB.3.3.1. Message Sequencing
-
BBB.3.3.2. Transactions and Message Flow
-
BBB.3.4. Treatment-delivery With External Verification - Machine Adjustment Required
-
-
BBB.3.4.1. Message Sequencing
-
BBB.3.4.2. Transactions and Message Flow
-
CCC. Ophthalmic Axial Measurements and Intraocular Lens Calculations Use Cases (Informative)
-
-
CCC.1. Axial Measurements
-
CCC.2. Intraocular Lens Calculations Introduction
-
CCC.3. Output of An Ultrasound A-scan Device
-
CCC.4. Output of An Optical A-scan Device
-
CCC.5. IOL Calculation Results Example
-
DDD. Visual Field Static Perimetry Use Cases (Informative)
-
-
DDD.1. Introduction
-
DDD.2. Use Cases
-
-
DDD.2.1. Evaluation For Glaucoma
-
DDD.2.2. Neurological Disease
-
DDD.2.3. Diffuse and Local Defect
-
-
DDD.2.3.1. Diffuse Defect
-
DDD.2.4.2. Local Defect
-
EEE. Intravascular OCT Image (Informative)
-
-
EEE.1. Purpose of This Annex
-
EEE.2. IVOCT For Processing Parameters
-
-
EEE.2.1. Z Offset Correction
-
EEE.2.2. Refractive Index Correction
-
EEE.2.3. Polar-Cartesian Conversion
-
EEE.3. Intravascular Longitudinal Image
-
FFF. Enhanced XA/XRF Encoding Examples (Informative)
-
-
FFF.1. General Concepts of X-Ray Angiography
-
-
FFF.1.1. Time Relationships
-
-
FFF.1.1.1. Time Relationships of A Multi-frame Image
-
FFF.1.1.2. Time Relationships of One Frame
-
FFF.1.2. Acquisition Geometry
-
-
FFF.1.2.1. Patient Description
-
FFF.1.2.2. Patient Position
-
-
FFF.1.2.2.1. Table Description
-
FFF.1.2.2.2. Options For Patient Position On The X-Ray Table
-
FFF.1.2.3. Table Movement
-
-
FFF.1.2.3.1. Isocenter Coordinate System
-
FFF.1.2.3.2. Table Movement in The Isocenter Coordinate System
-
FFF.1.2.4. Positioner Movement
-
-
FFF.1.2.4.1. Positioner Movement in The Isocenter Coordinate System
-
FFF.1.2.4.2. X-Ray Incidence and Image Coordinate System
-
FFF.1.2.5. Field of View Transformations
-
-
FFF.1.2.5.1. Detector
-
FFF.1.2.5.2. Field of View
-
FFF.1.2.5.3. Field of View Rotation and Flip
-
FFF.1.3. Calibration
-
FFF.1.4. X-Ray Generation
-
FFF.1.5. Pixel Data Properties and Display Pipeline
-
FFF.2. Application Cases
-
-
FFF.2.1. Acquisition
-
-
FFF.2.1.1. ECG Recording at Acquisition Modality
-
-
FFF.2.1.1.1. User Scenario
-
FFF.2.1.1.2. Encoding Outline
-
FFF.2.1.1.3. Encoding Details
-
-
FFF.2.1.1.3.1. Enhanced XA Image
-
-
FFF.2.1.1.3.1.1. Synchronization Module Recommendations
-
FFF.2.1.1.3.1.2. General Equipment Module Recommendations
-
FFF.2.1.1.3.1.3. Cardiac Synchronization Module Recommendations
-
FFF.2.1.1.3.1.4. Enhanced XA/XRF Image Module Recommendations
-
FFF.2.1.1.3.1.5. Cardiac Synchronization Macro Recommendations
-
FFF.2.1.1.3.1.6. Frame Content Macro Recommendations
-
FFF.2.1.1.3.2. General ECG Object
-
-
FFF.2.1.1.3.2.1. General Series Module Recommendations
-
FFF.2.1.1.3.2.2. Synchronization Module Recommendations
-
FFF.2.1.1.3.2.3. General Equipment Module Recommendations
-
FFF.2.1.1.3.2.4. Waveform Identification Recommendations
-
FFF.2.1.1.3.2.5. Waveform Module Recommendations
-
FFF.2.1.1.4. Examples
-
-
FFF.2.1.1.4.1. Enhanced XA Image Without Cardiac Synchronization
-
FFF.2.1.1.4.2. Enhanced XA Image With Cardiac Synchronization
-
FFF.2.1.2. Multi-modality Waveform Synchronization
-
-
FFF.2.1.2.1. Both Modalities Synchronized Via NTP
-
-
FFF.2.1.2.1.1. User Scenario
-
FFF.2.1.2.1.2. Encoding Outline
-
FFF.2.1.2.1.3. Encoding Details
-
-
FFF.2.1.2.1.3.1. Enhanced XA Image
-
-
FFF.2.1.2.1.3.1.1. Synchronization Module Recommendations
-
FFF.2.1.2.1.3.1.2. Enhanced XA/XRF Image Module Recommendations
-
FFF.2.1.2.1.3.1.3. Frame Content Macro Recommendations
-
FFF.2.1.2.1.3.2. Waveform Object
-
FFF.2.1.2.1.4. Example
-
FFF.2.1.2.2. One Modality Sends Trigger to The Other Modality
-
-
FFF.2.1.2.2.1. User Scenario
-
FFF.2.1.2.2.2. Encoding Outline
-
FFF.2.1.2.2.3. Encoding Details
-
-
FFF.2.1.2.2.3.1. Enhanced XA Image
-
-
FFF.2.1.2.2.3.1.1. Synchronization Module Recommendations
-
FFF.2.1.2.2.3.1.2. Enhanced XA/XRF Image Module Recommendations
-
FFF.2.1.2.2.3.1.3. Frame Content Macro Recommendations
-
FFF.2.1.2.2.3.2. Waveform Object
-
-
FFF.2.1.2.2.3.2.2. Synchronization Module Recommendations
-
FFF.2.1.2.2.3.2.3. Waveform Identification Module Recommendations
-
FFF.2.1.2.2.3.2.4. Waveform Module Recommendations
-
FFF.2.1.2.2.4. Examples
-
-
FFF.2.1.2.2.4.1. Image modality sends trigger to the waveform modality
-
FFF.2.1.2.2.4.2. Waveform modality sends trigger to the image modality
-
FFF.2.1.3. Mechanical Movement
-
-
FFF.2.1.3.1. Rotational Acquisition
-
-
FFF.2.1.3.1.1. User Scenario
-
FFF.2.1.3.1.2. Encoding Outline
-
FFF.2.1.3.1.3. Encoding Details
-
-
FFF.2.1.3.1.3.1. XA/XRF Acquisition Module Recommendations
-
FFF.2.1.3.1.3.2. X-Ray Positioner Macro Recommendations
-
FFF.2.1.3.1.3.3. X-Ray Isocenter Reference System Macro Recommendations
-
FFF.2.1.3.1.4. Example
-
FFF.2.1.3.2. Peripheral/stepping Acquisition
-
-
FFF.2.1.3.2.1. User Scenario
-
FFF.2.1.3.2.2. Encoding Outline
-
FFF.2.1.3.2.3. Encoding Details
-
-
FFF.2.1.3.2.3.1. XA/XRF Acquisition Module Recommendations
-
FFF.2.1.3.2.3.2. X-Ray Table Position Macro Recommendations
-
FFF.2.1.3.2.3.3. X-Ray Isocenter Reference System Macro Recommendations
-
FFF.2.1.3.2.4. Example
-
FFF.2.1.4. Changes in X-Ray Controls
-
-
FFF.2.1.4.1. Exposure Regulation Control
-
-
FFF.2.1.4.1.1. User Scenario
-
FFF.2.1.4.1.2. Encoding Outline
-
FFF.2.1.4.1.3. Encoding Details
-
-
FFF.2.1.4.1.3.1. X-Ray Exposure Control Sensing Regions Macro Recommendations
-
FFF.2.1.4.1.4. Example
-
FFF.2.1.5. Image Detector and Field of View
-
-
FFF.2.1.5.1. User Scenario
-
FFF.2.1.5.2. Encoding Outline
-
FFF.2.1.5.3. Encoding Details
-
-
FFF.2.1.5.3.1. XA/XRF Acquisition Module Recommendations
-
FFF.2.1.5.3.2. X-Ray Image Intensifier Module Recommendations
-
FFF.2.1.5.3.3. X-Ray Detector Module Recommendations
-
FFF.2.1.5.3.4. X-Ray Field of View Macro Recommendations
-
FFF.2.1.5.3.5. XA/XRF Frame Pixel Data Properties Macro Recommendations
-
FFF.2.1.5.4. Examples
-
-
FFF.2.1.5.4.1. Field of View On Image Intensifier
-
FFF.2.1.5.4.2. Field of View On Digital Detector
-
FFF.2.1.6. Acquisitions With Contrast
-
-
FFF.2.1.6.1. User Scenario
-
FFF.2.1.6.2. Encoding Outline
-
FFF.2.1.6.3. Encoding Details
-
-
FFF.2.1.6.3.1. Enhanced Contrast/bolus Module Recommendations
-
FFF.2.1.6.3.2. Contrast/bolus Usage Macro Recommendations
-
FFF.2.1.6.4. Example
-
FFF.2.1.7. Acquisition Parameters For X-Ray Generation (kVp, mA, …)
-
-
FFF.2.1.7.1. User Scenario
-
FFF.2.1.7.2. Encoding Outline
-
FFF.2.1.7.3. Encoding Details
-
-
FFF.2.1.7.3.1. XA/XRF Acquisition Module Recommendations
-
FFF.2.1.7.3.2. Frame Content Macro Recommendations
-
FFF.2.1.7.3.3. X-Ray Frame Acquisition Macro Recommendations
-
FFF.2.1.7.4. Example
-
FFF.2.2. Review
-
-
FFF.2.2.1. Variable Frame-rate Acquisition With Skip Frames
-
-
FFF.2.2.1.1. User Scenario
-
FFF.2.2.1.2. Encoding Outline
-
FFF.2.2.1.3. Encoding Details
-
-
FFF.2.2.1.3.1. XA/XRF Multi-frame Presentation Module Recommendations
-
FFF.2.2.1.4. Example
-
FFF.2.3. Display
-
-
FFF.2.3.1. Standard Pipeline With Enhanced XA
-
-
FFF.2.3.1.1. User Scenario
-
FFF.2.3.1.2. Encoding Outline
-
FFF.2.3.1.3. Encoding Details
-
-
FFF.2.3.1.3.1. Enhanced XA/XRF Image Module Recommendations
-
FFF.2.3.1.3.2. XA/XRF Multi-frame Presentation Module Recommendations
-
FFF.2.3.1.3.3. Frame VOI LUT Macro Recommendations
-
FFF.2.3.1.3.4. Pixel Intensity Relationship LUT Macro Recommendations
-
FFF.2.3.1.3.5. XA/XRF Frame Pixel Data Properties Macro Recommendations
-
FFF.2.3.1.4. Example
-
FFF.2.3.2. Mask Subtraction
-
-
FFF.2.3.2.1. User Scenario
-
FFF.2.3.2.2. Encoding Outline
-
FFF.2.3.2.3. Encoding Details
-
-
FFF.2.3.2.3.1. Mask Module Recommendations
-
FFF.2.3.2.3.2. XA/XRF Multi-frame Presentation Module Recommendations
-
FFF.2.3.2.4. Examples
-
FFF.2.3.3. Pixel-shift
-
-
FFF.2.3.3.1. User Scenario
-
FFF.2.3.3.2. Encoding Outline
-
FFF.2.3.3.3. Encoding Details
-
-
FFF.2.3.3.3.1. Mask Module Recommendations
-
FFF.2.3.3.3.2. Frame Pixel Shift Macro Recommendations
-
FFF.2.3.3.4. Examples
-
-
FFF.2.3.3.4.1. Usage of Pixel Shift Macro in Shared Context
-
FFF.2.3.3.4.2. Usage of Pixel Shift Macro in "per Frame" Context
-
FFF.2.3.3.4.3. Usage of Pixel Shift Macro in "per Frame" Context For Multiple Shifts
-
FFF.2.4. Processing
-
-
FFF.2.4.1. Projection Pixel Calibration
-
-
FFF.2.4.1.1. User Scenario
-
FFF.2.4.1.2. Encoding Outline
-
FFF.2.4.1.3. Encoding Details
-
-
FFF.2.4.1.3.1. XA/XRF Acquisition Module Recommendations
-
FFF.2.4.1.3.2. XA/XRF Frame Pixel Data Properties Macro Recommendations
-
FFF.2.4.1.3.3. X-Ray Projection Pixel Calibration Macro Recommendations
-
FFF.2.4.1.3.4. X-Ray Geometry Macro Recommendations
-
FFF.2.4.1.4. Example
-
FFF.2.4.2. Image Derivation and Pixel Data Properties
-
-
FFF.2.4.2.1. User Scenario
-
FFF.2.4.2.2. Encoding Outline
-
FFF.2.4.2.3. Encoding Details
-
-
FFF.2.4.2.3.1. Enhanced XA/XRF Image Module Recommendations
-
FFF.2.4.2.3.2. Derivation Image Macro Recommendations
-
FFF.2.4.2.3.3. Pixel Intensity Relationship LUT Macro Recommendations
-
FFF.2.4.2.3.4. XA/XRF Frame Characteristics Macro Recommendations
-
FFF.2.4.2.3.5. XA/XRF Frame Pixel Data Properties Macro Recommendations
-
FFF.2.4.2.4. Examples
-
-
FFF.2.4.2.4.1. Various Successive Derivations
-
FFF.2.4.2.4.2. Derivation by Applying A Square Root Transformation
-
FFF.2.5. Registration
-
-
FFF.2.5.1. Tracking An Object of Interest On Multiple 2d Images
-
-
FFF.2.5.1.1. User Scenario
-
FFF.2.5.1.2. Encoding Outline
-
FFF.2.5.1.3. Encoding Details
-
-
FFF.2.5.1.3.1. Image Pixel Module Recommendations
-
FFF.2.5.1.3.2. XA/XRF Acquisition Module Recommendations
-
FFF.2.5.1.3.3. X-Ray Detector Module Recommendations
-
FFF.2.5.1.3.4. X-Ray Field of View Macro Recommendations
-
FFF.2.5.1.3.5. X-Ray Isocenter Reference System Macro Recommendations
-
FFF.2.5.1.3.6. X-Ray Geometry Macro Recommendations
-
FFF.2.5.1.3.7. XA/XRF Frame Pixel Data Properties Macro Recommendations
-
FFF.2.5.1.4. Example
-
GGG. Unified Worklist and Procedure Step - UPS (Informative)
-
-
GGG.1. Introduction
-
GGG.2. Implementation Examples
-
-
GGG.2.1. Typical SOP Class Implementations
-
GGG.2.2. Typical Pull Workflow
-
GGG.2.3. Reporting Workflow With "hand-off"
-
GGG.2.4. Third Party Cancel
-
GGG.2.5. Radiation Therapy Dose Calculation Push Workflow
-
GGG.2.6. X-Ray Clinic Push Workflow
-
GGG.2.7. Other Examples
-
GGG.3. Other Features
-
-
GGG.3.1. What Was Scheduled Vs. What Was Performed
-
GGG.3.2. Complex Procedure Steps
-
GGG.3.3. Gift Subscriptions
-
HHH. Transition from WADO to RESTful Services (Informative)
-
-
HHH.1. Request and Response Parameters
-
-
HHH.1.1. Request Parameters
-
HHH.1.2. Response Parameters
-
-
HHH.1.2.1. URI WADO-URI
-
HHH.1.2.2. Retired
-
HHH.1.2.3. WADO-RS
-
HHH.1.2.4. STOW-RS
-
HHH.2. Web Services Implementation
-
HHH.3. Uses for Web Services
-
-
HHH.3.1. General Requirements
-
HHH.3.2. Analysis of Use Cases
-
HHH.3.3. Description of The Use Cases
-
-
HHH.3.3.1. URI Based WADO Use Case
-
HHH.3.3.2. DICOM (Encoded Content) Requester
-
HHH.3.3.3. Rendered (JPEG/PDF) Requester
-
HHH.3.3.4. Metadata (XML Without Pixel Data, Waveform Data, etc.) Requester
-
HHH.3.3.5. DICOM Requester
-
HHH.3.3.6. Frame Pixel Data Requester
-
HHH.3.3.7. Bulk Data Requester
-
HHH.3.3.8. Metadata Requester
-
HHH.3.3.9. DICOM Creator
-
HHH.3.3.10. Metadata and Bulk Data Creator
-
HHH.4. Uses For QIDO Services
-
-
HHH.4.1. General Requirements
-
HHH.4.2. Analysis of Use Cases
-
-
HHH.4.2.1. Search From EMR
-
HHH.4.2.2. Populating FHIR Resources
-
HHH.4.2.3. Worklist in Viewer
-
HHH.4.2.4. Multiple Systems Query
-
HHH.4.2.5. Clinical Reconstruction
-
HHH.4.2.6. Mobile Device Access
-
HHH.4.3. Description of The Use Cases
-
-
HHH.4.3.1. XML Study Search Use Case
-
HHH.4.3.2. XML Study, Series and Instance Search Use Case
-
HHH.4.3.3. JSON Use Case
-
HHH.5. Retired
-
HHH.6. Retired
-
HHH.7. Uses for Server Options Services
-
-
HHH.7.1. WADL Example (XML)
-
III. Ophthalmic Thickness Map Use Cases (Informative)
-
-
III.1. Introduction
-
III.2. Macular Retinal Thickness Example
-
III.3. RNFL Example
-
III.4. Diabetic Macular Edema Example
-
III.5. Glaucoma Example
-
III.6. Retinal Thickness Definition
-
III.7. Thickness Calculations Between Various Devices
-
JJJ. Optical Surface Scan
-
-
JJJ.1. General Information
-
JJJ.2. One Single Shot Without Texture Acquisition As Point Cloud
-
JJJ.3. One Single Shot With Texture Acquisition As Mesh
-
JJJ.4. Storing Modified Point Cloud With Texture As Mesh
-
JJJ.5. Multishot Without Texture As Point Clouds and Merged Mesh
-
JJJ.6. Multishot With Two Texture Per Point Cloud
-
JJJ.7. Using Colored Vertices Instead of Texture
-
JJJ.8. 4D Surface Data Analysis
-
JJJ.9. Referencing A Texture From Another Series
-
KKK. Use-cases For Conversion of Classic Single Frame Images to Legacy Converted Enhanced Multi-frame Images (Informative)
-
-
KKK.1. Introduction
-
KKK.2. Enhanced Legacy Converted Image Storage IODs
-
KKK.3. Heterogeneous Environment
-
KKK.4. Compatibility With Modality Association Negotiation
-
KKK.5. Query and Retrieval
-
KKK.6. Referential Integrity
-
KKK.7. Persistence and Determinism
-
KKK.8. Source References
-
KKK.9. Uncertainty Principle
-
LLL. Conversion of Single Frame Images to Legacy Converted Enhanced Multi-frame Images (Informative)
-
-
LLL.1. Introduction
-
LLL.2. Simple CT Example
-
-
LLL.2.1. Images
-
-
LLL.2.1.1. First Slice As Classic Image
-
LLL.2.1.2. Second Slice As Classic Image
-
LLL.2.1.3. Legacy Converted Enhanced Image Containing Both Slices
-
LLL.2.2. Presentation States
-
-
LLL.2.2.1. Presentation State Referencing Classic Image That Contains The First Slice
-
LLL.2.2.2. Presentation State Referencing First Slice in Legacy Converted Enhanced Image
-
MMM. Query and Retrieval of Legacy Converted Enhanced Multi-frame Images (Informative)
-
-
MMM.1. Introduction
-
MMM.2. CT Example with Images and Presentation States
-
-
MMM.2.1. C-FIND and C-MOVE At Study Level With Classic View
-
MMM.2.2. C-FIND and C-MOVE at Study Level with Enhanced View
-
NNN. Corneal Topography and Tomography Maps (Informative)
-
-
NNN.1. Introduction
-
NNN.2. Corneal Topography Scales and Color Palettes
-
NNN.3. Corneal Topography Examples
-
NNN.4. Contact Lens Fitting Examples
-
NNN.5. Wavefront Map Example
-
OOO. Radiopharmaceutical Radiation Dose Structured Report (Informative)
-
-
OOO.1. Purpose of This Annex
-
OOO.2. Real-World Nuclear Medicine and PET Radiopharmaceutical Radiation Dose (RRD) SR Workflow
-
OOO.3. Real-World Radiopharmaceutical and Radiopharmaceutical Components Identification
-
PPP. Examples of Communication of Display Parameters (Informative)
-
-
PPP.1. The Relationship Between AE and Display System
-
PPP.2. Examples of Message Sequencing
-
-
PPP.2.1. Example of Retrieval of Status and Configuration From Display Systems
-
PPP.3. Examples of Display System SOP Class
-
-
PPP.3.1. An Example of A Typical Display System
-
PPP.3.2. An Example of A Tablet Display
-
QQQ. Parametric Maps (Informative)
-
-
QQQ.1.
-
-
QQQ.1.1.
-
RRR. Measurement Report SR Document for Planar and Volumetric ROI (Informative)
-
-
RRR.1. Measurement Report SR Document Volumetric ROI on CT Example
-
RRR.2. Measurement Report SR Document Volumetric ROI on CT Example
-
RRR.3. Measurement Report SR Document Planar ROI on DCE-MR Tracer Kinetic Model Example
-
RRR.4. Measurement Report SR Document Volumetric and SUV ROI on FDG PET Example
-
RRR.5. Measurement Report SR Document Volumetric ROI with RECIST Linear Distance Specified by Coordinates on CT Example
-
SSS. Use of Image Libraries in SR Documents (Informative)
-
-
SSS.1. Image Library for PET-CT Example
-
TTT. X-Ray 3D Angiographic Image Encoding Examples (Informative)
-
-
TTT.1. General Concepts of X-Ray 3D Angiography
-
-
TTT.1.1. Process of Creating An X-Ray 3D Angiography
-
-
TTT.1.1.1. Acquisition of 2D Projections
-
TTT.1.1.2. 3D Reconstruction
-
TTT.1.2. X-Ray 3D Angiographic Real World Entities Relationships
-
TTT.1.3. X-Ray 3D Angiographic Pixel Data Characterization
-
TTT.2. Application Cases
-
-
TTT.2.1. Case #1: One Rotation, One 2D Instance, One Reconstruction, One X-Ray 3D Instance
-
-
TTT.2.1.1. User Scenario
-
TTT.2.1.2. Encoding Outline
-
TTT.2.1.3. Encoding Details
-
-
TTT.2.1.3.1. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.1.3.1.1. General and Enhanced Series Modules Recommendations
-
TTT.2.1.3.1.2. Frame of Reference Module Recommendations
-
TTT.2.1.3.1.3. General and Enhanced General Equipment Modules Recommendations
-
TTT.2.1.3.1.4. Image Pixel Module Recommendations
-
TTT.2.1.3.1.5. Enhanced Contrast/Bolus Module Recommendations
-
-
TTT.2.1.3.1.5.1. Differences between XA and Enhanced XA
-
TTT.2.1.3.1.6. Multi-frame Dimensions Module Recommendations
-
TTT.2.1.3.1.7. Patient Orientation Module Recommendations
-
TTT.2.1.3.1.8. X-Ray 3D Image Module Recommendations
-
TTT.2.1.3.1.9. X-Ray 3D Angiographic Image Contributing Sources Module Recommendations
-
TTT.2.1.3.1.10. X-Ray 3D Angiographic Acquisition Module Recommendations
-
TTT.2.1.3.1.11. Pixel Measures Macro Recommendations
-
TTT.2.1.3.1.12. Frame Content Macro Recommendations
-
TTT.2.1.3.1.13. Derivation Image Macro Recommendations
-
TTT.2.1.3.1.14. Frame Anatomy Macro Recommendations
-
TTT.2.1.3.1.15. X-Ray 3D Frame Type Macro Recommendations
-
TTT.2.1.4. Example
-
-
TTT.2.1.4.1. Reconstruction Using All Frames of An Enhanced XA Image
-
TTT.2.2. Case #2: Reconstruction From A Sub-set of Projection Frames
-
-
TTT.2.2.1. User Scenario
-
TTT.2.2.2. Encoding Outline
-
TTT.2.2.3. Encoding Details
-
-
TTT.2.2.3.1. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.2.3.1.1. X-Ray 3D Angiographic Acquisition Module Recommendations
-
TTT.2.2.3.1.2. Frame Content Macro Recommendations
-
TTT.2.2.4. Example
-
TTT.2.3. Case #3: Reconstruction From A Sub-region of All Image Frames
-
-
TTT.2.3.1. User Scenario
-
TTT.2.3.2. Encoding Outline
-
TTT.2.3.3. Encoding Details
-
-
TTT.2.3.3.1. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.3.3.1.1. Frame of Reference Module Recommendations
-
TTT.2.3.3.1.2. Pixel Measures Macro Recommendations
-
TTT.2.3.3.1.3. Plane Position (Patient) Macro Recommendations
-
TTT.2.3.3.1.4. Plane Orientation (Patient) Macro Recommendations
-
TTT.2.3.3.1.5. Frame Content Macro Recommendations
-
TTT.2.3.3.1.6. Frame Anatomy Macro Recommendations
-
TTT.2.3.4. Example
-
TTT.2.4. Case #4: Multiple Rotations, One Or More 2D Instances, One Reconstruction, One X-Ray 3D Instance
-
-
TTT.2.4.1. User Scenario
-
TTT.2.4.2. Encoding Outline
-
TTT.2.4.3. Encoding Details
-
-
TTT.2.4.3.1. 2D X-Ray Angiographic Image IOD
-
-
TTT.2.4.3.1.1. Frame of Reference Module Recommendations
-
TTT.2.4.3.2. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.4.3.2.1. X-Ray 3D Angiographic Image Contributing Sources Module Recommendations
-
TTT.2.4.3.2.2. X-Ray 3D Angiographic Acquisition Module Recommendations
-
TTT.2.4.3.2.3. Frame Content Macro Recommendations
-
TTT.2.4.4. Example
-
TTT.2.5. Case #5: One Rotation, One 2D Instance, Multiple Reconstructions, One X-Ray 3D Instance
-
-
TTT.2.5.1. User Scenario
-
TTT.2.5.2. Encoding Outline
-
TTT.2.5.3. Encoding Details
-
-
TTT.2.5.3.1. 2D X-Ray Angiographic Image IOD
-
TTT.2.5.3.2. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.5.3.2.1. Image Pixel Module Recommendations
-
TTT.2.5.3.2.2. Multi-frame Dimension Module Recommendations
-
TTT.2.5.3.2.3. X-Ray 3D Angiographic Acquisition Module Recommendations
-
TTT.2.5.3.2.4. X-Ray 3D Reconstruction Module Recommendations
-
TTT.2.5.3.2.5. Frame Content Macro Recommendations
-
TTT.2.5.3.2.6. Cardiac Synchronization Macro Recommendations
-
TTT.2.5.3.2.7. X-Ray 3D Frame Type Macro Recommendations
-
TTT.2.5.4. Example
-
TTT.2.6. Case #6: Two Rotations, Two 2D Instances, Two Reconstructions, Two X-Ray 3D Instances
-
-
TTT.2.6.1. User Scenario
-
TTT.2.6.2. Encoding Outline
-
TTT.2.6.3. Encoding Details
-
-
TTT.2.6.3.1. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.6.3.1.1. Frame of Reference Module Recommendations
-
TTT.2.6.3.1.2. Patient Orientation Module Recommendations
-
TTT.2.6.3.1.3. Pixel Measures Macro Recommendations
-
TTT.2.6.3.1.4. Plane Position (Patient) Macro Recommendations
-
TTT.2.6.3.1.5. Plane Orientation (Patient) Macro Recommendations
-
TTT.2.6.4. Example
-
TTT.2.7. Case #7: Spatial Registration of 3D X-Ray Angiography With Enhanced XA
-
-
TTT.2.7.1. User Scenario
-
TTT.2.7.2. Encoding Outline
-
TTT.2.7.3. Encoding Details
-
-
TTT.2.7.3.1. Enhanced X-Ray Angiographic Image IOD
-
TTT.2.7.3.2. X-Ray 3D Angiographic Image IOD
-
-
TTT.2.7.3.2.1. Frame of Reference Module Recommendations
-
TTT.2.7.3.2.2. Patient Orientation Module
-
TTT.2.7.3.2.3. Image - Equipment Coordinate Relationship Module
-
TTT.2.7.3.2.4. X-Ray 3D Angiographic Acquisition Module Recommendations
-
TTT.2.7.4. Example
-
UUU. Ophthalmology Use Cases (Informative)
-
-
UUU.1. Wide Field Ophthalmic Use Cases
-
-
UUU.1.1. Clinical Use Cases
-
-
UUU.1.1.1. Routine Wide Field Image For Surveillance For Diabetic Retinopathy
-
UUU.1.1.2. Patient With Myopia
-
UUU.1.1.3. Patient With Diabetes
-
UUU.1.1.4. Patient With Age Related Macular Degeneration (ARMD)
-
UUU.1.2. Stereographic Projection (SP)
-
-
UUU.1.2.1. Distance
-
UUU.1.2.2. Area
-
UUU.1.2.3. Angle
-
UUU.1.3. Introduction to 2D to 3D Map For Wide Field Ophthalmic Photography
-
-
UUU.1.3.1. Measuring the Length of a Path
-
UUU.1.3.2. Shortest Distance Between Two Points
-
UUU.1.3.3. Computing The Area of A Region of Interest
-
UUU.1.3.4. Transformation Method Code Sequence
-
UUU.2. Relationship Between Ophthalmic Tomography Image and Ophthalmic Optical Coherence Tomography B-scan Volume Analysis IODs
-
UUU.3. Ophthalmic Tomography Angiography Examples
-
-
UUU.3.1. Clinical Examples
-
-
UUU.3.1.1. Diabetic Macular Ischemia
-
UUU.3.1.2. Age Related Macular Degeneration
-
UUU.3.1.3. Branch Retinal Vein Occlusion
-
UUU.3.2. Research Examples
-
-
UUU.3.2.1. Proliferative Diabetic Retinopathy
-
VVV. Segmentation of Images of Groups of Animals (Informative)
-
-
VVV.1. Use Case
-
-
VVV.1.1. Reference Attributes
-
-
VVV.1.1.1. Acquired Images of Multiple Animals
-
VVV.1.1.2. Segmentation Instances
-
VVV.1.1.3. Derived Images of Single Animals
-
VVV.1.2. Propagation of Composite Context
-
VVV.1.3. Propagation of History
-
WWW. Tractography Results (Informative)
-
-
WWW.1. Introduction
-
WWW.2. Encoding Example
-
XXX. Volumetric Presentation States (Informative)
-
-
XXX.1. Scope of Volumetric Presentation States
-
-
XXX.1.1. Volumetric Presentation States vs. Softcopy Presentation States
-
XXX.1.2. Image Creation Process
-
XXX.1.3. Volumetric Presentation State Display Consistency
-
XXX.2. Volumetric Presentation States vs. Static Derived Images
-
-
XXX.2.1. Static Derived Images
-
XXX.2.2. Volumetric Presentation States
-
XXX.2.3. Both Volumetric Presentation States and Linked Static Images
-
XXX.3. Use Cases
-
-
XXX.3.1. Simple Planar MPR View
-
-
XXX.3.1.1. User Scenario
-
XXX.3.1.2. Encoding Outline
-
XXX.3.1.3. Encoding Details
-
-
XXX.3.1.3.1. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.1.3.2. Volumetric Presentation State Display Module Recommendations
-
XXX.3.2. Spatially Related Views (e.g., Orthogonal)
-
-
XXX.3.2.1. User Scenario
-
XXX.3.2.2. Encoding Outline
-
XXX.3.2.3. Encoding Details
-
-
XXX.3.2.3.1. Volumetric Presentation State Identification Module Recommendations
-
XXX.3.2.3.2. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.2.3.3. Presentation View Description Module Recommendations
-
XXX.3.3. Replacing Set of Derived Images with Multiple Volumetric Presentation States
-
-
XXX.3.3.1. User Scenario
-
XXX.3.3.2. Encoding Outline
-
XXX.3.3.3. Encoding Details
-
-
XXX.3.3.3.1. Volumetric Presentation State Identification Module Recommendations
-
XXX.3.4. Replacing Set of Derived Images With Single VPS Using Crosscurve Animation
-
-
XXX.3.4.1. User Scenario
-
XXX.3.4.2. Encoding Outline
-
XXX.3.4.3. Encoding Details
-
-
XXX.3.4.3.1. Presentation Animation Module Recommendations
-
XXX.3.5. Volumetric Annotations (example: Trajectory Planning)
-
-
XXX.3.5.1. User Scenario
-
XXX.3.5.2. Encoding Outline
-
XXX.3.5.3. Encoding Details
-
-
XXX.3.5.3.1. Volumetric Graphic Annotation Module Recommendations
-
XXX.3.6. Highlighting Areas of Interest in MPR View
-
-
XXX.3.6.1. User Scenario
-
XXX.3.6.2. Encoding Outline
-
XXX.3.6.3. Encoding Details
-
-
XXX.3.6.3.1. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.6.3.2. Volumetric Presentation State Cropping Module Recommendations
-
XXX.3.6.3.3. Volumetric Presentation State Display Module Recommendations
-
XXX.3.7. Ultrasound Color Flow MPR
-
-
XXX.3.7.1. User Scenario
-
XXX.3.7.2. Encoding Outline
-
XXX.3.7.3. Encoding Details
-
-
XXX.3.7.3.1. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.7.3.2. Presentation View Description Module Recommendations
-
XXX.3.7.3.3. Multi-Planar Reconstruction Geometry Module Recommendations
-
XXX.3.7.3.4. Volumetric Presentation State Display Module Recommendations
-
XXX.3.8. Blending with Functional Data, e.g., PET/CT or Perfusion Data
-
-
XXX.3.8.1. User Scenario
-
XXX.3.8.2. Encoding Outline
-
XXX.3.8.3. Encoding Details
-
-
XXX.3.8.3.1. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.8.2.3. Volumetric Presentation State Display Module Recommendations
-
XXX.3.9. Stent Stabilization
-
-
XXX.3.9.1. User Scenario
-
XXX.3.9.2. Encoding Outline
-
XXX.3.9.3. Encoding Details
-
-
XXX.3.9.3.1. Volumetric Presentation State Identification Module Recommendations
-
XXX.3.9.3.2. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.9.3.3. Presentation View Description Module Recommendations
-
XXX.3.9.3.4. Presentation Animation Module Recommendations
-
XXX.3.10. Highlighting Areas of Interest in Volume Rendered View
-
-
XXX.3.10.1. User Scenario
-
XXX.3.10.2. Encoding Outline
-
XXX.3.10.3. Encoding Details
-
-
XXX.3.10.3.1. Volume Presentation State Relationship Module Recommendations
-
XXX.3.10.3.2. Volume Render Geometry Module Recommendations
-
XXX.3.10.3.3. Render Shading Module Recommendations
-
XXX.3.10.3.4. Render Display Module Recommendations
-
XXX.3.10.3.5. Volumetric Graphic Annotation Module Recommendations
-
XXX.3.10.3.6. Graphic Layer Module Recommendations
-
XXX.3.11. Colorized Volume Rendering of Segmented Volume Data
-
-
XXX.3.11.1. User Scenario
-
XXX.3.11.2. Encoding Outline
-
XXX.3.11.3. Encoding Details
-
-
XXX.3.11.3.1. Volumetric Presentation State Relationship Module Recommendations
-
XXX.3.11.3.2. Volume Render Geometry Module Recommendations
-
XXX.3.11.3.3. Render Shading Module Recommendations
-
XXX.3.11.3.4. Render Display Module Recommendations
-
XXX.3.12. Liver Resection Planning
-
-
XXX.3.12.1. User Scenario
-
XXX.3.12.2. Encoding Outline
-
XXX.3.12.3. Encoding Details
-
-
XXX.3.12.3.1. Volumetric Presentation State Relatonship Module Recommendations
-
XXX.3.12.3.2. Volume Cropping Module Recommendations
-
XXX.3.12.3.3. Volume Cropping Module Recommendations
-
XXX.3.12.3.4. Render Shading Module Recommendations
-
XXX.3.12.3.5. Render Display Module Recommendations
-
XXX.4. Uses of Presentation View Description in the Identification Module
-
-
XXX.4.1. Hanging Protocols
-
XXX.4.2. Structured Displays
-
XXX.4.3. Ad Hoc Display Layout
-
XXX.5. Compositing and the Use of Weighting Transfer Functions
-
-
XXX.5.1. Fixed Proportional Compositing
-
XXX.5.2. Partially Transparent A Over B Compositing
-
XXX.5.3. Pass-through Compositing
-
XXX.5.4. Threshold Compositing
-
XXX.6. Usage of the Classification and Compositing Components
-
YYY. Preclinical Small Animal Imaging Acquisition Context (Informative)
-
-
YYY.1.
-
-
YYY.1.1. Example of housing and anesthesia for PET-CT
-
YYY.1.2. Example of exogenous substance administration to encode tumor cell line
-
YYY.1.3. Informative References
-
ZZZ. Content Assessment (Informative)
-
-
ZZZ.1. RT Plan Treatment Assessment Use Case
-
AAAA. Protocol Storage Examples and Concepts (Informative)
-
-
AAAA.1. Protocol Storage Concepts
-
-
AAAA.1.1. Use Cases
-
-
AAAA.1.2. Workflow
-
AAAA.1.3. XA Workflow
-
AAAA.2. CT Routine Adult Head Protocol
-
-
AAAA.2.1. Common Context
-
AAAA.2.2. Scantech Industries
-
AAAA.2.3. Acme
-
AAAA.3. CT Protocol For Tumor Volumetric Measurements
-
-
AAAA.3.1. Common Context
-
AAAA.3.2. Acme
-
AAAA.4. Single XA Device For Acquisition and Reconstruction
-
-
AAAA.4.1. Common Context
-
AAAA.4.2. Angiotech Industries
-
AAAA.5. Two XA Devices For Acquisition and Reconstruction
-
-
AAAA.5.1. Acquisition and Storage Protocol
-
AAAA.5.2. Rotational XA Image
-
AAAA.5.3. Reconstruction Protocol
-
BBBB. Color information for Parametric Object (Informative)
-
-
BBBB.1. Introduction
-
BBBB.2. Encoding Example
-
CCCC. Populating The Simplified Echo Procedure Report Template (Informative)
-
-
CCCC.1. Structure Overview
-
CCCC.2. Use Cases
-
-
CCCC.2.1. Use Case 1: Store and Extract Specific Measurement
-
-
CCCC.2.1.1. Configuration
-
CCCC.2.1.2. Operation
-
CCCC.2.2. Use Case 2: Store and Process Measurements
-
-
CCCC.2.2.1. Configuration
-
CCCC.2.2.2. Operation
-
CCCC.3. Differences of Note Between TID_5200 and TID 5300
-
-
CCCC.3.1. Report Sections
-
CCCC.3.2. Finding Observation Type
-
CCCC.4. Usage Guidance
-
-
CCCC.4.1. Finding Site
-
CCCC.4.2. Measured Property
-
CCCC.4.3. Image View
-
CCCC.4.4. Cardiac Cycle Point
-
CCCC.4.5. Measurement Method
-
CCCC.4.6. Selection Status
-
CCCC.4.7. Additional Modifiers
-
CCCC.5. Example
-
DDDD. Types of Echocardiography Measurement Specifications (Informative)
-
-
DDDD.1. Overview
-
DDDD.2. Specification of Standard Measurements
-
DDDD.3. Specification of Non-standard Measurements
-
-
DDDD.3.1. Acquiring the Intended Real-World Quantity
-
DDDD.3.2. Interpreting the Non-Standard Measurement
-
DDDD.3.3. Determining Equivalence of Measurements from Different Sources
-
DDDD.4. Specification of Adhoc (One-Time) Measurements
-
EEEE. Encoding Diffusion Model Parameters for Parametric Maps and ROI Measurements (Informative)
-
-
EEEE.1. Encoding Diffusion Model Parameters for Parametric Maps
-
EEEE.2. Encoding Diffusion Model Parameters for ROIs in Measurement Report SR Documents
-
EEEE.3. Relationship of Derived Diffusion Model Parametric Maps to Diffusion Weighted Source Images
-
EEEE.4. Image and Frame of Derived Diffusion Model Parametric Maps
-
EEEE.5. Informative References
-
FFFF. Advanced Blending Presentation State Storage Encoding Example (Informative)
-
-
FFFF.1. Introduction
-
FFFF.2. Example
-
FFFF.3. Encoding Example
-
GGGG. Patient Radiation Dose Structured Report Document (Informative)
-
-
GGGG.1. Skin Dose Map Example
-
GGGG.2. Dual-source CT Organ Radiation Dose Example
-
HHHH. Protocol Approval Examples and Concepts (Informative)
-
IIII. Encapsulated STL (Informative)
-
-
IIII.1. Example of CT Derived Encapsulated STL
-
IIII.2. Example of Fused CT/MR Derived Encapsulated STL
-
JJJJ. Multi-energy CT Imaging (Informative)
-
-
JJJJ.1. Domain of Application
-
JJJJ.2. Use Cases
-
JJJJ.3. Classification of Multi-energy Images
-
JJJJ.4. Presentation of Multi-energy Images by Legacy Display Systems
-
JJJJ.5. Examples of Implementation
-
-
JJJJ.5.1. Examples For Objective Image Family
-
-
JJJJ.5.1.1. Example Multiple Physical Sources and Multiple Physical Detectors
-
JJJJ.5.1.2. Example Single Source Multi-layer Detector
-
JJJJ.5.2. Examples For Material Quantification Image Family
-
-
JJJJ.5.2.1. Example Switching Source Integrating Detector
-
JJJJ.5.3. Examples For Enhanced CT Image Multi-Frame, Multi-Energy
-
-
JJJJ.5.3.1. Example For Mixed Multi-Energy Image Types
-
KKKK. Encoding Quantitative Image Family Parameters (Informative)
-
-
KKKK.1. Encoding of Quantitative Image Family Parameters With RWVM
-
LLLL. Imaging Agent Administration Report Template (Informative)
-
-
LLLL.1. Purpose of this Annex
-
LLLL.2. Use Cases
-
-
LLLL.2.1. Use Case 1 - Manual Bolus Injection
-
LLLL.2.2. Use Case 2 - Automatic Infusion Pump - Contrast Reporting
-
LLLL.2.3. Use Case 3 - Protocoling
-
LLLL.2.4. Use Case 4 - Consumption of the Contrast Information by Reporting Systems for Automated Documentation
-
LLLL.3. Informative References
-
MMMM. Performed Imaging Agent Administration Structured Report (Informative)
-
-
MMMM.1. Performed Imaging Agent Administration Structured Report
-
NNNN. Mapping of Visible Light Photography Related Attributes to EXIF and TIFF/EP Tags (Informative)
-
-
NNNN.1. Mapping
-
NNNN.2. Informative References
-
OOOO. Encoding Perfusion Parameters for Parametric Maps and ROI Measurements (Informative)
-
-
OOOO.1. Encoding Relative Cerebral Tumor Blood Flow for Parametric Maps
-
OOOO.2. Encoding Relative Cerebral Tumor Blood Volume for ROIs in Measurement Report SR Documents
-
OOOO.5. Informative References
-
PPPP. Real-Time Video Use Cases (Informative)
-
-
PPPP.1. Introduction
-
PPPP.2. Use Case: Duplicating Video On Additional Monitors
-
PPPP.3. Use Case: Post Review by Senior
-
PPPP.4. Use Case: Automatic Display in Operating Room (or)
-
PPPP.5. Use Case: Augmented Reality
-
PPPP.6. Use Case: Robotic Aided Surgery
-
PPPP.7. Example of DICOM Real-Time Video Implementation
-
PPPP.8. Storage Considerationa
-
-
PPPP.8.1. Creating IOD From DICOM-RTV Streams
-
PPPP.8.2. Streaming DICOM-RTV From Stored IOD
-
PPPP.9. Example of Engineering Implementation
-
PPPP.20. Transmitting a Stereo Video
-
QQQQ. Transport of Elementary Stream over IP (Informative)
-
RRRR. Encapsulated OBJ, 3D Model Grouping, & Color (Informative)
-
-
RRRR.1. Overview
-
RRRR.2. Example Encoding of OBJ & MTL
-
-
RRRR.2.1. Example A
-
RRRR.3. Manufacturing Model Grouping, Color & Opacity
-
SSSS. Neurophysiology Waveforms
-
-
SSSS.1. Purpose of This Annex
-
-
SSSS.1.1. Electroencephalography
-
SSSS.1.2. Electromyography
-
SSSS.1.3. Electrooculography
-
SSSS.1.4. Body Position
-
SSSS.1.5. Polysomnography
-
-
SSSS.1.5.1. Mapping of Polysomnographic Data to DICOM
-
SSSS.1.6. Considerations On Storing Large Data Recordings
-
SSSS.1.7. Example DICOM Routine Scalp EEG Waveform Object
-
TTTT. Dermoscopy (Informative)
-
-
TTTT.1. Measurements
-
TTTT.2. Frame of Reference
-
TTTT.3. Use Cases
-
-
TTTT.3.1. Use Case 1: Linking Dermoscopic Images to A Regional Image
-
-
TTTT.3.1.1. Potential acquisition workflow
-
TTTT.3.1.2. Considerations
-
TTTT.3.1.3. Potential display functionality
-
TTTT.3.2. Use Case 2: Longitudinal Lesion Tracking
-
-
TTTT.3.2.1. Potential workflow for the acquisition of lesion tracking information
-
TTTT.3.2.2. Considerations
-
TTTT.3.2.3. Potential workflow for the display of lesion tracking
-
UUUU. Radiation Dose Structured Reporting (Informative)
-
-
UUUU.1. Cone Beam CT (CBCT) Enhanced RDSR in TID 10040
-
VVVV. Microscopy Bulk Simple Annotations (Informative)
-
-
VVVV.1. Introduction
-
VVVV.2. Encoding Example
-
WWWW. Prostate Imaging Report SR Document
-
-
WWWW.1. Prostate Imaging Report SR Document with Minimal Content
-
WWWW.2. Application of the templates describing multiparametric MRI acquisition
-
WWWW.3. Application of the templates describing multiparametric MRI image quality
-
WWWW.4. Prostate MRI relevant patient information
-
WWWW.5. Complete Prostate Imaging Report SR Document
-
XXXX. Radiotherapy Examples
-
-
XXXX.1. RT Structure Set
-
-
XXXX.1.1. Coding RT ROI Interpreted Type Information
-
YYYY. Inventories (Informative)
-
-
YYYY.1. The DICOM Data Management Environment
-
-
YYYY.1.1. Inventories
-
YYYY.2. Repository Query
-
-
YYYY.2.1. Overview
-
YYYY.2.2. Record Key and Continuation
-
YYYY.2.3. Key Matching Attributes
-
-
YYYY.2.3.1Objects. Removed From Operational Use
-
YYYY.2.3.2. Access to Stored Objects
-
YYYY.2.3.3. Managed Metadata and Updated Metadata
-
YYYY.2.3.4. Study Update Datetime
-
YYYY.3. The Inventory Information Object
-
-
YYYY.3.1. Overview
-
YYYY.3.2. Scope of Inventory
-
YYYY.3.3. Inventory Instance Tree
-
-
YYYY.3.3.1. Scope and Completion Status
-
YYYY.3.3.2. Examples
-
-
YYYY.3.3.2.1. Serial Production
-
YYYY.3.3.2.2. Baseline and Increment
-
YYYY.3.3.2.3. Parallel Production
-
YYYY.3.3.2.4. Arbitrary Tree Structure
-
YYYY.3.3.2.5. Empty Inventory
-
YYYY.3.4. Access Mechanisms For Repository Data
-
YYYY.3.5. Additional Data Elements
-
YYYY.3.6. Producer vs. Consumer Implementation
-
YYYY.4. Related Services For Inventory SOP Instances
-
-
YYYY.4.1. Inventory Storage and Query/retrieve
-
YYYY.4.2. Inventory Creation Service
-
YYYY.4.3. Separability of Services
-
YYYY.5. Use Cases
-
-
YYYY.5.1. Migration and Consolidation
-
YYYY.5.2. Safety Backup
-
YYYY.5.3. Research
-
YYYY.5.4. Quality Assurance
-
YYYY.5.5. Wellness Check/Continuous Testing
-
YYYY.6. Security Considerations
-
-
YYYY.6.1. Access Control and Secure Transport
-
-
YYYY.6.1.1. Access Control in Production of Inventory
-
YYYY.6.2. File Format
-
YYYY.6.3. Network Protocols
-
YYYY.6.4. Application Validation
-
YYYY.6.5. Inventory Resource Use
-
YYYY.6.6. Encryption of Data At Rest
-
YYYY.6.7. Message Digest
-
YYYY.6.8. De-identification
-
YYYY.7. Operational Considerations
-
-
YYYY.7.1. Transforming Repository Query Responses into Inventory SOP Instances
-
YYYY.7.2. Using Non-DICOM Protocols
-
YYYY.7.3. Using Referenced Inventories
-
YYYY.7.4. Incremental Inventories
-
YYYY.7.5. Inventory Lifecycle Management
-
YYYY.7.6. Interactive Access to Inventory Content
-
YYYY.7.7. Multiple Application Entity Titles
-
YYYY.7.8. Multiple Patient IDs
-
YYYY.7.9. Metadata Updates
-
-
YYYY.7.9.1. Original Attributes Sequence
-
YYYY.7.10. Study Record Reconciliation
-
-
YYYY.7.10.1. Example - Deleted Study
-
YYYY.7.11. Key Attributes Unsupported For Matching
-
ZZZZ. Variable Modality LUT Softcopy Presentation State Storage (Informative)
-
-
ZZZZ.1. Example 1 - Pseudo-color Transformations to a Pseudo-color Reference Image
-
ZZZZ.2. Example 2 - Grayscale Transformations to a Pseudo-color Reference Image
-
ZZZZ.3. Example 3 - Pseudo-color Transformations to a Grayscale Reference Image
-
ZZZZ.4. Example 4 - Grayscale Transformations to a Grayscale Reference Image
-
AAAAA. Photoacoustic Imaging (Informative)
-
-
AAAAA.1. Introduction
-
AAAAA.2. Use Cases
-
-
AAAAA.2.1. Acquisition and Storage
-
AAAAA.2.2. Presentation and Review
-
-
AAAAA.2.2.1. Fusion Visualization With Complementary Imaging Modalities
-
AAAAA.2.3. Example Workflow
-
AAAAA.3. Acquisition Examples
-
-
AAAAA.3.1. Example 1: Photoacoustic Standalone Image
-
-
AAAAA.3.1.1. Photoacoustic Single Wavelength Standalone Image
-
AAAAA.3.1.2. Photoacoustic Dimension Index Sequence For Examples
-
AAAAA.3.1.3. Photoacoustic Standalone Image Per-Frame Example
-
AAAAA.3.2. Example 2: Photoacoustic/Ultrasound Coupled Acquisition
-
-
AAAAA.3.2.1. Photoacoustic Dimension Index Sequence For Examples
-
AAAAA.3.2.2. Ultrasound Dimension Index Sequence For Examples
-
AAAAA.3.2.3. Photoacoustic/Ultrasound Coupled Acquisition Per-Frame Example
-
AAAAA.3.3. Example 3: Stationary Tomographic 3D Photoacoustic/Ultrasound Coupled Acquisition
-
-
AAAAA.3.3.1. Photoacoustic and Ultrasound Dimension Index Sequence For Examples
-
AAAAA.3.3.2. Stationary Tomographic 3D Photoacoustic/Ultrasound Per-Frame Example
-
AAAAA.3.4. Photoacoustic Attribute Example Values
-
AAAAA.4. Real World Display Examples
-
AAAAA.5. References
-
BBBBB. Cutaneous Confocal Microscopy (Informative)
-
-
BBBBB.1. Cutaneous Confocal Microscopy Imaging Study
-
BBBBB.2. Cutaneous Confocal Microscopy Raw Data
-
BBBBB.3. Pre-rendered Pseudo Color Images
-
BBBBB.4. Correlation of Macroscopic and Confocal Images
-
-
BBBBB.4.1. In-Vivo Confocal Microscopy Imaging Acquisition Method
-
BBBBB.4.2. Ex-Vivo Confocal Microscopy Imaging Acquisition Method
-
BBBBB.5. Specimen Preparation
-
BBBBB.6. Series Organization
-
BBBBB.7. Encoding of Confocal Microscopsy Tiled Pyramidal Images
-
BBBBB.8. Frame of Reference Module
List of Tables
- C.6-1. Correspondence Between DICOM and HL7 Channel Definition
- K.4-1. Attributes That Convey Staged Protocol Related Information
- K.5-1. Staged Protocol Image Attributes Example
- K.5-2. Comparison Of Protocol And Extra-Protocol Image Attributes Example
- Q.2-1. Breast Image Report Content for Example 1
- Q.2-2. Breast Imaging Report Content for Example 2
- Q.2-3. Breast Imaging Report Content for Example 3
- Q.2-4. Breast Imaging Report Content for Example 4
- X.3-1. WADO Reference in an HL7 CDA <linkHtml>
- X.3-2. DICOM Study Reference in an HL7 V3 Act (CDA Act Entry)
- X.3-3. DICOM Series Reference in an HL7 V3 Act (CDA Act Entry)
- X.3-4. Modality Qualifier for The Series Act.Code
- X.3-5. DICOM Composite Object Reference in an HL7 V3 Act (CDA Observation Entry)
- X.3-6. WADO Reference in an HL7 DGIMG Observation.Text
- FF.3-1. Example #1 Report Encoding
- II-1. Contrast/Bolus Module Attribute Mapping
- II-2. Enhanced Contrast/Bolus Module Attribute Mapping
- II-3. Device Module Attribute Mapping
- II-4. Intervention Module Attribute Mapping
- NN.6-1. Specimen Module for Gross Specimen
- NN.6-2. Specimen Preparation Sequence for Gross Specimen
- NN.6-3. Specimen Module for a Slide
- NN.6-4. Specimen Preparation Sequence for Slide
- OO.1.1-1. Hanging Protocol Names for Dental Image Layout based on JSOMR classification
- QQ.1-1. Enhanced US Data Type Blending Examples (Informative)
- RR-1. Reference Table for Use with Traditional Charts
- RR-2. Reference Table for Use with ETDRS Charts or Equivalent
- YY-1. Graphic Annotation Module Attributes
- YY-2. Graphic Annotation Module Attributes
- YY-3. Graphic Group Module
- YY-4. Graphic Annotation Module Attributes
- ZZ.4-1. Attributes Used to Describe a Mono Stem Implant for Total Hip Replacement
- ZZ.4-2. Attributes Used to Describe a Mono Cup Implant for Total Hip Replacement
- ZZ.4-3. Attributes Used to Describe The Assembly of Cup and Stem
- AAA.3-1. Total Hip Replacement Example
- AAA.3-2. Dental Drilling Template Example
- FFF.2.1-1. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-2. Enhanced XA Image Functional Group Macros
- FFF.2.1-3. Synchronization Module Recommendations
- FFF.2.1-4. Cardiac Synchronization Module Recommendations
- FFF.2.1-5. Enhanced XA/XRF Image Module Recommendations
- FFF.2.1-6. Frame Content Macro Recommendations
- FFF.2.1-7. General ECG IOD Modules
- FFF.2.1-8. General Series Module Recommendations
- FFF.2.1-9. Synchronization Module Recommendations
- FFF.2.1-10. Waveform Identification Module Recommendations
- FFF.2.1-11. Waveform Module Recommendations
- FFF.2.1-12. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-13. Enhanced XA Image Functional Group Macros
- FFF.2.1-14. Synchronization Module Recommendations
- FFF.2.1-15. Frame Content Macro Recommendations
- FFF.2.1-16. Waveform IOD Modules
- FFF.2.1-18. Waveform Identification Module Recommendations
- FFF.2.1-19. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-20. Enhanced XA Image Functional Group Macros
- FFF.2.1-21. Synchronization Module Recommendations
- FFF.2.1-22. Enhanced XA/XRF Image Module Recommendations
- FFF.2.1-23. Frame Content Macro Recommendations
- FFF.2.1-24. Waveform IOD Modules
- FFF.2.1-25. Synchronization Module Recommendations
- FFF.2.1-26. Waveform Identification Module Recommendations
- FFF.2.1-27. Waveform Module Recommendations
- FFF.2.1-28. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-29. Enhanced XA Image Functional Group Macros
- FFF.2.1-30. XA/XRF Acquisition Module Example
- FFF.2.1-31. X-Ray Positioner Macro Example
- FFF.2.1-32. X-Ray Isocenter Reference System Macro Example
- FFF.2.1-33. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-34. Enhanced XA Image Functional Group Macros
- FFF.2.1-35. XA/XRF Acquisition Module Example
- FFF.2.1-36. X-Ray Table Position Macro Example
- FFF.2.1-37. X-Ray Isocenter Reference System Macro Example
- FFF.2.1-38. Enhanced XA Image Functional Group Macros
- FFF.2.1-39. X-Ray Exposure Control Sensing Regions Macro Recommendations
- FFF.2.1-40. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-41. Enhanced XA Image Functional Group Macros
- FFF.2.1-42. XA/XRF Acquisition Module Recommendations
- FFF.2.1-43. X-Ray Detector Module Recommendations
- FFF.2.1-44. X-Ray Field of View Macro Recommendations
- FFF.2.1-45. XA/XRF Frame Pixel Data Properties Macro Recommendations
- FFF.2.1-46. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-47. Enhanced XA Image Functional Group Macros
- FFF.2.1-48. Contrast/Bolus Usage Macro Recommendations
- FFF.2.1-49. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.1-50. Enhanced XA Image Functional Group Macros
- FFF.2.1-51. XA/XRF Acquisition Module Recommendations
- FFF.2.1-52. X-Ray Frame Acquisition Macro Recommendations
- FFF.2.2-1. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.2-2. XA/XRF Multi-frame Presentation Module Recommendations
- FFF.2.3-1. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.3-2. Enhanced XA Image Functional Group Macros
- FFF.2.3-3. Enhanced XA/XRF Image Module Recommendations
- FFF.2.3-4. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.3-5. Mask Module Recommendations
- FFF.2.3-6. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.3-7. Enhanced XA Image Functional Group Macros
- FFF.2.3-8. Mask Module Recommendations
- FFF.2.3-9. Frame Pixel Shift Macro Recommendations
- FFF.2.4-1. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.4-2. Enhanced XA Image Functional Group Macros
- FFF.2.4-3. XA/XRF Acquisition Module Recommendations
- FFF.2.4-4. XA/XRF Frame Pixel Data Properties Macro Recommendations
- FFF.2.4-5. X-Ray Projection Pixel Calibration Macro Recommendations
- FFF.2.4-6. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.4-7. Enhanced XA Image Functional Group Macros
- FFF.2.4-8. Enhanced XA/XRF Image Module Recommendations
- FFF.2.4-9. Derivation Image Macro Recommendations
- FFF.2.4-10. XA/XRF Frame Characteristics Macro Recommendations
- FFF.2.4-11. XA/XRF Frame Pixel Data Properties Macro Recommendations
- FFF.2.5-1. Enhanced X-Ray Angiographic Image IOD Modules
- FFF.2.5-2. Enhanced XA Image Functional Group Macros
- FFF.2.5-3. XA/XRF Acquisition Module Recommendations
- GGG.1-1. SOP Classes for Typical Implementation Examples
- HHH.1-1. Summary of DICOM/Rendered URI Based WADO Parameters
- PPP.3.1-1. N-GET Request/Response Example
- PPP.3.1-2. Example of N-GET Request/Response for QA Result Module
- PPP.3.2-1. N-GET Request/Response Example
- RRR.1-1. Volumetric ROI on CT Example
- RRR.2-1. Volumetric ROI on CT Example
- RRR.3-1. Planar ROI on DCE-MR Example
- RRR.4-1. SUV ROI on FDG PET Example
- RRR.5-1. Volumetric ROI on CT Example
- SSS.1-1. Image Library for PET-CT Example
- TTT.2.1-1. General and Enhanced Series Modules Recommendations
- TTT.2.1-2. Frame of Reference Module Recommendations
- TTT.2.1-3. Enhanced Contrast/Bolus Module Recommendations
- TTT.2.1-4. Multi-frame Dimensions Module Recommendations
- TTT.2.1-5. Patient Position to Orientation Conversion Recommendations
- TTT.2.1-6. X-Ray 3D Image Module Recommendations
- TTT.2.1-7. X-Ray 3D Angiographic Image Contributing Sources Module Recommendations
- TTT.2.1-8. X-Ray 3D Angiographic Acquisition Module Recommendations
- TTT.2.1-9. Frame Content Macro Recommendations
- TTT.2.2-1. X-Ray 3D Angiographic Acquisition Module Recommendations
- TTT.2.2-2. Frame Content Macro Recommendations
- TTT.2.3-1. Frame of Reference Module Recommendations
- TTT.2.3-2. Pixel Measures Macro Recommendations
- TTT.2.3-3. Frame Content Macro Recommendations
- TTT.2.4-1. Frame of Reference Module Recommendations
- TTT.2.4-2. X-Ray 3D Angiographic Image Contributing Sources Module Recommendations
- TTT.2.4-3. X-Ray 3D Angiographic Acquisition Module Recommendations
- TTT.2.4-4. Frame Content Macro Recommendations
- TTT.2.5-1. Multi-frame Dimension Module Recommendations
- TTT.2.5-2. X-Ray 3D Angiographic Acquisition Module Recommendations
- TTT.2.5-3. X-Ray 3D Reconstruction Module Recommendations
- TTT.2.5-4. Frame Content Macro Recommendations
- TTT.2.5-5. Cardiac Synchronization Macro Recommendations
- TTT.2.6-1. Frame of Reference Module Recommendations
- TTT.2.6-2. Pixel Measures Macro Recommendations
- TTT.2.7-1. Image-Equipment Coordinate Relationship Module Recommendations
- WWW-1. Example of the Tractography Results Module
- XXX.3.1-1. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.1-2. Volumetric Presentation State Display Module Recommendations
- XXX.3.2-1. Volumetric Presentation State Identification Module Recommendations
- XXX.3.2-2. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.2-3. Presentation View Description Module Recommendations
- XXX.3.3-1. Volumetric Presentation State Identification Module Recommendations
- XXX.3.4-1. Presentation Animation Module Recommendations
- XXX.3.5-1. Volumetric Graphic Annotation Module Recommendations
- XXX.3.6-1. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.6-2. Volumetric Presentation State Cropping Module Recommendations
- XXX.3.6-3. Volumetric Presentation State Display Module Recommendations
- XXX.3.7-1. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.7-2. Presentation View Description Module Recommendations
- XXX.3.7-3. Multi-Planar Reconstruction Geometry Module Recommendations
- XXX.3.7-4. Volumetric Presentation State Display Module Recommendations
- XXX.3.8-1. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.8-3. Volumetric Presentation State Display Module Recommendations
- XXX.3.9-1. Volumetric Presentation State Identification Module Recommendations
- XXX.3.9-2. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.9-3. Presentation View Description Module Recommendations
- XXX.3.9-4. Presentation Animation Module Recommendations
- XXX.3.10.3.1-1. Volume Presentation State Relationship Module Recommendations
- XXX.3.10.3.2-1. Volume Render Geometry Module Recommendations
- XXX.3.10.3.3-1. Render Shading Module Recommendations
- XXX.3.10.3.4-1. Render Display Module Recommendations
- XXX.3.10.3.5-1. Volumetric Graphic Annotation Module Recommendations
- XXX.3.10.3.6-1. Graphic Layer Module Recommendations
- XXX.3.11.3.1-1. Volumetric Presentation State Relationship Module Recommendations
- XXX.3.11.3.2-1. Volume Render Geometry Module Recommendations
- XXX.3.11.3.3-1. Render Shading Module Recommendations
- XXX.3.11.3.4-1. Render Display Module Recommendations
- XXX.3.12.3.1-1. Volumetric Presentation State Relatonship Module Recommendations
- XXX.3.12.3.2-1. Volume Cropping Module Recommendations
- XXX.3.12.3.3-1. Volume Cropping Module Recommendations
- XXX.3.12.3.4-1. Render Shading Module Recommendations
- XXX.3.12.3.5-1. Render Display Module Recommendations
- XXX.4.1-1. Hanging Protocol Image Set Sequence Recommendations
- ZZZ.1-1. Content Assessment Results Module Example of a RT Plan Treatment Assessment
- AAAA.2-1. Routine Adult Head - Context
- AAAA.2-2. Routine Adult Head - Details - Scantech
- AAAA.2-2a. Patient Specification
- AAAA.2-2b. First Acquisition Protocol Element Specification
- AAAA.2-2c. Second Acquisition Protocol Element Specification
- AAAA.2-2d. First Reconstruction Protocol Element Specification
- AAAA.2-3. AAPM Routine Brain Details - Acme
- AAAA.2-3a. Patient Specification
- AAAA.2-3b. First Acquisition Protocol Element Specification
- AAAA.2-3c. Second Acquisition Protocol Element Specification
- AAAA.2-3d. Third Acquisition Protocol Element Specification
- AAAA.2-3e. First Reconstruction Protocol Element Specification
- AAAA.2-3f. Second Reconstruction Protocol Element Specification
- AAAA.2-3g. First Storage Protocol Element Specification
- AAAA.2-3h. Second Storage Protocol Element Specification
- AAAA.2-3i. Third Storage Protocol Element Specification
- AAAA.3-1. CT Tumor Volumetric Measurement - Context
- AAAA.3-2. CT Tumor Volumetric Measurement - Details - Acme
- AAAA.3-2a. First Acquisition Protocol Element Specification
- AAAA.3-2b. Second Acquisition Protocol Element Specification
- AAAA.3-2c. First Reconstruction Protocol Element Specification
- AAAA.4-1. Adult Carotid Stenting Protocol - Context
- AAAA.4-2. Adult Carotid Stenting Protocol - Details - Angiotech
- AAAA.4-2a. Patient Specification
- AAAA.4-2b. First Acquisition Protocol Element Specification - FLUOROSCOPY NOSUB
- AAAA.4-2c. Second Acquisition Protocol Element Specification - DSA
- AAAA.4-2d. Third Acquisition Protocol Element Specification - ROTATIONAL SUB
- AAAA.4-2e. First Reconstruction Protocol Element Specification - 3D SUB RECONSTRUCTION
- AAAA.5-1. Acquisition and Storage Protocol
- AAAA.5-1a. Third Acquisition Protocol Element Specification - ROTATIONAL SUB ACQ
- AAAA.5-1b. First Storage Protocol Element Specification - SEND TO 3D WS
- AAAA.5-2. Rotational Image
- AAAA.5-3. Reconstruction Protocol
- AAAA.5-3a. First Reconstruction Protocol Element Specification - 3D SUB RECONSTRUCTION
- BBBB.2-1. Example data for the Floating Point Image Pixel Module
- BBBB.2-2. Example data for the Dimension Organization Module
- BBBB.2-3. Example data for the Pixel Measures Macro
- BBBB.2-4. Example data for the Frame Content Macro
- BBBB.2-5. Example data for the Identity Pixel Value Transformation Macro
- BBBB.2-6. Example data for the Frame VOI LUT With LUT Macro
- BBBB.2-7. Example data for the Real World Value Mapping Macro
- BBBB.2-8. Example data for the Palette Color Lookup Table Module
- BBBB.2-9. Example data for the Stored Value Color Range Macro
- BBBB.2-10. Example data for the Parametric Map Frame Type Macro
- FFFF.3-1. Encoding Example
- GGGG.1-1. Skin Dose Map Example
- GGGG.2-1. Dual-source CT Organ Radiation Dose Example
- HHHH-1. Approval by Chief Radiologist
- IIII.1-1. CT Derived Encapsulated STL Example
- IIII.2-1. Fused CT/MR Derived Encapsulated STL Example
- JJJJ.5.1.1-1. CT Image Module Attributes
- JJJJ.5.1.1-2. Multi-energy CT Image Attributes
- JJJJ.5.1.1-3. Multi-energy CT X-Ray Source Macro Attributes
- JJJJ.5.1.1-4. Multi-energy CT X-Ray Detector Macro Attributes
- JJJJ.5.1.1-5. Multi-energy CT Path Macro Attributes
- JJJJ.5.1.1-6. CT Exposure Macro Attributes
- JJJJ.5.1.1-7. CT X-Ray Details Sequence Macro Attributes
- JJJJ.5.1.1-8. CT Acquisition Details Macro Attributes
- JJJJ.5.1.1-9. CT Geometry Macro Attributes
- JJJJ.5.1.1-10. Multi-energy CT Processing Attributes
- JJJJ.5.1.2-1. CT Image Module Attributes
- JJJJ.5.1.2-2. Multi-energy CT Image Attributes
- JJJJ.5.1.2-3. Multi-energy CT X-Ray Source Macro Attributes
- JJJJ.5.1.2-4. Multi-energy CT X-Ray Detector Macro Attributes
- JJJJ.5.1.2-5. Multi-energy CT Path Macro Attributes
- JJJJ.5.1.2-6. CT Exposure Macro Attributes
- JJJJ.5.1.2-7. CT X-Ray Details Sequence Macro Attributes
- JJJJ.5.1.2-8. CT Acquisition Details Macro Attributes
- JJJJ.5.1.2-9. CT Geometry Macro Attributes
- JJJJ.5.1.2-10. Multi-energy CT Processing Attributes
- JJJJ.5.2.1-1. CT Image Module Attributes
- JJJJ.5.2.1-2. Multi-energy CT Image Attributes
- JJJJ.5.2.1-3. Multi-energy CT X-Ray Source Macro Attributes
- JJJJ.5.2.1-4. Multi-energy CT X-Ray Detector Macro Attributes
- JJJJ.5.2.1-5. Multi-energy CT Path Macro Attributes
- JJJJ.5.2.1-6. CT Exposure Macro Attributes
- JJJJ.5.2.1-7. CT X-Ray Details Sequence Macro Attributes
- JJJJ.5.2.1-8. CT Acquisition Details Macro Attributes
- JJJJ.5.2.1-9. CT Geometry Macro Attributes
- JJJJ.5.2.1-10. Multi-energy CT Processing Attributes
- JJJJ.5.3.1-1. Dimension Module
- JJJJ.5.3.1-2. Per-Frame Attributes
- KKKK.1-1. Example Material Specific Images for the Real World Value Mapping Macro
- KKKK.1-2. Example Value Based Images for the Real World Value Mapping Macro
- NNNN-1. Mapping of Visible Light Photography Related Attributes to EXIF Tags
- RRRR.2-1. Encapsulated OBJ Example A
- RRRR.2-2. Encapsulated MTL Example A
- RRRR.2-3. Multi-frame True Color Secondary Capture Texture Map Example A
- SSSS.1.7-1. Sample representation of a 23-lead Routine EEG object
- UUUU.1-1. Cone Beam CT (CBCT) Enhanced RDSR
- VVVV.2-1. Example of the Microscopy Bulk Simple Annotations Module
- WWWW.1-1. Prostate Imaging Report SR Document with Minimal Content
- WWWW.2-1. Application of the templates describing multiparametric MRI acquisition
- WWWW.3-1. Application of the templates describing multiparametric MRI image quality
- WWWW.4-1. Prostate MRI relevant patient information
- WWWW.5-1. Complete Prostate Imaging Report SR Document
- XXXX.1-1. Coding Example Prostate as GTV
- XXXX.1-2. Coding Example Left Eye as OAR
- XXXX.1-3. Coding Example Marker Coil as Registration Mark
- XXXX.1-4. Coding Example Object as PTV
- YYYY.7-1. Example Uses of Base and Relative Path URI
- YYYY.7-2. Use of URI-related Attributes
- YYYY.7-2b. Example Use of URI-related Attributes
- YYYY.7-2c. Example Updated Study Record with Original Attributes Sequences
- YYYY.7-3. Timestamp Attributes Assisting in Reconciliation
- AAAAA.3.1.2-1. Photoacoustic Example Dimension Index Sequence
- AAAAA.3.1.3-1. Photoacoustic Standalone Example, Wavelength 1, Frame 1
- AAAAA.3.1.3-2. Photoacoustic Standalone Example, Wavelength 2, Frame 1
- AAAAA.3.2.2-1. US Example Dimension Index Sequence for Photoacoustic/Ultrasound Coupled Acquisition
- AAAAA.3.2.3-1. Photoacoustic/Ultrasound Coupled Acquisition, Photoacoustic Image, Algorithm 1, Frame 1
- AAAAA.3.2.3-2. Photoacoustic/Ultrasound Coupled Acquisition, Photoacoustic Image, Algorithm 2, Frame 1
- AAAAA.3.2.3-3. Photoacoustic/Ultrasound Coupled Acquisition, Ultrasound Image, Frame 1
- AAAAA.3.3.2-1. Stationary tomographic 3D Photoacoustic/Ultrasound Example, Image Position (Volume), Frames 1 & 2
- AAAAA.3.4-1. Photoacoustic Attribute Example
- BBBBB.5-1. Confocal Microscopy Specimen Preparation Example
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.
This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.
The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].
PS3.1 should be used as the base reference for the current parts of this Standard.
DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.
HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development
Organisation
(IHTSDO), all rights reserved.
LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.
1 Scope and Field of Application
This Part of the DICOM Standard contains explanatory information in the form of Normative and Informative Annexes.
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.
For the purposes of this Standard the following definitions apply.
4 Symbols and Abbreviations
The following symbols and abbreviations are used in this Part of the Standard.
-
FHIR
-
HL7 Fast Healthcare Interoperability Resources (draft standard)
Terms listed in Section 3 are capitalized throughout the document.
A Explanation of Patient Orientation (Normative)
This Annex was formerly located in Annex E “Explanation of Patient Orientation (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
This Annex provides an explanation of how to use the patient orientation data elements.
As for the hand, the direction labels are based on the foot in the standard anatomic position. For the right foot, for example, RIGHT will be in the direction of the 5th toe. This assignment will remain constant through movement or positioning of the extremity. This is also true of the HEAD and FOOT directions.
B Integration of Modality Worklist and Modality Performed Procedure Step in The Original DICOM Standard (Informative)
This Annex was formerly located in Annex G “Integration of Modality Worklist and Modality Performed Procedure Step in the Original DICOM Standard (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
DICOM was published in 1993 and effectively addresses image communication for a number of modalities and Image Management functions for a significant part of the field of medical imaging. Since then, many additional medical imaging specialties have contributed to the extension of the DICOM Standard and developed additional Image Object Definitions. Furthermore, there have been discussions about the harmonization of the DICOM Real-World domain model with other standardization bodies. This effort has resulted in a number of extensions to the DICOM Standard. The integration of the Modality Worklist and Modality Performed Procedure Step address an important part of the domain area that was not included initially in the DICOM Standard. At the same time, the Modality Worklist and Modality Performed Procedure Step integration make steps in the direction of harmonization with other standardization bodies (CEN TC 251, HL7,
etc.).
The purpose of this Annex is to show how the original DICOM Standard relates to the extension for Modality Worklist Management and Modality Performed Procedure Step. The two included figures outline the void filled by the Modality Worklist Management and Modality Performed Procedure Step specification, and the relationship between the original DICOM Data Model and the extended model.
The management of a patient starts when the patient enters a physical facility (e.g., a hospital, a clinic, an imaging center) or even before that time. The DICOM Patient Management SOP Class provides many of the functions that are of interest to imaging departments. Figure B-1 is an example where one presumes that an order for a procedure has been issued for a patient. The order for an imaging procedure results in the creation of a Study Instance within the DICOM Study Management SOP Class. At the same time (A) the Modality Worklist Management SOP Class enables a modality operator to request the scheduling information for the ordered procedures. A worklist can be constructed based on the scheduling information. The handling of the requested imaging procedure in DICOM Study Management and in DICOM Worklist Management are closely related. The worklist also conveys patient/study
demographic information that can be incorporated into the images.
Worklist Management is completed once the imaging procedure has started and the Scheduled Procedure Step has been removed from the Worklist, possibly in response to the Modality Performed Procedure Step (B). However, Study Management continues throughout all stages of the Study, including interpretation. The actual procedure performed (based on the request) and information about the images produced are conveyed by the DICOM Study Component SOP Class or the Modality Performed Procedure Step SOP Classes.
Figure B-2 shows the relationship between the original DICOM Real-World model and the extensions of this Real-World model required to support the Modality Worklist and the Modality Performed Procedure Step. The new parts of the model add entities that are needed to request, schedule, and describe the performance of imaging procedures, concepts that were not supported in the original model. The entities required for representing the Worklist form a natural extension of the original DICOM Real-World model.
Common to both the original model and the extended model is the Patient entity. The Service Episode is an administrative concept that has been shown in the extended model in order to pave the way for future adaptation to a common model supported by other standardization groups including HL7, CEN TC 251 WG 3, CAP-IEC, etc. The Visit is in the original model but not shown in the extended model because it is a part of the Service Episode.
There is a 1 to 1 relationship between a Requested Procedure and the DICOM Study (A). A DICOM Study is the result of a single Requested Procedure. A Requested Procedure can result in only one Study.
A n:m relationship exists between a Scheduled Procedure Step and a Modality Performed Procedure Step (B). The concept of a Modality Performed Procedure Step is a superset of the Study Component concept contained in the original DICOM model. The Modality Performed Procedure Step SOP Classes provide a means to relate Modality Performed Procedure Steps to Scheduled Procedure Steps.
C Waveforms (Informative)
This Annex was formerly located in Annex J “Waveforms (Informative)” in PS3.3 in the 2003 and earlier revisions of the Standard.
C.1 Domain of Application
Waveform acquisition is part of both the medical imaging environment and the general clinical environment. Because of its broad use, there has been significant previous and complementary work in waveform standardization of which the following are particularly important:
-
ASTM E31.16 - E1467
-
Specification for Transferring Digital Neurophysiological Data Between Independent Computer Systems
-
CEN TC251 PT5-007 - prENV1064 draft
-
Standard Communications Protocol for Computer-Assisted Electrocardiography (SCP-ECG).
-
CEN TC251 PT5-021 - draft
-
Vital Signs Information Representation Standard (VITAL)
-
HL7 Automated Data SIG
-
HL7 Version 2.3, Chapter 7.14-20
-
IEEE P1073 - draft
-
Medical Information Bus Standard (MIB)
-
DICOM Section A.10 in PS3.3
-
Standalone Curve Information Object Definition
For DICOM, the domain of waveform standardization is waveform acquisition within the imaging context. It is specifically meant to address waveform acquisitions that will be analyzed with other data that is transferred and managed using the DICOM protocol. It allows the addition of waveform data to that context with minimal incremental cost. Further, it leverages the DICOM persistent object capability for maintaining referential relationships to other data collected in a multi-modality environment, including references necessary for multi-modality synchronization.
Waveform interchange in other clinical contexts may use different protocols more appropriate to those domains. In particular, HL7 may be used for transfer of waveform observations to general clinical information systems, and MIB may be used for real-time physiological monitoring and therapy.
The waveform information object definition in DICOM has been specifically harmonized at the semantic level with the HL7 waveform message format. The use of a common object model allows straightforward transcoding and interoperation between systems that use DICOM for waveform interchange and those that use HL7, and may be viewed as an example of common semantics implemented in the differing syntaxes of two messaging systems.
Note
HL7 allows transport of DICOM SOP Instances (information objects) encapsulated within HL7 messages. Since the DICOM and HL7 waveform semantics are harmonized, DICOM Waveform SOP Instances need not be transported as encapsulated data, as they can be transcoded to native HL7 Waveform Observation format.
The following are specific use case examples for waveforms in the imaging environment.
-
Case 1: Catheterization Laboratory - During a cardiac catheterization, several independent pieces of data acquisition equipment may be brought together for the exam. An electrocardiographic subsystem records surface ECG waveforms; an X-ray angiographic subsystem records motion images; a hemodynamic subsystem records intracardiac pressures from a sensor on the catheter. These subsystems send their acquired data by network to a repository. These data are assembled at an analytic workstation by retrieving from the repository. For a left ventriculographic procedure, the ECG is used by the physician to determine the time of maximum and minimum ventricular fill, and when coordinated with the angiographic images, an accurate estimate of the ejection fraction can be calculated. For a valvuloplasty procedure, the hemodynamic waveforms are used to calculate the pre-intervention and post-intervention pressure gradients.
-
Case 2: Electrophysiology Laboratory - An electrophysiological exam will capture waveforms from multiple sensors on a catheter; the placement of the catheter in the heart is captured on an angiographic image. At an analytic workstation, the exact location of the sensors can thus be aligned with a model of the heart, and the relative timing of the arrival of the electrophysiological waves at different cardiac locations can be mapped.
-
Case 3: Stress Exam - A stress exam may involve the acquisition of both ECG waveforms and echocardiographic ultrasound images from portable equipment at different stages of the test. The waveforms and the echocardiograms are output on an interchange disk, which is then input and read at a review station. The physician analyzes both types of data to make a diagnosis of cardiac health.
C.3 Time Synchronization Frame of Reference
Synchronization of acquisition across multiple modalities in a single study (e.g., angiography and electrocardiography) requires either a shared trigger, or a shared clock. A Synchronization Module within the Frame of Reference Information Entity specifies the synchronization mechanism. A common temporal environment used by multiple equipment is identified by a shared Synchronization Frame of Reference UID. How this UID is determined and distributed to the participating equipment is outside the scope of the Standard.
The method used for time synchronization of equipment clocks is implementation or site specific, and therefore outside the scope of this proposal. If required, standard time distribution protocols are available (e.g., NTP, IRIG, GPS).
An informative description of time distribution methods can be found at: http://web.archive.org/web/20001001065227/http://www.bancomm.com/cntpApp.htm
A second method of synchronizing acquisitions is to utilize a common reference channel (temporal fiducial), which is recorded in the data acquired from the several equipment units participating in a study, and/or that is used to trigger synchronized data acquisitions. For instance, the "X-ray on" pulse train that triggers the acquisition of frames for an X-ray angiographic SOP Instance can be recorded as a waveform channel in a simultaneously acquired hemodynamic waveform SOP Instance, and can be used to align the different object instances. Associated with this Supplement are proposed coded entry channel identifiers to specifically support this synchronization mechanism (DICOM Terminology Mapping Resource Context Group ID 3090).
C.4 Waveform Acquisition Model
Figure C.4-1 shows a canonical model of waveform data acquisition. A patient is the subject of the study. There may be several sensors placed at different locations on or in the patient, and waveforms are measurements of some physical quality (metric) by those sensors (e.g., electrical voltage, pressure, gas concentration, or sound). The sensor is typically connected to an amplifier and filter, and its output is sampled at constant time intervals and digitized. In most cases, several signal channels are acquired synchronously. The measured signal usually originates in the anatomy of the patient, but an important special case is a signal that originates in the equipment, either as a stimulus, such as a cardiac pacing signal, as a therapy, such as a radio frequency signal used for ablation, or as a synchronization signal.
C.5 Waveform Information Model
The part of the composite information object that carries the waveform data is the Waveform Information Entity (IE). The Waveform IE includes the technical parameters of waveform acquisition and the waveform samples.
The information model, or internal organizational structure, of the Waveform IE is shown in Figure C.5-1. A waveform information object includes data from a continuous time period during which signals were acquired. The object may contain several multiplex groups, each defined by digitization with the same clock whose frequency is defined for the group. Within each multiplex group there will be one or more channels, each with a full technical definition. Finally, each channel has its set of digital waveform samples.
C.6 Harmonization With HL7
This Waveform IE definition is harmonized with the HL7 waveform semantic constructs, including the channel definition Attributes and the use of multiplex groups for synchronously acquired channels. The use of a common object model allows straightforward transcoding and interoperation between systems that use DICOM for waveform interchange and those that use HL7, and may be viewed as an example of common semantics implemented in the differing syntaxes of two messaging systems.
This section describes the congruence between the DICOM Waveform IE and the HL7 version 2.3 waveform message format (see HL7 version 2.3 Chapter 7, sections 7.14 - 7.20).
C.6.1 HL7 Waveform Observation
Waveforms in HL7 messages are sent in a set of OBX (Observation) Segments. Four subtypes of OBX segments are defined:
-
The CHN subtype defines one channel in a CD (Channel Definition) Data Type
-
The TIM subtype defines the start time of the waveform data in a TS (Time String) Data Type
-
The WAV subtype carries the waveform data in an NA (Numeric Array) or MA (Multiplexed Array) Data Type (ASCII encoded samples, character delimited)
-
The ANO subtype carries an annotation in a CE (Coded Entry) Data Type with a reference to a specific time within the waveform to which the annotation applies
Other segments of the HL7 message definition specify patient and study identification, whose harmonization with DICOM constructs is not defined in this Annex.
The Waveform Module Channel Definition sequence Attribute (003A,0200) is defined in harmonization with the HL7 Channel Definition (CD) Data Type, in accordance with the following Table. Each Item in the Channel Definition sequence Attribute corresponds to an OBX Segment of subtype CHN.
Table C.6-1. Correspondence Between DICOM and HL7 Channel Definition
DICOM Attribute
|
DICOM Tag
|
HL7 CD Data Type Component
|
Waveform Channel Number
|
(003A,0202)
|
Channel Identifier (number&name)
|
Channel Label
|
(003A,0203)
|
Channel Source Sequence
|
(003A,0208)
|
Waveform Source
|
Channel Source Modifier Sequence
|
(003A,0209)
|
Channel Sensitivity
|
(003A,0210)
|
Channel Sensitivity and Units
|
Channel Sensitivity Units Sequence
|
(003A,0211)
|
Channel Sensitivity Correction Factor
|
(003A,0212)
|
Channel Calibration Parameters
(correctionfactor&baseline×kew)
|
Channel Baseline
|
(003A,0213)
|
Channel Time Skew
|
(003A,0214)
|
[Group] Sampling Frequency
|
(003A,001A)
|
Channel Sampling Frequency
|
Channel Minimum Value
|
(5400,0110)
|
Minimum and Maximum Data Values
(minimum & maximum)
|
Channel Maximum Value
|
(5400,0112)
|
Channel Offset
|
(003A,0218)
|
not defined in HL7
|
Channel Status
|
(003A,0205)
|
Filter Low Frequency
|
(003A,0220)
|
Filter High Frequency
|
(003A,0221)
|
Notch Filter Frequency
|
(003A,0222)
|
Notch Filter Bandwidth
|
(003A,0223)
|
In the DICOM information object definition, the sampling frequency is defined for the multiplex group, while in HL7 it is defined for each channel, but is required to be identical for all multiplexed channels.
Note that in the HL7 syntax, Waveform Source is a string, rather than a coded entry as used in DICOM. This should be considered in any transcoding between the two formats.
In HL7, the exact start time for waveform data is sent in an OBX Segment of subtype TIM. The corresponding DICOM Attributes, which must be combined to form the equivalent time string, are:
The DICOM binary encoding of data samples in the Waveform Data (5400,1010) corresponds to the ASCII representation of data samples in the HL7 OBX Segment of subtype WAV. The same channel-interleaved multiplexing used in the HL7 MA (Multiplexed Array) Data Type is used in the DICOM Waveform Data Attribute.
Because of its binary representation, DICOM uses several data elements to specify the precise encoding, as listed in the following Table. There are no corresponding HL7 data elements, since HL7 uses explicit character-delimited ASCII encoding of data samples.
In HL7, Waveform Annotation is sent in an OBX Segment of subtype ANO, using the CE (Coded Entry) Data Type CE. This corresponds precisely to the DICOM Annotation using Coded Entry Sequences. However, HL7 annotation ROI is to a single point only (time reference), while DICOM allows reference to ranges of samples delimited by time or by explicit sample position.
C.7 Harmonization With SCP-ECG
The SCP-ECG standard is designed for recording routine resting electrocardiograms. Such ECGs are reviewed prior to cardiac imaging procedures, and a typical use case would be for SCP-ECG waveforms to be translated to DICOM for inclusion with the full cardiac imaging patient record.
SCP-ECG provides for either simultaneous or non-simultaneous recording of the channels, but does not provide a multiplexed data format (each channel is separately encoded). When translating to DICOM, each subset of simultaneously recorded channels may be encoded in a Waveform Sequence Item (multiplex group), and the delay to the recording of each multiplex group shall be encoded in the Multiplex Group Time Offset (0018,1068).
The electrode configuration of SCP-ECG Section 1 may be translated to the DICOM Acquisition Context (0040,0555) sequence items using TID 3401 “ECG Acquisition Context” and Context Groups 3263 and 3264.
The lead identification of SCP-ECG Section 3, a term coded as an unsigned integer, may be translated to the DICOM Waveform Channel Source (003A,0208) coded sequence using CID 3001 “ECG Lead”.
Pacemaker spike records of SCP-ECG Section 7 may be translated to items in the Waveform Annotations Sequence (0040,B020) with a code term from CID 3335 “ECG Annotation”. The annotation sequence item may record the spike amplitude in its Numeric Value and Measurement Units Attributes.
D SR Encoding Example (Informative)
This Annex was formerly located in Annex K “SR Encoding Example (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
The following is a simple and non-comprehensive illustration of the encoding of the Informative SR Content Tree Example in PS3.3.
E Mammography CAD (Informative)
This Annex was formerly located in Annex L “Mammography CAD (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
E.1 Mammography CAD SR Content Tree Structure
The templates for the Mammography CAD SR IOD are defined in Mammography CAD SR IOD Templates in PS3.16
. Relationships defined in the Mammography CAD SR IOD templates are by-value, unless otherwise stated. Content Items referenced from another SR object instance, such as a prior Mammography CAD SR, are inserted by-value in the new SR object instance, with appropriate original source observation context. It is necessary to update Rendering Intent, and referenced Content Item identifiers for by-reference relationships, within Content Items paraphrased from another source.
The Document Root, Image Library, Summaries of Detections and Analyses, and CAD Processing and Findings Summary sub-trees together form the Content Tree of the Mammography CAD SR IOD. There are no constraints regarding the 1-n multiplicity of the Individual Impression/Recommendation or its underlying structure, other than the TID 4001 “Mammography CAD Overall Impression/Recommendation” and TID 4003 “Mammography CAD Individual Impression/Recommendation” requirements in PS3.16. Individual Impression/Recommendation containers may be organized, for example per image, per finding or composite feature, or some combination thereof.
The Summary of Detections and Summary of Analyses sub-trees identify the algorithms used and the work done by the CAD device, and whether or not each process was performed on one or more entire images or selected regions of images. The findings of the detections and analyses are not encoded in the summary sub-trees, but rather in the CAD Processing and Findings Summary sub-tree. CAD processing may produce no findings, in which case the sub-trees of the CAD Processing and Findings Summary sub-tree are incompletely populated. This occurs in the following situations:
-
All algorithms succeeded, but no findings resulted
-
Some algorithms succeeded, some failed, but no findings resulted
-
All algorithms failed
Note
-
If the tree contains no Individual Impression/Recommendation nodes and all attempted detections and analyses succeeded then the mammography CAD device made no findings.
-
Detections and Analyses that are not attempted are not listed in the Summary of Detections and Summary of Analyses trees.
-
If the code value of the Summary of Detections or Summary of Analyses codes in TID 4000 “Mammography CAD Document Root” is "Not Attempted" then no detail is provided as to which algorithms were not attempted.
The shaded area in Figure E.1-3 demarcates information resulting from Detection, whereas the unshaded area is information resulting from Analysis. This distinction is used in determining whether to place algorithm identification information in the Summary of Detections or Summary of Analyses sub-trees.
The clustering of calcifications within a single image is considered to be a Detection process that results in a Single Image Finding. The spatial correlation of a calcification cluster in two views, resulting in a Composite Feature, is considered Analysis. The clustering of calcifications in a single image is the only circumstance in which a Single Image Finding can result from the combination of other Single Image Findings, which must be Individual Calcifications.
Once a Single Image Finding or Composite Feature has been instantiated, it may be referenced by any number of Composite Features higher in the tree.
E.2 Mammography CAD SR Observation Context Encoding
-
Any Content Item in the Content Tree that has been inserted (i.e., duplicated) from another SR object instance has a HAS OBS CONTEXT relationship to one or more Content Items that describe the context of the SR object instance from which it originated. This mechanism may be used to combine reports (e.g., Mammography CAD 1, Mammography CAD 2, Human).
-
By-reference relationships within Single Image Findings and Composite Features paraphrased from prior Mammography CAD SR objects need to be updated to properly reference Image Library Entries carried from the prior object to their new positions in the present object.
The Impression/Recommendation section of the SR Document Content Tree of a Mammography CAD SR IOD may contain a mixture of current and prior single image findings and composite features. The Content Items from current and prior contexts are target Content Items that have a by-value INFERRED FROM relationship to a Composite Feature Content Item. Content Items that come from a context other than the Initial Observation Context have a HAS OBS CONTEXT relationship to target Content Items that describe the context of the source document.
In Figure E.2-1, Composite Feature and Single Image Finding are current, and Single Image Finding (from Prior) is duplicated from a prior document.
E.3 Mammography CAD SR Examples
The following is a simple and non-comprehensive illustration of an encoding of the Mammography CAD SR IOD for Mammography computer aided detection results. For brevity, some Mandatory Content Items are not included, such as several acquisition context Content Items for the images in the Image Library.
E.3.1 Example 1: Calcification and Mass Detection With No Findings
A mammography CAD device processes a typical screening mammography case, i.e., there are four films and no cancer. Mammography CAD runs both density and calcification detection successfully and finds nothing. The mammograms resemble:
The Content Tree structure would resemble:
E.3.2 Example 2: Calcification and Mass Detection With Findings
A mammography CAD device processes a screening mammography case with four films and a mass in the left breast. Mammography CAD runs both density and calcification detection successfully. It finds two densities in the LCC, one density in the LMLO, a cluster of two calcifications in the RCC and a cluster of 20 calcifications in the RMLO. It performs two clustering algorithms. One identifies individual calcifications and then clusters them, and the second simply detects calcification clusters. It performs mass correlation and combines one of the LCC densities and the LMLO density into a mass; the other LCC density is flagged Not for Presentation, therefore not intended for display to the end-user. The mammograms resemble:
The Content Tree structure in this example is complex. Structural illustrations of portions of the Content Tree are placed within the Content Tree table to show the relationships of data within the tree. Some Content Items are duplicated (and shown in boldface) to facilitate use of the diagrams.
E.3.3 Example 3: Calcification and Mass Detection, Temporal Differencing With Findings
The patient in Example 2 returns for another mammogram. A more comprehensive mammography CAD device processes the current mammogram; analyses are performed that determine some Content Items for Overall and Individual Impression/Recommendations. Portions of the prior mammography CAD report (Example 2) are incorporated into this report. In the current mammogram the number of calcifications in the RCC has increased, and the size of the mass in the left breast has increased from 1 to 4 cm2.
Italicized entries (xxx) in the following table denote references to or by-value inclusion of Content Tree items reused from the prior Mammography CAD SR instance (Example 2).
While the Image Library contains references to Content Tree items reused from the prior Mammography CAD SR instance, the images are actually used in the mammography CAD analysis and are therefore not italicized as indicated above.
Current year content:
Included content from prior mammography CAD report (see Example 2, starting with node 1.2.1.2)
More current year content:
Included content from prior mammography CAD report (see Example 2, starting with node 1.2.4.2)
More current year content:
Computer-aided detection algorithms often compute an internal "CAD score" for each Single Image Finding detected by the algorithm. In some implementations the algorithms then group the findings into "bins" as a function of their CAD score. The number of bins is a function of the algorithm and the manufacturer's implementation, and must be one or more. The bins allow an application that is displaying CAD marks to provide a number of operating points on the Free-response Receiver-Operating Characteristic (FROC) curve for the algorithm, as illustrated in Figure E.4-1.
This is accomplished by displaying all CAD marks of Rendering Intent "Presentation Required" or "Presentation Optional" according to the following rules:
-
if the display application's Operating Point is 0, only marks with a Rendering Intent = "Presentation Required" are displayed
-
if the display application's Operating Point is 1, then marks with a Rendering Intent = "Presentation Required" and marks with a Rendering Intent = "Presentation Optional" with a CAD Operating Point = 1 are displayed
-
if the display application's Operating Point is n, then marks with a Rendering Intent = "Presentation Required" and marks with a Rendering Intent = "Presentation Optional" with a CAD Operating Point <= n are displayed
E.5 Mammography CAD SR and For Processing / For Presentation Images
If a Mammography CAD SR Instance references Digital Mammography X-ray Image Storage - For Processing Instances, but a review workstation has access only to Digital Mammography X-Ray Image Storage - For Presentation Instances, the following steps are recommended in order to display such Mammography CAD SR content with Digital Mammography X-Ray Image - For Presentation Instances.
-
In most scenarios, the Mammography CAD SR Instance is assigned to the same DICOM Patient and Study as the corresponding Digital Mammography "For Processing" and "For Presentation" image Instances.
-
If a workstation has a Mammography CAD SR Instance, but does not have images for the same DICOM Patient and Study, the workstation may use the Patient and Study Attributes of the Mammography CAD SR Instance in order to Query/Retrieve the Digital Mammography "For Presentation" images for that Patient and Study.
-
Once a workstation has the Mammography CAD SR Instance and Digital Mammography "For Presentation" image Instances for the Patient and Study, the Source Image Sequence (0008,2112) Attribute of each Digital Mammography "For Presentation" Instance will reference the corresponding Digital Mammography "For Processing" Instance. The workstation can match the referenced Digital Mammography "For Processing" Instance to a Digital Mammography "For Processing" Instance referenced in the Mammography CAD SR.
-
The workstation should check for Spatial Locations Preserved (0028,135A) in the Source Image Sequence of each Digital Mammography "For Presentation" image Instance, to determine whether it is spatially equivalent to the corresponding Digital Mammography "For Processing" image Instance.
-
If the value of Spatial Locations Preserved (0028,135A) is YES, then the CAD results should be displayed.
-
If the value of Spatial Locations Preserved (0028,135A) is NO, then the CAD results should not be displayed.
-
If Spatial Locations Preserved (0028,135A) is not present, whether or not the images are spatially equivalent is not known. If the workstation chooses to proceed with attempting to display CAD results, then compare the Image Library (see TID 4020 “CAD Image Library Entry”) Content Item values of the Mammography CAD SR Instance to the associated Attribute values in the corresponding Digital Mammography "For Presentation" image Instance. The Content Items (111044, DCM, "Patient Orientation Row"), (111043, DCM, "Patient Orientation Column"), (111026, DCM, "Horizontal Pixel Spacing"), and (111066, DCM, "Vertical Pixel Spacing")
may be used for this purpose. If the values do not match, the workstation needs to adjust the coordinates of the findings in the Mammography CAD SR content to match the spatial characteristics of the Digital Mammography "For Presentation" image Instance.
F Chest CAD (Informative)
This Annex was formerly located in Annex M “Chest CAD (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
F.1 Chest CAD SR Content Tree Structure
The templates for the Chest CAD SR IOD are defined in Annex A “Structured Reporting Templates (Normative)” in PS3.16. Relationships defined in the Chest CAD SR IOD templates are by-value, unless otherwise stated. Content Items referenced from another SR object instance, such as a prior Chest CAD SR, are inserted by-value in the new SR object instance, with appropriate original source observation context. It is necessary to update Rendering Intent, and referenced Content Item identifiers for by-reference relationships, within Content Items paraphrased from another source.
The Document Root, Image Library, CAD Processing and Findings Summary, and Summaries of Detections and Analyses sub-trees together form the Content Tree of the Chest CAD SR IOD. See Annex E for additional explanation of the Summaries of Detections and Analyses sub-trees.
The shaded area in Figure F.1-2 demarcates information resulting from Detection, whereas the unshaded area is information resulting from Analysis. This distinction is used in determining whether to place algorithm identification information in the Summary of Detections or Summary of Analyses sub-trees.
The identification of a lung nodule within a single image is considered to be a Detection, which results in a Single Image Finding. The temporal correlation of a lung nodule in two instances of the same view taken at different times, resulting in a Composite Feature, is considered Analysis.
Once a Single Image Finding or Composite Feature has been instantiated, it may be referenced by any number of Composite Features higher in the CAD Processing and Findings Summary sub-tree.
F.2 Chest CAD SR Observation Context Encoding
-
Any Content Item in the Content Tree that has been inserted (i.e., duplicated) from another SR object instance has a HAS OBS CONTEXT relationship to one or more Content Items that describe the context of the SR object instance from which it originated. This mechanism may be used to combine reports (e.g., Chest CAD SR 1, Chest CAD SR 2, Human).
-
By-reference relationships within Single Image Findings and Composite Features paraphrased from prior Chest CAD SR objects need to be updated to properly reference Image Library Entries carried from the prior object to their new positions in the present object.
The CAD Processing and Findings Summary section of the SR Document Content Tree of a Chest CAD SR IOD may contain a mixture of current and prior single image findings and composite features. The Content Items from current and prior contexts are target Content Items that have a by-value INFERRED FROM relationship to a Composite Feature Content Item. Content Items that come from a context other than the Initial Observation Context have a HAS OBS CONTEXT relationship to target Content Items that describe the context of the source document.
In Figure F.2-1, Composite Feature and Single Image Finding are current, and Single Image Finding (from Prior) is duplicated from a prior document.
F.3 Chest CAD SR Examples
The following is a simple and non-comprehensive illustration of an encoding of the Chest CAD SR IOD for chest computer aided detection results. For brevity, some mandatory Content Items are not included, such as several acquisition context Content Items for the images in the Image Library.
F.3.1 Example 1: Lung Nodule Detection With No Findings
A chest CAD device processes a typical screening chest case, i.e., there is one image and no nodule findings. Chest CAD runs lung nodule detection successfully and finds nothing.
The chest radiograph resembles:
The Content Tree structure would resemble:
F.3.2 Example 2: Lung Nodule Detection With Findings and Anatomy/pathology Interpretation
A chest CAD device processes a screening chest case with one image, and a lung nodule detected. The chest radiograph resembles:
The Content Tree structure in this example is complex. Structural illustrations of portions of the Content Tree are placed within the Content Tree table to show the relationships of data within the tree. Some Content Items are duplicated (and shown in boldface) to facilitate use of the diagrams.
The Content Tree structure would resemble:
F.3.3 Example 3: Lung Nodule Detection, Temporal Differencing With Findings
The patient in Example 2 returns for another chest radiograph. A more comprehensive chest CAD device processes the current chest radiograph, and analyses are performed that determine some temporally related Content Items for Composite Features. Portions of the prior chest CAD report (Example 2) are incorporated into this report. In the current chest radiograph the lung nodule has increased in size.
Italicized entries (xxx) in the following table denote references to or by-value inclusion of Content Tree items reused from the prior Chest CAD SR instance (Example 2).
While the Image Library contains references to Content Tree items reused from the prior Chest CAD SR instance, the images are actually used in the chest CAD analysis and are therefore not italicized as indicated above.
The CAD processing and findings consist of one composite feature, comprised of single image findings, one from each year. The temporal relationship allows a quantitative temporal difference to be calculated:
F.3.4 Example 4: Lung Nodule Detection in Chest Radiograph, Spatially Correlated With CT
The patient in Example 3 is called back for CT to confirm the Lung Nodule found in Example 3. The patient undergoes CT of the Thorax and the initial chest radiograph and CT slices are sent to a more comprehensive CAD device for processing. Findings are detected and analyses are performed that correlate findings from the two collections of data. Portions of the prior CAD report (Example 3) are incorporated into this report.
Italicized entries (xxx) in the following table denote references to or by-value inclusion of Content Tree items reused from the prior Chest CAD SR instance (Example 3).
While the Image Library contains references to Content Tree items reused from the prior Chest CAD SR instance, the images are actually used in the CAD analysis and are therefore not italicized as indicated above.
Most recent examination content:
G Explanation of Grouping Criteria For Multi-frame Functional Group IODs (Informative)
This Annex was formerly located in Annex N “Explanation of Grouping Criteria for Multi-frame Functional Group IODs (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
When considering how to group an Attribute, one needs to consider first of all whether or not the values of an Attribute are different per frame. The reasons to consider whether to allow an Attribute to change include:
-
The more Attributes that change, the more parsing a receiving application has to do in order to determine if the multi-frame object has frames the application should deal with. The more choices, the more complex the application becomes, potentially resulting in interoperability problems.
-
The frequency of change of an Attribute must also be considered. If an Attribute could be changed every frame then obviously it is not a very good candidate for making it fixed, since this would result in a multi-frame size of 1.
-
The number of applications that depend on frame level Attribute grouping is another consideration. For example, one might imagine a pulse sequence being changed in a real-time acquisition, but the vast majority of acquisitions would leave this constant. Therefore, it was judged not too large a burden to force an acquisition device to start a new object when this happens. Obviously, this is a somewhat subjective decision, and one should take a close look at the Attributes that are required to be fixed in this document.
-
The Attributes from the image pixel module must not change in a multi-frame object due to legacy tool kits and implementations.
-
The potential frequency of change is dependent on the applications both now and likely during the life of this Standard. The penalty for failure to allow an Attribute to change is rather high since it will be hard/impossible to change later. Making an Attribute variable that is static is more complex and could result in more header space usage depending on how it is grouped. Thus there is a trade-off of complexity and potentially header size with not being able to take advantage of the multi-frame organization for an application that requires changes per frame.
Once it is decided which Attributes should be changed within a multi-frame object then one needs to consider the criteria for grouping Attributes together:
-
Groupings should be designed so those Attributes that are likely to vary together should be in the same sequence. The goal is to avoid the case where Attributes that are mostly static have to be included in a sequence that is repeated for every frame.
-
Care should be taken so that we define a manageable number of grouping sequences. Too few sequences could result in many static Attributes being repeated for each frame, when some other element in their sequence was varying, and too many sequences becomes unwieldy.
-
The groupings should be designed such that modality independent Attributes are kept separate from those that are MR specific. This will presumably allow future working groups to reuse the more general groupings. It also should allow software that operates on multi-frame objects from multiple objects maximize code reuse.
-
Grouping related Attributes together could convey some semantics of the overall contents of the multi-frame object to receiving applications. For instance, if a volumetric application finds the Plane Orientation Macro present in the Per-Frame Functional Groups Sequence, it may decide to reject the object as inappropriate for volumetric calculations.
Specific notes on Attribute grouping:
-
Attributes not allowed to change: Image Pixel Module (due to legacy toolkit concerns); and Pulse Sequence Module Attributes (normally do not change except in real-time - it is expected real time applications can handle the complexity and speed of starting new IODs when pulse sequence changes).
-
Sequences not starting with the word "MR" could be applied to more modalities than just MR.
-
All Attributes that must be in a frame header were placed in the Frame Content Macro.
-
Position and orientation are in separate sequences since they are changed independently.
-
For real-time sequences there are contrast mechanisms that can be applied to base pulse sequences and are turned on and off by the operator depending on the anatomy being imaged and the time/contrast trade-off associated with these. Such modifiers include: IR, flow compensation, spoiled, MT, and T2 preparation… These probably are not changed in non-real-time scans. These are all kept in the MR Modifier Macro.
"Number of Averages" Attributes is in its own sequence because real-time applications may start a new averaging process every time a slice position/orientation changes. Each subsequent frame will average with the preceding N frames where N is chosen based on motion and time. Each frame collected at a particular position/orientation will have a different number of averages, but all other Attributes are likely to remain the same. This particular application drives this Attribute being in its own group.
H Clinical Trial Identification Workflow Examples (Informative)
This Annex was formerly located in Annex O “Clinical Trial Identification Workflow Examples (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
The Clinical Trial Identification modules are optional. As such, there are several points in the workflow of clinical trial or research data at which the Clinical Trial Identification Attributes may be added to the data. At the Clinical Trial Site, the Attributes may be added at the scanner, a PACS system, a site workstation, or a workstation provided to the site by a Clinical Trial Coordinating Center. If not added at the site, the Clinical Trial Identification Attributes may be added to the data after receipt by the Clinical Trial Coordinating Center. The addition of clinical trial Attributes does not itself require changes to the SOP Instance UID. However, the clinical trial or research protocol or the process of de-identification may require such a change.
Images are obtained for the purpose of comparing patients treated with placebo or the drug under test, then evaluated in a blinded manner by a team of radiologists at the Clinical Trial Coordinating Center (CTCC). The images are obtained at the clinical sites, collected by the CTCC, at which time their identifying Attributes are removed and the Clinical Trial Identification (CTI) module is added. The de-identified images with the CTI information are then presented to the radiologists who make quantitative and/or qualitative assessments. The assessments, and in some cases the images, are returned to the sponsor for analysis, and later are contributed to the submission to the regulating authority.
I Ultrasound Templates (Informative)
I.1 SR Content Tree Structure
The templates for ultrasound reports are defined in Annex A “Structured Reporting Templates (Normative)” in PS3.16. Figure I.1-1 is an outline of the common elements of ultrasound structured reports.
The Patient Characteristics Section is for medical data of immediate relevance to administering the procedure and interpreting the results. This information may originate outside the procedure.
The Procedure Summary Section contains exam observations of immediate or primary significance. This is key information a physician typically expects to see first in the report.
Measurements typically reside in a measurement group container within a Section. Measurement groups share context such as anatomical location, protocol or type of analysis. The grouping may be specific to a product implementation or even to a user configuration. OB-GYN measurement groups have related measurements, averages and other derived results.
If present, the Image Library contains a list of images from which observations were derived. These are referenced from the observations with by-reference relationships.
The Procedure Summary Section contains the observations of most immediate interest. Observations in the procedure summary may have by-reference relationships to other Content Items.
I.4 Explicitly Specifying Calculation Dependencies
Reports may specify dependencies of a calculation on its dependent observations using by-reference relationships. This relationship must be present for the report reader to know the inputs of the derived value.
I.5 Linking Measurements to Images, Coordinates
Optionally, the relationship of an observation to its image and image coordinates can be encoded with by-reference Content Items as Figure I.5-1 shows. For conciseness, the by-reference relationship points to the Content Item in the Image Library, rather than directly to the image.
R-INFERRED FROM relationships to IMAGE Content Items specify that the image supports the observation. A purpose of reference in an SCOORD Content Item may specify an analytic operation (performed on that image) that supports or produces the observation.
A common OB-GYN pattern is that of several instances of one measurement type (e.g., BPD), the calculated average of those values, and derived values such as a gestational age calculated according to an equation or table. The measurements and calculations are all siblings in the measurement group. A child Content Item specifies the equation or table used to calculate the gestational age. All measurement types must relate to the same biometric type. For example, it is not allowed to mix a BPD and a Nuchal Fold Thickness measurement in the same biometry group.
The example above is a gestational age calculated from the measured value. The relationship is to an equation or table. The inferred from relationship identifies equation or table in the Concept Name. Codes from CID 12013 “Gestational Age Equation/Table” identify the specific equation or table.
Another use case is the calculation of a growth parameter's relationship to that of a referenced distribution and a known or assumed gestational age. CID 12015 “Fetal Growth Equation/Table” identify the growth table. Figure I.6-2 shows the assignment of a percentile for the measured BPD, against the growth of a referenced population. The dependency relationship to the gestational age is a by-reference relationship to the established gestational age. Though the percentile rank is derived from the BPD measurement, a by-reference relationship is not essential if one BPD has a concept modifier indicating that it is the mean or has selection status (see TID 300 “Measurement”). A variation of this pattern is the use of Z-score instead of percentile
rank. Not shown is the expression of the normal distribution mean, standard deviation, or confidence limits.
Estimated fetal weight (EFW) is a fetus summary item as shown below. It is calculated from one or more growth parameters (the inferred from relationships are not shown). TID 315 “Equation or Table” allows specifying how the value was derived. Terms from CID 12014 “OB Fetal Body Weight Equation/Table” specify the table or equation that yields the EFW from growth parameters.
"EFW percentile rank" is another summary term. By definition, this term depends upon the EFW and the population distribution of the ranking. A Reference Authority Content Item identifies the distribution. CID 12016 “Estimated Fetal Weight Percentile Equation/Table” is list of established reference authorities.
When multiple observations of the same type exist, one of these may be the selected value. Typically, this value is the average of the others, or it may be the last entered, or user chosen. TID 310 “Measurement Properties” provides a Content Item with concept name of (121404, DCM, "Selection Status") and a value set specified by DCID 224 “Selection Method”.
There are multiple ways that a measurement may originate. The measurement value may result as an output of an image interactive, system tool. Alternatively, the user may directly enter the value, or the system may create a value automatically as the mean of multiple measurement instances. TID 300 “Measurement” provides that a concept modifier of the numeric Content Item specify the derivation of the measurement. The concept name of the modifier is (121401, DCM, "Derivation"). CID 3627 “Measurement Type” provides concepts of appropriate measurement modifiers. Figure I.7-2 illustrates such a case.
The following are simple, non-comprehensive illustrations of report sections.
I.8.1 Example 1: OB-GYN Root with Observation Context
The following example shows the highest level of Content Items for a second or third trimester OB exam. Subsequent examples show details of section content,
The following example shows the highest level of Content Items for a GYN exam. Subsequent examples show details of section content.
I.8.2 Example 2: OB-GYN Patient Characteristics and Procedure Summary
I.8.3 Example 3: OB-GYN Multiple Fetus
I.8.4 Example 4: Biophysical Profile
I.8.5 Example 5: Biometry Ratios
Optionally, but not shown, the ratios may have by-reference, inferred-from relationships to the Content Items holding the numerator and denominator values.
I.8.6 Example 6: Biometry
This example shows measurements and estimated gestational age.
This example shows measurements and with percentile ranking.
I.8.7 Example 7: Amniotic Sac
I.8.8 Example 8: OB-GYN Ovaries
The content structure in the example below conforms to TID 5012 “Ovaries Section”. The example shows the volume derived from three perpendicular diameters.
I.8.9 Example 9: OB-GYN Follicles
The content structure in the example below conforms to TID 5013 “Follicles Section”. It uses multiple measurements and derived averages for each of the perpendicular diameters.
I.8.10 Example 10: Pelvis and Uterus
J Handling of Identifying Parameters (Informative)
This Annex was formerly located in Annex M “Handling of Identifying Parameters (Informative)” in PS3.4 in the 2003 and earlier revisions of the Standard.
J.1 Purpose of This Annex
The DICOM Standard was published in 1993 and addresses medical images communication between medical modalities, workstations and other medical devices as well as data exchange between medical devices and the Information System (IS). DICOM defines SOP Instances with Patient, Visit and Study information managed by the Information System and allows to communicate the Attribute values of these objects.
Since the publication of the DICOM Standard great effort has been made to harmonize the Information Model of the DICOM Standard with the models of other relevant standards, especially with the HL7 model and the CEN TC 251 WG3 PT 022 model. The result of these effort is a better understanding of the various practical situations in hospitals and an adaptation of the model to these situations. In the discussion of models, the definition of Information Entities and their Identifying Parameters play a very important role.
The purpose of this Informative Annex is to show which identifying parameters may be included in Image SOP Instances and their related Modality Performed Procedure Step (MPPS) SOP Instance. Different scenarios are elucidated to describe varying levels of integration of the Modality with the Information System, as well as situations in which a connection is temporarily unavailable.
Note
In this Annex, "Image SOP Instance" is used as a collective term for all Composite Image Storage SOP Instances.
The scenarios described here are informative and do not constitute a normative section of the DICOM Standard.
J.2 Integrated Environment
"Integrated" means in this context that the Acquisition Modality is connected to an Information System or Systems that may be an SCP of the Modality Worklist SOP Class or an SCP of the Modality Performed Procedure Step SOP Class or both. In the following description only the behavior of "Modalities" is mentioned, it goes without saying that the IS must conform to the same SOP Classes.
The Modality receives identifying parameters by querying the Modality Worklist SCP and generates other Attribute values during image generation. It is desirable that these identifying parameters be included in the Image SOP Instances as well as in the MPPS object in a consistent manner. In the case of a Modality that is integrated but unable to receive or send identifying parameters, e.g., link down, emergency case, the Modality may behave as if it were not integrated.
The Study Instance UID is a crucial Attribute that is used to relate Image SOP Instances (whose Study is identified by their Study Instance UID), the Modality PPS SOP Instance that contains it as a reference, and the actual or conceptual Requested Procedure (i.e., Study) and related Imaging Service Request in the IS. An IS that manages an actual or conceptual Detached Study Management entity is expected to be able to relate this Study Instance UID to the SOP Instance UID of the Detached Study Management SOP Instance, whether or not the Study Instance UID is provided by the IS or generated by the modality.
For a detailed description of an integrated environment see the IHE Radiology Technical Framework. This document can be obtained at http://www.ihe.net/
J.2.1 Modality Conforms to Modality Worklist and MPPS SOP Classes
The modality may:
-
N-CREATE a MPPS SOP Instance and include its SOP Instance UID in the Image SOP Instances within the Referenced Performed Procedure Step Sequence Attribute.
-
Copy the following Attribute values from the Modality Worklist information into the Image SOP Instances and into the related MPPS SOP Instance:
-
Study Instance UID
-
Referenced Study Sequence
-
Accession Number
-
Requested Procedure ID
-
Scheduled Procedure Step ID
-
Scheduled Procedure Step Description
-
Scheduled Protocol Code Sequence
-
Create the following Attribute value and include it into the Image SOP Instances and the related MPPS SOP Instance:
-
Include the following Attribute values that may be generated during image acquisition, if supported, into the Image SOP Instances and the related MPPS SOP Instance:
-
Performed Procedure Step Start Date
-
Performed Procedure Step Start Time
-
Performed Procedure Step Description
-
Study ID
J.2.2 Modality Conforms Only to The Modality Worklist SOP Class
The modality may:
-
In the absence of the ability to N-CREATE a MPPS SOP Instance, generate a MPPS SOP Instance UID and include it into the Referenced Performed Procedure Step Sequence Attribute of the Image SOP Instances. A system that later N-CREATEs a MPPS SOP Instance may use this UID extracted from the related Image SOP Instances.
-
Copy the following Attribute values from the Modality Worklist information into the Image SOP Instances:
-
Study Instance UID
-
Referenced Study Sequence
-
Accession Number
-
Requested Procedure ID
-
Scheduled Procedure Step ID
-
Scheduled Procedure Step Description
-
Scheduled Protocol Code Sequence
-
Create the following Attribute value and include it into the Image SOP Instances:
A system that later N-CREATEs a MPPS SOP Instance may use this Attribute value extracted from the related Image SOP Instances.
A system that later N-CREATEs a MPPS SOP Instance may use these Attribute values extracted from the related Image SOP Instances.
J.2.3 Modality Conforms Only to The MPPS SOP Class
The modality may:
-
N-CREATE a MPPS SOP Instance and include its SOP Instance UID in the Image SOP Instances within the Referenced Performed Procedure Step Sequence Attribute.
-
Create the following Attribute values and include them in the Image SOP Instances and the related MPPS SOP Instance:
-
Copy the following Attribute values, if available to the Modality, into the Image SOP Instances and into the related MPPS SOP Instance:
-
Accession Number
-
Patient ID
-
Patient's Name
-
Patient's Birth Date
-
Patient's Sex
If sufficient identifying information is included, it will allow the Image SOP Instances and the MPPS SOP Instance to be later related to the Requested Procedure and the actual or conceptual Detached Study Management entity.
J.3 Non-integrated Environment
"Non-Integrated" means in this context that the Acquisition Modality is not connected to an Information System Systems, does not receive Attribute values from an SCP of the Modality Worklist SOP Class, and cannot create a Performed Procedure Step SOP Instance.
The modality may:
-
In the absence of the ability to N-CREATE a MPPS SOP Instance, generate a MPPS SOP Instance UID and include it into the Referenced Performed Procedure Step Sequence Attribute of the Image SOP Instances. A system that later N-CREATEs a MPPS SOP Instance may use this UID extracted from the related Image SOP Instances.
-
Create the following Attribute values and include them in the Image SOP Instances:
A system that later N-CREATEs a MPPS SOP Instance may use these Attribute values extracted from the related Image SOP Instances.
If sufficient identifying information is be included, it will allow the Image SOP Instances to be later related to the Requested Procedure and the actual or conceptual Detached Study Management entity.
A system that later N-CREATEs a MPPS SOP Instance may use these Attribute values extracted from the related Image SOP Instances.
J.4 One MPPS Is Created in Response to Two Or More Requested Procedures
In the MPPS SOP Instance, all the specific Attributes of a Scheduled Procedure Step or Steps are included in the Scheduled Step Attributes Sequence. In the Image SOP Instances, these Attributes may be included in the Request Attributes Sequence. This is an optional Sequence in order not to change the definition of existing SOP Classes by adding new required Attributes or changing the meaning of existing Attributes.
Both Sequences may have more than one Item if more than one Requested Procedure results in a single Performed Procedure Step.
Because of the definitions of existing Attributes in existing Image SOP Classes, the following solutions are a compromise. The first one chooses or creates a value for the single valued Attributes Study Instance UID and Accession Number. The second one completely replicates the Image data with different values for the Attributes Study Instance UID and Accession Number.
J.4.1 Choose Or Create A Value For Study Instance UID and Accession Number
The modality may:
-
In the Image SOP Instances:
-
create a Request Attributes Sequence containing two or more Items each containing the following Attributes:
-
Requested Procedure ID
-
Scheduled Procedure Step ID
-
Scheduled Procedure Step Description
-
Scheduled Protocol Code Sequence
-
create a Referenced Study Sequence containing two or more Items sufficient to contain the Study SOP Instance UID values from the Modality Worklist for both Requested Procedures
-
select one value from the Modality Worklist or generate a new value for:
-
select one value from the Modality Worklist or generate a new value or assign an empty value for:
-
In the MPPS SOP Instance:
-
create a Scheduled Step Attributes Sequence containing two or more Items each containing the following Attributes:
-
Study Instance UID
-
Referenced Study Sequence
-
Accession Number
-
Requested Procedure ID
-
Scheduled Procedure Step ID
-
Scheduled Procedure Step Description
-
Scheduled Protocol Code Sequence
-
include the following Attribute value that may be generated during image acquisition, if supported:
-
In both the Image SOP Instances and the MPPS SOP Instance
-
create a Performed Procedure Step ID
-
include the following Attribute values that may be generated during image acquisition, if supported:
-
Performed Procedure Step Start Date
-
Performed Procedure Step Start Time
-
Performed Procedure Step Description
-
Study ID
J.4.2 Replicate The Image IOD
An alternative method is to replicate the entire Image SOP Instance with a new SOP Instance UID, and assign each Image IOD it's own identifying Attributes. In this case, each of the Study Instance UID and the Accession Number values can be used in their own Image SOP Instance.
Both Image SOP Instances may reference a single MPPS SOP Instance (via the MPPS SOP Instance UID in the Referenced Performed Procedure Step Sequence).
Each individual Image SOP Instance may reference it's own related Study SOP Instance, if it exists (via the Referenced Study Sequence). This Study SOP Instance has a one to one relationship with the corresponding Requested Procedure.
If an MPPS SOP Instance is created, it may reference both related Study SOP Instances.
The modality may:
-
For all Series in the MPPS, replicate the entire Series of Images using new Series Instance UIDs
-
Create replicated Image SOP Instances with different SOP Instance UIDs that use the new Series Instance UIDs, for each of the two or more Requested Procedures
-
In each of the Image SOP Instances, using values from the corresponding Requested Procedure:
-
create a Request Attributes Sequence containing an Item containing the following Attributes:
-
Requested Procedure ID
-
Scheduled Procedure Step ID
-
Scheduled Procedure Step Description
-
Scheduled Protocol Code Sequence
-
copy from the Modality Worklist:
-
Study Instance UID
-
Accession Number
-
create a Referenced Study Sequence containing an Item containing the following Attribute:
-
In the MPPS SOP Instance (if supported):
-
create a Scheduled Step Attributes Sequence containing two or more Items each containing the following Attributes:
-
Study Instance UID
-
Referenced Study Sequence
-
Accession Number
-
Requested Procedure ID
-
Scheduled Procedure Step ID
-
Scheduled Procedure Step Description
-
Scheduled Protocol Code Sequence
-
include the following Attribute value that may be generated during image acquisition, if supported:
-
In both the Image SOP Instances and the MPPS SOP Instance (if supported):
J.5 MPPS SOP Instance Created by Another System (not the Modality)
If for some reason the Modality was unable to create the MPPS SOP Instance, another system may wish to perform this service. This system must make sure that the created PPS SOP Instance is consistent with the related Image SOP Instances.
Depending on the availability and correctness of values for the Attributes in the Image SOP Instances, these values may be copied into the MPPS SOP Instance, or they may have to be coerced, e.g., if they are not consistent with corresponding values available from the IS.
For example, if the MPPS SOP Instance UID is already available in the Image SOP Instance (in the Referenced Performed Procedure Step Sequence), it may be utilized to N-CREATE the MPPS SOP Instance. If not available, a new MPPS SOP Instance UID may be generated and used to N-CREATE the MPPS SOP Instance. In this case there may be no MPPS SOP Instance UID in the Referenced Performed Procedure Step Sequence in the corresponding Image SOP Instances. An update of the Image SOP Instances will restore the consistency, but this is not required.
J.6 Mapping of Study Instance UIDs to the Study SOP Instance UID
Retired. See PS3.17-2004.
K Ultrasound Staged Protocol Data Management (Informative)
K.1 Purpose of this Annex
The purpose of this annex is to enhance consistency and interoperability among creators and consumers of Ultrasound images within Staged Protocol Exams. An ultrasound "Staged Protocol Exam" is an exam that acquires a set of images under specified conditions during time intervals called "Stages". An example of such an exam is a cardiac stress-echo Staged Protocol.
This informative annex describes the use of ultrasound Staged Protocol Attributes within the following DICOM Services: Ultrasound Image, Ultrasound Multi-frame Image, and Key Object Selection Document Storage, Modality Worklist, and Modality Performed Procedure Step Services.
K.2 Prerequisites For Support
The support of ultrasound Staged Protocol Data Management requires support for the Ultrasound Image SOP Class or Ultrasound Multi-frame Image SOP Class as appropriate for the nature of the Protocol. By supporting some optional Elements of these SOP Classes, Staged-Protocols can be managed. Support of Key Object Selection allows control of the order of View and Stage presentation. Support of Modality Worklist Management and Modality Performed Procedure Step allow control over specific workflow use cases as described in this Annex.
K.3 Definition of a Staged Protocol Exam
A "Staged Protocol Exam" acquires images in two or more distinct time intervals called "Stages" with a consistent set of images called "Views" acquired during each Stage of the exam. A View is of a particular cross section of the anatomy acquired with a specific ultrasound transducer position and orientation. During the acquisition of a Staged Protocol Exam, the modality may also acquire non-Protocol images at one or more Protocol Stages.
A common real-world example of an ultrasound Staged Protocol exam is a cardiac stress-echo ultrasound exam. Images are acquired in distinct time intervals (Stages) of different levels of stress and Views as shown in Figure K.3-1. Typically, stress is induced by means of patient exercise or medication. Typical Stages for such an exam are baseline, mid-stress, peak-stress, and recovery. During the baseline Stage the patient is at rest, prior to inducing stress through medication or exercise. At mid-stress Stage the heart is under a moderate level of stress. During peak-stress Stage the patient's heart experiences maximum stress appropriate for the patient's condition. Finally, during the recovery Stage, the heart recovers because the source of stress is absent.
At each Stage an equivalent set of Views is acquired. Examples of typical Views are parasternal long axis and parasternal short axis. Examination of wall motion between the corresponding Views of different Stages may reveal ischemia of one or more regions ("segments") of the myocardium. Figure K.3-1 illustrates the typical results of a cardiac stress-echo ultrasound exam.
K.4 Attributes Used in Staged Protocol Exams
The DICOM Standard includes a number of Attributes of significance to Staged Protocol Exams. This Annex explains how scheduling and acquisition systems may use these Attributes to convey Staged Protocol related information.
Table K.4-1 lists all the Attributes relevant to convey Staged Protocol related information (see PS3.3 for details about these Attributes).
Table K.4-1. Attributes That Convey Staged Protocol Related Information
Modality Worklist
(Tag) [Return Key Type]
|
US Image and US Multi-frame IOD
(TAG) [Type]
|
MPPS IOD
(Tag) [SCU/SCP Type]
|
----
|
----
|
Scheduled Step Attributes Sequence (0040,0270) [1/1] (b)
|
Study Instance UID (0020,000D) [1]
|
Study Instance UID (0020,000D) [1]
|
>Study Instance UID (0020,000D) [1/1]
|
Scheduled Procedure Step Sequence (0040,0100)
|
Request Attributes Sequence (0040,0275) [3] (a,b)
|
----
|
>Scheduled Procedure Step Description (0040,0007) [1C]
|
>Scheduled Procedure Step Description (0040,0007) [3]
|
>Scheduled Procedure Step Description (0040,0007) [2/2]
|
>Scheduled Protocol Code Sequence (0040,0008) [1C]
|
>Scheduled Protocol Code Sequence (0040,0008) [3]
|
>Scheduled Protocol Code Sequence (0040,0008) [2/2]
|
----
|
Performed Procedure Step Description (0040,0254) [3]
|
Performed Procedure Step Description (0040,0254) [2/2]
|
----
|
Protocol Name (0018,1030) [3]
|
Performed Series Sequence (0040,0340)>Protocol Name (0018,1030) [1/1]
|
----
|
Performed Protocol Code Sequence (0040,0260) [3]
|
Performed Protocol Code Sequence (0040,0260) [1/1]
|
----
|
Number of Stages (0008,2124) [2C]
|
----
|
----
|
Number of Views In Stage (0008,212A) [2C]
|
----
|
----
|
Stage Name (0008,2120) [3]
|
----
|
----
|
Stage Number (0008,2122) [3]
|
----
|
----
|
Stage Code Sequence (0040,000A) [3]
|
----
|
----
|
View Name (0008,2127) [3]
|
----
|
----
|
View Number (0008,2128) [3]
|
----
|
----
|
Number of Event Timers (0008,2129) [3]
|
----
|
----
|
Event Elapsed Time(s) (0008,2130) [3]
|
----
|
----
|
Event Timer Name(s) (0008,2132) [3]
|
----
|
----
|
View Code Sequence (0054,0220) [3]
|
----
|
----
|
>View Modifier Code Sequence (0054,0222) [3]
|
----
|
-
Recommended if the Modality conforms as an SCU to the Modality Worklist SOP Class and Modality Performed Procedure Step
-
Sequence may have one or more Items
This annex provides guidelines for implementation of the following aspects of Staged Protocol exams:
-
Identification of a Staged Protocol exam.
-
Identification of Stages and Views within a Staged Protocol exam.
-
Identification of extra-Protocol images within a Staged Protocol exam.
-
Acquisition of multiple images of a View during a Stage, and identification of the preferred image for that Stage.
-
Workflow management of Staged Protocol images.
K.5.1 Staged Protocol Exam Identification
The Attributes Number of Stages (0008,2124) and Number of Views in Stage (0008,212A) are each Type 2C with the condition "Required if this image was acquired in a Staged Protocol." These two Attributes will be present with values in image SOP Instances if the exam meets the definition of a Staged Protocol Exam stated in Section K.3. This includes both the Protocol View images as well as any extra-Protocol images acquired during the Protocol Stages.
The Attributes Protocol Name (0018,1030) and Performed Protocol Code Sequence (0040,0260) identify the Protocol of a Staged Protocol Exam, but the mere presence of one or both of these Attributes does not in itself identify the acquisition as a Staged Protocol Exam. If both Protocol Name and Performed Protocol Code Sequence Attributes are present, the Protocol Name value takes precedence over the Performed Protocol Code Sequence Code Meaning value as a display label for the Protocol, since the Protocol Name would convey the institutional preference better than the standardized code meaning.
K.5.2 Stage and View Identification
Display devices usually include capabilities that aid in the organization and presentation of images acquired as part of the Staged Protocol. These capabilities allow a clinician to display images of a given View acquired during different Stages of the Protocol side by side for comparison. A View is a particular combination of the transducer position and orientation at the time of image acquisition. Images are acquired at the same View in different Protocol Stages for the purpose of comparison. For these features to work properly, the display device must be able to determine the Stage and View of each image in an unambiguous fashion.
There are three possible mechanisms for conveying Stage and View identification in the image SOP Instances:
-
"Numbers" (Stage Number (0008,2122) and View Number (0008,2128) ), which number Stages and Views, starting with one.
-
"Names" (Stage Name (0008,2120) and View Name (0008,2127) ), which specify textual names for each Stage and View, respectively.
-
"Code sequences" (Stage Code Sequence (0040,000A) for Stage identification, and View Code Sequence (0054,0220) for View identification), which give identification "codes" to the Stage and View respectively.
The use of code sequences to identify Stage and View, using Context Group values specified in PS3.16 (e.g., CID 12002 “Ultrasound Protocol Stage Type” and CID 12226 “Echocardiography Image View”), allows a display application with knowledge of the code semantics to render a display in accordance with clinical domain uses and user preferences (e.g., populating each quadrant of an echocardiographic display with the user desired stage and view). The IHE Echocardiography Workflow Profile requires such use of code sequences for stress-echo studies.
Table K.5-1 provides an example of the Staged Protocol relevant Attributes in images acquired during a typical cardiac stress-echo ultrasound exam.
Table K.5-1. Staged Protocol Image Attributes Example
Baseline Stage - View 1
|
Mid-Stress Stage - View 1
|
Mid-Stress Stage - View 2
|
Study Instance UID:
"1.2.840….123.1"
|
Study Instance UID:
"1.2.840….123.1"
|
Study Instance UID:
"1.2.840….123.1"
|
Request Attributes Sequence:
|
Request Attributes Sequence:
|
Request Attributes Sequence:
|
>Scheduled Procedure Step Description: "Exercise stress echocardiography"
|
>Scheduled Procedure Step Description: "Exercise stress echocardiography"
|
>Scheduled Procedure Step Description: "Exercise stress echocardiography"
|
>Scheduled Protocol Code Sequence:
|
>Scheduled Protocol Code Sequence:
|
>Scheduled Protocol Code Sequence:
|
>>Code Value: "433233004"
|
>>Code Value: "433233004"
|
>>Code Value: "433233004"
|
>>Coding Scheme Designator: "SCT"
|
>>Coding Scheme Designator: "SCT"
|
>>Coding Scheme Designator: "SCT"
|
>>Code Meaning: "Exercise stress echocardiography"
|
>>Code Meaning: "Exercise stress echocardiography"
|
>>Code Meaning: "Exercise stress echocardiography"
|
Performed Procedure Step Description: "Exercise stress echocardiography"
|
Performed Procedure Step Description: "Exercise stress echocardiography"
|
Performed Procedure Step Description: "Exercise stress echocardiography"
|
Protocol Name:
"EXERCISE STRESS-ECHO"
|
Protocol Name:
"EXERCISE STRESS-ECHO"
|
Protocol Name:
"EXERCISE STRESS-ECHO"
|
Performed Protocol Code Sequence:
|
Performed Protocol Code Sequence:
|
Performed Protocol Code Sequence:
|
>Code Value: "433233004"
|
>Code Value: "433233004"
|
>Code Value: "433233004"
|
>Coding Scheme Designator: "SCT"
|
>Coding Scheme Designator: "SCT"
|
>Coding Scheme Designator: "SCT"
|
>Code Meaning: "Exercise stress echocardiography"
|
>Code Meaning: "Exercise stress echocardiography"
|
>Code Meaning: "Exercise stress echocardiography"
|
Number of Stages: "4"
|
Number of Stages: "4"
|
Number of Stages: "4"
|
Number of Views In Stage: "2"
|
Number of Views In Stage: "2"
|
Number of Views In Stage: "2"
|
Stage Name: "BASELINE"
|
Stage Name: "MID-STRESS"
|
Stage Name: "MID-STRESS"
|
Stage Number: "1"
|
Stage Number: "2"
|
Stage Number: "2"
|
Stage Code Sequence:
|
Stage Code Sequence:
|
Stage Code Sequence:
|
>Code Value:"128974000"
|
>Code Value: "109091"
|
>Code Value: "109091"
|
>Coding Scheme Designator: "SCT"
|
>Coding Scheme Designator: "DCM"
|
>Coding Scheme Designator: "DCM"
|
>Code Meaning: "Baseline state"
|
>Code Meaning: "Cardiac Stress State"
|
>Code Meaning: "Cardiac Stress State"
|
View Name: "Para-sternal long axis"
|
View Name: "Para-sternal long axis"
|
View Name: "Para-sternal short axis"
|
View Number: "1"
|
View Number: "1"
|
View Number: "2"
|
----
|
Number of Event Timers: "1"
|
Number of Event Timers: "1"
|
----
|
Event Elapsed Time(s): "10000" (ms)
|
Event Elapsed Time(s): "25000" (ms)
|
----
|
Event Elapsed Timer Name(s): "Time Since Exercise Halted"
|
Event Elapsed Timer Name(s): "Time Since Exercise Halted"
|
View Code Sequence:
|
View Code Sequence:
|
View Code Sequence:
|
>Code Value: "399139001"
|
>Code Value: "399139001"
|
>Code Value: "399306005"
|
>Coding Scheme Designator: "SCT"
|
>Coding Scheme Designator: "SCT"
|
>Coding Scheme Designator: "SCT"
|
>Code Meaning: "Parasternal long axis"
|
>Code Meaning: "Parasternal long axis"
|
>Code Meaning: "Parasternal short axis"
|
K.5.3 Extra-protocol Image Identification
At any Stage of a Staged Protocol exam, the operator may acquire images that are not part of the Protocol. These images are so-called "extra-Protocol images". Information regarding the performed Protocol is still included because such images are acquired in the same Procedure Step as the Protocol images. The Stage number and optionally other Stage identification Attributes (Stage Name and/or Stage Code Sequence) should still be conveyed in extra-Protocol images. However, the View number should be omitted to signify that the image is not one of the standard Views in the Protocol. Other View identifying information, such as name or code sequences, may indicate the image location.
Table K.5-2. Comparison Of Protocol And Extra-Protocol Image Attributes Example
Mid-Stress Stage - View 1
Protocol Image
|
Mid-Stress Stage
Extra-Protocol Image
|
Study Instance UID:
"1.2.840….123.1"
|
Study Instance UID:
"1.2.840….123.1"
|
Request Attributes Sequence:
|
Request Attributes Sequence:
|
>Scheduled Procedure Step Description: " Exercise stress echocardiography protocol"
|
>Scheduled Procedure Step Description: " Exercise stress echocardiography protocol"
|
>Scheduled Protocol Code Sequence:
|
>Scheduled Protocol Code Sequence:
|
>>Code Value: " 433233004"
|
>>Code Value: " 433233004"
|
>>Coding Scheme Designator: "SCT"
|
>>Coding Scheme Designator: "SCT"
|
>>Code Meaning:" Exercise stress echocardiography"
|
>>Code Meaning:" Exercise stress echocardiography"
|
Performed Procedure Step Description: "Exercise stress echocardiography"
|
Performed Procedure Step Description: "Exercise stress echocardiography"
|
Protocol Name:
"EXERCISE STRESS-ECHO"
|
Protocol Name:
"EXERCISE STRESS-ECHO"
|
Performed Protocol Code Sequence:
|
Performed Protocol Code Sequence:
|
>Code Value: "433233004"
|
>Code Value: "433233004"
|
>Coding Scheme Designator: "SCT"
|
>Coding Scheme Designator: "SCT"
|
>Code Meaning:" Exercise stress echocardiography"
|
>Code Meaning:" Exercise stress echocardiography"
|
Number of Stages: "4"
|
Number of Stages: "4"
|
Number of Views In Stage: "2"
|
Number of Views In Stage: "2"
|
Stage Name: "MID-STRESS"
|
Stage Name: "MID-STRESS"
|
Stage Number: "2"
|
Stage Number: "2"
|
Stage Code Sequence:
|
Stage Code Sequence:
|
>Code Value: "109091"
|
>Code Value: "109091"
|
>Coding Scheme Designator: "DCM"
|
>Coding Scheme Designator: "DCM"
|
>Code Meaning: "Cardiac Stress state"
|
>Code Meaning: "Cardiac Stress state"
|
View Name: "Para-sternal long axis"
|
----
|
View Number: "1"
|
----
|
View Code Sequence:
|
----
|
>Code Value: "399139001"
|
----
|
>Coding Scheme Designator: "SCT"
|
----
|
>Code Meaning: "Parasternal long axis"
|
----
|
K.5.4 Multiple Images of A Stage-view
Ultrasound systems often acquire multiple images at a particular stage and view. If one image is difficult to interpret or does not fully portray the ventricle wall, the physician may choose to view an alternate. In some cases, the user may identify the preferred image. The Key Object Selection Document can identify the preferred image for any or all of the Stage-Views. This specific usage of the Key Object Selection Document has a Document Title of (113013, DCM, "Best In Set") and Document Title Modifier of (113017, DCM, "Stage-View").
K.5.5 Workflow Management of Staged Protocol Images
K.5.5.1 Uninterrupted Exams - Single MPPS
Modality Performed Procedure Step (MPPS) is the basic organizational unit of Staged Protocol Exams. It is recommended that a single MPPS instance encompass the entire acquisition of an ultrasound Staged Protocol Exam if possible.
There are no semantics assigned to the use of Series within a Staged Protocol Exam other than the DICOM requirements as to the relationship between Series and Modality Performed Procedure Steps. In particular, all of the following scenarios are possible:
-
one Series for all images in the MPPS.
-
separate Series for Protocol View images and extra-Protocol images in the MPPS.
-
separate Series for images of each Stage within the MPPS.
-
more than one Series for the images acquired in a single Protocol Stage.
There is no recommendation on the organization of images into Series because clinical events make such recommendations impractical. Figure K.5.5-1 shows a possible sequence of interactions for a protocol performed as a single MPPS.
K.5.5.2 Interrupted Exams - Multiple MPPS
A special case arises when the acquisition during a Protocol Stage is halted for some reason. For example, such a situation can occur if signs of patient distress are observed, such as angina in a cardiac stress exam. These criteria are part of the normal exam Protocol, and as long as the conditions defined for the Protocol are met the MPPS status is set to COMPLETED. Only if the exam terminates before meeting the minimum acquisition requirements of the selected Protocol would MPPS status be set to DISCONTINUED. It is recommended that the reason for discontinuation should be conveyed in the Modality Procedure Step Discontinuation Reason Code Sequence (0040,0281). Staged Protocols generally include criteria for ending the exam, such as when a target time duration is reached or if signs of patient distress are observed.
If a Protocol Stage is to be acquired at a later time with the intention of using an earlier completed Protocol Stage of a halted Staged Protocol then a new Scheduled Procedure Step may or may not be created for this additional acquisition. Workflow management recommendations vary depending on whether the care institution decides to create a new Scheduled Procedure Step or not.
Follow-up Stages must use View Numbers, Names, and Code Sequences identical to those in the prior Stages to enable automatically correlating images of the original and follow-up Stages.
K.5.5.2.1 Unscheduled Follow-up Stages
Follow-up Stages require a separate MPPS. Since follow-up stages are part of the same Requested Procedure and Scheduled Procedure Step, all acquired image SOP Instances and generated MPPS instances specify the same Study Instance UID. If the Study Instance UID is different, systems will have difficulty associating related images. This creates a significant problem if Modality Worklist is not supported. Therefore systems should assign the same Study Instance UID for follow-up Stages even if Modality Worklist is not supported. Figure K.5.5-2 shows a possible interaction sequence for this scenario.
K.5.5.2.2 Scheduled Follow-up Stages
In some cases a new Scheduled Procedure Step is created to acquire follow-up Stages. For example, a drug induced stress-echo exam may be scheduled because an earlier exercise induced stress-echo exam had to be halted due to patient discomfort. In such cases it would be redundant to reacquire earlier Stages such as the rest Stage of a cardiac stress-echo ultrasound exam. One MPPS contains the Image instances of the original Stage and a separate MPSS contains the follow-up instances.
If Scheduled and Performed Procedure Steps for Staged Protocol Exam data use the same Study Instance UID, workstations can associate images from the original and follow-up Stages. Figure K.5.5-3 shows a possible interaction sequence for this scenario.
L Hemodynamics Report Structure (Informative)
The Hemodynamics Report is based on TID 3500 “Hemodynamics Report”. The report contains one or more measurement containers, each corresponding to a phase of the cath procedure. Within each container may be one or more sub-containers, each associated with a single measurement set. A measurement set consists of measurements from a single anatomic location. The resulting hierarchical structure is depicted in Figure L-1.
The container for each phase has an optional subsidiary container for Clinical Context with a parent-child relationship of has-acquisition-context. This Clinical Context container allows the recording of pertinent patient state information that may be essential to understanding the measurements made during that procedure phase. It should be noted that any such patient state information is necessarily only a summary; a more complete clinical picture may be obtained by review of the cath procedure log.
The lowest level containers for the measurement sets are specialized by the class of anatomic location - arterial, venous, atrial, ventricular - for the particular measurements appropriate to that type of location. These containers explicitly identify the anatomic location with a has-acquisition-context relationship. Since such measurement sets are typically measured on the same source (e.g., pressure waveform), the container may also have a has-acquisition-context relationship with a source DICOM waveform SOP Instance.
The "atomic" level of measurements within the measurement set containers includes three types of data. First is the specific measurement data acquired from waveforms related to the site. Second is general measurement data that may include any hemodynamic, patient vital sign, or blood chemistry data. Third, derived data are produced from a combination of other data using a mathematical formula or table, and may provide reference to the equation.
M Vascular Ultrasound Reports (Informative)
M.1 Vascular Report Structure
The vascular procedure report partitions numeric measurements into section headings by anatomic region and by laterality. A laterality concept modifier of the section heading concept name specifies whether laterality is left or right. Therefore, laterally paired anatomy sections may appear two times, once for each laterality. Findings of unpaired anatomy, are separately contained in a separate "unilateral" section container. Therefore, in vascular ultrasound, laterality is always expressed at the section heading level with one of three states: left, right, or unilateral (unpaired). There is no provision for anatomy of unknown laterality other than as a TEXT Content Item in the summary.
Note that expressing laterality at the heading level differs from OB-GYN Pelvic and fetal vasculature, which expresses laterality as concept modifiers of the anatomic containers.
The common vascular pattern is a battery of measurements and calculations repeatedly applied to various anatomic locations. The anatomic location is the acquisition context of the measurement group. For example, a measurement group may have a measurement source of Common Iliac Artery with several measurement instances and measurement types such as mean velocity, peak systolic velocity, acceleration time, etc.
There are distinct anatomic concepts to modify the base anatomy concept. The modification expression is a Content Item with a modifier concept name and value selected from a Context Group as the table shows below.
The following are simple, non-comprehensive illustrations of significant report sections.
M.2.1 Example 1: Renal Vessels
M.2.2 Example 2: Carotids Extracranial
N Echocardiography Procedure Reports (Informative)
The templates for ultrasound reports are defined in PS3.16. Figure N.1-1 is an outline of the echocardiography report.
The common echocardiography measurement pattern is a group of measurements obtained in the context of a protocol. Figure N.1-2 shows the pattern.
N.2 Measurement Terminology Composition
DICOM identifies echocardiography observations with various degrees of pre- and post-coordination. The concept name of the base Content Item typically specifies both anatomy and property for commonly used terms, or purely a property. Pure property concepts require an anatomic site concept modifier. Pure property concepts such as those in CID 12222 “Orifice Flow Property” and CID 12239 “Cardiac Output Property” use concept modifiers shown below.
Further qualification specifies the image mode and the image plane using HAS ACQ CONTEXT with the value sets shown below.
N.3 Illustrative Mapping to ASE Concepts
The content of this section provides recommendations on how to express the concepts from draft ASE guidelines with measurement type concept names and concept name modifiers.
The leftmost column is the name of the ASE concept. The Base Measurement Concept Name is the concept name of the numeric measurement Content Item. The modifiers column specifies a set of modifiers for the base measurement concept name. Each modifier consists of a modifier concept name (e.g., method or mode) and its value (e.g., Continuity). Where no Concept Modifier appears, the base concept matches the ASE concept.
N.3.3 Left Ventricle - Linear
N.3.4 Left Ventricle Volumes and Ejection Fraction
N.3.5 Left Ventricle Output
N.3.6 Left Ventricular Outflow Tract
N.3.7 Left Ventricle Mass
N.3.8 Left Ventricle Miscellaneous
N.3.11 Left Atrium / Appendage
N.3.13 Pulmonic Valve / Pulmonic Artery
N.3.15 Right Atrium / Inferior Vena Cava
N.3.16 Congenital/Pediatric
N.4.1 Example 1: Patient Characteristics
N.4.2 Example 2: LV Dimensions and Fractional Shortening
N.4.3 Example 3: Left Atrium / Aortic Root Ratio
N.4.4 Example 4: Pressures
N.4.5 Example 5: Cardiac Output
N.4.6 Example 6: Wall Scoring
The IVUS Report contains one or more vessel containers, each corresponding to the vessel (arterial location) being imaged. Each vessel is associated with one or more IVUS image pullbacks (Ultrasound Multi-frame Images), acquired during a phase of a catheterization procedure. Each vessel may contain one or more sub-containers, each associated with a single lesion. Each lesion container includes a set of IVUS measurements and qualitative assessments. The resulting hierarchical structure is depicted in Figure N.5-1.
O Registration (Informative)
O.1 Spatial Registration and Spatial Fiducials SOP Classes
These SOP Classes allow describing spatial relationships between sets of images. Each instance can describe any number of registrations as shown in Figure O.1-1. It may also reference prior registration instances that contribute to the creation of the registrations in the instance.
A Reference Coordinate System (RCS) is a spatial Frame of Reference described by the DICOM Frame of Reference Module. The chosen Frame of Reference of the Registration SOP Instance may be the same as one or more of the Referenced SOP Instances. In this case, the Frame of Reference UID (0020,0052) is the same, as shown by the Registered RCS in the figure. The registration information is a sequence of spatial transformations, potentially including deformation information. The composite of the specified spatial transformations defines the complete transformation from one RCS to the other.
Image instances may have no DICOM Frame of Reference, in which case the registration is to that single image (or frame, in the case of a Multi-frame Image). The Spatial Registration IOD may also be used to establish a coordinate system for an image that has no defined Frame of Reference. To do this, the center of the top left pixel of the source image is treated as being located at (0, 0, 0). Offsets from the first pixel are computed using the resolution specified in the Source IOD. Multiplying that coordinate by the Transformation matrix gives the patient coordinate in the new Frame of Reference.
A special case is an atlas. DICOM has defined Well-Known Frame of Reference UIDs for several common atlases. There is not necessarily image data associated with an atlas.
When using the Spatial Registration or Deformable Registration SOP Classes there are two types of coordinate systems. The coordinate system of the referenced data is the Source RCS. The coordinate system established by the SOP instance is the Registered RCS.
The sense of the direction of transformation differs between the Spatial Registration SOP Class and the Deformable Spatial Registration SOP Class. The Spatial Registration SOP Class specifies a transformation that maps Source coordinates, in the Source RCS, to Registered coordinates, in the Registered RCS. The Deformable Spatial Registration SOP Class specifies transformations that map Registered coordinates, in the Registered RCS, to coordinates in the Source RCS.
The Spatial Fiducials SOP Class stores spatial fiducials as implicit registration information.
Multi-Modality Fusion:
A workstation or modality performs a registration of images from independent acquisition modalities-PET, CT, MR, NM, and US-from multiple series. The workstation stores the registration data for subsequent visualization and image processing. Such visualization may include side-by-side synchronized display, or overlay (fusion) of one modality image on the display of another. The processes for such fusion are beyond the scope of the Standard. The workstation may also create and store a ready-for-display fused image, which references both the source image instances and the registration instance that describes their alignment.
Prior Study Fusion:
Using post processing or a manual process, a workstation creates a spatial object registration of the current Study's Series from prior Studies for comparative evaluation.
Atlas Mapping:
A workstation or a CAD device specifies fiducials of anatomical features in the brain such as the anterior commissure, posterior commissure, and points that define the hemispheric fissure plane. The system stores this information in the Spatial Fiducials SOP Instance. Subsequent retrieval of the fiducials enables a device or workstation to register the patient images to a functional or anatomical atlas, presenting the atlas information as overlays.
CAD:
A CAD device creates fiducials of features during the course of the analysis. It stores the locations of the fiducials for future analysis in another imaging procedure. In the subsequent CAD procedure, the CAD device performs a new analysis on the new data. As before, it creates comparable fiducials, which it may store in a Spatial Fiducials SOP Instance. The CAD device then performs additional analysis by registering the images of the current exam to the prior exam. It does so by correlating the fiducials of the prior and current exam. The CAD device may store the registration in Registration SOP Instance.
Adaptive Radiotherapy:
A CT Scan is taken to account for variations in patient position prior to radiation therapy. A workstation performs the registration of the most recent image data to the prior data, corrects the plan, and stores the registration and revised plan.
Image Stitching:
An acquisition device captures multiple images, e.g., DX images down a limb. A user identifies fiducials on each of the images. The system stores these in one or more Fiducial SOP Instances. Then the images are "stitched" together algorithmically by means that utilize the Fiducial SOP Instances as input. The result is a single image and optionally a Registration SOP Instance that indicates how the original images can be transformed to a location on the final image.
Figure O.3-1 shows the system interaction of storage operations for a registration of MR and CT using the Spatial Registration SOP Class. The Image Plane Module Attributes of the CT Series specify the spatial mapping to the RCS of its DICOM Frame of Reference.
The receiver of the Registration SOP Instance may use the spatial transformation to display or process the referenced image data in a common coordinate system. This enables interactive display in 3D during interpretation or planning, tissue classification, quantification, or Computer Aided Detection. Figure O.3-2 shows a typical interaction scenario.
In the case of coupled acquisition modalities, one acquisition device may know the spatial relationship of its image data relative to the other. The acquisition device may use the Registration SOP Class to specify the relationship of modality B images to modality A images as shown below in Figure O.3-3. In the most direct case, the data of both modalities are in the same DICOM Frame of Reference for each SOP Class Instance.
A Spatial Registration instance consists of one or more instances of a Registration. Each Registration specifies a transformation from the RCS of the Referenced Image Set, to the RCS of this Spatial Registration instance (see PS3.3) identified by the Frame of Reference UID (0020,0052).
Figure O.4-1 shows an information model of a Spatial Registration to illustrate the relationship of the Attributes to the objects of the model. The DICOM Attributes that describe each object are adjacent to the object.
Figure O.4-2 shows an information model of a Deformable Spatial Registration to illustrate the relationship of the Attributes to the objects of the model. The DICOM Attributes that describe each object are adjacent to the object.
Figure O.4-3 shows a Spatial Fiducials information model to illustrate the relationship of the Attributes to the objects of the model. The DICOM Attributes that describe each object are adjacent to the object.
A 4x4 affine transformation matrix describes spatial rotation, translation, scale changes and affine transformations that register referenced images to the Registration IE's homogeneous RCS. These steps are expressible in a single matrix, or as a sequence of multiple independent rotations, translations, or scaling, each expressed in a separate matrix. Normally, registrations are rigid body, involving only rotation and translation. Changes in scale or affine transformations occur in atlas registration or to correct minor mismatches.
Fiducials are image-derived reference markers of location, orientation, or scale. These may be labeled points or collections of points in a data volume that specify a shape. Most commonly, fiducials are individual points.
Correlated fiducials of separate image sets may serve as inputs to a registration process to estimate the spatial registration between similar objects in the images. The correlation may, or may not, be expressed in the fiducial identifiers. A fiducial identifier may be an arbitrary number or text string to uniquely identify each fiducial from others in the set. In this case, fiducial correlation relies on operator recognition and control.
Alternatively, coded concepts may identify the acquired fiducials so that systems can automatically correlate them. Examples of such coded concepts are points of a stereotactic frame, prosthesis points, or well-resolved anatomical landmarks such as bicuspid tips. Such codes could be established and used locally by a department, over a wider area by a society or research study coordinator, or from a standardized set.
The table below shows each case of identifier encoding. A and B represent two independent registrations: one to some image set A, and the other to image set B.
Fiducials may be a point or some other shape. For example, three or more arbitrarily chosen points might designate the inter-hemispheric plane for the registration of head images. Many arbitrarily chosen points may identify a surface such as the inside of the skull.
A fiducial also has a Fiducial UID. This UID identifies the creation of the fiducial and allows other SOP Instances to reference the fiducial assignment.
P Transforms and Mappings (Informative)
The Affine Transform Matrix is of the following form.
This matrix requires the bottom row to be [0 0 0 1] to preserve the homogeneous coordinates.
The matrix can be of type: RIGID, RIGID_SCALE and AFFINE. These different types represent different conditions on the allowable values for the matrix elements.
-
RIGID:
This transform requires the matrix obey orthonormal transformation properties:
for all combinations of j = 1,2,3 and k = 1,2,3 where δ = 1 for i = j and zero otherwise.
The expansion into non-matrix equations is:
-
M11 M11 + M21 M21 + M31 M31 = 1 where j = 1, k = 1
-
M11 M12 + M21 M22 + M31 M32 = 0 where j = 1, k = 2
-
M11 M13 + M21 M23 + M31 M33 = 0 where j = 1, k = 3
-
M12 M11 + M22 M21 + M32 M31 = 0 where j = 2, k = 1
-
M12 M12 + M22 M22 + M32 M32 = 1 where j = 2, k = 2
-
M12 M13 + M22 M23 + M32 M33 = 0 where j = 2, k = 3
-
M13 M11 + M23 M21 + M33 M31 = 0 where j = 3, k = 1
-
M13 M12 + M23 M22 + M33 M32 = 0 where j = 3, k = 2
-
M13 M13 + M23 M23 + M33 M33 = 1 where j = 3, k = 3
The Frame of Reference Transformation Matrix AMB describes how to transform a point (Bx,By,Bz) with respect to RCSB into (Ax,Ay,Az) with respect to RCSA.
The matrix above consists of two parts: a rotation and translation as shown below;
Rotation:
Translation:
The first column [M11,M21,M31 ] are the direction cosines (projection) of the X-axis of RCSB with respect to RCSA
. The second column [M12,M22,M32] are the direction cosines (projection) of the Y-axis of RCSB with respect to RCSA. The third column [M13,M23,M33] are the direction cosines (projection) of the Z-axis of RCSB with respect to RCSA. The fourth column [T1,T2,T3] is the origin of RCSB with respect to RCSA.
There are three degrees of freedom representing rotation, and three degrees of freedom representing translation, giving a total of six degrees of freedom.
-
RIGID_SCALE
The following constraint applies:
for all combinations of j = 1,2,3 and k = 1,2,3 where δ = 1 for i=j and zero otherwise.
The expansion into non-matrix equations is:
-
M11 M11 + M21 M21 + M31 M31 = S1
2 where j = 1, k = 1
-
M11 M12 + M21 M22 + M31 M32 = 0 where j = 1, k = 2
-
M11 M13 + M21 M23 + M31 M33 = 0 where j = 1, k = 3
-
M12 M11 + M22 M21 + M32 M31 = 0 where j = 2, k = 1
-
M12 M12 + M22 M22 + M32 M32 = S2
2 where j = 2, k = 2
-
M12 M13 + M22 M23 + M32 M33 = 0 where j = 2, k = 3
-
M13 M11 + M23 M21 + M33 M31 = 0 where j = 3, k = 1
-
M13 M12 + M23 M22 + M33 M32 = 0 where j = 3, k = 2
-
M13 M13 + M23 M23 + M33 M33 = S3
2 where j = 3, k = 3
The above equations show a simple way of extracting the spatial scaling parameters Sj from a given matrix. The units of Sj
2 is the RCS unit dimension of one millimeter.
This type can be considered a simple extension of the type RIGID. The RIGID_SCALE is easily created by pre-multiplying a RIGID matrix by a diagonal scaling matrix as follows:
where MRBWS is a matrix of type RIGID_SCALE and MRB is a matrix of type RIGID.
-
AFFINE:
No constraints apply to this matrix, so it contains twelve degrees of freedom. This type of Frame of Reference Transformation Matrix allows shearing in addition to rotation, translation and scaling.
For a RIGID type of Frame of Reference Transformation Matrix, the inverse is easily computed using the following formula (inverse of an orthonormal matrix):
For RIGID_SCALE and AFFINE types of Registration Matrices, the inverse cannot be calculated using the above equation, and must be calculated using a conventional matrix inverse operation.
Q Breast Imaging Report (Informative)
Q.1 Breast Imaging Report Content Tree Structure
The templates for the Breast Imaging Report are defined in PS3.16. Relationships defined in the Breast Imaging Report templates are by-value. This template structure may be conveyed using the Enhanced SR SOP Class or the Basic Text SR SOP Class.
As shown in Figure Q.1-1, the Breast Imaging Report Narrative and Breast Imaging Report Supplementary Data sub-trees together form the Content Tree of the Breast Imaging Report.
The Breast Imaging Procedure Reported sub-tree is a mandatory child of the Supplementary Data Content Item, to describe all of the procedures to which the report applies using coded terminology. It may also be used as a sub-tree of sections within the Supplementary Data sub-tree, for the instance in which a report covers more than one procedure, but different sections of the Supplementary Data record the evidence of a subset of the procedures.
An instance of the Breast Imaging Report Narrative sub-tree contains one or more text-based report sections, with a name chosen from CID 6052 “Breast Imaging Report Section Title”. Within a report section, one or more observers may be identified. This sub-tree is intended to contain the report text as it was created, presented to, and signed off by the verifying observer. It is not intended to convey the exact rendering of the report, such as formatting or visual organization. Report text may reference one or more image or other composite objects on which the interpretation was based.
An instance of the Breast Imaging Report Supplementary Data sub-tree contains one or more of: Breast Imaging Procedure Reported, Breast Composition Section, Breast Imaging Report Finding Section, Breast Imaging Report Intervention Section, Overall Assessment. This sub-tree is intended to contain the supporting evidence for the Breast Imaging Report Narrative sub-tree, using coded terminology and numeric data.
The Breast Imaging Assessment sub-tree may be instantiated as the content of an Overall Assessment section of a report (see Figure Q.1-4), or as part of a Findings section of a report (see TID 4206 “Breast Imaging Report Finding Section”). Reports may provide an individual assessment for each Finding, and then an overall assessment based on an aggregate of the individual assessments.
Q.2 Breast Imaging Report Examples
The following are simple illustrations of encoding Mammography procedure based Breast Imaging Reports.
Q.2.1 Example 1: Screening Mammogram With Negative Findings
A screening mammography case, i.e., there are typically four films and no suspicious abnormalities. The result is a negative mammogram with basic reporting. This example illustrates a report encoded as narrative text only:
Example Q.2-1. Report Sample: Narrative Text Only
Procedure reported
Film screen mammography, both breasts.
Reason for procedure
Screening
Findings
Comparison was made to exam from 11/14/2001. The breasts are heterogeneously dense. This may lower the sensitivity of mammography. No significant masses, calcifications, or other abnormalities are present. There is no significant change from the prior exam.
Impressions
BI-RADS® Category 1: Negative. Recommend normal interval follow-up in 12 months
Table Q.2-1. Breast Image Report Content for Example 1
Node
|
Code Meaning of Concept Name
|
Code Meaning or Example Value
|
TID/CID
|
1
|
Breast Imaging Report
|
|
TID 4200
|
1.1
|
Language of Content Item and Descendants
|
English
|
TID 1204
|
1.2
|
Narrative Summary
|
|
TID 4202
|
1.2.1
|
Procedure reported
|
|
TID 4202
CID 6052
|
1.2.1.1
|
Procedure reported
|
Film screen mammography, both breasts.
|
TID 4202
CID 6053
|
1.2.2
|
Reason for procedure
|
|
TID 4202
CID 6052
|
1.2.2.1
|
Reason for procedure
|
Screening
|
TID 4202
CID 6053
|
1.2.3
|
Findings
|
|
TID 4202
CID 6052
|
1.2.3.1
|
Finding
|
Comparison was made to exam from 11/14/2001. The breasts are heterogeneously dense. This may lower the sensitivity of mammography. No significant masses, calcifications, or other abnormalities are present. There is no significant change from the prior exam.
|
TID 4202
CID 6053
|
1.2.4
|
Impressions
|
|
TID 4202
CID 6052
|
1.2.4.1
|
Impression
|
BI-RADS® Category 1: Negative. Recommend normal interval follow-up in 12 months.
|
TID 4202
CID 6053
|
Q.2.2 Example 2: Screening Mammogram With Negative Findings
A screening mammography case, i.e., there are typically four films and no suspicious abnormalities. The result is a negative mammogram with basic reporting. This example illustrates a report encoded as narrative text with minimal supplementary data, and follows BI-RADS® and MQSA:
Example Q.2-2. Report Sample: Narrative Text with Minimal Supplementary Data
Procedure reported
Film screen mammography, both breasts.
Reason for procedure
Screening
Comparison to previous exams
Comparison was made to exam from 11/14/2001.
Breast composition
The breasts are heterogeneously dense. This may lower the sensitivity of mammography.
Findings
No significant masses, calcifications, or other abnormalities are present. There is no significant change from the prior exam.
Impressions
BI-RADS® Category 1: Negative. Recommend normal interval follow-up in 12 months.
Overall Assessment
Negative
Table Q.2-2. Breast Imaging Report Content for Example 2
Q.2.3 Example 3: Diagnostic Mammogram - Unilateral
A diagnostic mammogram was prompted by a clinical finding. The result is a probably benign finding with a short interval follow-up of the left breast. This report provides the narrative text with more extensive supplementary data.
Example Q.2-3. Report Sample: Narrative Text with More Extensive Supplementary Data
Procedure reported
Film screen mammography, left breast.
Reason for procedure
Non-bloody discharge left breast.
Breast composition
The breast is almost entirely fat.
Findings
Film screen mammograms were performed. There are heterogeneous calcifications regionally distributed in the 1 o'clock upper outer quadrant, anterior region of the left breast. There is an increase in the number of calcifications from the prior exam.
Impressions
BI-RADS® Category 3: Probably Benign Finding. Short interval follow-up of the left breast is recommended in 6 months.
Table Q.2-3. Breast Imaging Report Content for Example 3
Q.2.4 Example 4: Diagnostic Mammogram and Ultrasound - Unilateral
Following a screening mammogram, the patient was asked to return for additional imaging and an ultrasound on the breast, for further evaluation of a mammographic mass. This example demonstrates a report on multiple breast imaging procedures. This report provides the narrative text with some supplementary data.
Example Q.2-4. Report Sample: Multiple Procedures, Narrative Text with Some Supplementary Data
Procedure reported
Film screen mammography, left breast; Ultrasound procedure, left breast.
Reason for procedure
Additional evaluation requested at current screening.
Comparison to previous exams
Comparison was made to exam from 11/14/2001.
Findings
Film Screen Mammography: A lobular mass with obscured margins is present measuring 7mm in the upper outer quadrant.
Findings
Ultrasound demonstrates a simple cyst.
Impressions
BI-RADS® Category 2: Benign, no evidence of malignancy. Normal interval follow-up of both breasts is recommended in 12 months.
Overall Assessment
Benign
Table Q.2-4. Breast Imaging Report Content for Example 4
R Configuration Use Cases (Informative)
The following use cases are the basis for the decisions made in defining the Configuration Management Profiles specified in PS3.15. Where possible specific protocols that are commonly used in IT system management are specifically identified.
R.1 Install A New Machine
When a new machine is added there need to be new entries made for:
-
TCP/IP parameters
-
DICOM Application Entity Related Parameters
The service staff effort needed for either of these should be minimal. To the extent feasible these parameters should be generated and installed automatically.
The need for some sort of ID is common to most of the use cases, so it is assumed that each machine has sufficient non-volatile storage to at least remember its own name for later use.
Updates may be made directly to the configuration databases or made via the machine being configured. A common procedure for large networks is for the initial network design to assign these parameters and create the initial databases during the complete initial network design. Updates can be made later as new devices are installed.
One step that specifically needs automation is the allocation of AE Titles. These must be unique. Their assignment has been a problem with manual procedures. Possibilities include:
-
Fully automatic allocation of AE Titles as requested. This interacts with the need for AE title stability in some use cases. The automatic process should permit AE Titles to be persistently associated with particular devices and application entities. The automatic process should permit the assignment of AE titles that comply with particular internal structuring rules.
-
Assisted manual allocation, where the service staff proposes AE Titles (perhaps based on examining the list of present AE Titles) and the system accepts them as unique or rejects them when non-unique.
These AE Titles can then be associated with the other application entity related information. This complete set of information needs to be provided for later uses.
The local setup may also involve searches for other AEs on the network. For example, it is likely that a search will be made for archives and printers. These searches might be by SOP class or device type. This is related to vendor specific application setup procedures, which are outside the scope of DICOM.
The network may have been designed in advance and the configuration specified in advance. It should be possible to pre-configure the configuration servers prior to other hardware installation. This should not preclude later updates or later configuration at specific devices.
The DHCP servers have a database that is manually maintained defining the relationship between machine parameters and IP parameters. This defines:
-
Hardware MAC addresses that are to be allocated specific fixed IP information.
-
Client machine names that are to be allocated specific fixed IP information.
-
Hardware MAC addresses and address ranges that are to be allocated dynamically assigned IP addresses and IP information.
-
Client machine name patterns that are to be allocated dynamically assigned IP addresses and IP information.
The IP information that is provided will be a specific IP address together with other information. The present recommendation is to provide all of the following information when available.
The manual configuration of DHCP is often assisted by automated user interface tools that are outside the scope of DICOM. Some people utilize the DHCP database as a documentation tool for documenting the assignment of IP addresses that are preset on equipment. This does not interfere with DHCP operation and can make a gradual transition from equipment presets to DHCP assignments easier. It also helps avoid accidental re-use of IP addresses that are already manually assigned. However, DHCP does not verify that these entries are in fact correct.
There are several ways that the LDAP configuration information can be obtained.
-
A complete installation may be pre-designed and the full configuration loaded into the LDAP server, with the installation Attribute set to false. Then as systems are installed, they acquire their own configurations from the LDAP server. The site administration can set the installation Attribute to true when appropriate.
-
When the LDAP server permits network clients to update the configuration, they can be individually installed and configured. Then after each device is configured, that device uploads its own configuration to the LDAP server.
-
When the LDAP server does not permit network clients to update configurations, they can be individually installed and configured. Then, instead of uploading their own configuration, they create a standard format file with their configuration objects. This file is then manually added to the LDAP server (complying with local security procedures) and any conflicts resolved manually.
The network may have been designed in advance and the configuration specified in advance. It should be possible to pre-configure the configuration servers prior to other hardware installation. This should not preclude later updates or later configuration at specific devices.
LDAP defines a standard file exchange format for transmitting LDAP database subsets in an ASCII format. This file exchange format can be created by a variety of network configuration tools. There are also systems that use XML tools to create database subsets that can be loaded into LDAP servers. It is out of scope to specify these tools in any detail. The use case simply requires that such tools be available.
When the LDAP database is pre-configured using these tools, it is the responsibility of the tools to ensure that the resulting database entries have unique names. The unique name requirement is common to any LDAP database and not just to DICOM AE Titles. Consequently, most tools have mechanisms to ensure that the database updates that they create do have unique names.
At an appropriate time, the installed Attribute is set on the device objects in the LDAP configuration.
R.1.2.2 Updating Configuration During Installation
The "unconfigured" device start up begins with use of the pre-configured services from DHCP, DNS, and NTP. It then performs device configuration and updates the LDAP database. This description assumes that the device has been given permission to update the LDAP database directly.
-
DHCP is used to obtain IP related parameters. The DHCP request can indicate a desired machine name that DHCP can associate with a configuration saved at the DHCP server. DHCP does not guarantee that the desired machine name will be granted because it might already be in use, but this mechanism is often used to maintain specific machine configurations. The DHCP will also update the DNS server (using the DDNS mechanisms) with the assigned IP address and hostname information. Legacy note: A machine with pre-configured IP addresses, DNS servers, and NTP servers may skip this step. As an operational and documentation convenience, the DHCP server database may contain the description of this pre-configured machine.
-
The list of NTP servers is used to initiate the NTP process for obtaining and maintaining the correct time. This is an ongoing process that continues for the duration of device activity. See Time Synchronization below.
-
The list of DNS servers is used to obtain the address of the DNS servers at this site. Then the DNS servers are queried to get the list of LDAP servers. This utilizes a relatively new addition to the DNS capabilities that permit querying DNS to obtain servers within a domain that provide a particular service.
-
The LDAP servers are queried to find the server that provides DICOM configuration services, and then obtain a description for the device matching the assigned machine name. This description includes device specific configuration information and a list of Network AEs. For the unconfigured device there will be no configuration found.
Note
These first four steps are the same as a normal start up (described below).
-
Through a device specific process it determines its internal AE structure. During initial device installation it is likely that the LDAP database lacks information regarding the device. Using some vendor specific mechanism, e.g., service procedures, the device configuration is obtained. This device configuration includes all the information that will be stored in the LDAP database. The fields for "device name" and "AE Title" are tentative at this point.
-
Each of the Network AE objects is created by means of the LDAP object creation process. It is at this point that LDAP determines whether the AE Title is in fact unique among all AE Titles. If the title is unique, the creation succeeds. If there is a conflict, the creation fails and "name already in use" is given as a reasonless uses propose/create as an atomic operation for creating unique items. The LDAP approach permits unique titles that comply with algorithms for structured names, check digits, etc. DICOM does not require structured names, but they are a commonplace requirement for other LDAP users. It may take multiple attempts to find an unused name. This multiple probe behavior can be a problem if "unconfigured device" is a common occurrence and name collisions are common. Name collisions can be minimized at the expense of name structure by selecting names such as "AExxxxxxxxxxxxxx" where
"xxxxxxxxxxxxxx" is a truly randomly selected number. The odds of collision are then exceedingly small, and a unique name will be found within one or two probes.
-
The device object is created. The device information is updated to reflect the actual AE titles of the AE objects. As with AE objects, there is the potential for device name collisions.
-
The network connection objects are created as subordinates to the device object.
-
The AE objects are updated to reflect the names of the network connection objects.
The "unconfigured device" now has a saved configuration. The LDAP database reflects its present configuration.
In the following example, the new system needs two AE Titles. During its installation another machine is also being installed and takes one of the two AE Titles that the first machine expected to use. The new system then claims another different EYE-title that does not conflict.
R.1.2.3 Configure Client Then Update Server
Much of the initial start up is the same for restarting a configured device and for configuring a client first and then updating the server. The difference is two-fold.
The AE Title uniqueness must be established manually, and the configuration information saved at the client onto a file that can then be provided to the LDAP server. There is a risk that the manually assigned AE Title is not unique, but this can be managed and is easier than the present entirely manual process for assigning AE Titles.
R.1.3 Distributed Update Propagation
The larger enterprise networks require prompt database responses and reliable responses during network disruptions. This implies the use of a distributed or federated database. These have update propagation issues. There is not a requirement for a complete and accurate view of the DICOM network at all times. There is a requirement that local subsets of the network maintain an accurate local view. E.g., each hospital in a large hospital chain may tolerate occasional disconnections or problems in viewing the network information in other hospitals in that chain, but they require that their own internal network be reliably and accurately described.
LDAP supports a variety of federation and distribution schemes. It specifically states that it is designed and appropriate for federated situations where distribution of updates between federated servers may be slow. It is specifically designed for situations where database updates are infrequent and database queries dominate.
Legacy devices utilize some internal method for obtaining the IP addresses, port numbers, and AE Titles of the other devices. For legacy compatibility, a managed node must be controlled so that the IP addresses, port numbers, and AE Titles do not change. This affects DHCP because it is DHCP that assigns IP addresses. The LDAP database design must preserve port number and AE Title so that once the device is configured these do not change.
DHCP was designed to deal with some common legacy issues:
-
Documenting legacy devices that do not utilize DHCP. Most DHCP servers can document a legacy device with a DHCP entry that describes the device. This avoids IP address conflicts. Since this is a manual process, there still remains the potential for errors. The DHCP server configuration is used to reserve the addresses and document how they are used. This documented entry approach is also used for complex multi-homed servers. These are often manually configured and kept with fixed configurations.
-
Specifying fixed IP addresses for DHCP clients. Many servers have clients that are not able to use DNS to obtain server IP addresses. These servers may also utilize DHCP for start up configuration. The DHCP servers must support the use of fixed IP allocations so that the servers are always assigned the same IP address. This avoids disrupting access by the server's legacy clients. This usage is quite common because it gives the IT administrators the centralized control that they need without disrupting operations. It is a frequent transitional stage for machines on networks that are transitioning to full DHCP operation.
There are two legacy-related issues with time configuration:
-
The NTP system operates in UTC. The device users probably want to operate in local time. This introduces additional internal software requirements to configure local time. DHCP will provide this information if that option is configured into the DHCP server.
-
Device clock setting must be documented correctly. Some systems set the battery-powered clock to local time; others use UTC. Incorrect settings will introduce very large time transient problems during start up. Eventually NTP clients do resolve the huge mismatch between battery clock and NTP clock, but the device may already be in medical use by the time this problem is resolved. The resulting time discontinuity can then pose problems. The magnitude of this problem depends on the particular NTP client implementation.
R.3 Obtain Configuration of Other Devices
Managed devices can utilize the LDAP database during their own installation to establish configuration parameters such as the AE Title of destination devices. They may also utilize the LDAP database to obtain this information at run time prior to association negotiation.
R.3.1 Find AE When Given Device Type
The LDAP server supports simple relational queries. This query can be phrased:
Return devices where
DeviceType == <device type>
Then, for each of those devices, query
Return Network AE where
[ApplicationCluster == name]
The result will be the Network AE entries that match those two criteria. The first criteria selects the device type match. There are LDAP scoping controls that determine whether the queries search the entire enterprise or just this server. LDAP does not support complex queries, transactions, constraints, nesting, etc. LDAP cannot provide the hostnames for these Network AEs as part of a single query. Instead, the returned Network AEs will include the names of the network connections for each Network AE. Then the application would need to issue LDAP reads using the DN of the NetworkConnection objects to obtain the hostnames.
Normal start up of an already configured device will obtain IP information and DICOM information from the servers.
The device start up sequence is:
-
DHCP is used to obtain IP related parameters. The DHCP request can indicate a desired machine name that DHCP can associate with a configuration saved at the DHCP server. DHCP does not guarantee that the desired machine name will be granted because it might already be in use, but this mechanism is often used to maintain specific machine configurations. The DHCP will also update the DNS server (using the DDNS mechanisms) with the assigned IP address and hostname information. Legacy note: A machine with pre-configured IP addresses, DNS servers, and NTP servers may skip this step. As an operational and documentation convenience, the DHCP server database may contain the description of this pre-configured machine.
-
The list of NTP servers is used to initiate the NTP process for obtaining and maintaining the correct time. This is an ongoing process that continues for the duration of device activity. See Time Synchronization below.
-
The list of DNS servers is used to obtain the list of LDAP servers. This utilizes a relatively new addition to the DNS capabilities that permit querying DNS to obtain servers within a domain that provide a particular service.
-
The "nearest" LDAP server is queried to obtain a description for the device matching the assigned machine name. This description includes device specific configuration information and a list of Network AEs.
Note
A partially managed node may reach this point and discover that there is no description for that device in the LDAP database. During installation (as described above) this may then proceed into device configuration. Partially managed devices may utilize an internal configuration mechanism.
-
The AE descriptions are obtained from the LDAP server. Key information in the AE description is the assigned AE Title. The AE descriptions probably include vendor unique information in either the vendor text field or vendor extensions to the AE object. The details of this information are vendor unique. DICOM is defining a mandatory minimum capability because this will be a common need for vendors that offer dynamically configurable devices. The AE description may be present even for devices that do not support dynamic configuration. If the device has been configured with an AE Title and description that is intended to be fixed, then a description should be present in the LDAP database. The device can confirm that the description matches its stored configuration. The presence of the AE Title in the description will prevent later network activities from inadvertently re-using the same AE Title for another
purpose. The degree of configurability may also vary. Many simple devices may only permit dynamic configuration of the IP address and AE Title, with all other configuration requiring local service modifications.
-
The device performs whatever internal operations are involved to configure itself to match the device description and AE descriptions.
At this point, the device is ready for regular operation, the DNS servers will correctly report its IP address when requested, and the LDAP server has a correct description of the device, Network AEs, and network connections.
The lease timeouts eventually release the IP address at DHCP, which can then update DNS to indicate that the host is down. Clients that utilize the hostname information in the LDAP database will initially experience reports of connection failure; and then after DNS is updated, they will get errors indicating the device is down when they attempt to use it. Clients that use the IP entry directly will experience reports of connection failure.
A device may be deliberately placed offline in the LDAP database to indicate that it is unavailable and will remain unavailable for an extended period of time. This may be utilized during system installation so that pre-configured systems can be marked as offline until the system installation is complete. It can also be used for systems that are down for extended maintenance or upgrades. It may be useful for equipment that is on mobile vans and only present for certain days.
For this purpose a separate Installed Attribute has been given to devices, Network AEs, and Network Connections so that it can be manually managed.
Medical device time requirements primarily deal with synchronization of machines on a local network or campus. There are very few requirements for accurate time (synchronized with an international reference clock). DICOM time users are usually concerned with:
-
local time synchronization between machines
-
local time base stability. This means controlling the discontinuities in the local time and its first derivative. There is also an upper bound on time base stability errors that results from the synchronization error limits.
-
international time synchronization with the UTC master clocks
Other master clocks and time references (e.g., sidereal time) are not relevant to medical users.
R.6.1 High Accuracy Time Synchronization
High accuracy time synchronization is needed for devices like cardiology equipment. The measurements taken on various different machines are recorded with synchronization modules specifying the precise time base for measurements such as waveforms and Multi-frame Images. These are later used to synchronize data for analysis and display.
Typical requirements are:
Local synchronization
Synchronized to within approximately 10 millisecond. This corresponds to a few percent of a typical heartbeat. Under some circumstances, the requirements may be stricter than this.
Time base stability
During the measurement period there should be no discontinuities greater than a few milliseconds. The time base rate should be within 0.01% of standard time rate.
International Time Synchronization
There are no special extra requirements. Note however that time base stability conflicts with time synchronization when UTC time jumps (e.g., leap seconds).
R.6.2 Ordinary Time Synchronization
Ordinary medical equipment uses time synchronization to perform functions that were previously performed manually, e.g., record-keeping and scheduling. These were typically done using watches and clocks, with resultant stability and synchronization errors measured in seconds or longer. The most stringent time synchronization requirements for networked medical equipment derive from some of the security protocols and their record keeping.
Ordinary requirements are:
Local synchronization
Synchronized to within approximately 500 milliseconds. Some security systems have problems when the synchronization error exceeds 1 second.
Time base stability
Large drift errors may cause problems. Typical clock drift errors approximately 1 second/day are unlikely to cause problems. Large discontinuities are permissible if rare or during start up. Time may run backwards, but only during rare large discontinuities.
International Time Synchronization
Some sites require synchronization to within a few seconds of UTC. Others have no requirement.
R.6.3.1 Unsynchronized Time
The local system time of a computer is usually provided by two distinct components.
-
There is a battery-powered clock that is used to establish an initial time estimate when the machine is turned on. These clocks are typically very inaccurate. Local and international synchronization errors are often 5-10 minutes. In some cases, the battery clock is incorrect by hours or days.
-
The ongoing system time is provided by a software function and a pulse source. The pulse source "ticks" at some rate between 1-1000Hz. It has a nominal tick rate that is used by the system software. For every tick the system software increments the current time estimate appropriately. E.g., for a system with a 100Hz tick, the system time increments 10ms each tick.
This lacks any external synchronization and is subject to substantial initial error in the time estimate and to errors due to systematic and random drift in the tick source. The tick sources are typically low cost quartz crystal based, with a systematic error up to approximately 10-5 in the actual versus nominal tick rate and with a variation due to temperature, pressure, etc. up to approximately 10-5. This corresponds to drifts on the order of 10 seconds per day.
R.6.3.2 Network Synchronized Time
There is a well established Internet protocol (NTP) for maintaining time synchronization that should be used by DICOM. It operates in several ways.
The most common is for the computer to become an NTP client of one or more NTP servers. As a client it uses occasional ping-pong NTP messages to:
-
Estimate the network delays. These estimates are updated during each NTP update cycle.
-
Obtain a time estimate from the server. Each estimate includes the server's own statistical characteristics and accuracy assessment of the estimate.
-
Use the time estimates from the servers, the network delay estimates, and the time estimates from the local system clock, to obtain a new NTP time estimate. This typically uses modern statistical methods and filtering to perform optimal estimation.
-
Use the resulting time estimate to
-
Adjust the system time, and
-
Update drift and statistical characteristics of the local clock.
The local applications do not normally communicate with the NTP client software. They normally continue to use the system clock services. The NTP client software adjusts the system clock. The NTP standard defines a nominal system clock service as having two adjustable parameters:
-
The clock frequency. In the example above, the nominal clock was 100Hz, with a nominal increment of 10 milliseconds. Long term measurement may indicate that the actual clock is slightly faster and the NTP client can adjust the clock increment to be 9.98 milliseconds.
-
The clock phase. This adjustment permits jump adjustments, and is the fixed time offset between the internal clock and the estimated UTC.
The experience with NTP in the field is that NTP clients on the same LAN as their NTP server will maintain synchronization to within approximately 100 microseconds. NTP clients on the North American Internet and utilizing multiple NTP servers will maintain synchronization to within approximately 10 milliseconds.
There are low cost devices with only limited time synchronization needs. NTP has been updated to include SNTP for these devices. SNTP eliminates the estimation of network delays and eliminates the statistical methods for optimal time estimation. It assumes that the network delays are nil and that each NTP server time estimate received is completely accurate. This reduces the development and hardware costs for these devices. The computer processing costs for NTP are insignificant for a PC, but may be burdensome for very small devices. The SNTP synchronization errors are only a few milliseconds in a LAN environment. They are very topology sensitive and errors may become huge in a WAN environment.
Most NTP servers are in turn NTP clients to multiple superior servers and peers. NTP is designed to accommodate a hierarchy of server/clients that distributes time information from a few international standard clocks out through layers of servers.
The NTP implementations anticipate the use of three major kinds of external clock sources:
External NTP servers
Many ISPs and government agencies offer access to NTP servers that are in turn synchronized with the international standard clocks. This access is usually offered on a restricted basis.
External clock broadcasts
The US, Canada, Germany, and others offer radio broadcasts of time signals that may be used by local receivers attached to an NTP server. The US and Russia broadcast time signals from satellites, e.g., GPS. Some mobile telephone services broadcast time signals. These signals are synchronized with the international standard clocks. GPS time signals are popular worldwide time sources. Their primary problem is difficulties with proper antenna location and receiver cost. Most of the popular low cost consumer GPS systems save money by sacrificing the clock accuracy.
External pulse sources
For extremely high accuracy synchronization, atomic clocks can be attached to NTP servers. These clocks do not provide a time estimate, but they provide a pulse signal that is known to be extremely accurate. The optimal estimation logic can use this in combination with other external sources to achieve sub microsecond synchronization to a reference clock even when the devices are separated by the earth's diameter.
The details regarding selecting an external clock source and appropriate use of the clock source are outside the scope of the NTP protocol. They are often discussed and documented in conjunction with the NTP protocol and many such interfaces are included in the reference implementation of NTP.
In theory, servers can be SNTP servers and NTP servers can be SNTP clients of other servers. This is very strongly discouraged. The SNTP errors can be substantial, and the clients of a server using SNTP will not have the statistical information needed to assess the magnitude of these errors. It is feasible for SNTP clients to use NTP servers. The SNTP protocol packets are identical to the NTP protocol packets. SNTP differs in that some of the statistical information fields are filled with nominal SNTP values instead of having actual measured values.
R.6.5 Implementation Considerations
There are several public reference implementations of NTP server and client software available. These are in widespread use and have been ported to many platforms (including Unix, Windows, and Macintosh). There are also proprietary and built-in NTP services for some platforms (e.g., Windows 2000). The public reference implementations include sample interfaces to many kinds of external clock sources.
There are significant performance considerations in the selection of locations for servers and clients. Devices that need high accuracy synchronization should probably be all on the same LAN together with an NTP server on that LAN.
Real time operating system (RTOS) implementations may have greater difficulties. The reference NTP implementations have been ported to several RTOSs. There were difficulties with the implementations of the internal system clock on the RTOS. The dual frequency/phase adjustment requirements may require the clock functions to be rewritten. The reference implementations also require access to a separate high resolution interval timer (with sub microsecond accuracy and precision). This is a standard CPU feature for modern workstation processors, but may be missing on low end processors.
An RTOS implementation with only ordinary synchronization requirements might choose to write their own SNTP only implementation rather than use the reference NTP implementation. The SNTP client is very simple. It may be based on the reference implementation or written from scratch. The operating system support needed for accurate adjustment is optional for SNTP clients. The only requirement is the time base stability requirement, which usually implies the ability to specify fractional seconds when setting the time.
The conflict between the user desire to use local time and the NTP use of UTC must be resolved in the device. DHCP offers the ability to obtain the offset between local time and UTC dynamically, provided the DHCP server supports this option. There remain issues such as service procedures, start up in the absence of DHCP, etc.
The differences between local time, UTC, summer time, etc. are a common source of confusion and errors setting the battery clock. The NTP algorithms will eventually resolve these errors, but the final convergence on correct time may be significantly delayed. The device might be ready for medical use before these errors are resolved.
S Legacy Transition For Configuration Management (Informative)
There will usually be a period of time where a network will have some applications that utilize the configuration management protocols coexisting with applications that are only manually configured. The transition issues arise when a legacy Association Requester interacts with a managed Association Acceptor or when a managed Association Requester interacts with a legacy Association Acceptor. Some of these issues also arise when the Association Requester and Association Acceptor support different configuration management profiles. These are discussed below and some general recommendations made for techniques that simplify the transition to a fully configuration managed network.
S.1 Legacy Association Requester, Configuration Managed Association Acceptor
The legacy Association Requester requires that the IP address of the Association Acceptor not change dynamically because it lacks the ability to utilize DNS to obtain the current IP address of the Association Acceptor. The legacy Association Requester also requires that the AE Title of the Association Acceptor be provided manually.
The DHCP server should be configurable with a database of hostname, IP, and MAC address relationships. The DHCP server can be configured to provide the same IP address every time that a particular machine requests an IP address. This is a common requirement for Association Acceptors that obtain IP addresses from DHCP. The Association Acceptor may be identified by either the hardware MAC address or the hostname requested by the Association Acceptor.
The IP address can be permanently assigned as a static IP address so that legacy Association Requester can be configured to use that IP address while managed Association Requester can utilize the DNS services to obtain its IP address.
No specific actions are needed, although see below for the potential that the DHCP server does not perform DDNS updates.
Although the managed Association Acceptor may obtain information from the LDAP server, the legacy Association Requester will not. This means that the legacy mechanisms for establishing EYE-Titles and related information on the Association Requester will need to be coordinated manually. Most LDAP products have suitable GUI mechanisms for examining and updating the LDAP database. These are not specified by this Standard.
An LDAP entry for the Association Requester should be manually created, although this may be a very abbreviated entry. It is needed so that the EYE-Title mechanisms can maintain unique AE Titles. There must be entries created for each of the AEs on the legacy Association Requester.
The legacy Association Requester will need to be configured based on manual examination of the LDAP information for the server and using the legacy procedures for that Association Requester.
S.2 Managed Association Requester, Legacy Association Acceptor
The DHCP server may need to be configured with a pre-assigned IP address for the Association Requester if the legacy Association Acceptor restricts access by IP addresses. Otherwise no special actions are needed.
The legacy Association Acceptor hostname and IP address should be manually placed into the DNS database.
The LDAP server should be configured with a full description of the legacy Association Acceptor, even though the Association Acceptor itself cannot provide this information. This will need to be done manually, most likely using GUI tools. The legacy Association Acceptor will need to be manually configured to match the EYE-Titles and other configuration information.
In the event that the DHCP server or DNS server do not support or permit DDNS updates, then the DNS server database will need to be manually configured. Also, because these updates are not occurring, all of the machines should have fixed pre-assigned IP addresses. This is not strictly necessary for clients, since they will not have incoming DICOM connections, but may be needed for other reasons. In practice maintaining this file is very similar to the maintenance of the older hostname files. There is still a significant administrative gain because only the DNS and DHCP configuration files need to be maintained, instead of maintaining files on each of the servers and clients
S.4 Partially Managed Devices
It is likely that some devices will support only some of the system management profiles. A typical example of such partial support is a node that supports:
-
DHCP Client,
-
DNS Client, and
-
NTP Client
Configurations like this are common because many operating system platforms provide complete tools for implementing these clients. The support for LDAP Client requires application support and is often released on a different cycle than the operating system support. These devices will still have their DICOM application manually configured, but will utilize the DHCP, DNS, and NTP services.
S.5 Adding The First Managed Device to A Legacy Network
The addition of the first fully managed device to a legacy network requires both server setup and device setup.
S.5.1 New Servers Required
The managed node requires that servers be installed or assigned to provide the following actors:
-
DHCP Server
-
DNS Server
-
NTP Server
-
LDAP Server
These may be existing servers that need only administrative additions, they may be existing hardware that has new software