PS3.2

DICOM PS3.2 2023a - Conformance

DICOM Standards Committee

A DICOM® publication


Table of Contents

Notice and Disclaimer
Foreword
1. Scope and Field of Application
2. Normative References
Bibliography
3. Definitions
Glossary
4. Symbols and Abbreviations
5. Conventions
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 Implementation Model Section For Conformance Statements
6.2. Overview of Service and Interoperability Description Section For Conformance Statements
6.2.1. Mapping of Services to Application Entities
6.2.2. Supported DIMSE Services
6.2.3. Supported DICOM Web Services
6.2.4. Supported Media Storage Services Section For Conformance Statements
6.3. Overview of DICOM Configuration Section For Conformance Statements
6.4. Overview of Network and Media Communication Details Section For Conformance Statements
7. Conformance Requirements
7.1. DICOM Networking Conformance Requirements
7.1.1. DIMSE Protocol Conformance Requirements
7.1.2. DICOM Web Services 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
7.8. DICOM Real Time Video Conformance Requirements
A. DICOM Conformance Statement Template (Retired)
B. Conformance Statement Sample Integrated Modality (Retired)
C. Conformance Statement Sample DICOMRis Interface (Retired)
D. Conformance Statement Sample DICOM Image Viewer (Retired)
E. Conformance Statement Example Print Server (Retired)
F. DICOM Conformance Statement Query-Retrieve-Server (Retired)
G. Conformance Statement Sample ImageViewer with Hanging Protocol Support (Retired)
H. DICOM Conformance Statement Medication-System-Gateway (Retired)
I. Conformance Statement Sample WADO Service (Retired)
J. Conformance Statement Sample STOW Service (Retired)
K. Conformance Statement Sample QIDO-RS Provider (Retired)
L. Conformance Statement Sample DICOM-RTV Service Provider (Retired)
M. Conformance Statement Sample DICOM-RTV Service Consumer (Retired)
N. DICOM Conformance Statement Template (Normative)
N.0. Cover Page
N.1. Overview
N.1.1. Content and Transfer
N.1.1.1. Structured Reporting Root Template IDs
N.1.2. DIMSE Services
N.1.2.1. Verification
N.1.2.2. Storage
N.1.2.3. Workflow Management
N.1.2.4. Query/Retrieve
N.1.2.5. Printing
N.1.3. DICOM Web Services
N.1.3.1. URI Service (WADO-URI)
N.1.3.2. Studies Service
N.1.3.3. Worklist Service
N.1.3.4. Non-Patient Instance Service
N.1.4. Media Services
N.1.5. Real Time Video Service
N.1.6. De-identification Profiles
N.1.7. Specific Character Sets
N.2. Table of Contents
N.3. Introduction
N.3.1. Revision History
N.3.2. Audience
N.3.3. Remarks
N.3.4. Terms and Definitions
N.3.5. Abbreviations
N.3.6. References
N.4. Implementation Model
N.4.1. Application Entities and Data Flow
N.4.1.1. Functional Definition of <Application Entity 1>
N.5. Service and Interoperability Description
N.5.1. Mapping of Services to Application Entities
N.5.2. Supported DIMSE Services
N.5.2.1. Basic Worklist Management Service
N.5.2.1.1. SCU of the Modality Worklist Information Model - FIND SOP Class
N.5.2.1.2. SCP of the Modality Worklist Information Model - FIND SOP Class
N.5.2.2. Modality Performed Procedure Step Service
N.5.2.2.1. SCU of the Modality Performed Procedure Step SOP Class
N.5.2.2.2. SCP of the Modality Performed Procedure Step SOP Class
N.5.2.3. Unified Worklist and Procedure Step Service
N.5.2.4. Instance Availability Notification Service
N.5.2.4.1. SCU of the Instance Availability Notification SOP Class
N.5.2.4.2. SCP of the Instance Availability Notification SOP Class
N.5.2.5. Storage Service
N.5.2.5.1. SCU of the Storage SOP Classes
N.5.2.5.1.1. Transcoding of Transfer Syntaxes
N.5.2.5.2. SCP of the Storage SOP Classes
N.5.2.6. Storage Commitment Service
N.5.2.6.1. SCU of the Storage Commitment SOP Class
N.5.2.6.2. SCP of the Storage Commitment SOP Class
N.5.2.7. Query/Retrieve Service Class
N.5.2.7.1. SCU of the Study Root Q/R Information Model - FIND SOP Class
N.5.2.7.2. SCU of the Patient Root Q/R Information Model - FIND SOP Class
N.5.2.7.3. SCU of the Study Root Q/R Information Model - MOVE SOP Class
N.5.2.7.4. SCU of the Patient Root Q/R Information Model - MOVE SOP Class
N.5.2.7.5. SCP of the Study Root Q/R Information Model - FIND SOP Class
N.5.2.7.6. SCP of the Patient Root Q/R Information Model - FIND SOP Class
N.5.2.7.7. SCP of the Study Root Q/R Information Model - MOVE SOP Class
N.5.2.7.8. SCP of the Patient Root Q/R - Information Model - MOVE SOP Class
N.5.2.8. Print Management Service
N.5.2.8.1. SCU of the Basic Grayscale Print Management Meta SOP Class
N.5.2.8.1.1. Basic Film Session SOP Class
N.5.2.8.1.2. Basic Film Box SOP Class
N.5.2.8.1.3. Basic Grayscale Image Box SOP Class
N.5.2.8.1.4. Printer SOP Class
N.5.2.8.2. SCU of the Basic Color Print Management Meta SOP Class
N.5.2.8.2.1. Basic Film Session SOP Class
N.5.2.8.2.2. Basic Film Box SOP Class
N.5.2.8.2.3. Basic Color Image Box SOP Class
N.5.2.8.2.4. Printer SOP Class
N.5.2.8.3. SCU of the Basic Annotation Box SOP Class
N.5.2.8.4. SCU of the Print Job SOP Class
N.5.2.8.5. SCU of the Presentation LUT SOP Class
N.5.2.8.6. SCU of the Printer Configuration Retrieval SOP Class
N.5.2.8.7. SCP of the Basic Grayscale Print Management Meta SOP Class
N.5.2.8.7.1. Basic Film Session SOP Class
N.5.2.8.7.2. Basic Film Box SOP Class
N.5.2.8.7.3. Basic Grayscale Image Box SOP Class
N.5.2.8.7.4. Printer SOP Class
N.5.2.8.8. SCP of the Basic Color Print Management Meta SOP Class
N.5.2.8.8.1. Basic Film Session SOP Class
N.5.2.8.8.2. Basic Film Box SOP Class
N.5.2.8.8.3. Basic Color Image Box SOP Class
N.5.2.8.8.4. Printer SOP Class
N.5.2.8.9. SCP of the Basic Annotation Box SOP Class
N.5.2.8.10. SCP of the Print Job SOP Class
N.5.2.8.11. SCP of the Presentation LUT SOP Class
N.5.2.8.12. SCP of the Printer Configuration Retrieval SOP Class
N.5.3. Supported DICOM Web Services
N.5.3.1. URI Web Service (WADO URI)
N.5.3.1.1. Supported Web Media Types
N.5.3.1.1.1. DICOM Media Types
N.5.3.1.1.2. Rendered Media Types
N.5.3.1.2. Retrieve DICOM Instance Transaction - URI Web Service
N.5.3.1.2.1. User Agent
N.5.3.1.2.2. Origin Server
N.5.3.1.3. Retrieve Rendered Instance Transaction - URI Web Service
N.5.3.1.3.1. User Agent
N.5.3.1.3.2. Origin Server
N.5.3.2. Studies Web Service
N.5.3.2.1. Supported Web Media Types
N.5.3.2.1.1. DICOM Media Types
N.5.3.2.1.2. DICOM Bulkdata Media Type
N.5.3.2.1.3. Supported Rendered Media Types
N.5.3.2.2. Retrieve supported transaction (WADO-RS)
N.5.3.2.2.1. User Agent
N.5.3.2.2.2. Origin Server
N.5.3.2.3. Store Transaction (STOW-RS)
N.5.3.2.3.1. User Agent
N.5.3.2.3.2. Origin Server
N.5.3.2.4. Search Transaction (QIDO-RS)
N.5.3.2.4.1. User Agent
N.5.3.2.4.2. Origin Server
N.5.3.3. Worklist Web Service
N.5.3.3.1. Create Transaction Worklist Web Service
N.5.3.3.1.1. User Agent
N.5.3.3.1.2. Origin Server
N.5.3.3.2. Retrieve Transaction Worklist Web Service
N.5.3.3.2.1. User Agent
N.5.3.3.2.2. Origin Server
N.5.3.3.3. Update Transaction Worklist Web Service
N.5.3.3.3.1. User Agent
N.5.3.3.3.2. Origin Server
N.5.3.3.4. Change State Transaction Worklist Web Service
N.5.3.3.4.1. User Agent
N.5.3.3.4.2. Origin Server
N.5.3.3.5. Request Cancellation Transaction Worklist Web Service
N.5.3.3.5.1. User Agent
N.5.3.3.5.2. Origin Server
N.5.3.3.6. Search Transaction Worklist Web Service
N.5.3.3.6.1. User Agent
N.5.3.3.6.2. Origin Server
N.5.3.3.7. Subscribe Transaction Worklist Web Service
N.5.3.3.7.1. User Agent
N.5.3.3.7.2. Origin Server
N.5.3.3.8. Unsubscribe Transaction Worklist Web Service
N.5.3.3.8.1. User Agent
N.5.3.3.8.2. Origin Server
N.5.3.3.9. Suspend Global Subscription Transaction Worklist Web Service
N.5.3.3.9.1. User Agent
N.5.3.3.9.2. Origin Server
N.5.3.4. Non-Patient Instance Web Service
N.5.3.4.1. Supported Web Media Types
N.5.3.4.2. Retrieve Transaction
N.5.3.4.2.1. User Agent
N.5.3.4.2.2. Origin Server
N.5.3.4.3. Store Transaction
N.5.3.4.3.1. User Agent
N.5.3.4.3.2. Origin Server
N.5.3.4.4. Search Transaction
N.5.3.4.4.1. User Agent
N.5.3.4.4.2. Origin Server
N.5.3.5. Notification Web Service
N.5.4. Media Service
N.5.4.1. File Set Creator (FSC)
N.5.4.2. File Set Reader (FSR)
N.5.4.3. File Set Updater (FSU)
N.5.5. Real Time Video Service
N.5.5.1. Service Consumer
N.5.5.2. Service Provider
N.5.6. Cross Service Considerations
N.5.7. Specific Character Sets
N.6. Configuration
N.6.1. General Configuration Parameters
N.6.2. Configuration of DIMSE Services
N.6.2.1. Basic Worklist Management Service Configuration
N.6.2.2. Modality Performed Procedure Step Service Configuration
N.6.2.3. Unified Worklist and Procedure Step Service Configuration
N.6.2.4. Instance Availability Notification Service Configuration
N.6.2.5. Storage Service Configuration
N.6.2.6. Storage Commitment Service Configuration
N.6.2.7. Query/Retrieve Service Configuration
N.6.2.8. Print Management Service Configuration
N.6.3. Configuration of DICOM Web Services
N.6.3.1. URI Web Service Configuration
N.6.3.2. Studies Web Service Configuration
N.6.3.2.1. Retrieve Transaction (WADO-RS) Configuration
N.6.3.2.2. Store Transaction (STOW-RS) Configuration
N.6.3.2.3. Search Transaction (QIDO-RS) Configuration
N.6.3.3. Worklist Web Service Configuration
N.6.3.4. Non-Patient Instances (NPI) Web Service Configuration
N.6.4. Configuration of Media Storage Service
N.6.5. Configuration of Real Time Video Service
N.6.6. Configuration of Audit Trail - Syslog
N.7. Network and Media Communication Details
N.7.1. General
N.7.1.1. General Association Parameters
N.7.2. Specifications
N.7.2.1. <AE1> Application Entity
N.7.2.1.1. Sequencing of Real-World Activities for <AE1>
N.7.2.1.2. Association Parameters of <AE1>
N.7.2.1.3. Association Initiation
N.7.2.1.3.1. Real-World Activity <Activity 1>
N.7.2.1.4. Association Acceptance
N.7.2.1.4.1. Real-World Activity <Activity 2>
N.7.3. Status Codes
N.7.3.1. General AE Communication and Failure Behavior and Handling
N.7.3.1.1. Communication Failure Behavior as Association Initiator
N.7.3.1.2. Communication Failure Handling as Association Acceptor
N.7.3.2. DIMSE Services
N.7.3.2.1. Basic Worklist Management Service
N.7.3.2.1.1. SCU of the Modality Worklist Information Model Find SOP Class - C-FIND
N.7.3.2.1.2. SCP of the Modality Worklist Information Model Find SOP Class - C-FIND
N.7.3.2.2. Modality Performed Procedure Step Service
N.7.3.2.2.1. SCU of the Modality Performed Procedure Step SOP Class - N-CREATE
N.7.3.2.2.2. SCU of the Modality Performed Procedure Step SOP Class - N-SET
N.7.3.2.2.3. SCP of the Modality Performed Procedure Step SOP Class - N-CREATE
N.7.3.2.2.4. SCP of the Modality Performed Procedure Step SOP Class - N-SET
N.7.3.2.3. Unified Worklist und Procedure Step Service
N.7.3.2.3.1. SCU of the UPS Push SOP Class
N.7.3.2.3.1.1. SCU of the UPS Push SOP Class - N-CREATE
N.7.3.2.3.1.2. SCU of the UPS Push SOP Class Request UPS Cancel - N-ACTION
N.7.3.2.3.1.3. SCU of the UPS Push SOP Class - N-GET
N.7.3.2.3.2. SCU of the UPS Pull SOP Class
N.7.3.2.3.2.1. SCU of the UPS Pull SOP Class - C-FIND
N.7.3.2.3.2.2. SCU of the UPS Pull SOP Class - N-GET
N.7.3.2.3.2.3. SCU of the UPS Pull SOP Class - N-SET
N.7.3.2.3.2.4. SCU of the Change UPS State of UPS Pull SOP Class - N-ACTION
N.7.3.2.3.3. SCU of the UPS Watch SOP Class
N.7.3.2.3.3.1. SCU of the Un/Subscribe on UPS Watch SOP Class - N-ACTION
N.7.3.2.3.3.2. SCU of the UPS Watch SOP Class - N-GET
N.7.3.2.3.3.3. SCU of the UPS Watch SOP Class - C-FIND
N.7.3.2.3.3.4. SCU of the Request UPS Cancellation on UPS Watch SOP Class - N-ACTION
N.7.3.2.3.4. SCU of the UPS Event SOP Class
N.7.3.2.3.4.1. SCU of the UPS Event SOP Class - N-EVENT-REPORT
N.7.3.2.3.5. SCP of the UPS Push SOP Class
N.7.3.2.3.5.1. SCP of the UPS Push SOP Class - N-CREATE
N.7.3.2.3.5.2. SCP of Request UPS Cancel on UPS Push SOP Class - N-ACTION
N.7.3.2.3.5.3. SCP of the UPS Push SOP Class - N-GET
N.7.3.2.3.6. SCP of the UPS Pull SOP Class
N.7.3.2.3.6.1. SCP of the UPS Pull SOP Class - C-FIND
N.7.3.2.3.6.2. SCP of the UPS Pull SOP Class - N-GET
N.7.3.2.3.6.3. SCP of the UPS Pull SOP Class - N-SET
N.7.3.2.3.6.4. SCP of the Change UPS State of UPS Pull SOP Class - N-ACTION
N.7.3.2.3.7. SCP of the UPS Watch SOP Class
N.7.3.2.3.7.1. SCP of the Un/Subscribe on UPS Watch SOP Class - N-ACTION
N.7.3.2.3.7.2. SCP of the UPS Watch SOP Class - N-GET
N.7.3.2.3.7.3. SCP of the UPS Watch SOP Class - C-FIND
N.7.3.2.3.7.4. SCP of the Request UPS Cancellation on UPS Watch SOP Class - N-ACTION
N.7.3.2.3.8. SCP of the UPS Event SOP Class
N.7.3.2.3.8.1. SCP of the UPS Event SOP Class - N-EVENT-REPORT
N.7.3.2.4. Instance Availability Notification Service
N.7.3.2.4.1. SCU of the Instance Availability Notification SOP Class - N-CREATE
N.7.3.2.4.2. SCP of the Instance Availability Notification SOP Class - N-CREATE
N.7.3.2.5. Storage Service
N.7.3.2.5.1. SCU of the Storage SOP Classes - C-STORE
N.7.3.2.5.2. SCP of the Storage SOP Classes - C-STORE
N.7.3.2.6. Storage Commitment Service
N.7.3.2.6.1. SCU of the Storage Commitment Push Model SOP Class - N-ACTION
N.7.3.2.6.2. SCU of the Storage Commitment Push Model SOP Class - N-EVENT-REPORT
N.7.3.2.6.3. SCP of the Storage Commitment Push Model SOP Class - N-ACTION
N.7.3.2.6.4. SCP of the Storage Commitment Push Model SOP Class - N-EVENT-REPORT
N.7.3.2.7. Query/Retrieve Service
N.7.3.2.7.1. SCU of the Query/Retrieve FIND SOP Classes - C-FIND
N.7.3.2.7.2. SCU of the Query/Retrieve MOVE SOP Classes - C-MOVE
N.7.3.2.7.3. SCP of the Query/Retrieve FIND SOP Classes - C-FIND
N.7.3.2.7.4. SCP of the Query/Retrieve MOVE SOP Classes - C-MOVE
N.7.3.2.8. Print Management Service
N.7.3.2.8.1. SCU of the Basic Film Session SOP Class
N.7.3.2.8.1.1. SCU of the Basic Film Session SOP Class - N-SET
N.7.3.2.8.1.2. SCU of the Basic Film Session SOP Class - N-DELETE
N.7.3.2.8.1.3. SCU of the Basic Film Session SOP Class - N-ACTION
N.7.3.2.8.2. SCU of the Basic Box Session SOP Class
N.7.3.2.8.2.1. SCU of the Basic Box Session SOP Class - N-CREATE
N.7.3.2.8.2.2. SCU of the Basic Box Session SOP Class - N-SET
N.7.3.2.8.2.3. SCU of the Basic Box Session SOP Class - N-DELETE
N.7.3.2.8.2.4. SCU of the Basic Box Session SOP Class - N-ACTION
N.7.3.2.8.3. SCU of the Basic Grayscale Image Box SOP Class - N-SET
N.7.3.2.8.4. SCU of the Basic Color Image Box SOP Class - N-SET
N.7.3.2.8.5. SCU of the Printer SOP Class
N.7.3.2.8.5.1. SCU of the Printer SOP Class - N-EVENT-REPORT
N.7.3.2.8.5.2. SCU of the Printer SOP Class - N-GET
N.7.3.2.8.6. SCU of the Basic Annotation Box SOP Class - N-SET
N.7.3.2.8.7. SCU of the Print Job SOP Class
N.7.3.2.8.7.1. SCU of the Print Job SOP Class - N-EVENT-REPORT
N.7.3.2.8.7.2. SCU of the Print Job SOP Class - N-GET
N.7.3.2.8.8. SCU of the Presentation LUT SOP Class
N.7.3.2.8.8.1. SCU of the Presentation LUT SOP Class - N-CREATE
N.7.3.2.8.8.2. SCU of the Presentation LUT SOP Class - N-DELETE
N.7.3.2.8.9. SCU of the Printer Configuration Retrieval SOP Class - N-GET
N.7.3.2.8.10. SCP of the Basic Film Session SOP Class
N.7.3.2.8.10.1. SCP of the Basic Film Session SOP Class - N-CREATE
N.7.3.2.8.10.2. SCP of the Basic Film Session SOP Class - N-SET
N.7.3.2.8.10.3. SCP of the Basic Film Session SOP Class - N-DELETE
N.7.3.2.8.10.4. SCP of the Basic Film Session SOP Class - N-ACTION
N.7.3.2.8.11. SCP of the Basic Film Box SOP Class
N.7.3.2.8.11.1. SCP of the Basic Film Box SOP Class - N-CREATE
N.7.3.2.8.11.2. SCP of the Basic Film Box SOP Class - N-SET
N.7.3.2.8.11.3. SCP of the Basic Film Box SOP Class - N-DELETE
N.7.3.2.8.11.4. SCP of the Basic Film Box SOP Class - N-ACTION
N.7.3.2.8.12. SCP of the Basic Grayscale Image Box SOP Class - N-SET
N.7.3.2.8.13. SCP of the Basic Color Image Box SOP Class - N-SET
N.7.3.2.8.14. SCP of the Printer SOP Class
N.7.3.2.8.14.1. SCP of the Printer SOP Class - N-EVENT-REPORT
N.7.3.2.8.14.2. SCP of the Printer SOP Class - N-GET
N.7.3.2.8.15. SCP the Basic Annotation Box SOP Class - N-SET
N.7.3.2.8.16. SCP of the Print Job SOP Class
N.7.3.2.8.16.1. SCP of the Print Job SOP Class - N-EVENT-REPORT
N.7.3.2.8.16.2. SCP of the Print Job SOP Class - N-GET
N.7.3.2.8.17. SCP of the Presentation LUT SOP Class
N.7.3.2.8.17.1. SCP of the Presentation LUT SOP Class - N-CREATE
N.7.3.2.8.17.2. SCP of the Presentation LUT SOP Class - N-DELETE
N.7.3.2.8.18. SCP of the Printer Configuration Retrieval SOP Class - N-GET
N.7.3.3. DICOM Web Services
N.7.3.3.1. General Status Codes
N.7.3.3.1.1. Common Transaction as Origin Server
N.7.3.3.1.2. Common Transaction as User Agent
N.7.3.3.2. URI Web Service
N.7.3.3.2.1. URI Web Service as Origin Server
N.7.3.3.2.2. URI Web Service as User Agent
N.7.3.3.3. Studies Web Service
N.7.3.3.3.1. Retrieve Transaction as Origin Server
N.7.3.3.3.2. Retrieve Transaction as User Agent
N.7.3.3.3.3. Store Transaction as Origin Server
N.7.3.3.3.4. Store Transaction as User Agent
N.7.3.3.3.5. Search Transaction as Origin Server
N.7.3.3.3.6. Search Transaction as User Agent
N.7.3.3.4. Worklist Web Service
N.7.3.3.4.1. Create Transaction as Origin Server
N.7.3.3.4.2. Create Transaction as User Agent
N.7.3.3.4.3. Retrieve Workitem Transaction as Origin Server
N.7.3.3.4.4. Retrieve Workitem Transaction as User Agent
N.7.3.3.4.5. Update Workitem Transaction as Origin Server
N.7.3.3.4.6. Update Workitem Transaction as User Agent
N.7.3.3.4.7. Change Workitem State Transaction as Origin Server
N.7.3.3.4.8. Change Workitem State Transaction as User Agent
N.7.3.3.4.9. Request Cancellation Transaction as Origin Server
N.7.3.3.4.10. Request Cancellation Transaction as User Agent
N.7.3.3.4.11. Search Transaction as Origin Server
N.7.3.3.4.12. Search Transaction as User Agent
N.7.3.3.4.13. Subscribe Transaction as Origin Server
N.7.3.3.4.14. Subscribe Transaction as User Agent
N.7.3.3.4.15. Unsubscribe Transaction as Origin Server
N.7.3.3.4.16. Unsubscribe Transaction as User Agent
N.7.3.3.4.17. Suspend Global Subscription Transaction as Origin Server
N.7.3.3.4.18. Suspend Global Subscription Transaction as User Agent
N.7.3.3.5. Non-Patient Instance Web Service
N.7.3.3.5.1. Retrieve Transaction as Origin Server
N.7.3.3.5.2. Retrieve Transaction as User Agent
N.7.3.3.5.3. Store Transaction as Origin Server
N.7.3.3.5.4. Store Transaction as User Agent
N.7.3.3.5.5. Search Transaction as Origin Server
N.7.3.3.5.6. Search Transaction as User Agent
N.8. Security
N.8.1. Introduction
N.8.2. External Network Requirements
N.8.3. TCP Port Configuration
N.8.4. DICOM Security Profiles Support
N.8.4.1. Secure Use and User Identity Profiles
N.8.4.2. Secure Transport Connection Profiles
N.8.4.3. Media Storage Security Profiles
N.8.4.4. Attribute Confidentiality Profiles
N.8.4.5. Digital Signature Profiles
N.8.4.6. Additional DICOM Security Profiles
N.8.5. User Identity Negotiation Support
N.8.5.1. Association Initiation
N.8.5.2. Association Acceptance
N.8.6. Web Services Security Features
N.8.7. Other Security Features
N.8.7.1. Media Storage Security
N.8.7.2. Network Security
N.8.7.3. Other Security Features
Annexes
N.9. A.A Information Object Definitions (IODs)
N.9.1. A.A.1 Information Shared Across Multiple IODs
N.9.1.1. A.A.1.1 Common Modules
N.9.1.2. A.A.1.2 Common Functional Group Macros
N.9.1.3. A.A.1.3 Common Private Modules
N.9.1.4. A.A.1.4 Coded Values
N.9.2. A.A.2 <image IOD1 E.g. Computed Tomography Image IOD>
N.9.2.1. A.A.2.1 <Image IOD 1> Specific Modules
N.9.2.2. A.A.2.2 <Image IOD 1> Functional Group Macros - NA
N.9.2.3. A.A.2.3 <Image IOD 1> Private Modules
N.9.2.4. A.A.2.3 <Image IOD 1> Coded Values
N.9.3. A.A.3 <image IOD 2 E.g., Enhanced Computed Tomography Image IOD>
N.9.3.1. A.A.3.1 <Image IOD 2> Specific Modules
N.9.3.2. A.A.3.2 <Image IOD 2> Functional Group Macro
N.9.3.3. A.A.3.3 <Image IOD 2> Private Modules
N.9.3.4. A.A.3.4 <Image IOD 2> Coded Values
N.9.4. A.A.4. <SR IOD 1 E.g., Comprehensive SR IOD>
N.9.4.1. A.A.4.1 <SR IOD 1> Specific Modules
N.9.4.2. A.A.4.2 <SR IOD 1> Functional Group Macros - N/A
N.9.4.3. A.A.4.3 <SR IOD 1> Private Modules
N.9.4.4. A.A.4.4 <SR IOD 1> Coded Values
N.9.5. A.A.5 Basic Directory IOD
N.9.6. A.A.6 <Private IOD 1>
N.9.6.1. A.A.6.1 <Private IOD 1> Specific Modules - NA
N.9.6.2. A.A.6.2 <Private IOD 1> Functional Group Macros
N.9.6.3. A.A.6.3 <Private IOD 1> Private Modules
N.9.6.4. A.A.6.4 <Private IOD 1> Coded Values
N.10. A.B Structured Report Content Encoding
N.10.1. A.B.1 Mammography CAD SR (TID 4000)
N.10.1.1. A.B.1.1 Code Sets
N.10.2. A.B.2 Echocardiography Procedure Result SR (TID 5200)
N.10.2.1. A.B.2.1 Measurement Encoding
N.10.2.1.1. A.B.2.1.1 Left Ventricle
N.10.2.1.2. A.B.2.1.2 Right Ventricle
N.11. A.C Security Details
N.11.1. A.C.1 External Network Requirement Details
N.11.1.1. A.C.1.1 Basic Time Synchronization
N.11.1.2. A.C.1.2 Basic Network Address Management
N.11.1.3. A.C.1.3 Application Configuration Management
N.11.1.4. A.C.1.4 DNS Service Discovery
N.11.2. A.C.2 DICOM Security Profile Details
N.11.2.1. A.C.2.1 Online Electronic Storage Secure Use
N.11.2.2. A.C.2.2 Audit Trail Messages
N.11.2.3. A.C.2.3 Audit Trail Message Transmission Profile - SYSLOG - TLS
N.11.2.4. A.C.2.4 Audit Trail Message Transmission Profile - SYSLOG - UDP
N.11.2.5. A.C.2.5 Secure Transport Connection Details
N.11.2.6. A.C.2.6 Attribute Confidentiality Details
N.11.2.7. A.C.2.7 Digital Signature Details
N.11.2.8. A.C.2.8 Additional DICOM Security Profile Details
N.12. A.D Mapping of Attributes
N.12.1. A.D.1 Mapping Between Modality Worklist Instances and MPPS
N.13. A.E Code Set Usage

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
N.1-1. Overview of Implemented Services
N.4-1. <Product> Application Data Flow Diagram
N.7-1. Real-World Activity and Cross AE interaction
N.7-2. Real-World Activity and Cross AE interaction - Query Retrieve
N.7-3. Sequencing of Real-World Activities for <AE1>
N.7-4. Sequencing of Real-World Activities for <QueryRetrieve AE>
N.7-5. Sequencing of Real-World Activities for <Web AE>

