PS3.4

DICOM PS3.4 2017a - Service Class Specifications

DICOM Standards Committee


Table of Contents

Notice and Disclaimer
Foreword
1. Scope and Field of Application
2. Normative References
Bibliography
3. Definitions
3.1. Reference Model Definitions
3.2. Service Conventions Definitions
3.3. DICOM Introduction and Overview Definitions
3.4. DICOM Upper Layer Service Definitions
3.5. DICOM Message Exchange Definitions
3.6. DICOM Information Object Definitions
3.7. DICOM Conformance
3.8. DICOM Data Structures and Encoding
3.9. DICOM Service Class Definitions
3.10. Device Independent Pixel Values
3.11. HTTP Definitions
4. Symbols and Abbreviations
5. Conventions
5.1. Entity-Relationship Model
5.1.1. Entity
5.1.2. Relationship
5.2. Sequences
5.3. Response Status Values
5.4. Usage Specification
6. DICOM Information Model
6.1. Information Object Definition
6.1.1. Composite IOD
6.1.2. Normalized IOD
6.2. Attributes
6.3. On-Line Communication and Media Storage Services
6.3.1. DIMSE-C Services
6.3.2. DIMSE-N Services
6.4. DIMSE Service Group
6.5. Service-Object Pair (SOP) Class
6.5.1. Normalized and Composite SOP Classes
6.6. Association Negotiation
6.7. Service Class Specification
7. DICOM Model of the Real World
A. Verification Service Class (Normative)
A.1. Overview
A.1.1. Scope
A.2. SCU/SCP Behavior
A.3. DIMSE-C Service Group
A.4. Verification SOP Class
A.5. Association Negotiation
A.6. Conformance
A.6.1. Conformance Supporting the SCU Role
A.6.2. Conformance Supporting the SCP Role
A.6.3. Conformance Statement
B. Storage Service Class (Normative)
B.1. Overview
B.1.1. Scope
B.1.2. Service Definition
B.2. Behavior
B.2.1. Behavior of an SCU
B.2.2. Behavior of an SCP
B.2.3. Statuses
B.3. Association Negotiation
B.3.1. Extended Negotiation
B.3.1.1. Service-Class-Application-Information (A-ASSOCIATE-RQ)
B.3.1.2. Service-Class-Application-Information (A-ASSOCIATE-AC)
B.3.1.3. Service Class UID (A-ASSOCIATE-RQ)
B.3.1.4. Related General SOP Classes (A-ASSOCIATE-RQ)
B.4. Conformance
B.4.1. Conformance as an SCP
B.4.2. Conformance as an SCU
B.4.2.1. SCU Fall-Back Behavior
B.4.3. Conformance Statement Requirements
B.4.3.1. Conformance Statement for an SCU
B.4.3.2. Conformance Statement for an SCP
B.4.4. Specialized Conformance
B.4.4.1. Specialized SOP Class Identification
B.4.4.2. Specialized Information Object Definition
B.5. Standard SOP Classes
B.5.1. Specialization for Standard SOP Classes
B.5.1.1. Digital X-Ray Image Storage SOP Classes
B.5.1.2. Digital Mammography X-Ray Image Storage SOP Classes
B.5.1.3. Digital Intra-Oral X-Ray Image Storage SOP Classes
B.5.1.4. Softcopy Presentation State Storage SOP Classes
B.5.1.5. Structured Reporting Storage SOP Classes
B.5.1.6. Enhanced MR Image Storage and Legacy Converted Enhanced MR Image Storage SOP Class
B.5.1.7. Enhanced CT Image Storage and Legacy Converted Enhanced CT Image Storage SOP Class
B.5.1.8. Enhanced MR Color Image Storage SOP Class
B.5.1.9. Basic Structured Display
B.5.1.10. Implant Template Storage SOP Classes
B.5.1.11. Ophthalmic Axial Measurements Storage SOP Class
B.5.1.12. IOL Calculation Storage SOP Class
B.5.1.13. Intravascular OCT Image Storage SOP Classes
B.5.1.14. Ophthalmic Thickness Map Storage SOP Class
B.5.1.15. Enhanced PET Image Storage and Legacy Converted Enhanced PET Image Storage SOP Class
B.5.1.16. Enhanced PET Image Storage SOP Classes
B.5.1.17. Corneal Topography Map Storage SOP Class
B.5.1.18. Breast Projection X-Ray Image Storage SOP Classes
B.5.1.19. Planar MPR Volumetric Presentation State Storage SOP Classes
B.5.1.20. Content Assessment Results Storage SOP Classes
B.5.1.21. CT Performed Procedure Protocol Storage SOP Class
B.5.1.22. Raw Data Storage SOP Class
B.6. Retired Standard SOP Classes
C. Query/Retrieve Service Class (Normative)
C.1. Overview
C.1.1. Scope
C.1.2. Conventions
C.1.3. Query/Retrieve Information Model
C.1.4. Service Definition
C.2. Query/Retrieve Information Model Definition
C.2.1. Entity-Relationship Model Definition
C.2.2. Attributes Definition
C.2.2.1. Attribute Types
C.2.2.1.1. Unique Keys
C.2.2.1.2. Required Keys
C.2.2.1.3. Optional Keys
C.2.2.2. Attribute Matching
C.2.2.2.1. Single Value Matching
C.2.2.2.2. List of UID Matching
C.2.2.2.3. Universal Matching
C.2.2.2.4. Wild Card Matching
C.2.2.2.5. Range Matching
C.2.2.2.6. Sequence Matching
C.2.2.3. Matching Multiple Values
C.3. Standard Query/Retrieve Information Models
C.3.1. Patient Root Query/Retrieve Information Model
C.3.2. Study Root Query/Retrieve Information Model
C.3.3. Patient/Study Only Query/Retrieve Information Model
C.3.4. Additional Query/Retrieve Attributes
C.3.5. New Instance Creation for Enhanced Multi-Frame Image Conversion
C.4. DIMSE-C Service Groups
C.4.1. C-FIND Operation
C.4.1.1. C-FIND Service Parameters
C.4.1.1.1. SOP Class UID
C.4.1.1.2. Priority
C.4.1.1.3. Identifier
C.4.1.1.3.1. Request Identifier Structure
C.4.1.1.3.2. Response Identifier Structure
C.4.1.1.4. Status
C.4.1.2. C-FIND SCU Behavior
C.4.1.2.1. Baseline Behavior of SCU
C.4.1.2.2. Extended Behavior of SCU
C.4.1.2.2.1. Relational-Queries
C.4.1.2.2.2. Enhanced Multi-Frame Image Conversion
C.4.1.3. C-FIND SCP Behavior
C.4.1.3.1. Baseline Behavior of SCP
C.4.1.3.1.1. Hierarchical Search Method
C.4.1.3.2. Extended Behavior of SCP
C.4.1.3.2.1. Relational-Queries
C.4.1.3.2.2. Relational Search Method
C.4.1.3.2.3. Enhanced Multi-Frame Image Conversion
C.4.2. C-MOVE Operation
C.4.2.1. C-MOVE Service Parameters
C.4.2.1.1. SOP Class UID
C.4.2.1.2. Priority
C.4.2.1.3. Move Destination
C.4.2.1.4. Identifier
C.4.2.1.4.1. Request Identifier Structure
C.4.2.1.4.2. Response Identifier Structure
C.4.2.1.5. Status
C.4.2.1.6. Number of Remaining Sub-Operations
C.4.2.1.7. Number of Completed Sub-Operations
C.4.2.1.8. Number of Failed Sub-Operations
C.4.2.1.9. Number of Warning Sub-Operations
C.4.2.2. C-MOVE SCU Behavior
C.4.2.2.1. Baseline Behavior of SCU
C.4.2.2.2. Extended Behavior of SCU
C.4.2.2.2.1. Relational-Retrieve
C.4.2.2.2.2. Enhanced Multi-Frame Image Conversion
C.4.2.3. C-MOVE SCP Behavior
C.4.2.3.1. Baseline Behavior of SCP
C.4.2.3.2. Extended Behavior of SCP
C.4.2.3.2.1. Relational-Retrieve
C.4.2.3.2.2. Enhanced Multi-Frame Image Conversion
C.4.3. C-GET Operation
C.4.3.1. C-GET Service Parameters
C.4.3.1.1. SOP Class UID
C.4.3.1.2. Priority
C.4.3.1.3. Identifier
C.4.3.1.3.1. Request Identifier Structure
C.4.3.1.3.2. Response Identifier Structure
C.4.3.1.4. Status
C.4.3.1.5. Number of Remaining Sub-Operations
C.4.3.1.6. Number of Completed Sub-Operations
C.4.3.1.7. Number of Failed Sub-Operations
C.4.3.1.8. Number of Warning Sub-Operations
C.4.3.2. C-GET SCU Behavior
C.4.3.2.1. Baseline Behavior of SCU
C.4.3.2.2. Extended Behavior of SCU
C.4.3.2.2.1. Relational-Retrieve
C.4.3.2.2.2. Enhanced Multi-Frame Image Conversion
C.4.3.3. C-GET SCP Behavior
C.4.3.3.1. Baseline Behavior of SCP
C.4.3.3.2. Extended Behavior of SCP
C.4.3.3.2.1. Relational-Retrieve
C.4.3.3.2.2. Enhanced Multi-Frame Image Conversion
C.5. Association Negotiation
C.5.1. Association Negotiation for C-FIND SOP Classes
C.5.1.1. SOP Class Extended Negotiation
C.5.1.1.1. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)
C.5.1.1.2. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)
C.5.2. Association Negotiation for C-MOVE SOP Classes
C.5.2.1. SOP Class Extended Negotiation
C.5.2.1.1. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)
C.5.2.1.2. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)
C.5.3. Association Negotiation for C-GET SOP Classes
C.5.3.1. SOP Class Extended Negotiation
C.6. SOP Class Definitions
C.6.1. Patient Root SOP Class Group
C.6.1.1. Patient Root Query/Retrieve Information Model
C.6.1.1.1. E/R Model
C.6.1.1.2. Patient Level
C.6.1.1.3. Study Level
C.6.1.1.4. Series Level
C.6.1.1.5. Composite Object Instance Level
C.6.1.1.5.1. Alternate Representation Sequence
C.6.1.1.6. Scope of the C-GET and C-MOVE Commands and Sub-Operations
C.6.1.2. Conformance Requirements
C.6.1.2.1. SCU Conformance
C.6.1.2.1.1. C-FIND SCU Conformance
C.6.1.2.1.2. C-MOVE SCU Conformance
C.6.1.2.1.3. C-GET SCU Conformance
C.6.1.2.2. SCP Conformance
C.6.1.2.2.1. C-FIND SCP Conformance
C.6.1.2.2.2. C-MOVE SCP Conformance
C.6.1.2.2.3. C-GET SCP Conformance
C.6.1.3. SOP Classes
C.6.2. Study Root SOP Class Group
C.6.2.1. Study Root Query/Retrieve Information Model
C.6.2.1.1. E/R Model
C.6.2.1.2. Study Level
C.6.2.1.3. Series Level
C.6.2.1.4. Composite Object Instance Level
C.6.2.1.5. Scope of the Get and Move Commands and Sub-Operations
C.6.2.2. Conformance Requirements
C.6.2.2.1. SCU Conformance
C.6.2.2.1.1. C-FIND SCU Conformance
C.6.2.2.1.2. C-MOVE SCU Conformance
C.6.2.2.1.3. C-GET SCU Conformance
C.6.2.2.2. SCP Conformance
C.6.2.2.2.1. C-FIND SCP Conformance
C.6.2.2.2.2. C-MOVE SCP Conformance
C.6.2.2.2.3. C-GET SCP Conformance
C.6.2.3. SOP Classes
C.6.3. Patient/Study Only SOP Class Group
D. Study Content Notification Service Class (Normative)
E. Patient Management Service Class (Normative)
F. Procedure Step SOP Classes (Normative)
F.1. Overview
F.1.1. Scope
F.1.2. Study Management Functional Model
F.1.3. Study Management Information Model
F.1.4. Study Management States
F.1.5. Modality Performed Procedure Step Management States
F.1.6. General Purpose Scheduled Procedure Step Management States (Retired)
F.1.7. General Purpose Performed Procedure Step Management States (Retired)
F.2. Conformance Overview
F.2.1. Association Negotiation
F.3. Detached Study Management SOP Class(Retired)
F.4. Study Component Management SOP Class(Retired)
F.5. Study Management Meta SOP Class(Retired)
F.6. Specialized SOP Class Conformance(Retired)
F.7. Modality Performed Procedure Step SOP Class
F.7.1. DIMSE Service Group
F.7.2. Operations
F.7.2.1. Create Modality Performed Procedure Step SOP Instance
F.7.2.1.1. Modality Performed Procedure Step Subset Specification
F.7.2.1.2. Service Class User
F.7.2.1.3. Service Class Provider
F.7.2.1.4. Status Codes
F.7.2.2. Set Modality Performed Procedure Step Information
F.7.2.2.1. Modality Performed Procedure Step IOD Subset Specification
F.7.2.2.2. Service Class User
F.7.2.2.3. Service Class Provider
F.7.2.2.4. Status Codes
F.7.3. Modality Performed Procedure Step SOP Class UID
F.7.4. Conformance Requirements
F.7.4.1. SCU Conformance
F.7.4.1.1. Operations
F.7.4.2. SCP Conformance
F.7.4.2.1. Operations
F.8. Modality Performed Procedure Step Retrieve SOP Class
F.8.1. DIMSE Service Group
F.8.2. Operations
F.8.2.1. Get Performed Procedure Step Information
F.8.2.1.1. Modality Performed Procedure Step Retrieve IOD Subset Specifications
F.8.2.1.2. Service Class User
F.8.2.1.3. Service Class Provider
F.8.2.1.4. Status Codes
F.8.3. Modality Performed Procedure Step Retrieve SOP Class UID
F.8.4. Conformance Requirements
F.8.4.1. SCU Conformance
F.8.4.1.1. Operations
F.8.4.2. SCP Conformance
F.8.4.2.1. Operations
F.9. Modality Performed Procedure Step Notification SOP Class
F.9.1. DIMSE Service Group
F.9.2. Notifications
F.9.2.1. Receive Modality Performed Procedure Step Event Notification
F.9.2.2. Provide Modality Performed Procedure Step Event Notification
F.9.2.3. Status Codes
F.9.3. Modality Performed Procedure Step Notification SOP Class UID
F.9.4. Conformance Requirements
F.9.4.1. SCU Conformance
F.9.4.1.1. Notifications
F.9.4.2. SCP Conformance
F.9.4.2.1. Notifications
F.10. General Purpose Scheduled Procedure Step SOP Class (Retired)
F.11. General Purpose Performed Procedure Step SOP Class(Retired)
G. Results Management Service Class (Normative)
H. Print Management Service Class (Normative)
H.1. Scope
H.2. Print Management Model
H.2.1. Print Management Data Flow Model
H.2.1.1. Global Data Flow Model
H.2.1.2. Grayscale Transformations
H.2.1.2.1. Modality and User Specific Transformations
H.2.1.2.2. Polarity
H.2.1.2.3. Presentation LUT
H.2.2. Print Management Service Class Structure
H.2.3. Print Management SOP Classes
H.2.4. Usage Specifications
H.2.5. Status Code Categories
H.3. Print Management Conformance
H.3.1. Scope
H.3.2. Print Management Meta SOP Classes
H.3.2.1. Description
H.3.2.2. Meta SOP Class Definitions
H.3.2.2.1. Basic Grayscale Print Management Meta SOP Class
H.3.2.2.2. Basic Color Print Management Meta SOP Class
H.3.2.2.3. Referenced Grayscale Print Management Meta SOP Class (Retired)
H.3.2.2.4. Referenced Color Print Management Meta SOP Class (Retired)
H.3.2.2.5. Pull Stored Print Management Meta SOP Class(Retired)
H.3.3. Optional SOP Classes
H.3.3.1. Description
H.3.3.2. List of Optional SOP Classes
H.3.4. Conformance Statement
H.4. Print Management SOP Class Definitions
H.4.1. Basic Film Session SOP Class
H.4.1.1. IOD Description
H.4.1.2. DIMSE Service Group
H.4.1.2.1. N-CREATE
H.4.1.2.1.1. Attributes
H.4.1.2.1.2. Status
H.4.1.2.1.3. Behavior
H.4.1.2.2. N-SET
H.4.1.2.2.1. Attributes
H.4.1.2.2.2. Status
H.4.1.2.2.3. Behavior
H.4.1.2.3. N-DELETE
H.4.1.2.3.1. Status
H.4.1.2.3.2. Behavior
H.4.1.2.4. N-ACTION
H.4.1.2.4.1. Attributes
H.4.1.2.4.2. Status
H.4.1.2.4.3. Behavior
H.4.1.3. SOP Class Definition and UID
H.4.2. Basic Film Box SOP Class
H.4.2.1. IOD Description
H.4.2.2. DIMSE Service Group
H.4.2.2.1. N-CREATE
H.4.2.2.1.1. Attributes
H.4.2.2.1.2. Status
H.4.2.2.1.3. Behavior
H.4.2.2.2. N-SET
H.4.2.2.2.1. Attributes
H.4.2.2.2.2. Status
H.4.2.2.2.3. Behavior
H.4.2.2.3. N-DELETE
H.4.2.2.3.1. Behavior
H.4.2.2.4. N-ACTION
H.4.2.2.4.1. Attributes
H.4.2.2.4.2. Status
H.4.2.2.4.3. Behavior
H.4.2.3. SOP Class Definition and UID
H.4.3. Image Box SOP Classes
H.4.3.1. Basic Grayscale Image Box SOP Class
H.4.3.1.1. IOD Description
H.4.3.1.2. DIMSE Service Group
H.4.3.1.2.1. N-SET
H.4.3.1.2.1.1. Attributes
H.4.3.1.2.1.2. Status
H.4.3.1.2.1.3. Behavior
H.4.3.1.3. SOP Class Definition and UID
H.4.3.2. Basic Color Image Box SOP Class
H.4.3.2.1. IOD Description
H.4.3.2.2. DIMSE Service Group
H.4.3.2.2.1. N-SET
H.4.3.2.2.1.1. Attributes
H.4.3.2.2.1.2. Status
H.4.3.2.2.1.3. Behavior
H.4.3.2.3. SOP Class Definition and UID
H.4.3.3. Referenced Image Box SOP Class (Retired)
H.4.4. Basic Annotation Box SOP Class
H.4.4.1. IOD Description
H.4.4.2. DIMSE Service Group
H.4.4.2.1. N-SET
H.4.4.2.1.1. Attributes
H.4.4.2.1.2. Status
H.4.4.2.1.3. Behavior
H.4.4.3. SOP Class Definition and UID
H.4.5. Print Job SOP Class
H.4.5.1. IOD Description
H.4.5.2. DIMSE Service Group
H.4.5.2.1. N-EVENT-REPORT
H.4.5.2.1.1. Attributes
H.4.5.2.1.2. Behavior
H.4.5.2.2. N-GET
H.4.5.2.2.1. Attributes
H.4.5.2.2.2. Behavior
H.4.5.3. Execution Status Information
H.4.5.4. SOP Class Definition and UID
H.4.6. Printer SOP Class
H.4.6.1. IOD Description
H.4.6.2. DIMSE Service Group
H.4.6.2.1. N-EVENT-REPORT
H.4.6.2.1.1. Attributes
H.4.6.2.1.2. Behavior
H.4.6.2.2. N-GET
H.4.6.2.2.1. Attributes
H.4.6.2.2.2. Behavior
H.4.6.3. Printer Status Information
H.4.6.4. SOP Class Definition and UID
H.4.6.5. Reserved Identifications
H.4.7. VOI LUT Box SOP Class(Retired)
H.4.8. Image Overlay Box SOP Class(Retired)
H.4.9. Presentation LUT SOP Class
H.4.9.1. Information Object Description
H.4.9.1.1. Mapping of P-Values to Optical Density
H.4.9.2. DIMSE Service Group
H.4.9.2.1. N-CREATE
H.4.9.2.1.1. Attributes
H.4.9.2.1.1.1. LUT Descriptor
H.4.9.2.1.2. Status
H.4.9.2.1.3. Behavior
H.4.9.2.2. N-DELETE
H.4.9.2.2.1. Status
H.4.9.2.2.2. Behavior
H.4.9.2.4. SOP Class Definition and UID
H.4.10. Pull Print Request SOP Class(Retired)
H.4.11. Printer Configuration Retrieval SOP Class
H.4.11.1. IOD Description
H.4.11.2. DIMSE Service Group
H.4.11.2.2. N-GET
H.4.11.2.2.1. Attributes
H.4.11.2.2.2. Behavior
H.4.11.3. SOP Class Definition and UID
H.4.11.4. Reserved Identifications
H.4.12. Basic Print Image Overlay Box SOP Class(Retired)
H.5. Association Negotiation
H.6. Example of Print Management SCU Session (Informative)
H.6.1. Simple Example
H.6.2. Advanced Example(Retired)
H.7. Example of the Pull Print Request Meta SOP Class (Informative)
H.8. Overlay Examples (Informative)
I. Media Storage Service Class (Normative)
I.1. Overview
I.1.1. Scope
I.1.2. Service Definition
I.2. Behavior
I.2.1. Behavior of an FSC
I.2.2. Behavior of an FSR
I.2.3. Behavior of an FSU
I.3. Conformance
I.3.1. Conformance as an FSC
I.3.2. Conformance as an FSR
I.3.3. Conformance as an FSU
I.3.4. Conformance Statement Requirements
I.3.5. Standard Extended, Specialized, and Private Conformance
I.4. Media Storage Standard SOP Classes
I.4.1. Specialization for Standard SOP Classes
I.4.1.1. Softcopy Presentation State Storage SOP Classes
I.4.1.2. Structured Reporting Storage SOP Classes
I.5. Retired Standard SOP Classes
J. Storage Commitment Service Class (Normative)
J.1. Overview
J.1.1. Scope
J.1.2. Models Overview
J.2. Conformance Overview
J.2.1. Association Negotiation
J.3. Storage Commitment Push Model SOP Class
J.3.1. DIMSE Service Group
J.3.2. Operations
J.3.2.1. Storage Commitment Request
J.3.2.1.1. Action Information
J.3.2.1.1.1. Storage Media File Set ID Attributes
J.3.2.1.1.2. Referenced Performed Procedure Step Sequence Attribute (Retired)
J.3.2.1.1.3. SOP Instance Reference
J.3.2.1.2. Service Class User Behavior
J.3.2.1.3. Service Class Provider Behavior
J.3.2.1.4. Status Codes
J.3.3. Notifications
J.3.3.1. Storage Commitment Result
J.3.3.1.1. Event Information
J.3.3.1.1.1. Retrieve AE Title Attribute
J.3.3.1.1.2. Storage Media File Set ID Attributes
J.3.3.1.2. Service Class Provider Behavior
J.3.3.1.3. Service Class User Behavior
J.3.3.1.4. Status Codes
J.3.4. Storage Commitment Push Model SOP Class UID
J.3.5. Storage Commitment Push Model Reserved Identification
J.3.6. Conformance Requirements
J.3.6.1. SCU Conformance
J.3.6.1.1. Operations
J.3.6.1.2. Notifications.
J.3.6.2. SCP Conformance.
J.3.6.2.1. Operations
J.3.6.2.2. Notifications
J.4. Storage Commitment Pull Model SOP Class(Retired)
J.5. Storage Commitment Examples (Informative)
K. Basic Worklist Management Service (Normative)
K.1. Overview
K.1.1. Scope
K.1.2. Conventions
K.1.3. Worklist Information Model
K.1.4. Service Definition
K.2. Worklist Information Model Definition
K.2.1. Entity-Relationship Model Definition
K.2.2. Attributes Definition
K.2.2.1. Attribute Types
K.2.2.1.1. Matching Key Attributes
K.2.2.1.1.1. Required Matching Key Attributes
K.2.2.1.1.2. Optional Matching Key Attributes
K.2.2.1.2. Return Key Attributes
K.2.2.2. Attribute Matching
K.2.2.3. Matching Multiple Values
K.3. Worklist Information Model
K.4. DIMSE-C Service Group
K.4.1. C-FIND Operation
K.4.1.1. C-FIND Service Parameters
K.4.1.1.1. SOP Class UID
K.4.1.1.2. Priority
K.4.1.1.3. Identifier
K.4.1.1.3.1. Request Identifier Structure
K.4.1.1.3.2. Response Identifier Structure
K.4.1.1.4. Status
K.4.1.2. C-FIND SCU Behavior
K.4.1.3. C-FIND SCP Behavior
K.4.1.3.1. "Worklist" Search Method
K.5. Association Negotiation
K.5.1. SOP Class Extended Negotiation
K.5.1.1. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)
K.5.1.2. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)
K.6. SOP Class Definitions
K.6.1. Modality Worklist SOP Class
K.6.1.1. Modality Worklist SOP Class Overview
K.6.1.2. Modality Worklist Information Model
K.6.1.2.1. E/R Model
K.6.1.2.2. Modality Worklist Attributes
K.6.1.3. Conformance Requirements
K.6.1.3.1. SCU Conformance
K.6.1.3.2. SCP Conformance
K.6.1.4. SOP Class
K.6.2. General Purpose Worklist SOP Class (Retired)
K.7. Examples for the Usage of the Modality Worklist (Informative)
K.8. General Purpose Worklist Example (Informative) (Retired)
L. Queue Management Service Class (Normative)
M. Handling of Identifying Parameters (Informative)
N. Softcopy Presentation State Storage SOP Classes (Normative)
N.1. Overview
N.1.1. Scope
N.2. Pixel Transformation Sequence
N.2.1. Grayscale Transformations
N.2.1.1. Modality LUT
N.2.1.2. Mask
N.2.1.3. VOI LUT
N.2.1.4. Presentation LUT
N.2.2. Color Transformations
N.2.2.1. Profile Connection Space Transformation
N.2.2.2. White Point (Informative)
N.2.3. Common Spatial and Annotation Transformations
N.2.3.1. Shutter
N.2.3.2. Pre-Spatial Transformation Annotation
N.2.3.3. Spatial Transformation
N.2.3.4. Post-Spatial Transformation Annotation
N.2.4. Blending Transformations
N.2.4.1. Underlying Image Pixels
N.2.4.2. Superimposed Image Pixels
N.2.4.3. Blending Operation
N.2.4.4. Conversion to Profile Connection Space
N.2.5. Angiography Grayscale Transformations
N.2.5.1. Mask
N.2.5.2. Edge Enhancement
N.3. Behavior of an SCP
N.4. Conformance
N.4.1. Conformance Statement for an SCU
N.4.2. Conformance Statement for an SCP
O. Structured Reporting Storage SOP Classes (Normative)
O.1. Overview
O.2. Structured Reporting Storage SOP Class SCU and SCP Behavior
O.2.1. Behavior of an SCU
O.2.1.1. CAD SR SOP Classes
O.2.1.2. Extensible SR SOP Class
O.2.2. Behavior of an SCP
O.2.2.1. CAD SR SOP Classes
O.2.2.2. Extensible SR SOP Class
O.3. Modification of SR Document Content
O.4. Conformance
O.4.1. Conformance Statement for an SCU
O.4.1.1. CAD SR SOP Classes
O.4.1.2. Ultrasound SR SOP Classes
O.4.2. Conformance Statement for an SCP
O.4.2.1. CAD SR SOP Classes
O.4.2.2. Extensible SR SOP Class
P. Application Event Logging Service Class (Normative)
P.1. Overview
P.1.1. Scope
P.1.2. Service Definition
P.2. Procedural Event Logging SOP Class Definition
P.2.1. DIMSE Service Group
P.2.2. Operation
P.2.2.1. Action Information
P.2.2.1.1. Study Matching Attributes
P.2.2.1.2. Synchronization Frame of Reference UID
P.2.2.1.3. Constraints on Attributes of the SR Document Content Module
P.2.2.2. Service Class User Behavior
P.2.2.3. Service Class Provider Behavior
P.2.2.4. Status Codes
P.2.2.5. Action Reply
P.2.3. Procedural Event Logging SOP Class UID
P.2.4. Procedural Event Logging Instance Identification
P.2.5. Conformance Requirements
P.2.5.1. SCU Conformance
P.2.5.2. SCP Conformance
P.3. Substance Administration Logging SOP Class Definition
P.3.1. DIMSE Service Group
P.3.2. Operation
P.3.2.1. Substance Administration Log Action Information
P.3.2.2. Service Class User Behavior
P.3.2.3. Service Class Provider Behavior
P.3.2.4. Status Codes
P.3.3. Substance Administration Logging SOP Class UID
P.3.4. Substance Administration Logging Instance UID
P.3.5. Conformance Requirements
P.3.5.1. SCU Conformance
P.3.5.2. SCP Conformance
Q. Relevant Patient Information Query Service Class (Normative)
Q.1. Overview
Q.2. DIMSE-C Service Group
Q.2.1. C-FIND Operation
Q.2.1.1. C-FIND Service Parameters
Q.2.1.1.1. SOP Class UID
Q.2.1.1.2. Priority
Q.2.1.1.3. Identifier
Q.2.1.1.3.1. Request Identifier Structure
Q.2.1.1.3.2. Response Identifier Structure
Q.2.1.1.3.3. Relevant Patient Information Templates
Q.2.1.1.4. Status
Q.3. Association Negotiation
Q.4. DIMSE-C C-FIND Service
Q.4.1. Conventions
Q.4.2. Service Definition
Q.4.3. Relevant Patient Information Model SOP Classes
Q.4.3.1. Relevant Patient Information Model
Q.4.3.1.1. E/R Model
Q.4.3.1.2. Relevant Patient Information Attributes
Q.4.3.1.2.1. Relevant Patient Information Attribute Descriptions
Q.4.3.2. Conformance Requirements
Q.4.3.2.1. SCU Conformance
Q.4.3.2.2. SCP Conformance
Q.4.3.3. SOP Classes
Q.5. Relevant Patient Information Query Example (Informative)
R. Instance Availability Notification Service Class (Normative)
R.1. Overview
R.1.1. Scope
R.2. Conformance Overview
R.3. Instance Availability Notification SOP Class
R.3.1. DIMSE Service Group
R.3.2. Operations
R.3.2.1. N-CREATE Instance Availability Notification SOP Instance
R.3.2.1.1. Attributes
R.3.2.1.2. Service Class User
R.3.2.1.3. Service Class Provider
R.3.2.1.4. Status Codes
R.3.3. Instance Availability Notification SOP Class UID
R.3.4. Conformance Requirements
R.3.4.1. SCU Conformance
R.3.4.1.1. Operations
R.3.4.2. SCP Conformance
R.3.4.2.1. Operations
S. Media Creation Management Service Class (Normative)
S.1. Overview
S.1.1. Scope
S.2. Conformance Overview
S.2.1. Association Negotiation
S.3. Media Creation Management SOP Class
S.3.1. DIMSE Service Group
S.3.2. Operations
S.3.2.1. Create a Media Creation Request
S.3.2.1.1. Attributes
S.3.2.1.1.1. Storage Media File-Set Attributes
S.3.2.1.1.2. Requested Media Application Profile
S.3.2.1.1.3. Icon Image Sequence
S.3.2.1.1.4. Labeling
S.3.2.1.1.5. Media Disposition
S.3.2.1.1.6. Allow Media Splitting
S.3.2.1.1.7. Include Non-DICOM Objects
S.3.2.1.1.8. Include Display Application
S.3.2.1.1.9. Allow Lossy Compression
S.3.2.1.2. Service Class User Behavior
S.3.2.1.3. Service Class Provider Behavior
S.3.2.1.4. Status Codes.
S.3.2.2. Initiate Media Creation
S.3.2.2.1. Action Information
S.3.2.2.1.1. Priority
S.3.2.2.2. Service Class User Behavior
S.3.2.2.3. Service Class Provider Behavior
S.3.2.2.4. Status Codes
S.3.2.3. Cancel Media Creation
S.3.2.3.1. Action Information
S.3.2.3.2. Service Class User Behavior
S.3.2.3.3. Service Class Provider Behavior
S.3.2.3.4. Status Codes
S.3.2.4. Get Media Creation Result
S.3.2.4.1. Attributes
S.3.2.4.2. Service Class User
S.3.2.4.3. Service Class Provider
S.3.2.4.4. Status Codes
S.3.3. Media Creation Management SOP Class UID
S.4. Conformance Requirements
S.4.1. SCU Conformance
S.4.1.1. Operations
S.4.2. SCP Conformance
S.4.2.1. Operations
T. Hanging Protocol Storage Service Class
U. Hanging Protocol Query/Retrieve Service Class
U.1. Overview
U.1.1. Scope
U.1.2. Conventions
U.1.3. Query/Retrieve Information Model
U.1.4. Service Definition
U.2. Hanging Protocol Information Model Definition
U.3. Hanging Protocol Information Model
U.4. DIMSE-C Service Groups
U.4.1. C-FIND Operation
U.4.2. C-MOVE Operation
U.4.3. C-GET Operation
U.5. Association Negotiation
U.6. SOP Class Definitions
U.6.1. Hanging Protocol Information Model
U.6.1.1. E/R Model
U.6.1.2. Hanging Protocol Attributes
U.6.1.3. Conformance Requirements
U.6.1.3.1. SCU Conformance
U.6.1.3.1.1. C-FIND SCU Conformance
U.6.1.3.1.2. C-MOVE SCU Conformance
U.6.1.3.1.3. C-GET SCU Conformance
U.6.1.3.2. SCP Conformance
U.6.1.3.2.1. C-FIND SCP Conformance
U.6.1.3.2.2. C-MOVE SCP Conformance
U.6.1.3.2.3. C-GET SCP Conformance
U.6.1.4. SOP Classes
V. Substance Administration Query Service Class (Normative)
V.1. Overview
V.1.1. Scope
V.1.2. Conventions
V.1.3. Substance Administration Query Information Model
V.1.4. Service Definition
V.2. Substance Administration Query Information Model Definition
V.2.1. Entity-Relationship Model Definition
V.2.2. Attributes Definition
V.2.2.1. Attribute Types
V.2.2.1.1. Matching Key Attributes
V.2.2.1.1.1. Required Matching Key Attributes
V.2.2.1.1.2. Optional Matching Key Attributes
V.2.2.1.2. Return Key Attributes
V.2.2.2. Attribute Matching
V.3. Query Information Models
V.4. DIMSE-C Service Group
V.4.1. C-FIND Operation
V.4.1.1. C-FIND Service Parameters
V.4.1.1.1. SOP Class UID
V.4.1.1.2. Priority
V.4.1.1.3. Identifier
V.4.1.1.3.1. Request Identifier Structure
V.4.1.1.3.2. Response Identifier Structure
V.4.1.1.4. Status
V.4.1.2. C-FIND SCU Behavior
V.4.1.3. C-FIND SCP Behavior
V.4.1.3.1. Query Search Method
V.5. Association Negotiation
V.6. SOP Class Definitions
V.6.1. Product Characteristics Query SOP Class
V.6.1.1. Product Characteristics Query SOP Class Overview
V.6.1.2. Product Characteristics Query Information Model
V.6.1.2.1. E/R Model
V.6.1.2.2. Product Characteristics Query Attributes
V.6.1.3. Conformance Requirements
V.6.1.3.1. SCU Conformance
V.6.1.3.2. SCP Conformance
V.6.1.4. SOP Class
V.6.2. Substance Approval Query SOP Class
V.6.2.1. Substance Approval Query SOP Class Overview
V.6.2.2. Substance Approval Query Information Model
V.6.2.2.1. E/R Model
V.6.2.2.2. Substance Approval Query Attributes
V.6.2.2.3. Substance Approval Query Responses
V.6.2.3. Conformance Requirements
V.6.2.3.1. SCU Conformance
V.6.2.3.2. SCP Conformance
V.6.2.4. SOP Class
W. Color Palette Storage Service Class
X. Color Palette Query/Retrieve Service Class
X.1. Overview
X.1.1. Scope
X.1.2. Conventions
X.1.3. Query/Retrieve Information Model
X.1.4. Service Definition
X.2. Color Palette Information Model Definition
X.3. Color Palette Information Model
X.4. DIMSE-C Service Groups
X.4.1. C-FIND Operation
X.4.2. C-MOVE Operation
X.4.3. C-GET Operation
X.5. Association Negotiation
X.6. SOP Class Definitions
X.6.1. Color Palette Information Model
X.6.1.1. E/R Model
X.6.1.2. Color Palette Attributes
X.6.1.3. Conformance Requirements
X.6.1.3.1. SCU Conformance
X.6.1.3.1.1. C-FIND SCU Conformance
X.6.1.3.1.2. C-MOVE SCU Conformance
X.6.1.3.1.3. C-GET SCU Conformance
X.6.1.3.2. SCP Conformance
X.6.1.3.2.1. C-FIND SCP Conformance
X.6.1.3.2.2. C-MOVE SCP Conformance
X.6.1.3.2.3. C-GET SCP Conformance
X.6.1.4. SOP Classes
Y. Instance and Frame Level Retrieve SOP Classes (Normative)
Y.1. Overview
Y.1.1. Scope
Y.1.2. Composite Instance Root Retrieve Information Model
Y.1.3. Service Definition
Y.2. Composite Instance Root Retrieve Information Model Definition
Y.2.1. Entity-Relationship Model Definition
Y.2.2. Attributes Definition
Y.3. Standard Composite Instance Root Retrieve Information Model
Y.3.1. Composite Instance Root Information Model
Y.3.2. Construction and Interpretation of Frame Range Keys
Y.3.2.1. Frame List definitions
Y.3.2.1.1. Simple Frame List
Y.3.2.1.2. Calculated Frame List
Y.3.2.1.3. Time Range
Y.3.3. New Instance Creation At the Frame Level
Y.4. DIMSE-C Service Groups
Y.4.1. C-MOVE Operation
Y.4.1.1. C-MOVE Service Parameters
Y.4.1.1.1. SOP Class UID
Y.4.1.1.2. Priority
Y.4.1.1.3. Identifier
Y.4.1.1.3.1. Request Identifier Structure
Y.4.1.1.4. Status
Y.4.1.1.5. Number of Remaining Sub-Operations
Y.4.1.1.6. Number of Completed Sub-Operations
Y.4.1.1.7. Number of Failed Sub-Operations
Y.4.1.1.8. Number of Warning Sub-Operations
Y.4.1.2. C-MOVE SCU Behavior
Y.4.1.2.1. Baseline Behavior of SCU
Y.4.1.2.2. Extended Behavior of SCU
Y.4.1.3. C-MOVE SCP Behavior
Y.4.1.3.1. Baseline Behavior of SCP
Y.4.1.3.2. Extended Behavior of SCP
Y.4.2. C-GET Operation
Y.4.2.1. C-GET Service Parameters
Y.4.2.1.1. SOP Class UID
Y.4.2.1.2. Priority
Y.4.2.1.3. Identifier
Y.4.2.1.3.1. Request Identifier Structure
Y.4.2.1.4. Status
Y.4.2.1.5. Number of Remaining Sub-Operations
Y.4.2.1.6. Number of Completed Sub-Operations
Y.4.2.1.7. Number of Failed Sub-Operations
Y.4.2.1.8. Number of Warning Sub-Operations
Y.4.2.2. C-GET SCU Behavior
Y.4.2.2.1. Baseline Behavior of SCU
Y.4.2.2.2. Extended Behavior of SCU
Y.4.2.3. C-GET SCP Behavior
Y.4.2.3.1. Baseline Behavior of SCP
Y.4.2.3.2. Extended Behavior of SCP
Y.5. Association Negotiation
Y.5.1. Association Negotiation for C-MOVE and C-GET SOP Classes
Y.5.1.1. SOP Class Extended Negotiation
Y.5.1.1.1. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)
Y.5.1.1.2. SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)
Y.6. SOP Class Definitions
Y.6.1. Composite Instance Root SOP Class Group
Y.6.1.1. Composite Instance Root Retrieve Only Information Model
Y.6.1.1.1. E/R Model
Y.6.1.1.2. Composite Instance Level
Y.6.1.1.3. Frame Level
Y.6.1.1.4. Scope of the C-MOVE or C-GET Commands and Sub-Operations
Y.6.1.2. Conformance Requirements
Y.6.1.2.1. SCU Conformance
Y.6.1.2.1.1. C-MOVE SCU Conformance
Y.6.1.2.1.2. C-GET SCU Conformance
Y.6.1.2.2. SCP Conformance
Y.6.1.2.2.1. C-MOVE SCP Conformance
Y.6.1.2.2.2. C-GET SCP Conformance
Y.6.1.3. SOP Classes
Z. Composite Instance Retrieve Without Bulk Data SOP Classes (Normative)
Z.1. Overview
Z.1.1. Scope
Z.1.2. Composite Instance Retrieve Without Bulk Data Information Model
Z.1.3. Attributes Not Included
Z.1.4. Service Definition
Z.2. Composite Instance Retrieve Without Bulk Data Information Model Definition
Z.2.1. Entity-Relationship Model Definition
Z.2.2. Attributes Definition
Z.3. Standard Composite Instance Retrieve Without Bulk Data Information Model
Z.3.1. Composite Instance Retrieve Without Bulk Data Information Model
Z.4. DIMSE-C Service Groups
Z.4.1. C-GET Operation
Z.4.2.1. C-GET Service Parameters
Z.4.2.1.1. SOP Class UID
Z.4.2.1.2. Priority
Z.4.2.1.3. Identifier
Z.4.2.1.3.1. Request Identifier Structure
Z.4.2.1.4. Status
Z.4.2.1.5. Number of Remaining Sub-Operations
Z.4.2.1.6. Number of Completed Sub-Operations
Z.4.2.1.7. Number of Failed Sub-Operations
Z.4.2.1.8. Number of Warning Sub-Operations
Z.4.2.2. C-GET SCU and C-STORE SCP Behavior
Z.4.2.2.1. Baseline Behavior of SCU
Z.4.2.2.2. Extended Behavior of SCU
Z.4.2.3. C-GET SCP and C-STORE SCU Behavior
Z.4.2.3.1. Baseline Behavior of SCP
Z.4.2.3.2. Extended Behavior of SCP
Z.5. Association Negotiation
Z.5.1. Association Negotiation for C-GET SOP Classes
Z.6. SOP Class Definitions
Z.6.1. Composite Instance Retrieve Without Bulk Data SOP Class Group
Z.6.1.1. Composite Instance Retrieve Without Bulk Data Information Model
Z.6.1.1.1. E/R Model
Z.6.1.1.2. Composite Instance Level
Z.6.1.1.3. Scope of the C-GET Commands and Sub-Operations
Z.6.1.2. Conformance Requirements
Z.6.1.2.1. SCU Conformance
Z.6.1.2.2. SCP Conformance
Z.6.1.3. SOP Classes
AA. Ophthalmic Refractive Measurements Storage SOP Classes(Normative)
AA.1. Scope
AA.2. Behavior of a SCP
BB. Implant Template Query/Retrieve Service Classes
BB.1. Overview
BB.1.1. Scope
BB.1.2. Conventions
BB.1.3. Query/Retrieve Information Model
BB.1.4. Service Definition
BB.2. Implant Template Information Models Definitions
BB.3. Implant Template Information Models
BB.4. DIMSE-C Service Groups
BB.4.1. C-FIND Operation
BB.4.1.1. Service Class User Behavior
BB.4.1.2. Service Class Provider Behavior
BB.4.2. C-MOVE Operation
BB.4.3. C-GET Operation
BB.5. Association Negotiation
BB.6. SOP Class Definitions
BB.6.1. Implant Template Information Model
BB.6.1.1. E/R Models
BB.6.1.2. Implant Template Attributes
BB.6.1.2.1. Generic Implant Template Attributes
BB.6.1.2.2. Implant Assembly Template Attributes
BB.6.1.2.3. Implant Template Group Attributes
BB.6.1.3. Conformance Requirements
BB.6.1.3.1. SCU Conformance
BB.6.1.3.1.1. C-FIND SCU Conformance
BB.6.1.3.1.2. C-MOVE SCU Conformance
BB.6.1.3.1.3. C-GET SCU Conformance
BB.6.1.3.2. SCP Conformance
BB.6.1.3.2.1. C-FIND SCP Conformance
BB.6.1.3.2.2. C-MOVE SCP Conformance
BB.6.1.3.2.3. C-GET SCP Conformance
BB.6.1.4. SOP Classes
CC. Unified Procedure Step Service and SOP Classes (Normative)
CC.1. Overview
CC.1.1. Unified Procedure Step States
CC.2. DIMSE Service Groups
CC.2.1. Change UPS State (N-ACTION)
CC.2.1.1. Action Information
CC.2.1.2. Service Class User Behavior
CC.2.1.3. Service Class Provider Behavior
CC.2.1.4. Status Codes
CC.2.2. Request UPS Cancel (N-ACTION)
CC.2.2.1. Action Information
CC.2.2.2. Service Class User Behavior
CC.2.2.3. Service Class Provider Behavior
CC.2.2.4. Status Codes
CC.2.3. Subscribe/Unsubscribe to Receive UPS Event Reports (N-ACTION)
CC.2.3.1. Action Information
CC.2.3.2. Service Class User Behavior
CC.2.3.3. Service Class Provider Behavior
CC.2.3.3.1. Filtered Global Subscription
CC.2.3.4. Status Codes
CC.2.4. Report a Change in UPS Status (N-EVENT-REPORT)
CC.2.4.1. Event Report Information
CC.2.4.2. Service Class User Behavior
CC.2.4.3. Service Class Provider Behavior
CC.2.4.4. Status Codes
CC.2.5. Create a Unified Procedure Step (N-CREATE)
CC.2.5.1. Unified Procedure Step Attribute Specification
CC.2.5.1.1. UPS Final State Requirements
CC.2.5.1.2. UPS Macros
CC.2.5.1.3. UPS Attribute Service Requirements
CC.2.5.1.3.1. UPS SOP Class UID
CC.2.5.1.3.2. Unified Procedure Step Performed Procedure Sequence
CC.2.5.2. Service Class User Behavior
CC.2.5.3. Service Class Provider Behavior
CC.2.5.4. Status Codes
CC.2.6. Set Unified Procedure Step Information (N-SET)
CC.2.6.1. Unified Procedure Step IOD Subset Specification
CC.2.6.2. Service Class User Behavior
CC.2.6.3. Service Class Provider Behavior
CC.2.6.4. Status Codes
CC.2.7. Get Unified Procedure Step Information (N-GET)
CC.2.7.1. Unified Procedure Step IOD Subset Specification
CC.2.7.2. Service Class User Behavior
CC.2.7.3. Service Class Provider Behavior
CC.2.7.4. Status Codes
CC.2.8. Search for Unified Procedure Step (C-FIND)
CC.2.8.1. Operation
CC.2.8.1.1. E/R Model
CC.2.8.1.2. C-FIND Service Parameters
CC.2.8.1.2.1. SOP Class UID
CC.2.8.1.2.2. Priority
CC.2.8.1.3. Identifier
CC.2.8.1.3.1. Request Identifier Structure
CC.2.8.1.3.2. Response Identifier Structure
CC.2.8.2. Service Class User Behavior
CC.2.8.3. Service Class Provider Behavior
CC.2.8.3.1. Worklist Search Method
CC.2.8.4. Status Codes
CC.3. UPS SOP Classes
CC.3.1. Service Class and SOP Class UIDs
CC.3.1.1. DIMSE Implications for UPS (Informative)
CC.3.1.2. Global Instance Subscription UID
CC.3.2. Association Negotiation
CC.4. Conformance Requirements
CC.4.1. SCU Conformance
CC.4.1.1. Operations
CC.4.2. SCP Conformance
CC.4.2.1. Operations
DD. RT Machine Verification Service Classes (Normative)
DD.1. Scope
DD.2. RT Machine Verification Model
DD.2.1. RT Machine Verification Data Flow
DD.3. Machine Verification SOP Class Definitions
DD.3.1. IOD Description
DD.3.2. DIMSE Service Group
DD.3.2.1. N-CREATE and N-SET
DD.3.2.1.1. Attributes
DD.3.2.1.1.1. Beam Modifiers
DD.3.2.1.2. Status
DD.3.2.1.3. Behavior
DD.3.2.1.3.1. N-CREATE
DD.3.2.1.3.2. N-SET
DD.3.2.2. N-GET
DD.3.2.2.1Verification. Parameters Selector Attribute Macro
DD.3.2.2.2. Attributes
DD.3.2.2.3. Status
DD.3.2.2.4. Behavior
DD.3.2.3. N-ACTION
DD.3.2.3.1. Attributes
DD.3.2.3.2. Status
DD.3.2.3.3. Behavior
DD.3.2.4. N-DELETE
DD.3.2.4.1. Attributes
DD.3.2.4.2. Status
DD.3.2.4.3. Behavior
DD.3.2.5. N-EVENT-REPORT
DD.3.2.5.1. Attributes
DD.3.2.5.2. Status
DD.3.2.5.3. Behavior
EE. Display System Management Service Class (Normative)
EE.1. Scope
EE.2. Display System SOP Class
EE.2.1. IOD Description
EE.2.2. DIMSE Service Group
EE.2.2.1. N-GET
EE.2.2.1.1. Attributes
EE.2.2.1.1.1. Display Subsystem Macros
EE.2.2.1.1.2. Display System N-GET Attribute Requirements
EE.2.2.1.2. SCU Behavior
EE.2.2.1.3. SCP Behavior
EE.2.3. SOP Class Definitions and UIDs
EE.2.4. Reserved Identifications
EE.3. Conformance
EE.3.1. Conformance Statement
FF. Volumetric Presentation State Storage SOP Classes (Normative)
FF.1. Overview
FF.1.1. Scope
FF.2. Volume Transformation Processes
FF.2.1. Planar MPR Volumetric Transformation Process
FF.2.1.1. Volumetric Inputs, Registration and Cropping
FF.2.1.2. Volumetric Transformations
FF.2.1.2.1. Planar MPR Volumetric Presentation State
FF.2.1.3Volumetric. Presentation State Display
FF.2.1.3.1. Volumetric Presentation State Display Foundation
FF.2.1.3.1.1. Classification Component Components
FF.2.1.3.1.2. Compositor Components
FF.2.1.3.2. Internal Structure of Components
FF.2.1.3.2.1. Internal Structure of Classification Components
FF.2.1.3.2.2. Internal Structure of RGB Compositor Component
FF.3. Additional Volumetric Considerations
FF.3.1. Annotations in Volumetric Presentations States
FF.3.2. Volumetric Animation
FF.3.2.1. Input Sequence Animation
FF.3.2.2. Presentation Sequence Animation
FF.3.2.3. Crosscurve Animation
FF.3.3. Display Layout
FF.4. Behavior of An SCP
FF.5. Conformance
FF.5.1. Conformance Statement For An SCU
FF.5.2. Conformance Statement For An SCP
GG. Non-Patient Object Storage Service Class
GG.1. Overview
GG.1.1. Scope
GG.1.2. Service Definition
GG.2. Association Negotiation
GG.3. SOP Classes
GG.4. Behavior
GG.4.1. Service Class User
GG.4.2. Service Class Provider
GG.5. Conformance Statement Requirements
GG.5.1. SCU Conformance Requirements
GG.5.2. SCP Conformance Requirements
GG.6. Application Behavior for Standard SOP Classes
GG.6.1. Hanging Protocol SOP Class
GG.6.1.1. Instance Creator
GG.6.1.2. Display Application
GG.6.2. Color Palette Storage SOP Class
GG.6.2.1. Instance Creator
GG.6.2.2. Display Application
GG.6.3. Template Storage SOP Classes
GG.6.4. CT Defined Procedure Protocol Storage SOP Class
HH. Defined Procedure Protocol Query/Retrieve Service Classes
HH.1. Overview
HH.1.1. Scope
HH.1.2. Conventions
HH.1.3. Query/Retrieve Information Model
HH.1.4. Service Definition
HH.2. Defined Procedure Protocol Information Models Definitions
HH.3. Defined Procedure Protocol Information Models
HH.4. DIMSE-C Service Groups
HH.4.1. C-FIND Operation
HH.4.1.1. Service Class User Behavior
HH.4.1.2. Service Class Provider Behavior
HH.4.2. C-MOVE Operation
HH.4.3. C-GET Operation
HH.5. Association Negotiation
HH.6. SOP Class Definitions
HH.6.1. Defined Procedure Protocol Information Model
HH.6.1.1. E/R Models
HH.6.1.2. Defined Procedure Protocol Attributes
HH.6.1.3. Conformance Requirements
HH.6.1.3.1. SCU Conformance
HH.6.1.3.1.1. C-FIND SCU Conformance
HH.6.1.3.1.2. C-MOVE SCU Conformance
HH.6.1.3.1.3. C-GET SCU Conformance
HH.6.1.3.2. SCP Conformance
HH.6.1.3.2.1. C-FIND SCP Conformance
HH.6.1.3.2.2. C-MOVE SCP Conformance
HH.6.1.3.2.3. C-GET SCP Conformance
HH.6.1.4. SOP Classes

