PS3.2

DICOM PS3.2 2017d - Conformance

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. ACSE Service Definitions
3.3. Presentation Service Definitions
3.4. DICOM Introduction and Overview Definitions
3.5. DICOM Information Object Definitions
3.6. DICOM Service Class Specification Definitions
3.7. DICOM Data Structure and Encoding Definitions
3.8. DICOM Message Exchange Definitions
3.9. DICOM Upper Layer Service Definitions
3.10. Media Storage and File Format for Data Interchange
3.11. DICOM Conformance
3.11.1. Conformance Statement
3.11.2. Standard SOP Class
3.11.3. Standard Extended SOP Class
3.11.4. Specialized SOP Class
3.11.5. Private SOP Class
3.11.6. Standard Attribute
3.11.7. Private Attribute
3.11.8. Standard Application Profile
3.11.9. Augmented Application Profile
3.11.10. Private Application Profile
3.11.11. Security Profile
3.11.12. Transformation of DICOM SR to CDA
4. Symbols and Abbreviations
5. Conventions
5.1. Application Data Flow Diagram
5.1.1. Application Entity
5.1.2. Real-World Activity
5.1.3. Local Relationships
5.1.4. Network-Associations
5.1.5. Media Storage File-Set Access
6. Purpose of a Conformance Statement
6.1. Overview of Networking Section for Conformance Statements
6.2. Overview of Media Storage Section for Conformance Statements
7. Conformance Requirements
7.1. DICOM Network Conformance Requirements
7.2. DICOM Media Interchange Conformance Requirements
7.3. Rules Governing Types of SOP Classes
7.4. Rules Governing Types of Application Profiles
7.4.1. Standard Application Profile
7.4.2. Augmented Application Profile
7.4.3. Private Application Profile
7.5. Conformance of DICOM Media
7.6. Security Profiles
7.7. Transformation of DICOM SR to CDA
A. DICOM Conformance Statement Template (Normative)
A.0. Cover Page
A.1. Conformance Statement Overview
A.2. Table of Contents
A.3. Introduction
A.3.1. Revision History
A.3.2. Audience
A.3.3. Remarks
A.3.4. Terms and Definitions
A.3.5. Basics of DICOM Communication
A.3.6. Abbreviations
A.3.7. References
A.4. Networking
A.4.1. Implementation Model
A.4.1.1. Application Data Flow
A.4.1.2. Functional Definition of AEs
A.4.1.2.1. Functional Definition of "Application Entity <1>"
A.4.1.2.2. Functional Definition of "Application Entity <2>"
A.4.1.2.3. Functional Definition of "Application Entity <3>"
A.4.1.3. Sequencing of Real World Activities
A.4.2. AE Specifications:
A.4.2.1. "Application Entity <1>"
A.4.2.1.1. SOP Classes
A.4.2.1.2. Association Policies
A.4.2.1.2.1. General
A.4.2.1.2.2. Number of Associations.
A.4.2.1.2.3. Asynchronous Nature
A.4.2.1.2.4. Implementation Identifying Information
A.4.2.1.3. Association Initiation Policy
A.4.2.1.3.1. "Activity <1>"
A.4.2.1.3.1.1. Description and Sequencing of Activities
A.4.2.1.3.1.2. Proposed Presentation Contexts
A.4.2.1.3.1.3. SOP Specific Conformance for SOP Class(Es)
A.4.2.1.4. Association Acceptance Policy
A.4.2.1.4.1. "Activity <2>"
A.4.2.1.4.1.1. Description and Sequencing of Activities
A.4.2.1.4.1.2. Accepted Presentation Contexts
A.4.2.1.4.1.3. SOP Specific Conformance for SOP Class(Es)
A.4.2.2. "Application Entity <1>"
A.4.2.2.1. Retired
A.4.2.2.2. WADO-URI Specifications
A.4.2.2.3. Restful Services Specifications
A.4.2.3. "Application Entity <2>"
A.4.3. Network Interfaces
A.4.3.1. Physical Network Interface
A.4.3.2. Additional Protocols
A.4.3.3. IPv4 and IPv6 Support
A.4.4. Configuration
A.4.4.1. AE Title/Presentation Address Mapping
A.4.4.1.1. Local AE Titles.
A.4.4.1.2. Remote AE Title/Presentation Address Mapping
A.4.4.1.2.1. Remote SCP 1
A.4.4.1.2.2. Remote SCP 2
A.4.4.2. Parameters
A.5. Media Interchange
A.5.1. Implementation Model
A.5.1.1. Application Data Flow Diagram
A.5.1.2. Functional Definitions of AEs
A.5.1.3. Sequencing of Real World Activities
A.5.1.4. File Meta Information for Implementation Class and Version
A.5.2. AE Specifications
A.5.2.1. "Application Entity <1>" - Specification
A.5.2.1.1. File Meta Information for the "Application Entity <1>"
A.5.2.1.2. Real-World Activities
A.5.2.1.2.i. "Real-World Activity <i>"
A.5.2.1.2.i.1. Media Storage Application Profile
A.5.2.1.2.i.1.y. Options
A.5.2.2. "Application Entity <2>" - Specification
A.5.3. Augmented and Private Application Profiles
A.5.3.1. Augmented Application Profiles
A.5.3.1.1. "Augmented Application Profile <1>"
A.5.3.1.1.1. SOP Class Augmentations
A.5.3.1.1.2. Directory Augmentations
A.5.3.1.1.3. Other Augmentations
A.5.3.1.2. "Augmented Application Profile <2>"
A.5.3.2. Private Application Profiles
A.5.4. Media Configuration
A.6. Transformation of DICOM to CDA
A.7. Support of Character Sets
A.8. Security
A.8.1. Security Profiles
A.8.2. Association Level Security
A.8.3. Application Level Security
A.9. Annexes
A.9.1. IOD Contents
A.9.1.1. Created SOP Instance(s)
A.9.1.2. Usage of Attributes From Received IODs
A.9.1.3. Attribute Mapping
A.9.1.4. Coerced/Modified Fields
A.9.2. Data Dictionary of Private Attributes
A.9.3. Coded Terminology and Templates
A.9.3.1. Context Groups
A.9.3.2. Template Specifications
A.9.3.3. Private Code Definitions
A.9.4. Grayscale Image Consistency
A.9.5. Standard Extended/Specialized/Private SOP Classes
A.9.5.1. Standard Extended/Specialized/Private SOP <i>
A.9.6. Private Transfer Syntaxes
A.9.6.1. Private Transfer Syntax <i>
B. Conformance Statement Sample Integrated Modality (Informative)
B.0. Cover Page
B.1. Conformance Statement Overview
B.2. Table of Contents
B.3. Introduction
B.3.1. Revision History
B.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
B.3.3. Additional Remarks for This Example
B.4. Networking
B.4.1. Implementation Model
B.4.1.1. Application Data Flow
B.4.1.2. Functional Definition of AEs
B.4.1.2.1. Functional Definition of Storage Application Entity
B.4.1.2.2. Functional Definition of Workflow Application Entity
B.4.1.2.3. Functional Definition of Hardcopy Application Entity
B.4.1.3. Sequencing of Real-World Activities
B.4.2. AE Specifications
B.4.2.1. Storage Application Entity Specification
B.4.2.1.1. SOP Classes
B.4.2.1.2. Association Policies
B.4.2.1.2.1. General
B.4.2.1.2.2. Number of Associations
B.4.2.1.2.3. Asynchronous Nature
B.4.2.1.2.4. Implementation Identifying Information
B.4.2.1.3. Association Initiation Policy
B.4.2.1.3.1. Activity - Send Images
B.4.2.1.3.1.1. Description and Sequencing of Activities
B.4.2.1.3.1.2. Proposed Presentation Contexts
B.4.2.1.3.1.3. SOP Specific Conformance Image & Pres State Storage SOP Classes
B.4.2.1.3.1.4. SOP Specific Conformance for Storage Commitment SOP Class
B.4.2.1.3.1.4.1. Storage Commitment Operations (N-ACTION)
B.4.2.1.3.1.4.2. Storage Commitment Notifications (N-EVENT-REPORT)
B.4.2.1.4. Association Acceptance Policy
B.4.2.1.4.1. Activity - Receive Storage Commitment Response
B.4.2.1.4.1.1. Description and Sequencing of Activities
B.4.2.1.4.1.2. Accepted Presentation Contexts
B.4.2.1.4.1.3. SOP Specific Conformance for Storage Commitment SOP Class
B.4.2.1.4.1.3.1. Storage Commitment Notifications (N-EVENT-REPORT)
B.4.2.1.4.1.4. SOP Specific Conformance for Verification SOP Class
B.4.2.2. Workflow Application Entity Specification
B.4.2.2.1. SOP Classes
B.4.2.2.2. Association Policies
B.4.2.2.2.1. General
B.4.2.2.2.2. Number of Associations
B.4.2.2.2.3. Asynchronous Nature
B.4.2.2.2.4. Implementation Identifying Information
B.4.2.2.3. Association Initiation Policy
B.4.2.2.3.1. Activity - Worklist Update
B.4.2.2.3.1.1. Description and Sequencing of Activities
B.4.2.2.3.1.2. Proposed Presentation Contexts
B.4.2.2.3.1.3. SOP Specific Conformance for Modality Worklist
B.4.2.2.3.2. Activity - Acquire Images
B.4.2.2.3.2.1. Description and Sequencing of Activities
B.4.2.2.3.2.2. Proposed Presentation Contexts
B.4.2.2.3.2.3. SOP Specific Conformance for MPPS
B.4.2.2.4. Association Acceptance Policy
B.4.2.3. Hardcopy Application Entity Specification
B.4.2.3.1. SOP Classes
B.4.2.3.2. Association Policies
B.4.2.3.2.1. General
B.4.2.3.2.2. Number of Associations
B.4.2.3.2.3. Asynchronous Nature
B.4.2.3.2.4. Implementation Identifying Information
B.4.2.3.3. Association Initiation Policy
B.4.2.3.3.1. Activity - Film Images
B.4.2.3.3.1.1. Description and Sequencing of Activities
B.4.2.3.3.1.2. Proposed Presentation Contexts
B.4.2.3.3.1.3. Common SOP Specific Conformance for All Print SOP Classes
B.4.2.3.3.1.4. SOP Specific Conformance for the Printer SOP Class
B.4.2.3.3.1.4.1. Printer SOP Class Operations (N-GET)
B.4.2.3.3.1.4.2. Printer SOP Class Notifications (N-EVENT-REPORT)
B.4.2.3.3.1.5. SOP Specific Conformance for the Film Session SOP Class
B.4.2.3.3.1.5.1. Film Session SOP Class Operations (N-CREATE)
B.4.2.3.3.1.5.2. Film Session SOP Class Operations (N-DELETE)
B.4.2.3.3.1.6. SOP Specific Conformance for the Presentation LUT SOP Class
B.4.2.3.3.1.6.1. Presentation LUT SOP Class Operations (N-CREATE)
B.4.2.3.3.1.7. SOP Specific Conformance for the Film Box SOP Class
B.4.2.3.3.1.7.1. Film Box SOP Class Operations (N-CREATE)
B.4.2.3.3.1.7.2. Film Box SOP Class Operations (N-ACTION)
B.4.2.3.3.1.8. SOP Specific Conformance for the Image Box SOP Class
B.4.2.3.3.1.8.1. Image Box SOP Class Operations (N-SET)
B.4.2.3.4. Association Acceptance Policy
B.4.3. Network Interfaces
B.4.3.1. Physical Network Interface
B.4.3.2. Additional Protocols
B.4.3.2.1. DHCP
B.4.3.2.2. DNS
B.4.3.2.3. NTP
B.4.3.2.4. LDAP
B.4.3.3. IPv4 and IPv6 Support
B.4.4. Configuration
B.4.4.1. AE Title/Presentation Address Mapping
B.4.4.1.1. Local AE Titles
B.4.4.1.1.1. Obtaining Local Configuration From LDAP Server
B.4.4.1.1.2. Publishing Local Configuration to LDAP Server
B.4.4.1.2. Remote AE Title/Presentation Address Mapping
B.4.4.1.2.1. Storage
B.4.4.1.2.2. Workflow
B.4.4.1.2.3. Hardcopy
B.4.4.2. Parameters
B.5. Media Interchange
B.5.1. Implementation Model
B.5.1.1. Application Data Flow
B.5.1.2. Functional Definition of AEs
B.5.1.2.1. Functional Definition of Offline-Media Application Entity
B.5.1.3. Sequencing of Real-World Activities
B.5.1.4. File Meta Information Options
B.5.2. AE Specifications
B.5.2.1. Offline-Media Application Entity Specification
B.5.2.1.1. File Meta Information for the Application Entity
B.5.2.1.2. Real-World Activities
B.5.2.1.2.1. Activity - Export to CD-R
B.5.2.1.2.1.1. Media Storage Application Profiles
B.5.2.1.2.1.1.1. Options
B.5.3. Augmented and Private Application Profiles
B.5.4. Media Configuration
B.6. Support of Character Sets
B.7. Security
B.8. Annexes
B.8.1. IOD Contents
B.8.1.1. Created SOP Instances
B.8.1.1.1. X-Ray Radiofluoroscopic Image IOD
B.8.1.1.2. Grayscale Softcopy Presentation State IOD
B.8.1.1.3. Common Modules
B.8.1.1.4. X-Ray Radiofluoroscopic Image Modules
B.8.1.1.5. Grayscale Softcopy Presentation State Modules
B.8.1.2. Used Fields in Received IOD By Application
B.8.1.3. Attribute Mapping
B.8.1.4. Coerced/Modified Fields
B.8.2. Data Dictionary of Private Attributes
B.8.3. Coded Terminology and Templates
B.8.4. Grayscale Image Consistency
B.8.5. Standard Extended / Specialized / Private SOP Classes
B.8.5.1. X-Ray Radiofluoroscopic Image Storage SOP Class
B.8.6. Private Transfer Syntaxes
C. Conformance Statement Sample DICOMRis Interface (Informative)
C.0. Cover Page
C.1. Conformance Statement Overview
C.2. Table of Contents
C.3. Introduction
C.3.1. Revision History
C.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
C.3.3. Additional References for This Example
C.3.4. Additional Remarks and Definitions for This Example
C.4. Networking
C.4.1. Implementation Model
C.4.1.1. Application Data Flow
C.4.1.2. Functional Definition of AEs
C.4.1.2.1. Functional Definition of DICOMSRV Application Entity
C.4.1.3. Sequencing of Real World Activities
C.4.2. AE Specifications
C.4.2.1. DICOMSRV AE Specification
C.4.2.1.1. SOP Classes
C.4.2.1.2. Association Policies
C.4.2.1.2.1. General
C.4.2.1.2.2. Number of Associations
C.4.2.1.2.3. Asynchronous Nature
C.4.2.1.2.4. Implementation Identifying Information
C.4.2.1.3. Association Initiation Policy
C.4.2.1.4. Association Acceptance Policy
C.4.2.1.4.1. Activity - Configured AE Requests MWL Query
C.4.2.1.4.1.1. Description and Sequencing of Activities
C.4.2.1.4.1.2. Accepted Presentation Contexts
C.4.2.1.4.1.2.1. Presentation Context Acceptance Criterion
C.4.2.1.4.1.2.2. Transfer Syntax Selection Policy
C.4.2.1.4.1.3. SOP Specific Conformance for Modality Worklist SOP Class
C.4.2.1.4.2. Activity - Configured AE Makes Procedure Step Request
C.4.2.1.4.2.1. Description and Sequencing of Activities
C.4.2.1.4.2.2. Accepted Presentation Contexts
C.4.2.1.4.2.3. SOP Specific Conformance for MPPS SOP Class
C.4.2.1.4.3. Activity - Configured AE Requests Verification
C.4.2.1.4.3.1. Description and Sequencing of Activities
C.4.2.1.4.3.2. Accepted Presentation Contexts
C.4.2.1.4.3.3. SOP Specific Conformance
C.4.2.1.4.3.4. Presentation Context Acceptance Criterion
C.4.2.1.4.3.5. Transfer Syntax Selection Policy
C.4.3. Network Interfaces
C.4.3.1. Physical Network Interface
C.4.3.2. Additional Protocols
C.4.3.3. IPv4 and IPv6 Support
C.4.4. Configuration
C.4.4.1. AE Title/Presentation Address Mapping
C.4.4.1.1. Local AE Titles
C.4.4.1.2. Remote AE Title/Presentation Address Mapping
C.4.4.2. Parameters
C.5. Media Interchange
C.6. Support of Character Sets
C.7. Security
C.8. Annexes
C.8.1. IOD Contents
C.8.1.1. Created SOP Instances
C.8.1.2. Usage of Attributes From Received IODs
C.8.1.3. Attribute Mapping
C.8.1.4. Coerced/Modified Fields
C.8.2. Data Dictionary of Private Attributes
C.8.3. Coded Terminology and Templates
C.8.4. Grayscale Image Consistency
C.8.5. Standard Extended/Specialized/Private SOP Classes
C.8.6. Private Transfer Syntaxes
D. Conformance Statement Sample DICOM Image Viewer (Informative)
D.0. Cover Page
D.1. Conformance Statement Overview
D.2. Table of Contents
D.3. Introduction
D.3.1. Revision History
D.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
D.3.3. Additional Remarks for This Example
D.4. Networking
D.4.1. Implementation Model
D.4.1.1. Application Data Flow
D.4.1.2. Functional Definitions of AEs
D.4.1.2.1. ECHO-SCP
D.4.1.2.2. STORAGE-SCP
D.4.1.2.3. STORAGE-SCU
D.4.1.2.4. FIND-SCU
D.4.1.2.5. MOVE-SCU
D.4.1.3. Sequencing of Real-World Activities
D.4.2. AE Specifications
D.4.2.1. ECHO-SCP
D.4.2.1.1. SOP Classes
D.4.2.1.2. Association Policies
D.4.2.1.2.1. General
D.4.2.1.2.2. Number of Associations
D.4.2.1.2.3. Asynchronous Nature
D.4.2.1.2.4. Implementation Identifying Information
D.4.2.1.3. Association Initiation Policy
D.4.2.1.4. Association Acceptance Policy
D.4.2.1.4.1. Activity- Receive Echo Request
D.4.2.1.4.1.1. Description and Sequencing of Activities
D.4.2.1.4.1.2. Accepted Presentation Contexts
D.4.2.1.4.1.2.1. Extended Negotiation
D.4.2.1.4.1.3. SOP Specific Conformance
D.4.2.1.4.1.3.1. SOP Specific Conformance to Verification SOP Class
D.4.2.1.4.1.3.2. Presentation Context Acceptance Criterion
D.4.2.1.4.1.3.3. Transfer Syntax Selection Policies
D.4.2.2. STORAGE-SCP
D.4.2.2.1. SOP Classes
D.4.2.2.2. Association Policies
D.4.2.2.2.1. General
D.4.2.2.2.2. Number of Associations
D.4.2.2.2.3. Asynchronous Nature
D.4.2.2.2.4. Implementation Identifying Information
D.4.2.2.3. Association Initiation Policy
D.4.2.2.4. Association Acceptance Policy
D.4.2.2.4.1. Activity - Receive Storage Request
D.4.2.2.4.1.1. Description and Sequencing of Activities
D.4.2.2.4.1.2. Accepted Presentation Contexts
D.4.2.2.4.1.2.1. Extended Negotiation
D.4.2.2.4.1.3. SOP Specific Conformance
D.4.2.2.4.1.3.1. SOP Specific Conformance to Storage SOP Classes
D.4.2.2.4.1.3.2. Presentation Context Acceptance Criterion
D.4.2.2.4.1.3.3. Transfer Syntax Selection Policies
D.4.2.2.4.1.3.4. Response Status
D.4.2.3. STORAGE-SCU
D.4.2.3.1. SOP Classes
D.4.2.3.2. Association Policies
D.4.2.3.2.1. General
D.4.2.3.2.2. Number of Associations
D.4.2.3.2.3. Asynchronous Nature
D.4.2.3.2.4. Implementation Identifying Information
D.4.2.3.3. Association Initiation Policy
D.4.2.3.3.1. Activity - Send Storage Request
D.4.2.3.3.1.1. Description and Sequencing of Activities
D.4.2.3.3.1.2. Proposed Presentation Contexts
D.4.2.3.3.1.2.1. Extended Negotiation
D.4.2.3.3.1.3. SOP Specific Conformance
D.4.2.3.3.1.3.1. SOP Specific Conformance to Storage SOP Classes
D.4.2.3.3.1.3.2. Presentation Context Acceptance Criterion
D.4.2.3.3.1.3.3. Transfer Syntax Selection Policies
D.4.2.3.3.1.3.4. Response Status
D.4.2.3.4. Association Acceptance Policy
D.4.2.4. FIND-SCU
D.4.2.4.1. SOP Classes
D.4.2.4.2. Association Policies
D.4.2.4.2.1. General
D.4.2.4.2.2. Number of Associations
D.4.2.4.2.3. Asynchronous Nature
D.4.2.4.2.4. Implementation Identifying Information
D.4.2.4.3. Association Initiation Policy
D.4.2.4.3.1. Activity - Query Remote AE
D.4.2.4.3.1.1. Description and Sequencing of Activities
D.4.2.4.3.1.2. Proposed Presentation Contexts
D.4.2.4.3.1.2.1. Extended Negotiation
D.4.2.4.3.1.3. SOP Specific Conformance
D.4.2.4.3.1.3.1. SOP Specific Conformance to C-FIND SOP Classes
D.4.2.4.3.1.3.2. Presentation Context Acceptance Criterion
D.4.2.4.3.1.3.3. Transfer Syntax Selection Policies
D.4.2.4.3.1.3.4. Response Status
D.4.2.4.4. Association Acceptance Policy
D.4.2.5. MOVE-SCU
D.4.2.5.1. SOP Classes
D.4.2.5.2. Association Policies
D.4.2.5.2.1. General
D.4.2.5.2.2. Number of Associations
D.4.2.5.2.3. Asynchronous Nature
D.4.2.5.2.4. Implementation Identifying Information
D.4.2.5.3. Association Initiation Policy
D.4.2.5.3.1. Activity - Retrieve From Remote AE
D.4.2.5.3.1.1. Description and Sequencing of Activities
D.4.2.5.3.1.2. Proposed Presentation Contexts
D.4.2.5.3.1.2.1. Extended Negotiation
D.4.2.5.3.1.3. SOP Specific Conformance
D.4.2.5.3.1.3.1. SOP Specific Conformance to C-FIND SOP Classes
D.4.2.5.3.1.3.2. Presentation Context Acceptance Criterion
D.4.2.5.3.1.3.3. Transfer Syntax Selection Policies
D.4.2.5.3.1.3.4. Response Status
D.4.2.5.3.1.3.5. Sub-Operation Dependent Behavior
D.4.2.5.4. Association Acceptance Policy
D.4.3. Network Interfaces
D.4.3.1. Physical Network Interface
D.4.3.2. Additional Protocols
D.4.3.3. IPv4 and IPv6 Support
D.4.4. Configuration
D.4.4.1. AE Title/Presentation Address Mapping
D.4.4.2. Parameters
D.5. Media Interchange
D.5.1. Implementation Model
D.5.1.1. Application Data Flow
D.5.1.2. Functional Definitions of AEs
D.5.1.2.1. MEDIA-FSR
D.5.1.3. Sequencing of Real-World Activities
D.5.2. AE Specifications
D.5.2.1. MEDIA-FSR
D.5.2.1.1. File Meta Information for the Application Entity
D.5.2.1.2. Real World Activities
D.5.2.1.2.1. Activity - Load Directory or File
D.5.2.1.2.1.1. Application Profile Specific Conformance
D.5.3. Augmented and Private Profiles
D.5.3.1. Augmented Profiles
D.5.3.2. Private Profiles
D.5.4. Media Configuration
D.6. Support of Character Sets
D.6.1. Overview
D.6.2. Character Sets
D.6.3. Character Set Configuration
D.7. Security
D.7.1. Security Profiles
D.7.2. Association Level Security
D.7.3. Application Level Security
D.8. Annexes
D.8.1. IOD Contents
D.8.1.1. Created SOP Instances
D.8.1.2. Usage of Attributes From Received IODs
D.8.1.3. Attribute Mapping
D.8.1.4. Coerced/Modified Fields
D.8.2. Data Dictionary of Private Attributes
D.8.3. Coded Terminology and Templates
D.8.4. Grayscale Image Consistency
D.8.5. Standard Extended/Specialized/Private SOP Classes
D.8.6. Private Transfer Syntaxes
E. Conformance Statement Example Print Server (Informative)
E.0. Cover Page
E.1. Conformance Statement Overview
E.2. Table of Contents
E.3. Introduction
E.3.1. Revision History
E.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
E.3.3. Additional Remarks for This Example
E.4. Networking
E.4.1. Implementation Model
E.4.1.1. Application Data Flow
E4.1.2. Functional Definition of AEs
E.4.1.2.1. Functional Definition of Print Server (SCP) Application Entity
E.4.1.3. Sequencing of Real-World Activities
E.4.2. AE Specifications
E.4.2.1. Print Server Management (SCP) Application Entity Specification
E.4.2.1.1. SOP Classes
E.4.2.1.2. Association Establishment Policy
E.4.2.1.2.1. General
E.4.2.1.2.2. Number of Associations
E.4.2.1.2.3. Asynchronous Nature
E.4.2.1.2.4. Implementation Identifying Information
E.4.2.1.3. Association Initiation Policy
E.4.2.1.3.1. Activity - Connectivity Verification
E.4.2.1.3.1.1. Description and Sequencing of Activities
E.4.2.1.3.1.2. Proposed Presentation Context Table
E.4.2.1.3.1.3. SOP Specific Conformance for Connectivity Verification
E.4.2.1.4. Association Acceptance Policy
E.4.2.1.4.1. Activity - Print Server Management
E.4.2.1.4.1.1. Description and Sequencing of Activities
E.4.2.1.4.1.2. Accepted Presentation Contexts
E.4.2.1.4.1.3. SOP Specific Conformance
E.4.2.1.4.1.3.1. Specific Conformance for Verification SOP Class
E.4.2.1.4.1.3.2. Specific Conformance to Grayscale Print Management Meta SOP Class
E.4.2.1.4.1.3.3. Specific Conformance to Basic Annotation Box SOP Class
E.4.2.1.4.1.3.4. Specific Conformance to Print Job Box SOP Class
E.4.2.1.4.1.3.5. Specific Conformance for Presentation LUT Box SOP Class
E.4.2.1.4.1.3.6. Specific Conformance for Printer Configuration SOP Class
E.4.3. Network Interfaces
E.4.3.1. Physical Network Interface
E.4.3.2. Additional Protocols
E.4.3.3. IPv4 and IPv6 Support
E.4.4. Configuration
E.4.4.1. AE Title/Presentation Address Mapping
E4.4.1.1. Local AE Titles
E.4.4.1.2. Remote AE Title/Presentation Address Mapping
E.4.4.1.2.1. Print Server Management
E.4.4.2. Parameters
E.5. Media Interchange
E.6. Support of Character Sets
E.7. Security
E.8. Annexes
E.8.1. IOD Contents
E.8.1.1. Created IOD Instance(s)
E.8.1.2. Usage of Attributes From Received IODs
E.8.1.3. Attribute Mapping
E.8.1.4. Coerced/Modified Fields
E.8.2. Data Dictionary of Private Attributes
E.8.3. Coded Terminology and Templates
E.8.4. Grayscale Image Consistency
E.8.5. Standard Extended / Specialized / Private SOP Classes
E.8.5.1. Standard Extended Basic Film Session SOP Class
E.8.5.2. Standard Extended Basic Film Box SOP Class
E.8.5.3. Standard Extended Basic Grayscale Image Box SOP Class
E.8.6. Private Transfer Syntaxes
F. DICOM Conformance Statement Query-Retrieve-Server (Informative)
F.0. Cover Page
F.1. Conformance Statement Overview
F.2. Table of Contents
F.3. Introduction
F.3.1. Revision History
F.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
F.3.3. Additional Remarks for This Example
F.4. Networking
F.4.1. Implementation Model
F.4.1.1. Application Data Flow
F.4.1.2. Functional Definition of AEs
F.4.1.2.1. Functional Definition of STORAGE-SCU Application Entity
F.4.1.2.2. Functional Definition of QUERY-RETRIEVE-SCP Application Entity
F.4.1.2.3. Functional Definition of STORAGE-SCP Application Entity
F.4.1.3. Sequencing of Real-World Activities
F.4.2. AE Specifications
F.4.2.1. STORAGE-SCU Application Entity Specification
F.4.2.1.1. SOP Classes
F.4.2.1.2. Association Establishment Policies
F.4.2.1.2.1. General
F.4.2.1.2.2. Number of Associations
F.4.2.1.2.3. Asynchronous Nature
F.4.2.1.2.4. Implementation Identifying Information
F.4.2.1.3. Association Initiation Policy
F.4.2.1.3.1. Activity - Send Images Requested By an External Peer AE
F.4.2.1.3.1.1. Description and Sequencing of Activity
F.4.2.1.3.1.2. Proposed Presentation Contexts
F.4.2.1.3.1.3. SOP Specific Conformance for Verification SOP Class
F.4.2.1.3.1.4. SOP Specific Conformance for Image SOP Classes
F.4.2.1.4. Association Acceptance Policy
F.4.2.2. QUERY-RETRIEVE-SCP Application Entity Specification
F.4.2.2.1. SOP Classes
F.4.2.2.2. Association Policies
F.4.2.2.2.1. General
F.4.2.2.2.2. Number of Associations
F.4.2.2.2.3. Asynchronous Nature
F.4.2.2.2.4. Implementation Identifying Information
F.4.2.2.3. Association Initiation Policy
F.4.2.2.4. Association Acceptance Policy
F.4.2.2.4.1. Activity - Handling Query and Retrieval Requests
F.4.2.2.4.1.1. Description and Sequencing of Activity
F.4.2.2.4.1.2. Accepted Presentation Contexts
F.4.2.2.4.1.3. SOP Specific Conformance for Query SOP Classes
F.4.2.2.4.1.4. SOP Specific Conformance for Retrieval SOP Classes
F.4.2.3. STORAGE-SCP Application Entity Specification
F.4.2.3.1. SOP Classes
F.4.2.3.2. Association Policies
F.4.2.3.2.1. General
F.4.2.3.2.2. Number of Associations
F.4.2.3.2.3. Asynchronous Nature
F.4.2.3.2.4. Implementation Identifying Information
F.4.2.3.3. Association Initiation Policy
F.4.2.3.3.1. Activity - Send Storage Commitment Notification Over New Association
F.4.2.3.3.1.1. Description and Sequencing of Activity
F.4.2.3.3.1.2. Proposed Presentation Contexts
F.4.2.3.3.1.3. SOP Specific Conformance for Storage SOP Classes
F.4.2.3.3.1.4. SOP Specific Conformance for Verification SOP Class
F.4.2.3.4. Association Acceptance Policy
F.4.2.3.4.1. Activity - Receive Images and Storage Commitment Requests
F.4.2.3.4.1.1. Description and Sequencing of Activity
F.4.2.3.4.1.2. Accepted Presentation Contexts
F.4.2.3.4.1.3. SOP Specific Conformance for Verification SOP Class
F.4.2.3.4.1.4. SOP Specific Conformance for Storage SOP Classes
F.4.2.3.4.1.5. SOP Specific Conformance for Storage Commitment SOP Class
F.4.3. Network Interfaces
F.4.3.1. Physical Network Interface
F.4.3.2. Additional Protocols
F.4.3.2.1. DHCP
F.4.3.2.2. DNS
F.4.3.3. IPv4 and IPv6 Support
F.4.4. Configuration
F.4.4.1. AE Title/Presentation Address Mapping
F.4.4.1.1. Local AE Titles
F.4.4.1.2. Remote AE Title/Presentation Address Mapping
F.4.4.2. Parameters
F.5. Media Interchange
F.6. Support of Extended Character Sets
F.7. Security
F.7.1. Security Profiles
F.7.2. Association Level Security
F.8. Annexes
F.8.1. IOD Contents
F.8.1.1. STORAGE-SCP AE Element Use
F.8.1.2. STORAGE-SCU AE Element Modification
G. Conformance Statement Sample ImageViewer with Hanging Protocol Support (Informative)
G.0. Cover Page
G.1. Conformance Statement Overview
G.2. Table of Contents
G.3. Introduction
G.3.1. Revision History
G.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
G.3.3. Additional Remarks for This Example
G.4. Networking
G.4.1. Implementation Model
G.4.1.1. Application Data Flow
G.4.1.2. Functional Definitions of AEs
G.4.1.2.1. STORAGE-SCP
G.4.1.2.2. STORAGE-SCU
G.4.1.2.3. FIND-SCU
G.4.1.2.4. MOVE-SCU
G.4.1.3. Sequencing of Real-World Activities
G.4.2. AE Specifications
G.4.2.1. STORAGE-SCP
G.4.2.1.1. SOP Classes
G.4.2.1.2. Association Policies
G.4.2.1.2.1. General
G.4.2.1.2.2. Number of Associations
G.4.2.1.2.3. Asynchronous Nature
G.4.2.1.2.4. Implementation Identifying Information
G.4.2.1.3. Association Initiation Policy
G.4.2.1.4. Association Acceptance Policy
G.4.2.1.4.1. Activity - Receive Storage Request
G.4.2.1.4.1.1. Description and Sequencing of Activities
G.4.2.1.4.1.2. Accepted Presentation Contexts
G.4.2.1.4.1.2.1. Extended Negotiation
G.4.2.1.4.1.3. SOP Specific Conformance
G.4.2.1.4.1.3.1. SOP Specific Conformance to Storage Service Class
G.4.2.1.4.1.3.2. SOP Specific Conformance to Hanging Protocol Storage Service Class
G.4.2.1.4.1.3.3. Presentation Context Acceptance Criterion
G.4.2.1.4.1.3.4. Transfer Syntax Selection Policies
G.4.2.1.4.1.3.5. Response Status
G.4.2.2. STORAGE-SCU
G.4.2.2.1. SOP Classes
G.4.2.2.2. Association Policies
G.4.2.2.2.1. General
G.4.2.2.2.2. Number of Associations
G.4.2.2.2.3. Asynchronous Nature
G.4.2.2.2.4. Implementation Identifying Information
G.4.2.2.3. Association Initiation Policy
G.4.2.2.3.1. Activity - Send Storage Request
G.4.2.2.3.1.1. Description and Sequencing of Activities
G.4.2.2.3.1.2. Proposed Presentation Contexts
G.4.2.2.3.1.2.1. Extended Negotiation
G.4.2.2.3.1.3. SOP Specific Conformance
G.4.2.2.3.1.3.1. SOP Specific Conformance to Storage Service Class
G.4.2.2.3.1.3.2. SOP Specific Conformance to Hanging Protocol Storage Service Class
G.4.2.2.3.1.3.3. Presentation Context Acceptance Criterion
G.4.2.2.3.1.3.4. Transfer Syntax Selection Policies
G.4.2.2.3.1.3.5. Response Status
G.4.2.2.4. Association Acceptance Policy
G.4.2.3. FIND-SCU
G.4.2.3.1. SOP Classes
G.4.2.3.2. Association Policies
G.4.2.3.2.1. General
G.4.2.3.2.2. Number of Associations
G.4.2.3.2.3. Asynchronous Nature
G.4.2.3.2.4. Implementation Identifying Information
G.4.2.3.3. Association Initiation Policy
G.4.2.3.3.1. Activity - Query Remote AE
G.4.2.3.3.1.1. Description and Sequencing of Activities
G.4.2.3.3.1.2. Proposed Presentation Contexts
G.4.2.3.3.1.2.1. Extended Negotiation
G.4.2.3.3.1.3. SOP Specific Conformance
G.4.2.3.3.1.3.1. SOP Specific Conformance to C-FIND SOP Classes
G.4.2.3.3.1.3.2. Presentation Context Acceptance Criterion
G.4.2.3.3.1.3.3. Transfer Syntax Selection Policies
G.4.2.3.3.1.3.4. Response Status
G.4.2.3.4. Association Acceptance Policy
G.4.2.4. MOVE-SCU
G.4.2.4.1. SOP Classes
G.4.2.4.2. Association Policies
G.4.2.4.2.1. General
G.4.2.4.2.2. Number of Associations
G.4.2.4.2.3. Asynchronous Nature
G.4.2.4.2.4. Implementation Identifying Information
G.4.2.4.3. Association Initiation Policy
G.4.2.4.3.1. Activity - Retrieve From Remote AE
G.4.2.4.3.1.1. Description and Sequencing of Activities
G.4.2.4.3.1.2. Proposed Presentation Contexts
G.4.2.4.3.1.2.1. Extended Negotiation
G.4.2.4.3.1.3. SOP Specific Conformance
G.4.2.4.3.1.3.1. SOP Specific Conformance to C-FIND SOP Classes
G.4.2.4.3.1.3.2. Presentation Context Acceptance Criterion
G.4.2.4.3.1.3.3. Transfer Syntax Selection Policies
G.4.2.4.3.1.3.4. Response Status
G.4.2.4.3.1.3.5. Sub-Operation Dependent Behavior
G.4.2.4.4. Association Acceptance Policy
G.4.3. Network Interfaces
G.4.3.1. Physical Network Interface
G.4.3.2. Additional Protocols
G.4.3.3. IPv4 and IPv6 Support
G.4.4. Configuration
G.4.4.1. AE Title/Presentation Address Mapping
G.4.4.2. Parameters
G.5. Media Interchange
G.6. Support of Character Sets
G.6.1. Overview
G.6.2. Character Sets
G.6.3. Character Set Configuration
G.7. Security
G.7.1. Security Profiles
G.7.2. Association Level Security
G.7.3. Application Level Security
G.8. Annexes
G.8.1. IOD Contents
G.8.1.1. Created SOP Instances
G.8.1.1.1. Hanging Protocol IOD
G.8.1.2. Usage of Attributes From Received IODs
G.8.1.3. Attribute Mapping
G.8.1.4. Coerced/Modified Fields
G.8.2. Data Dictionary of Private Attributes
G.8.3. Coded Terminology and Templates
G.8.4. Grayscale Image Consistency
G.8.5. Standard Extended/Specialized/Private SOP Classes
G.8.6. Private Transfer Syntaxes
H. DICOM Conformance Statement Medication-System-Gateway (Informative)
H.0. Cover Page
H.1. Conformance Statement Overview
H.2. Table of Contents
H.3. Introduction
H.3.1. Revision History
H.3.2. Audience,Remarks,Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
H.3.3. Additional Remarks for This Example
H.4. Networking
H.4.1. Implementation Model
H.4.1.1. Application Data Flow
H.4.1.2. Functional Definition of AEs
H.4.1.2.1. Functional Definition of PHARMACY-SCP Application Entity
H.4.1.2.2. Functional Definition of MAR-SCP Application Entity
H.4.1.3. Sequencing of Real-World Activities
H.4.2. AE Specifications
H.4.2.1. PHARMACY-SCP Application Entity Specification
H.4.2.1.1. SOP Classes
H.4.2.1.2. Association Policies
H.4.2.1.2.1. General
H.4.2.1.2.2. Number of Associations
H.4.2.1.2.3. Asynchronous Nature
H.4.2.1.2.4. Implementation Identifying Information
H.4.2.1.3. Association Initiation Policy
H.4.2.1.4. Association Acceptance Policy
H.4.2.1.4.1. Activity - Handling Query Requests
H.4.2.1.4.1.1. Description and Sequencing of Activity
H.4.2.1.4.1.2. Accepted Presentation Contexts
H.4.2.1.4.1.3. SOP Specific Conformance for Verification SOP Class
H.4.2.1.4.1.4. SOP Specific Conformance for Product Characteristics Query SOP Class
H.4.2.1.4.1.5. SOP Specific Conformance for Substance Approval Query SOP Class
H.4.2.1.4.1.6. PHARMACY-SCP AE C-FIND Response Behavior
H.4.2.2. MAR-SCP Application Entity Specification
H.4.2.2.1. SOP Classes
H.4.2.2.2. Association Policies
H.4.2.2.2.1. General
H.4.2.2.2.2. Number of Associations
H.4.2.2.2.3. Asynchronous Nature
H.4.2.2.2.4. Implementation Identifying Information
H.4.2.2.3. Association Initiation Policy
H.4.2.2.4. Association Acceptance Policy
H.4.2.2.4.1. Activity - Handling Substance Administration Logging Requests
H.4.2.2.4.1.1. Description and Sequencing of Activity
H.4.2.2.4.1.2. Accepted Presentation Contexts
H.4.2.2.4.1.3. SOP Specific Conformance for Verification SOP Class
H.4.2.2.4.1.4. SOP Specific Conformance for Substance Administration Logging SOP Classes
H.4.3. Network Interfaces
H.4.3.1. Physical Network Interface
H.4.3.2. Additional Protocols
H.4.3.2.1. DHCP
H.4.3.2.2. DNS
H.4.4. Configuration
H.4.4.1. AE Title/Presentation Address Mapping
H.4.4.1.1. Local AE Titles
H.4.4.1.2. Remote AE Title/Presentation Address Mapping
H.4.4.2. Parameters
H.5. Media Interchange
H.6. Support of Extended Character Sets
H.7. Security
H.7.1. Security Profiles
H.7.2. Association Level Security
I. Conformance Statement Sample WADO Service (Informative)
I.0. Cover Page
I.1. Conformance Statement Overview
I.2. Table of Contents
I.3. Introduction
I.3.1. Revision History
I.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
I.3.3. Additional Remarks for This Example
I.4. Networking
I.4.1. Implementation Model
I.4.1.1. Application Data Flow
I.4.1.2. Functional Definition of AEs
I.4.1.2.1. Functional Definition of WADO Service Application
I.4.2. AE Specifications
I.4.2.1. WADO-WS Specifications
I.4.2.1.1. WADO-WS Retrieve Imaging Document Set
I.4.2.1.2. WADO-WS Retrieve Rendered Imaging Document Set
I.4.2.1.3. WADO-WS Retrieve Imaging Document Set Metadata
I.4.2.1.4. Connection Policies
I.4.2.1.4.1. General
I.4.2.1.4.2. Number of Connections
I.4.2.1.4.3. Asynchronous Nature
I.4.2.2. WADO-URI Specification
I.4.2.2.1. WADO-URI Retrieve Imaging Document Set
I.4.2.2.2. WADO-URI Retrieve Rendered Imaging Document Set
I.4.2.2.3. WADO-URI Retrieve Imaging Document Set Metadata
I.4.2.2.4. Connection Policies
I.4.2.2.4.1. General
I.4.2.2.4.2. Number of Connections
I.4.2.2.4.3. Asynchronous Nature
I.4.2.3. WADO-RS Specifications
I.4.2.3.1. WADO-RS Retrieve Study
I.4.2.3.2. WADO-RS Retrieve Series
I.4.2.3.3. WADO-RS Retrieve Instance
I.4.2.3.4. WADO-RS Retrieve Frames
I.4.2.3.5. WADO-RS Retrieve Bulk Data
I.4.2.3.6. WADO-RS Retrieve Metadata
I.4.2.3.7. Connection Policies
I.4.2.3.7.1. General
I.4.2.3.7.2. Number of Connections
I.4.2.3.7.3. Asynchronous Nature
I.4.3. Network Interfaces
I.4.3.1. Physical Network Interface
I.4.3.2. Additional Protocols
I.4.3.3. IPv4 and IPv6 Support
I.4.4. Configuration
I.4.4.1. HTTP URI Interface
I.4.4.2. WS Interface
I.4.4.3. RS Interface
I.5. Media Interchange
I.6. Support of Character Sets
I.7. Security
I.8. Annexes
I.8.1. IOD Contents
I.8.3. Coded Terminology and Templates
I.8.4. Grayscale Image Consistency
I.8.5. Standard Extended / Specialized / Private SOP Classes
I.8.6. Private Transfer Syntaxes
J. Conformance Statement Sample STOW Service (Informative)
J.0. Cover Page
J.1. Conformance Statement Overview
J.2. Table of Contents
J.3. Introduction
J.3.1. Revision History
J.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
J.3.3. Additional Remarks for This Example
J.4. Networking
J.4.1. Implementation Model
J.4.1.1. Application Data Flow
J.4.1.2. Functional Definition of AEs
J.4.1.2.1. Functional Definition of STOW Service Application
J.4.2. AE Specifications
J.4.2.1. STOW-RS Specifications
J.4.2.1.1. STOW-RS Store Instance
J.4.2.2.4. Connection Policies
J.4.2.2.4.1. General
J.4.2.2.4.2. Number of Connections
J.4.2.2.4.3. Asynchronous Nature
J.4.2.2.4.4. SOP Specific Conformance for SOP Class(Es)
J.4.3. Network Interfaces
J.4.3.1. Physical Network Interface
J.4.3.2. Additional Protocols
J.4.3.3. IPv4 and IPv6 Support
J.4.4. Configuration
J.4.4.1. STOW-RS Interface
J.5. Media Interchange
J.6. Support of Character Sets
J.7. Security
J.8. Annexes
J.8.1. IOD Contents
J.8.2. Data Dictionary of Private Attributes
J.8.3. Coded Terminology and Templates
J.8.4. Standard Extended / Specialized / Private SOP Classes
J.8.5. Private Transfer Syntaxes
K. Conformance Statement Sample QIDO-RS Provider (Informative)
K.0. Cover Page
K.1. Conformance Statement Overview
K.2. Table of Contents
K.3. Introduction
K.3.1. Revision History
K.3.2. Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References
K.3.3. Additional Remarks for This Example
K.4. Networking
K.4.1. Implementation Model
K.4.1.1. Application Data Flow
K.4.1.2. Functional Definition of AEs
K.4.1.2.1. Functional Definition of QIDO Service Application
K.4.2. AE Specifications
K.4.2.1. QIDO-RS Specifications
K.4.2.1.1. QIDO-RS Search for Studies
K.4.2.1.2. QIDO-RS Search for Series
K.4.2.1.3. QIDO-RS Search for Instances
K.4.2.1.4. Connection Policies
K.4.2.1.4.1. General
K.4.2.1.4.2. Number of Connections
K.4.2.1.4.3. Asynchronous Nature
K.4.2.1.4.4. Response Status
K.4.2.2. Extended Negotiation
K.4.3. Network Interfaces
K.4.3.1. Physical Network Interface
K.4.3.2. Additional Protocols
K.4.3.3. IPv4 and IPv6 Support
K.4.4. Configuration
K.4.4.1. QIDO-RS Interface
K.5. Media Interchange
K.6. Support of Character Sets
K.7. Security