List of Tables

N.1-1. Storage SOP Classes
N.1-2. Supported Transfer Syntaxes
N.1-3. Supported Root SR Template IDs (TIDs)
N.1-4. Verification SOP Class
N.1-5. Workflow Management SOP Classes
N.1-6. Query/Retrieve SOP Classes
N.1-7. Printing SOP Classes
N.1-8. URI Service
N.1-9. Study Service
N.1-10. Worklist Service
N.1-11. Non-Patient Instance Service
N.1-12. Supported Media Application Profiles
N.1-13. Supported Real-Time Video SOP Classes
N.1-14. De-Identification Profiles
N.1-15. :Supported Specific Character Sets
N.5-1. Service to AE Mapping
N.5-2. Supported C-FIND Query Parameters for Modality Worklist - SCU
N.5-3. Supported C-FIND Return Keys for Modality Worklist - SCP
N.5-4. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCU
N.5-5. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCP
N.5-6. Supported N-CREATE Attributes for Instance Availability Notification - SCU
N.5-7. Meaning of Instance Availability Values- SCU
N.5-8. Behavior on Instance Availability Values -SCP
N.5-9. Transcoding of Transfer Syntaxes
N.5-10. Levels of Conformance
N.5-11. Attribute Coercion by Storage SCP
N.5-12. Display and Processing Limitations for Storage SCP
N.5-13. Behavior when storing Instances
N.5-14. Image Compression by Storage SCP
N.5-15. Failure Behavior for Storage Commitment SCU
N.5-16. Failure Conditions on Storage Commitment SCP
N.5-17. Supported C-FIND Attribute Matching for Study Root Q/R Model -SCU
N.5-18. Supported C-FIND Attribute Matching for Study Root Q/R Model - SCP
N.5-19. Basic Grayscale Print Management Meta SOP Classes - SCU
N.5-20. Services for the Basic Film Session SOP Class - SCU
N.5-21. Supported N-CREATE and N-SET Attributes for the Basic Film Session SOP Class - SCU
N.5-22. Supported Services for the Basic Film Box SOP Classes
N.5-23. Supported N-CREATE and N-SET Attributes for the Basic Film Box SOP Class - SCU
N.5-24. Services for the Basic Grayscale Image Box SOP Class
N.5-25. Supported N-SET Attributes for the Basic Grayscale Image Box SOP Class -SCU
N.5-26. Services for the Printer SOP Class
N.5-27. Printer SOP Class N-EVENT-REPORT Behavior
N.5-28. Supported N-GET Attributes for the Printer SOP Class - SCU
N.5-29. Basic Color Print Management Meta SOP Classes
N.5-30. :Services for the Basic Color Image Box SOP Class - SCU
N.5-31. Supported N-SET Attributes for the Basic Color Image Box SOP Class - SCU
N.5-32. Services for the Basic Annotation Box SOP Class - SCU
N.5-33. Supported N-SET Attributes for the Basic Annotation Box SOP Class-SCU
N.5-34. Services for the Print Job SOP Class - SCU
N.5-35. Print Job SOP Class N-EVENT-REPORT Behavior
N.5-36. Supported N-GET Attributes for the Print Job SOP Class - SCU
N.5-37. Services for the Presentation LUT SOP Class - SCU
N.5-38. Supported N-CREATE Attributes for the Presentation LUT SOP Class-SCU
N.5-39. Services for the Printer Configuration Retrieval SOP Class - SCU
N.5-40. Basic Grayscale Print Management Meta SOP Classes - SCP
N.5-41. Services for the Basic Film Session SOP Class - SCP
N.5-42. - Supported N-CREATE and N-SET Attributes for Basic Film Session - SCP
N.5-43. Services Supported for the Basic Film Box SOP Class - SCP
N.5-44. Supported N-CREATE and N-SET Attributes for Basic Film Box - SCP
N.5-45. Services for the Basic Grayscale Image Box SOP Class- SCP
N.5-46. Supported N-SET Attributes for Basic Grayscale Image Box - SCP
N.5-47. Services for the Printer SOP Class - SCP
N.5-48. Printer SOP Class N-EVENT-REPORT Behavior
N.5-49. Supported N-GET Attributes for the Printer SOP Class - SCP
N.5-50. Basic Color Print Management Meta OP Classes - SCP
N.5-51. Services for the Basic Color Image Box SOP Class - SCP
N.5-52. Supported N-SET Attributes for Basic Color Image Box - SCP
N.5-53. Services for the Basic Annotation Box SOP Class - SCP
N.5-54. Supported N-SET Attributes for Basic Annotation Box SOP Class - SCP
N.5-55. Services for the Print Job SOP Class - SCP
N.5-56. Print Job SOP Class N-EVENT-REPORT- SCP
N.5-57. Supported N-GET Attributes for the Print Job SOP Class - SCP
N.5-58. Services for the Presentation LUT SOP Class SCP
N.5-59. Supported N-CREATE Attributes for Presentation LUT - SCP
N.5-60. Services for the Printer Configuration Retrieval SOP Class
N.5-61. Supported Rendered Media Types
N.5-62. Query Parameters for Retrieve DICOM Instance URI Web Service - User Agent
N.5-63. Header Fields for Retrieve DICOM Instance URI Web Service - User Agent
N.5-64. Query Parameters for Retrieve DICOM Instance URI Web Service - Origin Server
N.5-65. Header Fields for Retrieve DICOM Instance URI Web Service - Origin Server
N.5-66. Query Parameters for Retrieve Rendered Instance URI Web Service - User Agent
N.5-67. Header Fields for Retrieve Rendered Instance URI Web Service - User Agent
N.5-68. Query Parameters for Retrieve Rendered Instance URI Web Service - Origin Server
N.5-69. Header Fields for Retrieve Rendered Instance URI Web Service - Origin Server
N.5-70. DICOM Compressed Bulkdata Media Types
N.5-71. Rendered Media Types
N.5-72. Resources Retrieve Transaction - User Agent
N.5-73. Query Parameters for Retrieve Transaction - User Agent
N.5-74. Header Fields for Retrieve Transaction - User Agent
N.5-75. Resources Retrieve Transaction - Origin Server
N.5-76. Query Parameters for Retrieve Transaction - Origin Server
N.5-77. Header Fields for Retrieve Transaction - Origin Server
N.5-78. Resources Store Transaction - User Agent
N.5-79. Header Fields for Store Transaction - User Agent
N.5-80. Resources Store Transaction - Origin Server
N.5-81. Header Fields for Store Transaction - Origin Server
N.5-82. Resources Search Transaction - User Agent
N.5-83. Query Parameters for Search Transaction - User Agent
N.5-84. Supported Query Attributes User Agent
N.5-85. Header Fields for Search Transaction - User Agent
N.5-86. Resources Search Transaction - Origin Server
N.5-87. Query Parameters for Search Transaction - Origin Server
N.5-88. Header Fields for Search Transaction - Origin Server
N.5-89. Query / Return Key Search Transaction - Origin Server
N.5-90. Resources for the Worklist Web Service Create Transaction - User Agent
N.5-91. Query Parameters for Worklist Web Service Create Workitem- User Agent
N.5-92. Header Fields for Worklist Web Service Create Workitem Worklist Web Service - User Agent
N.5-93. Resources for the Worklist Web ServiceCreate Transaction - Origin Server
N.5-94. Query Parameters for Worklist Web Service Create Transaction - Origin Server
N.5-95. Header Fields for Worklist Web Service Create Transaction - Origin Server
N.5-96. Resources for Worklist Web Service Retrieve Transaction - User Agent
N.5-97. Query Parameters for Worklist Web Service Retrieve Workitem Transaction - User Agent
N.5-98. Header Fields for Worklist Web Service Retrieve Workitem- User Agent
N.5-99. Resources for Worklist Web Service Retrieve Transaction- Origin Server
N.5-100. Query Parameters for Worklist Web Service Retrieve Workitem - Origin Server
N.5-101. Header Fields for Worklist Web Service Retrieve Workitem - Origin Server
N.5-102. Resources for Worklist Web Service Update Transaction - User Agent
N.5-103. Query Parameters for Worklist Web Service Update Transaction - User Agent
N.5-104. Header Fields for Worklist Web Service Update Transaction - User Agent
N.5-105. Resources for t Worklist Web Service Update Transaction - Origin Server
N.5-106. Query Parameters for Worklist Web Service Update Transaction - Origin Server
N.5-107. Header Fields for Worklist Web Service Update Transaction - Origin Server
N.5-108. Resources for Worklist Web Service Change State - User Agent
N.5-109. Query Parameters for Worklist Web Service Change State- User Agent
N.5-110. Header Fields for Worklist Web Service Change State - User Agent
N.5-111. Resources for Worklist Web Service Change State - Origin Server
N.5-112. Query Parameters for Worklist Web Service Change State Transaction - Origin Server
N.5-113. Header Fields for Worklist Web Service Change State Transaction - Origin Server
N.5-114. Resources for the Worklist Web Service Request Cancellation Transaction - User Agent
N.5-115. Query Parameters for Worklist Web Service Request Cancellation - User Agent
N.5-116. Header Fields for Worklist Web Service Request Cancellation - User Agent
N.5-117. Resources for the Worklist Web Service Request Cancellation - Origin Server
N.5-118. Query Parameters for Worklist Web Service Request Cancellation Transaction - Origin Server
N.5-119. Header Fields for Worklist Web Service Request Cancellation Transaction - Origin Server
N.5-120. Resources for Worklist Web Service Search Transaction - User Agent
N.5-121. Query Parameters for Worklist Web Service Search Transaction - User Agent
N.5-122. Header Fields for Worklist Web Service Search Transaction - User Agent
N.5-123. Resources for Worklist Web Service Search Transaction - Origin Server
N.5-124. Query Parameters for Worklist Web Service Search Transaction - Origin Server
N.5-125. Header Fields for Worklist Web Service Search Transaction - Origin Server
N.5-126. Resources for Worklist Web Service Subscribe Transaction - User Agent
N.5-127. Query Parameters for Worklist Web Service Subscribe Transaction - User Agent
N.5-128. Header Fields for Worklist Web Service Subscribe Transaction - User Agent
N.5-129. Resources for Worklist Web Service Subscribe Transaction - Origin Server
N.5-130. Query Parameters for Worklist Web Service Subscribe Transaction - Origin Server
N.5-131. Header Fields for Worklist Web Service Subscribe Transaction - Origin Server
N.5-132. Resources for Worklist Web Service Unsubscribe Transaction - User Agent
N.5-133. Header Fields for Worklist Web Service Unsubscribe Transaction- User Agent
N.5-134. Resources for Worklist Web Service Unsubscribe Transaction - Origin Server
N.5-135. Header Fields for Worklist Web Service Unsubscribe Transaction - Origin Server
N.5-136. Resources for Worklist Web Service Suspend Global Subscription Transaction - User Agent
N.5-137. Header Fields for Worklist Web Service Suspend Global Subscription Transaction - User Agent
N.5-138. Resources for Worklist Web Service Suspend Global Subscription Transaction - Origin Server
N.5-139. Header Fields for Worklist Web Service Suspend Global Subscription Transaction - Origin Server
N.5-140. Non-Patient Instance Web Service Storage SOP Classes
N.5-141. Resources for NPI Web Services Retrieve Transaction - User Agent
N.5-142. Query Parameters for NPI Web Services Retrieve Transaction - User Agent
N.5-143. Header Fields for NPI Web Services Retrieve Transaction - User Agent
N.5-144. Resources for NPI Web Services Retrieve Transaction - Origin Server
N.5-145. Query Parameters for NPI Web Services Retrieve Transaction - Origin Server
N.5-146. Header Fields for NPI Web Services Retrieve Transaction - Origin Server
N.5-147. Resources for NPI Web Services Store Transaction - User Agent
N.5-148. Query Parameters for NPI Web Services Store Transaction - User Agent
N.5-149. Header Fields for NPI Web Services Store Transaction - User Agent
N.5-150. Resources for NPI Web Services Store Transaction - Origin Server
N.5-151. Query Parameters for NPI Web Services Store Transaction - Origin Server
N.5-152. Header Fields for NPI Web Services Store Transaction - Origin Server
N.5-153. Resources for NPI Web Services Search Transaction - User Agent
N.5-154. Query Parameters for NPI Web Services Search Transaction - User Agent
N.5-155. Supported Query Attributes for NPI Web Services Search Transaction - User Agent
N.5-156. Header Fields for NPI Web Services Search Transaction - User Agent
N.5-157. Resources for NPI Web Services Search Transaction - Origin Server
N.5-158. Query Parameters for NPI Web Services Search Transaction - Origin Server
N.5-159. Header Fields for NPI Web Services Search Transaction - Origin Server
N.5-160. Query / Return Key for NPI Web Services Search Transaction - Origin Server
N.5-161. DICOM-RTV Instances Specification Service Consumer
N.5-162. :DICOM-RTV Screen Resolutions Service Consumer
N.5-163. DICOM-RTV Instances Specification Service Provider
N.5-164. DICOM RTV Screen Resolutions Service Provider
N.5-165. Conversion/Mapping of Non-Default Specific Character Sets
N.6-1. General Configuration Parameters
N.6-2. Worklist Service Parameters
N.6-3. MPPS Service Parameters
N.6-4. Unified Worklist and Procedure Step Service Parameters
N.6-5. IAN Service Parameters
N.6-6. Storage Service Parameters
N.6-7. Storage Commitment Service Parameters
N.6-8. Query/Retrieve Service Parameters
N.6-9. Print Management Service Parameters
N.6-10. URI Web Service Parameters
N.6-11. Retrieve Transaction Configuration Parameters
N.6-12. Store Transaction Parameters
N.6-13. Search Transaction Parameters
N.6-14. Worklist Web Service Parameters
N.6-15. NPI Web Service Parameters
N.6-16. Media Storage Service Parameters
N.6-17. RTV Service Parameters
N.6-18. Audit Trail Originator Parameters
N.6-19. Audit Trail Collector Parameters
N.7-1. General Association Parameters
N.7-2. Association Parameters for <AE1>
N.7-3. Extended Negotiation for <Activity 1> of <AE1> - Association Initiation
N.7-4. Extended Negotiation for <Activity 2> of <AE1> - Association Acceptance
N.7-5. Transfer Syntax Selection Preference Order - Image SOP Classes for <AE1>
N.7-6. Transfer Syntax Selection Preference Order - Video SOP Classes for <AE1>
N.7-7. Transfer Syntax Selection Preference Order - Non-Image SOP Classes for <AE1>
N.7-8. DICOM Communication Failure Behavior as Association Initiator
N.7-9. DICOM Communication Failure Handling as Association Acceptor
N.7-10. Status Codes for C-FIND of the Modality Worklist Information Model SOP Class - SCU
N.7-11. Status Codes for C-FIND of the Modality Worklist Information Model SOP Class - SCP
N.7-12. Status Codes for N-CREATE of the Modality Performed Procedure Step SOP Class - SCU
N.7-13. Status Codes for N-SET of the Modality Performed Procedure Step SOP Class - SCU
N.7-14. Status Codes for N-CREATE of the Modality Performed Procedure Step SOP Class - SCP
N.7-15. Status Codes for N-SET of the Modality Performed Procedure Step SOP Class - SCP
N.7-16. Status Codes for N-CREATE of the UPS Push SOP Class - SCU
N.7-17. N-ACTION of the UPS Push SOP Class Request UPS Cancel - SCU
N.7-18. Status Codes for N-GET of the UPS Push SOP Class - SCU
N.7-19. Status Codes for C-FIND of the UPS Pull SOP Class - SCU
N.7-20. Status Codes for N-GET of the UPS Pull SOP Class - SCU
N.7-21. Status Codes for N-SET of the UPS Pull SOP Class - SCU
N.7-22. Status Codes for N-ACTION of the UPS Pull SOP Class - SCU
N.7-23. Status Codes for N-ACTION (subscribe/unsubscribe) of the UPS Watch SOP Class - SCU
N.7-24. Status Codes for N-GET of the UPS Watch SOP Class - SCU
N.7-25. Status Codes for C-FIND of the UPS Watch SOP Class - SCU
N.7-26. Status Codes for N-ACTION (request cancel) of the UPS Watch SOP Class - SCU
N.7-27. Status Codes for the N-EVENT-REPORT of the UPS Event SOP Class - SCU
N.7-28. Status Codes for N-CREATE of the UPS Push SOP Class - SCP
N.7-29. Status Codes for N-ACTION (request cancel) of the UPS Push SOP Class - SCP
N.7-30. Status Codes for N-GET of the UPS Push SOP Class - SCP
N.7-31. Status Codes C-FIND of the UPS Pull SOP Class - SCP
N.7-32. Status Codes for N-GET of the UPS Pull SOP Class - SCP
N.7-33. Status Codes for N-SET of the UPS Pull SOP Class - SCP
N.7-34. Status Codes for N-ACTION (change state) of the UPS Pull SOP Class - SCP
N.7-35. Status Codes for N-ACTION (Un/subscribe) ) of the UPS Watch SOP Class - SCP
N.7-36. Status Codes for N-GET of the UPS Watch SOP Class - SCP
N.7-37. Status Codes C-FIND of the UPS Watch SOP Class - SCP
N.7-38. Status Codes for N-ACTION (cancel request) of the UPS Watch SOP Class - SCP
N.7-39. Status Codes for N-EVENT-REPORT of the UPS Event SOP Class - SCP
N.7-40. Status Codes for N-CREATE for the Instance Availability Notification SOP Class - SCU
N.7-41. Status Codes for N-CREATE for the Instance Availability Notification SOP Class - SCP
N.7-42. Status Codes C-STORE for the Storage SOP Classes - SCU
N.7-43. Status Codes C-STORE of the Storage SOP Classes - SCP
N.7-44. Status Codes for N-ACTION of the Storage Commitment Push Model SOP Class - SCU
N.7-45. Status Codes for N-EVENT-REPORT for the Storage Commitment Push Model SOP Class - SCU
N.7-46. Status Codes for N-ACTION for the Storage Commitment Push Model SOP Class - SCP
N.7-47. Status Codes for N-EVENT-REPORT for the Storage Commitment Push Model SOP Class - SCP
N.7-48. Status Codes C-FIND for Query/Retrieve FIND SOP Classes - SCU
N.7-49. Status Codes C-MOVE for Query/Retrieve MOVE SOP Classes - SCU
N.7-50. Status Codes C-FIND for Query/Retrieve FIND SOP Classes - SCP
N.7-51. Status Codes C-MOVE for Query/Retrieve MOVE SOP Classes - SCP
N.7-52. Status Codes for N-CREATE of the Basic Film Session SOP Class - SCU
N.7-53. Status Codes for N-SET of the Basic Film Session SOP Class - SCU
N.7-54. Status Codes for N-DELETE of the Basic Film Session SOP Class - SCU
N.7-55. Status Codes for N-Action of the Basic Film Session SOP Class - SCU
N.7-56. Status Codes for N-CREATE of the Basic Film Box SOP Class - SCU
N.7-57. Status Codes for N-SET of the Basic Film Box SOP Class - SCU
N.7-58. Status Codes for N-DELETE of the Basic Film Box SOP Class - SCU
N.7-59. Status Codes for N-ACTION of the Basic Film Box SOP Class - SCU
N.7-60. Status Codes for N-SET of the Grayscale Image Box SOP Class - SCU
N.7-61. Status Codes for N-SET of the Color Image Box SOP Class - SCU
N.7-62. Status Codes for N-EVENT-REPORT of the Printer SOP Class - SCU
N.7-63. Status Codes for N-GET of the Printer SOP Class - SCU
N.7-64. Status Codes for N-SET of the Basic Annotation Box SOP Class - SCU
N.7-65. Status Codes N-EVENT-REPORT of the Print Job SOP Class - SCU
N.7-66. Status Codes for N-GET of the Print Job SOP Class - SCU
N.7-67. Status Codes N-CREATE of the Presentation LUTSOP Class - SCU
N.7-68. Status Codes for N-DELETE of the Presentation LUT SOP Class - SCU
N.7-69. Status Codes N-GET of the Printer Configuration Retrieval SOP Class - SCU
N.7-70. Status Codes for N-CREATE of the Basic Film Session SOP Class - SCP
N.7-71. Status Codes for N-SET of the Basic Film Session SOP Class - SCP
N.7-72. Status Codes for N-DELETE of the Basic Film Session SOP Class - SCP
N.7-73. Status Codes for N-ACTION of the Basic Film Session SOP Class - SCP
N.7-74. Status Codes for N-CREATE of the Basic Film Box SOP Class - SCP
N.7-75. Status Codes for N-SET of the Basic Film Box SOP Class - SCP
N.7-76. Status Codes for N-DELETE of the Basic Film Box SOP Class - SCP
N.7-77. Status Codes for N-ACTION of the Basic Film Box SOP Class - SCP
N.7-78. Status Codes for N-SET of the Basic Grayscale Image Box SOP Class - SCP
N.7-79. Status Codes for N-SET of the Basic Color Image Box SOP Class - SCP
N.7-80. Status Codes for N-EVENT-REPORT of the Printer SOP Class - SCP
N.7-81. Status Codes for N-GET of the Printer SOP Class - SCP
N.7-82. Status Codes for N-SET of the Basic Annotation Box SOP Class - SCP
N.7-83. Status Codes for N-EVENT-REPORT of the Print Job SOP Class - SCP
N.7-84. Status Codes for N-GET of the Print Job SOP Class - SCP
N.7-85. Status Codes for N-CREATE of the Presentation LUT SOP Class - SCP
N.7-86. Status Codes for N-DELETE of the Presentation LUT SOP Class - SCP
N.7-87. Status Codes for N-GET of the Printer Configuration Retrieval SOP Class - SCP
N.7-88. Status Codes of Origin Server for all Transactions
N.7-89. Status Codes of User Agent for all Transactions
N.7-90. Status Codes of Origin Server for URI Service
N.7-91. Status Codes of User Agent for URI Service
N.7-92. Status Codes of Origin Server for Retrieve Transaction
N.7-93. Status Codes of User Agent for Retrieve Transaction
N.7-94. Status Codes of Origin Server for Store Transaction
N.7-95. Status Codes of User Agent for Store Transaction
N.7-96. Status Codes of Origin Server for Search Transaction
N.7-97. Status Codes of User Agent for Search Transaction
N.7-98. Status Codes of Origin Server for Create Transaction
N.7-99. Status Codes of User Agent for Create Transaction
N.7-100. Status Codes of Origin Server for Retrieve Workitem Transaction
N.7-101. Status Codes of User Agent for Retrieve Workitem Transaction
N.7-102. Status Codes of Origin Server for Update Workitem Transaction
N.7-103. Status Codes of User Agent for Update Workitem Transaction
N.7-104. Status Codes of Origin Server for Change Workitem State Transaction
N.7-105. Status Codes of User Agent for Change Workitem State Transaction
N.7-106. Status Codes of Origin Server for Request Cancellation Transaction
N.7-107. Status Codes of User Agent for Request Cancellation Transaction
N.7-108. Status Codes of Origin Server for Search Transaction
N.7-109. Status Codes of User Agent for Search Transaction
N.7-110. Status Codes of Origin Server for Subscribe Transaction
N.7-111. Status Codes of User Agent for Subscribe Transaction
N.7-112. Status Codes of Origin Server for Unsubscribe Transaction
N.7-113. Status Codes of User Agent for Unsubscribe Transaction
N.7-114. Status Codes of Origin Server for Suspend Global Subscription Transaction
N.7-115. Status Codes of User Agent for Suspend Global Subscription Transaction
N.7-116. Status Codes of Origin Server for Retrieve Transaction
N.7-117. Status Codes of User Agent for Retrieve Transaction
N.7-118. Status Codes of Origin Server for Search Transaction
N.7-119. Status Codes of User Agent for Store Transaction
N.7-120. Status Codes of Origin Server for Search Transaction
N.7-121. Status Codes of User Agent for Search Transaction
N.8-1. External Network Requirements
N.8-2. Secure Use and User Identity Profiles
N.8-3. Secure Transport Connection Profiles
N.8-4. Content Encryption used for Secured Media
N.8-5. Content Types used for Secured Media
N.8-6. Digest Algorithms used for Secured Media
N.8-7. Attribute Confidentiality Profiles
N.8-8. User Identity Negotiation as Association Initiator
N.8-9. User Identity Negotiation as Association Acceptor
N.9-1. Patient Module
N.9-2. General Study Module
N.9-3. General Series Module
N.9-4. Frame of Reference Module
N.9-5. General Equipment Module
N.9-6. Enhanced General Equipment Module
N.9-7. General Image Module
N.9-8. Image Pixel Module
N.9-9. Multi-Frame Functional Groups Module
N.9-10. Multi-Frame Dimension Module
N.9-11. Acquisition Context Module
N.9-12. SOP Common Module
N.9-13. Pixel Measures Functional Group Macro
N.9-14. Frame Content Functional Group Macro
N.9-15. Plane Position (Patient) Functional Group Macro
N.9-16. Plane Orientation (Patient) Functional Group Macro
N.9-17. Referenced Image Functional Group Macro
N.9-18. Frame Anatomy Functional Group Macro
N.9-19. Irradiation Event Identification Functional Group Macro
N.9-20. Private Module 1
N.9-21. Private Module 2
N.9-22. Values and Code Sets shared across IODs
N.9-23. <Image IOD 1>
N.9-24. Image Plane Module for <Image IOD 1>
N.9-25. CT Image Module for <Image IOD 1>
N.9-26. Private Module3 for <Image IOD 1>
N.9-27. Values and Code Sets for <Image IOD 1>
N.9-28. <Image IOD 2>
N.9-29. Functional Group Macros used in < Image IOD 2>
N.9-30. CT Series Module for <Image IOD 2>
N.9-31. Enhanced CT Image Module for <Image IOD 2>
N.9-32. CT Frame Type Functional Group Macro for <Image IOD 2>
N.9-33. CT Acquisition Type Functional Group Macro for <Image IOD 2>
N.9-34. CT Acquisition Details Functional Group Macro for <Image IOD 2>
N.9-35. CT Table Dynamics Functional Group Macro for <Image IOD 2>
N.9-36. CT Position Functional Group Macro for < Image IOD 2>
N.9-37. CT Geometry Functional Group Macro for <Image IOD 2>
N.9-38. CT Reconstruction Functional Group Macro for <Image IOD 2>
N.9-39. CT Exposure Functional Group Macro for <Image IOD 2>
N.9-40. CT X-Ray Details Functional Group Macro for <Image IOD 2>
N.9-41. CT Pixel Value Transformation Functional Group Macro for <Image IOD 2>
N.9-42. CT Additional X-Ray Source Functional Group Macro for <Image IOD 2>
N.9-43. CT Multi-energy CT Characteristics Functional Group Macro for <Image IOD 2>
N.9-44. Values and Code Sets for <Image IOD 2>
N.9-45. <SR IOD 1>
N.9-46. SR Document Series Module used in <SR IOD 1>
N.9-47. SR Document General Module used in <SR IOD 1>
N.9-48. SR Document Content Module used in <SR IOD 1>
N.9-49. SR IOD 1>
N.9-50. Basic Directory IOD
N.9-51. <Private IOD 1>
N.9-52. Private Module 4 for <Private IOD 1>
N.9-53. Private Module 5 for <Private IOD 1>
N.9-54. Values and Code Sets for <Private IOD 1>
N.10-1. Mammography CAD SR (TID 4000)
N.10-2. Mammography CAD SR - Image View Modifier Codes
N.10-3. Mammography CAD SR - Single Image Finding Codes
N.10-4. Echocardiography Procedure Report SR (TID 5200)
N.10-5. Left Ventricle Measurements
N.10-6. Right Ventricle Measurements
N.11-1. LDAP Security Patterns
N.11-2. DICOM Specific Audit Messages
N.11-3. Audit Message Details
N.11.2.5 1. Secure Transport Connection Profiles and Cipher Suites
N.11.2.5 2. Secure Transport Connection Profiles and TLS 1.3 Key Exchange Algorithms
N.11.2.5 3. Secure Transport Connection Profiles and TLS 1.3 Signature Algorithms
N.11-4. Secure Transport Connection Profiles and Cipher Suites
N.11-5. Secure Transport Connection Configuration
N.11-6. De-identified Elements and Actions
N.12-1. Mapping of Attributes from Modality Worklist to Instance and MPPS

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