List of Figures

5-1. Entity Convention
5-2. Relationship Convention
6-1. Major Structures of DICOM Information Model
C.5-1. An Example of the Sub-Operation SCU/SCP Roles
C.5-2. An Example of the Retrieve (C-GET) Negotiation
C.6-1. Patient Root Query/Retrieve Information Model E/R Diagram
C.6-2. Study Root Query/Retrieve Information Model E/R Diagram
H.2-1. Print Management Data Flow Model
H.2-2. Print Management Data Flow Model
H.2-3. Print Management Service Class Structure
H.2-4. Configurations for Printing On Multiple Printers
K.6-1. Modality Worklist Information Model E/R Diagram
N.2-1. Grayscale and Color Image Transformation Models
N.2-2. Common Spatial and Annotation Transformation Model
N.2-3. Grayscale to Color Blending Transformation Model
N.2.5-1. XA/XRF Grayscale Image Transformation Model
Q.4-1. Relevant Patient Information E/R Model
U.6-1. Hanging Protocol Information Model E/R Diagram
V.6-1. Product Characteristics E-R Diagram
V.6-2. Substance Approval E-R Diagram
X.6-1. Color Palette Information Model E/R Diagram
Y.6-1. Composite Instance Root Information Model E/R Diagram
Z.3.1-1. Retrieve Without Bulk Data Information Model E/R Diagram
BB.6-1. Implant Template Information Model E/R Diagram
BB.6-2. Implant Assembly Template Information Model E/R Diagram
BB.6-3. Implant Template Group Information Model E/R Diagram
CC.1.1-1. Unified Procedure Step State Diagram
CC.2.8-1. Unified Procedure Step E-R Diagram
DD.2-1. RT Verification Data Flow
EE.1-1. Display System Management Data Flow
FF.2-1. Grayscale Planar MPR Volumetric Pipeline
FF.2-2. Compositing Planar MPR Volumetric Pipeline
FF.2-3. One Input -> RGBA Component
FF.2-4. Two Inputs ->RGBA Component
FF.2-5. RGB Compositor Component
FF.2-6. Internal Structure of One Input -> RGBA Component
FF.2-7. Internal Structure of Two Input -> RGBA Component
FF.2-8. Internal Structure of RGB Compositor Component
FF.3.2-1. Input Sequence Animation
FF.3.2-2. Presentation Sequence Animation
FF.3.2-3. Crosscurve Animation
HH.6-1. Defined Procedure Protocol Information Model E/R Diagram