List of Figures

5.1-1. Application Entity Convention
5.1-2. Real-World Activity Convention
5.1-3. Local Relationship Convention
5.1-4. Associations Convention
5.1-5. File-Set Access
A.4.1-1. Functional Overview
A.5.1-1. Application Data Flow Diagram
B.4.1-1. Application Data Flow Diagram
B.4.1-2. Sequencing Constraints
B.4.2-1. Sequencing of Activity - Send Images
B.4.2-2. Sequencing of Activity - Receive Storage Commitment Response
B.4.2-3. Sequencing of Activity - Worklist Update
B.4.2-4. Sequencing of Activity - Acquire Images
B.4.2-5. Sequencing of Activity - Film Images
B.5.1-1. Application Data Flow Diagram for Media Storage
C.4.1-1. DICOM Standard Interface
C.4.1-2. Sequencing Constraints
C.4.2-1. Sequencing Diagram for Activity: Configured AE Requests MWL Query
C.4.2-2. Sequencing Diagram for Activity: Configured AE Makes Procedure Step Request
D.4.1-1. Implementation Model
D.5.1-1. Implementation Model
E.4.1-1. Application Data Flow Diagram
E.4.1-2. Print Server Management Sequence
F.4.1-1. Example-Query-Retrieve-Server DICOM Data Flow Diagram
F.4.1-2. Sequencing Constraints
F.4.2-1. Sequencing of Activity - Send Images Requested By an External Peer AE
F.4.2-2. Sequencing of Activity - Handling Query and Retrieval Requests
F.4.2-3. Sequencing of Activity - Send Storage Commitment Notification Over New Association
F.4.2-4. Sequencing of Activity - Receive Images and Storage Commitment Requests
G.4.1-1. Implementation Model
H.4.2-1. Example-Medication-System-Gateway DICOM Data Flow Diagram
I.4.1-1. Application Data Flow Diagram
J.4.1-1. Application Data Flow Diagram
K.4.1-1. Application Data Flow Diagram