[ISO 7498-1] ISO. 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.

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

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

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

Application Entity (AE)

See [ISO 7498-1].

Application Entity Title

See [ISO 7498-1].

Protocol Data Unit

See [ISO 7498-1].

Transfer Syntax

See [ISO 7498-1].

3.2 ACSE Service Definitions

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

Association

See [ISO 8649].

Association Initiator

See [ISO 8649].

3.3 Presentation Service Definitions

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

Abstract Syntax

See [ISO 8822].

Abstract Syntax Name

See [ISO 8822].

Presentation Context

See [ISO 8822].

Transfer Syntax Name

See [ISO 8822].

3.4 DICOM Introduction and Overview Definitions

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

Conformance Statement

See Conformance Statement in PS3.1 .

Information Object

See Information Object in PS3.1 .

Service-Object Pair Class (SOP Class)

See Service-Object Pair Class in PS3.1 .

3.5 DICOM Information Object Definitions

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

Information Object Definition (IOD)

See Information Object Definition in PS3.3 .

3.6 DICOM Service Class Specification Definitions

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

Real-World Activity

See Real-World Activity in PS3.4 .

Service Class

See Service Class in PS3.4 .

Service Class User (SCU)

See Service Class User in PS3.4 .

Service Class Provider (SCP)

See Service Class Provider in PS3.4 .