List of Tables

B.2-1. C-STORE Status
B.3-1. Service-Class-Application-Information (A-ASSOCIATE-RQ)
B.3-2. Service-Class-Application-Information (A-ASSOCIATE-AC)
B.3-3. Standard and Related General SOP Classes
B.4-1. Attributes Subject to Coercion
B.5-1. Standard SOP Classes
B.6-1. Retired Standard SOP Classes
C.1.2-1. Key Type Conventions for Query/Retrieve Information Models
C.3-1. Additional Query/Retrieve Attributes
C.3.5-1. Modality-Specific SOP Class Conversions
C.4-1. C-FIND Response Status Values
C.4-2. C-MOVE Response Status Values
C.4-3. C-GET Response Status Values
C.5-1. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-RQ
C.5-2. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-AC
C.5-3. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-RQ
C.5-4. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-AC
C.6.1-1. Query/Retrieve Level Values for Patient Root
C.6-1. Patient Level Attributes for the Patient Root Query/Retrieve Information Model
C.6-2. Study Level Keys for the Patient Root Query/Retrieve Information Model
C.6-3. Series Level Attributes for the Patient Root Query/Retrieve Information Model
C.6-4. Composite Object Instance Level Keys for the Patient Root Query/Retrieve Information Model
C.6.1.3-1. SOP Classes for Patient Root Query/Retrieve
C.6.2-1. Query/Retrieve Level Values for Study Root
C.6-5. Study Level Keys for the Study Root Query/Retrieve Information Model
C.6.2.3-1. SOP Classes for Study Root Query/Retrieve
F.1-3. Modality Performed Procedure Step States
F.1-4. Modality Performed Procedure Step State Transition Diagram
F.7.1-1. DIMSE Service Group
F.7.2-1. Modality Performed Procedure Step SOP Class N-CREATE, N-SET and Final State Attributes
F.7.2-2. N-SET Status
F.8.1-1. DIMSE Service Group
F.8.2-1. Modality Performed Procedure Step Retrieve SOP Class N-GET Attributes
F.8.2-2. Response Status
F.9.1-1. DIMSE-N Service Group
F.9.2-1. Performed Procedure Step Notification Event Information
H.3.2.2.1-1. SOP Classes of Basic Grayscale Print Management Meta SOP Class
H.3.2.2.2-1. SOP Classes of Basic Color Print Management Meta SOP Class
H.3.3.2-1. List of Optional SOP Classes for Basic Print Management Meta SOP Classes
H.4-1. DIMSE Service Group
H.4-2. N-CREATE Attribute List
H.4.1.2.1.2-1. Status Values for Basic Film Session SOP Class
H.4-3. N-ACTION Arguments
H.4-4. SOP Class Status Values
H.4-5. DIMSE Service Group
H.4-6. N-CREATE Attribute List
H.4.2.2.1.2-1. Status Values for Basic Film Box SOP Class
H.4-7. N-SET Attributes
H.4-8. N-ACTION Arguments
H.4-9. Status Values
H.4.3.1.2-1. DIMSE Services Applicable to Basic Grayscale Image Box
H.4-10. N-SET Attributes
H.4.3.1.2.1.2-1. Status Values for Basic Grayscale Image Box SOP Class
H.4.3.2.2-1. DIMSE Services Applicable to Basic Color Image Box
H.4-11. N-SET Attributes
H.4.3.2.2.1.2-1. Status Values for Basic Color Image Box SOP Class
H.4.4.2-1. DIMSE Services Applicable to Basic Annotation Box
H.4-13. N-SET Attributes
H.4.5.2-1. DIMSE Services Applicable to Print Job
H.4-14. Notification Event Information
H.4-15. N-GET Attributes
H.4.6.2-1. DIMSE Services Applicable to Printer
H.4-16. Notification Event Information
H.4-17. N-GET Attributes
H.4.9.2-1. DIMSE Services Are Applicable to Presentation LUT
H.4-23. N-CREATE Attribute List
H.4.9.2.1.2-1. Status Values for Presentation LUT SOP Class
H.4.11.2-1. IOD DIMSE Services
H.4-26. N-GET Attributes
I.3-1. Allowed Combinations of Roles
I.4-1. Media Storage Standard SOP Classes
J.3.1-1. IOD DIMSE Services
J.3-1. Storage Commitment Request - Action Information
J.3-2. Storage Commitment Result - Event Information
K.4-1. C-FIND Response Status Values
K.5.1-1. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-RQ
K.5.1-2. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-AC
K.6-1. Attributes for the Modality Worklist Information Model
K.6-1a. Attributes for the Modality Worklist C-FIND Identifier
K.6.1.4-1. Modality Worklist SOP Class
N.2.5.1-1. Summary of Providing a LUT Function for Subtraction
P.2-1. DIMSE Service Group
P.2-2. Procedural Event Logging Action Information
P.2-3. Response Status
P.2-4. Procedural Event Logging Action Reply
P.3-1. DIMSE Service Group
P.3-2. Substance Administration Logging N-ACTION Information
P.3-3. Response Status
Q.2-1. C-FIND Response Status Values
Q.4-1. Attributes for the Relevant Patient Information Model
Q.4-2. Additional C-FIND Identifier Attributes
Q.4-3. SOP Classes for the Relevant Patient Information Model
R.3.1-1. DIMSE Service Group
R.3.2-1. Instance Availability Notification SOP Class N-CREATE Attributes
S.3.1-1. DIMSE-N Services Applicable to Media Creation Management
S.3.2.1.1-1. Media Creation Management - N-CREATE Attributes
S.3.2.2.4-1. SOP Class Status Values
S.3.2.2.1-1. Media Creation Request - Action Information
S.3.2.3.1-1. Media Creation Request - Action Information
S.3.2.3.4-1. Response Statuses
S.3.2.4.1-1. Media Creation Management SOP Class N-GET Attributes
S.3.2.4.4-1. Response Statuses
U.6-1. Attributes for the Hanging Protocol Information Model
U.6.1.4-1. Hanging Protocol SOP Classes
V.4-1. C-FIND Response Status Values
V.6-1. Attributes for the Product Characteristics Query Information Model
V.6.1.4-1. Product Characteristics Query SOP Classes
V.6-2. Attributes for the Substance Approval Query Information Model
V.6.2.4-1. Substance Approval Query SOP Classes
X.6-1. Attributes for the Color Palette Information Model
X.6.1.4-1. Color Palette SOP Classes
Y.4-1. C-MOVE Response Status Values for Instance Root Retrieve
Y.4-2. C-GET Response Status Values for Instance Root Retrieve
Y.5.1-1. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-RQ
Y.5.1-2. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-AC
Y.6.1-1. Retrieve Level Values for Composite Instance Root
Y.6-1. Composite Instance Level Keys for the Composite Instance Root Query/Retrieve Information Model
Y.6-2. Frame Level Keys for the Composite Instance Root Query/Retrieve Information Model
Y.6.1.3-1. SOP Classes for Composite Instance Query/Retrieve Root
Z.1-1. Attributes Not to Be Included in Instances Sent
Z.4-1. C-GET Response Status Values for Instance Root Retrieve
Z.6.1-1. Retrieve Level Value for Retrieve Without Bulk Data
Z.6-1. Composite Instance Level Keys for the Composite Instance Root Query/Retrieve Information Model
Z.6.1.3-1. SOP Classes for Composite Instance Query/Retrieve Root
BB.6-1. Attributes for the Implant Template Information Model
BB.6-2. Attributes for the Implant Assembly Template Information Model
BB.6-3. Attributes for the Implant Template Group Information Model
BB.6.1.4-1. Implant Template SOP Classes
CC.1.1-1. Unified Procedure Step (UPS) States
CC.1.1-2. Unified Procedure Step State Transition Table
CC.2-1. DIMSE Service Group - UPS Push
CC.2-2. DIMSE Service Group - UPS Pull
CC.2-3. DIMSE Service Group - UPS Watch
CC.2-4. DIMSE Service Group - UPS Event
CC.2.1-1. Change UPS State - Action Information
CC.2.1-2. Status Values
CC.2.2-1. Request UPS Cancel - Action Information
CC.2.2-2. Status Values
CC.2.3-1. Subscribe/Unsubscribe to Receive UPS Event Reports - Action Information
CC.2.3-2. UPS Subscription State Transition Table
CC.2.3-3. Status Values
CC.2.4-1. Report a Change in UPS Status - Event Report Information
CC.2.5-1. Final State Codes
CC.2.5-2a. UPS Code Sequence Macro
CC.2.5-2b. UPS Content Item Macro
CC.2.5-2c. Referenced Instances and Access Macro
CC.2.5-2d. HL7V2 Hierarchic Designator Macro
CC.2.5-2e. Issuer of Patient ID Macro
CC.2.5-2f. SOP Instance Reference Macro
CC.2.5-2g. Storage Macro
CC.2.5-3. UPS SOP Class N-CREATE/N-SET/N-GET/C-FIND Attributes
CC.2.5-4. Status Values
CC.2.6-1. Status Values
CC.2.7-1. Status Values
CC.2.8-2. C-FIND Response Status Values
DD.3.2-1. DIMSE Service Group
DD.3.2.1-1. N-CREATE and N-SET Attribute List - RT Conventional Machine Verification SOP Class
DD.3.2.1-2. N-CREATE and N-SET Attribute List - RT Ion Machine Verification SOP Class
DD.3.2.1.2-1. RT Ion Machine Verification SOP Class N-CREATE Status Values
DD.3.2.1.2-2. RT Ion Machine Verification SOP Class N-SET Status Values
DD.3.2.2.1-1. Verification Parameters Selector Attribute Macro
DD.3.2.2.2-1. N-GET Attribute List- RT Conventional Machine Verification SOP Class and RT Ion Machine Verification SOP Class
DD.3.2.2.3-1. RT Conventional Machine and RT Ion Machine Verification SOP Class N-GET Status Values
DD.3.2.3-1. Action Event Information
DD.3.2.3-2. RT Conventional Machine and RT Ion Machine Verification SOP Class N-ACTION Status Values
DD.3.2.5-1. Notification Event Information
EE.2.2-1. DIMSE Service Group - Display System
EE.2.2.1-1. Table Result Context Macro
EE.2.2.1-2. Display System N-GET Attributes
GG.3-1. Standard SOP Classes
GG.4-1. C-STORE Response Status Values
HH.6-1. Attributes for the Defined Procedure Protocol Information Model
HH.6.1.4-1. Defined Procedure Protocol SOP Classes

Notice and Disclaimer

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

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

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

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

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

Foreword

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

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 specifies the set of Service Class Definitions that provide an abstract definition of real-world activities applicable to communication of digital medical information. For each Service Class Definition, this Part specifies:

  • the semantic description of the activities of the Service Class Definition

  • the group of DIMSE Service operations and notifications applicable to the Service Class Description

  • one or more functionally-related Service-Object Pair (SOP) Classes that are supported by the Service Class Definition and may be performed between peer DICOM Application Entities

  • the relationship of each Service-Object Pair (SOP) Classes to applicable Information Object Definitions specified in PS3.3.

For each Service Class Definition, this Part does not specify:

  • any necessary information for the semantic description of the IOD

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

  • Attributes that describe the characteristics of the IOD

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

2 Normative References

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

[ISO/IEC Directives, Part 2] ISO/IEC. 2011/04. 6.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.pdf .

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

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

IETF RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 Reference Model Definitions

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

  1. Application Entity

  2. Service or Layer Service

  3. Application Entity Title

3.2 Service Conventions Definitions

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

  1. Primitive

3.3 DICOM Introduction and Overview Definitions

This Part of the Standard makes use of the following terms defined in PS3.1:

  1. Attribute

  2. Command

  3. Data Dictionary

  4. Information Object

  5. Message

3.4 DICOM Upper Layer Service Definitions

This Part of the Standard makes use of the following terms defined in PS3.8:

  1. Unique Identifier (UID)

  2. DICOM Upper Layer Service

3.5 DICOM Message Exchange Definitions

This Part of the Standard makes use of the following terms defined in PS3.7:

  1. DICOM Message Service Element (DIMSE)

  2. DIMSE-N Services

  3. DIMSE-C Services

  4. DIMSE Service Group (DSG)

3.6 DICOM Information Object Definitions

This Part of the Standard makes use of the following terms defined in PS3.3:

  1. Attribute Tag

  2. Composite IOD

  3. DICOM Application Model

  4. DICOM Information Model

  5. Information Object Definition

  6. Module

  7. Normalized IOD

  8. Functional Group

3.7 DICOM Conformance

This Part of the Standard makes use of the following terms defined in PS3.2:

  1. Standard SOP Class

  2. Specialized SOP Class

  3. Conformance Statement

3.8 DICOM Data Structures and Encoding

This Part of the Standard makes use of the following terms defined in PS3.5:

  1. Data Element

  2. Data Set

3.9 DICOM Service Class Definitions

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

Classic Image Storage SOP Class : an Image Storage SOP Class that is defined by an IOD that stores a single frame and defines the majority of the Attributes in the top-level Data Set.

Combined Print Image : a pixel matrix created by superimposing an image and an overlay, the size of which is defined by the smallest rectangle enclosing the superimposed image and overlay.

DICOM Information Model : an Entity-Relationship diagram that is used to model the relationships between the Information Object Definitions representing classes of Real-World Objects defined by the DICOM Application Model.

DICOM Application Model : an Entity-Relationship diagram used to model the relationships between Real-World Objects that are within the area of interest of the DICOM Standard.

Enhanced Image Storage SOP Class : an Image Storage SOP Class that is defined by an IOD that stores multiple frames and defines the majority of the Attributes in Functional Group Sequences.

Legacy Converted Enhanced Image Storage SOP Class : a modality-specific Enhanced Image Storage SOP Class that is defined by an IOD that defines only generic Functional Group Sequences, which does not require information that is not present in Classic Image Storage SOP Class Instances, and is intended for storage of converted Classic Image Storage SOP Class Instances when there is insufficient information to use a True Enhanced Image Storage SOP Class.

Meta Service-Object Pair (SOP) Class : a pre-defined set of SOP Classes that may be associated under a single SOP for the purpose of negotiating the use of the set with a single item.

Performed Procedure Step SOP Class : any SOP Class that encodes the details about the performance of a procedure step.

Performed Procedure Step SOP Instance : an instance of a Performed Procedure Step SOP Class. Note that all UPS instances are instances of the UPS Push SOP Class, which is capable of encoding details about the performance of a procedure step (in addition to details about the scheduled procedure step) and thus qualify as an instance of a Performed Procedure Step SOP Class.

Preformatted Grayscale Image : an image where all annotation, graphics, and grayscale transformations (up to and including the VOI LUT) expected in the printed image have been burnt in or applied before being sent to the SCP. It is a displayable image where the polarity of the intended display is specified by Photometric Interpretation (0028,0004).

Preformatted Color Image : an image where all annotation, graphics, and color transformations expected in the printed image have been burnt in or applied before being sent to the SCP.

Real-World Activity : that which exists in the real world that pertains to specific area of information processing within the area of interest of the DICOM Standard. Such a Real-World Activity may be represented by one or more computer information metaphors called SOP Classes.

Real-World Object : that which exists in the real world upon which operations may be performed that are within the area of interest of the DICOM Standard. Such a Real-World Object may be represented through a computer information metaphor called a SOP Instance.

Related General SOP Class : a SOP Class that is related to another SOP Class as being more generalized in terms of behavior defined in the standard, and that may be used to identically encode an instance with the same Attributes and values, other than the SOP Class UID. In particular, this may be the SOP Class from which a Specialized SOP Class (see PS3.2) is derived.

Service Class User : the role played by a DICOM Application Entity (DIMSE-Service-User) that invokes operations and performs notifications on a specific Association.

Service Class Provider : the role played by a DICOM Application Entity (DIMSE-Service-User) that performs operations and invokes notifications on a specific Association.

Service Class : a collection of SOP Classes and/or Meta SOP Classes that are related in that they are described together to accomplish a single application.

Service-Object Pair (SOP) Class : the union of a specific set of DIMSE Services and one related Information Object Definition (as specified by a Service Class Definition) that completely defines a precise context for communication of operations on such an object or notifications about its state.

Service-Object Pair (SOP) Instance : a concrete occurrence of an Information Object that is managed by a DICOM Application Entity and may be operated upon in a communication context defined by a specific set of DIMSE Services (on a network or interchange media). A SOP Instance is persistent beyond the context of its communication.

True Enhanced Image Storage SOP Class : a modality-specific Enhanced Image Storage SOP Class that is defined by an IOD that defines modality-specific Functional Group Sequences, Attributes and sets of values, and is intended for creation by acquisition devices.

3.10 Device Independent Pixel Values

This Part of the Standard makes use of the following terms defined in PS3.3:

  1. P-Value

  2. PCS-Value

3.11 HTTP Definitions

This Part of the Standard makes use of the following terms defined in IETF RFC7230:

  1. Origin-Server

  2. User-Agent

4 Symbols and Abbreviations

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

ACR American College of Radiology

ASCII American Standard Code for Information Interchange

AE Application Entity

ANSI American National Standards Institute

CDS Clinical Decision Support

CEN TC251 Comité Européen de Normalisation - Technical Committee 251 - Medical Informatics

Chest CAD Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography

DICOM Digital Imaging and Communications in Medicine

DIMSE DICOM Message Service Element

DIMSE-C DICOM Message Service Element-Composite

DIMSE-N DICOM Message Service Element-Normalized