List of Tables

A.1-1. Network Services
A.1-2. UID Values
A.1-3. Media Services
A.4.2-1. SOP Class(Es) for "Application Entity <1>"
A.4.2-2. DICOM Application Context
A.4.2-3. Number of Associations as an Association Initiator for "Application Entity <1>"
A.4.2-4. Number of Associations as an Association Acceptor for "Application Entity <1>"
A.4.2-5. Asynchronous Nature as an Association Initiator for "Application Entity <1>"
A.4.2-6. DICOM Implementation Class and Version for "Application Entity <1>"
A.4.2-7. Proposed Presentation Contexts for "Application Entity <1>"
A.4.2-8. Extended Negotiation as a SCU
A.4.2-9. DICOM Command Response Status Handling Behavior
A.4.2-10. DICOM Command Communication Failure Behavior
A.4.2-11. Acceptable Presentation Contexts For"Application Entity <1>" and "Activity <2>"
A.4.2-12. Extended Negotiation as a SCP
4.2-13. Storage C-STORE Response Status
A.4.3-1. System Management Profiles Table
A.4.4-1. AE Title Configuration Table
A.4.4-2. Configuration Parameters Table
A.5.2-1. AE Related Application Profiles, Real-World Activities, and Roles
A.9.3-1. Context Groups
B.1-1. Network Services
B.1-2. Media Services
B.3.1. Revision History
B.4.2-1. SOP Classes for AE Storage
B.4.2-2. DICOM Application Context for AE Storage
B.4.2-3. Number of Associations Initiated for AE Storage
B.4.2-4. Number of Associations Accepted for AE Storage
B.4.2-5. Asynchronous Nature as a SCU for AE Storage
B.4.2-6. DICOM Implementation Class and Version for AE Storage
B.4.2-7. Proposed Presentation Contexts for Activity Send Images
B.4.2-8. Storage C-STORE Response Status Handling Behavior
B.4.2-9. Storage Communication Failure Behavior
B.4.2-10. Storage Commitment N-ACTION Response Status Handling Behavior
B.4.2-11. Storage Commitment Communication Failure Behavior
B.4.2-12. Storage Commitment N-EVENT-REPORT Behavior
B.4.2-13. Storage Commitment N-EVENT-REPORT Response Status Reasons
B.4.2-14. Association Rejection Reasons
B.4.2-15. Acceptable Presentation Contexts for Activity Receive Storage Commitment Response
B.4.2-16. SOP Classes for AE Workflow
B.4.2-17. DICOM Application Context for AE Workflow
B.4.2-18. Number of Associations Initiated for AE Workflow
B.4.2-19. Asynchronous Nature as a SCU for AE Workflow
B.4.2-20. DICOM Implementation Class and Version for AE Workflow
B.4.2-21. Proposed Presentation Contexts for Activity Worklist Update
B.4.2-22. Modality Worklist C-FIND Response Status Handling Behavior
B.4.2-23. Modality Worklist Communication Failure Behavior
B.4.2-24. Worklist Request Identifier
B.4.2-25. Proposed Presentation Contexts for Real-World Activity Acquire Images
B.4.2-26. MPPS N-CREATE / N-SET Response Status Handling Behavior
B.4.2-27. MPPS Communication Failure Behavior
B.4.2-28. MPPS N-CREATE / N-SET Request Identifier
B.4.2-29. SOP Classes for AE Hardcopy
B.4.2-30. DICOM Application Context for AE Hardcopy
B.4.2-31. Number of Associations Initiated for AE Hardcopy
B.4.2-32. Asynchronous Nature as a SCU for AE Hardcopy
B.4.2-33. DICOM Implementation Class and Version for AE Hardcopy
B.4.2-34. Proposed Presentation Contexts for Activity Film Images
B.4.2-35. Hardcopy Communication Failure Behavior
B.4.2-36. Printer SOP Class N-GET Request Attributes
B.4.2-37. Printer SOP Class N-GET Response Status Handling Behavior
B.4.2-38. Printer SOP Class N-EVENT-REPORT Behavior
B.4.2-39. Printer SOP Class N-EVENT-REPORT Response Status Reasons
B.4.2-40. Film Session SOP Class N-CREATE Request Attributes
B.4.2-41. Film Session SOP Class N-CREATE Response Status Handling Behavior
B.4.2-42. Printer SOP Class N-DELETE Response Status Handling Behavior
B.4.2-43. Presentation LUT SOP Class N-CREATE Request Attributes
B.4.2-44. Presentation LUT SOP Class N-CREATE Response Status Handling Behavior
B.4.2-45. Film Box SOP Class N-CREATE Request Attributes
B.4.2-46. Film Box SOP Class N-CREATE Response Status Handling Behavior
B.4.2-47. Film Box SOP Class N-ACTION Response Status Handling Behavior
B.4.2-48. Image Box SOP Class N-SET Request Attributes
B.4.2-49. Image Box SOP Class N-SET Response Status Handling Behavior
B.4.3-1. Supported Physical Network Interfaces
B.4.3-2. Supported System Management Profiles
B.4.3-3. Supported DHCP Parameters
B.4.4-1. AE Title Configuration Table
B.4.4-2. Device Configuration Parameters Obtained From LDAP Server
B.4.4-3. AE Configuration Parameters Obtained From LDAP Server
B.4.4-4. Network Connection Configuration Parameters Obtained From LDAP Server
B.4.4-5. Device Configuration Parameters Updated On LDAP Server
B.4.4-6. Network Connection Configuration Parameters Updated On LDAP Server
B.4.4-7. Storage AE Configuration Parameters Updated On LDAP Server
B.4.4-8. Workflow AE Configuration Parameters Updated On LDAP Server
B.4.4-9. Hardcopy AE Configuration Parameters Updated On LDAP Server
B.4.4-10. Configuration Parameters Table
B.5.1-1. DICOM Implementation Class and Version for Media Storage
B.5.2-1. Application Profiles, Activities and Roles for Offline-Media
B.5.2-2. IODs, SOP Classes and Transfer Syntaxes for Offline­Media
B.5.4-1. AE Title Configuration Table
B.8.1-1. IOD of Created Rf SOP Instances
B.8.1-2. IOD of Created Grayscale Softcopy Presentation State SOP Instances
B.8.1-3. Patient Module of Created SOP Instances
B.8.1-4. General Study Module of Created SOP Instances
B.8.1-5. Patient Study Module of Created SOP Instances
B.8.1-6. General Series Module of Created SOP Instances
B.8.1-7. General Equipment Module of Created SOP Instances
B.8.1-8. Private Application Module of Created SOP Instances
B.8.1-9. General Image Module of Created Rf SOP Instances
B.8.1-10. Image Pixel Module of Created Rf SOP Instances
B.8.1-11. Cine Module of Created Rf SOP
B.8.1-12. Multi-Frame Module of Created Rf SOP Instances
B.8.1-13. Frame Pointers Module of Created Rf SOP Instances
B.8.1-14. Mask Module of Created Rf SOP Instances
B.8.1-15. X-Ray Image Module of Created Rf SOP Instances
B.8.1-16. X-Ray Acquisition Module of Created Rf SOP Instances
B.8.1-17. Modality LUT Module of Created Rf SOP Instances
B.8.1-18. VOI LUT Module of Created RF SOP Instances
B.8.1-19. SOP Common Module of Created Rf SOP Instances
B.8.1-20. Presentation Series Module of Created GSPS SOP Instances
B.8.1-21. Presentation State Module of Created GSPS SOP Instances
B.8.1-22. Display Shutter Module of Created GSPS SOP Instances
B.8.1-23. Displayed Area Module of Created GSPS SOP Instances
B.8.1-24. Graphic Annotation Module of Created GSPS SOP Instances
B.8.1-25. Spatial Transformation Module of Created GSPS SOP Instances
B.8.1-26. Graphic Layer Module of Created GSPS SOP Instances
B.8.1-27. Modality LUT Module of Created GSPS SOP Instances
B.8.1-28. Softcopy VOI LUT Module of Created GSPS SOP Instances
B.8.1-29. Softcopy Presentation LUT Module of Created GSPS SOP Instances
B.8.1-30. SOP Common Module of Created GSPS SOP Instances
B.8.1-31. Attribute Mapping Between Modality Worklist, Image and MPPS
B.8.2-1. Data Dictionary of Private Attributes
C.1-1. Network Services
C.3.1-1. Revision History
C.4.2-1. SOP Classes for AE DICOMSRV
C.4.2-2. DICOM Application Context
C.4.2-3. Number of Associations as an SCP for AE DICOMSRV
C.4.2-4. DICOM Implementation Class and Version for DICOMSRV
C.4.2-5. Scheduled Procedure Step Entry Actions Table
C.4.2-6. Acceptable Presentation Contexts for AE DICOMSRV and Real-World Activity 'Configured AE Requests MWL Query'
C.4.2-7. Modality Worklist Optional Return Keys Supported
C.4.2-8. MWL C-FIND Response Status Reasons
C.4.2-9. Acceptable Presentation Contexts for AE DICOMSRV and Real-World Activity "Configured AE Makes Procedure Step Request"
C.4.2-10. Supported N-SET/N-CREATE Attributes for MPPS
C.4.2-11. MPPS N-CREATE/N-SET Response Status Reasons
C.4.2-12. Acceptable Presentation Contexts for AE DICOMSRV and Real-World Activity Configured AE Requests Verification
C.4.2-13. AE Title Configuration Table
C.4.2-14. Configuration Parameters Table
C.8.1-1. Attributes in MPPS IOD Used By DICOMRis Applications
C.8.1-2. HL7/Modality Worklist Attribute Mapping
C.8.1-3. Coerced Fields for Modality Performed Procedure Step
C.8.1-4. DICOMRis Controlled Terminology Usage
D.1-1. Network Services
D.1-2. Media Services
D.3.1-1. Revision History
D.4.2-1. SOP Classes Supported By ECHO-SCP
D.4.2-2. Maximum PDU Size Received as a SCP for ECHO-SCP
D.4.2-3. Number of Associations as a SCP for ECHO-SCP
D.4.2-4. DICOM Implementation Class and Version for ECHO-SCP
D.4.2-5. Acceptable Presentation Contexts for ECHO-SCP and Receive Echo Request
D.4.2-6. SOP Classes Supported By STORAGE-SCP
D.4.2-7. Maximum PDU Size Received as a SCP for STORAGE-SCP
D.4.2-8. Number of Associations as a SCP for STORAGE-SCP
D.4.2-9. DICOM Implementation Class and Version for STORAGE-SCP
D.4.2-10. Acceptable Presentation Contexts for STORAGE-SCP and Receive Storage Request
D.4.2-11. Response Status for STORAGE-SCP and Receive Storage Request
D.4.2-12. SOP Classes Supported By STORAGE-SCU
D.4.2-13. Maximum PDU Size Received as a SCP for STORAGE-SCU
D.4.2-14. Number of Associations as a SCP for STORAGE-SCU
D.4.2-15. DICOM Implementation Class and Version for STORAGE-SCU
D.4.2-16. Proposed Presentation Contexts for STORAGE-SCU and Receive Storage Request
D.4.2-17. Response Status for STORAGE-SCU and Receive Storage Request
D.4.2-18. SOP Classes Supported By FIND-SCU
D.4.2-19. Maximum PDU Size Received as a SCP for FIND-SCU
D.4.2-20. Number of Associations as a SCP for FIND-SCU
D.4.2-21. DICOM Implementation Class and Version for FIND-SCU
D.4.2-22. Proposed Presentation Contexts for FIND-SCU and Query Remote AE
D.4.2-23. Study Root Request Identifier for FIND-SCU
D.4.2-24. Response Status for FIND-SCU and Query Remote AE Request
D.4.2-25. SOP Classes Supported By MOVE-SCU
D.4.2-26. Maximum PDU Size Received as a SCP for MOVE-SCU
D.4.2-27. Number of Associations as a SCP for MOVE-SCU
D.4.2-28. DICOM Implementation Class and Version for MOVE-SCU
D.4.2-29. Proposed Presentation Contexts for MOVE-SCU and Retrieve From Remote AE
D.4.2-30. Study Root Request Identifier for MOVE-SCU
D.4.2-31. Response Status for MOVE-SCU and Retrieve From Remote AE Request
D.4.4-1. Configuration Parameters Table
D.5.2-1. Application Profiles, Activities, and Roles for MEDIA-FSR
D.6.2-1. Supported Specific Character Set Defined Terms
E.1-1. Network Services
E.3.1-1. Revision History
E.4.2-1. SOP Classes for AE Print Server (SCP)
E.4.2-2. DICOM Application Context for AE Print SCP
E.4.2-3. Number of Associations Accepted for AE Print Server Management (SCP)
E.4.2-4. Number of Associations Initiated for Connectivity
E.4.2-5. Asynchronous Nature as a SCP for AE Print Server (SCP)
E.4.2-6. DICOM Implementation Class and Version for AE Print SCP
E.4.2-7. Proposed Presentation Context for Connectivity Verification
E.4.2-8. C-ECHO Response Status Handling Behavior
E.4.2-9. Association Rejection Reasons
E.4.2-10. Accepted Presentation Contexts for Print Server Management Activity
E.4.2-11. C-ECHO Response Status Handling Reasons
E.4.2-12. SOP Classes for Basic Grayscale Print Management Meta SOP Class
E.4.2-13. Print Server SCP Communication Failure Reasons
E.4.2-14. Basic Film Session SOP Class N-CREATE Request Attributes
E.4.2-15. Film Session SOP Class N-CREATE Response Status Handling Reasons
E.4.2-16. Film Session SOP Class N-SET Response Status Handling Reasons
E.4.2-17. Film Session SOP Class N-DELETE Response Status Handling Reasons
E.4.2-18. Film Session SOP Class N-ACTION Response Status Handling Reasons
E.4.2-19. Basic Film Box SOP Class N-CREATE Request Attributes
E.4.2-20. Annotation Display Formats
E.4.2-21. Film Box SOP Class N-CREATE Response Status Handling Behavior
E.4.2-22. Basic Film Box SOP Class N-SET Request Attributes
E.4.2-23. Film Box SOP Class N-SET Response Status Handling Behavior
E.4.2-24. Film Box SOP Class N-DELETE Response Status Handling Behavior
E.4.2-25. Film Box SOP Class N-ACTION Response Status Handling Behavior
E.4.2-26. Image Box SOP Class N-SET Request Attributes
E.4.2-27. Image Box SOP Class N-SET Response Status Handling Behavior
E.4.2-28. Printer SOP Class N-GET Request Attributes
E.4.2-29. Printer SOP Class N-GET Response Status Handling Behavior
E.4.2-30. Printer SOP Class N-EVENT-REPORT Attributes
E.4.2-31. Printer SOP Class N-EVENT-REPORT Behavior
E.4.2-32. Basic Annotation Box SOP Class N-SET Request Attributes
E.4.2-33. Basic Annotation Box SOP Class N-SET Response Status Handling Behavior
E.4.2-34. Print Job SOP Class N-EVENT-REPORT Attributes
E.4.2-35. Print Job SOP Class N-EVENT-REPORT Notification Events Information
E.4.2-36. Print Job SOP Class N-GET Request Attributes
E.4.2-37. Print Job SOP Class N-GET Response Status Handling Behavior
E.4.2-38. Presentation LUT SOP Class N-CREATE Request Attributes
E.4.2-39. Presentation LUT SOP Class N-CREATE Response Status Handling Behavior
E.4.2-40. Printer Configuration SOP Class N-GET Response Attributes
E.4.3-1. Supported Physical Network Interfaces
E.4.4-1. AE Title Configuration Table
E.4.4-2. Configuration Parameters Table
E.8.1-1. Print Server Attribute Mapping
E.8.2-1. Data Dictionary of Private Attributes
F.1-1. Network Services
F.3.1-1. Revision History
F.4.2-1. SOP Classes for STORAGE-SCU AE
F.4.2-2. DICOM Application Context for STORAGE-SCU AE
F.4.2-3. Number of Associations as a SCU for STORAGE-SCU AE
F.4.2-4. Asynchronous Nature as a SCU for STORAGE-SCU AE
F.4.2-5. DICOM Implementation Class and Version for STORAGE-SCU AE
F.4.2-6. Proposed Presentation Contexts By the STORAGE-SCU AE
F.4.2-7. STORAGE-SCU AE C-STORE Response Status Handling Behavior
F.4.2-8. STORAGE-SCU AE Communication Failure Behavior
F.4.2-9. SOP Classes for QUERY-RETRIEVE-SCP AE
F.4.2-10. DICOM Application Context for QUERY-RETRIEVE-SCP AE
F.4.2-11. Number of Simultaneous Associations as a SCP for QUERY-RETRIEVE-SCP AE
F.4.2-12. Asynchronous Nature as a SCP for QUERY-RETRIEVE-SCP AE
F.4.2-13. DICOM Implementation Class and Version for QUERY-RETRIEVE-SCP AE
F.4.2-14. Association Rejection Reasons
F.4.2-15. Accepted Presentation Contexts By the QUERY-RETRIEVE-SCP AE
F.4.2-16. Patient Root C-FIND SCP Supported Elements
F.4.2-17. Study Root C-FIND SCP Supported Elements
F.4.2-19. QUERY-RETRIEVE-SCP AE C-FIND Response Status Return Behavior
F.4.2-20. QUERY-RETRIEVE-SCP AE C-MOVE Response Status Return Behavior
F.4.2-21. QUERY-RETRIEVE-SCP AE Communication Failure Behavior
F.4.2-22. SOP Classes for STORAGE-SCP AE
F.4.2-23. DICOM Application Context for STORAGE-SCP AE
F.4.2-24. Number of Simultaneous Associations as an SCP for STORAGE-SCP AE
F.4.2-25. Asynchronous Nature as a SCP for STORAGE-SCP AE
F.4.2-26. Outstanding Storage Commitment Push Model Requests for STORAGE-SCP AE
F.4.2-27. DICOM Implementation Class and Version for STORAGE-SCP AE
F.4.2-28. Proposed Presentation Contexts By the STORAGE-SCP AE
F.4.2-29. Association Rejection Reasons
F.4.2-30. Accepted Presentation Contexts By STORAGE-SCP AE
F.4.2-31. STORAGE-SCP AE C-STORE Response Status Return Reasons
F.4.2-32. STORAGE-SCP AE Storage Service Communication Failure Reasons
F.4.2-33. Supported Referenced SOP Classes in Storage Commitment Push Model N-ACTION Requests
F.4.2-34. STORAGE-SCP AE Storage Commitment Push Model N-ACTION Response Status Return Behavior
F.4.2-35. STORAGE-SCP AE N-EVENT-REPORT Response Status Handling Behavior
F.4.2-36. STORAGE-SCP AE Storage Commitment Push Model Communication Failure Behavior
F.4.3-1. Supported Physical Network Interfaces
F.4.3-2. Supported System Management Profiles
F.4.3-3. Supported DHCP Parameters
F.4.4-1. Default Application Entity Characteristics
F.4.4-2. Configuration Parameters
F.8.1-1. Supported Composite Image SOP Classes for Display
F.8.1-2. Significant Elements in Received Composite SOP Instances
F.8.1-3. Significant Elements in Exported Composite SOP Instances
G.1-1. Network Services
G.3.1-1. Revision History
G.4.2-1. SOP Classes Supported By STORAGE-SCP
G.4.2-2. Maximum PDU Size Received as a SCP for STORAGE-SCP
G.4.2-3. Number of Associations as a SCP for STORAGE-SCP
G.4.2-4. DICOM Implementation Class and Version for STORAGE-SCP
G.4.2-5. Accepted Presentation Contexts for STORAGE-SCP and Receive Storage Request
G.4.2-6. Response Status for STORAGE-SCP and Receive Storage Request
G.4.2-7. SOP Classes Supported By STORAGE-SCU
G.4.2-8. Maximum PDU Size Received as a SCP for STORAGE-SCU
G.4.2-9. Number of Associations as a SCP for STORAGE-SCU
G.4.2-10. DICOM Implementation Class and Version for STORAGE-SCU
G.4.2-11. Proposed Presentation Contexts for STORAGE-SCU and Receive Storage Request
G.4.2-12. Response Behavior for STORAGE-SCU and Send Storage Request
G.4.2-13. SOP Classes Supported By FIND-SCU
G.4.2-14. Maximum PDU Size Received as a SCP for FIND-SCU
G.4.2-15. Number of Associations as a SCP for FIND-SCU
G.4.2-16. DICOM Implementation Class and Version for FIND-SCU
G.4.2-17. Proposed Presentation Contexts for FIND-SCU and Query Remote AE
G.4.2.3.3.1.3.1-1. Hanging Protocol Information Model C-FIND SOP Specific Conformance
G.4.2-19. Response Status for FIND-SCU and Query Remote AE Request
G.4.2-20. SOP Classes Supported By MOVE-SCU
G.4.2-21. Maximum PDU Size Received as a SCP for MOVE-SCU
G.4.2-27. Number of Associations as a SCP for MOVE-SCU
G.4.2-23. DICOM Implementation Class and Version for MOVE-SCU
G.4.2-24. Proposed Presentation Contexts for MOVE-SCU and Retrieve From Remote AE
G.4.2-25. Request Identifier for MOVE-SCU
G.4.2-26. Response Status for MOVE-SCU and Retrieve From Remote AE Request
G.4.4-1. Configuration Parameters Table
G.6.2-1. Supported Specific Character Set Defined Terms
G.8.1-1. IOD of Created Hanging Protocol SOP Instances
G.8.1-2. SOP Common Module of Created SOP Instances
G.8.1-3. Hanging Protocol Definition Module of Created SOP Instances
G.8.1-4. Hanging Protocol Environment Module of Created SOP Instances
G.8.1-5. Hanging Protocol Display Module of Created SOP Instances
H.1-1. Network Services
H.3.1-1. Revision History
H.4.2-1. SOP Classes for PHARMACY-SCP AE
H.4.2-2. DICOM Application Context for PHARMACY-SCP AE
H.4.2-3. Number of Simultaneous Associations as a SCP for PHARMACY-SCP AE
H.4.2-4. Asynchronous Nature as a SCP for PHARMACY-SCP AE
H.4.2-5. DICOM Implementation Class and Version for PHARMACY-SCP AE
H.4.2-6. Association Rejection Reasons
H.4.2-7. PHARMACY-SCP AE Communication Failure Behavior
H.4.2-8. Accepted Presentation Contexts By the PHARMACY-SCP AE
H.4.2-9. Return Key Attributes Supported for Product Characteristics Query
H.4.2-10. Product Parameter Sequence Item Concepts Supported
H.4.2-11. Matching Key Attributes Supported for Substance Approval Query
H.4.2-12. Return Key Attributes Supported for Substance Approval Query
H.4.2-13. PHARMACY-SCP AE C-FIND Response Status Return Behavior
H.4.2-14. SOP Classes for MAR-SCP AE
H.4.2-15. DICOM Application Context for MAR-SCP AE
H.4.2-16. Number of Simultaneous Associations as an SCP for MAR-SCP AE
H.4.2-17. Asynchronous Nature as a SCP for MAR-SCP AE
H.4.2-18. DICOM Implementation Class and Version for MAR-SCP AE
H.4.2-19. Association Rejection Reasons
H.4.2-20. PHARMACY-SCP AE Communication Failure Behavior
H.4.2-21. Accepted Presentation Contexts By MAR-SCP AE
H.4.2-22. Attributes of Logging Request Imported to Mar Database
H.4.2-23. MAR-SCP AE N-ACTION Response Status Return Reasons
H.4.3-1. Supported Physical Network Interfaces
H.4.3-2. Supported System Management Profiles
H.4.3-3. Supported DHCP Parameters
H.4.4-1. Default Application Entity Characteristics
H.4.4-2. Configuration Parameters
I.1-1. Network Services
I.3.1-1. Revision History
I.4.2-1. WADO-WS Retrieve Imaging Document Set Specification
I.4.2-3. WADO-WS Retrieve Rendered Imaging Documents Specification
I.4.2-4. Number of WS Requests Supported
I.4.2-5. WADO-URI Retrieve Imaging Documents Specification
I.4.2-6. WADO-URI Retrieve Rendered Imaging Documents Specification
I.4.2-7. Number of HTTP Requests Supported
I.4.2.3-1. WADO-RS Retrieve Study
I.4.2.3-2. WADO-RS Retrieve Series
I.4.2.3-3. WADO-RS Retrieve Instance
I.4.2.3-4. WADO-RS Retrieve Frames
I.4.2.3-5. WADO-RS Retrieve Bulk Data
I.4.2.3-6. WADO-RS Retrieve Metadata
I.4.2.3-7. Number of Rs Requests Supported
J.1-1. Network Services
J.3.1-1. Revision History
J.4.2-1. STOW-RS Store Instances Specification
J.4.2-4. Number of HTTP Requests Supported
J.4.2.2.4.4-1. HTTP Standard Response Codes
K.1-1. Network Services
K.3.1-1. Revision History
K.4.2-1. QIDO-RS Search for Studies Specification
K.4.2-1a. QIDO-RS Study Attribute Matching
K.4.2-2. QIDO-RS Search for Series Specification
K.4.2-2a. QIDO-RS Series Attribute Matching
K.4.2-3. QIDO-RS Search for Instances Specification
K.4.2-3a. QIDO-RS Instance Attribute Matching
K.4.2-4. Number of HTTP Requests Supported
K.4.2-5. HTTP Standard Response Codes

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