Meta Service-Object Pair Class (Meta SOP Class)

See Meta Service-Object Pair Class in PS3.4 .

3.7 DICOM Data Structure and Encoding Definitions

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

Data Set

See Data Set in PS3.5 .

DICOM Transfer Syntax

See DICOM Transfer Syntax in PS3.5 .

Unique Identifier (UID)

See Unique Identifier in PS3.5 .

3.8 DICOM Message Exchange Definitions

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

Extended Negotiation

See Extended Negotiation in PS3.7 .

Implementation Class UID

See Implementation Class UID in PS3.7 .

3.9 DICOM Upper Layer Service Definitions

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

DICOM Upper Layer Service

See DICOM Upper Layer Service in PS3.8 .

Presentation Address

See Presentation Address in PS3.8 .

3.10 Media Storage and File Format for Data Interchange

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

File-set

See File-set in PS3.10 .

File-set Creator (FSC)

See File-set Creator in PS3.10 .

File-set Reader (FSR)

See File-set Reader in PS3.10 .

File-set Updater (FSU)

See File-set Updater in PS3.10 .

Media Storage Application Profile

See Media Storage Application Profile in PS3.10 .

3.11 DICOM Conformance

This Part uses the following definitions:

Standard SOP Class

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

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 that do not recognize the additional Type 3 Attributes would simply ignore them.

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.

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.

Standard Attribute

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

Private Attribute

An Attribute that is not defined in the DICOM Standard.

Standard Application Profile

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

Augmented Application Profile

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

Private Application Profile

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

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.

Transformation of DICOM SR to CDA

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

3.12 Hypertext Transfer Protocol (HTTP/HTTPS) Definitions

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

HTTP

See HTTP in PS3.18 .

HTTPS

See HTTPS in PS3.18 .

origin server

See origin server in PS3.18 .

user agent

See user agent in PS3.18 .

3.13 Web Services Definitions

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

Bulk Data

See Bulk Data in PS3.18 .

Bulk Data URI

See Bulk Data URI in PS3.18 .

DICOM Object

See DICOM Object in PS3.18 .

DICOM Resource

See DICOM Resource in PS3.18 .

DIMSE Proxy

See DIMSE Proxy in PS3.18 .

Event Report

See Event Report in PS3.18 .

Metadata

See Metadata in PS3.18 .

RESTful Web Service

See RESTful Web Service in PS3.18 .

Service

See Service in PS3.18 .

sRGB

See sRGB in PS3.18 .

Status Report

See Status Report in PS3.18 .

Subscriber

See Subscriber in PS3.18 .