HL7 Health Level 7

IE Information Entity

IEEE Institute of Electrical and Electronics Engineers

IOD Information Object Definition

IS Information System

ISO International Standards Organization

JIRA Japan Medical Imaging and Radiological Systems Industries Association

JPIP JPEG 2000 Interactive Protocol

MAR Medication Administration Record

NEMA National Electrical Manufacturers Association

OSI Open Systems Interconnection

SCP Service Class Provider

SCU Service Class User

SOP Service-Object Pair

UID Unique Identifier

5 Conventions

5.1 Entity-Relationship Model

5.1.1 Entity

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

Entity Convention

Figure 5-1. Entity Convention


5.1.2 Relationship

A relationship, which defines how entities are related, is depicted as a diamond within this Standard as shown in Figure 5-2.

Relationship Convention

Figure 5-2. Relationship Convention


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

  1. (a = 1, b = 1) -one source entity is related to one destination entity

  2. (a = 1, b = 0-n) -one source entity is related to zero or more destination entities

  3. (a = 1, b = 1-n) -one source entity is related to one or more destination entities

  4. (a = 1-n, b = 1) -one or more source entities are related to one destination entity

  5. (a = 1-n, b = 0-n) -one or more source entities are related to zero or more destination entities

  6. (a = 1-n, b = 1-n) -one or more source entities are related to one or more destination entities

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

Note

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

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

5.2 Sequences

Certain tables in this Part of the DICOM Standard denote a Sequence of Items by using the symbol: '>.'

In Annex A, '>' is used to identify a 'Sequence of Modules.' Nested Sequences of Modules are identified by '>>'. In Annex B and Annex C, '>' is used to identify a 'Sequence of Attributes'. See PS3.5 for the complete specification of how Sequences of Items shall be encoded.

Note

Information Object Definitions (IODs) that include the Sequence of Module construct are often called folders. The use of 'Sequences of Attributes' is not limited to 'Folders.'

5.3 Response Status Values

Certain tables in this Part of the DICOM Standard denote an implementation specific response status code by using the symbol: 'xx' as part of the code.

5.4 Usage Specification

The building blocks of SOP Classes are Modules and DIMSE Services. The DIMSE Services associated with a SOP Class may be Mandatory (M) or Optional (U). The usage may be different for the SCU and SCP. The usage is specified as a pair of letters: the former indicating the SCU usage, the latter indicating the SCP usage.

The meaning and behavior of the usage specification for DIMSE Services are:

M/M

The SCU shall support the DIMSE Service but is not required to use it on an Association. The SCP shall support the DIMSE Service.

U/M

The SCU may support and use the DIMSE Service. The SCP shall support the DIMSE Service.

U/U

The SCU may support and use the DIMSE Service. The SCP may support the DIMSE Service. If the SCP does not support the DIMSE Service used by the SCU, it shall return a Failure status.

Modules and their usage in Composite IODs are defined in PS3.3. Normalized IODs are also constructed from Modules but usage is specified on an Attribute basis in this Part of the DICOM Standard. The following usage specification applies to all Attributes of Normalized IODs unless superseded by a usage specification in a particular SOP Class Specification.

The meaning and behavior of the usage specification for Attributes of Normalized IODs are as follows:

1/1

The SCU shall provide a value for the Attribute. If the SCU does not supply a value, the SCP shall return a Failure status ("Missing Attribute," code 0120H). The SCP shall support the Attribute. The SCP shall not support null values (Attribute provided with a zero length and no value) for the Attribute.

3/1

The SCU may retrieve or provide a value for the Attribute. The SCP shall support the Attribute. The SCP shall not support null values (Attribute provided with a zero length and no value) for the Attribute.

-/1

The SCU's usage of the Attribute is undefined. The SCP shall support the Attribute. The SCP shall not support null values (Attribute provided with a zero length and no value) for the Attribute.

2/2

The SCU shall retrieve or provide a value for the Attribute. The SCU shall always provide the Attribute but a null value shall be permitted (Attribute provided with a zero length and no value). The SCP shall support the Attribute and permit null values (Attribute provided with a zero length and no value) for the Attribute.

3/2

The SCU may retrieve or provide a value for the Attribute. The SCP shall support the Attribute and permit null values (Attribute provided with a zero length and no value) for the Attribute.

-/2

The SCU's usage of the Attribute is undefined. The SCP shall support the Attribute and permit null values (Attribute provided with a zero length and no value) for the Attribute.

3/3

The SCU may retrieve or provide a value for the Attribute. The SCP may support the Attribute. If the SCP does not support the Attribute and it is requested by the SCU, the SCP shall return either a Failure status ("Invalid Attribute Value", code 0106H) or a Warning status ("Attribute Value out of Range", code 0116H). If the SCU provides the Attribute and the SCP does not support the Attribute and returned a failure or warning, the Attribute shall be ignored.

If the SCP usage type designation is modified by a "C" (e.g., 3/1C) the specification stated above shall be modified to include the requirement that the SCP shall support the Attribute if the specified condition is met.

For all N-CREATE, N-SET, N-GET, N-DELETE, N-ACTION and N-EVENT-REPORT operations, the SOP Class is conveyed in the request primitive in Affected SOP Class UID (0000,0002). The SOP Class UID (0008,0016) Attribute shall not be present in the Data Set.

For N-CREATE operations and N-EVENT-REPORT notifications, the SOP Instance is conveyed in Affected SOP Instance UID (0000,1000). The SOP Instance UID (0008,0018) Attribute shall not be present in the Data Set.

Note

In some Service Classes, the SOP Class definition may override the general provision in PS3.7 that allows the SOP Instance UID to be specified or omitted in the N-CREATE request primitive, and require that the SCU be responsible for specifying the SOP Instance UID.

For N-SET, N-GET, N-ACTION and N-DELETE operations, the SOP Instance is conveyed in Requested SOP Instance UID (0000,1001). The SOP Instance UID (0008,0018) Attribute shall not be present in the data set.

6 DICOM Information Model

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

6.1 Information Object Definition

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

Major Structures of DICOM Information Model

Figure 6-1. Major Structures of DICOM Information Model


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

6.1.1 Composite IOD

A Composite IOD is an Information Object Definition that represents parts of several entities in the DICOM Model of the Real-World. (see PS3.3.) Such an IOD includes Attributes that are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.

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

Note

  1. Actual communication of IOD Instances is via SOP Instances.

  2. Whenever Composite SOP Instances are in fact related, some of the contextual information is redundant (i.e., the same information about the same Real-World Objects is contained in multiple SOP Instances).

The Composite IODs are specified in PS3.3.

6.1.2 Normalized IOD

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

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

The Normalized IODs are specified in PS3.3.

6.2 Attributes

The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules that represents a higher level of semantics documented in the Module Specifications found in PS3.3.

Attributes are encoded as Data Elements using the rules, the Value Representation and the Value Multiplicity concepts specified in PS3.5. For specific Data Elements, the Value Representation and Value Multiplicity of Data Elements are specified in the Data Dictionary in PS3.6.

6.3 On-Line Communication and Media Storage Services

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

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

Media Storage Services are discussed in PS3.10.

6.3.1 DIMSE-C Services

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

6.3.2 DIMSE-N Services

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

6.4 DIMSE Service Group

A DIMSE Service Group specifies one or more operations/notifications defined in PS3.7 that are applicable to an IOD.

DIMSE Service Groups are defined in this Part of the DICOM Standard, in the specification of a Service-Object Pair Class.

6.5 Service-Object Pair (SOP) Class

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

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction. This negotiation is performed at Association establishment time as described in PS3.7. An extended negotiation allows Application Entities to further agree on specific options within a SOP Class.

Note

The SOP Class as defined in the DICOM Information Model is equivalent in ISO/OSI terminology to the Managed Object Class. Readers familiar with object oriented terminology will recognize the SOP Class operations (and notifications) as comprising the methods of an object class.

6.5.1 Normalized and Composite SOP Classes

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

Note

SOP Class Specifications play a central role for defining DICOM conformance requirements. It allows DICOM Application Entities to select a well-defined application level subset of this Standard to which they may claim conformance. See PS3.2.

6.6 Association Negotiation

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

Association Negotiation is defined in PS3.7.

6.7 Service Class Specification

A Service Class Specification defines a group of one or more SOP Classes related to a specific function that is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules that allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to network SOP Classes as either a Service Class User (SCU) or Service Class Provider (SCP), and to media exchange SOP Classes as a File Set Creator (FSC), File Set Reader (FSR), or File Set Updater (FSU).

Service Class Specifications are defined in this Part of the DICOM Standard.

Note

Network interaction between peer Application Entities work on a 'client/server model.' The SCU acts as the 'client,' while the SCP acts as the 'server'. The SCU/SCP roles are determined during Association establishment.

7 DICOM Model of the Real World

The DICOM view of the Real-World that identifies the relevant Real-World Objects and their relationships within the scope of the DICOM Standard is described in the DICOM Model of the Real-World Section of PS3.3.

This section also describes the DICOM Information Model that identifies the various IODs specified by the DICOM Standard and their relationship.

A Verification Service Class (Normative)

A.1 Overview

A.1.1 Scope

The Verification Service Class defines a service that verifies application level communication between peer DICOM AEs. This verification is accomplished on an established Association using the C-ECHO DIMSE-C service.

A.2 SCU/SCP Behavior

A DICOM AE, supporting the Verification SOP Class SCU role, requests verification of communication to a remote DICOM AE. This request is performed using the C-ECHO request primitive. The remote DICOM AE, supporting the Verification SOP Class SCP role, issues an C-ECHO response primitive. Upon receipt of the C-ECHO confirmation, the SCU determines that verification is complete. See PS3.7 for the specification of the C-ECHO primitives.

A.3 DIMSE-C Service Group

The C-ECHO DIMSE-C service shall be the mechanism used to verify communications between peer DICOM AEs. The C-ECHO service and protocol parameters shall be required as defined in PS3.7.

A.4 Verification SOP Class

The Verification SOP Class consists of the C-ECHO DIMSE-C service. No associated Information Object Definition is defined. The SOP Class UID shall be "1.2.840.10008.1.1".

No Specialized SOP Classes and/or Meta SOP Classes shall be defined for the Verification SOP Class.

A.5 Association Negotiation

Association establishment is the first phase of any instance of communication between peer DICOM AEs. The following negotiation rules apply to DICOM AEs that support the Verification SOP Class

  • The Association-requester (verification SCU role) in the A-ASSOCIATE request shall convey an Abstract Syntax, in a Presentation Context, for the Verification SOP Class. The Abstract Syntax Name shall be equivalent to the Verification SOP Class UID.

  • The Association-acceptor (verification SCP role) in the A-ASSOCIATE response shall accept the Abstract Syntax, in a Presentation Context, for the supported Verification SOP Class.

No Application Association Information specific to the Verification SOP Class shall be used.

A.6 Conformance

A.6.1 Conformance Supporting the SCU Role

Implementations that conform to the Verification SOP Class SCU role shall meet the:

  • C-ECHO service requirements as defined by the DIMSE Service Group, Section A.3

  • Association negotiation rules as defined in Section A.5

A.6.2 Conformance Supporting the SCP Role

Implementations that conform to the Verification SOP Class SCP role shall meet the:

  • C-ECHO operation rules as defined by the DIMSE Service Group, Section A.3

  • Association negotiation rules as defined in Section A.5

A.6.3 Conformance Statement

An implementation may conform to the Verification SOP Class as an SCU, SCP, or both. The Conformance Statement shall be in the format defined in PS3.2.

B Storage Service Class (Normative)

B.1 Overview

B.1.1 Scope

The Storage Service Class defines an application-level class-of-service that facilitates the simple transfer of information Instances (objects).. It allows one DICOM AE to send images, waveforms, reports, etc., to another.

Information Object Definitions for Instances that are transferred under the Storage Service Class shall adhere to the Composite Instance IOD Information Model specified in PS3.3, and include at least the Patient, Study, and Series Information Entities.

B.1.2 Service Definition

Two peer DICOM AEs implement a SOP Class of the Storage Service Class with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Storage Service Class are implemented using the C-STORE DIMSE-C service. C-STORE is described in PS3.7. A successful completion of the C-STORE has the following semantics:

  • Both the SCU and the SCP support the type of information to be stored.

  • The information is stored in some medium.

  • For some time frame, the information may be accessed.

Note

  1. Support for Storage SOP Classes does not necessarily involve support for SOP Classes of the Query/Retrieve Service Class. How the information may be accessed is implementation dependent. It is required that some access method exists. This method may require an implementation dependent operation at the SCP of the Storage Service Class. The duration of the storage is also implementation dependent, but is described in the Conformance Statement of the SCP. Storage SOP Classes are intended to be used in a variety of environments: e.g., for modalities to transfer images to workstations or archives, for archives to transfer images to workstations or back to modalities, for workstations to transfer processed images to archives, etc.

  2. For the JPIP Referenced Pixel Data transfer syntaxes, transfers may result in storage of incomplete information in that the pixel data may be partially or completely transferred by some other mechanism at the discretion of the SCP.

B.2 Behavior

This Section discusses the SCU and SCP behavior for SOP Classes of the Storage Service Class. The C-STORE DIMSE-C Service shall be the mechanism used to transfer SOP Instances between peer DICOM AEs as described in PS3.7.

B.2.1 Behavior of an SCU

The SCU invokes a C-STORE DIMSE Service with a SOP Instance that meets the requirements of the corresponding IOD. The SCU shall recognize the status of the C-STORE service and take appropriate action upon the success or failure of the service.

Note

The appropriate action is implementation dependent. It is required that the SCU distinguish between successful and failed C-STORE responses. Appropriate action may differ according to application, but are described in the Conformance Statement of the SCU.

B.2.2 Behavior of an SCP

An SCP of a Storage SOP Class acts as a performing DIMSE-service-user for the C-STORE Service. By performing this service successfully, the SCP indicates that the SOP Instance has been successfully stored.

B.2.3 Statuses

Table B.2-1 defines the specific status code values that might be returned in a C-STORE response. General status code values and fields related to status code values are defined in PS3.7.

Table B.2-1. C-STORE Status

Service Status

Further Meaning

Status Codes

Related Fields

Failure

Refused: Out of Resources

A7xx

(0000,0902)

Error: Data Set does not match SOP Class

A9xx

(0000,0901)

(0000,0902)

Error: Cannot understand

Cxxx

(0000,0901)

(0000,0902)

Warning

Coercion of Data Elements

B000

(0000,0901)

(0000,0902)

Data Set does not match SOP Class

B007

(0000,0901)

(0000,0902)

Elements Discarded

B006

(0000,0901)

(0000,0902)

Success

0000

None


B.3 Association Negotiation

SCUs and SCPs of Storage SOP Classes operate on SOP Instances specific to the SOP Class. They may use the SOP Class Extended Negotiation Sub-Item defined in PS3.7. This Sub-Item allows DICOM AEs to exchange application information specific to SOP Class specifications. This is achieved by defining the Service-class-application-information field.

SCUs may use the SOP Class Common Extended Negotiation Sub-Item defined in PS3.7. This Sub-Item allows DICOM AEs to exchange information about the nature of the SOP Classes.

The SOP Class Extended Negotiation Sub-Item and SOP Class Common Extended Negotiation Sub-Item negotiation is optional for storage based SOP Classes.

The following negotiation rules apply to all DICOM SOP Classes and Specialized SOP Classes of the Storage Service Class.

The Association-requester (Storage SCU role) in the A-ASSOCIATE request shall convey:

  • one Abstract Syntax, in a Presentation Context, for each supported SOP Class of the Storage Service Class

  • optionally, one SOP Class Extended Negotiation Sub-Item, for each supported SOP Class of the Storage Service Class

  • optionally, one SOP Class Common Extended Negotiation Sub-Item, for each supported SOP Class of the Storage Service Class

The Association-acceptor (Storage SCP role) in the A-ASSOCIATE request shall accept:

  • one Abstract Syntax, in a Presentation Context, for each supported SOP Class of the Storage Service Class

  • optionally, one SOP Class Extended Negotiation Sub-Item, for each supported SOP Class of the Storage Service Class

B.3.1 Extended Negotiation

At the time of Association establishment implementations may exchange information about their respective capabilities, as described in PS3.7 and PS3.8. SCUs and SCPs may use the SOP Class Extended Negotiation Sub-Item Structure as described in PS3.7 to exchange information about the level of conformance and options supported. SCUs may use the SOP Class Common Extended Negotiation Sub-Item defined in PS3.7 to exchange information about the nature of the SOP Classes.

Extended negotiation is optional. In the event that either the SCU or the SCP does not support extended negotiation, the defaults shall apply.

B.3.1.1 Service-Class-Application-Information (A-ASSOCIATE-RQ)

The SOP Class Extended Negotiation Sub-item is made of a sequence of mandatory fields as defined by PS3.7. Table B.3-1 shows the format of the Service-class-application-information field of the SOP Class Extended Negotiation Sub-Item for SOP Classes of the Storage Service Class in the A-ASSOCIATE-RQ.

Table B.3-1. Service-Class-Application-Information (A-ASSOCIATE-RQ)

Item Bytes

Field Name

Description of Field

1

Level of support

This byte field defines the supported storage level of the Association-requester. It shall be encoded as an unsigned binary integer and shall use one of the following values:

0 - level 0 SCP

1 - level 1 SCP

2 - level 2 SCP

3 - N/A Association-requester is SCU only

If extended negotiation is not supported, the default shall have a value of 3.

2

Reserved

This reserved field shall be sent with a value 00H but not tested to this value when received.

3

Level of Digital Signature support

A Level 2 SCP may further define its behavior in this byte field.

0 - The signature level is unspecified, the AE is an SCU only, or the AE is not a level 2 SCP

1 - signature level 1

2 - signature level 2

3 - signature level 3

If extended negotiation is not supported, the default shall have a value of 0.

4

Reserved

This reserved field shall be sent with a value 00H but not tested to this value when received.

5

Element Coercion

This byte field defines whether the Association-requester may coerce Data Elements. It shall be encoded as an unsigned binary integer and shall use one of the following values:

0 - does not coerce any Data Element

1 - may coerce Data Elements

2 - N/A - Association-requester is SCU only

If extended negotiation is not supported, the default shall have a value of 2.

6

Reserved

This reserved field shall be sent with a value 00H but not tested to this value when received.


B.3.1.2 Service-Class-Application-Information (A-ASSOCIATE-AC)

The SOP Class Extended Negotiation Sub-item is made of a sequence of mandatory fields as defined by PS3.7. Table B.3-2 shows the format of the Service-class-application-information field of the SOP Class Extended Negotiation Sub-Item for SOP Classes of the Storage Service Class in the A-ASSOCIATE-AC.

Table B.3-2. Service-Class-Application-Information (A-ASSOCIATE-AC)

Item Bytes

Field Name

Description of Field

1

Level of support

This byte field defines the supported storage level of the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values:

0 - level 0 SCP

1 - level 1 SCP

2 - level 2 SCP

3 - N/A - Association-acceptor is SCU only

If extended negotiation is not supported, no assumptions shall be made by the Association-requester about the capabilities of the Association-acceptor based upon this extended negotiation.

2

Reserved

This reserved field shall be sent with a value 00H but not tested to this value when received.

3

Level of Digital Signature support

A Level 2 SCP may further define its behavior in this byte field.

0 - The signature level is unspecified, the AE is an SCU only, or the AE is not a level 2 SCP

1 - signature level 1

2 - signature level 2

3 - signature level 3

If extended negotiation is not supported, no assumptions shall be made by the Association-requester about the capabilities of the Association-acceptor based upon this extended negotiation.

4

Reserved

This reserved field shall be sent with a value 00H but not tested to this value when received.

5

Element Coercion

This byte field defines whether the Association-acceptor may coerce Data Elements. It shall be encoded as an unsigned binary integer and shall use one of the following values:

0 - does not coerce any Data Element

1 - may coerce Data Elements

2 - N/A - Association-acceptor is SCU only

If extended negotiation is not supported, no assumptions shall be made by the Association-requester about the capabilities of the Association-acceptor based upon this extended negotiation.

6

Reserved

This reserved field shall be sent with a value 00H but not tested to this value when received.


B.3.1.3 Service Class UID (A-ASSOCIATE-RQ)

SOP Class Common Extended Negotiation Sub-Item allows the SCU to convey the Service Class UID of each proposed SOP Class.

The Storage Service Class UID shall be "1.2.840.10008.4.2".

B.3.1.4 Related General SOP Classes (A-ASSOCIATE-RQ)

A limited set of Standard SOP Classes in the Storage Service Class are defined to have one or more Related General SOP Classes. The Related General SOP Classes may be conveyed using the SOP Class Relationship Extended Negotiation during association establishment as defined in PS3.7. Table B.3-3 identifies which Standard SOP Classes participate in this mechanism. If a Standard SOP Class is not listed in this table, Related General SOP Classes shall not be included in a Related Storage SOP Class Extended Negotiation Sub-Item.

Note

Implementation-defined Specialized SOP Classes (see PS3.2) of the Storage Service Class may convey a Related General SOP Class.

Table B.3-3. Standard and Related General SOP Classes

SOP Class Name

Related General SOP Class Name

12-lead ECG Waveform Storage

General ECG Waveform Storage

Digital Mammography X-Ray Image Storage - For Presentation

Digital X-Ray Image Storage - For Presentation

Digital Mammography X-Ray Image Storage - For Processing

Digital X-Ray Image Storage - For Processing

Digital Intra-Oral X-Ray Image Storage - For Presentation

Digital X-Ray Image Storage - For Presentation

Digital Intra-Oral X-Ray Image Storage - For Processing

Digital X-Ray Image Storage - For Processing

Basic Text SR

Enhanced SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

Enhanced SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

Comprehensive 3D SR

Extensible SR

Procedure Log

Enhanced SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

Simplified Adult Echo SR

Enhanced SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

X-Ray Radiation Dose SR

Enhanced SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

Radiopharmaceutical Radiation Dose SR

Enhanced SR

Comprehensive SR

Comprehensive 3D SR

Extensible SR

Acquisition Context SR

Enhanced SR (see note)

Comprehensive SR (see note)

Comprehensive 3D SR

Extensible SR

Spectacle Prescription Report

Enhanced SR

Macular Grid Thickness and Volume Report

Enhanced SR

Enhanced CT Image Storage

Legacy Converted Enhanced CT Image Storage

Enhanced MR Image Storage

Legacy Converted Enhanced MR Image Storage

Enhanced PET Image Storage

Legacy Converted Enhanced PET Image Storage


Note

The Acquisition Context SR may be encoded as Enhanced or Comprehensive only if it does not contain stereotactic coordinates (SCOORD3D).

B.4 Conformance

An implementation that conforms to Storage SOP Classes shall meet the:

Note

No SCU or SCP behavior requirements other than those in this section are specified. In particular, an SCP of the Storage SOP Classes may not attach any significance to the particular association or associations over which C-STORE operations are requested, nor the order in which C-STORE operations occur within an association. No constraints are placed on the operations an SCU may perform during any particular association, other than those defined during association negotiation. An SCP may not expect an SCU to perform C-STORE operations in a particular order.

Similarly, no semantics are attached to the closing of an Association, such as the end of a Study or Performed Procedure Step.

B.4.1 Conformance as an SCP

Three levels of conformance to the Storage SOP Classes as an SCP may be provided:

  • Level 0 (Local). Level 0 conformance indicates that a user-defined subset of the Attributes of the image will be stored, and all others will be discarded. This subset of the Attributes shall be defined in the Conformance Statement of the implementer.

  • Level 1 (Base). Level 1 conformance indicates that all Type 1 and 2 Attributes defined in the IOD associated with the SOP Class will be stored, and may be accessed. All other elements may be discarded. The SCP may, but is not required to validate that the Attributes of the SOP Instance meets the requirements of the IOD.

  • Level 2 (Full). Level 2 conformance indicates that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition associated with the SOP Class, as well as any Standard Extended Attributes (including Private Attributes) included in the SOP Instance, will be stored and may be accessed. The SCP may, but is not required to validate that the Attributes of the SOP Instance meet the requirements of the IOD.

Note

A Level 2 SCP may discard (not store) Type 3 Attributes that are empty (zero length and no Value), since the meaning of an empty Type 3 Attribute is the same as absence of the Attribute. See PS3.5 definition of "Type 3 Optional Data Elements".