Conformance Statements are critical to interoperability because they provide important information for implementers and system integrators in order to determine whether or not applications do interoperate. In addition, when issues occur, they provide a source of information in order to potentially resolve any problems. Lastly, it is important to provide potential implementers with a consistent template for generating these documents.

PS3.2 defines principles that implementations claiming conformance to the Standard shall follow. PS3.2 specifies:

  • the minimum general conformance requirements that must be met by any implementation claiming conformance to the DICOM Standard. Additional conformance requirements for particular features, Service Classes, Information Objects, and communications protocols may be found in the conformance sections of other Parts of the DICOM Standard;

  • the purpose and structure of a Conformance Statement. PS3.2 provides a framework by which conformance information can be placed into a Conformance Statement as dictated by the conformance sections of other Parts of the DICOM Standard.

The DICOM Standard does not specify:

  • testing or validation procedures to assess an implementation's conformance to the Standard;

  • testing or validation procedures to assess whether an implementation matches to its Conformance Statement;

  • what optional features, Service Classes, or Information Objects should be supported for a given type of device.

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 7498-1 Information Processing Systems - Open Systems Interconnection - Basic Reference Model.

ISO 8649:1988 Information Processing Systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).

ISO 8822:1988 Information Processing Systems - Open Systems Interconnection - Connection oriented presentation service definition.

ISO/IEC 10646-1:2000 Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane

ISO/IEC 10646-1:2000/Amd 1:2002 Mathematical symbols and other characters

ISO/IEC 10646-2:2001 Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 2: Supplementary Planes

[ISO/IEC Directives, Part 2] ISO/IEC. 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 Reference Model Definitions

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

  1. Application Entity

  2. Application Entity Title

  3. Protocol Data Unit

  4. Transfer Syntax.

3.2 ACSE Service Definitions

This Part makes use of the following terms defined in ISO 8649:

  1. Association or Application Association

  2. Association Initiator.

3.3 Presentation Service Definitions

This Part makes use of the following terms defined in ISO 8822:

  1. Abstract Syntax

  2. Abstract Syntax Name

  3. Presentation Context

  4. Transfer Syntax

  5. Transfer Syntax Name.

3.4 DICOM Introduction and Overview Definitions

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

  1. Information Object

3.5 DICOM Information Object Definitions

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

  1. Information Object Definition (IOD).

3.6 DICOM Service Class Specification Definitions

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

  1. Real-World Activity

  2. Service Class.

  3. Service Class User (SCU)

  4. Service Class Provider (SCP)

  5. Service-Object Pair (SOP) Class

  6. Meta SOP Class.

3.7 DICOM Data Structure and Encoding Definitions

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

  1. DICOM Defined UID

  2. Privately Defined UID

  3. Transfer Syntax: (Standard and Private)

  4. Unique Identifier (UID).

3.8 DICOM Message Exchange Definitions

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

  1. Extended Negotiation

  2. Implementation Class UID.

3.9 DICOM Upper Layer Service Definitions

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

  1. Unique Identifier (UID)

  2. DICOM Upper Layer Service

  3. Presentation Address.

3.10 Media Storage and File Format for Data Interchange

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

  1. File-set

  2. File-set Creator (FSC)

  3. File-set Reader (FSR)

  4. File-set Updater (FSU)

  5. Application Profile

3.11 DICOM Conformance

This Part uses the following definitions:

3.11.1 Conformance Statement

A formal statement associated with a specific implementation of the DICOM Standard. It specifies the Service Classes, Information Objects, Communications Protocols and Media Storage Application Profiles supported by the implementation.

3.11.2 Standard SOP Class

A SOP Class defined in the DICOM Standard that is used in an implementation with no modifications.

3.11.3 Standard Extended SOP Class

A SOP Class defined in the DICOM Standard extended in an implementation with additional Type 3 Attributes. The additional Attributes may either be drawn from the Data Dictionary in PS3.6, or may be Private Attributes. The semantics of the related Standard SOP Class shall not be modified by the additional Type 3 Attributes when absent. Therefore, the Standard Extended SOP Class utilizes the same UID as the related Standard SOP Class.

Note

IODs from a Standard Extended SOP Class may be freely exchanged between DICOM implementations since implementations unfamiliar with the additional Type 3 Attributes would simply ignore them.

3.11.4 Specialized SOP Class

A SOP Class derived from a Standard SOP Class that has been specialized in an implementation by additional Type 1, 1C, 2, 2C, or 3 Attributes, by enumeration of specific permitted values for Attributes, or by enumeration of specific permitted Templates. The additional Attributes may either be drawn from the Data Dictionary in PS3.6, or may be Private Attributes. The enumeration of permitted Attribute values or Templates shall be a subset of those permitted in the related Standard SOP Class. Since the semantics of the related Standard SOP Class may be modified by the additional Attributes, a Specialized SOP Class utilizes a Privately Defined UID that differs from the UID for the related Standard SOP Class.

Note

  1. Since a Specialized SOP Class has a different UID than a Standard or Standard Extended SOP Class, other DICOM implementations may not recognize the Specialized SOP Class. Because of this limitation, a Specialized SOP Class should only be used when a Standard or Standard Extended SOP Class would not be appropriate. Before different implementations can exchange Instances in a Specialized SOP Class, the implementations must agree on the UID, content (in particular the additional Type 1, 1C, 2, and 2C Attributes), and semantics of the Specialized SOP Class. A Specialized SOP Class may be used to create a new or experimental SOP Class that is closely related to a Standard SOP Class.

  2. The Association Negotiation for a Specialized SOP Class may include a SOP Class Common Extended Negotiation Sub-Item (as defined in PS3.7) for identification of the Service Class and of the Related General SOP Class from which it was specialized. This may allow a receiving application, without prior agreement on the Specialized SOP Class IOD, to process Instances of that class as if they were instances of a Related General SOP Class.

3.11.5 Private SOP Class

A SOP Class that is not defined in the DICOM Standard, but is published in an implementation's Conformance Statement.

Note

Since a Private SOP Class is not defined in the DICOM Standard, other DICOM implementations may not recognize the Private SOP Class. Because of this limitation, a Private SOP Class should only be used when a Standard or Standard Extended SOP Class would not be appropriate. In order for different implementations to exchange Instances in a Private SOP Class, the implementations must agree on the UID, content (in particular the Type 1, 1C, 2, and 2C Attributes), and semantics of the Private SOP Class. A Private SOP class may be used to create a totally new or experimental SOP Class.

3.11.6 Standard Attribute

An Attribute defined in the Data Dictionary in PS3.6.

3.11.7 Private Attribute

An Attribute that is not defined in the DICOM Standard.

3.11.8 Standard Application Profile

An Application Profile defined in the DICOM Standard that is used in an implementation with no modifications.

3.11.9 Augmented Application Profile

An Application Profile derived from a Standard Application Profile by incorporating support for additional Standard or Standard Extended SOP Classes.

3.11.10 Private Application Profile

An Application Profile that is not defined in the DICOM Standard, but is published in an implementation's Conformance Statement.

3.11.11 Security Profile

A mechanism for selecting an appropriate set of choices from the Parts of the DICOM standard along with corresponding security mechanisms (e.g., encryption algorithms) for the support of security facilities.

3.11.12 Transformation of DICOM SR to CDA

A mechanism for mapping and transforming DICOM SR objects to HL7 CDA documents.

4 Symbols and Abbreviations

The following symbols and abbreviations are used in this Part.

ACR

American College of Radiology

ACSE

Association Control Service Element

AE

Application Entity

ANSI

American National Standards Institute

AP

Application Profile

API

Application Programming Interface

ASCII

American Standard Code for Information Interchange

CEN TC251

Comite Europeen de Normalisation-Technical Committee 251-Medical Informatics

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

FSC

File-set Creator

FSR

File-set Reader

FSU

File-set Updater

HISPP

Healthcare Informatics Standards Planning Panel

HL7

Health Level 7

IE

Information Entity

IEEE

Institute of Electrical and Electronics Engineers

IOD

Information Object Definition

ISO

International Standards Organization

ISP

International Standardized Profile

JIRA

Japan Medical Imaging and Radiological Systems Industries Association

MSDS

Healthcare Message Standard Developers Sub-Committee

NEMA

National Electrical Manufacturers Association

OSI

Open Systems Interconnection

PDU

Protocol Data Unit

REST

Representational State Transfer

RESTful

A RESTful Web service is a Web service implemented using REST architecture and HTTP (see http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf)

RWA

Real-World Activity

SCP

Service Class Provider

SCU

Service Class User

SOP

Service-Object Pair

STOW-RS

STore Over the Web by RESTful Services

TCP/IP

Transmission Control Protocol/Internet Protocol

UID

Unique Identifier

UML

Unified Modeling Language

WADO-RS

Web Access to DICOM Objects by RESTful Services

WADO-URI

Web Access to DICOM Objects by URI

5 Conventions

5.1 Application Data Flow Diagram

In a Conformance Statement, the relationships between Real-World Activities and Application Entities are illustrated by an Application Data Flow Diagram.

5.1.1 Application Entity

An Application Entity is depicted as a box in an Application Data Flow Diagram, shown in Figure 5.1-1

Application Entity Convention

Figure 5.1-1. Application Entity Convention


5.1.2 Real-World Activity

A Real-World Activity is depicted as a circle in an Application Data Flow Diagram, shown in Figure 5.1-2.

Real-World Activity Convention

Figure 5.1-2. Real-World Activity Convention


Circles representing multiple Real-World Activities may overlap, indicating a degree of overlap in the Real-World Activities.

5.1.3 Local Relationships

A relationship between a local Real-World Activity and an Application Entity is depicted within an Application Data Flow Diagram by placing the local Real-World Activity to the left of the related Application Entity with a dashed line between them as shown in Figure 5.1-3.

Local Relationship Convention

Figure 5.1-3. Local Relationship Convention


An Application Entity may be associated with multiple Real-World Activities.

A Real-World Activity may be associated with multiple Application Entities.

5.1.4 Network-Associations

An association between a local Application Entity and a remote Application Entity over a network supporting a remote Real-World Activity is depicted within an Application Data Flow Diagram by placing the remote Real-World Activity to the right of the related local Application Entity with one or two arrows drawn between them as shown in Figure 5.1-4. The dashed line represents the DICOM Standard Interface between the local Application Entities, and whatever remote Application Entities that handle the remote Real-World Activities. An arrow from the local Application Entity to the remote Real-World Activity indicates that an occurrence of the local Real-World Activity will cause the local Application Entity to initiate an association for the purpose of causing the remote Real-World Activity to occur. An arrow from the remote Real-World Activity to the local Application Entity indicates that the local Application Entity expects to receive an association request when the remote Real-World Activity occurs, causing the local Application Entity to perform the local Real-World Activity.