Target URI

See Target URI in PS3.18 .

Thumbnail

See Thumbnail in PS3.18 .

Transaction

See Transaction in PS3.18 .

UTF-8

See UTF-8 in PS3.18 .

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

QIDO-RS

Query based on ID for DICOM Objects by RESTful Services

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, which could be DICOM DIMSE, DICOM Web Services or DICOM Real Time Video, between the local Application Entities, and whichever remote Application Entities handle the remote Real-World Activities. 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.

The content of Conformance Statement uses a consistent structure regardless of whether the implementation supports a DIMSE interface, a DICOM Media Storage interface, a DICOM Web Service interface, DICOM Real Time Video interface, or a combination thereof. A single Conformance Statement shall be provided with the appropriate sections filled in. Sections not relevant for the implementation shall be kept and marked as not applicable. Subsections of a section marked as not applicable need not be included in the Conformance Statement (see the template in Annex N).

The first part of the Conformance Statement contains a DICOM Conformance Statement Overview, which is typically a short summary at the beginning of the document providing a high level description of the system. It should list the transfer capabilities, DIMSE Services, Media Services, DICOM Web Services and DICOM Real Time Video Services, including their roles (SCU/SCP, FSC, FSR, etc.), and supported Transfer Syntaxes. This overview should also include a list of all Root Templates supported by the system.

6.1 Overview of Implementation Model Section For Conformance Statements

A functional overview containing the Application Data Flow Diagram that shows all the Application Entities. It also shows how they relate to both local and remote Real-World Activities.

6.2 Overview of Service and Interoperability Description Section For Conformance Statements

The Service and Interoperability description section of a Conformance Statement consists of the following major parts:

6.2.1 Mapping of Services to Application Entities

Provides an overview of the Application Entities and the Services supported by each AE.

6.2.2 Supported DIMSE Services

  • Provides a more detailed specification of each SOP Classes supported within the various services (Worklist, MPPS, Storage, Query/Retrieve, Print, etc.)

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

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

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

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

6.2.3 Supported DICOM Web Services

  • Provides a more detailed specification of each DICOM Web Service supported

6.2.4 Supported Media Storage Services Section For Conformance Statements

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

  • a more detailed specification of each Application Entity listing the Media Storage Application Profiles supported, which outlines the policies with which it creates, reads, or updates File-sets on the media;

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

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

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

6.3 Overview of DICOM Configuration Section For Conformance Statements

Section describing DICOM-related configuration details for the supported communication mechanisms:

  • DIMSE Services

  • DICOM Web Services

  • Media Storage Services

  • Real Time Video Services

  • Audit Trail - Syslog

6.4 Overview of Network and Media Communication Details Section For Conformance Statements

The network and Media Communication Details section of a Conformance Statement consists of the following major parts:

  • Real-World activity Data Flow Diagrams that shows the sequencing activities among the Application Entities

  • Association parameters

  • Policies with which each Application Entity and Real-World Activity combination initiates or accepts Associations

  • Transfer syntaxes selection preferences

  • Status codes and handling for DIMSE Services and DICOM Web Services

7 Conformance Requirements

An implementation claiming DICOM conformance may choose to support one or more of the following communication mechanisms:

7.1 DICOM Networking Conformance Requirements

7.1.1 DIMSE Protocol Conformance Requirements

An implementation claiming DIMSE network conformance shall:

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

  • provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;

  • 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 a 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:

7.1.2 DICOM Web Services Conformance Requirements

An implementation claiming DICOM Web Services conformance shall:

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

  • provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;

  • conform to at least one Service as defined in PS3.18;

    Note

    Conformance to a Service implies conformance to the related Resources defined in PS3.18 and IODs outlined in PS3.3, and Data Elements defined in PS3.6.

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

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

    Note

    Conformance to PS3.5 and/or PS3.18 also implies conformance to PS3.6.

  • obtain a 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).

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 a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;

  • 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. If additional Type 3 Attributes drawn from the Data Dictionary in PS3.6 are sent that affect the encoding of other Attributes, or whose encoding depends on the values of other Attributes, their presence and use shall be consistent.

Note

E.g., An Attribute such as Pixel Padding Value (0028,0120) with a dictionary VR of US or SS would not be allowed to be present without Pixel Representation (0028,0103) also being present to resolve the encoding ambiguity. Further, Pixel Padding Value would not be allowed to be present in the absence of the Pixel Data (7FE0,0010) to which it applies.

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.

7.8 DICOM Real Time Video Conformance Requirements

An implementation claiming DICOM Real Time Video conformance shall:

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

  • provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in AnnexA;

  • conform to at least one Service as defined PS3.22;

    Note

    Conformance to a Service implies conformance to the related IODs outlined in PS3.3, and Data Elements defined in PS3.6.

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

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

    Note

    Conformance to PS3.5 and/or PS3.22 also implies conformance to PS3.6;

  • obtain a 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).

A DICOM Conformance Statement Template (Retired)

Retired. See PS3.2-2022d

B Conformance Statement Sample Integrated Modality (Retired)

Retired. See PS3.2-2022d

C Conformance Statement Sample DICOMRis Interface (Retired)

Retired. See PS3.2-2022d

D Conformance Statement Sample DICOM Image Viewer (Retired)

Retired. See PS3.2-2022d

E Conformance Statement Example Print Server (Retired)

Retired. See PS3.2-2022d

F DICOM Conformance Statement Query-Retrieve-Server (Retired)

Retired. See PS3.2-2022d

G Conformance Statement Sample ImageViewer with Hanging Protocol Support (Retired)

Retired. See PS3.2-2022d

H DICOM Conformance Statement Medication-System-Gateway (Retired)

Retired. See PS3.2-2022d

I Conformance Statement Sample WADO Service (Retired)

Retired. See PS3.2-2022d

J Conformance Statement Sample STOW Service (Retired)

Retired. See PS3.2-2022d

K Conformance Statement Sample QIDO-RS Provider (Retired)

Retired. See PS3.2-2022d

L Conformance Statement Sample DICOM-RTV Service Provider (Retired)

Retired. See PS3.2-2022d

M Conformance Statement Sample DICOM-RTV Service Consumer (Retired)

Retired. See PS3.2-2022d

N DICOM Conformance Statement Template (Normative)

The content and organization of DICOM Conformance Statements shall conform to this template

The following formatting conventions are used in this template to guide Conformance Statement authors. Based on the format of the text used in the template, a DICOM Conformance Statement shall:

  • Include, without modification, text shown in regular font style (i.e., non-italic). Such text is standard "boilerplate" like introductions to sections, tables that list mandatory Attributes, etc.

  • Remove text shown in italic font style and [enclosed by square brackets]. Such text provides instructions to Conformance Statement authors on how to use this template. The text may be retained until the author has no further use for it but should be removed before publication of the Conformance Statement.

  • Either remove text shown in italic font style or modify it appropriately and change it to regular font style. Such text is example text that may provide typical phrasing, examples of the types of topics that might be addressed in a certain section, or list optional Attributes which should be deleted if not supported, etc.

  • Replace text <enclosed in angle brackets> with appropriate text. Such text is a placeholder for variables like the product name. Remove the < > characters when replacing the text.

  • Replace text <<enclosed in double angle brackets>> with a single Value from the enclosed list. Such text provides a list of alternatives such as DICOM Defined Terms for an Attribute Value. Remove the << >> characters when replacing the text.

    • If Values other than those listed may be used, that is indicated by an ellipsis before the closing angle brackets (i.e., "…>>")

    • If multiple Values can be selected, instruction text will document that fact.

    • If some of the multiple Values are mandatory, the mandatory Values are shown in regular font style and the optional Values are shown in italic font style.

Note

Some sections and tables mix text in multiple fonts. Each piece of text is treated accordingly to its font style.

The following conventions are used in this template to encourage uniformity that makes it easier for consumers to read Conformance Statements from different vendors and find specific pieces of information. A DICOM Conformance Statement shall:

  • Indicate support in tables (e.g., in the "SCU" and "SCP" column of table with rows for SOP Classes) by using "Y" for yes and "N" for no.

  • Include rows in tables only for things (e.g., SOP Classes, Services, Attributes, etc.) supported by your implementation. Do not include rows for things that are not supported.

  • Format supported Value ranges in table cells using square brackets as follows: [lower Value … upper Value].

  • Format multiple supported Values in table cells separated by a semicolon in the cell.

  • Replace the content of Sections that are not applicable to the implementation with the text "N/A" and append "- N/A" to the end of the section title. This is done rather than deleting the section; however, if all the subsections in a section are marked "N/A", the subsections may be deleted, and, if so, the parent section should have the text "N/A" as content, and its title should have "- N/A" appended to its original title. This keeps the numbering of sections consistent throughout DICOM Conformance Statements for easier comparison.

  • If Sections need to be added, append them at the end of the parent Section in order to keep Section numbering consistent with this Template.

  • Tables shall be numbered sequentially within each major subsection. It is not necessary to follow the table numbering in the template, if specific tables are not applicable for the product described in this DICOM Conformance Statement.

  • Consider providing information (e.g., extensive explanation) as a footnote under the table when the information exceeds the comfortable size of the cell.

The Annexes are mandatory parts of this template and shall be populated if applicable to the implementation. For example, the IOD definitions must be filled in if the implementation supports creation of DICOM SOP Instances.

If throughout the document any of the tables get too wide for portrait mode it is recommended to switch to landscape mode for the table.

Tables are split into subsections for better readability. If a subsection of the table is not supported, remove the complete subsection from the table.

If the DICOM Conformance Statement describes multiple products/versions in one document, the cover page should indicate which products/versions are covered.

Ensure spelling throughout the entire DICOM Conformance Statement is consistent with the DICOM Standard.

If this template contradicts normative statements in other Parts of the DICOM Standard, those other Parts take precedence.

The template content begins after this line.

[When using the template below for creation of a DICOM Conformance Statement, start numbering the actual document content with Section 1 for the Overview, not with N.1.]

N.0 Cover Page

[A DICOM Conformance Statement shall have a cover page, which shall include:

  • The commercial name(s) 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.

  • Date of the document

]

N.1 Overview

[Provide a short description of the product's DICOM functionality.]

[Edit the following illustration, depicting DICOM Services implemented in your product and the interactions with remote systems connected to product. Replace <Product> with your product name and <Remote Systems x> with a system category such as modality, PACS, RIS, or <DICOM Service> by the applicable service such as storage, query/ retrieve, query modality worklist, ….]

Overview of Implemented Services

Figure N.1-1. Overview of Implemented Services


N.1.1 Content and Transfer

Table N.1-1 lists all Storage SOP Classes and the supported transfer mechanisms as well as the usage scenarios for those instances.

The "Transfer Syntax Set" column lists the sets of Transfer Syntaxes defined in Table N.1-2 that are applicable to each SOP Class. The "DIMSE", "DICOM Web" and "Media Services" columns indicate the roles supported for each SOP Class.

The "Function" columns indicate how the instances are used by the system:

  • Create: The system creates instances of the SOP Class. The type of the created SOP Class is indicated by one of the following abbreviations:

    • S: Standard SOP Class

    • SE: Standard Extended SOP Class

    • SP: Specialized SOP Class

    • P: Private SOP Class

  • Display: The system displays the instances of the SOP Class to the user, either by displaying the SOP Instances natively or by applying instances of another suitable SOP Class to the image instances (e.g., a Presentation State or CAD SR).

  • Process: The system processes the instances of the SOP Class to derive some further information that is made available to the user (e.g., a CAD processing algorithm, or a 3D Rendering).

  • Archive: The system stores the instances of the SOP Class and makes them available again.

[List all Storage SOP Classes supported by the system in numerical order of the SOP Class UID. Indicate in the "Transfer Syntax Set" column which of the Transfer Syntax Sets defined in Table N.1-2 below are supported. Note that for each SOP Class, multiple Transfer Syntax Sets can be supported.]

[For the "Create Function" columns, use Values as defined above. For all other supported role/"Function" columns, list "Y" for yes and "N" for no.]

Table N.1-1. Storage SOP Classes

SOP Classes

Transfer Syntax Set

DIMSE Services

DICOM Web Services

Media Services

Function

SCU

SCP

UA

OS

FSC

FSU

FSR

Create

Display

Process

Archive

Media Storage Directory Storage

1.2.840.10008.1.3.10

NI

Computed Radiography Image Storage

1.2.840.10008.5.1.4.1.1.1

U; LL; L

Digital X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.1

U; LL; L

Digital X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.1.1

U; LL; L

Digital Mammography X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.2

U; LL

VL Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4

U; LL; L

Video Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4.1

V

Comprehensive SR Storage

1.2.840.10008.5.1.4.1.1.88.33

NI

See Table N.1-3 below

Mammography CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.50

See Table N.1-3 below


[Table N.1-2 defines some example Transfer Syntax Sets that are referenced by their abbreviation in Table N.1-1 above. You can modify the Transfer Syntax Sets below to match your product implementation and extend the Table with additional Transfer Syntax Sets as needed. For additional Transfer Syntax Sets, create additional rows and assign abbreviations in "() " that can be referenced in the Table above.]

Table N.1-2. Supported Transfer Syntaxes

Transfer Syntax Set

Transfer Syntax Name

Transfer Syntax UID

DICOM Web Service Bulkdata Media Type

Lossless Compressed Transfer Syntax Set (LL)

JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])

1.2.840.10008.1.2.4.70

image/jpeg

JPEG 2000 Image Compression (Lossless Only)

1.2.840.10008.1.2.4.90

image/jp2

RLE Lossless

1.2.840.10008.1.2.5

image/x-dicom-rle

Lossy Compressed Transfer Syntax Set (L)

JPEG Baseline (Process 1)

1.2.840.10008.1.2.4.50

image/jpeg

JPEG Extended (Process 2 & 4)

1.2.840.10008.1.2.4.51

image/jpeg

JPEG 2000 Image Compression

1.2.840.10008.1.2.4.91

image/jp2

Non-Image Transfer Syntax Set (NI)

Implicit VR Little Endian

1.2.840.10008.1.2

N/A

Explicit VR Little Endian

1.2.840.10008.1.2.1

application/octet-stream

Explicit VR Big Endian (Retired)

1.2.840.10008.1.2.2

N/A

Uncompressed Transfer Syntax Set (U)

Implicit VR Little Endian

1.2.840.10008.1.2

N/A

Explicit VR Little Endian

1.2.840.10008.1.2.1

application/octet-stream

Explicit VR Big Endian (Retired)

1.2.840.10008.1.2.2

N/A

Video Transfer Syntax Set (V)

MPEG2 Main Profile / Main Level

1.2.840.10008.1.2.4.100

video/mpeg2

MPEG2 Main Profile / High Level

1.2.840.10008.1.2.4.101

video/mpeg2

MPEG-4 AVC/H.264 High Profile / Level 4.1

1.2.840.10008.1.2.4.102

video/mp4

MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1

1.2.840.10008.1.2.4.103

video/mp4

MPEG-4 AVC/H.264 High Profile / Level 4.2 For 2D Video

1.2.840.10008.1.2.4.104

video/mp4

Real-Time Video Transfer Syntax Set (RTV)

SMPTE ST 2110-20 Uncompressed Progressive Active Video

1.2.840.10008.1.2.7.1

N/A

SMPTE ST 2110-20 Uncompressed Interlaced Active Video

1.2.840.10008.1.2.7.2