An SCP that claims conformance to Level 2 (Full) support of the Storage Service Class may accept any Presentation Context negotiation of a SOP Class that specifies the Storage Service Class during the SOP Class Common Extended Negotiation, without asserting conformance to that SOP Class in its Conformance Statement.

Note

The SCP may support storage of all SOP Classes of the Storage Service Class, preserving all Attributes as a Level 2 SCP.

An SCP that claims conformance to Level 2 (Full) support of a Related General SOP Class may accept any Presentation Context negotiation of a SOP Class that specifies that Related General SOP Class during the SOP Class Common Extended Negotiation, without asserting conformance to that specialized SOP Class in its Conformance Statement.

Note

  1. The term "specialized" in this section is used generically, including both Implementation-defined Specialized SOP Classes and Standard SOP Classes specified in Table B.3-3.

  2. The SCP may handle instances of such specialized SOP Classes using the semantics of the Related General SOP Class, but preserving all additional (potentially Type 1 or 2) Attributes as a Level 2 SCP.

Level 2 (Full) Storage SCP Conformance is required for support of the Enhanced Multi-Frame Image Conversion Extended Negotiation of the Query/Retrieve Service Class, since effective use of that option requires the storage of Type 3 Attributes. See Section C.3.5 New Instance Creation for Enhanced Multi-frame Image Conversion.

At any level of conformance, the SCP of the Storage Service Class may modify the values of certain Attributes in order to coerce the SOP Instance into the Query Model of the SCP. The Attributes that may be modified are shown in Table B.4-1.

Table B.4-1. Attributes Subject to Coercion

Attribute Name

Tag

Patient ID

(0010,0020)

Study Instance UID

(0020,000D)

Series Instance UID

(0020,000E)


The SCP of the Storage Service Class may modify the values of Code Sequence Attributes to convert from one coding scheme into another. This includes changing from deprecated values of Coding Scheme Designator (0008,0102) or Code Value (0008,0100) to currently valid values.

If an SCP performs such a modification, it shall return a C-STORE response with a status of Warning.

Note

  1. Modification of these Attributes may be necessary if the SCP is also an SCP of a Query/Retrieve SOP Classes. These SOP Classes are described in this Standard. For example, an MR scanner may be implemented to generate Study Instance UIDs for images generated on the MR. When these images are sent to an archive that is HIS/RIS aware, it may choose to change the UID of the study assigned to the study by the PACS. The mechanism by which it performs this coercion is implementation dependent.

  2. An SCP may, for instance, convert Coding Scheme Designator values "SNM3" to "SRT", in accordance with the DICOM conventions for SNOMED (see PS3.16).

  3. Modification of Attributes that may be used to reference a SOP Instance by another SOP Instance (such as Study Instance UID and Series Instance UID Attributes) will make that reference invalid. Modification of these Attributes is strongly discouraged.

  4. Other Attributes may be modified/corrected by an SCP of a Storage SOP Class.

  5. Modification of Attributes may affect digital signatures referencing the content of the SOP Instance.

Three levels of Digital Signature support are defined for an SCP that claims conformance to Level 2 (Full) storage support:

  • Signature Level 1. SCP may not preserve Digital Signatures and does not replace them.

  • Signature Level 2. SCP does not preserve the integrity of incoming Digital Signatures, but does validate the signatures of SOP Instances being stored, takes implementation-specific measures for insuring the integrity of data stored, and will add replacement Digital Signatures before sending SOP Instances elsewhere.

  • Signature Level 3. SCP does preserve the integrity of incoming Digital Signatures (i.e., is bit-preserving and stores and retrieves all Attributes regardless of whether they are defined in the IOD).

B.4.2 Conformance as an SCU

The SCU shall generate only C-STORE requests with SOP Instances that meet the requirements of the IOD associated with the SOP Class.

B.4.2.1 SCU Fall-Back Behavior

During Association Negotiation, an application may propose a specialized SOP Class and its related general SOP Class in separate Presentation Contexts as a Storage SCU. If the Association Acceptor rejects the specialized SOP Class Presentation Context, but accepts the related general SOP Class Presentation Context, the application may send instances of the specialized SOP Class as instances of the related general SOP Class. In this fall-back behavior, the SOP Class UID of the instance shall be the UID of the related general SOP Class, and any special semantics associated with the specialized SOP Class may be lost; the SOP Instance UID shall remain the same.

Note

The SCU may include the SOP Class UID of the original intended specialized SOP Class in the Attribute Original Specialized SOP Class UID (0008,001B) of the instance sent under the related general SOP Class. In some cases, e.g., when all intermediate storage applications are Level 2 SCPs, this may allow an ultimate receiver of the instance to recast it as an instance of the specialized SOP Class IOD. However, this transformation is not guaranteed.

B.4.3 Conformance Statement Requirements

An implementation may conform to a SOP Class of the Storage Service Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.

B.4.3.1 Conformance Statement for an SCU

The following issues shall be documented in the Conformance Statement of any implementation claiming conformance to the Storage SOP Class as an SCU:

  • The behavior of the SCU in the case of a successful C-STORE response status shall be described.

  • The behavior of the SCU in each case of an unsuccessful C-STORE response status shall be described.

  • The behavior of the SCU in the case of a Warning status received in response to a C-STORE operation.

  • Whether extended negotiation is supported.

  • The optional elements that may be included in Storage SOP Instances for each IOD supported shall be listed.

  • The standard and privately defined Functional Groups that may be included in Storage SOP Instances for each Multi-frame IOD that support Functional Groups.

  • The behavior of the SCU in the case of a C-STORE operation using a referenced pixel data transfer syntax such as JPIP Referenced Pixel Data Transfer Syntax shall be described. This includes the duration of validity of the reference

B.4.3.2 Conformance Statement for an SCP

The following issues shall be documented in the Conformance Statement of any implementation claiming conformance to the Storage Service Class as an SCP:

  • The level of conformance, as defined by Section B.4.1, shall be stated.

  • The level of Digital Signature support, as defined by Section B.4.1, shall be stated.

  • The optional elements that will be discarded (if any) shall be listed for each IOD supported.

  • The Conformance Statement shall document the policies concerning the Attribute Lossy Image Compression (0028,2110).

  • The behavior of the SCP in the case of a successful C-STORE operation shall be described. This includes the following:

    • the access method for a stored SOP Instance

    • the duration of the storage

  • The meaning of each case of an unsuccessful C-STORE response status shall be described, as well as appropriate recovery action.

  • The meaning of each case of a warning C-STORE response status shall be described, as well as appropriate action.

  • If the SCP performs coercion on any Attributes, this shall be stated, and the conditions under which it may occur shall be described.

B.4.4 Specialized Conformance

Implementations may provide Specialized SOP Class conformance by providing a proper superset of the SOP Instances to be stored. Implementations providing Specialized SOP Class Conformance to one of the SOP Classes defined in this Annex shall be conformant as described in the following sections and shall include within their Conformance Statement information as described in the following sections.

An implementation shall be permitted to conform as a Specialization of the standard SOP Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.

B.4.4.1 Specialized SOP Class Identification

Any implementation that specializes the standard SOP Class shall define its specialization as an Allomorphic subclass of the standard SOP Class. As such, the specialization shall have its own unique SOP Class identification.

The Conformance Statement shall include a SOP Class Identification Statement as defined in PS3.2, declaring a SOP Name and SOP Class UID that identify the Specialized SOP Class. The SOP Name is not guaranteed to be unique (unless the implementer chooses to copyright it) but is provided for informal identification of the SOP Class. The SOP Class UID shall uniquely identify the Specialized SOP Class and conform to the DICOM UID requirements as specified in PS3.5.

B.4.4.2 Specialized Information Object Definition

The standard SOP Class may be specialized by supporting additional private Attributes. The SCU Operations Statement shall describe these specializations and be formatted as defined in PS3.2. Following this statement shall be the list of Attributes that may be sent or stored with SOP Instances.

B.5 Standard SOP Classes

The SOP Classes in the Storage Service Class identify the Composite IODs to be stored. Table B.5-1 identifies Standard SOP Classes.

Table B.5-1. Standard SOP Classes

SOP Class Name

SOP Class UID

IOD Specification (defined in PS3.3)

Computed Radiography Image Storage

1.2.840.10008.5.1.4.1.1.1

Computed Radiography Image IOD

Digital X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.1

Digital X-Ray Image IOD

(see Section B.5.1.1)

Digital X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.1.1

Digital X-Ray Image IOD

(see Section B.5.1.1)

Digital Mammography X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.2

Digital Mammography X-Ray Image IOD

(see Section B.5.1.2)

Digital Mammography X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.2.1

Digital Mammography X-Ray Image IOD

(see Section B.5.1.2)

Digital Intra-Oral X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.3

Digital Intra-Oral X-Ray Image IOD

(see Section B.5.1.3)

Digital Intra-Oral X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.3.1

Digital Intra-Oral X-Ray Image IOD

(see Section B.5.1.3)

CT Image Storage

1.2.840.10008.5.1.4.1.1.2

Computed Tomography Image IOD

Enhanced CT Image Storage

1.2.840.10008.5.1.4.1.1.2.1

Enhanced CT Image IOD

(see Section B.5.1.7)

Legacy Converted Enhanced CT Image Storage

1.2.840.10008.5.1.4.1.1.2.2

Legacy Converted Enhanced CT Image IOD

(see Section B.5.1.7)

Ultrasound Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.3.1

Ultrasound Multi-frame Image IOD

MR Image Storage

1.2.840.10008.5.1.4.1.1.4

Magnetic Resonance Image IOD

Enhanced MR Image Storage

1.2.840.10008.5.1.4.1.1.4.1

Enhanced MR Image IOD

(see Section B.5.1.6)

MR Spectroscopy Storage

1.2.840.10008.5.1.4.1.1.4.2

MR Spectroscopy IOD

Enhanced MR Color Image Storage

1.2.840.10008.5.1.4.1.1.4.3

Enhanced MR Color Image IOD

Legacy Converted Enhanced MR Image Storage

1.2.840.10008.5.1.4.1.1.4.4

Legacy Converted Enhanced MR Image IOD

(see Section B.5.1.6)

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image IOD

Enhanced US Volume Storage

1.2.840.10008.5.1.4.1.1.6.2

Enhanced US Volume IOD

Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7

Secondary Capture Image IOD

Multi-frame Single Bit Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.1

Multi-frame Single Bit Secondary Capture Image IOD

Multi-frame Grayscale Byte Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.2

Multi-frame Grayscale Byte Secondary Capture Image IOD

Multi-frame Grayscale Word Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.3

Multi-frame Grayscale Word Secondary Capture Image IOD

Multi-frame True Color Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.4

Multi-frame True Color Secondary Capture Image IOD

12-lead ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.1

12-Lead Electrocardiogram IOD

General ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.2

General Electrocardiogram IOD

Ambulatory ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.3

Ambulatory Electrocardiogram IOD

Hemodynamic Waveform Storage

1.2.840.10008.5.1.4.1.1.9.2.1

Hemodynamic IOD

Cardiac Electrophysiology Waveform Storage

1.2.840.10008.5.1.4.1.1.9.3.1

Basic Cardiac Electrophysiology IOD

Basic Voice Audio Waveform Storage

1.2.840.10008.5.1.4.1.1.9.4.1

Basic Voice Audio IOD

General Audio Waveform Storage

1.2.840.10008.5.1.4.1.1.9.4.2

General Audio Waveform IOD

Arterial Pulse Waveform Storage

1.2.840.10008.5.1.4.1.1.9.5.1

Arterial Pulse Waveform IOD

Respiratory Waveform Storage

1.2.840.10008.5.1.4.1.1.9.6.1

Respiratory Waveform IOD

Grayscale Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.1

Grayscale Softcopy Presentation State IOD

Color Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.2

Color Softcopy Presentation State IOD

Pseudo-Color Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.3

Pseudo-color Softcopy Presentation State IOD

Blending Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.4

Blending Softcopy Presentation State IOD

XA/XRF Grayscale Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.5

XA/XRF Grayscale Softcopy Presentation State IOD

Grayscale Planar MPR Volumetric Presentation State Storage

1.2.840.10008.​5.​1.​4.​1.​1.​11.​6

Planar MPR Volumetric Presentation State IOD Description

Compositing Planar MPR Volumetric Presentation State Storage

1.2.840.10008.​5.​1.​4.​1.​1.​11.​7

Planar MPR Volumetric Presentation State IOD Description

X-Ray Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.12.1

X-Ray Angiographic Image IOD

Enhanced XA Image Storage

1.2.840.10008.5.1.4.1.1.12.1.1

Enhanced X-Ray Angiographic Image IOD

X-Ray Radiofluoroscopic Image Storage

1.2.840.10008.5.1.4.1.1.12.2

X-Ray RF Image IOD

Enhanced XRF Image Storage

1.2.840.10008.5.1.4.1.1.12.2.1

Enhanced X-Ray RF Image IOD

X-Ray 3D Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.13.1.1

X-Ray 3D Angiographic Image IOD

X-Ray 3D Craniofacial Image Storage

1.2.840.10008.5.1.4.1.1.13.1.2

X-Ray 3D Craniofacial Image IOD

Breast Tomosynthesis Image Storage

1.2.840.10008.5.1.4.1.1.13.1.3

Breast Tomosynthesis Image IOD

Breast Projection X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.13.1.4

Breast Projection X-Ray Image IOD

Breast Projection X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.13.1.5

Breast Projection X-Ray Image IOD

Intravascular Optical Coherence Tomography Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.14.1

Intravascular OCT IOD

(see Section B.5.1.13)

Intravascular Optical Coherence Tomography Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.14.2

Intravascular OCT IOD

(see Section B.5.1.13)

Nuclear Medicine Image Storage

1.2.840.10008.5.1.4.1.1.20

Nuclear Medicine Image IOD

Parametric Map Storage

1.2.840.10008.5.1.4.1.1.30

Parametric Map IOD

Raw Data Storage

1.2.840.10008.5.1.4.1.1.66

Raw Data IOD

Spatial Registration Storage

1.2.840.10008.5.1.4.1.1.66.1

Spatial Registration IOD

Spatial Fiducials Storage

1.2.840.10008.5.1.4.1.1.66.2

Spatial Fiducials IOD

Deformable Spatial Registration Storage

1.2.840.10008.5.1.4.1.1.66.3

Deformable Spatial Registration IOD

Segmentation Storage

1.2.840.10008.5.1.4.1.1.66.4

Segmentation IOD

Surface Segmentation Storage

1.2.840.10008.5.1.4.1.1.66.5

Surface Segmentation IOD

Tractography Results Storage

1.2.840.10008.5.1.4.1.1.66.6

Tractography Results IOD

Real World Value Mapping Storage

1.2.840.10008.5.1.4.1.1.67

Real World Value Mapping IOD

Surface Scan Mesh Storage

1.2.840.10008.5.1.4.1.1.68.1

Surface Scan Mesh IOD

Surface Scan Point Cloud Storage

1.2.840.10008.5.1.4.1.1.68.2

Surface Scan Point Cloud IOD

VL Endoscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.1

VL Endoscopic Image IOD

Video Endoscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.1.1

Video Endoscopic Image IOD

VL Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.2

VL Microscopic Image IOD

Video Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.2.1

Video Microscopic Image IOD

VL Slide-Coordinates Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.3

VL Slide-Coordinates Microscopic Image IOD

VL Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4

VL Photographic Image IOD

Video Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4.1

Video Photographic Image IOD

Ophthalmic Photography 8 Bit Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.1

Ophthalmic Photography 8 Bit Image IOD

Ophthalmic Photography 16 Bit Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.2

Ophthalmic Photography 16 Bit Image IOD

Stereometric Relationship Storage

1.2.840.10008.5.1.4.1.1.77.1.5.3

Stereometric Relationship IOD

Ophthalmic Tomography Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.4

Ophthalmic Tomography Image IOD

Wide Field Ophthalmic Photography Stereographic Projection Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.5

Wide Field Ophthalmic Photography Stereographic Projection Image IOD

Wide Field Ophthalmic Photography 3D Coordinates Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.6

Wide Field Ophthalmic Photography 3D Coordinates Image IOD

VL Whole Slide Microscopy Image Storage

1.2.840.10008.5.1.4.1.1.77.1.6

VL Whole Slide Microscopy Image IOD

Lensometry Measurements Storage

1.2.840.10008.5.1.4.1.1.78.1

Lensometry Measurements IOD

Autorefraction Measurements Storage

1.2.840.10008.5.1.4.1.1.78.2

Autorefraction Measurements IOD

Keratometry Measurements Storage

1.2.840.10008.5.1.4.1.1.78.3

Keratometry Measurements IOD

Subjective Refraction Measurements Storage

1.2.840.10008.5.1.4.1.1.78.4

Subjective Refraction Measurements IOD

Visual Acuity Measurements Storage

1.2.840.10008.5.1.4.1.1.78.5

Visual Acuity Measurements IOD

Spectacle Prescription Report Storage

1.2.840.10008.5.1.4.1.1.78.6

Spectacle Prescription Report IOD

Ophthalmic Axial Measurements Storage

1.2.840.10008.5.1.4.1.1.78.7

Ophthalmic Axial Measurements IOD

Intraocular Lens Calculations Storage

1.2.840.10008.5.1.4.1.1.78.8

Intraocular Lens Calculations IOD

Macular Grid Thickness and Volume Report

1.2.840.10008.5.1.4.1.1.79.1

Macular Grid Thickness and Volume Report IOD

Ophthalmic Visual Field Static Perimetry Measurements Storage

1.2.840.10008.5.1.4.1.1.80.1

Ophthalmic Visual Field Static Perimetry Measurements IOD

Ophthalmic Thickness Map Storage

1.2.840.10008.5.1.4.1.1.81.1

Ophthalmic Thickness Map IOD

Corneal Topography Map Storage

1.2.840.10008.5.1.4.1.1.82.1

Corneal Topography Map IOD

Basic Text SR Storage

1.2.840.10008.5.1.4.1.1.88.11

Basic Text SR IOD

Enhanced SR Storage

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR IOD

Comprehensive SR Storage

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR IOD

Comprehensive 3D SR Storage

1.2.840.10008.5.1.4.1.1.88.34

Comprehensive 3D SR IOD

Extensible SR Storage

1.2.840.10008.5.1.4.1.1.88.35

Extensible SR IOD

Procedure Log Storage

1.2.840.10008.5.1.4.1.1.88.40

Procedure Log IOD

Mammography CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.50

Mammography CAD SR IOD

Key Object Selection Storage

1.2.840.10008.5.1.4.1.1.88.59

Key Object Selection Document IOD

Chest CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.65

Chest CAD SR IOD

X-Ray Radiation Dose SR Storage

1.2.840.10008.5.1.4.1.1.88.67

X-Ray Radiation Dose SR IOD

Radiopharmaceutical Radiation Dose SR Storage

1.2.840.10008.5.1.4.1.1.88.68

Radiopharmaceutical Radiation Dose SR IOD

Colon CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.69

Colon CAD SR IOD

Implantation Plan SR Document Storage

1.2.840.10008.5.1.4.1.1.88.70

Implantation Plan SR Document IOD

Acquisition Context SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​71

Acquisition Context SR IOD

Simplified Adult Echo SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​72

Simplified Adult Echo SR IOD

Content Assessment Results Storage

1.2.840.10008.5.1.4.1.1.90.1

Content Assessment Results IOD

Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

Encapsulated PDF IOD

Encapsulated CDA Storage

1.2.840.10008.5.1.4.1.1.104.2

Encapsulated CDA IOD

Positron Emission Tomography Image Storage

1.2.840.10008.5.1.4.1.1.128

Positron Emission Tomography Image IOD

Enhanced PET Image Storage

1.2.840.10008.5.1.4.1.1.130

Enhanced PET Image IOD

(see Section B.5.1.16)

Legacy Converted Enhanced PET Image Storage

1.2.840.10008.5.1.4.1.1.128.1

Legacy Converted Enhanced PET Image IOD

Basic Structured Display Storage

1.2.840.10008.5.1.4.1.1.131

Basic Structured Display IOD

CT Performed Procedure Protocol Storage

1.2.840.10008.5.1.4.1.1.200.2

CT Performed Procedure Protocol IOD

RT Image Storage

1.2.840.10008.5.1.4.1.1.481.1

RT Image IOD

RT Dose Storage

1.2.840.10008.5.1.4.1.1.481.2

RT Dose IOD

RT Structure Set Storage

1.2.840.10008.5.1.4.1.1.481.3

RT Structure Set IOD

RT Beams Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.4

RT Beams Treatment Record IOD

RT Plan Storage

1.2.840.10008.5.1.4.1.1.481.5

RT Plan IOD

RT Brachy Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.6

RT Brachy Treatment Record IOD

RT Treatment Summary Record Storage

1.2.840.10008.5.1.4.1.1.481.7

RT Treatment Summary Record IOD

RT Ion Plan Storage

1.2.840.10008.5.1.4.1.1.481.8

RT Ion Plan IOD

RT Ion Beams Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.9

RT Ion Beams Treatment Record IOD

RT Beams Delivery Instruction Storage

1.2.840.10008.5.1.4.34.7

RT Beams Delivery Instruction IOD

RT Brachy Application Setup Delivery Instruction Storage

1.2.840.10008.5.1.4.34.10

RT Brachy Application Setup Delivery Instruction IOD


Note

The Generic Implant Template Storage, Implant Assembly Template Storage, and Implant Template Group Storage SOP Classes were formerly specified in this table, incorrectly since they do not use the Patient / Study / Series / Instance information model. Those have been consolidated into the Non-Patient Object Storage Service Class (see Annex GG).

B.5.1 Specialization for Standard SOP Classes

B.5.1.1 Digital X-Ray Image Storage SOP Classes

The Digital X-Ray Image Storage - For Presentation SOP Class shall use the DX IOD with an Enumerated Value of FOR PRESENTATION for Presentation Intent Type (0008,0068).

The Digital X-Ray Image Storage - For Processing SOP Class shall use the DX IOD with an Enumerated Value of FOR PROCESSING for Presentation Intent Type (0008,0068).

An SCU or SCP of the Digital X-Ray Image Storage - For Processing SOP Class shall also support the Digital X-Ray Image Storage - For Presentation SOP Class.

Note

  1. The intent of this requirement is to ensure a useful level of interoperability by avoiding the situation where an SCU might support only the Digital X-Ray Image Storage - For Processing SOP Class and an SCP only the Digital X-Ray Image Storage - For Presentation SOP Class, or vice versa. The burden is therefore to support the Digital X-Ray Image Storage - For Presentation SOP Class as a "baseline".

  2. The term "support" is used in this section in the sense that an SCU or SCP must be capable of sending or receiving the For Presentation SOP Class. There is no intent to imply that an SCU must always send an instance of the For Presentation SOP Class when an instance of the For Processing SOP Class is sent.

    Nor is there any intent to imply that during Association establishment, that a Presentation Context for the For Presentation SOP Class has to be proposed by the initiator. However, an association acceptor may reject a For Presentation SOP Class Presentation Context if it accepts a For Processing SOP Class Presentation Context, and prefers that SOP Class, in which case it may no longer be able to "pass on" the object later as an SCU unless it is able to generate a For Presentation object.

    It is not possible for an SCP to determine from proposed Presentation Contexts whether or not an SCU "supports" (is capable of sending) both For Processing and For Presentation SOP Class Instances. Such a determination requires a priori knowledge of the information contained in the Conformance Statement for the SCU, as well as how the SCU is configured and operated. An SCU that supports both SOP Classes may well choose to only propose one or the other during Association establishment, depending on which Instances it actually intends to send over that particular association (although the SCU must be capable of sending instances of the For Presentation SOP Class if the SCP does not accept the For Processing).

    The intent of the requirement is that if an SCU is only capable of sending the For Presentation SOP Class, any SCP will be guaranteed to be able to receive it. Conversely, if an SCP is only capable of receiving the For Presentation SOP Class, any SCU will be guaranteed to be able to send it.

B.5.1.2 Digital Mammography X-Ray Image Storage SOP Classes

The Digital Mammography X-Ray Image Storage - For Presentation SOP Class shall use the Digital Mammography IOD with an Enumerated Value of FOR PRESENTATION for Presentation Intent Type (0008,0068).

The Digital Mammography X-Ray Image Storage - For Processing SOP Class shall use the Digital Mammography IOD with an Enumerated Value of FOR PROCESSING for Presentation Intent Type (0008,0068).