Associations Convention

Figure 5.1-4. Associations Convention


5.1.5 Media Storage File-Set Access

Application Entities exchanging information on media use the DICOM File Service as specified in PS3.10 for access to, or creation of, File-sets. This File Service provides operations that support three basic roles, which are File-set Creator (FSC), File-set Reader (FSR), and File-set Updater (FSU).

These roles are depicted on an Application Data Flow diagram by directional arrows placed between the local Application Entities and the DICOM Storage Media on which the roles are applied.

  • File-set Creator (FSC), denoted by

  • File-set Reader (FSR), denoted by

  • File-set Updater (FSU), denoted by

  • Physical movement of the medium, denoted by (with or without arrowhead)

Figure 5.1-5 illustrates the three basic roles.

File-Set Access

Figure 5.1-5. File-Set Access


The local interactions shown on the left between a local Real-World activity and a local Application Entity are depicted by a dashed line. The arrows on the right represent access by the local Application Entity to a File-set on the DICOM Storage Medium. When an Application Entity supports several roles, this combination is depicted with multiple arrows corresponding to each of the roles. The dotted arrow symbolizes the removable nature of media for an interchange application.

Note

The use of two arrows relative to an FSC and an FSR should be distinguished from the case where a double arrow relative to an FSU is used. For example, an FSU may update a File-set without creating a new File-set, whereas a combined FSC and FSR may be used to create and verify a File-set.

6 Purpose of a Conformance Statement

An implementation need not employ all the optional components of the DICOM Standard. After meeting the minimum general requirements, a conformant DICOM implementation may utilize whatever SOP Classes, communications protocols, Media Storage Application Profiles, optional (Type 3) Attributes, codes and controlled terminology, etc., needed to accomplish its designed task.

Note

In fact, it is expected that an implementation might only support the SOP Classes related to its Real World Activities. For example, a simple film digitizer may not support the SOP Classes for other imaging modalities since such support may not be required. On the other hand, a complex storage server might be required to support SOP Classes from multiple modalities in order to adequately function as a storage server. The choice of which components of the DICOM Standard are utilized by an implementation depends heavily on the intended application and is beyond the scope of this Standard.

In addition, the DICOM Standard allows an implementation to extend or specialize the DICOM defined SOP Classes, as well as define Private SOP classes.

A Conformance Statement allows a user to determine which optional components of the DICOM Standard are supported by a particular implementation, and what additional extensions or specializations an implementation adds. By comparing the Conformance Statements from two different implementations, a knowledgeable user should be able to determine whether and to what extent communications might be supported between the two implementations.

Different structures are used for the content of Conformance Statements depending on whether the implementation supports a DICOM network interface, a DICOM Media Storage interface, or a combination thereof. In the latter case, a single Conformance Statement shall be provided that consists of the appropriate sections.

The first part of the conformance statement contains a DICOM Conformance Statement Overview, which is typically a one-page description in the beginning of the document providing a high level description and also listing the Networking and Media Service Classes, including their roles (SCU/SCP, FSC, FSR, etc.).

6.1 Overview of Networking Section for Conformance Statements

The networking section of a Conformance Statement consists of the following major parts:

  • a functional overview containing the Application Data Flow Diagram that shows all the Application Entities, including any sequencing constraints among them. It also shows how they relate to both local and remote Real World Activities;

  • a more detailed specification of each Application Entity, listing the SOP Classes supported and outlining the policies with which it initiates or accepts associations;

  • for each Application Entity and Real-World Activity combination, a description of proposed (for Association Initiation) and acceptable (for Association Acceptance) Presentation Contexts;

Note

A Presentation Context consists of an Abstract Syntax plus a list of acceptable Transfer Syntaxes. The Abstract Syntax identifies one SOP Class or Meta SOP Class (a collection of related SOP Classes identified by a single Abstract Syntax UID). By listing the Application Entities with their proposed and accepted Presentation Contexts, the Conformance Statement is identifying the set of Information Objects and Service Classes that are recognized by this implementation;

  • for each SOP Class related to an Abstract Syntax, a list of any SOP options supported;

  • a set of communications protocols that this implementation supports;

  • a description of any extensions, specializations, and publicly disclosed privatizations in this implementation;

  • a section describing DICOM related configuration details;

  • a description of any implementation details that may be related to DICOM conformance or interoperability;

  • a description of what codes and controlled terminology mechanisms are used.

6.2 Overview of Media Storage Section for Conformance Statements

The media storage section of a Conformance Statement consists of the following major parts:

  • a functional overview containing the Application Data Flow Diagram that shows all the Application Entities, including any sequencing constraints among them. It also shows how they relate to both local and remote Real-World Activities;

  • a more detailed specification of each Application Entity listing the Media Storage Application Profiles supported (this defines SOP Classes supported and media selected), which outlines the policies with which it creates, reads, or updates File-sets on the media;

  • a list of optional SOP Classes supported;

  • for each Media Storage SOP Class related to a media storage Application Profile, a list of any SOP options supported;

  • for each Media Storage SOP Class related to a media storage Application Profile, a list of optional Transfer Syntaxes supported;

  • a description of any extensions, specializations, and publicly disclosed privatizations in this implementation such as Augmented or Private Application Profiles;

  • a section describing DICOM related configuration details;

a description of any implementation details that may be related to DICOM conformance or interoperability;

a description of what codes and controlled terminology mechanisms are used.

7 Conformance Requirements

An implementation claiming DICOM conformance may choose to support one of the following:

  • network conformance according to Section 7.1 (DICOM Network Conformance Requirements);

  • media storage conformance according to Section 7.2 (DICOM Media Storage Conformance Requirements);

  • both of the above.

7.1 DICOM Network Conformance Requirements

An implementation claiming DICOM network conformance shall:

  • conform to the minimum conformance requirements defined in this section;

  • provide with the implementation a Conformance Statement structured according to the rules and policies in this Part including Annex A;

  • conform to at least one Standard or Standard Extended SOP class as defined in PS3.4;

Note

Conformance to a Standard or Standard Extended SOP class implies conformance to the related IOD outlined in PS3.3, the Data Elements defined in PS3.6, and the operations and notifications defined in PS3.7.

  • comply with the rules governing SOP Class types outlined in Section 7.3;

  • accept a Presentation Context for the Verification SOP Class as an SCP if the implementation accepts any DICOM association requests;

  • produce and/or process Data Sets as defined in PS3.5;

Note

Conformance to PS3.5 also implies conformance to PS3.6.

  • obtain legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard);

  • support the following communication mode:

  • TCP/IP (See PS3.8),

7.2 DICOM Media Interchange Conformance Requirements

An implementation claiming DICOM Media Interchange conformance shall:

  • conform to the minimum conformance requirements defined in this section;

  • provide with the implementation a Conformance Statement structured according to the rules and policies in this Part including Annex C;

  • conform to at least one Standard Application Profile as defined in PS3.11;

  • support one of the Physical Media and associated Media Format, as specified by PS3.12;

  • comply with the rules governing SOP Class types outlined in Section 7.3;

  • comply with the specific rules governing media storage Application Profile according to their types as specified in Section 7.4. No other types of Application Profiles may be used;

  • read as an FSR or FSU all SOP Classes defined as mandatory by each of the supported Application Profiles encoded in any of the mandatory Transfer Syntaxes.

  • write as an FSC or FSU all SOP Classes defined as mandatory by each of the supported Application Profiles in one of the mandatory Transfer Syntaxes;

  • be able to gracefully ignore any Standard, Standard Extended, specialized or Private SOP Classes that may be present on the Storage Medium but are not defined in any of the Application Profiles to which conformance is claimed.

Note

There may be more than one Application Profile used to create or read a File-set on a single physical medium (e.g., a medium may have a File-set created with Standard and Augmented Application Profiles).

  • be able to gracefully ignore Directory Records in the DICOMDIR file that do not correspond to Directory Records defined in any of the Application Profiles to which conformance is claimed.

  • access the File-set(s) on media using the standard roles defined in PS3.10;

  • produce and/or process Data Sets as defined in PS3.5 encapsulated in DICOM Files;

Note

Conformance to PS3.5 also implies conformance to PS3.6

  • obtain legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).

An implementation that does not meet all the above requirements shall not claim conformance to DICOM for Media Storage Interchange.

7.3 Rules Governing Types of SOP Classes

Each SOP Class published in a Conformance Statement is one of four basic types. Each SOP Class in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of SOP Class.

Standard SOP Classes conform to all relevant Parts of the DICOM Standard with no additions or changes.

To claim conformance to a Standard SOP Class, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.

Standard Extended SOP Classes shall:

  1. be a proper super set of one Standard SOP Class;

  2. not change the semantics of any Standard Attribute of that Standard SOP Class;

  3. not contain any Private Type 1, 1C, 2, or 2C Attributes, nor add additional Standard Type 1, 1C, 2 or 2C Attributes;

  4. not change any Standard Type 3 Attributes to Type 1, 1C, 2, or 2C;

  5. use the same UID as the Standard SOP Class on which it is based.

A Standard Extended SOP Class may include Standard and/or Private Type 3 Attributes beyond those defined in the IOD on which it is based as long as the Conformance Statement identifies the added Attributes and defines their relationship with the PS3.3 information model.

An implementation claiming conformance with a Standard Extended SOP Class shall identify in its Conformance Statement the Standard SOP Class being extended, the options, roles, and behavior selected, and describe the Attributes being added with the Standard SOP Class's IOD Model and Modules.

Specialized SOP Classes shall:

  1. be completely conformant to relevant Parts of the DICOM Standard;

  2. be based on a Standard SOP Class, i.e.:

    • contain all the Type 1, 1C, 2, and 2C Attributes of Standard SOP Class on which it is based;

    • not change the semantics of any Standard Attribute;

    • use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);

  3. be based on the DICOM Information Model in PS3.3 and PS3.4.

Specialized SOP Classes may:

  1. contain additional Standard and/or Private Type 1, 1C, 2, or 2C Attributes;

  2. add Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.

    Note

    The usage of any unpublished Attributes may be ignored by other users and providers of the Specialized SOP Class.

  3. enumerate the permitted values for Attributes within the set allowed by the Standard SOP Class;

  4. enumerate the permitted Templates for Content Items within the set allowed by the Standard SOP Class.

An implementation claiming conformance with a Specialized SOP Class shall include in its Conformance Statement the identity of the Standard SOP Class being specialized, a description of usage of all Standard and Private Type 1, 1C, 2, and 2C Attributes in the Specialized SOP Class, a description of the constraints on Attributes values and Templates, and the associated Privately Defined UID.

Private SOP Classes shall:

  1. be completely conformant to relevant Parts of the DICOM Standard with the possible exception that support of the DICOM Default Transfer Syntax or a Transfer Syntax mandated by a media storage Application Profile is not required;

  2. not change the PS3.6 specification of any Standard Attributes;

  3. use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);

  4. not change existing DIMSE Services or create new ones;

  5. not change existing DICOM File Services defined in PS3.10 or extend them in a manner that jeopardizes interoperability.

Private SOP Classes may:

  1. use or apply DIMSE Services to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);

  2. use or apply Media Storage Operations to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);

  3. designate any Standard Attribute as Type 1, 1C, 2, or 2C regardless of the Type of the Attribute in other IODs;

  4. define Private Attributes as Type 1, 1C, 2, or 2C;

  5. include Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.

An implementation claiming conformance with a Private SOP Class shall provide a PS3.3, PS3.4, and PS3.6-like description of the Private SOP Class in the implementation's Conformance Statement, including descriptions of the usage of all Standard and Private Type 1, 1C, 2, or 2C Attributes in the SOP Class, the DICOM Information Model, and the Privately Defined UIDs.

Note

Unpublished SOP Classes (i.e., SOP Classes that are not defined in the DICOM Standard and are not defined in the Conformance Statement) are permitted in order to allow an implementation to support other abstract syntaxes within the DICOM Application Context. Such unpublished SOP Classes would utilize Privately Defined UIDs. The presence of an unpublished SOP Class does not prevent the implementation from being DICOM conformant but would have no meaning to other implementations and may be ignored.

7.4 Rules Governing Types of Application Profiles

Application Profile used in a Conformance Statement shall be of one of three basic types. Each Application Profile in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of Application Profile.

7.4.1 Standard Application Profile

A Standard Application Profile shall:

  1. conform to all relevant Parts of DICOM with no changes;

  2. support only one of the Physical Media and associated Media Format, as specified by PS3.12.

To claim conformance to a Standard Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.

An implementation of a Standard Application Profile may extend Standard SOP Classes of this Standard application profile. Such Standard Extended SOP Classes shall meet the requirements specified in Section 7.3.

7.4.2 Augmented Application Profile

An Augmented Application Profile shall:

  1. be a proper super set of the Standard Application Profile. It adds the support of additional Standard or Standard Extended SOP Classes;

  2. use the same Physical Media and its associated Media Format specified in the corresponding Standard Application Profile;

  3. not include Specialized or Private SOP Classes.

An Augmented Application Profile may:

  1. include one or more Standard or Standard Extended SOP Classes in addition to those of the corresponding Standard Application Profile. These additional SOP Classes may be mandatory or optional;

  2. include the extensions (e.g., additional required keys, additional directory records) to the Basic Directory Information Object corresponding to the SOP Classes defined in a);

  3. add one or more new roles (FSC, FSR, FSU).

To claim conformance to an Augmented Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and shall identify the Standard Application Profile from which it is derived and specify the augmentations. The implementation shall also identify its selected options, roles, and behavior.

An implementation of a Augmented Application Profile may:

  1. extend Standard SOP Classes of the corresponding Standard application profile. Such Standard Extended SOP Classes shall meet the requirements specified in Section 7.3;

  2. also claim conformance to the Standard Application Profile on which this Augmented Profile is based. In this case, FSC and FSU implementations shall be able to restrict their behavior to the Standard Application Profile (i.e., provide a means to write only the Standard or Standard Extended SOP Classes defined in the corresponding Standard Application Profile).

7.4.3 Private Application Profile

A Private Application Profile:

  • conforms to PS3.10 and to the Media Storage Service Class specified in PS3.4;

  • support only one of the Physical Media and associated Media Format, as specified by PS3.12;

    Note

    The intent of these two conditions is to ensure that at least the DICOMDIR is readable by other APs.

  • complies with the rules governing SOP Classes in Section 7.3.

To claim conformance to a Private Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and shall provide a description of the Application Profile patterned after the descriptions in PS3.11. The implementation shall also identify its selected options, roles, and behavior.

Note

An implementation that does not meet the provisions of Section 7, including the types of Application Profile, is not conformant to DICOM and so is outside the scope of DICOM conformance. Such an implementation is not an Application Profile in DICOM terminology. For example, if an implementation chooses to write DICOM files onto media that is not in PS3.12, or use a file system not defined for a specific media type in PS3.12, then that implementation cannot claim that it conforms to the DICOM Standard using that media or file system.

7.5 Conformance of DICOM Media

DICOM does not define conformance of a piece of medium in a generic sense. DICOM conformance of a piece of medium can only be evaluated within the scope of one or more media storage Application Profiles that define specific contexts for interoperability.

Note

One may accept the statement "this is a DICOM CD-R" when pointing to a storage medium. However, one should not state "this CD-R is DICOM conformant", but rather "this CD-R conforms to the Basic Cardiac X-ray Angiographic DICOM Application Profile".

7.6 Security Profiles

DICOM specifies methods for providing security at different levels of the ISO OSI Basic Reference Model through the use of mechanisms specific to a particular layer. The methods for applying these mechanisms are described in the various parts of the DICOM Standard. Some mechanisms and algorithms are specified in PS3.15 as Security Profiles. An implementation's Conformance Statement describes which Security Profiles can be used by that application.

Note

For example, the Basic TLS Secure Transport Connection Profile defines a mechanism for authenticating entities participating in the exchange of data, and for protecting the integrity and confidentiality of information during interchange.

An implementation shall list in its Conformance Statement any Security Profiles that it supports, how it selects which Security Profiles it uses, how it uses features of that Security Profile, and any extensions it makes to that Security Profile.

An implementation shall list in its Conformance Statement any additional use of the User Identity association negotiation sub-item that is not specified in a standard Security Profile.

7.7 Transformation of DICOM SR to CDA

DICOM specifies the transformation of DICOM SR objects to CDA documents in PS3.20.

This transformation is unidirectional (DICOM SR to HL7 CDA). Conformance statements shall at a minimum state conformance to the top level templates used for the SR document and the CDA document.

A DICOM Conformance Statement Template (Normative)

This Annex is a template that shall be used to generate a DICOM Conformance Statement. The document is hierarchically structured in three different levels:

  • A DICOM Conformance Statement Overview, which is typically one page, geared towards people that want to get a quick overview of the functionality and services.

  • For Networking and Media, the relationship between the AEs, followed by the information for each AE

  • For the services supported as SCU and SCP all the SOP specific details

Annexes are provided to specify the Object descriptions (IODs), with specifics about the field usage as well as the data dictionaries.

Note

The numbering scheme for numbering paragraphs in this document is to be used as a guideline in preparing the outline of the Conformance Statement. Although strongly encouraged, the Conformance Statement is not required to have exactly the same paragraph numbers because a particular Conformance Statement might have special considerations, which will cause the outline to differ in certain details from the outline of this document. In addition, a vendor might have internal company guidelines prescribing a specific format. Note however, that the overall structure, tables, definition of variables and information such as headers, should be strictly followed.

A.0 Cover Page

A DICOM Conformance Statement may have a cover page, which, if present, shall include:

  1. The commercial name and version(s) of the concerned product or products (if applicable to several products) including all optional features. The product version shall correspond to the functionality as described in this conformance statement.

  2. Date of the document

A.1 Conformance Statement Overview

The Overview consist of typically 5-10 lines describing the network services and media storage capabilities supported by the product in layman's terms (i.e., no DICOM acronyms should be used).

A table of Supported Networking DICOM Service (SOP) Classes is provided with roles (User/Provider), organized in 4 categories:

  • Transfer

  • Query/Retrieve

  • Workflow Management

  • Print Management

The first column shall specify the SOP Classes exactly as named in PS3.6., Registry of DICOM Unique Identifiers. The phrase "and specializations" may be added to indicate support of all specializations negotiated through the SOP Class Common Extended Negotiation. If the implementation supports all SOP Classes of a particular Service Class through SOP Class Common Extended Negotiation, the first column shall specify "All services of the <x> Service Class".

Table A.1-1. Network Services

SOP Classes

User of Service (SCU)

Provider of Service (SCP)

Transfer

CT Image Storage

Yes

No

US Image Storage

Yes

Yes

Query/Retrieve

Patient Root Information Model FIND

Option

No

Notes, Reports, Measurements Transfer

Comprehensive SR, and specializations

No

Yes


The services can be specified as a SCU, SCP or as an Option, which means that it is either configurable or that it can be purchased separately.

Note

Verification SCP (C-Echo) is not included in the table above because it is required for any Acceptor of an Association. The Verification SCU details are covered in the details of the conformance statement.

The SOP Classes are categorized as follows:

Table A.1-2. UID Values

UID Value

UID Name

Category

1.2.840.10008.1.20.1

Storage Commitment Push Model SOP Class

Workflow Management

1.2.840.10008.1.40

Procedural Event Logging SOP Class

Workflow Management

1.2.840.10008.1.42

Substance Administration Logging SOP Class

Workflow Management

1.­2.840.10008.3.1.2.3.3

Modality Performed Procedure Step SOP Class

Workflow Management

1.­2.840.10008.3.1.2.3.4

Modality Performed Procedure Step Retrieve SOP Class

Workflow Management

1.­2.840.10008.3.1.2.3.5

Modality Performed Procedure Step Notification SOP Class

Workflow Management

1.2.840.10008.4.2

Storage Service Class

Transfer

1.2.840.10008.5.1.1.1

Basic Film Session SOP Class

Print Management

1.2.840.10008.5.1.1.2

Basic Film Box SOP Class

Print Management

1.2.840.10008.5.1.1.4

Basic Grayscale Image Box SOP Class

Print Management

1.2.840.10008.5.1.1.4.1

Basic Color Image Box SOP Class

Print Management

1.2.840.10008.5.1.1.9

Basic Grayscale Print Management Meta SOP Class

Print Management

1.2.840.10008.5.1.1.14

Print Job SOP Class

Print Management

1.2.840.10008.5.1.1.15

Basic Annotation Box SOP Class

Print Management

1.2.840.10008.5.1.1.16

Printer SOP Class

Print Management

1.2.840.10008.5.1.1.16.376

Printer Configuration Retrieval SOP Class

Print Management

1.2.840.10008.5.1.1.18

Basic Color Print Management Meta SOP Class

Print Management

1.2.840.10008.5.1.1.23

Presentation LUT SOP Class

Print Management

1.2.840.10008.5.1.1.24.1

Basic Print Image Overlay Box SOP Class

Print Management

1.2.840.10008.5.1.1.33

Media Creation Management SOP Class

Print Management

1.2.840.10008.5.1.4.1.1.1

Computed Radiography Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.1.1

Digital X-Ray Image Storage - For Presentation SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.1.1.1

Digital X-Ray Image Storage - For Processing SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.1.2

Digital Mammography X-Ray Image Storage - For Presentation SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.1.2.1