N/A

SMPTE ST 2110-30 PCM Digital Audio

1.2.840.10008.1.2.7.3

N/A


N.1.1.1 Structured Reporting Root Template IDs

Table N.1-3 lists all Template IDs (TID) of Root Templates that are supported by the system. The "Function" column indicates how the system uses the content of the DICOM SR:

  • CREATE: The system creates instances using the specified TID.

  • RENDER: The system displays the content of the SR, without using the data for any processing.

  • EXTRACT_DATA: The system can extract structured data from the content and use the data for subsequent processing (e.g., reporting).

  • OVERLAY: The system uses the information in the SR to display information directly on the images (e.g., Mammography CAD markers).

  • ARCHIVE: The system stores instances for later retrieval.

The "SOP Class UID" column indicates which of the SR Storage SOP Classes are used to encode the information or to store it. If multiple SOP Classes are supported the "Condition" column describes the conditions for using the different SOP Classes.

[Table N.1-3 provides some examples, add/remove TIDs to match your product implementation. Add Root TIDs in ascending numerical order.

For guidance on the meaning of the columns see description above. Note that in the "Function" column multiple Values can be listed.

It is recommended to add a link to the "Root Template ID" column to the relevant subsection of Section N.10.]

Table N.1-3. Supported Root SR Template IDs (TIDs)

Name

Root TID

Function

SOP Classes

Condition

Mammography CAD Document Root

4000

CREATE;

ARCHIVE;

OVERLAY

Comprehensive SR Storage

1.2.840.10008.5.1.4.1.1.88.33

Based on association negotiation

Mammography CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.50

Adult Echocardiography Procedure Report

5200

EXTRACT_DATA

Comprehensive SR Storage

1.2.840.10008.5.1.4.1.1.88.33


N.1.2 DIMSE Services

N.1.2.1 Verification

Table N.1-4 lists support for the Verification SOP Class.

[Modify Table N.1-4 to reflect support for the Verification SOP Class.]

Table N.1-4. Verification SOP Class

SOP Classes

Transfer Syntax

SCU

SCP

Verification

1.2.840.10008.1.1

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1


N.1.2.2 Storage

For details on supported Storage SOP Classes see Section N.1.1.

N.1.2.3 Workflow Management

Table N.1-5 lists all supported Workflow Management SOP Classes.

[Modify Table N.1-5 to reflect SOP Classes in the Workflow Management area that are supported. For each supported service indicate the role it supports. If it neither supports a SOP Class as SCU nor SCP, remove the respective line from the Table]

Table N.1-5. Workflow Management SOP Classes

SOP Classes

Transfer Syntax

SCU

SCP

Modality Worklist Information Model - FIND

1.2.840.10008.5.1.4.31

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Modality Performed Procedure Step

1.2.840.10008.3.1.2.3.3

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Storage Commitment Push Model

1.2.840.10008.1.20.1

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Unified Procedure Step - Push

1.2.840.10008.5.1.4.34.6.1

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Unified Procedure Step - Watch

1.2.840.10008.5.1.4.34.6.2

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Unified Procedure Step - Pull

1.2.840.10008.5.1.4.34.6.3

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Unified Procedure Step - Event

1.2.840.10008.5.1.4.34.6.4

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Instance Availability Notification

1.2.840.10008.5.1.4.33

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1


N.1.2.4 Query/Retrieve

Table N.1-6 lists all supported Query/Retrieve SOP Classes.

[Table N.1-6 lists some SOP Classes for querying and retrieving from a remote DICOM node, nevertheless PS3.4 defines many more additional SOP Classes for querying and retrieving. If your product supports any of these additional SOP Classes (e.g., any of the SOP Classes supporting C-GET), add them to the Table below and delete the SOP Classes not supported by your product. If you neither support a SOP Class as SCU or SCP, remove the respective line from the Table.]

Table N.1-6. Query/Retrieve SOP Classes

SOP Classes

Transfer Syntax

SCU

SCP

Patient Root Query/Retrieve Information Model - FIND

1.2.840.10008.5.1.4.1.2.1.1

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Study Root Query/Retrieve - Information Model - FIND

1.2.840.10008.5.1.4.1.2.2.1

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Patient Root Query/Retrieve - Information Model - MOVE

1.2.840.10008.5.1.4.1.2.1.2

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Study Root Query/Retrieve - Information Model - MOVE

1.2.840.10008.5.1.4.1.2.2.2

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1


N.1.2.5 Printing

Table N.1-7 lists all supported Printing SOP Classes.

[Table N.1-7 lists some SOP Classes for Printing and PS3.4 defines additional SOP Classes for printing. If your product supports any of these additional SOP Classes, add them to the Table below, and remove any rows that do not apply to your product. If you neither support a SOP Class as SCU nor SCP, remove the respective line from the Table]

Table N.1-7. Printing SOP Classes

SOP Classes

Transfer Syntax

SCU

SCP

Basic Grayscale Print Management Meta

1.2.840.10008.5.1.1.9

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Basic Color Print Management Meta

1.2.840.10008.5.1.1.18

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Basic Annotation Box

1.2.840.10008.5.1.1.15

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Print Job

1.2.840.10008.5.1.1.14

Explicit VR Little Endian

1.2.840.10008.1.2.1

Explicit VR Little Endian

1.2.840.10008.1.2.1

Presentation LUT

1.2.840.10008.5.1.1.23

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Printer Configuration Retrieval

1.2.840.10008.5.1.1.17.376

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1


N.1.3 DICOM Web Services

N.1.3.1 URI Service (WADO-URI)

Table N.1-8 lists details on the support of the URI Service.

[Complete Table N.1-8 to indicate support for the URI Web Service.]

Table N.1-8. URI Service

Service

Transaction

User Agent

Origin Server

URI Web Service (WADO-URI)

Retrieve DICOM Instances

Retrieve Rendered Instance


For resources supported see Table N.1-1 in Section N.1.1

N.1.3.2 Studies Service

Table N.1-9 lists details on the support of the Studies Service.

[Complete Table N.1-9 to indicate support for the Studies Web Service]

Table N.1-9. Study Service

Service

Transaction

Resource

User Agent

Origin Server

Studies Web Service

Retrieve Capabilities

Retrieve (WADO-RS)

Study

Study Metadata

Study Bulkdata

Study Pixel Data

Rendered Study

Study Thumbnail

Series

Series Metadata

Series Bulkdata

Series Pixel Data

Rendered Series

Series Thumbnail

Instance

Instance Metadata

Instance Bulkdata

Instance Pixel Data

Rendered Instance

Instance Thumbnail

Frames

Rendered Frames

Frame Thumbnail

Bulkdata

Search (QIDO-RS)

All Studies

Study

Study's Series

Study's Instances

All Series

Series

Series Instances

All Instances

Instance

Store (STOW-RS)

All Studies

Study

Bulkdata


N.1.3.3 Worklist Service

Table N.1-10 lists details on the support of the Worklist Service.

[Complete Table N.1-10 to indicate support for the Worklist Web Service.]

Table N.1-10. Worklist Service

Service

Transaction

Resource

User Agent

Origin Server

Worklist Web Service (UPS-RS)

Retrieve Capabilities

Create Workitem

Worklist

Workitem

Update Workitem

Workitem

Retrieve Workitem

Workitem

Change Workitem State

Workitem

Request Cancellation

Workitem

Search

Worklist

Subscribe

Worklist

Filtered Worklist

Workitem

Unsubscribe

Worklist

Filtered Worklist

Workitem

Suspend Global Subscription

Worklist

Filtered Worklist

Workitem Event Report


N.1.3.4 Non-Patient Instance Service

Table N.1-11 lists details on the support of Non-Patient Instances Service.

For details on the supported resource categories (e.g., Color Palette, Defined Procedure Protocol, Hanging Protocol or Implant Templates), see Table N.1-1.

[Complete Table N.1-11 to indicate support for the Non-Patient Instance Web Service.]

Table N.1-11. Non-Patient Instance Service

Service

Transaction

Resource

User Agent

Origin Server

Non-Patient Instances Web Service

Retrieve Capabilities

Retrieve

Store

Search (Note)


N.1.4 Media Services

Table N.1-12 lists all supported Media Application Profiles.

[Table N.1-12 lists Media Storage Application profiles and supported roles. Extend/modify the Table to list the profiles supported by your system.]

Table N.1-12. Supported Media Application Profiles

Media Storage Application Profile

FSC

FSR

FSU

Compact Disk - Recordable

STD-GEN-CD

AUG-GEN-CD

DVD

AUG-GEN-DVD-JPEG

AUG-GEN-DVD-J2K

STD-GEN-DVD-JPEG

STD-GEN-DVD-J2K

USB

AUG-GEN-USB-J2K

STD-GEN-USB-J2K


N.1.5 Real Time Video Service

Table N.1-13 lists all supported Real-Time Video SOP Classes and Transfer Syntaxes.

[List all supported Real-Time Video SOP Classes in the Table below. For the "Transfer Syntax Set" column use Transfer Syntax Sets defined in Table N.1-2.]

Table N.1-13. Supported Real-Time Video SOP Classes

SOP Classes

Transfer Syntax Set

RTV

SCU

SCP

Video Endoscopic Image Real-Time Communication

1.2.840.10008.10.1

RTV

Video Photographic Image Real-Time Communication

1.2.840.10008.10.2

RTV

Audio Waveform Real-Time Communication

1.2.840.10008.10.3

RTV

Rendition Selection Document Real-Time Communication

1.2.840.10008.10.4

N/A


N.1.6 De-identification Profiles

Table N.1-14 lists all supported de-identification profiles and options.

[Complete Table N.1-14 to list supported De-Identification profiles and options. If you do not support de-identification, remove this table, and mark section as N/A]

Table N.1-14. De-Identification Profiles

Profile

Option

Basic Application-Level Confidentiality Profile

Clean Pixel Data Option

Clean Structured Content Option


N.1.7 Specific Character Sets

[List all supported Character Sets and the IANA name as well as a description in the Table below.]

Table N.1-15. :Supported Specific Character Sets

Defined Term

IANA

Description

Single-Byte Character Sets without Code Extensions

ISO_IR 6

ISO-646

Default Repertoire

ISO_IR 100

ISO-8859-1

Latin Alphabet No.1 (West Europe)

Single-Byte Character Sets with Code Extension

ISO 2022 IR 100

Latin Alphabet No. 1 (West Europe)

Multi-Byte Character Sets without Code Extensions

GB18030

GB18030

GB18030-2000 (P.R China Norm GB18030)

Multi-Byte Character Sets with Code Extensions

ISO 2022 IR 87

ISO-2022-JP

Japanese


N.2 Table of Contents

[The Table of Contents shall be provided to assist readers in easily finding the needed information.]

N.3 Introduction

N.3.1 Revision History

[Provide the revision history for this document including the document revision, the document revision date, the product version(s) the DICOM Conformance Statement applies to and give a high-level description of changes.]

Revision

Date

Product Version(s)

Change

<Revision>

<Date>

<Product Version(s)>

<Change>

N.3.2 Audience

This document is intended for the audience listed below. It is assumed that the reader has a working knowledge of the DICOM Standard.

[Below is a list of typical users of a DICOM Conformance Statement, modify and add other user groups if needed.]

The document structure was designed for easier access to relevant information for different user groups:

  • Clinical Users, who want to get an overview of the implemented interoperability features of the system can see Section N.4 Implementation Model.

  • Personnel involved in Sales can use the information in Section N.1 to assess the compatibility between different systems involved in a sales situation.

  • System Integrators can use information in Section N.6 during system installation and also information from Section N.5 Service and Interoperability Description for details regarding the implemented services.

  • Field Service Engineers can use the details from Section N.5 Service and Interoperability Description and from Section N.7 Network and Media Communication Details for troubleshooting.

  • Hospital IT staff focusing on security can use the details provided in Section N.8 Security regarding implemented Security features.

  • Research Personnel may be interested in using information provided in Section N.9 Information Object Definitions (IODs) or Section N.10 Structured Report Content Encoding to get detailed imaging and measurement information.

N.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> and other DICOM products. The Conformance Statement should be read and understood in conjunction with the DICOM Standard [1]. 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 should not replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, it is the user's responsibility to perform the following validation activities:

    • The comparison of Conformance Statements from <Product> and other DICOM conformant equipment is the first step towards assessing interconnectivity and interoperability between those systems.

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

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

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

N.3.4 Terms and Definitions

[Terms and definitions should be listed here. The following list includes DICOM terms, delete terms that are not used throughout the Conformance Statement, but do not add or modify terms listed here.]

The following list includes DICOM Terms, that are used throughout this Conformance Statement:

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)

A representation of the external behavior of an application process in terms of DICOM Network Services, Web Services and/or media exchange capabilities implemented in one or more roles. 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 Information 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).

Data Element

A unit of information as defined by a single entry in the data dictionary. An encoded Information Object Definition (IOD) Attribute that is composed of, at a minimum, three fields: a Data Element Tag, a Value Length, and a Value Field. For some specific Transfer Syntaxes, a Data Element also contains a VR Field where the Value Representation of that Data Element is specified explicitly

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. Examples: MR Image IOD, CT Image IOD, Print Job IOD. The Attributes within an IOD 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).

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's Name, Patient ID, Patient' Birth Date, and Patient's 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.

Origin Server

Refers to the program that can originate authoritative responses to HTTP requests for a given Target Resource. The term "server" refers to any implementation that receives a web service request message from a user agent.

Presentation Context

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

Private SOP Class

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

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 a 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. E.g., a specific X-ray image.

Specialized SOP Class

A SOP Class that is derived from the Standard that is specialized 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.

Standard SOP Class

A SOP Class defined in the Standard, and that is implemented and used without any modifications.

Standard Extended SOP Class

A SOP Class that is defined in the standard, and that is extended by additional type 3 Attributes. The additional Attributes may either be drawn from the DICOM Data Dictionary in PS3.6 or may be Private Attributes.

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.

TLS-Secured Port

TCP port on which an implementation accepts TLS connections to exchange DICOM information.

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.

User Agent

A client in a network protocol used in communications within a client-server distributed computing system. In particular, the Hypertext Transfer Protocol (HTTP) identifies the client software originating the request, using a user-agent header, even when the client is not operated by a user.

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.

[Modify: Add a list of product specific definitions here. If none are needed remove the following introduction and table]

The following list includes product specific definitions used throughout this Conformance Statement

Product-specific Term

This is a product specific term used throughout this Conformance Statement

N.3.5 Abbreviations

Abbreviations that are used in this DICOM Conformance Statement are listed here.

[It is important to add any additional terms used by the implementation. Terms in the list may also be deleted at the discretion of the implementer.]

AE

Application Entity

AET

Application Entity Title

CAD

Computer Aided Detection

CDA

Clinical Document Architecture

CID

Context Identifier

DCS

DICOM Conformance Statement

DHCP

Dynamic Host Configuration Protocol

DICOM

Digital Imaging and Communications in Medicine

ELE

Explicit VR Little Endian

FSC

File-Set Creator

FSU

File-Set Updater

FSR

File-Set Reader

IANA

Internet Assigned Numbers Authority

IHE

Integrating the Healthcare Enterprise

ILE

Implicit VR Little Endian

IOD

Information Object Definition

IPv4

Internet Protocol version 4

IPv6

Internet Protocol version 6

ISO

International Organization for Standardization

MPPS