An SCU or SCP of the Digital Mammography X-Ray Image Storage - For Processing SOP Class shall also support the Digital Mammography X-Ray Image Storage - For Presentation SOP Class.

B.5.1.3 Digital Intra-Oral X-Ray Image Storage SOP Classes

The Digital Intra-Oral X-Ray Image Storage - For Presentation SOP Class shall use the Digital Intra-Oral X-Ray IOD with an Enumerated Value of FOR PRESENTATION for Presentation Intent Type (0008,0068).

The Digital Intra-Oral X-Ray Image Storage - For Processing SOP Class shall use the Digital Intra-Oral X-Ray IOD with an Enumerated Value of FOR PROCESSING for Presentation Intent Type (0008,0068).

An SCU or SCP of the Digital Intra-Oral X-Ray Image Storage - For Processing SOP Class shall also support the Digital Intra-Oral X-Ray Image Storage - For Presentation SOP Class.

B.5.1.4 Softcopy Presentation State Storage SOP Classes

See Annex N.

B.5.1.5 Structured Reporting Storage SOP Classes

The requirements of Annex O apply to the following SOP Classes:

  • Basic Text SR

  • Extensible SR, Enhanced SR, and SOP Classes for which it is the Related General SOP Class

  • Comprehensive 3D SR, Comprehensive SR, and SOP Classes for which they are the Related General SOP Classes

  • Mammography CAD SR

  • Chest CAD SR

  • Procedure Log

  • X-Ray Radiation Dose SR

  • Radiopharmaceutical Radiation Dose SR

  • Spectacle Prescription Report

  • Colon CAD SR

  • Macular Grid Thickness and Volume Report

  • Implantation Plan SR Document

  • Acquisition Context SR

  • Simplified Adult Echo SR

Annex O requirements do not apply to the Key Object Selection Document SOP Class.

B.5.1.6 Enhanced MR Image Storage and Legacy Converted Enhanced MR Image Storage SOP Class

An SCP of the Enhanced MR Image Storage or Legacy Converted Enhanced MR Image Storage SOP Class shall also support the Grayscale Softcopy Presentation State Storage SOP Class.

Note

This requirement is present in order to allow the exchange of graphical annotations created by an acquisition or conversion device.

B.5.1.7 Enhanced CT Image Storage and Legacy Converted Enhanced CT Image Storage SOP Class

An SCP of the Enhanced CT Image Storage or Legacy Converted Enhanced CT Image Storage SOP Class shall also support the Grayscale Softcopy Presentation State Storage SOP Class.

Note

This requirement is present in order to allow the exchange of graphical annotations created by an acquisition or conversion device.

B.5.1.8 Enhanced MR Color Image Storage SOP Class

An SCP of the Enhanced MR Color Image Storage SOP Class shall also support the Color Softcopy Presentation State Storage SOP Class.

Note

This requirement is present in order to allow the exchange of graphical annotations created by an acquisition device.

B.5.1.9 Basic Structured Display

An SCU of the Basic Structured Display Storage SOP Class that creates SOP Instances of the Class shall identify in its Conformance Statement the Composite Storage SOP Classes and Softcopy Presentation State Storage SOP Classes that are also supported by the SCU, and may be referenced by Basic Structured Display SOP Instances it creates. It shall identify in its Conformance Statement the values it may use in the Attributes Image Box Layout Type (0072,0304) and Type of Synchronization (0072,0434).

An SCP of the Basic Structured Display Storage SOP Class, when rendering SOP Instances of the Class, shall preserve the aspect ratio specified by the Nominal Screen Definition Sequence (0072,0102) Attributes Number of Vertical Pixels (0072,0104) and Number of Horizontal Pixels (0072,0106) without clipping.

Note

  1. The SCP is not required to display using the exact number of vertical and horizontal pixels. The SCP may use as much of its display screen as it desires, while maintaining the Structured Display aspect ratio.

  2. If the display screen has a different aspect ratio, the positioning of the display on the screen is unspecified (centered, left or right justified, top or bottom justified).

An SCP of the Basic Structured Display Storage SOP Class that is capable of rendering SOP Instances of the Class shall identify in its Conformance Statement the Composite Storage SOP Classes and Softcopy Presentation State Storage SOP Classes that are also supported by the SCP, and will be rendered when referenced by Basic Structured Display SOP Instances for display. It shall specify in its Conformance Statement the user display controls and interactions for the values of Image Box Layout Type (0072,0304) and Type of Synchronization (0072,0434) that it supports. It shall identify in its Conformance Statement its behavior when encountering a referenced Presentation State or other Composite Storage SOP Instance whose display it does not support, or an unsupported value of Image Box Layout Type or Type of Synchronization; such behavior shall include at a minimum a display to the user of the nature of the incompatibility.

B.5.1.10 Implant Template Storage SOP Classes

See Annex GG.

Note

The requirements of this section have been consolidated into the Non-Patient Object Storage Service Class (see Section GG.6.3).

B.5.1.11 Ophthalmic Axial Measurements Storage SOP Class

Ophthalmic axial measurements devices are used in the preoperative assessment of every cataract surgery patient. Ophthalmic axial measurements SOP Classes support ophthalmic axial measurements devices.

For a device that is both a SCU and a SCP of the Ophthalmic Axial Measurements Storage SOP Class, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for Ophthalmic Axial Measurements Storage SOP Classes:

  • A SCP of this SOP Class shall support Level 2 Conformance as defined in Section B.4.1.

Note

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

B.5.1.12 IOL Calculation Storage SOP Class

IOL (intraocular lens) calculation is used in the preoperative assessment of every cataract surgery patient. IOL Calculation SOP Classes support IOL calculation software, which may be located either on ophthalmic axial measurement devices or on a separate computer.

For a device that is both a SCU and a SCP of the IOL Calculation Storage SOP Class, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for IOL Calculation Storage SOP Classes:

  • A SCP of this SOP Class shall support Level 2 Conformance as defined in Section B.4.1.

Note

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

B.5.1.13 Intravascular OCT Image Storage SOP Classes

The Intravascular OCT Image Storage - For Presentation SOP Class shall use the IVOCT IOD with an Enumerated Value of FOR PRESENTATION for Presentation Intent Type (0008,0068).

The Intravascular OCT Image Storage - For Processing SOP Class shall use the IVOCT IOD with an Enumerated Value of FOR PROCESSING for Presentation Intent Type (0008,0068).

An SCU or SCP of the Intravascular OCT Image Storage - For Processing SOP Class shall also support the Intravascular OCT Image Storage - For Presentation SOP Class.

Note

  1. The intent of this requirement is to ensure a useful level of interoperability by avoiding the situation where an SCU might support only the Intravascular OCT Image Storage - For Processing SOP Class and an SCP only the Intravascular OCT Image Storage - For Presentation SOP Class, or vice versa. The burden is therefore to support the Intravascular OCT Image Storage - For Presentation SOP Class as a "baseline".

  2. The term "support" is used in this section in the sense that an SCU or SCP must be capable of sending or receiving the For Presentation SOP Class. There is no intent to imply that an SCU must always send an instance of the For Presentation SOP Class when an instance of the For Processing SOP Class is sent.

    Nor is there any intent to imply that during Association establishment, that a Presentation Context for the For Presentation SOP Class has to be proposed by the initiator. However, an association acceptor may reject a For Presentation SOP Class Presentation Context if it accepts a For Processing SOP Class Presentation Context, and prefers that SOP Class, in which case it may no longer be able to "pass on" the object later as an SCU unless it is able to generate a For Presentation object.

    It is not possible for an SCP to determine from proposed Presentation Contexts whether or not an SCU "supports" (is capable of sending) both For Processing and For Presentation SOP Class Instances. Such a determination requires a priori knowledge of the information contained in the Conformance Statement for the SCU, as well as how the SCU is configured and operated. An SCU that supports both SOP Classes may well choose to only propose one or the other during Association establishment, depending on which Instances it actually intends to send over that particular association (although the SCU must be capable of sending instances of the For Presentation SOP Class if the SCP does not accept the For Processing).

    The intent of the requirement is that if an SCU is only capable of sending the For Presentation SOP Class, any SCP will be guaranteed to be able to receive it. Conversely, if an SCP is only capable of receiving the For Presentation SOP Class, any SCU will be guaranteed to be able to send it.

B.5.1.14 Ophthalmic Thickness Map Storage SOP Class

The Ophthalmic Thickness Map SOP Class encodes a topographic representation of the thickness/height measurements of the posterior eye.

For a device that is both a SCU and a SCP of the Ophthalmic Thickness Map Storage SOP Class, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for Ophthalmic Thickness Map Storage SOP Classes:

  • A SCP of this SOP Class shall support Level 2 Conformance as defined in Section B.4.1.

Note

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

B.5.1.15 Enhanced PET Image Storage and Legacy Converted Enhanced PET Image Storage SOP Class

An SCP of the Enhanced PET Image Storage or Legacy Converted Enhanced PET Image Storage SOP Class shall also support the Grayscale Softcopy Presentation State Storage SOP Class.

Note

This requirement is present in order to allow the exchange of graphical annotations created by an acquisition or conversion device.

B.5.1.16 Enhanced PET Image Storage SOP Classes

An SCP of the Enhanced PET Image Storage SOP Class shall also support the Grayscale Softcopy Presentation State Storage SOP Class.

Note

This requirement is present in order to allow the exchange of graphical annotations created by an acquisition device.

B.5.1.17 Corneal Topography Map Storage SOP Class

The Corneal Topography Map SOP Class encodes a topographic representation of the curvature and/or elevation measurements of corneal anterior and posterior surfaces (e.g., maps that display corneal curvatures, corneal elevations, and corneal power, etc.).

For a device that is both a SCU and a SCP of the Corneal Topography Map Storage SOP Class, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for Corneal Topography Map Storage SOP Classes:

  • A SCP of this SOP Class shall support Level 2 Conformance as defined in Section B.4.1.

Note

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

B.5.1.18 Breast Projection X-Ray Image Storage SOP Classes

The Breast Projection X-Ray Image Storage - For Presentation SOP Class shall use the Breast Projection X-Ray Image IOD with an Enumerated Value of FOR PRESENTATION for Presentation Intent Type (0008,0068).

The Breast Projection X-Ray Image Storage - For Processing SOP Class shall use the Breast Projection X-Ray Image IOD with an Enumerated Value of FOR PROCESSING for Presentation Intent Type (0008,0068).

An SCU or SCP of the Breast Projection X-Ray Image Storage - For Processing SOP Class shall also support the Breast Projection X-Ray Image Storage - For Presentation SOP Class.

B.5.1.19 Planar MPR Volumetric Presentation State Storage SOP Classes

The requirements of Annex FF apply to the following SOP Classes:

  • Grayscale Planar MPR Volumetric Presentation State Storage

  • Compositing Planar MPR Volumetric Presentation State Storage

The Grayscale Planar MPR Volumetric Presentation State Storage SOP Class shall use the Planar MPR Volumetric Presentation State IOD with an Enumerated Value of MONOCHROME for Pixel Presentation (0008,9205) and shall have only a single item in the Volumetric Presentation State Input Sequence (0070,1201).

The Compositing Planar MPR Volumetric Presentation State Storage SOP Class shall use the Planar MPR Volumetric Presentation State IOD with an Enumerated Value of TRUE COLOR for Pixel Presentation (0008,9205).

B.5.1.20 Content Assessment Results Storage SOP Classes

An SCU of the Content Assessment Results Storage SOP Class that creates SOP Instances of the Class shall identify in its Conformance Statement the criteria for setting the Observation Significance (0082,0008).

B.5.1.21 CT Performed Procedure Protocol Storage SOP Class

The CT Performed Procedure Protocol Storage SOP Class encodes the acquisition and reconstruction protocol parameter values used during a specific performed CT procedure and related details.

For a device that is both a SCU and a SCP of the CT Performed Procedure Protocol Storage SOP Class, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for CT Performed Procedure Protocol Storage SOP Classes:

  • A SCP of this SOP Class shall support Level 2 Conformance as defined in Section B.4.1.

Note

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

B.5.1.22 Raw Data Storage SOP Class

For a device that is both a SCU and a SCP of the Raw Data Storage SOP Class, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for the Raw Data Storage SOP Class:

  • An SCP of this SOP Class shall support Level 2 Conformance as defined in Section B.4.1.

Note

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

B.6 Retired Standard SOP Classes

The SOP Classes in Table B.6-1 were defined in previous versions of the DICOM Standard. They are now retired and have been replaced by new standard SOP Classes shown in Table B.5-1.

Note

Usage of the retired SOP Classes is permitted by DICOM. However, new implementations are strongly encouraged to implement the newer SOP Classes.

Table B.6-1. Retired Standard SOP Classes

SOP Class Name

SOP Class UID

Nuclear Medicine Image Storage

1.2.840.10008.5.1.4.1.1.5

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.6

Ultrasound Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.3

X-Ray Angiographic Bi-plane Image Storage

1.2.840.10008.5.1.4.1.1.12.3


C Query/Retrieve Service Class (Normative)

C.1 Overview

C.1.1 Scope

The Query/Retrieve Service Class defines an application-level class-of-service that facilitates the simple management of Composite Object Instances in a manner functionally similar to ACR-NEMA 300-1988. The types of queries that are allowed are not complex. This Service Class is not intended to provide a comprehensive generalized database query mechanism such as SQL. Instead, the Query/Retrieve Service Class is focused towards basic Composite Object Instance information queries using a small set of common Key Attributes.

In addition, the Query/Retrieve Service Class provides the ability to retrieve/transfer a well-identified set of Composite Object Instances. The retrieve/transfer capability allows a DICOM AE to retrieve Composite Object Instances from a remote DICOM AE or request the remote DICOM AE to initiate a transfer of Composite Object Instances to another DICOM AE.

Note

Functional similarity to ACR-NEMA 300-1988 facilitates the migration to DICOM.

An Enhanced Multi-Frame Image Conversion Extended Negotiation option allows the Query/Retrieve Service Class to access Classic single-frame images that have been converted to Enhanced multi-frame images, or vice-versa. This is achieved by providing alternative "views" of studies, such that:

  • the default view provides the images in the form they were received,

  • a Classic single-frame "view" provides images as Classic single frame (that were received that way or have been converted from Enhanced multi-frame),

  • an Enhanced multi-frame "view" provides images as Enhanced multi-frame (that were received that way or have been converted to Enhanced multi-frame).

A query or retrieval above the IMAGE level does not show or return duplicate information (two sets of images). The SCU may request the default, enhanced multi-frame or Classic single frame view. For each view, referential integrity is required to be consistent within the scope of the Patient and that view; i.e., references to UIDs will be converted in all Instances, not only within converted images.

Note

  1. The Classic single-frame view is not intended as an alternative to the Frame Level Retrieve SOP Classes defined in Annex Y. Enhanced Image Storage SOP Classes and Frame Level Retrieve SOP Classes should be used together since they support a unified view of the relationships between instances through a common set of UIDs.

  2. In the Enhanced view, Instances that have no Enhanced equivalent will be returned in their original form but with referential integrity related changes.

C.1.2 Conventions

The following conventions are used to define the types of keys used in Query/Retrieve Information Models.

Table C.1.2-1. Key Type Conventions for Query/Retrieve Information Models

Symbol

Description

U

Unique Key Attribute

R

Required Key Attribute

O

Optional Key Attribute


C.1.3 Query/Retrieve Information Model

In order to serve as an SCP of the Query/Retrieve Service Class, a DICOM AE possesses information about the Attributes of a number of stored Composite Object Instances. This information is organized into a well defined Query/Retrieve Information Model. The Query/Retrieve Information Model shall be a standard Query/Retrieve Information Model, as defined in this Annex of the DICOM Standard.

Queries and Retrievals are implemented against well defined Information Models. A specific SOP Class of the Query/Retrieve Service Class consists of an Information Model Definition and a DIMSE-C Service Group. In this Service Class, the Information Model plays a role similar to an Information Object Definition (IOD) of most other DICOM Service Classes.

C.1.4 Service Definition

Two peer DICOM AEs implement a SOP Class of the Query/Retrieve Service Class with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Query/Retrieve Service Class are implemented using the DIMSE-C C-FIND, C-MOVE, and C-GET services as defined in PS3.7.

Both a baseline and extended behavior is defined for the DIMSE-C C-FIND, C-MOVE, and C-GET services. Baseline behavior specifies a minimum level of conformance for all implementations to facilitate interoperability. Extended behavior enhances the baseline behavior to provide additional features that may be negotiated independently at Association establishment time.

The following descriptions of the DIMSE-C C-FIND, C-MOVE, and C-GET services provide a brief overview of the SCU/SCP semantics:

  1. A C-FIND service conveys the following semantics:

    • The SCU requests that the SCP perform a match of all the keys specified in the Identifier of the request, against the information it possesses, to the level (E.g. Patient, Study, Series, or Composite Object Instance) specified in the request.

      Note

      In this Annex, the term "Identifier" refers to the Identifier service parameter of the C-FIND, C-MOVE, or C-GET service as defined in PS3.7.

    • The SCP generates a C-FIND response for each match with an Identifier containing the values of all key fields and all known Attributes requested. All such responses will contain a status of Pending. A status of Pending indicates that the process of matching is not complete.

    • When the process of matching is complete a C-FIND response is sent with a status of Success and no Identifier.

    • A Refused or Failed response to a C-FIND request indicates that the SCP is unable to process the request.

    • The SCU may cancel the C-FIND service by issuing a C-FIND-CANCEL request at any time during the processing of the C-FIND service. The SCP will interrupt all matching and return a status of Canceled.

  2. A C-MOVE service conveys the following semantics:

    • The SCU supplies Unique Key values to identify an entity at the level of the retrieval. The SCP of the C-MOVE initiates C-STORE sub-operations for the corresponding storage SOP Instances identified by Unique Key values. These C-STORE sub-operations occur on a different Association than the C-MOVE service. The SCP role of the Query/Retrieve SOP Class and the SCU role of the Storage SOP Class may be performed by different applications that may or may not reside on the same system. Initiation mechanism of C-STORE sub-operations is outside of the scope of DICOM standard.

      Note

      This does not imply that they use the same AE Title. See Section C.6.1.2.2.2 and Section C.6.2.2.2.2 for the requirements to the C-MOVE SCP conformance.

    • The SCP may optionally generate responses to the C-MOVE with status equal to Pending during the processing of the C-STORE sub-operations. These C-MOVE responses indicate the number of Remaining C-STORE sub-operations and the number of C-STORE sub-operations returning the status of Success, Warning, and Failed.

    • When the number of Remaining C-STORE sub-operations reaches zero, the SCP generates a final response with a status equal to Success, Warning, Failed, or Refused. This response may indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If the status of a C-STORE sub-operation was Failed a UID List will be returned.

    • The SCU may cancel the C-MOVE service by issuing a C-MOVE-CANCEL request at any time during the processing of the C-MOVE. The SCP terminates all incomplete C-STORE sub-operations and returns a status of Canceled.

  3. A C-GET service conveys the following semantics:

    • The SCU supplies Unique Key values to identify an entity at the level of the retrieval. The SCP generates C-STORE sub-operations for the corresponding storage SOP Instances identified by the Unique Key values. These C-STORE sub-operations occur on the same Association as the C-GET service and the SCU/SCP roles will be reversed for the C-STORE.

    • The SCP may optionally generate responses to the C-GET with status equal to Pending during the processing of the C-STORE sub-operations. These C-GET responses indicate the number of Remaining C-STORE sub-operations and the number of C-STORE sub-operations returning the status of Success, Warning, and Failed.

    • When the number of Remaining C-STORE sub-operations reaches zero, the SCP generates a final response with a status equal to Success, Warning, Failed, or Refused. This response may indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If the status of a C-STORE sub-operation was Failed a UID List will be returned.

    • The SCU may cancel the C-GET service by issuing a C-GET-CANCEL request at any time during the processing of the C-GET. The SCP terminates all incomplete C-STORE sub-operations and returns a status of Canceled.

C.2 Query/Retrieve Information Model Definition

The Query/Retrieve Information Model is identified by the SOP Class negotiated at Association establishment time. The SOP Class is composed of both an Information Model and a DIMSE-C Service Group.

Note

This SOP Class identifies the class of the Query/Retrieve Information Model (i.e., not the SOP Class of the stored SOP Instances for which the SCP has information).

Information Model Definitions for standard SOP Classes of the Query/Retrieve Service Class are defined in this Annex. A Query/Retrieve Information Model Definition contains:

  • Entity-Relationship Model Definition

  • Key Attributes Definition

C.2.1 Entity-Relationship Model Definition

For any Query/Retrieve Information Model, an Entity-Relationship Model defines a hierarchy of entities, with Attributes defined for each level in the hierarchy (e.g., Patient, Study, Series, Composite Object Instance).

C.2.2 Attributes Definition

Attributes shall be defined at each level in the Entity-Relationship Model. An Identifier in a C-FIND, C-MOVE, or C-GET command shall contain values to be matched against the Attributes of the Entities in a Query/Retrieve Information Model. For any query, the set of entities for which Attributes are returned, shall be determined by the set of Key Attributes specified in the Identifier that have corresponding matches on entities managed by the SCP associated with the query.

C.2.2.1 Attribute Types

All Attributes of entities in a Query/Retrieve Information Model shall be either a Unique Key, Required Key, or Optional Key. The term Key Attributes refers to Unique, Required, and Optional Key Attributes.

C.2.2.1.1 Unique Keys

At each level in the Entity-Relationship Model, one Attribute shall be defined as a Unique Key. A single value in a Unique Key Attribute shall uniquely identify a single entity at a given level. That is, two entities at the same level may not have the same Unique Key value.

C-FIND, C-MOVE, and C-GET SCPs shall support existence and matching of all Unique Keys defined by a Query/Retrieve Information Model. All entities managed by C-FIND, C-MOVE, and C-GET SCPs shall have a specific non-zero length Unique Key value.

Unique Keys may be contained in the Identifier of a C-FIND request. Unique Keys shall be contained in the Identifier of C-MOVE and C-GET requests.

C.2.2.1.2 Required Keys

At each level in the Entity-Relationship Model, a set of Attributes shall be defined as Required Keys. Required Keys imply the SCP of a C-FIND shall support matching based on a value contained in a Required Key of the C-FIND request. Multiple entities may have the same value for Required Keys. That is, a distinct value in a Required Key shall not necessarily identify a single entity at the level of the key.

C-FIND SCPs shall support existence and matching of all Required Keys defined by a Query/Retrieve Information Model. If a C-FIND SCP manages an entity with a Required Key of zero length, the value is considered unknown and all matching against the zero length Required Key shall be considered a successful match.

Required Keys may be contained in the Identifier of a C-FIND request. Required Keys shall not be contained in the Identifier of C-MOVE and C-GET requests.

C.2.2.1.3 Optional Keys

At each level in the Entity-Relationship Model, a set of Attributes shall be defined as Optional Keys.

Optional Keys contained in the Identifier of a C-FIND request may have three different types of behavior depending on support for existence and/or matching by the C-FIND SCP. If the C-FIND SCP:

  • does not support the existence of the Optional Key, then the Attribute shall not be returned in C-FIND responses

  • supports the existence of the Optional Key but does not support matching on the Optional Key, then the Optional Key shall be processed in the same manner as a zero length Required Key. That is, the value specified to be matched for the Optional Key is ignored but a value may be returned by the SCP for this Optional Key.

  • supports the existence and matching of the Optional Key, then the Optional Key shall be processed in the same manner as a Required Key.

Note

  1. C-FIND SCU may not assume an Optional Key with non-zero length will be processed in the same manner as a Required Key. The Conformance Statement of the C-FIND SCP shall list the Optional Keys that are supported.

  2. Optional Keys are differentiated from Required Keys in that Optional Keys may or may not be supported for existence and/or matching by C-FIND SCPs. Whereas, Required Keys must always be supported by C-FIND SCPs.

Optional Keys may be contained in the Identifier of a C-FIND request. Optional Keys shall not be contained in the Identifier of C-MOVE and C-GET requests.

C.2.2.2 Attribute Matching

The following types of matching may be performed on Key Attributes in the Query/Retrieve Service Class:

  • Single Value Matching

  • List of UID Matching

  • Universal Matching

  • Wild Card Matching

  • Range Matching

  • Sequence Matching