Digital Mammography X-Ray Image Storage - For Processing SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.1.3

Digital Intra-oral X-Ray Image Storage - For Presentation SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.1.3.1

Digital Intra-oral X-Ray Image Storage - For Processing SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.2

CT Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.2.1

Enhanced CT Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.3.1

Ultrasound Multi-frame Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.4

MR Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.4.1

Enhanced MR Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.4.2

MR Spectroscopy Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.4.3

Enhanced MR Color Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.6.2

Enhanced US Volume Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.7

Secondary Capture Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.7.1

Multi-frame Single Bit Secondary Capture Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.7.2

Multi-frame Grayscale Byte Secondary Capture Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.7.3

Multi-frame Grayscale Word Secondary Capture Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.7.4

Multi-frame True Color Secondary Capture Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.1.1

12-lead ECG Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.1.2

General ECG Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.1.3

Ambulatory ECG Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.2.1

Hemodynamic Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.3.1

Cardiac Electrophysiology Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.4.1

Basic Voice Audio Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.4.2

General Audio Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.5.1

Arterial Pulse Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.9.6.1

Respiratory Waveform Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.11.1

Grayscale Softcopy Presentation State Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.11.2

Color Softcopy Presentation State Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.11.3

Pseudo-Color Softcopy Presentation State Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.11.4

Blending Softcopy Presentation State Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.11.5

XA/XRF Grayscale Softcopy Presentation State Storage SOP Class

Transfer

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

Grayscale Planar MPR Volumetric Presentation State Storage SOP Class

Transfer

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

Compositing Planar MPR Volumetric Presentation State Storage SOP Class

Transfer

1.2.840.10008.​5.​1.​4.​1.​1.​11.​8

Advanced Blending Presentation State Storage SOP Class

Transfer

1.2.840.10008.​5.​1.​4.​1.​1.​11.​9

Volume Rendering Volumetric Presentation State Storage SOP Class

Transfer

1.2.840.10008.​5.​1.​4.​1.​1.​11.​10

Segmented Volume Rendering Volumetric Presentation State Storage SOP Class

Transfer

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

Multiple Volume Rendering Volumetric Presentation State Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.12.1

X-Ray Angiographic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.12.1.1

Enhanced XA Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.12.2

X-Ray Radiofluoroscopic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.12.2.1

Enhanced XRF Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.13.1.1

X-Ray 3D Angiographic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.13.1.2

X-Ray 3D Craniofacial Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.13.1.3

Breast Tomosynthesis Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.13.1.4

Breast Projection X-Ray Image Storage - For Presentation SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.13.1.5

Breast Projection X-Ray Image Storage - For Processing SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.14.1

Intravascular Optical Coherence Tomography Image Storage - For Presentation SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.14.2

Intravascular Optical Coherence Tomography Image Storage - For Processing SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.20

Nuclear Medicine Image Storage SOP Classe

Transfer

1.2.840.10008.5.1.4.1.1.30

Parametric Map Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66

Raw Data Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66.1

Spatial Registration Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66.2

Spatial Fiducials Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66.3

Deformable Spatial Registration Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66.4

Segmentation Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66.5

Surface Segmentation Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.66.6

Tractography Results Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.67

Real World Value Mapping Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.68.1

Surface Scan Mesh Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.68.2

Surface Scan Point Cloud Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.1

VL Endoscopic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.1.1

Video Endoscopic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.2

VL Microscopic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.2.1

Video Microscopic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.3

VL Slide-Coordinates Microscopic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.4

VL Photographic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.4.1

Video Photographic Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.1

Ophthalmic Photography 8 Bit Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.2

Ophthalmic Photography 16 Bit Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.3

Stereometric Relationship Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.4

Ophthalmic Tomography Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.5

Wide Field Ophthalmic Photography Stereographic Projection Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.6

Wide Field Ophthalmic Photography 3D Coordinates Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.7

Ophthalmic Optical Coherence Tomography En Face Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.5.8

Ophthalmic Optical Coherence Tomography B-scan Volume Analysis Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.77.1.6

VL Whole Slide Microscopy Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.1

Lensometry Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.2

Autorefraction Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.3

Keratometry Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.4

Subjective Refraction Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.5

Visual Acuity Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.6

Spectacle Prescription Report Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.7

Ophthalmic Axial Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.78.8

Intraocular Lens Calculations Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.79.1

Macular Grid Thickness and Volume Report Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.80.1

Ophthalmic Visual Field Static Perimetry Measurements Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.81.1

Ophthalmic Thickness Map Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.82.1

Corneal Topography Map Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.11

Basic Text SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.34

Comprehensive 3D SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.40

Procedure Log Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.50

Mammography CAD SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.59

Key Object Selection Document Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.65

Chest CAD SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.67

X-Ray Radiation Dose SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.68

Radiopharmaceutical Radiation Dose SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.69

Colon CAD SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.88.70

Implantation Plan SR Document Storage SOP Class

Transfer

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

Acquisition Context SR Storage SOP Class

Transfer

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

Simplified Adult Echo SR Storage SOP Class

Transfer

1.2.840.10008.5.​1.​4.​1.​1.​88.​73

Patient Radiation Dose SR Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.90.1

Content Assessment Results Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.104.1

Encapsulated PDF Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.104.2

Encapsulated CDA Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.128

Positron Emission Tomography Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.130

Enhanced PET Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.131

Basic Structured Display Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.200.1

CT Defined Procedure Protocol Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.200.2

CT Performed Procedure Protocol Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.200.3

Protocol Approval Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.1

RT Image Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.2

RT Dose Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.3

RT Structure Set Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.4

RT Beams Treatment Record Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.5

RT Plan Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.6

RT Brachy Treatment Record Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.1.481.7

RT Treatment Summary Record Storage SOP Class

Transfer

1.2.840.10008.5.1.4.1.2.1.1

Patient Root Query/Retrieve Information Model - FIND SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.1.2

Patient Root Query/Retrieve Information Model - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.1.3

Patient Root Query/Retrieve Information Model - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.2.1

Study Root Query/Retrieve Information Model - FIND SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.2.2

Study Root Query/Retrieve Information Model - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.2.3

Study Root Query/Retrieve Information Model - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.4.2

Composite Instance Root Retrieve - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.4.3

Composite Instance Root Retrieve - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.2.5.3

Composite Instance Retrieve Without Bulk Data - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.20.1

Defined Procedure Protocol Information Model - FIND SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.20.2

Defined Procedure Protocol Information Model - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.20.3

Defined Procedure Protocol Information Model - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.1.200.4

Protocol Approval Information Model - FIND SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.1.200.5

Protocol Approval Information Model - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.1.1.200.6

Protocol Approval Information Model - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.31

Modality Worklist Information Model - FIND SOP Class

Workflow Management

1.2.840.10008.5.1.4.32.1

General Purpose Worklist Information Model - FIND SOP Class (Retired)

Workflow Management

1.2.840.10008.5.1.4.32.2

General Purpose Scheduled Procedure Step SOP Class (Retired)

Workflow Management

1.2.840.10008.5.1.4.32.3

General Purpose Performed Procedure Step SOP Class (Retired)

Workflow Management

1.2.840.10008.5.1.4.32

General Purpose Worklist Management Meta SOP Class (Retired)

Workflow Management

1.2.840.10008.5.1.4.33

Instance Availability Notification SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.6.1

Unified Procedure Step - Push SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.6.2

Unified Procedure Step - Watch SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.6.3

Unified Procedure Step - Pull SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.6.4

Unified Procedure Step - Event SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.7

RT Beams Delivery Instruction Storage SOP Class

Transfer

1.2.840.10008.5.1.4.34.8

RT Conventional Machine Verification SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.9

RT Ion Machine Verification SOP Class

Workflow Management

1.2.840.10008.5.1.4.34.10

RT Brachy Application Setup Delivery Instruction Storage SOP Class

Transfer

1.2.840.10008.5.1.4.37.1

General Relevant Patient Information Query SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.37.2

Breast Imaging Relevant Patient Information Query SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.37.3

Cardiac Relevant Patient Information Query SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.38.1

Hanging Protocol Storage SOP Class

Transfer

1.2.840.10008.5.1.4.38.2

Hanging Protocol Information Model - FIND SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.38.3

Hanging Protocol Information Model - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.39.1

Color Palette Storage SOP Class

Transfer

1.2.840.10008.5.1.4.39.2

Color Palette Information Model - FIND SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.39.3

Color Palette Information Model - MOVE SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.39.4

Color Palette Information Model - GET SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.41

Product Characteristics Query SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.42

Substance Approval Query SOP Class

Query/Retrieve

1.2.840.10008.5.1.4.43.1

Generic Implant Template Storage SOP Class

Transfer

1.2.840.10008.5.1.4.43.2

Generic Implant Template Information Model - FIND SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.43.3

Generic Implant Template Information Model - MOVE SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.43.4

Generic Implant Template Information Model - GET SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.44.1

Implant Assembly Template Storage SOP Class

Transfer

1.2.840.10008.5.1.4.44.2

Implant Assembly Template Information Model - FIND SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.44.3

Implant Assembly Template Information Model - MOVE SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.44.4

Implant Assembly Template Information Model - GET SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.45.1

Implant Template Group Storage SOP Class

Transfer

1.2.840.10008.5.1.4.45.2

Implant Template Group Information Model - FIND SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.45.3

Implant Template Group Information Model - MOVE SOP Class

Query / Retrieve

1.2.840.10008.5.1.4.45.4

Implant Template Group Information Model - GET SOP Class

Query / Retrieve


A table of Supported Media Storage Application Profiles (with roles) is provided, organized in categories:

  • Compact Disk - Recordable

  • Magneto-Optical Disk

  • DVD

  • BD

  • USB and Flash Memory

  • Email

  • Other Media

Table A.1-3. Media Services

Media Storage Application Profile

Write Files (FSC or FSU)

Read Files (FSR)

Compact Disk - Recordable

General Purpose CD-R

Option

Yes

Magneto-Optical Disk

CT/MR 2.3 GB MOD

Yes

Yes

DVD

General Purpose DVD-RAM

Yes

Yes

BD

General Purpose BD Interchange with MPEG-4 AVC/H.264 BD-Compatible HiP@Level4.1

Yes

Yes

USB and Flash Memory

General Purpose USB Media Interchange with JPEG

Yes

Yes

Email

General Purpose MIME Interchange

Yes

No

General Purpose ZIP Email

Yes

No


A.2 Table of Contents

The table of contents will be provided to assist readers in easily finding the needed information.

A.3 Introduction

The introduction specifies product and relevant disclaimers as well as any general information that the vendor feels is appropriate.

The following subsections are suggested:

A.3.1 Revision History

The revision history provides dates and differences of the different releases of the product and the Conformance Statement.

A.3.2 Audience

The audience is specified with their assumed pre-knowledge. The following example may be used as a template:

This document is written for the people that need to understand how <Product Name> will integrate into their healthcare facility. This includes both those responsible for overall imaging network policy and architecture, as well as integrators who need to have a detailed understanding of the DICOM features of the product. This document contains some basic DICOM definitions so that any reader may understand how this product implements DICOM features. However, integrators are expected to fully understand all the DICOM terminology, how the tables in this document relate to the product's functionality, and how that functionality integrates with other devices that support compatible DICOM features.

A.3.3 Remarks

Any important remarks, disclaimers, and general information are specified. The following example may be used as a template:

The scope of this DICOM Conformance Statement is to facilitate integration between <Product Name> and other DICOM products. The Conformance Statement should be read and understood in conjunction with the DICOM Standard. DICOM by itself does not guarantee interoperability. The Conformance Statement does, however, facilitate a first-level comparison for interoperability between different applications supporting compatible DICOM functionality.

This Conformance Statement is not supposed to replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, the user should be aware of the following important issues:

  • The comparison of different Conformance Statements is just the first step towards assessing interconnectivity and interoperability between the product and other DICOM conformant equipment.

  • Test procedures should be defined and executed to validate the required level of interoperability with specific compatible DICOM equipment, as established by the healthcare facility.

If the product has an IHE Integration Statement, the following statement may be applicable:

<Product Name> has participated in an industry-wide testing program sponsored by Integrating the Healthcare Enterprise (IHE). The IHE Integration Statement for <Product Name>, together with the IHE Technical Framework, may facilitate the process of validation testing.

A.3.4 Terms and Definitions

Terms and definitions should be listed here. The following example may be used as a template:

Informal definitions are provided for the following terms used in this Conformance Statement. The DICOM Standard is the authoritative source for formal definitions of these terms.

Abstract Syntax

The information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) Class. Examples: Verification SOP Class, Modality Worklist Information Model Find SOP Class, Computed Radiography Image Storage SOP Class.

Application Entity (AE)

An end point of a DICOM information exchange, including the DICOM network or media interface software; i.e., the software that sends or receives DICOM information objects or messages. A single device may have multiple Application Entities.

Application Entity Title (AET)

The externally known name of an Application Entity, used to identify a DICOM application to other DICOM applications on the network.

Application Context

The specification of the type of communication used between Application Entities. Example: DICOM network protocol.

Association

A network communication channel set up between Application Entities.

Attribute

A unit of information in an object definition; a data element identified by a tag. The information may be a complex data structure (Sequence), itself composed of lower level data elements. Examples: Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation (0028,0004), Procedure Code Sequence (0008,1032).

Information Object Definition (IOD)

The specified set of Attributes that comprise a type of data object; does not represent a specific instance of the data object, but rather a class of similar data objects that have the same properties. The Attributes may be specified as Mandatory (Type 1), Required but possibly unknown (Type 2), or Optional (Type 3), and there may be conditions associated with the use of an Attribute (Types 1C and 2C). Examples: MR Image IOD, CT Image IOD, Print Job IOD.

Joint Photographic Experts Group (JPEG)

A set of standardized image compression techniques, available for use by DICOM applications.

Media Application Profile

The specification of DICOM information objects and encoding exchanged on removable media (e.g., CDs)

Module

A set of Attributes within an Information Object Definition that are logically related to each other. Example: Patient Module includes Patient Name, Patient ID, Patient Birth Date, and Patient Sex.

Negotiation

First phase of Association establishment that allows Application Entities to agree on the types of data to be exchanged and how that data will be encoded.

Presentation Context

The set of DICOM network services used over an Association, as negotiated between Application Entities; includes Abstract Syntaxes and Transfer Syntaxes.

Protocol Data Unit (PDU)

A packet (piece) of a DICOM message sent across the network. Devices must specify the maximum size packet they can receive for DICOM messages.

Security Profile

A set of mechanisms, such as encryption, user authentication, or digital signatures, used by an Application Entity to ensure confidentiality, integrity, and/or availability of exchanged DICOM data

Service Class Provider (SCP)

Role of an Application Entity that provides a DICOM network service; typically, a server that performs operations requested by another Application Entity (Service Class User). Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP).

Service Class User (SCU)

Role of an Application Entity that uses a DICOM network service; typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU)

Service/Object Pair Class (SOP Class)

The specification of the network or media transfer (service) of a particular type of data (object); the fundamental unit of DICOM interoperability specification. Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management.

Service/Object Pair Instance (SOP Instance)

An information object; a specific occurrence of information exchanged in a SOP Class. Examples: a specific x-ray image.

Tag

A 32-bit identifier for a data element, represented as a pair of four digit hexadecimal numbers, the "group" and the "element". If the "group" number is odd, the tag is for a private (manufacturer-specific) data element. Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element]

Transfer Syntax

The encoding used for exchange of DICOM information objects and messages. Examples: JPEG compressed (images), little endian explicit value representation.

Unique Identifier (UID)

A globally unique "dotted decimal" string that identifies a specific object or a class of objects; an ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOP Instance UID.

Value Representation (VR)

The format type of an individual DICOM data element, such as text, an integer, a person's name, or a code. DICOM information objects can be transmitted with either explicit identification of the type of each data element (Explicit VR), or without explicit identification (Implicit VR); with Implicit VR, the receiving application must use a DICOM data dictionary to look up the format of each data element.

A.3.5 Basics of DICOM Communication

A layman's introduction to DICOM may be included here. The following example may be used as a template:

This section describes terminology used in this Conformance Statement for the non-specialist. The key terms used in the Conformance Statement are highlighted in italics below. This section is not a substitute for training about DICOM, and it makes many simplifications about the meanings of DICOM terms.

Two Application Entities (devices) that want to communicate with each other over a network using DICOM protocol must first agree on several things during an initial network "handshake". One of the two devices must initiate an Association (a connection to the other device), and ask if specific services, information, and encoding can be supported by the other device (Negotiation).

DICOM specifies a number of network services and types of information objects, each of which is called an Abstract Syntax for the Negotiation. DICOM also specifies a variety of methods for encoding data, denoted Transfer Syntaxes. The Negotiation allows the initiating Application Entity to propose combinations of Abstract Syntax and Transfer Syntax to be used on the Association; these combinations are called Presentation Contexts. The receiving Application Entity accepts the Presentation Contexts it supports.

For each Presentation Context, the Association Negotiation also allows the devices to agree on Roles - which one is the Service Class User (SCU - client) and which is the Service Class Provider (SCP - server). Normally the device initiating the connection is the SCU, i.e., the client system calls the server, but not always.

The Association Negotiation finally enables exchange of maximum network packet (PDU) size, security information, and network service options (called Extended Negotiation information).

The Application Entities, having negotiated the Association parameters, may now commence exchanging data. Common data exchanges include queries for worklists and lists of stored images, transfer of image objects and analyses (structured reports), and sending images to film printers. Each exchangeable unit of data is formatted by the sender in accordance with the appropriate Information Object Definition, and sent using the negotiated Transfer Syntax. There is a Default Transfer Syntax that all systems must accept, but it may not be the most efficient for some use cases. Each transfer is explicitly acknowledged by the receiver with a Response Status indicating success, failure, or that query or retrieve operations are still in process.

Two Application Entities may also communicate with each other by exchanging media (such as a CD-R). Since there is no Association Negotiation possible, they both use a Media Application Profile that specifies "pre-negotiated" exchange media format, Abstract Syntax, and Transfer Syntax.

A.3.6 Abbreviations

Abbreviations should be listed here. These may be taken from the following list, deleting terms that are not used within the Conformance Statement, and adding any additional terms that are used:

AE

Application Entity

AET

Application Entity Title

CAD

Computer Aided Detection

CDA

Clinical Document Architecture

CD-R

Compact Disk Recordable

CSE

Customer Service Engineer

CR

Computed Radiography

CT

Computed Tomography

DHCP

Dynamic Host Configuration Protocol

DICOM

Digital Imaging and Communications in Medicine

DIT

Directory Information Tree (LDAP)

DN

Distinguished Name (LDAP)

DNS

Domain Name System

DX

Digital X-ray

FSC

File-Set Creator

FSU

File-Set Updater

FSR

File-Set Reader

GSDF

Grayscale Standard Display Function

GSPS

Grayscale Softcopy Presentation State

HIS

Hospital Information System

HL7

Health Level 7 Standard

IHE

Integrating the Healthcare Enterprise

IOD

Information Object Definition

IPv4

Internet Protocol version 4

IPv6

Internet Protocol version 6

ISO

International Organization for Standards

IO

Intra-oral X-ray

JPEG

Joint Photographic Experts Group

LDAP

Lightweight Directory Access Protocol

LDIF

LDAP Data Interchange Format

LUT

Look-up Table

MAR

Medication Administration Record

MPEG

Moving Picture Experts Group

MG

Mammography (X-ray)

MPPS

Modality Performed Procedure Step

MR

Magnetic Resonance Imaging

MSPS

Modality Scheduled Procedure Step

MTU

Maximum Transmission Unit (IP)

MWL

Modality Worklist

NM

Nuclear Medicine

NTP

Network Time Protocol

O

Optional (Key Attribute)

OP

Ophthalmic Photography

OSI

Open Systems Interconnection

PACS

Picture Archiving and Communication System

PET

Positron Emission Tomography

PDU

Protocol Data Unit

R

Required (Key Attribute)

RDN

Relative Distinguished Name (LDAP)

RF

Radiofluoroscopy

RIS

Radiology Information System.

RT

Radiotherapy

SC

Secondary Capture

SCP

Service Class Provider

SCU

Service Class User

SOP

Service-Object Pair

SPS

Scheduled Procedure Step

SR

Structured Reporting

TCP/IP

Transmission Control Protocol/Internet Protocol

U

Unique (Key Attribute)

UL

Upper Layer

US

Ultrasound

VL

Visible Light

VR

Value Representation

XA

X-ray Angiography

A.3.7 References

Referenced documents should be listed here, including appropriate product manuals (such as service manuals that specify how to set DICOM communication parameters). References to the DICOM Standard should provide the URL for the free published version of the Standard, but should not specify a date of publication:

NEMA PS3 Digital Imaging and Communications in Medicine (DICOM) Standard, available free at http://medical.nema.org/

A.4 Networking

This section contains the networking related services (vs. the media related ones).

A.4.1 Implementation Model

The Implementation model consists of three sections: the Application Data Flow Diagram, specifying the relationship between the Application Entities and the "external world" or Real-World activities, a functional description of each Application Entity, and the sequencing constraints among them.

A.4.1.1 Application Data Flow

As part of the Implementation model, an Application Data Flow Diagram shall be included. This diagram represents all of the Application Entities present in an implementation, and graphically depicts the relationship of the AEs use of DICOM to Real-World Activities as well as any applicable User interaction. Figure A.4.1-1 is a template for such a Data Flow Diagram.