Modality Performed Procedure Step

MWL

Modality Worklist

NEMA

National Electrical Manufacturers Association

NTP

Network Time Protocol

OID

Object Identifier

OS

Origin Server

PDU

Protocol Data Unit

PHI

Protected Health Information

PPS

Performed Procedure Step

QIDO-RS

Query based on ID for DICOM Objects by RESTful Services

RTV

Real Time Video

SCP

Service Class Provider

SCU

Service Class User

SDP

Service Description Protocol

SOP

Service-Object Pair

SPS

Scheduled Procedure Step

SR

Structured Reporting

STOW-RS

STore Over the Web by RESTful Services

TCP/IP

Transmission Control Protocol/Internet Protocol

TID

Template Identifier

UA

User Agent

UI

User Interface

UID

Unique Identifier

UL

Upper Layer

UPS

Unified Procedure Step

UPS-RS

Unified Procedure Step by RESTful Services

VR

Value Representation

WADO-RS

Web Access to DICOM Objects by RESTful Services

WADO-URI

Web Access to DICOM Objects by URI

N.3.6 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]:

[1] National Electrical Manufacturers Association (NEMA), Rosslyn, VA USA. PS3 / ISO 12052 Digital Imaging and Communications in Medicine (DICOM) Standard. http://www.dicomstandard.org .

[2] Integrating the Healthcare Enterprise (IHE). IHE Radiology Technical Framework. http://www.ihe.net/Resources/technical_frameworks/#radiology .

N.4 Implementation Model

[Provide a short description of your implementation, including list of product names and versions that this DICOM Conformance Statement (DCS) intends to cover, as well as the use of DICOM Networking, DICOM Media Interchange and DICOM Web Services to achieve their purpose.]

[Also provide some high-level details of your product architecture, which are relevant to the interoperability features of the product (e.g., implementation of functionality in separate applications).]

N.4.1 Application Entities and Data Flow

The network and media interchange application model for the < Product> is shown in Figure N.4-1 <Product> Application Data Flow Diagram.

[Edit the Application Data Flow Diagram and description below as appropriate. Note that the Real-World Activity and Application Entity names specified in the figure must be used consistently throughout the document. If your product supports configurable AE definition, then describe the default configuration of AEs in this section. As a reminder, an AE is a representation of the external behavior of an application process in terms of DICOM network services, web services and/or media exchange capabilities implemented in one or more roles. A single device may have multiple Application Entities.]

<Product> Application Data Flow Diagram

Figure N.4-1.  <Product> Application Data Flow Diagram


[For each AE listed in Figure N.4-1 add one subsection A.4.1.x to describe the AE's DICOM functionality with regards to supported DIMSE, DICOM Web and Media Services, including the real-world activities that may trigger the service.]

[If your system supports flexible grouping of Services into Application Entities, keep the following paragraph, otherwise delete it]

This section describes the organization of the supported Services into Application Entities based on the default configuration of the system. This may change based on the actual setup at the customer site. See Section N.6 for details about the configurability of Services into AEs.

N.4.1.1 Functional Definition of <Application Entity 1>

[Provide a functional description of <Application Entity 1>, i.e., the DICOM Services (DIMSE, DICOM Web and Media Services), and supported roles, Real World Activities triggering the service and AE specific behavior.]

N.5 Service and Interoperability Description

N.5.1 Mapping of Services to Application Entities

Table N.5-1 provides an overview of the Application Entities and the Services supported by each AE.

[Table N.5-1 provides the mapping between Application Entities, Services and Roles as indicated in the example below.]

Table N.5-1. Service to AE Mapping

Application Entity

Supported Services

Role

DIMSE

DICOM Web

DICOM Media

Real-Time Video

SCU

SCP

Origin Server

User Agent

FSC

FSU

FSR

SCU

SCP

<Application Entity 1>

Basic Worklist Management

MPPS

<Application Entity 2>

Storage

Storage Commitment

Query/Retrieve

<Application Entity 3>(see Note 1)

Storage

Query/Retrieve

<Application Entity 4>

Print Management

<Media Entity 1>

Media Storage

<RTV Entity 1>

Real-Time Video


[If needed, explain specific behavior of an AE in a note, e.g., if you have an AE that provides specifically storage of de-identified instances or support for querying rejected instances as defined in the IOCM profile, e.g.:

Note

  1. This implementation of Query/Retrieve service handles retrieval of rejected instances as defined in the IHE Radiology IOCM Profile [2].

]

N.5.2 Supported DIMSE Services

[The following sections define the details of the supported DIMSE Services in more details. Fill in the information for all services supported by the system. Tables are given as examples and should be modified to meet the functionality of the system.]

N.5.2.1 Basic Worklist Management Service

N.5.2.1.1 SCU of the Modality Worklist Information Model - FIND SOP Class

As a Service Class User of the Modality Worklist Information Model - FIND SOP Class, the <Product> uses the C-FIND-RQ message to query the SCP. It supports the Query Keys listed in Table N.5-2.

In the "Matching Type" column, the following Values can be used:

  • SINGLE_VALUE: SCU can request single Value matching on this Attribute.

  • UID: SCU can request List of UID matching on this Attribute.

  • WILDCARD: SCU can request Wildcard matching on this Attribute.

  • RANGE: SCU can request Range matching on this Attribute.

  • SEQUENCE: SCU can request sequence matching on this Attribute.

  • UNIVERSAL: SCU can request that the Attribute be a return Value (universal matching).

In the "Query Value Source" column, the following Values can be used:

  • FIXED: The query Value cannot be modified by the user or by configuration.

  • GENERATED: The query Value is generated by the system (e.g., current date as the study date).

  • CONFIGURATION: The query Value is dependent on system configuration.

  • USER: The query Value is entered by the user.

  • SCANNED: The query Value is read from a barcode scanner or similar device.

  • EMPTY: The query Value is sent with a zero-length Value to indicate it is a return key only.

In the "Display on UI" column the following Values can be used:

  • D: the return Value is displayed on the main UI by default.

  • C: the return Value is displayed on the main UI if configured.

  • N: the return Value is never displayed.

[Modify the Table N.5-2 to include all Attributes supported by your system and use the terms defined for Matching Type, Query Value Source and Display on UI above. If Display on UI Values are modified from the ones received, indicate in a footnote. If multiple Values are supported for the Query Value Source, list all of them.]

Table N.5-2. Supported C-FIND Query Parameters for Modality Worklist - SCU

Attribute Name

Tag

Matching Type

Query Value Source

Value

Display on UI

Comments

Scheduled Procedure Step

Scheduled Procedure Step Sequence

(0040,0100)

SEQUENCE

>Scheduled Station AE Title

(0040,0001)

SINGLE_VALUE

GENERATED

D

AE title of the system performing the query

>Scheduled Procedure StepStart date

(0040,0002)

RANGE

GENERATED

D

Current date and time minus 1 hour plus 24 hours ahead

>Scheduled Procedure StepStart Time

(0040,0003)

RANGE

GENERATED

D

Current date and time minus 1 hour plus 24 hours ahead

>Modality

(0008,0060)

SINGLE_VALUE

FIXED

CT

>Scheduled PerformingPhysician's Name

(0040,0006)

UNIVERSAL

EMPTY

D

Requested Procedure

Study Instance UID

(0020,000D)

UNIVERSAL

EMPTY

Imaging Service Request

Accession Number

(0008,0050)

SINGLE VALUE

USER

D

See Annex D for details

Issuer of Accession Number Sequence

(0008,0051)

UNIVERSAL

EMPTY

Visit Identification

Visit Status

Patient Identification

Patient's Name

(0010,0010)

WILDCARD

USER

D

Patient Demographics


[Describe scenarios in which the product can issue C-FIND-CANCEL requests, e.g.,

The product issues C-FIND CANCEL requests in the following scenarios:* Configurable maximum of matches detected* Initiated by user]

[Also describe the SCU behavior if the cancellation request is ignored by the SCP and the SCP continues sending responses.]

[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN).]

N.5.2.1.2 SCP of the Modality Worklist Information Model - FIND SOP Class

As a Service Class Provider of the Modality Worklist Information Model - FIND SOP Class, the <Product> uses the C-FIND-RSP to communicate matches back to the SCU. It supports the Matching Keys listed in Table N.5-3.

In the "Matching Type" column, the following Values can be used:

  • SINGLE_VALUE: SCP can perform single Value matching on this Attribute.

  • UID: SCP can perform List of UID matching on this Attribute.

  • WILDCARD: SCP can perform Wildcard matching on this Attribute.

  • RANGE: SCP can perform Range matching on this Attribute.

  • SEQUENCE: SCP can perform sequence matching on this Attribute.

  • UNIVERSAL: SCP can provide the Attribute in the C-FIND response (i.e., universal matching).

[Table N.5-3 below contains a set of Attributes that could be supported by a product. Add and remove Attributes in order to match your product implementation using the matching type as defined above. If multiple codes are supported, list all of them. Use the "Comments" column if clarification is needed.]

Table N.5-3. Supported C-FIND Return Keys for Modality Worklist - SCP

Attribute Name

Tag

Matching Type

Comments

Scheduled Procedure Step

Schedule Procedure Step Sequence

(0040,0100)

>Scheduled Station AE Title

(0040,0001)

SINGLE_VALUE

>Scheduled Procedure StepStart Date

(0040, 0002)

RANGE

>Scheduled Procedure StepStart Time

(0040, 0003)

RANGE

>Modality

(0008,0060)

SINGLE_VALUE

>Scheduled PerformingPhysician's Name

(0040,0006)

WILDCARD

Requested Procedure

Study Instance UID

(0020,000D)

UNIVERSAL

Imaging Service Request

Accession Number

(0008,0050)

SINGLE_VALUE

Issuer of Accession Number Sequence

(0008,0051)

UNIVERSAL

Requesting Physician

(0032,1032)

UNIVERSAL

Referring Physician's Name

(0008,0090)

UNIVERSAL

Visit Identification

Visit Relationship

Patient Identification

Patient Demographics


[Describe the behavior of the product when it receives a C-FIND-CANCEL request.]

[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN).]

N.5.2.2 Modality Performed Procedure Step Service

N.5.2.2.1 SCU of the Modality Performed Procedure Step SOP Class

As a Service Class User of the Modality Performed Procedure Step SOP Class, the <Product> supports the Attributes listed in Table N.5-4 in the N-CREATE-RQ and N-SET-RQ messages, if it creates the message.

In the "Source" column the following Values can be used:

  • FIXED: the Value is pre-defined and cannot be modified.

  • GENERATED: the Value is generated by the system.

  • CONFIGURATION: the Value is copied from system configuration.

  • MWL: the Value is copied from modality worklist entry.

  • USER: the Value is entered by the user.

  • SCANNED: the Value is read from a barcode scanner or similar device.

  • EMPTY: The Attribute is sent with a zero-length Value

[List all Attributes provided in the MPPS message and list the Values that are used to populate the N-CREATE or N-SET messages, add or remove Attributes as applicable for your product and note that in the "Source" column, multiple Values can be provided in a semicolon separated list.]

Table N.5-4. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCU

Attribute Name

Tag

Source

Value N-CREATE

Value N-SET

Comments

Specific Character Set

(0008,0005)

FIXED

ISO_IR 100

ISO_IR 100

Performed Procedure Step Relationship

Scheduled Step Attribute Sequence

(0040,0270)

>Study Instance UID

(0020,000D)

MWL

>Accession Number

(0008,0050)

MWL;

USER; EMPTY

>Issuer of Accession Number Sequence

(0008,0051)

MWL; GENERATED

Patient's Name

(0010,0010)

MWL;

USER

Patient ID

(0010,0020)

MWL; GENERATED

Performed Procedure Step Information

Performed Procedure Step ID

(0040,0253)

Performed Procedure Step Status

(0040,0252)

GENERATED

DISCONTINUED

Performed Procedure Step Discontinuation Reason Code Sequence

GENERATED

[Either reference CID 9301 or provide the supported Code Set, if the Performed Procedure Step Status is set to DISCONTINUED]

Image Acquisition Results

Modality

(0008,0060)

GENERATED

CT

Study ID

(0020,0010)

GENERATED

Copied from Requested Procedure ID

Performed Protocol Code Sequence

(0040,0260)

GENERATED


[Describe the triggers by which your product initiates sending messages, e.g., the N-CREATE is sent when starting image acquisition and N-SET is sent when the study is closed.]

[If product also supports forwarding of MPPS messages (e.g., as described by the MPPS Manager Actor in the IHE Schedule Workflow profile), provide a description of the product behavior here.]

N.5.2.2.2 SCP of the Modality Performed Procedure Step SOP Class

As a Service Class Provider of the Modality Performed Procedure Step SOP Class, the product receives N-CREATE-RQ and N-SET-RQ messages from a remote SCU indicating the status of a procedure.

[Indicate in the table below whether your product has specific requirements with regards to the message content, e.g., whether specific Attributes are required using Y for yes and N for no.]

Table N.5-5 lists the message content that is required.

Table N.5-5. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCP

Attribute Name

Tag

Required in N-CREATE

Required in N-SET

Comments

Specific Character Set

(0008,0005)

Performed Procedure Step Relationship

Scheduled Step Attribute Sequence

(0040,0270)

>Study Instance UID

(0020,000D)

>Accession Number

(0008,0050)

>Issuer of Accession Number Sequence

(0008,0051)

Patient Name

(0010,0010)

Patient ID

(0010,0020)

Performed Procedure Step Information

Performed Procedure Step ID

(0040,0253)

Performed Procedure Step Discontinuation Reason Code Sequence

(0040,0281)

Image Acquisition Results

Modality

(0008,0060)

Study ID

(0020,0010)

Performed Protocol Code Sequence

(0040,0260)


[Describe the behavior of the product upon receiving an MPPS message, both the N-CREATE and the N SET.]

N.5.2.3 Unified Worklist and Procedure Step Service

[If your product supports any of the Unified Worklist SOP Classes, list the supported SOP Classes, the role, a list of supported messages, and the content of each supported message. If one or more of the Unified Worklist SOP Classes are not supported, keep the section, but include text indicating the SOP Class is "N/A".]

N.5.2.4 Instance Availability Notification Service

N.5.2.4.1 SCU of the Instance Availability Notification SOP Class

As a Service Class User of the Instance Availability Notification SOP Class, the system uses the N-CREATE-RQ message to inform remote SCPs about the availability and status of instances stored. Details of the message content are summarized in Table N.5-6.

In the "Source" column the following Values can be used:

  • FIXED: The Value is predefined and cannot be modified by data entry or by configuration.

  • GENERATED: The Value is generated by the system (e.g., current date as the study date).

  • CONFIGURATION: The Value is dependent on system configuration.

  • IMAGE: The Value is copied from the SOP Instance.

  • MWL: The Value is copied from Modality Worklist entry.

  • MPPS: The Value is copied from the MPPS message.

[The table below lists some Attribute for instance availability notification as examples. Complete table with Attributes supported by your product. For the "Source" column use Values as defined above.]

Table N.5-6. Supported N-CREATE Attributes for Instance Availability Notification - SCU

Attribute Name

Tag

Source

Value

Comments

Specific Character Set

(0008,0005)

FIXED

ISO_IR 100

Referenced Performed Procedure Step Sequence

(0008,1111)

GENERATED

>…

(0008,1150)

>Performed Workitem Code Sequence

(0040,4019)

GENERATED