Matching requires special characters (i.e., "*","?","-", "=" and "\"), which need not be part of the character repertoire for the VR of the Key Attributes.

Note

  1. For example, the "-" character is not valid for the DA, DT and TM VRs but is used for range matching.

  2. When character sets other than the default character repertoire are used, then the rules in PS3.5 apply, such as with respect to the use of the 05/12 "\" (BACKSLASH) (in ISO IR 6) or 05/12 "¥" (YEN SIGN) (in ISO IR 14).

The total length of the Key Attribute may exceed the length as specified in the VR in PS3.5. The Value Multiplicity (VM) may be larger than the VM specified in PS3.6 for the Key Attribute, as defined for particular Matching Type.

The Specific Character Set (0008,0005) Attribute may be present in the Identifier but is never matched. Rather, it specifies how other Attributes are encoded in the Request and Response Identifiers.

It may influence how matching of other Attributes is performed. If Specific Character Set (0008,0005) is absent, then the default character repertoire shall be used. Specific Character Set (0008,0005) shall not have a zero length value.

Specific Character Set (0008,0005) may have multiple values if escape sequences are used to switch between character repertoires within values.

If the SCP does not support the value(s) of Specific Character Set (0008,0005) in the Request Identifier, then the manner in which matching is performed is undefined and shall be specified in the conformance statement.

Note

  1. If an SCU sends a Request Identifier with a single byte character set not supported by the SCP, then it is likely, but not required, that the SCP will treat unrecognized characters as wild cards and match only on characters in the default repertoire, and return a response in the default repertoire.

  2. Some Specific Character Set values are used with multi-component group person names (e.g., single-byte, ideographic and phonetic and phonetic component groups separated by an "=" (3DH) character), which may also affect the behavior of literal string matching.

The Timezone Offset From UTC (0008,0201) Attribute may be present in the Identifier but is not matched if Timezone query adjustment is negotiated. If Timezone query adjustment is negotiated, it specifies how date and time Attribute values are interpreted in the Request and Response Identifiers if those values lack a specific time zone offset specification.

C.2.2.2.1 Single Value Matching

If the value specified for a Key Attribute in a request is non-zero length and if it is:

  1. not a date or time or datetime, contains no wild card characters

  2. a date or time or datetime, contains a single date or time or datetime with no "-"

then single value matching shall be performed. Except for Attributes with a PN Value Representation, only entities with values that match exactly the value specified in the request shall match. This matching is case-sensitive, i.e., sensitive to the exact encoding of the key Attribute value in character sets where a letter may have multiple encodings (e.g., based on its case, its position in a word, or whether it is accented).

For Attributes with a PN Value Representation (e.g., Patient Name (0010,0010)), an application may perform literal matching that is either case-sensitive, or that is insensitive to some or all aspects of case, position, accent, or other character encoding variants.

Note

  1. For multi-component names, the component group delimiter "=" (3DH) may be present in the Key Attribute value, but may give unexpected results if the SCP does not support matching on separate components but interprets the entire value literally as a single string. E.g., "Wang^XiaoDong=王^小東" may or may not match "Wang^XiaoDong" or "王^小東"; wild card matching without the component group delimiter, such as "*Wang^XiaoDong*" or "*王^小東 *" may be necessary.

  2. Using attributes with VR of AE, LO, PN and SH as matching keys will not allow single value matching on values that contain characters "*" and "?" - such queries will always be treated as queries with wildcard matching.

  3. Attributes with VR of ST, LT and UT are intended for conveying narrative text and may contain wildcard characters "*" and "?". Attempts to match on a string explicitly containing "*" or "?" will be treated as wildcard matching and thus may return multiple results rather than a single one.

If extended negotiation of fuzzy semantic matching rather than literal matching of PN Value Representation is successful, not only may matching be insensitive to case, position, accent, and character encoding, but in addition other techniques such as phonetic matching may be applied.

If the Timezone Offset From UTC (0008,0201) Attribute is present in the Identifier and Timezone query adjustment was negotiated, it shall be used to adjust values of time Attributes (and associated date Attributes, if present) from the local timezone to UTC. It shall also adjust values of datetime Attributes that do not specify a timezone offset. The encoding and semantics of the Timezone Offset From UTC (0008,0201) Attribute shall be as defined in the SOP Common Module in PS3.3.

The manner in which matching is performed is implementation dependent and shall be specified in the conformance statement.

Note

  1. This definition implies that dates or times or datetimes are matched by their meaning, not as literal strings. For example:

    • the DT "19980128103000.0000" matches "19980128103000"

    • the DT "19980128103000" with no timezone offset matches "19980128073000" with timezone offset "-0300"

    • the TM "2230" matches "223000"

  2. If an application is concerned about how single value matching of dates and times is performed by another application, it may consider using range matching instead, which is always performed by meaning, with both values in the range the same.

  3. Exclusion of the "-" character for single value matching implies that a Key Attribute with DT Value Representation may not contain a negative offset from Universal Coordinated Time (UTC) if single value matching is intended. Use of the "-" character in date, time or datetime indicates range matching.

  4. If an application is in a local time zone that has a negative offset then it cannot perform single value matching using a local time notation. Instead, it can convert the Key Attribute value to UTC and use an explicit suffix of "+0000".

  5. Matching of PN Attributes may be accent-insensitive, as specified in the conformance statement. Accent-insensitive matching would successfully match, for instance, a query character "SMALL LETTER a" (06/01 in the default ISO-IR 6) with

    • "SMALL LETTER a WITH GRAVE ACCENT" (14/00 in ISO-IR 100),

    • "SMALL LETTER a WITH TILDE" (14/03 in ISO-IR 100),

    • "SMALL LETTER a WITH BREVE" (14/03 in ISO-IR 101), and

    • "CAPITAL LETTER a WITH ACUTE ACCENT" (12/01 in ISO-IR 100) (if matching is also case-insensitive),

    but would not match 14/00 in ISO-IR 101, which is "SMALL LETTER r WITH ACUTE ACCENT". Matching to particular bit-combinations is specific to each supported character set (note the difference in meaning of 14/00), and should be described in the conformance statement.

  6. An SCU application may elect to perform additional filtering of the responses by applying the matching rules itself. In the event that both the SCU and SCP are applying the matching rules, this process will be successful as long as literal matching is performed by both, and any additional SCU filtering is insensitive to case, position, accent, or other character encoding variants.

However if fuzzy semantic matching of PN Attributes has been negotiated, matching by the SCP may result in responses that are not obviously related to the request, hence care should be taken if any additional filtering of responses is performed by the SCU. For example, if phonetic matching is performed, a query for "Swain" might well return "Swayne", or if name component order insensitive matching is performed, a query for "Smith^Mary" might well return "Mary^Smith" or "Mary Smith" or "Smith, Mary". Fuzzy semantic matching may also take into account separate single-byte, ideographic and phonetic name component groups.

C.2.2.2.2 List of UID Matching

A List of UIDs is encoded by using the value multiplicity operator, backslash ("\"), as a delimiter between UIDs. Each item in the list shall contain a single UID value. Each UID in the list contained in the Identifier of the request may generate a match.

Note

A list of single values is encoded exactly as a VR of UI and a VM of Multiple (see PS3.5).

C.2.2.2.3 Universal Matching

If the value specified for a Key Attribute in a request is zero length, then all entities shall match this Attribute. An Attribute that contains a Universal Match specification in a C-FIND request provides a mechanism to request the selected Attribute value be returned in corresponding C-FIND responses.

C.2.2.2.4 Wild Card Matching

If the Attribute is not a date, time, signed long, signed short, unsigned short, unsigned long, floating point single, floating point double, other byte string, other word string, unknown, Attribute tag, decimal string, integer string, age string or UID and the value specified in the request contains any occurrence of an "*" or a "?", then "*" shall match any sequence of characters (including a zero length value) and "?" shall match any single character. This matching is case sensitive, except for Attributes with an PN Value Representation (e.g., Patient Name (0010,0010)).

For Attributes with a PN value representation, including the case of extended negotiation of fuzzy semantic matching, wild card matching is implementation dependent and shall be specified in the conformance statement.

Note

  1. Wild card matching on a value of "*" is equivalent to universal matching.

  2. The wild card matching method specified by DICOM might not be supported by some non-DICOM multi-byte character text processors.

  3. For multi-component group names, the component group delimiter "=" (3DH) may be present in the Key Attribute value, but may give unexpected results if the SCP does not support matching on separate components but interprets the entire value literally. E.g., "*=*" or "*=*=*" may or may not return all strings, and hence is not equivalent to "*", nor to universal matching.

  4. Using attributes with VR of AE, LO, PN and SH as matching keys will not allow single value matching on values that contain characters "*" and "?" - such queries will always be treated as queries with wildcard matching.

  5. Attributes with VR of ST, LT and UT are intended for conveying narrative text and may contain wildcard characters "*" and "?". Attempts to match on a string explicitly containing "*" or "?" will be treated as wildcard matching and thus may return multiple results rather than a single one.

C.2.2.2.5 Range Matching

In the absence of extended negotiation, if the Attribute is a date, then:

  1. A string of the form "<date1> - <date2>", where <date1> is less or equal to <date2>, shall match all occurrences of dates that fall between <date1> and <date2> inclusive

  2. A string of the form "- <date1>" shall match all occurrences of dates prior to and including <date1>

  3. A string of the form "<date1> -" shall match all occurrences of <date1> and subsequent dates

In the absence of extended negotiation, if the Attribute is a time, then:

  1. A string of the form "<time1> - <time2>", where <time1> is less or equal to <time2>, shall match all occurrences of times that fall between <time1> and <time2> inclusive

  2. A string of the form "- <time1>" shall match all occurrences of times prior to and including <time1>

  3. A string of the form "<time1> -" shall match all occurrences of <time1> and subsequent times

If the Attribute is a datetime, then:

  1. A string of the form "<datetime1> - <datetime2>", where <datetime1> is less or equal to <datetime2>, shall match all moments in time that fall between <datetime1> and <datetime2> inclusive

  2. A string of the form "- <datetime1>" shall match all moments in time prior to and including <datetime1>

  3. A string of the form "<datetime1> -" shall match all moments in time subsequent to and including <datetime1>

  4. The offset from Universal Coordinated Time, if present in the Value of the Attribute, shall be taken into account for the purposes of the match.

If extended negotiation of combined datetime matching is successful, then a pair of Attributes that are a date and a time, both of which specify the same form of range matching, shall have the concatenated string values of each range matching component matched as if they were a single datetime Attribute.

Note

For example, a Study Date of "20060705-20060707" and a Study Time of "1000-1800" will match the time period of July 5, 10am until July 7, 6pm, rather than the three time periods of 10am until 6pm on each of July 5, July 6 and July 7, as would be the case without extended negotiation.

Regardless of other extended negotiation, an application may use the value of Timezone Offset From UTC (0008,0201) to adjust values of time and datetime Attributes from the local timezone to UTC for matching. See Section C.2.2.2.1.

Note

If extended negotiation of combined datetime matching is successful, the timezone offset may effect a change in date if the local time and UTC are on different sides of midnight.

Range matching is not defined for types of Attributes other than dates and times.

C.2.2.2.6 Sequence Matching

If a Key Attribute in the Identifier of a C-FIND request needs to be matched against an Attribute structured as a Sequence of Items (Value Representation of Type SQ), the Key Attribute shall be structured as a Sequence of Items with a single Item. This Item may contain zero or more Item Key Attributes. Each Item Key Attribute matching shall be performed on an Item by Item basis. The types of matching defined in Section C.2.2.2 shall be used: Single Value Matching, List of UID Matching, Universal Matching, Wild Card Matching, Range Matching and Sequence Matching (recursive Sequence matching).

If all the Item Key Attributes match, for at least one of the Items of the Attribute against which the match is performed, a successful match is generated. A sequence of matching Items containing only the requested Attributes is returned in the corresponding C-FIND responses.

If the Key Attribute in the Identifier of a C-FIND request contains no Key Item Attribute (zero-length Item Tag), then all entities shall match this Attribute. This provides a universal matching like mechanism to request that the selected Key Attribute value (the entire Sequence of Items) be returned in corresponding C-FIND responses.

C.2.2.3 Matching Multiple Values

When matching an Attribute that has a value multiplicity of greater than one, if any of the values match, then all values shall be returned.

C.3 Standard Query/Retrieve Information Models

Three standard Query/Retrieve Information Models are defined in this Annex. Each Query/Retrieve Information Model is associated with a number of SOP Classes. The following three hierarchical Query/Retrieve Information Models are defined:

  • Patient Root

  • Study Root

  • Patient/Study Only

C.3.1 Patient Root Query/Retrieve Information Model

The Patient Root Query/Retrieve Information Model is based upon a four level hierarchy:

  • Patient

  • Study

  • Series

  • Composite Object Instance

The patient level is the top level and contains Attributes associated with the Patient Information Entity (IE) of the Composite IODs as defined in PS3.3. Patients IEs are modality independent.

The study level is below the patient level and contains Attributes associated with the Study IE of the Composite IODs as defined in PS3.3. A study belongs to a single patient. A single patient may have multiple studies. Study IEs are modality independent.

The series level is below the study level and contains Attributes associated with the Series, Frame of Reference and Equipment IEs of the Composite IODs as defined in PS3.3. A series belongs to a single study. A single study may have multiple series. Series IEs are modality dependent. To accommodate this modality dependence, the set of Optional Keys at the series level includes all Attributes defined at the series level from any Composite IOD defined in PS3.3.

The lowest level is the Composite Object Instance level and contains Attributes associated with the Composite object IE of the Composite IODs as defined in PS3.3. A Composite Object Instance belongs to a single series. A single series may contain multiple Composite Object Instances. Most composite object IEs are modality dependent. To accommodate this potential modality dependence, the set of Optional Keys at the Composite Object Instance level includes all Attributes defined at the Composite Object Instance level from any Composite IOD defined in PS3.3.

C.3.2 Study Root Query/Retrieve Information Model

The Study Root Query/Retrieve Information Model is identical to the Patient Root Query/Retrieve Information Model except the top level is the study level. Attributes of patients are considered to be Attributes of studies.

C.3.3 Patient/Study Only Query/Retrieve Information Model

Retired. See PS 3.4-2004.

C.3.4 Additional Query/Retrieve Attributes

Some optional Attributes that may be used in Query/Retrieve Information Models that are not Attributes of an Information Object Definition and, therefore, are not defined in PS3.3. These Attributes are defined in Table C.3-1.

Table C.3-1. Additional Query/Retrieve Attributes

Attribute Name

Tag

Attribute Description

Number of Patient Related Studies

(0020,1200)

The number of studies that match the Patient level Query/Retrieve search criteria

Number of Patient Related Series

(0020,1202)

The number of series that match the Patient level Query/Retrieve search criteria

Number of Patient Related Instances

(0020,1204)

The number of Composite Object Instances that match the Patient level Query/Retrieve search criteria

Number of Study Related Series

(0020,1206)

The number of series that match the Study level Query/Retrieve search criteria

Number of Series Related Instances

(0020,1209)

The number of Composite Object Instances in a Series that match the Series level Query/Retrieve search criteria

Number of Study Related Instances

(0020,1208)

The number of Composite Object Instances that match the Study level Query/Retrieve search criteria

Modalities in Study

(0008,0061)

All of the distinct values used for Modality (0008,0060) in the Series of the Study.

SOP Classes in Study

(0008,0062)

The SOP Classes contained in the Study.

Alternate Representation Sequence

(0008,3001)

A Sequence of Items, each identifying an alternate encoding of an image that matches the Instance level Query/Retrieve search criteria (see Section C.6.1.1.5.1)


If the SCP manages images in multiple alternate encodings, only one of the alternate encodings of an image is included in the number of object instances.

C.3.5 New Instance Creation for Enhanced Multi-Frame Image Conversion

When Query/Retrieve View (0008,0053) is present with a value of "CLASSIC" or "ENHANCED" in a C-FIND, C-MOVE or C-GET Request Identifier, then the Information Model against which the query or retrieval is performed and any SOP Instances that are retrieved shall be returned, constructed or converted according to the requirements in this section.

There are no requirements with respect to when such instances are actually created or persisted, only that they be available on request. I.e., they may be created in advance (cached) or they may be created dynamically as required, as long as the process is deterministic in the sense that the same Attributes will be populated with the same values on successive queries and retrievals (including UIDs).

Note

  1. The UID generation process is required to be deterministic but it is important to remember that appending a suffix to an existing UID is not a valid approach to generating a new UID, unless the converter is the producer (owner of the root) of the original UID and knows that this is safe and the result will be unique.

  2. The cross-references between original and converted instances contain sufficient information to recover UIDs in the alternative form.

All instances for a Patient known to the SCP shall be converted as necessary to maintain referential integrity and to avoid information loss.

Note

  1. It is not permitted to fail to include a subset of instances within this scope, for example, the presentation states or key object selection documents, in the "ENHANCED" view, in order to avoid the effort of creating new instances with updated references required to maintain referential integrity. In other words, the total "information content" of any view will be no less than that of the default view.

  2. This does not mean that all instances need to be converted, since if they contain no such references, they can be left alone and included in the view. For example, a Classic single slice CT localizer image with no references can remain unchanged in the view as a CT Image Storage SOP Class with its existing SOP Instance UID and SOP Class and in its existing Series, and be referenced from converted instances, such as the axial images prescribed from it. An SCU cannot make any assumptions about what will or will not be converted, or in what order.

  3. It is understood that the requirements of this section are applicable to a single SCP; it is not possible to require all SCPs that perform conversion to perform it the same way, or create the same UIDs, etc.

In addition to the general requirements in this section, specific requirements apply to the following types of instance created:

  • Enhanced (true or legacy converted) multi-frame images that are created from Classic single frame images

  • Classic single frame images that are created from Enhanced (true or legacy converted) multi-frame images

  • Instances that contain references to the SOP Instance UIDs or Series Instance UIDs corresponding to either the converted single frame images, or other instances with such references

The general requirements are that:

  • The new Composite Instance shall have a new SOP Instance UID.

  • The new Composite Instance shall be a valid SOP Instance (i.e., will comply with the IOD, Module and Attribute requirements for the Storage SOP Class).

- The new Composite Instance shall contain the Contributing Equipment Sequence (0018,A001). If the source Composite Instances already contain the Contributing Equipment Sequence with a consistent set of Item values (excluding Contribution DateTime (0018,A002)), then a new Item shall be appended to the copy of the sequence in the new Composite Instance; if the source Composite Instance does not contain the Contributing Equipment Sequence or the Item values (excluding Contribution DateTime (0018,A002)) differ between source instances, then Contributing Equipment Sequence shall be created, containing one new Item. In either case, the new Item shall describe the equipment that is creating the new Composite Instance, and the Purpose of Reference Code Sequence (0040,A170) within the Item shall be (109106, DCM, "Enhanced Multi-frame Conversion Equipment") and the Contribution Description (0018,A003) shall be "Legacy Enhanced Image created from Classic Images", "Classic Image created from Enhanced Image", or "Updated UID references during Legacy Enhanced Classic conversion" as appropriate.

  • The new Composite Instance shall have the same Patient and Study level information as the source Instance, including the same Study Instance UID.

  • The new Composite Instance shall have the same spatial and temporal Frame of Reference information as the source instance, if present (e.g., the Frame of Reference UID shall be the same).

  • The new Composite Instance shall be placed in a new Series (together with other new Composite Instances that share the same, new Series level information), with a new Series Instance UID. The Series Date (0008,0021) and Series Time (0008,0031) of all the Instances in the new Series shall be the earliest of the values in the source Composite Instances, if present.

    Note

    1. The new Series Date and Time shall NOT be that of when the conversion was performed, but shall reflect the values in the source images.

    2. There is no standard requirement or mechanism defined to change or preserve other Series level Attributes, such as Series Number or Series Description. This is left to the discretion of the implementer, particularly in cases where instances from different Series are merged.

  • The new Composite Instance shall have the same Items and Values of Request Attributes Sequence (0040,0275) as the source Composite Instances, if Request Attributes Sequence (0040,0275) is present in any of the source Composite Instances.

  • If the new Composite Instance contains references to another entity for the same Patient (including, but not limited to, references to SOP Instances, Series, Studies or Frames of Reference), and the target of those references is also converted, then the references shall be changed to refer to the converted entity.

    Note

    1. For example, if the source instance refers to an instance in a Series, and the referenced instance is also converted, and hence placed in a new Series, then both the SOP Instance UID and the Series Reference UID in the hierarchical reference to the instance will need to be updated, as will the SOP Class UID of the referenced instance, if that has changed, as it likely will have.

    2. The overall intent is to maintain referential integrity within the converted set of instances, within the scope of the same Patient. Since it is likely that most if not all non-image instances for a patient will reference images that will be converted, this means that most if not all non-image instances will also have to be "converted", for the purpose of updating such references. This referential integrity is required regardless of whether the initial request is for a subset of instances for the patient only, or not.

    3. The UIDs referenced in Conversion Source Attributes Sequence (0020,9172) are not converted, since by definition, these reference instances in the "other" view; they should not exist in the source, but will be inserted (or be replaced, if previously converted) during conversion.

The specific requirements for the conversion of single frame images to Enhanced Multi-frame images are:

  • The SOP Class of the new Composite Instance shall be the appropriate modality-specific Enhanced Image Storage SOP Class that is intended for de novo creation by an acquisition or post-processing device, unless the source images do not contain sufficient information to populate mandatory Attributes with standard Enumerated Values and Defined Terms or Coded Sequence Item values, in which case the appropriate modality-specific Legacy Converted Enhanced Image Storage SOP Class shall be used. The appropriate SOP Classes are defined in Table C.3.5-1.

    Note

    1. For example, if the source images to be converted are of the CT Image Storage SOP Class, then the preferred new SOP Class is the Enhanced CT Image Storage SOP Class, but if this is not possible, the Legacy Converted Enhanced CT Image Storage SOP Class is used.

    2. It is not intended that images from different modalities be combined in the same new Composite Instance. For example, it is not expected that CT and PET images would be combined in the same Instance, since the technique Attributes and the pixel data characteristics are quite distinct.

    3. It is expected that as many single frame images will be combined into a single multi-frame image as is sensible, given the constrains on what Attributes must be identical as defined in this section, and depending on the type of images and the size of the resulting object. Different implementations may make different choices in this respect. For example, an application might choose to combine only images in the same Series, or with the same slice spacing, or the same values for Image Type, or with the same Image Orientation (Patient).

  • The new Composite Instance shall not be contained in a Concatenation. This means that it shall not contain a Concatenation UID (0020,9161) Attribute or other Concatenation Attributes. If the existing Composite Instance contains such Attributes, they shall not be included in the new Composite Instance.

  • The new Composite Instance contains only one set of Attributes for the Image Pixel Module, hence the contents of the Image Pixel Module shall either be identical in all source images, or the Pixel Data for each frame shall be converted as necessary to match the Image Pixel Module of the new Composite Instance.

    Note

    1. In particular this means that the values of Rows, Columns, Bits Stored, Bits Allocated, High Bit, Pixel Representation, Samples per Pixel, Photometric Interpretation and Planar Configuration applicable to all of the frames needs to be the same. In special cases, such as where Bits Stored is less than Bits Allocated but varies per frame, it may be safe to use the largest value for all the frames and ensure that any unused high bits are appropriately masked before encoding. It is not expected that source images with different numbers of Rows and Columns will be combined (by padding the periphery of images smaller than the largest); quite apart from not being the intended use case, this has the potential to greatly expand the size of the instance, and might also require adjustment of the Image Position (Patient) values.

    2. Special attention should be given to the Pixel Padding Value and associated Attributes, in case these vary per frame in the source images, in which case the Pixel Data for some frames may need to be modified to be consistent with all the other frames.

    3. It is possible to change the Image Pixel Module Attributes related to compressed Transfer Syntaxes (including lossy or irreversible compression) during conversion.

  • All mandatory Attributes of all mandatory Modules and Functional Group Macros of the SOP Class of the new Composite Instance shall be populated as required by the IOD. In this context, "mandatory" means either required or conditional where the condition is satisfied.

    Note

    For example, if the source images to be converted are of the CT Image Storage SOP Class, and the new Composite Instance is of the Legacy Converted Enhanced CT Image Storage SOP Class, then it is required that the Pixel Measures Functional Group be populated from Pixel Spacing, that the Plane Position (Patient) Functional Group be populated from Image Position (Patient), etc. In addition, if Body Part Examined is present in the source images with a standard value, then the condition for the inclusion of the Frame Anatomy Functional Group is satisfied, and the value therein needs to be converted to the appropriate Anatomic Region Sequence code.

  • All optional Attributes, Modules and Functional Group Macros for which corresponding information is present in the source images in standard Attributes shall also be populated.

  • All Attributes of the Overlay Module shall be removed and converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation); if the Overlay uses high bits in the Pixel Data (7FE0,0010) these shall be extracted and encoded in Overlay Data (60xx,3000) in the Presentation State and shall be set to zero in the Pixel Data (7FE0,0010) Attribute in the converted image.

    Note

    The extraction of Overlays from multiple frames may lead to a proliferation of GSPS Instances (one per converted frame), unless the converter recognizes commonality in the binary values of overlay bit planes and factors it out into fewer GSPS objects that each apply to multiple frames.

  • All Attributes of the Curve Module (retired, but formerly defined in DICOM) shall be removed; they may be converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation) or a Waveform as appropriate, but this is not required.

  • All Attributes of the Graphic Annotation Sequence (0070,0001) (not defined in Classic image IODs, but sometimes used in a Standard Extended SOP Class) shall be removed; they may be converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation), but this is not required.

  • All remaining Attributes in the source images (i.e., those that have not been used to populate mandatory or optional Attributes in Modules and Functional Groups), including Private Attributes, shall be copied into the top-level Data Set or the Unassigned Shared Converted Attributes Sequence (0020,9170) if they are present in all of the source images for the new Composite Instance, have the same number of values, and have the same values, otherwise they shall be copied into the Unassigned Per-Frame Converted Attributes Sequence (0020,9171).

    Note

    The semantics of Private Attributes, or Standard Attributes used in a Standard Extended SOP Class, might not be maintained, being unknown to the converting application; for example, referential integrity of UIDs in Private Attributes might not be updated.

  • The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Reference Functional Group Macro.