In this illustration, according to figure A.4.1-1, an occurrence of local Real-World Activity A will cause local Application Entity <1> to initiate an association for the purpose of causing Real-World Activity X to occur remotely. It also shows that Real-World Activities B and Y are interactively related via Application Entity <2>, with B being local and Y Remote, and that local Application Entity 3 expects to receive an association request when remote Real-World Activity Z occurs so that it can perform Real-World Activity C and/or D. When the performance of Real-World activities relies on interactions within the implementation, one may depict the circles as overlapping as shown in Figure A.4.1-1. Any such overlap shall be discussed in this section of a Conformance Statement.

Typically, there is a one to one relationship between an AE and an AE Title. Devices may be capable of configuring the relationship between AE and AE Title (e.g., by merging Application Entities to use a single AE Title). This is specified in the configuration section.

Functional Overview

Figure A.4.1-1. Functional Overview


The Application Data Flow Diagram shall contain overview text with one bullet per AE. Each bullet should provide an overview of each one of the AEs, in relationship to their real-world activities, AE network exchanges and external real-world activities.

Note

There is no standard definition or guidelines on the number of AEs within a product and what an AE should encompass. Its functionality and scope is purely to the discretion of the vendor and typically depending on the system architecture.

A.4.1.2 Functional Definition of AEs

This part shall contain a functional definition for each individual local Application Entity. This shall describe in general terms the functions to be performed by the AE, and the DICOM services used to accomplish these functions. In this sense, "DICOM services" refers not only to DICOM Service Classes, but also to lower level DICOM services, such as Association Services.

A.4.1.2.1 Functional Definition of "Application Entity <1>"

Functional description of "Application Entity <1>" (substitute actual AE name), i.e., what is it that the AE performs.

A.4.1.2.2 Functional Definition of "Application Entity <2>"

Same for "Application Entity <2>".

A.4.1.2.3 Functional Definition of "Application Entity <3>"

Same for "Application Entity <3>".

A.4.1.3 Sequencing of Real World Activities

If applicable, this section shall contain a description of sequencing as well as potential constraints, of Real-World Activities, including any applicable user interactions, as performed by all the Application Entities. A UML sequence diagram, which depicts the Real-World Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.

A.4.2 AE Specifications:

The next section in the DICOM Conformance Statement is a set of Application Entity Specifications. There shall be one such specification for each Application Entity. Each individual AE Specification has a subsection, A.4.2.x. There are as many of these subsections as there are different AEs in the implementation. That is, if there are two distinct AEs, then there will be two subsections, A.4.2.1, and A.4.2.2.

A.4.2.1 "Application Entity <1>"

Every detail of this specific Application Entity shall be completely specified under this section.

AEs that utilize the DIMSE services shall have the following sections.

Note

AEs that utilize other services are described later, and will re-use this section numbering.

A.4.2.1.1 SOP Classes

The specification for an Application Entity shall contain a statement of the form:

"This Application Entity provides Standard Conformance to the following SOP Class(es) :"

Table A.4.2-1. SOP Class(Es) for "Application Entity <1>"

SOP Class Name

SOP Class UID

SCU

SCP

SOP Class UID Name as specified in the registry table of DICOM Unique Identifiers (UID) in PS3.6, with phrase "and specializations" as appropriate

UID as specified in PS3.6

Yes/No

Yes/No


Note

Any SOP specific behavior is documented later in the conformance statement in the applicable SOP specific conformance section.

A.4.2.1.2 Association Policies

Each AE Specification shall contain a description of the General Association Establishment and Acceptance policies of the AE.

A.4.2.1.2.1 General

The DICOM standard Application context shall be specified.

Table A.4.2-2. DICOM Application Context

Application Context Name

1.2.840.10008.3.1.1.1


A.4.2.1.2.2 Number of Associations.

The number of simultaneous associations, which an Application Entity may support as a SCU or SCP, shall be specified. Any rules governing simultaneity of associations shall be defined here.

Note

For example an AE may have the capability to have up to 10 simultaneous associations, but may limit itself to have no more than 2 with any particular other AE. There may also be policies based upon combinations of simultaneous Real-World Activities.

Table A.4.2-3. Number of Associations as an Association Initiator for "Application Entity <1>"

Maximum number of simultaneous associations

x


Table A.4.2-4. Number of Associations as an Association Acceptor for "Application Entity <1>"

Maximum number of simultaneous associations

x


A.4.2.1.2.3 Asynchronous Nature

If the implementation supports negotiation of multiple outstanding transactions, this shall be stated here, along with the maximum number of outstanding transactions supported.

Table A.4.2-5. Asynchronous Nature as an Association Initiator for "Application Entity <1>"

Maximum number of outstanding asynchronous transactions

x


A.4.2.1.2.4 Implementation Identifying Information

The value supplied for Implementation Class UID shall be documented here. If a version name is supplied, this fact shall be documented here. Policies defining the values supplied for version name may be stated here.

Table A.4.2-6. DICOM Implementation Class and Version for "Application Entity <1>"

Implementation Class UID

a.b.c.xxxxxxx.yyy.zz

Implementation Version Name

XYZxyz


A.4.2.1.3 Association Initiation Policy

This describes the conditions under which the AE will initiate an association.

A.4.2.1.3.1 "Activity <1>"
A.4.2.1.3.1.1 Description and Sequencing of Activities

If applicable, this section shall contain a description of sequencing of the events for "Activity <1>" (substitute actual activity name), including any applicable user interactions, which this specific AE performs. A UML sequence diagram, which depicts the Application Entity and Real-World Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.

Note

An example of a situation in which such a description is required is an AE, which supports both the Storage Service Class and the Modality Performed Procedure SOP Class. Some implementations might store the images before sending the final MPPS N-SET message while other implementations might send the final MPPS N-SET message before sending the images.

A.4.2.1.3.1.2 Proposed Presentation Contexts

Each time an association is initiated, the Association Initiator proposes a number of Presentation Contexts to be used on that association. In this subsection, the Presentation Contexts proposed by "Application Entity <1>" for "Activity <1>" shall be defined in a table with the following format:

Table A.4.2-7. Proposed Presentation Contexts for "Application Entity <1>"

Presentation Context Table

Abstract Syntax

Transfer Syntax

Role

Extended Negotiation

Name

UID

Name List

UID List

name_a

AS_UID_a

XS_Name_1, ..., XS_Name_n

XS_UID_1, _, XS_UID_n

SCP | SCU | BOTH

None |See Note <1> | See Table A.4.2-8

...

...

...

...

...

...


Note

<1>: <Describe the content of any extended negotiation done for the SOP Classes of this Presentation Context. One note may serve multiple Presentation Contexts, as a single Abstract Syntax often corresponds to a single SOP class, which may appear in different Presentation Contexts.>

In Table A.4.2-7, the following meanings are assigned to the fields:

  • <name_a> This is the name of the Abstract Syntax to be used with this Presentation Context.

  • <AS_UID_a> This is the UID of the Abstract Syntax to be used for this Presentation Context.

  • <XS_Name_n> This is the name of a Transfer Syntax that may be used for this Presentation Context.

  • <XS_UID_n> The UID of the corresponding Transfer Syntax.

If the AE through this Real World Activity might propose any of the SOP Classes of a particular Service Class (e.g., the Storage Service Class), the Abstract Syntax Name and UID shall be those of the Service Class. This section shall describe the conditions under which a SOP Class of that Service Class will be proposed in a Presentation Context.

Note

For instance, an AE may receive instances of a non-preconfigured SOP Class through support of SOP Class Common Extended Negotiation. These instances may be limited to specializations of a particular SOP Class, or they may be any SOP Class within the Service Class, and any such limits should be described.

This section shall describe the conditions under which the AE may change the SOP Class UID of SOP Instances sent, due to fall-back mechanisms.

Note

For instance, if the SCP does not accept the proposed Abstract Syntax (SOP Class) for which there is a Related General SOP Class that was accepted, the AE may modify SOP Instances of the refused SOP Class to use the Related General SOP Class for transmission.

In the event that the Abstract Syntax of the Presentation Context represents a Meta-SOP Class (that is, it includes many SOP Classes) and extended negotiation is supported for some of these SOP Classes, the following table is required to define this extended negotiation. This table is referenced in Table A.4.2-7:

Table A.4.2-8. Extended Negotiation as a SCU

SOP Class Name

SOP Class UID

Extended Negotiation

Name_i

SOP_UID_I

None | See Note <1>

...

...

...


Note

<1>: <Describe the content of any extended negotiation done for this SOP Class. One note may serve multiple Presentation Contexts, as a SOP class that may appear in different Presentation Contexts and/or Meta SOP Classes>

The implementation of the initiator shall document which Transfer Syntax will be chosen in case multiple Transfer Syntaxes are accepted during the Association Acceptance.

A.4.2.1.3.1.3 SOP Specific Conformance for SOP Class(Es)

This section includes the SOP specific behavior, i.e., error codes, error and exception handling, time-outs, etc. The information shall be as described in the SOP specific Conformance Statement section of PS3.4 (or relevant private SOP definition). It shall include the content of any extended negotiation. Keys shall be specified including how they are used (Matching, return keys, interactive query, whether they are displayed to the user, universal and/or list matching, etc.).

In particular, the behavior associated with the exchange of images available to the AE only in a lossy compressed form shall be documented. For example, if a lossy compressed transfer syntax is not negotiated, will the AE decompress the image data and send it using one of the negotiated transfer syntaxes.

All details regarding the specific conformance, including response behavior to all status codes, both from an application level and communication errors shall be provided in the form of a table as follows:

Table A.4.2-9. DICOM Command Response Status Handling Behavior

Service Status

Further Meaning

Error Code

Behavior

e.g., Success

e.g., Matching is complete

e.g., 0000

e.g., The SCP has successfully returned all matching information.

Warning

Error

…..


The behavior of the AE during communication failure is summarized in a table as follows:

Table A.4.2-10. DICOM Command Communication Failure Behavior

Exception

Behavior

e.g., Timeout

e.g., The Association is aborted using A-ABORT and command marked as failed. The reason is logged and reported to the user.

e.g., Association aborted

e.g., The command is marked as failed. The reason is logged and reported to the user.


A.4.2.1.4 Association Acceptance Policy

Each AE Specification shall contain a description of the Association Acceptance policies of the AE. This describes the conditions under which the AE will accept an association.

A.4.2.1.4.1 "Activity <2>"
A.4.2.1.4.1.1 Description and Sequencing of Activities

A.4.2.1.4.1.2 Accepted Presentation Contexts

Table A.4.2-11. Acceptable Presentation Contexts For"Application Entity <1>" and "Activity <2>"

Presentation Context Table

Abstract Syntax

Transfer Syntax

Role

Extended Negotiation

Name

UID

Name

UID

name_a

AS_UID_a

XS_Name_a

XS_UID_a

SCP | SCU | Both

None |See Note <1>| See Table A.4.2-12

...

...

...

...

...

...


Note

<1>: <Describe the content of any extended negotiation done for the SOP Classes of this Presentation Context. In particular, acceptance of specialized SOP Classes of the Abstract Syntax specified in this Presentation Context shall be noted. One note may serve multiple Presentation Contexts, as a single Abstract Syntax often corresponds to a single SOP class, which may appear in different Presentation Contexts>

In Table A.4.2-11, the following meanings are assigned to the fields:

<name_a> This is the name of the Abstract Syntax to be used with this Presentation Context.

<AS_UID_a> This is the UID of the Abstract Syntax to be used for this Presentation Context.

<XS_Name_a> This is the name of a Transfer Syntax that may be used for this Presentation Context.

<XS_UID_a> The UID of the corresponding transfer syntax.

If the AE through this Real World Activity supports all SOP Classes of a particular Service Class (e.g., the Storage Service Class) through SOP Class Common Extended Negotiation, the Abstract Syntax Name and UID shall be those of the Service Class, and this shall be noted under Extended Negotiation.

In the event that the Abstract Syntax of the Presentation Context represents a Meta-SOP Class (that is, it includes many SOP Classes) and extended negotiation is supported for some of these SOP Classes, the following table is required to define this extended negotiation. This table is referenced in Table A.4.2-11

Table A.4.2-12. Extended Negotiation as a SCP

SOP Class name

SOP Class UID

Extended Negotiation

Name_i

SOP_UID_I

None | See Note <1>

...

...

...


Note

<1>: <Describe the content of any extended negotiation done for this SOP Class. One note may serve multiple Presentation Contexts, as a SOP class, which may appear in different Presentation Contexts, and/or Meta SOP Classes>

Any rules that govern the acceptance of presentation contexts for this AE shall be stated here as well. This includes rules for which combinations of Abstract/Transfer Syntaxes are acceptable, and rules for prioritization of presentation contexts. Rules that govern selection of transfer syntax within a presentation context shall be stated here.

A.4.2.1.4.1.3 SOP Specific Conformance for SOP Class(Es)

This section includes the SOP specific behavior, i.e., error codes, error and exception handling, time-outs, etc. The information shall be as described in the SOP specific Conformance Statement section of PS3.4 (or relevant private SOP definition).

The behavior of an Application Entity shall be summarized as shown in Table 4.2-13. Standard as well as the manufacturer specific status codes and their corresponding behavior shall be specified.

Table 4.2-13. Storage C-STORE Response Status

Service Status

Further Meaning

Error Code

Reason

Success

Success

0000

Explain

Refused

Out of Resources

A700-A7FF

Explain

Error

Data Set does not match SOP Class

A900-A9FF

Explain

Error

Specify

Specify

Explain

Warning

Specify

Specify

Explain


A.4.2.2 "Application Entity <1>"

An Application Entity that supports Web services shall have the following sections:

Details of this specific Application Entity shall be specified under this section.

A.4.2.2.1 Retired

See PS3.2-2017b.

A.4.2.2.2 WADO-URI Specifications

All WADO-URI services that are supported shall be listed. Other WADO-URI services that are not supported may be indicated.

For each supported service, the parameters and restrictions on those parameters shall be described.

Any connection policies such as restrictions on the number of connections, support for pipeline requests, etc. shall be described.

A.4.2.2.3 Restful Services Specifications

All RESTful services that are supported shall be listed. Other RESTful services that are not supported may be indicated.

For each supported service, the parameters and restrictions on those parameters shall be described.

Any connection policies such as restrictions on the number of connections, support for pipeline requests, etc. shall be described.

A.4.2.3 "Application Entity <2>"

The same info shall be repeated for each additional AE.

A.4.3 Network Interfaces

A.4.3.1 Physical Network Interface

If applicable, specifies what physical network interface(s) are supported.

A.4.3.2 Additional Protocols

Additional protocols such as used for configuration management are listed here. Any conformance to specific System Management Profiles defined in PS3.15 shall be listed per the following table.

Table A.4.3-1. System Management Profiles Table

Profile Name

Actor

Protocols Used

Optional Transactions

Security Support

Profile (1)

P Client

Protocol_1, Protocol_2

N/A

Profile (x)

X Client

Protocol_2, Protocol_3

Protocol_3 Option_A supported


If the implementation conforms to the Basic Network Address Management Profile as a DHCP Client actor (see PS3.15), the use of DHCP to configure the local IP address and hostname shall be described.

Note

The hostname is an alias for the IP address, and has no semantic relationship to AE titles. It is solely a convenience for configuration description.

If the implementation conforms to the Basic Network Address Management Profile as a DNS Client actor (see PS3.15), the use of DNS to obtain IP addresses from hostname information shall be described.

If the implementation conforms to the Basic Time Synchronization profile as an NTP Client or SNTP Client, the available NTP configuration alternatives shall be described. If the implementation conforms to the Basic Time Synchronization Profile as an NTP Server, the available server configuration alternatives shall be described. Any device specific requirements for accuracy or maximum allowable synchronization error shall be described.

If there is support for WADO (see PS3.18) the options supported and any restrictions shall be described.

A.4.3.3 IPv4 and IPv6 Support

The support for specific IPv4 and IPv6 features and associated optional IPv6 security and configuration facilities shall be documented.

A.4.4 Configuration

Any implementation's DICOM conformance may be dependent upon configuration, which takes place at the time of installation. Issues concerning configuration shall be addressed in this section.

A.4.4.1 AE Title/Presentation Address Mapping

An important installation issue is the translation from AE title to Presentation Address. How this is to be performed shall be described in this section.

Note

There does not necessarily have to be a one to one relationship between AE titles and Application Entities. If so, this should be made clear in the tables.

A.4.4.1.1 Local AE Titles.

The local AE title mapping and configuration shall be specified. The following table shall be used:

Table A.4.4-1. AE Title Configuration Table

Application Entity

Default AE Title

Default TCP/IP Port

AE (1)

Name

Specify

AE (2)

Name

Specify

AE (x)


If the implementation conforms to the Application Configuration Management Profile as an LDAP Client actor (see PS3.15), any use of LDAP to configure the local AE titles shall be described. Any conformance to the Update LDAP Server option shall be specified, together with the values for all component object attributes in the update sent to the LDAP Server.

A.4.4.1.2 Remote AE Title/Presentation Address Mapping

Configuration of remote host names and port numbers shall be specified here.

A.4.4.1.2.1 Remote SCP 1

Configuration of the remote AET port number, host-names, IP addresses and capabilities shall be specified. If applicable, multiple remote SCPs can be specified.

If the implementation conforms to the Application Configuration Management Profile as an LDAP Client actor (see PS3.15), any use of LDAP to configure the remote device addresses and capabilities shall be described. The LDAP queries used to obtain remote device component object attributes shall be specified.

Note

In particular, use of LDAP to obtain the AE Title, TCP port, and IP address for specific system actors (e.g., an Image Archive, or a Performed Procedure Step Manager) should be detailed, as well as how the LDAP information for remote devices is selected for operational use.

A.4.4.1.2.2 Remote SCP 2

Etc.

A.4.4.2 Parameters

The specification of important operational parameters, and if configurable, their default value and range, shall be specified here. The parameters that apply to all Application Entities should be specified in a "General Parameters" section while those specific to particular Application Entities should be specified in separate sections specific to each AE. The following table, which is shown here with a recommended baseline of parameters, shall be used:

Table A.4.4-2. Configuration Parameters Table

Parameter

Configurable (Yes/No)

Default Value

General Parameters

Time-out waiting for acceptance or rejection Response to an Association Open Request. (Application Level timeout)

General DIMSE level time-out values

Time-out waiting for response to TCP/IP connect request. (Low-level timeout)

Time-out waiting for acceptance of a TCP/IP message over the network. (Low-level timeout)

Time-out for waiting for data between TCP/IP packets. (Low-level timeout)

Any changes to default TCP/IP settings, such as configurable stack parameters.

Definition of arbitrarily chosen origins

Definition of constant values used in Dose Related Distance Measurements

Other configurable parameters

AE Specific Parameters

Size constraint in maximum object size (see note)

Maximum PDU size the AE can receive

Maximum PDU size the AE can send

AE specific DIMSE level time-out values

Number of simultaneous Associations by Service and/or SOP Class

<SOP Class support> (e.g., Multi-frame vs. single frame vs. SC support), when configurable

<Transfer Syntax support>, e.g., JPEG, Explicit VR, when configurable

Other parameters that are configurable


Note

In particular when accommodating Multi-frame objects (e.g., Ultrasound Multi-frame, NM, XA, RF), a receiver might have a certain restriction with regard to its maximum length. This restriction should be specified here.

Additional configuration parameters such as hardware options for e.g., a printer shall be specified as well.

A.5 Media Interchange

A.5.1 Implementation Model

The Implementation Model shall identify the DICOM Application Entities in a specific implementation and relate the Application Entities to Real-World Activities.

A.5.1.1 Application Data Flow Diagram

As part of the Implementation Model, an Application Data Flow Diagram shall be included. This diagram represents all of the Application Entities present in an implementation and graphically depicts the relationship of the AEs use of DICOM to real world activities. Figure A.5.1-1 is a template for such a Data Flow Diagram. Accompanying the Application Data Flow Diagram shall be a discussion of the Application Data Flow represented.

In this illustration, according to Figure A.5.1-1, an occurrence of local Real-World Activity A or B will cause the local Application Entity 1 to initiate either creation of a File-set on a medium (FSC) for the purpose of interchange with a remote Real-World Activity X or to access a File-set on a medium for reading (FSR). The remote Real-World Activity X accesses the medium physically transferred from Real-World Activity A or B.

An occurrence of Real-World Activity C will cause the local Application Entity 2 to update a File-set (FSU) on a mounted medium.

Application Data Flow Diagram

Figure A.5.1-1. Application Data Flow Diagram


Note

If the AE expects a remote Real-World Activity to access the media for a specific purpose, this should be shown in the Application Data Flow Diagram as well as described in Section Section A.5.1.1.

A.5.1.2 Functional Definitions of AEs

The next part of the Conformance Statement shall contain a functional definition for each local Application Entity. This shall describe in general terms the functions to be performed by the AE, and the DICOM services used to accomplish these functions. In this sense "DICOM services" refers not only to DICOM Service Classes, but also to lower level DICOM services, such as the Media File System and mapping to particular Media Formats.

A.5.1.3 Sequencing of Real World Activities

If applicable, this section shall contain a description of sequencing of Real World Activities that the AEs require.

Note