>>…

Study Instance UID

(0020,000D)

IMAGE

Referenced Series Sequence

(0008,1115)

IMAGE

>Series Instance UID

(0020,000E)

IMAGE

>Referenced SOP Sequence

(0008,1199)

IMAGE

>>…

>>Instance Availability

(0008,0056)

GENERATED

See Table N.5-7

>>Retrieve AE Title

(0008,0054)

CONFIGURATION


The <Product> supports the Values listed in Table N.5-7, for the Instance Availability (0018,0056) Attribute.

[Fill in the table with Values supported for the Instance Availability Attribute and define the meaning of these Values in the context of your <Product>]

Table N.5-7. Meaning of Instance Availability Values- SCU

Value

Meaning

ONLINE

NEARLINE

OFFLINE

UNAVAILABLE


[Describe the mechanism that triggers sending of an Instance Availability Notification, the frequency and retrieve capabilities for referenced instances.]

[Describe the relationship between the Instance Availability Notification and Performed Procedure Step SOP Class, if both are supported.]

N.5.2.4.2 SCP of the Instance Availability Notification SOP Class

As a Service Class Provider of the Instance Availability Notification SOP Class, the system receives the N-CREATE-RQ message containing information on the availability and status of instances stored.

Table N.5-8 describes the behavior of <Product> when encountering one of the following Values for the Instance Availability (0018,0056) Attribute.

[Fill in the table with Values supported for the Instance Availability Attribute and define the policies of the product upon encountering these Values.]

Table N.5-8. Behavior on Instance Availability Values -SCP

Value

Behavior

ONLINE

NEARLINE

OFFLINE

UNAVAILABLE


[Describe the relationship between the Instance Availability Notification and Performed Procedure Step SOP Class, if both are supported and if a relationship exists.]

N.5.2.5 Storage Service

N.5.2.5.1 SCU of the Storage SOP Classes

As a Service Class User of the Storage Service Class, the <Product> uses the C-STORE-RQ message to request storage of DICOM objects by a remote SCP. See Section N.1.1 Content and Transfer in the Overview for the list of supported SOP Classes.

For details regarding the content of SOP Instances that are created by the system, see Section N.9, which describes the underlying IOD of the supported SOP Classes.

[Provide some details regarding the triggering of storage requests (e.g., automatically when an instance is stored, automatically when the study is closed, or initiated by the user).]

[Describe when and how your product divides sets of instances into multiple series and or studies and how these are ordered.]

[Describe the behavior of your product in the case of a C-STORE operation using a referenced pixel data Transfer Syntax such as JPIP Referenced Pixel Data Transfer Syntax. This includes the duration of validity of the reference.]

N.5.2.5.1.1 Transcoding of Transfer Syntaxes

[For implementations that store locally using multiple Transfer Syntaxes and if the SCU includes multiple Transfer Syntaxes in each Presentation Context it negotiates, the following can provide a useful summary for assessing compatibility with receiving systems. If this information is not useful for your product, replace the content of this Section with the text "N/A" and append "- N/A" to the end of the section title.]

Table N.5-9 describes supported transcodings between the locally stored encoding of SOP Instances and the negotiated Transfer Syntax. The following Values can be used:

  • SUPPORTED: Transcoding is possible and same SOP Instance UID is re-used.

  • NEW_UID: Transcoding is possible; however a new SOP Instance is created for transfer, e.g., due to lossy compression.

  • NOT_SUPPORTED: Transcoding is not possible.

[Table N.5-9 shows an example of how this transcoding could look, modify and add columns and rows as needed for Transfer Syntaxes supported by your product. If you need to provide further details on specific transcoding those can be added as notes below the table.]

Table N.5-9. Transcoding of Transfer Syntaxes

Stored Transfer Syntax

Sent Transfer Syntax

Implicit VR Little Endian

Explicit VR Little Endian

JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14)

JPEG Baseline (Process 1)

Implicit VR Little Endian

SUPPORTED (See Note 1)

SUPPORTED

NEW_UID

Explicit VR Little Endian

SUPPORTED

SUPPORTED

NEW_UID

JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14)

SUPPORTED

SUPPORTED

NEW_UID

JPEG Baseline (Process 1)

NOT_SUPPORTED

NOT_SUPPORTED

NOT_SUPPORTED

ACME Private Transfer Syntax 1 (See Note 2)

NOT_SUPPORTED

SUPPORTED

NOT_SUPPORTED

NOT_SUPPORTED


Note

  1. Explanation of the details of the transcoding (e.g., for known Private Attributes, the correct VR will be used. All others will be encoded as VR UN)

  2. This Private Transfer Syntax is using Explicit VR Little Endian with compressed pixel data.

N.5.2.5.2 SCP of the Storage SOP Classes

As a Service Class Provider of the Storage Service Class, the <Product> receives the C-STORE-RQ message from remote SCUs. See Section N.1.1 Content and Transferin the Overview for the list of supported SOP Classes.

Table N.5-10 defines the conformance levels of <Product>.

Table N.5-10. Levels of Conformance

Levels of Conformance

<<0, 1, or 2>>

Level of Digital Signature Support

<<1, 2, or 3>>


The <Product> coerces the Attributes listed in Table N.5-11 upon receiving them from other systems.

The "SOP Class UID" column indicates whether the coercion is applicable to specific SOP Classes or to "ALL" SOP Classes.

The "Type of Change" column defines the coercion done to the Attributes, the following Values can be used:

  • MODIFIED: The Value of the Attribute is changed; the new Value is described in the "New Value" column.

  • ADDED: The Attribute is added with the Value defined in the "New Value" column.

  • REMOVED: That Attribute is completely removed from the instance.

The "Condition" column defines the condition under which coercion is performed. The following Values can be used:

  • ALWAYS: Data coercion is performed on each instance of the specified SOP Class that is received by the system.

  • EXTERNAL: Data coercion is performed on instances received from systems external to the institution.

  • CONFIGURATION: Data coercion is performed based on system configuration.

  • OTHER: Data coercion is performed for other conditions. Details are defined in the "Comments" column.

[Table N.5-11 defines some examples on which data coercion can be performed. Add/remove scenarios as they apply to your product implementation. In case you use OTHER as a condition, the "Comments" column must be used to define the condition in further detail. It is recommended to include Attributes that are coerced in the Modified Attributes Sequence (0400,0550) of the Original Attributes Sequence (0400,0561), which is documented in Section N.9.1.1.]

Table N.5-11. Attribute Coercion by Storage SCP

Attribute Name

Tag

SOP Class UID

Type of Change

New Value

Condition

Comments

Patient ID

(0010,0020)

ALL

MODIFIED

Local patient ID

EXTERNAL

Issuer of Patient ID

(0010,0021)

ALL

ADDED

Local site as Issuer

ALWAYS

Lossy Image Compression

(0028,2110)

ALL

ADDED

01

CONFIGURATION

If lossy compression is enabled on system

Patient Name

(0010,0010)

CT Image Storage (1.2.840.10008.5. 1.4.1.1.2)

MODIFIED

Pat_xxx (where xxx is a sequential number)

OTHER

Studies received through CLINICALTRIAL AE


Table N.5-12 lists any limitations on displaying or processing instances, e.g., display or processing of the respective SOP Instances is prevented by an unsupported Value for an Attribute or the absence of that Attribute.

[When a Limitation is based on multiple Attributes (e.g., images cannot be displayed, if they are lossless compressed and encoded as Photometric Interpretation RGB), the Attributes are listed each in a row and the "Comments" and "Effect" cells are merged as shown in the example below. The "Comments" column is used to explain as necessary. Also use this mechanism when documenting restrictions based on Private Attributes, e.g., list the Private Creator attribute as well as the Private Attribute.]

The "Effect" column describes what happens if the limitation is encountered. The following Values are used:

  • ND: Display is not possible

  • LD: Display is limited

  • NP: Processing is not possible

  • LP: Processing is limited

  • OT: Other effects described in the "Comments" column

[If there are no restrictions on display or processing requirements, replace the sentence above with No restriction to display or post processing apply.]

Table N.5-12. Display and Processing Limitations for Storage SCP

Limitation Case

Effect

Comments

Attribute Name

Tag

Value

CT Image Storage (1.2.840.10008.5.1.4.1.1.2)

Bits Stored

(0028,0101)

16

ND

Digital Mammography X-Ray Image - Storage for Processing (1.2.840.10008.5.1.4.1.1.1.2.1)

Detector ID

(0018,700A)

ABSENT

NP

Value needs to be present for Licensing purposes

MR Image Storage (1.2.840.10008.5.1.4.1.1.4)

Private Creator

(0009,00xx)

MyCompanyPrivateCreator

LD

Different Diffusion directions and B Factors are not recognized for Diffusion Images

Diffusion B Factor

(0009,xx01)

ABSENT

Diffusion Direction

(0009,xx02)

ABSENT

All SOP Classes

Transfer Syntax UID

(0002,0010)

1.2.840.10008.1.2.4.70

ND

Lossless compressed RGB images cannot be displayed

Photometric Interpretation

(0028,0004)

RGB


Table N.5-13 lists the actions performed upon receiving instances from a remote AE and the system behavior when certain conditions are encountered

[Fill in Table N.5-13 for details. The Table shows some examples which can be reused, modified, deleted, or extended based on your product implementation]

Table N.5-13. Behavior when storing Instances

Action upon Receiving

Condition

System Behavior

Perform Attribute Validation

Minor DICOM inconsistencies

Fix error and log warning message:

  • Incorrect characters are replaced with "?"

  • Attributes exceeding length of VR are truncated

  • Type 2 Attributes not present are inserted with zero length

Duplicate Instance

<Reject/Overwrite/Ignore> Instances

DICOM Validation error

Send failure code on Association

Success

Instances are stored in an internal database

Add to an existing study

Mismatch in patient identifying information detected

Instances are stored in an exception queue

Success

Instances are stored in a local database

Localize Patient Information

Patient mismatch detected

Instances are stored in an exception queue

Success

Original patient identity information is copied to Other Patient ID Sequence (0010,1002)

Instances are stored in an internal database.

Coerce non-patient-identifying Attributes

Success

Original Values of coerced Attributes are copied to the Original Attributes Sequence (0040,0561).

Instances are stored in a local database

Evaluate Key Object Selection Document Title

Manifest

Use referenced data for cross-enterprise document sharing (IHE XDS-I).

Rejected for Quality Reasons

Rejected for Patient Safety Reasons

Only provide instances referenced in retrieval on a specialized AE title

Incorrect Modality Workflist Entry

Hide instances from display and never provide in retrieve requests

All other document titles

Display key images according to the specified title


Table N.5-14 describes how the SCP handles compression for stored instances.

The following Values are used in the "Behavior" column:

  • AS_IS: Images are stored as received.

  • CONFIGURATION: Images are compressed based on internal configuration settings.

  • OTHER: All other conditions, which are further described in the "Comments" column.

The Transfer Syntax is used to describe the compression mechanism applied.

Table N.5-14. Image Compression by Storage SCP

SOP Class

Behavior

Transfer Syntax

Comments

Digital Mammography X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.2.1

CONFIGU-RATION

JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])

1.2.840.10008.1.2.4.70

Video Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4.1

CONFIGURATION

JPEG Baseline (Process 1)

1.2.840.10008.1.2.4.50

All other SOP Classes

AS_IS


[Describe the mechanism by which additional SOP Classes are dynamically supported.]

[Describe storage details noted in PS3.4 Section B.4.3.2.]

N.5.2.6 Storage Commitment Service

N.5.2.6.1 SCU of the Storage Commitment SOP Class

As a Service Class User of the Storage Commitment SOP Class, the <Product> uses the N-ACTION-RQ message to request storage commitment from a remote SCP. In turn, it receives N-EVENT-REPORT-RQ messages from the SCP indicating success or failure of the request.

[Provide a list of Storage SOP Classes for which the product requests storage commitment. Also indicate whether this is configurable.]

[If Storage Commitment is provided for all supported SOP Classes, you can provide a reference to the list of supported Storage SOP Classes in Section N.1.1]

As a Service Class User of the Storage Commitment Push Model SOP Classes the product supports committing all Storage SOP Classes listed in Section N.1.1 Content and Transfer are supported.

[If Storage Commitment is provided for a subset of all supported Storage SOP Classes, provide a list of those, and delete the paragraph above.]

[Specify whether your product supports the Storage Media File Set ID and UID Attributes in the N-ACTION-Request. If this is supported, also list the Media Application profiles supported in this context.]

[Describe whether your product supports receiving the N-EVENT-REPORT request on the same Association as the N-ACTION.]

[Document the Behavior of <product> upon receiving an N-EVENT-REPORT with an Event Type ID of 1, e.g.

Upon receiving an N-EVENT-REPORT with an Event Type of 1 Instances will be removed from system after a configurable amount of time or if space is needed]

Table N.5-15 lists the behavior of <Product> for each possible Failure Reason (0008,1197) in the Failed SOP Sequence (0008,1198) upon receiving an N-EVENT-REPORT request from the SCP with an Event Type ID of 2 (Storage Commitment Request Complete - Failures Exist).

[Fill in the behavior of your product upon encountering the Status Code. Note that for each code, that is listed in the table, a behavior needs to be provided. If your system does not support specific codes, list "Code is ignored by the system".]

Table N.5-15. Failure Behavior for Storage Commitment SCU

Status Code

Description

Behavior

0110

Processing failure: A general failure in processing the operation was encountered.

The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances

0112

No such object instance: One or more of the elements in the Referenced SOP Instance Sequence was not available.

The instance is re-sent, and the N-ACTION request is repeated.

0119

Class / Instance conflict: The SOP Class of an element in the Referenced SOP Instance Sequence did not correspond to the SOP Class registered for this SOP Instance at the SCP.

Code is ignored by the system

0122

Referenced SOP Class not supported: Storage Commitment has been requested for a SOP Instance with a SOP Class that is not supported by the SCP.

The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances

0131

Duplicate Transaction UID: The Transaction UID of the Storage Commitment Request is already in use.

The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances

0213

Resource limitation: The SCP does not currently have enough resources to store the requested SOP Instance(s).

The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances


[Describe your product behavior in case the N-EVENT-REPORT request is not received after a specific time, e.g., <Product> expects to receive the N-EVENT-REPORT request in a configurable time frame after the N-ACTION is sent. If the N-EVENT-REPORT is not received within this configurable timeframe it repeats the N-ACTION-REQUEST.]

[Describe the policies for deleting instances from your product, both upon successful storage commitment as well as in failure scenarios.]

N.5.2.6.2 SCP of the Storage Commitment SOP Class

As a Service Class Provider of the Storage Commitment SOP Class, the <Product> receives the N-ACTION-RQ message to request storage commitment from a remote SCU. In turn it initiates the N-EVENT_REPORT-RQ messages to the SCU indicating success or failure of the request.

[Describe whether your product supports sending the N-EVENT-REPORT request on the same Association as the N-ACTION.]

Table N.5-16 lists conditions upon which an error code is sent in the Failure Reason (0008,1197) Attribute in the Failed SOP Sequence (0008,1198) of the N-EVEN-REPORT request.

[Fill in the conditions under which your product is sending the listed Status Codes. Note that for each code listed in the table, a condition needs to be provided. If your system does not support specific codes, list "Code is not supported"]

Table N.5-16. Failure Conditions on Storage Commitment SCP

Status Code

<