The specific requirements for the conversion of Enhanced Multi-frame images to Classic single frame images are:

  • The SOP Class of the new Composite Instance shall be the appropriate modality-specific (Classic) Image Storage SOP Class that is intended for de novo creation by an acquisition or post-processing device.

    Note

    For example, if the source images to be converted are of the Enhanced CT Image Storage SOP Class or the Legacy Converted Enhanced CT Image Storage SOP Class, then the new SOP Class is the CT Image Storage SOP Class.

  • All mandatory Attributes of the IOD of the SOP Class of the new Composite Instance shall be populated. In this context, "mandatory" means either required or conditional where the condition is satisfied.

    Note

    For example, if the source images to be converted are of the Legacy Converted Enhanced CT Image Storage SOP Class, and the new Composite Instance is of the CT Image Storage SOP Class, then it is required that Pixel Spacing be populated from the Pixel Measures Functional Group, that Image Position (Patient) be populated from the Plane Position (Patient) Functional Group, etc.

  • All optional Attributes in Modules of the IOD for which corresponding information is present in the source images shall also be populated.

  • All remaining Attributes in the source images (i.e., those that have not been used to populate mandatory or optional Attributes in Modules), including Private Attributes, shall be copied from the top-level Data Set and the Shared Functional Group Macro and the corresponding Item of the Per-Frame Functional Group Macro into the top-level Data Set of the new Composite Instance, including those in the Unassigned Shared Converted Attributes Sequence (0020,9170) and the corresponding Item of the Unassigned Per-Frame Converted Attributes Sequence (0020,9171) (which will result in a Standard Extended SOP Class).

    Note

    1. Identifying Attributes, such as Series Number or Series Description, will be present in the Unassigned functional groups, and UIDs will be present in the Conversion Source Attributes Sequence, allowing, for example, the original Series organization to be recovered, whether or not a single Series was previously converted into a single Legacy Converted instance or it was split or merged with other Series.

    2. The integrity of the set of Private Attributes recovered in this manner cannot be guaranteed to result in the correct function of any applications that depend on them, but the expectation is that this will be no better or worse than the impact of storing instances with private Attributes on any Storage SCP that may or may not reorganize and/or selectively preserve Private Attributes.

  • The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) in the SOP Common Module.

The specific requirements for the conversion of other instances are:

  • The new Composite Instance shall be an instance of the same SOP Class as the source Composite Instance.

  • The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) in the SOP Common Module.

Table C.3.5-1. Modality-Specific SOP Class Conversions

Classic

True Enhanced

Legacy Converted Enhanced

CT Image Storage

Enhanced CT Image Storage

Legacy Converted Enhanced CT Image Storage

MR Image Storage

Enhanced MR Image Storage

Legacy Converted Enhanced MR Image Storage

PET Image Storage

Enhanced PET Image Storage

Legacy Converted Enhanced PET Image Storage


C.4 DIMSE-C Service Groups

Three DIMSE-C Services are used in the construction of SOP Classes of the Query/Retrieve Service Class. The following DIMSE-C operations are used:

  • C-FIND

  • C-MOVE

  • C-GET

C.4.1 C-FIND Operation

SCPs of some SOP Classes of the Query/Retrieve Service Class may be capable of processing queries using the C-FIND operation as described in PS3.7. The C-FIND operation is the mechanism by which queries are performed. Matches against the keys present in the Identifier are returned in C-FIND responses.

C.4.1.1 C-FIND Service Parameters

C.4.1.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-FIND is to be performed. Support for the SOP Class UID is implied by the Abstract Syntax UID of the Presentation Context used by this C-FIND operation.

C.4.1.1.2 Priority

The Priority Attribute defines the requested priority of the C-FIND operation with respect to other DIMSE operations being performed by the same SCP.

Processing of priority requests is not required of SCPs. Whether or not an SCP supports priority processing and the meaning of the different priority levels shall be stated in the Conformance Statement of the SCP.

C.4.1.1.3 Identifier

Both the C-FIND request and response contain an Identifier encoded as a Data Set (see PS3.5).

Note

The definition of a Data Set in PS3.5 specifically excludes the range of groups below group 0008, and this includes in particular Meta Information Header elements such as Transfer Syntax UID (0002,0010). The C-FIND request and identifier do not support a mechanism for ascertaining the manner in which an SCP might have encoded a stored image whether it be by requesting Transfer Syntax UID (0002,0010) or by any other mechanism.

C.4.1.1.3.1 Request Identifier Structure

An Identifier in a C-FIND request shall contain:

  • Key Attributes values to be matched against the values of storage SOP Instances managed by the SCP.

  • Query/Retrieve Level (0008,0052), which defines the level of the query.

  • Conditionally, the Attribute Query/Retrieve View (0008,0053). This Attribute may be included if Enhanced Multi-Frame Image Conversion has been accepted during Association Extended Negotiation. It shall not be included otherwise.

  • Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier. It shall not be included otherwise.

  • Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if Key Attributes of time are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

The Key Attributes and values allowable for the level of the query shall be defined in the SOP Class definition for the Query/Retrieve Information Model.

C.4.1.1.3.2 Response Identifier Structure

The C-FIND response shall not contain Attributes that were not in the request or specified in this section.

An Identifier in a C-FIND response shall contain:

  • Key Attributes with values corresponding to Key Attributes contained in the Identifier of the request.

    Note

    1. All Required Keys in the Request Identifier, as well as all Optional Keys in the Request Identifier that are supported by the SCP, will therefore be present in the Response Identifier.

    2. Required Keys and supported Optional Keys in the Response Identifier will have zero length if the SCP has no value to send; i.e., there is no requirement that the SCP have a value for these, or create a dummy value.

    3. The requirement that unsupported Optional Keys present in the Request Identifier not be included in the Response Identifier is specified in Section C.2.2.1.3.

  • Query/Retrieve Level (0008,0052), which defines the level of the query. The Query/Retrieve level shall be equal to the level specified in the request.

  • Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Response Identifier. It shall not be included otherwise. The C-FIND SCP is not required to return responses in the Specific Character Set requested by the SCU if that character set is not supported by the SCP. The SCP may return responses with a different Specific Character Set.

  • Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if any Attributes of time in the Response Identifier are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

The C-FIND SCP is required to support either or both the Retrieve AE Title Data Element or the Storage Media File-Set ID/Storage Media File Set UID Data Elements. An Identifier in a C-FIND response shall contain:

  • Storage Media File-Set ID (0088,0130), which defines a user or implementation specific human readable Identifier that identifies the Storage Media on which the Composite Object Instance(s); reside. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Retrieve AE Title Data Element is not present. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

  • Storage Media File-Set UID (0088,0140), which uniquely identifies the Storage Media on which the Composite Object Instance(s) reside. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Retrieve AE Title Data Element is not present. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

    Note

    The File-Set concepts are used in PS3.10.

  • Retrieve AE Title (0008,0054), which defines a list of DICOM Application Entity Title(s) that identify the location from which the Composite Object Instance(s) may be retrieved on the network. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Storage Media File-Set ID and Storage Media File-Set UID elements are not present. The Application Entity named in this field shall support either the C-GET or C-MOVE SOP Class of the Query/Retrieve Service Class. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

    Note

    1. For example, a DICOM AE with the AE Title of "A" performs a C-FIND request to a DICOM AE with the AE Title of "B" with the Query/Retrieve level set to "STUDY". DICOM AE "B" determines that the Composite Object Instances for each matching study may be retrieved by itself and sets the Data Element Retrieve AE Title to "B".

    2. File-Sets may not be defined at every Query/Retrieve Level. If the SCP supports the File-Set ID/File-Set UID option but does not define these Attributes at the Query/Retrieve Level specified in the C-FIND request it may return these Data Elements with a length of 0 to signify that the value is unknown. An SCU should reissue a C-FIND at a Query/Retrieve Level lower in the hierarchy.

    3. The fact that the value of the Key Attribute is unknown to the SCP of the Query/Retrieve Service Class does not imply that it is not present in the underlying Information Object. Thus, a subsequent retrieval may cause a Storage of a SOP Instance that contains the value of the Attribute.

The C-FIND SCP may also, but is not required to, support the Instance Availability (0008,0056) Data Element. This Data Element shall not be included in a C-FIND request. An Identifier in a C-FIND response may contain:

  • Instance Availability (0008,0056), which defines how rapidly Composite Object Instance(s); become available for transmission after a C-MOVE or C-GET retrieval request. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). When some composite instances are less rapidly available than others, the availability of the least rapidly available shall be returned. If this Data Element is not returned, the availability is unknown or unspecified. A null value (Data Element length of 0) is not permitted. The Enumerated Values for this Data Element are:

    • "ONLINE", which means the instances are immediately available,

    • "NEARLINE", which means the instances need to be retrieved from relatively slow media such as optical disk or tape, or require conversion that takes time,

    • "OFFLINE", which means the instances need to be retrieved by manual intervention,

    • "UNAVAILABLE", which means the instances cannot be retrieved. Note that SOP Instances that are unavailable may have an alternate representation that is available (see section Section C.6.1.1.5.1).

C.4.1.1.4 Status

Table C.4-1 defines the specific status code values that might be returned in a C-FIND response. General status code values and fields related to status code values are defined in PS3.7.

Table C.4-1. C-FIND Response Status Values

Service Status

Further Meaning

Status Codes

Related Fields

Failure

Refused: Out of Resources

A700

(0000,0902)

Identifier does not match SOP Class

A900

(0000,0901)

(0000,0902)

Unable to process

Cxxx

(0000,0901)

(0000,0902)

Cancel

Matching terminated due to Cancel request

FE00

None

Success

Matching is complete - No final Identifier is supplied.

0000

None

Pending

Matches are continuing - Current Match is supplied and any Optional Keys were supported in the same manner as Required Keys.

FF00

Identifier

Matches are continuing - Warning that one or more Optional Keys were not supported for existence and/or matching for this Identifier.

FF01

Identifier


C.4.1.2 C-FIND SCU Behavior

This Section discusses both the baseline and extended behavior of the C-FIND SCU.

C.4.1.2.1 Baseline Behavior of SCU

All C-FIND SCUs shall be capable of generating query requests that meet the requirements of the Hierarchical Search.

The Identifier contained in a C-FIND request shall contain a single value in the Unique Key Attribute for each level above the Query/Retrieve level. No Required or Optional Keys shall be specified that are associated with levels above the Query/Retrieve level.

The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching. In addition, Required and Optional Keys associated with the Query/Retrieve level may be contained in the Identifier.

An SCU conveys the following semantics using the C-FIND request:

  • The SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information it possesses down to the Query/Retrieve level specified in the request.

    Note

    1. The SCU may not assume the SCP supports any Optional Keys. Hence, Optional Keys serve only to reduce network related overhead when they are supported by the SCP.

    2. The SCU must be prepared to filter C-FIND responses when the SCP fails to support an Optional Key specified in the C-FIND request.

  • The SCU shall interpret Pending responses to convey the Attributes of a match of an Entity at the level of the query.

  • The SCU shall interpret a response with a status equal to Success, Failed or Refused to convey the end of Pending responses.

  • The SCU shall interpret a Refused or Failed response to a C-FIND request as an indication that the SCP is unable to process the request.

  • The SCU may cancel the C-FIND service by issuing a C-FIND-CANCEL request at any time during the processing of the C-FIND. The SCU shall recognize a status of Canceled to indicate that the C-FIND-CANCEL was successful.

C.4.1.2.2 Extended Behavior of SCU

Extended SCU behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCU behavior shall be performed with respect to that option. Extended SCU behavior includes all baseline behavior with the following option:

  • Relational-queries

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.1.2.2.1 Relational-Queries

The C-FIND Service with relational-queries allows any combination of keys at any level in the hierarchy. The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching. Support for relational-queries removes the baseline restriction that a Unique Key shall be specified for all levels above the Query/Retrieve level in the C-FIND request.

C.4.1.2.2.2 Enhanced Multi-Frame Image Conversion

The C-FIND Service with Enhanced Multi-Frame Image Conversion allows for selection of the default or an alternative view of the instances represented by the Information Model.

Support for Enhanced Multi-Frame Image Conversion allows the SCU to specify the Query/Retrieve View (0008,0053) in the Request Identifier with a value of either "CLASSIC" or "ENHANCED".

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about the instances that it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Note

  1. The SCU may assume that no duplicate information will be returned. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-FIND will not return both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. Unconverted instances, such as for other modalities like Ultrasound, will appear identical regardless of view.

  4. Implementations may apply performance optimizations, such as pre-computing or caching the potential information against which CLASSIC and ENHANCED queries may be performed, in order to minimize significant delays between the query request and response caused by converting "on demand", but SCUs may need to consider the potential for a delayed response when configuring timeouts, etc.

C.4.1.3 C-FIND SCP Behavior

This Section discusses both the baseline and extended behavior of the C-FIND SCP.

C.4.1.3.1 Baseline Behavior of SCP

All C-FIND SCPs shall be capable of processing queries that meet the requirements of the Hierarchical Search.

An SCP conveys the following semantics with a C-FIND response:

  • The SCP is requested to perform a match of all the keys specified in the Identifier of the request, against the information it possesses, to the level specified in the request. Attribute matching is performed using the key values specified in the Identifier of the C-FIND request as defined in Section C.2.

  • The SCP generates a C-FIND response for each match using the Hierarchical Search method. All such responses shall contain an Identifier whose Attributes contain values from a single match. All such responses shall contain a status of Pending.

  • When all matches have been sent, the SCP generates a C-FIND response that contains a status of Success. A status of Success shall indicate that a response has been sent for each match known to the SCP.

    Note

    When there are no matches, then no responses with a status of Pending are sent, only a single response with a status of Success.

  • The SCP shall generate a response with a status of Refused or Failed if it is unable to process the request. A Refused or Failed response shall contain no Identifier.

  • If the SCP receives C-FIND-CANCEL indication before it has completed the processing of the matches it shall interrupt the matching process and return a status of Canceled.

  • If the SCP manages images in multiple alternate encodings (see Section C.6.1.1.5.1), only one of the alternate encodings of an image shall be included in the set of matches for a C-FIND request at the Instance level.

    Note

    For query of images with alternate encodings, the SCP may select the appropriately encoded Instance for the request response based on identity of the SCU or other factors.

C.4.1.3.1.1 Hierarchical Search Method

Starting at the top level in the Query/Retrieve Information Model, continuing until the level specified in the C-FIND request is reached, the following procedures are used to generate matches:

  1. If the current level is the level specified in the C-FIND request, then the key match strings contained in the Identifier of the C-FIND request are matched against the values of the Key Attributes for each entity at the current level. For each entity for which the Attributes match all of the specified match strings, construct an Identifier. This Identifier shall contain all of the Unique Keys at higher levels and all of the values of the Attributes for this entity that match those in the C-FIND request. Return a response for each such Identifier. If there are no matching keys, then there are no matches, return a response with a status equal to Success and with no Identifier.

  2. Otherwise, if the current level is not the level specified in the C-FIND request and there is an entity matching the Unique Key Attribute value for this level specified in the C-FIND request, perform this procedure at the next level down in the hierarchy.

  3. Otherwise there are no matches; return a response with a status equal to Success.

    Note

    The above description specifies a recursive procedure. It may recur upon itself multiple times as it goes down the hierarchical levels, but at each level it recurs only once.

C.4.1.3.2 Extended Behavior of SCP

Extended SCP behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCP behavior shall be performed with respect to that option. Extended SCP behavior includes all baseline behavior with the following option:

  • Relational-queries

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.1.3.2.1 Relational-Queries

The C-FIND Service with relational-queries allows any combination of keys at any level in the hierarchy. At the lowest level, a query using the relational-queries shall contain the Unique Key for that level with either a single value match, a wild card match, or a universal match. Support for relational-queries removes the baseline restriction that a Unique Key shall be specified for all levels above the Query/Retrieve level in the C-FIND request.

The C-FIND SCP shall perform matching based on all keys specified in the C-FIND request regardless of the Query/Retrieve level.

C.4.1.3.2.2 Relational Search Method

A query using the relational method may contain any combination of keys at any level in the hierarchy. Starting at the top level in the Query/Retrieve Information Model, continuing until the Query/Retrieve level specified in the C-FIND request is reached, the following procedures are used to generate matches:

  1. The key match strings contained in the Identifier of the C-FIND request are matched against the values of the Key Attributes for each entity at the current level.

  2. If no Key Attribute is specified at the current level and the current level is not the level specified in the C-FIND request, the match shall be performed as if a wild card were specified for the Unique Key Attribute for the current level (i.e., all entities at the current level shall match).

  3. If the current level is the level specified in the C-FIND request, then for each matching entity (a matching entity is one for which the Attributes match all of the specified match strings in the Key Attributes), construct an Identifier. This Identifier shall contain all of the Attributes generated by this procedure at higher levels on this recursion path and all of the values of the Key Attributes for this entity that match those in the C-FIND request.

  4. Otherwise, if the current level is not the level specified in the C-FIND request, then for each matching entity construct a list of Attributes containing all of the matching Key Attributes and all Attributes that were prepared at the previous level for this entity. Then perform this procedure at the next level down in the hierarchy for each matching entity.

  5. Otherwise, if there are no matches, return a response with status equal to Success and no Identifier.

Note

  1. The above description specifies a recursive procedure. It may recur upon itself multiple times as it goes down the hierarchical levels, and at each level, it may recur multiple times (one for each matching entity). This may result in a large number of Identifiers being generated.

  2. It is not required that the above defined procedure be used to generate matches. It is expected that implementations will incorporate different algorithms for performing searches of the databases. For a given query, the set of matches shall be equivalent to that which would be generated by the above procedure.

C.4.1.3.2.3 Enhanced Multi-Frame Image Conversion

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about the instances that it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Note

  1. The SCP will not return information that is duplicated. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-FIND will not return both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. Unconverted instances, such as for other modalities like Ultrasound, will appear identical regardless of view.

C.4.2 C-MOVE Operation

SCUs of some SOP Classes of the Query/Retrieve Service Class may generate retrievals using the C-MOVE operation as described in PS3.7. The C-MOVE operation allows an application entity to instruct another application entity to transfer stored SOP Instances to another application entity using the C-STORE operation. Support for the C-MOVE service shall be agreed upon at Association establishment time by both the SCU and SCP of the C-MOVE in order for a C-MOVE operation to occur over the Association. The C-STORE sub-operations shall always be accomplished over an Association different from the Association that accomplishes the C-MOVE operation. Hence, the SCP of the Query/Retrieve Service Class serves as the SCU of the Storage Service Class.

Note

The application entity that receives the stored SOP Instances may or may not be the originator of the C-MOVE operation.

A C-MOVE request may be performed to any level of the Query/Retrieve Information Model. However, the transfer of stored SOP Instances may not be performed at this level. The level at which the transfer is performed depends upon the SOP Class (see Section C.6).

C.4.2.1 C-MOVE Service Parameters

C.4.2.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-MOVE is to be performed. Support for the SOP Class UID is implied by the Abstract Syntax UID of the Presentation Context used by this C-MOVE operation.

C.4.2.1.2 Priority

The Priority Attribute defines the requested priority of the C-MOVE operation and corresponding C-STORE sub-operations with respect to other DIMSE operations being performed by the same SCP.

Processing of priority requests is not required of SCPs. Whether or not an SCP supports priority processing, and the meaning of the different priority levels shall be stated in the Conformance Statement of the SCP. The same priority shall be used for all C-STORE sub-operations.

C.4.2.1.3 Move Destination

Move Destination specifies the Application Entity Title of the receiver of the C-STORE sub-operations.

C.4.2.1.4 Identifier

The C-MOVE request shall contain an Identifier. The C-MOVE response shall conditionally contain an Identifier as required in Section C.4.2.1.4.2.

Note

The Identifier is specified as U in the definition of the C-MOVE primitive in PS3.7 but is specialized for use with this service.

C.4.2.1.4.1 Request Identifier Structure

An Identifier in a C-MOVE request shall contain:

  • Query/Retrieve Level (0008,0052), which defines the level of the retrieval

  • Unique Key Attributes, which may include Patient ID (0010,0020), Study Instance UIDs (0020,000D), Series Instance UIDs (0020,000E), and the SOP Instance UIDs (0008,0018)

  • Conditionally, the Attribute Query/Retrieve View (0008,0053). This Attribute may be included if Enhanced Multi-Frame Image Conversion has been accepted during Association Extended Negotiation. It shall not be included otherwise.

Specific Character Set (0008,0005) shall be present if Patient ID (0010,0020) is using a character set other than the default character repertoire.

The Unique Keys at each level of the hierarchy and the values allowable for the level of the retrieval shall be defined in the SOP Class definition for the Query/Retrieve Information Model.

Note

In the non-Relational behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching, but only Single Value Matching value may be specified for Patient ID (0010,0020).

C.4.2.1.4.2 Response Identifier Structure

The Failed SOP Instance UID List (0008,0058) specifies a list of UIDs of the C-STORE sub-operation SOP Instances for which this C-MOVE operation has failed. An Identifier in a C-MOVE response shall conditionally contain the Failed SOP Instance UID List (0008,0058) based on the C-MOVE response status value. If no C-STORE sub-operation failed, Failed SOP Instance UID List (0008,0058) is absent and therefore no Data Set shall be sent in the C-MOVE response.

Specific Character Set (0008,0005) shall not be present.

The Identifier in a C-MOVE response with a status of:

  • Canceled, Failure, Refused, or Warning shall contain the Failed SOP Instance UID List Attribute

  • Pending shall not contain the Failed SOP Instance UID List Attribute (no Data Set)

C.4.2.1.5 Status

Table C.4-2 defines the specific status code values that might be returned in a C-MOVE response. General status code values and fields related to status code values are defined in PS3.7.

Table C.4-2. C-MOVE Response Status Values

Service Status

Further Meaning

Status Codes

Related Fields

Failure

Refused: Out of Resources - Unable to calculate number of matches

A701

(0000,0902)

Refused: Out of Resources - Unable to perform sub-operations

A702

(0000,1021)

(0000,1022)

(0000,1023)

Refused: Move Destination unknown

A801

(0000,0902)

Identifier does not match SOP Class

A900

(0000,0901)

(0000,0902)

Unable to Process

Cxxx

(0000,0901)

(0000,0902)

Cancel

Sub-operations terminated due to Cancel Indication

FE00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Warning

Sub-operations Complete - One or more Failures

B000

(0000,1021)

(0000,1022)

(0000,1023)

Success

Sub-operations Complete - No Failures

0000

(0000,1021)