An example of a situation in which a such a description is required is an AE that supports roles as a File-set Updater and File-set Reader. In some instances, the File-set will be updated then read (e.g., for verification); and in other instances, may be read first to determine if the File-set needs to be updated.

A.5.1.4 File Meta Information for Implementation Class and Version

This section shall be used to list the values assigned to the File Meta Information attributes (see PS3.10) that pertain to the Implementation Class and Version. These are:

  • File Meta Information Version

  • Implementation Class UID

  • Implementation Version Name

A.5.2 AE Specifications

The next section in the DICOM Conformance Statement is a set of Application Entity Specifications. There shall be one such specification for each Application Entity type.

A.5.2.1 "Application Entity <1>" - Specification

The following table, Table A.5.2-1, shows that for one or more Application Profiles in the first column, there are a number of Real-World Activities in the second column and the roles required for each of these Real-World Activities in the third column

Table A.5.2-1. AE Related Application Profiles, Real-World Activities, and Roles

Supported Application Profile

Real-World Activity

Roles

STD-AP1

RWA A

FSR

RWA B

FSR, FSC

STD-AP1, AUG-AP2, etc.

RWA C

FSU

RWA D

FSC


This section shall also contain any general policies that apply to all of the AEs described in subsequent section.

A.5.2.1.1 File Meta Information for the "Application Entity <1>"

This section shall contain the values of the File Meta Information that pertain to the Application Entity (see PS3.10). These are:

  • Source Application Entity Title

If Private Information is used in the Application Profile File Meta Information, the following two File Meta Information attributes may be documented:

  • Private Information Creator UID

  • Private Information

A.5.2.1.2 Real-World Activities

The first sentence in this section shall state the Roles and Media Storage Service Class Options supported by the "Application Entity <1>".

A.5.2.1.2.i "Real-World Activity <i>"

The AE Specification shall contain a description of the Real-World Activities, which invoke the particular AE. There will be one section, A.5.2.1.2.i where i increments for each RWA, per Real-World Activity.

A.5.2.1.2.i.1 Media Storage Application Profile

The Application Profile that is used by the AE described in A.5.2-1 is specified in this section.

A.5.2.1.2.i.1.y Options

The options used in the Application Profiled specified in Table A.5.2-1 shall be detailed in this section. There will be separate sections for each option specified for the AP. If there are no options used in the Application Profile specified in A.5.2.x, this section may be omitted.

A.5.2.2 "Application Entity <2>" - Specification

Each individual AE Specification has a subsection, A.5.2.x. There are as many of these subsections as there are different AEs in the implementation. That is, if there are two distinct AEs, then there will be two subsections, A.5.2.1, and A.5.2.2.

A.5.3 Augmented and Private Application Profiles

This Section shall be used for the description of Augmented and Private Application Profiles.

A.5.3.1 Augmented Application Profiles

Any Augmented Application Profiles used by an AE shall be described in these sections. The rules governing the structure of an Augmented AP shall be described.

A.5.3.1.1 "Augmented Application Profile <1>"

Each Augmented Application Profile shall have a section A.5.3.1.x that describes the specific features of the Application Profile that make it Augmented. These shall be described in the three repeating sections that follow.

A.5.3.1.1.1 SOP Class Augmentations

The additional SOP Classes beyond those specified in the Standard AP on which this Augmented AP is based shall be detailed in this section.

A.5.3.1.1.2 Directory Augmentations

Any additions to the Directory IOD that augment this AP shall be described in this section.

A.5.3.1.1.3 Other Augmentations

Any additions to, or extensions of the Application Profile shall be described in this section. An example of such another augmentation is addition of a role (FSR, FSC, FSU) to the Standard Application Profile set of defined roles.

A.5.3.1.2 "Augmented Application Profile <2>"

To be repeated for the second, third, etc. Augmented Application Profile.

A.5.3.2 Private Application Profiles

The rules that govern construction of a Private Application Profile shall be described. This section shall be used to describe the details of the Private AP.

Note

  1. Refer to PS3.11 for a description of constructing a Private Application Profile.

  2. If the AP deviates from the rules governing a Private AP in any manner, it is non-conformant and is outside the scope of this Standard.

A.5.4 Media Configuration

Any implementation's DICOM conformance may be dependent upon configuration that takes place at the time of installation. Issues concerning configuration shall be addressed in this section (e.g., the configuration of the Source AE Title in File Meta Information).

A.6 Transformation of DICOM to CDA

The supported SR objects and corresponding template identifiers shall be described. The release version and template identifier of the generated valid CDA documents shall be documented. The transformation process may be described by reference to a specific Annex of PS3.20.

A.7 Support of Character Sets

Any support for Character Sets beyond the Default Character Repertoire in Network and Media Services shall be described here.

  • The behavior when an unsupported character set is received shall be documented.

  • Character set configuration capabilities, if any, shall be specified.

  • Mapping and/or conversion of character sets across Services and Instances shall be specified.

  • Query capabilities for attributes that include non-default character sets, both for the Worklist service class and Query service class shall be specified. Behavior of attributes using extended character sets by a C-FIND, both as SCU and SCP request and response, shall be specified. In particular the handling of Person Names (VR of PN) shall be specified.

  • The presentation of the characters to a user, i.e., capabilities, font limitations and/or substitutions shall be specified.

A.8 Security

A.8.1 Security Profiles

Any support for Security Profiles as defined in PS3.15 shall be described here. Any extensions to Security Profiles shall be described, e.g., extended schema for audit trail messages.

An implementation shall declare which level of security features it supports, including such things as:

  1. The conditions under which the implementation preserves the integrity of Digital Signatures (e.g., is the implementation bit-preserving).

  2. The conditions under which the implementation verifies incoming Digital Signatures.

  3. The conditions under which the implementation replaces Digital Signatures.

  4. IPv6 Security capabilities

A.8.2 Association Level Security

Any support for security at the Association level (e.g., allowing only certain AE-titles and/or IP addresses to open an Association) shall be specified here.

A.8.3 Application Level Security

Any support for additional application level security as it applies to the DICOM communication (e.g., passwords, biometrics) can be described here.

A.9 Annexes

A.9.1 IOD Contents

A.9.1.1 Created SOP Instance(s)

This section specifies each IOD created (including Private IODs). It should specify the Attribute Name, tag, VR, and Value. The Value should specify the range and source (e.g., User input, Modality Worklist, automatically generated, etc.). For content items in templates, the range and source of the concept name and concept values should be specified. Whether the value is always present or not shall be specified.

Recommended abbreviations to be used for the tables are:

VNAP Value Not Always Present (attribute sent zero length if no value is present)

ANAP Attribute Not Always Present

ALWAYS Always Present with a value

EMPTY Attribute is sent without a value

Recommended abbreviations to be used for the source of the data values in the tables are:

USER the attribute value source is from User input

AUTO the attribute value is generated automatically

MWL,MPPS, etc. the attribute value is the same as the value received using a DICOM service such as Modality Worklist, Modality Performed Procedure Step, etc.

CONFIG the attribute value source is a configurable parameter

Specification of a company web address can refer to sample SOP Instances that are available.

Private attributes should be specified.

A.9.1.2 Usage of Attributes From Received IODs

Each Application that depends on certain fields to function correctly should specify which ones are required for it to perform its intended function.

A.9.1.3 Attribute Mapping

When attributes are used by different SOP Classes, e.g., Modality Worklist, Storage and Modality Performed Procedure Step, this mapping shall be specified. For devices that specify other external protocols, such as HL7, mapping of their fields into the DICOM attributes is not required but highly recommended.

A.9.1.4 Coerced/Modified Fields

A SCU might coerce certain Attributes, e.g., the Patient Name. A SCP might provide a different value of an Attribute than was received. These changes shall be specified here. An example is Patient Name, which could be modified using available information from either an internal database or obtained from an Information System/Information Manager. Another example is the generation of a new SOP Instance UID for an existing instance. The conditions influencing such coercion should be specified..

A.9.2 Data Dictionary of Private Attributes

Any private Attributes should be specified, including their VR, VM and which are known to be safe from identity leakage. Private SOP Classes and Transfer syntaxes should be listed. Whether or not private Attributes are described in Private Data Element Characteristics Sequence (0008,0300) should be specified in Section A.9.1 IOD Contents.

A.9.3 Coded Terminology and Templates

Support for Coded Terminology and templates shall be described here.

A.9.3.1 Context Groups

Each Context Group (i.e., use of coded terminology in a specific context) shall be specified here with its default value set, and whether the value set is configurable. The configurable options are specified.

Table A.9.3-1. Context Groups

Context Group

Default Value Set

Configurable

Use

Logical Context Identification

CID xxx | extended CID xxx | Private CID yyyy | None

No| Extensible|Replaceable

Description of method of selection of a term from the Context Group, and identification of the IOD, Attribute, and/or Content Item that uses the term

e.g., Acquisition Protocol Equipment Settings

e.g., None

e.g., Replaceable

e.g., Value of Scheduled Protocol Code Sequence (0040,0008) from selected Modality Worklist Scheduled Procedure Step is matched to this group for protocol-assisted equipment set-up.

Selected value from this group is used in Modality Performed Procedure Step Performed Protocol Code Sequence (0040,0260)

e.g., Patient Orientation

e.g., CID 19 “Patient Orientation”

e.g., No

e.g., Mapped from user console selection of Patient Orientation. Used in Patient Orientation Code Sequence (0054,0410)

...

...

...

...


The Default Value Set may be an extension of a standard context group ("extended CID xxx"). If used, a table shall be provided specifying the extended context group, the Context Group Local Version (0008,0107) value and the Context Group Creator UID (0008,010D).

This section describes the specification of any private context groups that are used. It shall follow the format for context groups specified in PS3.16.

A.9.3.2 Template Specifications

This section specifies any extensions to standard templates and/or any private templates that are used, and defines them. Definitions shall follow the format for templates specified in PS3.16

A.9.3.3 Private Code Definitions

This section specifies any private codes used and their definitions.

A.9.4 Grayscale Image Consistency

Any support for the DICOM Grayscale Standard Display Function will be specified in this section.

A.9.5 Standard Extended/Specialized/Private SOP Classes

This section describes Standard Extended SOP Class, Specialized SOP Class, or Private SOP Class that are used.

A.9.5.1 Standard Extended/Specialized/Private SOP <i>

This section describes a particular Standard Extended SOP Class, Specialized SOP Class, or Private SOP Class.

A.9.6 Private Transfer Syntaxes

This section describes any private Transfer Syntaxes that are listed in the Transfer Syntax Tables.

A.9.6.1 Private Transfer Syntax <i>

This section describes particular private transfer syntax. It shall follow the guidelines specified in PS3.5.

B Conformance Statement Sample Integrated Modality (Informative)

Disclaimer:

This document is an example DICOM Conformance Statement for a fictional image acquisition modality called EXAMPLE-INTEGRATED-MODALITY produced by a fictional vendor called EXAMPLE-IMAGING-PRODUCTS.

As stated in the annex title, this document is truly informative, and not normative. A conformance statement of an actual product might implement additional services and options as appropriate for its specific purpose. In addition, an actual product might implement the services described in a different manner and, for example, with different characteristics and/or sequencing of activities. In other words, this conformance statement example does not intend to standardize a particular manner that a product might implement DICOM functionality.

B.0 Cover Page

Company Name: EXAMPLE-IMAGING-PRODUCTS.

Product Name: SAMPLE INTEGRATED MODALITY

Version: 1.0-rev. A.1

Internal document number: 4226-xxx-yyy-zzz rev 1

Date: YYYYMMDD

B.1 Conformance Statement Overview

This fictional product EXAMPLE-INTEGRATED-MODALITY implements the necessary DICOM services to download work lists from an information system, save acquired RF images and associated Presentation States to a network storage device or CD-R, print to a networked hardcopy device and inform the information system about the work actually done.

Table B.1-1 provides an overview of the network services supported by EXAMPLE-INTEGRATED-MODALITY.

Table B.1-1. Network Services

SOP Classes

User of Service (SCU)

Provider of Service (SCP)

Transfer

X-Ray Radiofluoroscopic Image Storage

Yes

No

Grayscale Softcopy Presentation State

Yes

No

Workflow Management

Modality Worklist

Yes

No

Storage Commitment Push Model

Yes

No

Modality Performed Procedure Step

Yes

No

Print Management

Basic Grayscale Print Management

Option (see Note 1)

No

Presentation LUT

Option (see Note 1)

No


Note

  1. Support for the Print Services is a separately licensable option. Details about licensable options can be found under:http://www.example-imaging-products.nocom/example­integrated-modality/licence-options

Table B.1-2 provides an overview of the Media Storage Application Profiles supported by Example-Integrated-Modality.

Table B.1-2. Media Services

Media Storage Application Profile

Write Files (FSC or FSU)

Read Files (FSR)

Compact Disk - Recordable

General Purpose CD-R

Yes

No


B.2 Table of Contents

A table of contents shall be provided to assist readers in easily finding the needed information.

B.3 Introduction

B.3.1 Revision History

Table B.3.1. Revision History

Document Version

Date of Issue

Author

Description

1.1

October 30, 2003

WG 6

Version for Final Text

1.2

August 30, 2007

WG 6

Revised Introduction


B.3.2 Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References

See example text in Section A.3.

B.3.3 Additional Remarks for This Example

This document is a sample DICOM Conformance Statement created for DICOM PS3.2. It is to be used solely as an example to illustrate how to create a DICOM Conformance Statement for an acquisition modality. The subject of the document, EXAMPLE-INTEGRATED-MODALITY, is a fictional product.

B.4 Networking

B.4.1 Implementation Model

B.4.1.1 Application Data Flow

Application Data Flow Diagram

Figure B.4.1-1. Application Data Flow Diagram


  • The Storage Application Entity sends images and Presentation States to a remote AE. It is associated with the local real-world activity "Send Images & GSPS". "Send Images & GSPS" is performed upon user request for each study completed or for specific images selected. When activated by user's settings (auto-send), each marked set of images and associated Presentation States can be immediately stored to a preferred destination whenever a Patient/Study is closed by the user. If the remote AE is configured as an archive device the Storage AE will request Storage Commitment and if a commitment is successfully obtained will record this information in the local database.

  • The Workflow Application Entity receives Worklist information from and sends MPPS information to a remote AE. It is associated with the local real-world activities "Update Worklist" and "Acquire Images". When the "Update Worklist" local real-world activity is performed the Workflow Application Entity queries a remote AE for worklist items and provides the set of worklist items matching the query request. "Update Worklist" is performed as a result of an operator request or can be performed automatically at specific time intervals. When the "Acquire Images" local real-world activity is performed the Workflow Application Entity creates and updates Modality Performed Procedure Step instances managed by a remote AE. Acquisition of images will result in automated creation of an MPPS Instance. Completion of the MPPS is performed as the result of an operator action.

  • The Hardcopy Application Entity prints images on a remote AE (Printer). It is associated with the local real-world activity "Film Images". "Film Images" creates a print-job within the print queue containing one or more virtual film sheets composed from images selected by the user.

B.4.1.2 Functional Definition of AEs

B.4.1.2.1 Functional Definition of Storage Application Entity

The existence of a send-job queue entry with associated network destination will activate the Storage AE. An association request is sent to the destination AE and upon successful negotiation of a Presentation Context the image transfer is started. If the association cannot be opened, the related send-job is set to an error state and can be restarted by the user via job control interface. By default, the Storage AE will not try to initiate another association for this send-job automatically. However, an automatic retry (retry-timer, retry­count) can be configured by a CSE.

B.4.1.2.2 Functional Definition of Workflow Application Entity

Worklist Update attempts to download a Worklist from a remote node. If the Workflow AE establishes an Association to a remote AE, it will transfer all worklist items via the open Association. During receiving the worklist response items are counted and the query processing is canceled if the configurable limit of items is reached. The results will be displayed in a separate list, which will be cleared with the next Worklist Update.

The Workflow AE performs the creation of a MPPS Instance automatically whenever images are acquired. Further updates on the MPPS data can be performed interactively from the related MPPS user interface. The MPPS "Complete" or "Discontinued" states can only be set from the user interface.

B.4.1.2.3 Functional Definition of Hardcopy Application Entity

The existence of a print-job in the print queue will activate the Hardcopy AE. An association is established with the printer and the printer's status determined. If the printer is operating normally, the film sheets described within the print-job will be printed. Changes in printer status will be detected (e.g., out of film) and reported to the user. If the printer is not operating normally, the print-job will set to an error state and can be restarted by the user via the job control interface.

B.4.1.3 Sequencing of Real-World Activities

Sequencing Constraints

Figure B.4.1-2. Sequencing Constraints


Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure B.4.1-2 apply:

  1. Query Worklist

  2. Receive Worklist of Modality Scheduled Procedure Steps (MSPS)

  3. Select Workitem (MSPS) from Worklist

  4. Start acquisition and create MPPS

  5. Acquire Images

  6. Complete acquisition and finalize MPPS

  7. Print acquired images (optional step)

  8. Store acquired images and any associated Grayscale Softcopy Presentation State (GSPS) instances.

  9. If the Image Manager is configured as an archive device the Storage AE will request Storage Commitment for the images and associated GSPS instances.

Other workflow situations (e.g., unscheduled procedure steps) will have other sequencing constraints. Printing could equally take place after the acquired images have been stored. Printing could be omitted completely if no printer is connected or hard copies are not required.

B.4.2 AE Specifications

B.4.2.1 Storage Application Entity Specification

B.4.2.1.1 SOP Classes

EXAMPLE-INTEGRATED-MODALITY provides Standard Conformance to the following SOP Classes:

Table B.4.2-1. SOP Classes for AE Storage

SOP Class Name

SOP Class UID

SCU

SCP

X-Ray Radiofluoroscopic Image Storage

1.2.840.10008.5.1.4.1.1.12.2

Yes

No

Grayscale Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.1

Yes

No

Storage Commitment Push Model

1.2.840.10008.1.20.1

Yes

No

Verification

1.2.840.10008.1.1

No

Yes


B.4.2.1.2 Association Policies
B.4.2.1.2.1 General

The DICOM standard application context name for DICOM 3.0 is always proposed:

Table B.4.2-2. DICOM Application Context for AE Storage

Application Context Name

1.2.840.10008.3.1.1.1


B.4.2.1.2.2 Number of Associations

EXAMPLE-INTEGRATED-MODALITY initiates one Association at a time for each destination to which a transfer request is being processed in the active job queue list. Only one job will be active at a time, the other remains pending until the active job is completed or failed.

Table B.4.2-3. Number of Associations Initiated for AE Storage

Maximum number of simultaneous Associations

1 (configurable)


EXAMPLE-INTEGRATED-MODALITY accepts Associations to receive N-EVENT-REPORT notifications for the Storage Commitment Push Model SOP Class.

Table B.4.2-4. Number of Associations Accepted for AE Storage

Maximum number of simultaneous Associations

5 (configurable)


B.4.2.1.2.3 Asynchronous Nature

EXAMPLE-INTEGRATED-MODALITY does not support asynchronous communication (multiple outstanding transactions over a single Association).

Table B.4.2-5. Asynchronous Nature as a SCU for AE Storage

Maximum number of outstanding asynchronous transactions

1


B.4.2.1.2.4 Implementation Identifying Information

The implementation information for this Application Entity is:

Table B.4.2-6. DICOM Implementation Class and Version for AE Storage

Implementation Class UID

1.xxxxxxx.yyy.etc.ad.inf.usw

Implementation Version Name

EXINTMOD_01


B.4.2.1.3 Association Initiation Policy
B.4.2.1.3.1 Activity - Send Images
B.4.2.1.3.1.1 Description and Sequencing of Activities

A user can select images and presentation states and request them to be sent to multiple destinations (up to 3). Each request is forwarded to the job queue and processed individually. When the "Auto-send" option is active, each marked instance or marked set of instances stored in database will be forwarded to the network job queue for a pre-configured auto-send target destination. Which instances will be automatically marked and the destination where the instances are automatically sent to can be configured. The "Auto-send" is triggered by the Close Patient user application.

The Storage AE is invoked by the job control interface that is responsible for processing network archival tasks. The job consists of data describing the instances marked for storage and the destination. An internal daemon process triggered by a job for a specific network destination initiates a C-STORE request to store images. If the process successfully establishes an Association to a remote Application Entity, it will transfer each marked instance one after another via the open Association. Status of the transfer is reported through the job control interface. Only one job will be active at a time. If the C-STORE Response from the remote Application contains a status other than Success or Warning, the Association is aborted and the related Job is switched to a failed state. It can be restarted any time by user interaction or, if configured, by automated retry.

The Storage AE attempts to initiate a new Association in order to issue a C-STORE request. If the job contains multiple images then multiple C-STORE requests will be issued over the same Association.

If the Remote AE is configured as an archive device the Storage AE will, after all images and presentation states have been sent, transmit a single Storage Commitment request (N-ACTION) over the same Association. Upon receiving the N-ACTION response the Storage AE will delay releasing the Association for a configurable amount of time. If no N-EVENT-REPORT is received within this time period the Association will be immediately released (i.e., notification of Storage Commitment success or failure will be received over a separate association). However, the Storage AE is capable of receiving an N-EVENT-REPORT request at any time during an association provided a Presentation Context for the Storage Commitment Push Model has been successfully negotiated (i.e., the N-ACTION is se