How it Works
NEMA
Loading...
C
D
M
Loading...
Loading...
DICOM
User manual
118 pgs492.58 Kb0
User manual
33 pgs195.78 Kb0
Table of contents
Loading...

NEMA DICOM User manual

Download
Page 1
PS 3.7-2004
Digital Imaging and Communications in Medicine (DICOM)
Part 7: Message Exchange
Published by
National Electrical Manufacturers Association 1300 N. 17th Street Rosslyn, Virginia 22209 USA
© Copyright 2004 by the National Electrical Manufacturers Association. All rights including translation into other languages, reserved under the Universal Copyright Convention, the Berne Convention or the Protection of Literacy and Artistic Works, and the International and Pan American Copyright Conventions.
- Standard -
Page 2
PS 3.7-2004 Page 2

NOTICE AND DISCLAIMER

The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.
NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller’s products or services by virtue of this standard or guide.
In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.
NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety–related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.
Page 3
PS 3.7-2004
Page 3

CONTENTS

NOTICE AND DISCLAIMER......................................................................................................................... 2
CONTENTS .................................................................................................................................................. 3
FOREWORD............................................................................................................................................... 10
1 Scope and field of application ................................................................................................................ 1
2 Normative references ............................................................................................................................. 1
3 Definitions ............................................................................................................................................... 2
3.1 REFERENCE MODEL DEFINITIONS....................................................................................... 2
3.2 SERVICE CONVENTIONS DEFINITIONS ............................................................................... 2
3.3 PRESENTATION SERVICE DEFINITIONS.............................................................................. 2
3.4 ACSE SERVICE DEFINITIONS ................................................................................................ 3
3.5 CMIS SERVICE DEFINITIONS................................................................................................. 3
3.6 DICOM INTRODUCTION AND OVERVIEW DEFINITIONS..................................................... 3
3.7 DICOM UPPER LAYER SERVICE DEFINITIONS ................................................................... 3
3.8 DICOM SERVICE CLASS DEFINITIONS ................................................................................. 3
3.9 DICOM DATA STRUCTURES AND ENCODING DEFINITIONS ............................................. 3
3.10 DICOM MESSAGE EXCHANGE DEFINITIONS ...................................................................... 4
4 Symbols and abbreviations ....................................................................................................................4
5 Conventions............................................................................................................................................ 5
6 Service context ....................................................................................................................................... 5
6.1 DICOM AND THE OSI BASIC REFERENCE MODEL ............................................................. 5
6.2 THE DICOM APPLICATION LAYER STRUCTURE ................................................................. 7
6.3 DICOM MESSAGE STRUCTURE AND COMMAND SET........................................................ 9
6.3.1 COMMAND SET STRUCTURE.......................................................................................... 9
7 Service overview .................................................................................................................................. 10
7.1 SERVICE TYPES .................................................................................................................... 11
7.2 DIMSE-SERVICE-USER INTERACTION ............................................................................... 12
7.3 SERVICE MODES...................................................................................................................12
7.4 ASSOCIATION SERVICES..................................................................................................... 13
7.4.1 ASSOCIATION ESTABLISHMENT .................................................................................. 13
7.4.2 ASSOCIATION RELEASE................................................................................................ 13
7.5 DIMSE SERVICES ..................................................................................................................15
7.5.1 DIMSE-C SERVICES........................................................................................................ 15
7.5.1.1 Operation services .................................................................................................. 15
7.5.2 DIMSE-N SERVICES........................................................................................................ 16
7.5.2.1 Notification service .................................................................................................. 16
7.5.2.2 Operation services .................................................................................................. 16
7.5.3 DIMSE PROCEDURES .................................................................................................... 16
7.5.3.1 Sub-operations ........................................................................................................ 17
7.5.3.2 Multiple responses .................................................................................................. 17
Page 4
PS 3.7-2004 Page 4
7.5.3.3
8 Protocol overview ................................................................................................................................. 18
8.1 DIMSE PROTOCOL ................................................................................................................ 18
8.2 ASSOCIATION PROTOCOL................................................................................................... 18
8.3 CONFORMANCE .................................................................................................................... 18
9 DIMSE-C............................................................................................................................................... 19
9.1 SERVICES............................................................................................................................... 19
9.1.1 C-STORE SERVICE ......................................................................................................... 19
9.1.1.1 C-STORE parameters............................................................................................. 19
9.1.1.2 C-STORE service procedures ................................................................................ 20
9.1.2 C-FIND SERVICE ............................................................................................................. 21
9.1.2.1 C-FIND Parameters ................................................................................................ 21
9.1.2.2 C-FIND service procedures .................................................................................... 22
9.1.3 C-GET SERVICE .............................................................................................................. 23
9.1.3.1 C-GET parameters .................................................................................................. 23
9.1.3.2 C-GET service procedures...................................................................................... 25
9.1.4 C-MOVE SERVICE........................................................................................................... 26
9.1.4.1 C-MOVE parameters............................................................................................... 26
Cancellation............................................................................................................. 17
9.1.1.1.1 Message ID .............................................................................................. 19
9.1.1.1.2 Message ID being responded to .............................................................. 19
9.1.1.1.3 Affected SOP class UID ........................................................................... 19
9.1.1.1.4 Affected SOP instance UID...................................................................... 20
9.1.1.1.5 Priority ...................................................................................................... 20
9.1.1.1.6 Move originator application entity title...................................................... 20
9.1.1.1.7 Move originator message ID .................................................................... 20
9.1.1.1.8 Data set .................................................................................................... 20
9.1.1.1.9 Status ....................................................................................................... 20
9.1.2.1.1 Message ID .............................................................................................. 21
9.1.2.1.2 Message ID being responded to .............................................................. 21
9.1.2.1.3 Affected SOP class UID ........................................................................... 21
9.1.2.1.4 Priority ...................................................................................................... 22
9.1.2.1.5 Identifier.................................................................................................... 22
9.1.3.1.1 Message ID .............................................................................................. 24
9.1.3.1.2 Message ID being responded to .............................................................. 24
9.1.3.1.3 Affected SOP class UID ........................................................................... 24
9.1.3.1.4 Priority ...................................................................................................... 24
9.1.3.1.5 Identifier.................................................................................................... 24
9.1.3.1.6 Status ....................................................................................................... 24
9.1.3.1.7 Number of remaining sub-operations ...................................................... 25
9.1.3.1.8 Number of completed sub-operations...................................................... 25
9.1.3.1.9 Number of failed sub-operations.............................................................. 25
9.1.3.1.10 Number of warning sub-operations........................................................ 25
9.1.4.1.1 Message ID .............................................................................................. 27
9.1.4.1.2 Message ID being responded to .............................................................. 27
9.1.4.1.3 Affected SOP class UID ........................................................................... 27
9.1.4.1.4 Priority ...................................................................................................... 27
9.1.4.1.5 Move destination ...................................................................................... 27
9.1.4.1.6 Identifier.................................................................................................... 27
9.1.4.1.7 Status ....................................................................................................... 28
9.1.4.1.8 Number of remaining sub-operations ...................................................... 28
9.1.4.1.9 Number of completed sub-operations...................................................... 28
9.1.4.1.10 Number of failed sub-operations............................................................ 28
Page 5
PS 3.7-2004
Page 5
9.1.4.1.11
9.1.4.2 C-MOVE service procedures .................................................................................. 28
9.1.5 C-ECHO SERVICE ........................................................................................................... 30
9.1.5.1 C-ECHO parameters............................................................................................... 30
9.1.5.1.1 Message ID .............................................................................................. 30
9.1.5.1.2 Message ID being responded to .............................................................. 30
9.1.5.1.3 Affected SOP class UID ........................................................................... 30
9.1.5.1.4 Status ...................................................................................................... 30
9.1.5.2 C-ECHO service procedures .................................................................................. 30
9.2 SEQUENCING ........................................................................................................................ 31
9.2.1 TYPES OF SERVICES ..................................................................................................... 31
9.2.2 USAGE RESTRICTIONS.................................................................................................. 31
9.2.3 DISRUPTED PROCEDURES........................................................................................... 31
9.2.4 DISRUPTING PROCEDURES .........................................................................................31
9.3 PROTOCOL ............................................................................................................................ 31
9.3.1 C-STORE PROTOCOL..................................................................................................... 31
9.3.1.1 C-STORE-RQ.......................................................................................................... 31
9.3.1.2 C-STORE-RSP........................................................................................................ 32
9.3.1.3 C-STORE protocol procedures ............................................................................... 33
9.3.2 C-FIND PROTOCOL......................................................................................................... 33
9.3.2.1 C-FIND-RQ.............................................................................................................. 33
9.3.2.2 C-FIND-RSP............................................................................................................ 34
9.3.2.3 C-CANCEL-FIND-RQ.............................................................................................. 35
9.3.2.4 C-FIND protocol procedures ................................................................................... 35
9.3.3 C-GET PROTOCOL.......................................................................................................... 36
9.3.3.1 C-GET-RQ............................................................................................................... 36
9.3.3.2 C-GET-RSP............................................................................................................. 37
9.3.3.3 C-CANCEL-GET-RQ............................................................................................... 38
9.3.3.4 C-GET protocol procedures .................................................................................... 38
9.3.4 C-MOVE PROTOCOL ...................................................................................................... 40
9.3.4.1 C-MOVE-RQ ........................................................................................................... 40
9.3.4.2 C-MOVE-RSP ......................................................................................................... 40
9.3.4.3 C-CANCEL-MOVE-RQ ...........................................................................................41
9.3.4.4 C-MOVE Protocol Procedures ................................................................................ 42
9.3.5 C-ECHO PROTOCOL....................................................................................................... 43
9.3.5.1 C-ECHO-RQ............................................................................................................ 43
9.3.5.2 C-ECHO-RSP.......................................................................................................... 44
9.3.5.3 C-ECHO protocol procedures ................................................................................. 44
10 DIMSE-N ................................................................................................................................................ 45
10.1 SERVICES............................................................................................................................... 45
10.1.1 N-EVENT-REPORT SERVICE ......................................................................................... 45
10.1.1.1 N-EVENT-REPORT parameters............................................................................ 45
10.1.1.1.1 Message ID ............................................................................................ 45
10.1.1.1.2 Message ID being responded to ............................................................ 45
10.1.1.1.3 Affected SOP class UID ......................................................................... 45
10.1.1.1.4 Affected SOP instance UID.................................................................... 45
10.1.1.1.5 Event type ID.......................................................................................... 46
10.1.1.1.6 Event information ................................................................................... 46
10.1.1.1.7 Event reply .............................................................................................46
10.1.1.1.8 Status ..................................................................................................... 46
10.1.1.2 N-EVENT-REPORT service procedures................................................................ 46
10.1.2 N-GET Service .................................................................................................................. 47
10.1.2.1 N-GET Parameters ................................................................................................. 47
Number of warning sub-operations........................................................ 28
Page 6
PS 3.7-2004 Page 6
10.1.2.1.1
10.1.2.1.2 Message ID being responded to ........................................................... 48
10.1.2.1.3 Requested SOP class UID.................................................................... 48
10.1.2.1.4 Requested SOP instance UID ..............................................................48
10.1.2.1.5 Attribute identifier list.............................................................................. 48
10.1.2.1.6 Affected SOP class UID ........................................................................ 48
10.1.2.1.7 Affected SOP instance UID................................................................... 48
10.1.2.1.8 Attribute list............................................................................................. 48
10.1.2.1.9 Status ..................................................................................................... 48
10.1.2.2 N-GET service procedures...................................................................................... 49
10.1.3 N-SET SERVICE............................................................................................................... 49
10.1.3.1 N-SET parameters .................................................................................................. 49
10.1.3.1.1 Message ID ............................................................................................ 49
10.1.3.1.2 Message ID being responded to ............................................................ 50
10.1.3.1.3 Requested SOP class UID..................................................................... 50
10.1.3.1.4 Requested SOP instance UID ............................................................... 50
10.1.3.1.5 Modification list....................................................................................... 50
10.1.3.1.6 Attribute list............................................................................................. 50
10.1.3.1.7 Affected SOP class UID ......................................................................... 50
10.1.3.1.8 Affected SOP instance UID.................................................................... 50
10.1.3.1.9 Status ..................................................................................................... 50
10.1.3.2 N-SET service procedures...................................................................................... 51
10.1.4 N-ACTION SERVICE........................................................................................................ 51
10.1.4.1 N-ACTION parameters............................................................................................ 51
10.1.4.1.1 Message ID ............................................................................................ 52
10.1.4.1.2 Message ID being responded to ........................................................... 52
10.1.4.1.3 Requested SOP class UID..................................................................... 52
10.1.4.1.4 Requested SOP instance UID .............................................................. 52
10.1.4.1.5 Action type ID........................................................................................ 52
10.1.4.1.6 Action information .................................................................................. 52
10.1.4.1.7 Affected SOP class UID ......................................................................... 52
10.1.4.1.8 Affected SOP instance UID.................................................................... 52
10.1.4.1.9 Action reply............................................................................................. 53
10.1.4.1.10 Status..................................................................................................... 53
10.1.4.2 N-ACTION service procedures ............................................................................... 53
10.1.5 N-CREATE SERVICE....................................................................................................... 54
10.1.5.1 N-CREATE parameters.......................................................................................... 54
10.1.5.1.1 Message ID ............................................................................................ 54
10.1.5.1.2 Message ID being responded to ........................................................... 54
10.1.5.1.3 Affected SOP class UID ......................................................................... 54
10.1.5.1.4 Affected SOP instance UID.................................................................... 55
10.1.5.1.5 Attribute list............................................................................................. 55
10.1.5.1.6 Status ..................................................................................................... 55
10.1.5.2 N-CREATE service procedures ..............................................................................55
10.1.6 N-DELETE SERVICE ....................................................................................................... 56
10.1.6.1 N-DELETE parameters ........................................................................................... 56
10.1.6.1.1 Message ID ............................................................................................ 56
10.1.6.1.2 Message ID being responded to ............................................................ 57
10.1.6.1.3 Requested SOP class UID..................................................................... 57
10.1.6.1.4 Requested SOP instance UID ............................................................... 57
10.1.6.1.5 Affected SOP class UID ......................................................................... 57
10.1.6.1.6 Affected SOP instance UID.................................................................... 57
10.1.6.1.7 Status ..................................................................................................... 57
10.1.6.2 N-DELETE service procedures............................................................................... 57
Message ID ............................................................................................ 47
Page 7
PS 3.7-2004
Page 7
10.2
SEQUENCING ........................................................................................................................ 58
10.2.1 TYPES OF SERVICES ..................................................................................................... 58
10.2.2 USAGE RESTRICTIONS.................................................................................................. 58
10.2.3 DISRUPTED PROCEDURES........................................................................................... 58
10.2.4 DISRUPTING PROCEDURES .........................................................................................58
10.3 PROTOCOL ............................................................................................................................ 58
10.3.1 N-EVENT-REPORT PROTOCOL..................................................................................... 58
10.3.1.1 N-EVENT-REPORT-RQ.......................................................................................... 58
10.3.1.2 N-EVENT-REPORT-RSP........................................................................................ 59
10.3.1.3 N-EVENT-REPORT protocol procedures ............................................................... 60
10.3.2 N-GET PROTOCOL.......................................................................................................... 61
10.3.2.1 N-GET-RQ............................................................................................................... 61
10.3.2.2 N-GET-RSP............................................................................................................. 61
10.3.2.3 N-GET protocol procedures .................................................................................... 62
10.3.3 N-SET PROTOCOL .......................................................................................................... 62
10.3.3.1 N-SET-RQ ............................................................................................................... 62
10.3.3.2 N-SET-RSP ............................................................................................................. 63
10.3.3.3 N-SET protocol procedures..................................................................................... 64
10.3.4 N-ACTION PROTOCOL ................................................................................................... 65
10.3.4.1 N-ACTION-RQ ........................................................................................................ 65
10.3.4.2 N-ACTION-RSP ...................................................................................................... 66
10.3.4.3 N-ACTION protocol procedures.............................................................................. 66
10.3.5 N-CREATE PROTOCOL .................................................................................................. 67
10.3.5.1 N-CREATE-RQ ....................................................................................................... 67
10.3.5.2 N-CREATE-RSP ..................................................................................................... 68
10.3.5.3 N-CREATE protocol procedures............................................................................. 69
10.3.6 N-DELETE PROTOCOL ................................................................................................... 69
10.3.6.1 N-DELETE-RQ ........................................................................................................ 69
10.3.6.2 N-DELETE-RSP ...................................................................................................... 70
10.3.6.3 N-DELETE protocol procedures ............................................................................. 71
Annex A Application Context Usage (Normative) .................................................................................. 72
A.1 APPLICATION CONTEXT DEFINITION ................................................................................. 72
A.2 DICOM APPLICATION CONTEXT NAME ENCODING AND REGISTRATION .................... 72
A.2.1 DICOM Registered Application Context Names ............................................................... 72
A.2.2 Privately defined application context names..................................................................... 72
A.3 ASSOCIATION INITIALIZATION FOR DICOM APPLICATION ENTITY ...................................... 73
A.4 OPERATION/NOTIFICATION FOR DICOM APPLICATION ENTITY........................................... 73
A.5 ASSOCIATION RELEASE FOR DICOM AE ................................................................................. 73
A.6 ASSOCIATION ABORT FOR DICOM AE...................................................................................... 73
Annex B Index to Application Context Name UIDs (Informative)........................................................... 75
Annex C Status Type Encoding (Normative) ......................................................................................... 76
C.1 SUCCESS STATUS CLASS................................................................................................... 76
C.1.1 Success ................................................................................................................................ 76
C.2 PENDING STATUS CLASS.................................................................................................... 76
C.2.1 Pending ................................................................................................................................ 76
C.3 CANCEL STATUS CLASS...................................................................................................... 76
C.3.1 Cancel .................................................................................................................................. 76
C.4 WARNING STATUS CLASS................................................................................................... 77
C.4.1 Warning............................................................................................................................. 77
Page 8
PS 3.7-2004 Page 8
C.4.2
Attribute list error............................................................................................................... 77
C.4.3 Attribute Value Out of Range ............................................................................................ 77
C.5 FAILURE STATUS CLASS ..................................................................................................... 77
C.5.1 Error: cannot understand .................................................................................................. 77
C.5.2 Error: Data Set does not match SOP class ...................................................................... 78
C.5.3 Failed ................................................................................................................................ 78
C.5.4 Refused: move destination unknown................................................................................ 78
C.5.5 Refused: out of resources................................................................................................. 78
C.5.6 Refused: SOP class not supported................................................................................... 79
C.5.7 Class-instance conflict ...................................................................................................... 79
C.5.8 Duplicate SOP instance .................................................................................................... 79
C.5.9 Duplicate invocation.......................................................................................................... 79
C.5.10 Invalid argument value...................................................................................................... 79
C.5.11 Invalid attribute value ........................................................................................................ 80
C.5.12 Invalid object instance....................................................................................................... 80
C.5.13 Missing attribute................................................................................................................ 80
C.5.14 Missing attribute value ...................................................................................................... 80
C.5.15 Mistyped argument ........................................................................................................... 81
C.5.16 No such argument............................................................................................................. 81
C.5.17 No such attribute...............................................................................................................81
C.5.18 No such event type ........................................................................................................... 81
C.5.19 No Such object instance ................................................................................................... 82
C.5.20 No Such SOP class .......................................................................................................... 82
C.5.21 Processing failure .............................................................................................................82
C.5.22 Resource limitation ........................................................................................................... 82
C.5.23 Unrecognized operation.................................................................................................... 82
C.5.24 No such action type .......................................................................................................... 82
Annex D Association Negotiation (Normative) ....................................................................................... 84
D.1 ABSTRACT SYNTAX.............................................................................................................. 84
D.1.1 Service-object pair class UID............................................................................................ 84
D.1.2 Meta service-object pair group UID .................................................................................. 85
D.2 TRANSFER SYNTAXES......................................................................................................... 86
D.3 ASSOCIATION ESTABLISHMENT......................................................................................... 86
D.3.1 Application context ............................................................................................................ 86
D.3.2 Presentation contexts negotiation..................................................................................... 87
D.3.3 DICOM application association information...................................................................... 88
D.3.3.1 MAXIMUM LENGTH APPLICATION PDU NOTIFICATION ................................... 89
D.3.3.2 IMPLEMENTATION IDENTIFICATION NOTIFICATION ........................................ 89
D.3.3.2.1 Implementation class UID sub-item structure (A-ASSOCIATE-RQ) ...... 90
D.3.3.2.2 Implementation class UID sub-item structure (A-ASSOCIATE-AC) ...... 91
D.3.3.2.3 Implementation version name structure (A-ASSOCIATE-RQ)............... 92
D.3.3.2.4 Implementation version name structure (A-ASSOCIATE-AC) ................ 92
D.3.3.3 ASYNCHRONOUS OPERATIONS (AND SUB-OPERATIONS) WINDOW
NEGOTIATION........................................................................................................................ 93
D.3.3.3.1 Asynchronous operations window sub-item structure(A-ASSOCIATE-RQ)95 D.3.3.3.2 Asynchronous operations window sub-item structure(A-ASSOCIATE-AC)95
D.3.3.4 SCP/SCU ROLE SELECTION NEGOTIATION ...................................................... 96
D.3.3.4.1 SCP/SCU role selection sub-item structure (A-ASSOCIATE-RQ)......... 97
D.3.3.4.2 SCP/SCU role selection sub-item structure (A-ASSOCIATE-AC) ......... 98
D.3.3.5 SERVICE-OBJECT PAIR (SOP) CLASS EXTENDED NEGOTIATION ................. 99
D.3.3.5.1 SOP class extended negotiation sub-item structure(A-ASSOCIATE-RQ)100 D.3.3.5.2 SOP class extended negotiation sub-item structure(A-ASSOCIATE-AC)100
Page 9
PS 3.7-2004
Page 9
D.3.3.6
NEGOTIATION...................................................................................................................... 101
Annex E Command Dictionary (Normative) ......................................................................................... 103
E.1 REGISTRY OF DICOM COMMAND ELEMENTS ................................................................ 103
E.2 RETIRED COMMAND FIELDS ............................................................................................. 105
Annex F Usage of the P-DATA service by the DICOM Application Entity (Normative)....................... 107
Annex G Command Element Cross Reference (Informative) .............................................................. 108
SERVICE-OBJECT PAIR (SOP) CLASS COMMON EXTENDED
D.3.3.6.1 SOP class common extended negotiation sub-item structure (A-ASSOCIATE­RQ) 101
Page 10
PS 3.7-2004 Page 10

FOREWORD

The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee to develop a standard for Digital Imaging and Communications in Medicine (DICOM). This DICOM Standard was developed according to the NEMA procedures.
This Standard is developed in liaison with other standardization organizations including CEN TC251 in Europe and JIRA in Japan, with review also by other organizations including IEEE, HL7 and ANSI in the USA.
The DICOM Standard is structured as a multi-part document using the guidelines established in the following document:
ISO/IEC Directives, 1989 Part 3 : Drafting and Presentation of International Standards.
This document is one part of the DICOM Standard which consists of the following parts:
PS 3.1: Introduction and Overview PS 3.2: Conformance PS 3.3: Information Object Definitions PS 3.4: Service Class Specifications PS 3.5: Data Structures and Encoding PS 3.6: Data Dictionary PS 3.7: Message Exchange PS 3.8: Network Communication Support for Message Exchange PS 3.9: Retired PS 3.10: Media Storage and File Format for Media Interchange PS 3.11: Media Storage Application Profiles PS 3.12: Media Format and Physical Media for Media Interchange PS 3.13: Retired PS 3.14: Grayscale Standard Display Function PS 3.15: Security and System Management Profiles PS 3.16: Content Mapping Resource PS 3.17: Explanatory Information PS 3.18: Web Access to DICOM Persistent Objects (WADO)
These parts are related but independent documents. Their development level and approval status may differ. Additional parts may be added to this multi-part Standard. PS 3.1 should be used as the base reference for the current parts of this Standard.
Page 11
PS 3.7-2004
Page 1

1 Scope and field of application

This Part of the DICOM Standard specifies the DICOM Message Service Element (DIMSE). The DIMSE defines an Application Service Element (both the service and protocol) used by peer DICOM Application Entities for the purpose of exchanging medical images and related information.
The DIMSE provides its services by relying on the DIMSE protocol. The DIMSE protocol defines the encoding rules necessary to construct Messages. A Message is composed of a Command Set (defined in this part of the DICOM Standard) followed by a conditional Data Set (defined in PS 3.5).
This Part specifies:
a set of service primitives provided by the DIMSE Application Service Element
the parameters which are passed in each service primitive
any necessary information for the semantic description of each service primitive
the procedures applicable to the service primitives
the Abstract Syntax of the DICOM composite and normalized command protocol and the
associated encoding rules to be applied
procedures for the correct interpretation of protocol control information
the conformance requirements to be met by implementation of this part of the Standard
the Application Context required for DICOM Application Entities
the Association requirements of DICOM Application Entities
the Application Association Information for DICOM Application Entities
This Part is related to other parts of the DICOM Standard in that:
PS 3.3, Information Object Definitions, specifies the set of Information Object Definitions to
which the services defined in this part may be applied
PS 3.5, Data Structure and Encoding, addresses the encoding rules necessary to construct a
conditional Data Set which is conveyed in a Message as specified in this part
This Part defines the protocols and services required to accomplish the Service Classes
described in PS 3.4

2 Normative references

The following Standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All Standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the Standards indicated below.
ISO/IEC Directives, 1989 Part 3 - Drafting and presentation of International Standards
ISO 7498-1, Information Processing Systems - Open Systems Interconnection - Basic Reference Model
ISO/TR 8509, Information Processing Systems - Open Systems Interconnection - Service Conventions
Page 12
PS 3.7-2004 Page 2
ISO 8649, Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element
ISO 8822, Information Processing Systems - Open Systems Interconnection - Connection-Oriented Presentation Service Definition
ISO/IEC 9595:1991, Information Technology - Open Systems Interconnection - Common Management Information Service Definition
ISO/IEC 9834-3, Information Processing Systems - Open Systems Interconnection - Part 3: Procedures for the Assignment of Object Identifier Component Values for Joint OSI-CCITT Use

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 REFERENCE MODEL DEFINITIONS

This part of the Standard is based on the concepts developed in ISO 7498-1 and makes use of the following terms defined in it:
a) Application Entity b) Application Process c) Protocol or Layer Protocol d) Protocol Data Unit or Layer Protocol Data Unit e) Service or Layer Service f) Transfer Syntax

3.2 SERVICE CONVENTIONS DEFINITIONS

This part of the Standard makes use of the following terms defined in ISO/TR 8509:
a) Service Provider b) Service User c) Confirmed Service d) Non-confirmed Service e) Primitive f) Request (Primitive) g) Indication (Primitive) h) Response (Primitive) i) Confirm (Primitive)

3.3 PRESENTATION SERVICE DEFINITIONS

This part of the Standard makes use of the following terms defined in ISO 8822:
a) Abstract Syntax b) Abstract Syntax Name
Page 13
c) Presentation Context d) Presentation Data Values

3.4 ACSE SERVICE DEFINITIONS

This part of the Standard makes use of the following terms defined in ISO 8649:
a) Association or Application Association b) Application Context c) Association Control Service Element d) Association Initiator

3.5 CMIS SERVICE DEFINITIONS

This part of the Standard makes use of the following terms defined in ISO 9595:
a) Functional Unit b) Kernel Functional Unit

3.6 DICOM INTRODUCTION AND OVERVIEW DEFINITIONS

PS 3.7-2004
Page 3
This part of the Standard makes use of the following terms defined in PS 3.1:
a) Attribute b) Command c) Command Stream d) Data Stream e) Message

3.7 DICOM UPPER LAYER SERVICE DEFINITIONS

This part of the Standard makes use of the following terms defined in PS 3.8:
a) Unique Identifier (UID) b) DICOM Upper Layer

3.8 DICOM SERVICE CLASS DEFINITIONS

This part of the Standard makes use of the following terms defined in PS 3.4:
a) Service Class b) Service Class User (SCU) c) Service Class Provider (SCP) d) Service-Object Pair (SOP) Class e) Service-Object Pair (SOP) Instance f) Related General SOP Class

3.9 DICOM DATA STRUCTURES AND ENCODING DEFINITIONS

This part of the Standard makes use of the following terms defined in PS 3.5:
Page 14
PS 3.7-2004 Page 4
a) Data Element b) Data Set

3.10 DICOM MESSAGE EXCHANGE DEFINITIONS

The following definitions are commonly used in this part of the Standard:
DICOM message service element (DIMSE): the particular Application Service Element defined in this Part of the DICOM Standard.
DIMSE-C services: A subset of the DIMSE services which supports operations on Composite SOP Instances related to composite Information Object Definitions with peer DIMSE-service-users.
DIMSE-N services: a subset of the DIMSE services which supports operations and notifications on Normalized SOP Instances related to Normalized Information Object Definitions with peer DIMSE­service-users.
DIMSE-service-provider: an abstraction of the totality of those entities which provide DIMSE services to peer DIMSE-service-users.
DIMSE-service-user: that part of an application entity which makes use of the DICOM Message Service Element.
Invoking DIMSE-service-user: the DIMSE-service-user that invokes a DIMSE operation or notification.
Performing DIMSE-service-user: the DIMSE-service-user that performs a DIMSE operation or
notification invoked by a peer DIMSE-service-user.

4 Symbols and abbreviations

The following symbols and abbreviations are used in this part of the Standard.
ACR American College of Radiology
ACSE Association Control Service Element
ASCII American Standard Code for Information Interchange
AE Application Entity
ANSI American National Standards Institute
CEN TC251 Comite Europeen de Normalisation - Technical Committee 251 - Medical
Informatics
CMIS Common Management Information Service
CMISE Common Management Information Service Element
DICOM Digital Imaging and Communications in Medicine
DIMSE DICOM Message Service Element
DIMSE-C DICOM Message Service Element - Composite
DIMSE-N DICOM Message Service Element - Normalized
HL7 Health Level 7
IEEE Institute of Electrical and Electronics Engineers
ISO International Standards Organization
Page 15
PS 3.7-2004
Page 5
JIRA Japan Industries Association of Radiation Apparatus
NEMA National Electrical Manufacturers Association
OSI Open Systems Interconnection
PDU Protocol Data Unit
PDV Protocol Data Value
SOP Service-Object Pair
TCP/IP Transmission Control Protocol/Internet Protocol
VM Value Multiplicity
VR Value Representation
UID Unique Identifier
UL Upper Layers

5 Conventions

The following conventions are used for the service description tables shown in this part of the Standard.
(=) The value of the parameter is equal to the value of the parameter in the column to the left.
Not applicable
C The parameter is conditional. The condition(s) are defined by the text which describes the parameter.
M Mandatory usage
MF Mandatory with a fixed value
U The use of this parameter is a DIMSE-service-user option
UF User Option with a fixed value

6 Service context

This section defines the DICOM Message Service Element and Protocol within the context of the DICOM Application Entity. Specifically, this section provides a model to clarify a number of concepts for digital imaging and communications and introduces key terms used throughout the Standard. This model has been used to partition the Application Layer of the DICOM Standard into separate parts.

6.1 DICOM AND THE OSI BASIC REFERENCE MODEL

The OSI Basic Reference Model is used to model the interconnection of medical imaging equipment. As shown in Figure 6.1-1 seven layers of communication protocols are distinguished. DICOM uses the OSI Upper Layer Service to separate the exchange of DICOM Messages at the Application Layer from the communication support provided by the lower layers.
This OSI Upper Layer Service boundary allows peer Application Entities to establish Associations, transfer Messages and terminate Associations. For this boundary, DICOM has adopted the OSI
Page 16
PS 3.7-2004 Page 6
Standards (Presentation Service augmented by the Association Control Service Element). It is a simple service that isolates the DICOM Application Layer from the specific stack of protocols used in the communication support layers.
The DICOM Upper Layer protocol augments TCP/IP. It combines the OSI upper layer protocols into a simple-to-implement single protocol while providing the same services and functions offered by the OSI stack
The DICOM Upper Layer Service is defined in PS 3.8.
Medical Imaging Application
Upper
Layer
Service
Bound ary
DICOM Application Message Exchange
DICOM
Upper Layer
Protocol
for
TCP/IP
TCP/IP
TCP/IP
Network
Figure 6.1-1
DICOM Network Protocol Architecture
Page 17
PS 3.7-2004
Page 7

6.2 THE DICOM APPLICATION LAYER STRUCTURE

A DICOM Application Entity and the Service Elements it includes are shown in Figure 6.2-1.
Note: Annexes of this part define certain aspects of the DICOM Application Entity.
The heart of any DICOM Application Entity is specified by the following parts of the DICOM Standard:
PS 3.3, Information Object Definitions, which provides data models and Attributes used as a
basis for defining SOP Instances which are operated upon by the services defined in this [art. Such SOP Instances are used to represent real-world occurrences of images, studies, patients, etc.
PS 3.4, Service Class Specifications, which defines the set of operations that can be
performed on SOP Instances. Such operations may include the storage, retrieval of information, printing, etc.
PS 3.5, Data Structure and Encoding, which addresses the encoding of the Data Sets
exchanged to accomplish the above services
PS 3.6, Data Dictionary, which contains the registry of DICOM Data Elements used to
represent Attributes of SOP Classes
The DICOM Application Entity uses the Association and Presentation data services of the OSI Upper Layer Service defined in PS 3.8. The Association Control Service Element (ACSE) augments the Presentation Layer Service with Association establishment and termination services. In the case of TCP/IP, the full equivalent of ACSE is provided by the DICOM Upper Layer Service. For the DICOM point-to-point stack, a minimum subset of ACSE is provided by the Session/Transport/Network Service.
The DICOM Application Entity uses the services provided by the DICOM Message Service Element. The DICOM Message Service Element specifies two sets of services.
DIMSE-C supports operations associated with composite SOP Classes and provides effective
compatibility with the previous versions of the DICOM Standard.
DIMSE-N supports operations associated with normalized SOP Classes and provides an
extended set of object-oriented operations and notifications. It is based on the OSI System Management Model and more specifically on the OSI Common Management Information Services (CMIS) Service definition.
Page 18
PS 3.7-2004
(
)
Page 8
DICOM Application Entity
Service Classes
Association
Negotiation
- Study Mgt
- Patient Image Mgt
- Results Mgt
- Storage
- Print
- Query/Retrieve
Information Objects
Normalized
- Patient
- Study
- Visit
Composite
- CT image
- MR image
- CR image
DICOM Message Service Element
DIMSE
(DIMSE-C and DIMSE-N Operations and Notifications)
Part 4
Part 3
Part 7
Upper Layer Association
Services (1)
Upper Layer Presentation Data Service
(see figure 6.1-1)
(1) This figure expands upon figure 6.1-1 by showing that the Association
Services specified in Part 8 are formally part of the Application Entity.
Figure 6.2-1
DICOM APPLICATION LAYER STRUCTURE
Part 8 and Part 9
Page 19
PS 3.7-2004
Page 9
The DIMSE-C and DIMSE-N services are supported by a single DIMSE protocol which uses the DICOM­specific Message formatting and encoding.

6.3 DICOM MESSAGE STRUCTURE AND COMMAND SET

Information is communicated across the DICOM network interface in a DICOM Message. A Message is composed of a Command Set followed by a conditional Data Set (see PS 3.5 for the definition of a Data Set). The Command Set is used to indicate the operations/notifications to be performed on or with the Data Set.
A Command Set is constructed of Command Elements. Command Elements contain the encoded values for each individual field of the Command Set per the semantics specified in the DIMSE protocol (see Section 9.2 and 10.2). Each Command Element is composed of an explicit Tag, a Value Length, and a Value Field.
The overall structure of a DICOM Message is shown in Figure 6.3-1.
DICOM Message
Command Set
(defined in Part 5)
Command Element
Tag Length Value
Figure 6.3-1
DICOM MESSAGE STRUCTURE

6.3.1 COMMAND SET STRUCTURE

The Command Elements in a Command Set shall be ordered by increasing Command Element Tag number. A Command Element Tag uniquely identifies a Command Element and shall occur at most once in a Command Set. The encoding of the Command Set shall be Little Endian Byte Ordering as defined in PS 3.5. The requirements for the existence of a Command Element in a Command Set is defined in the DIMSE protocol.
Data Set
Notes: 1. The use of Private Command Elements has been retired in this version of the DICOM Standard.
2. The encoding corresponds to the Implicit VR Data Element encoding defined in PS 3.5.
Page 20
PS 3.7-2004 Page 10
A Command Element is composed of three fields; a Command Element Tag, a Value Length, and a Value Field.
Command Element Tag: An ordered pair of 16-bit unsigned integers representing the Group Number followed by Element Number.
Value Length: A 32-bit unsigned integer representing the explicit Length as the number of bytes
(even) that make up the Value. It does not include the length of the Command Element Tag or Value Length fields.
Value Field: An even number of bytes containing the Value(s) of the Command Element.
The command type of Value(s) stored in this field is specified by the Command Element's Value Representation (VR). The VR for a given Command Element can be determined using the Command Dictionary in Annex E. The VR of Command Elements shall agree with those specified in the Command Dictionary. The VR definitions are defined in PS 3.5
The Value Multiplicity (VM) specifies how many Values with the VR can be placed in the Value Field. If the VM is greater than one, multiple Values shall be delimited within the Value Field as defined in PS 3.5. The VM for a given Command Element can be determined using the Command Dictionary in Annex E.
Notes: 1. The Message Length-to-End (0000,0001) Command Element is retired. Implementations may choose
to send it for backward compatibility reasons. DICOM V3.0 comformant implementations must not rely on its presence for their operation.
2. The delimitation of the Message length is actually achieved by relying on the fact that the Presentation Data Value (conveying each Message fragment) is delimited as defined by the OSI Upper Layer Service and the associated Message Control Header (see PS 3.5). This results from the fact that the DICOM V3.0 UL protocol or the OSI Presentation protocol explicitly conveys the length of a PDV.

7 Service overview

The DICOM Message Service Element supports communication between peer DIMSE-service-users. A DIMSE-service-user acts in one of two roles:
a) invoking DIMSE-service-user b) performing DIMSE-service-user
DIMSE-service-users make use of service primitives which are provided by the DIMSE-service-provider. The DIMSE-service-provider is an abstraction of the totality of those entities which provide DIMSE services to peer DIMSE-service-users. A service primitive shall be one of the following types:
a) request primitive b) indication primitive c) response primitive d) confirmation primitive
These primitives (which are shown in Figure 7-1) are used as follows to successfully complete a DIMSE service:
Page 21
PS 3.7-2004
Page 11
The invoking DIMSE-service-user issues a request primitive to the DIMSE-service-provider.
The DIMSE-service-provider receives the request primitive from the invoking DIMSE-service-
user and issues an indication primitive to the performing DIMSE-service-user.
The performing DIMSE-service-user receives the indication primitive from the DIMSE-service-
provider and performs the requested service.
The performing DIMSE-service-user issues a response primitive to the DIMSE-service-
provider.
The DIMSE-service-provider receives the response primitive from the performing DIMSE-
service-user and issues a confirmation primitive to the invoking DIMSE-service-user.
The invoking DIMSE-service-user receives the confirmation primitive from the DIMSE-service-
provider completing the DIMSE service.

7.1 SERVICE TYPES

DIMSE provides two types of information transfer services which are used by DICOM Application Entities:
a) a notification service b) an operation service
R
e
q
u
e
s
t
P
r
i
m
i
t
i
v
e
(
()
e
v
i
t
i
m
i
r
P
m
r
i
f
n
o
C
Invoking
DIMSE-Service-User
DIMSE SERVICE PRIMITIVES
Notification services enable one DICOM Application Entity to notify another about the occurrence of an event or change of state. The definition of the notification and the consequent behavior of the Application Entities is dependent upon the Service Class and Information Object Definitions. See PS 3.3 and PS 3.4.
Message
Command Request
and Associated Data
Message
Command Response
and Associated Data
DIMSE-
Service-Provider
Figure 7-1
)
I
n
d
i
c
a
t
i
o
n
P
r
i
m
r
P
e
s
n
o
p
s
e
R
Performing
DIMSE-Service-User
i
t
i
v
e
e
v
i
t
i
m
i
Operation services enable one DICOM Application Entity to explicitly request an operation to be performed upon a SOP Instance managed by another DICOM Application Entity.
Page 22
PS 3.7-2004 Page 12

7.2 DIMSE-SERVICE-USER INTERACTION

The DICOM Message Service Element receives notification and operation requests and their related information from the DIMSE-service-user. Two DICOM Application Entities take the roles as peer DIMSE­service-users in order to exchange notifications and operations.
A notification or operation is implemented as a request/response interaction carried out within the context of an established application Association. Typically, one DIMSE-service-user requests that a particular operation be performed (or notification be processed) and the other DIMSE-service-user attempts to perform the operation (or process the notification) and then reports the outcome of the attempt.
When engaging in the operations or notifications, the DIMSE-service-user takes on one of two roles:
a) it performs operations (on SOP Instances for which it has responsibility) which were invoked
by a peer DIMSE-service-user. It may also emit change-of-state notifications for SOP Instances to one or more peer DIMSE-service-users. These notifications may be invoked as a result of operations initiated by other DIMSE-service-users.
b) it invokes the performance of an operation on a peer DIMSE-service-user. It may also receive
notifications from a peer DIMSE-service-user.
These roles are depicted in Figure 7.2-1.
Notes: 1. Role a) (called the Agent role in ISO terminology) is used by an implementation which conforms to a
DICOM Service Class as an SCP.
2. Role b) (called the Manager role in ISO terminology) is used by an implementation which conforms to a DICOM Service Class as an SCU
Invoking
DIMSE-Service-User
DIMSE-Service-User
(Role b)
Performing
DIMSE-Service-User
OPERATION AND NOTIFICATION FLOW

7.3 SERVICE MODES

.
Operation
Notification
Figure 7.2-1
Performing
DIMSE-Service-User
DIMSE-Service-User
(Role a)
Invoking
DIMSE-Service-User
Operations and notifications, on an Association, are used in one of the following two modes:
a) synchronous b) asynchronous
Page 23
PS 3.7-2004
Page 13
In the synchronous mode, the invoking DIMSE-service-user, on an established Association, requires a response from the performing DIMSE-service-user before invoking another operation or notification.
In the asynchronous mode, the invoking DIMSE-service-user, on an established Association, may continue to invoke further operations or notifications to the performing DIMSE-service-user without awaiting a response.
The mode selection (synchronous or asynchronous) is determined at Association establishment time. The synchronous mode serves as the default mode and shall be supported by all DIMSE-service-users. The asynchronous mode is optional and the maximum number of outstanding operations/notifications is negotiated during Association establishment. This negotiation is accomplished by Application Association Information as defined in Annex D.

7.4 ASSOCIATION SERVICES

The DICOM Message Service Element does not provide separate services for the establishment and termination of application Associations. This section provides an overview of how an Application Entity using the DIMSE service uses the Association Services defined in PS 3.8.
During the Association establishment phase, a DIMSE-service-user shall exchange initialization information using parameters of the A-ASSOCIATE Upper Layer Service (see Figure 7.4-1) which include:
Application context
Presentation and session requirements
DIMSE-specific user information
Application Association Information
The A-RELEASE and A-ABORT Services defined in PS 3.8 shall be used for the termination of an Association.
Note: The rules defining how the Association Services are used by a DIMSE-service-user are defined in Annex
D.

7.4.1 ASSOCIATION ESTABLISHMENT

The A-ASSOCIATE Service is invoked by a DIMSE-service-user to establish an Association with a peer DIMSE-service-user. Association establishment is always the first phase of DICOM Message Exchange.
The initiating DIMSE-service-user and the responding DIMSE-service-user shall include Application Association Information on the request and response primitive respectively. The meaning of this parameter is Application Context specific. For more information on the use of the Application Association Information, see Annex D.

7.4.2 ASSOCIATION RELEASE

The A-RELEASE Service is invoked by a DIMSE-service-user to request the orderly termination of an Association between peer DIMSE-service-users. This part of the Standard does not specify any use of the parameters of the A-RELEASE service.
Page 24
PS 3.7-2004
pp
y
A
r
(1)
g
Page 14
DICOM A
Association
otiation
Ne
lication Entit
Application Association Information
DIMSE
ssociation
Information
Service Classes
Information Objects
DIMSE
Message
Upper Laye
Fragments
Association Services
Upper Layer Presentation Data Service
Figure 7.4-1
DICOM APPLICATION ENTITY AND ASSOCIATION
The A-ABORT Service is invoked by a DIMSE-service-user to request the abrupt termination of the Association between peer DIMSE-service-users. The A-ABORT invoking DIMSE-service-user shall include (within the A-ABORT user information field) the Abort Source parameter. The Abort Source parameter indicates the initiating source of the abort. It takes one of the following symbolic values:
Page 25
PS 3.7-2004
Page 15
DIMSE-service-provider
DIMSE-service-user
Reference PS 3.8 for more information on the A-RELEASE and A-ABORT services.

7.5 DIMSE SERVICES

Because the manner in which operations applied to Composite SOP Instances differ from operations and notifications applied to Normalized SOP Instances, two groups of DIMSE services are defined:
DIMSE-N: those services applicable to Normalized SOP Instances
DIMSE-C: those services applicable to Composite SOP Instances
Table 7.5-1
DIMSE SERVICES
Name Group Type
C-STORE DIMSE-C operation
C-GET DIMSE-C operation
C-MOVE DIMSE-C operation
C-FIND DIMSE-C operation
C-ECHO DIMSE-C operation
N-EVENT-REPORT DIMSE-N notification
N-GET DIMSE-N operation
N-SET DIMSE-N operation
N-ACTION DIMSE-N operation
N-CREATE DIMSE-N operation
N-DELETE DIMSE-N operation
Note: Use of the Dialog command, supported in previous versions of this Standard, has been retired.

7.5.1 DIMSE-C SERVICES

The DIMSE-C services allow a DICOM Application Entity to explicitly request an operation by another DICOM Application Entity on Composite SOP Instances. The operations allowed are intended to be effectively compatible with those provided by previous versions of this Standard. DIMSE-C provides only operation services.
7.5.1.1 Operation services
DIMSE-C provides the following operation services which are all confirmed services and as such a response is expected:
a) The C-STORE service is invoked by a DIMSE-service-user to request the storage of
Composite SOP Instance information by a peer DIMSE-service-user.
b) The C-FIND service is invoked by a DIMSE-service-user to match a series of Attribute strings
against the Attributes of the set of SOP Instances managed by a peer DIMSE-service-user. The C-FIND service returns for each match a list of requested Attributes and their values.
Page 26
PS 3.7-2004 Page 16
c) The C-GET service is invoked by a DIMSE-service-user to fetch the information for one or
more Composite SOP Instances from a peer DIMSE-service-user, based upon the Attributes supplied by the invoking DIMSE-service-user.
d) The C-MOVE service is invoked by a DIMSE-service-user to move the information for one or
more Composite SOP Instances from a peer DIMSE-service-user, to a third party DIMSE­service-user, based upon the Attributes supplied by the invoking DIMSE-service-user
e) The C-ECHO service is invoked by a DIMSE-service-user to verify end-to-end
communications with a peer DIMSE-service-user.
Notes: 1. The major differences between a C-GET and a C-MOVE operation are that the:
a. C-STORE sub-operations resulting from a C-GET are performed on the same Association as
the C-GET. With a C-MOVE, the resulting C-STORE sub-operations are performed on a separate Association.
b. C-MOVE operation supports C-STORE sub-operations being performed with an Application
Entity which is not the one that initiated the C-MOVE (third party move).
2. In the case where an Application Entity wishes to request that it receives one or more images for storage, it may use either a C-GET operation or a C-MOVE to itself. It is expected that in most environments the C-MOVE is a simpler solution despite the fact that two Associations are required. The use of the C-GET service may not be widely implemented. It may be implemented in special cases where a system does not support multiple Associations. It was left in this version of the Standard for backward compatibility with previous versions of the Standard.

7.5.2 DIMSE-N SERVICES

The DIMSE-N services provide both notification and operation services applicable to Normalized SOP Instances.
7.5.2.1 Notification service
DIMSE-N provides a single Notification Service, the N-EVENT-REPORT. The N-EVENT-REPORT service is invoked by a DIMSE-service-user to report an event about a SOP Instance to a peer DIMSE­service-user. This service is a confirmed service and a response is expected.
7.5.2.2 Operation services
DIMSE-N provides the following operation services which are all confirmed services and as such a response is expected:
a) The N-GET service is invoked by a DIMSE-service-user to request the retrieval of information
from a peer DIMSE-service-user.
b) The N-SET service is invoked by a DIMSE-service-user to request the modification of
information by a peer DIMSE-service-user.
c) The N-ACTION service is invoked by a DIMSE-service-user to request a peer DIMSE-service-
user to perform an action.
d) The N-CREATE service is invoked by a DIMSE-service-user to request a peer DIMSE-service-
user to create an instance of a SOP Class.
e) The N-DELETE service is invoked by a DIMSE-service-user to request a peer DIMSE-service-
user to delete an instance of a SOP Class.

7.5.3 DIMSE PROCEDURES

All DIMSE operations and notifications are confirmed services. The performing DIMSE-service-user shall report the response of each operation or notification over the same Association on which the operation or notification was invoked.
Page 27
PS 3.7-2004
Page 17
Each DIMSE service is accomplished through the use of one or more service primitives. How the peer DIMSE-service-users utilize and react to the service primitives are defined by the service procedures.
7.5.3.1 Sub-operations
Some DIMSE services are atomic in that the service is performed by one operation or notification. In such a case the DIMSE service primitives are used by peer DIMSE-service-users to invoke and perform the operation or notification.
Other DIMSE services require the use of one or more sub-operations to perform the service. In such cases DIMSE service primitives are used by peer DIMSE-service-users to invoke and perform each sub­operation. How and when the sub-operation service primitives are used is defined by the procedures for the DIMSE service.
7.5.3.2 Multiple responses
Each DIMSE service requires one or more response primitives as a result of the invocation of the service. How and when the multiple response primitives are used is defined by the procedures for the DIMSE service. Whether multiple responses are returned is conditional upon the information included in the request primitive by the DIMSE-service-user.
7.5.3.3 Cancellation
Certain DIMSE services permit the cancellation of the service through the use of service primitives. This allows an invoking DIMSE-service-user to request termination of a DIMSE service after completion of the request service primitive but prior to completion of the confirm service primitive.
Table 7.5-2 lists each DIMSE service and its related procedure information. The complete specifications for the service procedures are defined in Sections 9 and 10 for DIMSE-C and DIMSE-N respectively.
Table 7.5-2
DIMSE SERVICES AND PROCEDURES
Name Sub-
Operations
C-STORE
Multiple Responses
Cancel
C-GET M C M
C-MOVE M C M
C-FIND
C-ECHO
N-EVENT-REPORT
N-GET
N-SET
N-ACTION
N-CREATE
N-DELETE
C M
Page 28
PS 3.7-2004 Page 18

8 Protocol overview

8.1 DIMSE PROTOCOL

This Section provides an overview of the DIMSE protocol machine. The DIMSE protocol machine defines the procedures and the encoding rules necessary to construct Messages used to exchange command requests and responses between peer DIMSE-service-users (e.g. two DICOM Application Entities). The relationship between Messages and the different types of service primitives is shown in Figure 7-1.
The DIMSE protocol machine accepts DIMSE-service-user request and response service primitives and constructs Messages defined by the procedures defined in 9.3 and 10.3. The DIMSE protocol machine accepts Messages and passes them to the DIMSE-service-user by the means of indication and confirmation service primitives.
Procedures define the rules for the transfer of Messages that convey command requests and responses. These rules define interpretation of the various fields in the command part of the Message. They do not define what an invoking DIMSE-service-user should do with the information (the Data Set part of the Message) it requested nor how a performing DIMSE-service-user should process the operation.
Messages may be fragmented. The fragmentation of Messages exchanged between peer DICOM Application Entities and the P-DATA service used to exchange these Message fragments are defined in Annex F.
Note: These Message fragments are called Application Protocol Data Units (APDUs) by the OSI construct.
The invoking DIMSE-service-user request primitive results in a Message carrying a Command Request (with an optional associated Data Set). Each Message induces an indication primitive to the performing DIMSE-service-user.
The performing DIMSE-service-user response primitives result in a Message carrying a Command Response (with an optional associated Data Set). Each Message induces a confirmation primitive to the invoking DIMSE-service-user.

8.2 ASSOCIATION PROTOCOL

The establishment of an Association involves two DIMSE-service-users, one which is the Association­requester and one which is the Association-acceptor. A DIMSE-service-user may initiate an Association establishment by using the A-ASSOCIATE service described in PS 3.8.
Included in the parameters of the A-ASSOCIATE service is the Application Context which specifies, among other things, the rules required for the coordination of initialization information corresponding to different DICOM Application Entities. The Application Contexts permitted for DIMSE are specified in Annex A.

8.3 CONFORMANCE

Implementors conform to the DIMSE protocol only by conformance to a SOP class as defined in PS 3.2 and PS 3.4. Implementors do not conform directly to the DIMSE protocol, and are not required to include a statement about DIMSE conformance in conformance statements except as required in PS 3.4.
Page 29
PS 3.7-2004
Page 19

9 DIMSE-C

9.1 SERVICES

9.1.1 C-STORE SERVICE

The C-STORE service is used by a DIMSE-service-user to store a composite SOP Instance on a peer DIMSE-service-user. It is a confirmed service.
9.1.1.1 C-STORE parameters
Table 9.1-1 lists the parameters of this service.
Table 9.1-1
C-STORE PARAMETERS
DIMSE-C Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
Affected SOP Class UID M U(=)
Affected SOP Instance UID M U(=)
Priority M
Move Originator Application Entity Title U
Move Originator Message ID U
Data Set M
Status
M
M
9.1.1.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Notes: 1. Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but
this mode of use is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE-service-user should not attach any semantic significance to this parameter.
2. The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug procedures.
9.1.1.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the operation request/indication to which this response/confirmation applies.
9.1.1.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class for the storage. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
Page 30
PS 3.7-2004 Page 20
9.1.1.1.4 Affected SOP instance UID
For the request/indication, this parameter specifies the SOP Instance to be stored. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
9.1.1.1.5 Priority
This parameter specifies the priority of the C-STORE operation. It shall be one of LOW, MEDIUM, or HIGH.
9.1.1.1.6 Move originator application entity title
This parameter specifies the DICOM AE Title of the DICOM AE which invoked the C-MOVE operation from which this C-STORE sub-operation is being performed.
9.1.1.1.7 Move originator message ID
This parameter specifies the Message ID (0000,0110) of the C-MOVE request/indication primitive from which this C-STORE sub-operation is being performed.
9.1.1.1.8 Data set
The Data Set accompanying the C-STORE primitive contains the Attributes of the Composite SOP Instance to be stored.
9.1.1.1.9 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in the response/confirmation. The following types of status may occur in a response/confirmation:
a) Refused: Out of ResourcesThis indicates that the peer DIMSE-service-user was unable to
store the composite SOP Instance because it was out of resources.
b) Refused: SOP Class Not SupportedThis indicates that the peer DIMSE-service-user was
unable to store the composite SOP Instance because the SOP Class is not supported,
c Error: Cannot UnderstandThis indicates that the peer DIMSE-service-user was unable to
store the composite SOP Instance because it cannot understand certain Data Elements.
d) Error: Data Set does not match SOP ClassThis indicates that the peer DIMSE-service-user
was unable to store the composite SOP Instance because the Data Set does not match the SOP Class.
e) WarningThis indicates that the peer DIMSE-service-user was able to store the composite
SOP Instance, but detected a probable error.
f) Success This indicates that the composite SOP Instance was successfully stored.
9.1.1.2 C-STORE service procedures
The following C-STORE procedures apply:
a) The invoking DIMSE-service-user requests that the performing DIMSE-service-user store a
composite SOP Instance by issuing a C-STORE request primitive to the DIMSE-service­provider.
b) The DIMSE-service-provider issues a C-STORE indication primitive to the performing DIMSE-
service-user.
c) The performing DIMSE-service-user reports acceptance or rejection of the C-STORE request
primitive by issuing a C-STORE response primitive to the DIMSE-service-provider,
Page 31
PS 3.7-2004
Page 21
d) The DIMSE-service-provider issues a C-STORE confirmation primitive to the invoking DIMSE-
service-user, completing the C-STORE operation.
The performing DIMSE-service-user may return a C-STORE response primitive with the status of Failed or Refused before the entire C-STORE indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A C-STORE response primitive with the status of Success or Warning shall not be returned until the entire C-STORE indication has been received by the performing DIMSE-service­user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

9.1.2 C-FIND SERVICE

The C-FIND service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user. It is a confirmed service.
9.1.2.1 C-FIND Parameters
See Table 9.1-2.
Table 9.1-2
C-FIND PARAMETERS
DIMSE-C Parameter Name Req/Ind Rsp/Conf CnclReq/CnclInd
Message ID M
Message ID Being Responded To
Affected SOP Class UID M U(=)
Priority M
Identifier M C
Status
M M
M
9.1.2.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Notes: 1. Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but
this mode of use is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE-service-user should not attach any semantic significance to this parameter.
2. The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug procedures.
9.1.2.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the request/indication to which this response/confirmation applies.
9.1.2.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class of the Information Model for the query. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
Page 32
PS 3.7-2004 Page 22
9.1.2.1.4 Priority
This parameter specifies the priority of the C-FIND operation. It shall be one of LOW, MEDIUM, or HIGH.
9.1.2.1.5 Identifier
In the request/indication, this is a list of Attributes to be matched against the values of the Attributes in the instances of the composite objects known to the performing DIMSE-service-user.
In the response/confirmation, this is the same list of Attributes with values of these Attributes in a particular composite SOP Instance which matched. It shall be sent only when that Status (0000,0900) is equal to Pending (not permitted for other statuses).
The list of Attributes and the rules for construction are specified in PS 3.4.
9.1.2.1.6 Status
Indicates the status of the response. It may have any of the following values:
a) SuccessThis indicates that processing of the matches is complete. It shall not contain a
matching Identifier.
b) PendingThis indicates that processing of the matches is initiated or continuing. It shall
contain a matching Identifier.
c) Refused: Out of ResourcesIndicates that processing of the C-FIND has been terminated
because it was out of resources. This may be the initial response to the C-FIND, or may be sent after a number of pending C-FIND responses. This response shall not contain a matching Identifier.
d) Refused: SOP Class Not Supported Indicates that processing of the C-FIND has been
terminated because the SOP Class was not supported. This response shall not contain a matching Identifier.
e) CancelIndicates that the processing of the C-FIND has been terminated due to a C-FIND
Cancel indication primitive. The response shall not contain an Identifier.
f) FailedIndicates that the C-FIND operation failed at the performing DIMSE-service-user.
9.1.2.2 C-FIND service procedures
The following C-FIND service procedures apply to the invoking DIMSE-service user:
a) The invoking DIMSE-service-user requests a performing DIMSE-service-user to match an
Identifier against the Attributes of all SOP Instances known to the performing DIMSE-service­user by issuing a C-FIND request primitive to the DIMSE-service-provider. If the request is rejected by the DIMSE-service-provider, the following procedures do not apply.
b) At any time before receiving a C-FIND confirmation primitive with a status unequal to Pending,
the invoking DIMSE-service-user may request the performing DIMSE-service-user to cancel the service by issuing a C-FIND cancel request primitive to the DIMSE-service-provider.
c) The invoking DIMSE-service-user receives a C-FIND confirmation primitive for each unique
match of the Identifier to a set of composite SOP Instance Attributes.
d) The invoking DIMSE-service-user receives a final C-FIND confirmation primitive.
Note: In the above procedures, (c) may precede (b).
The following C-FIND service procedures apply to the performing DIMSE-service-user:
Page 33
PS 3.7-2004
Page 23
a) When the performing DIMSE-service-user receives a C-FIND indication from the DIMSE-
service-provider, it matches the Identifier against the Attributes of known composite SOP Instances.
b) At any time following the C-FIND indication, the performing DIMSE-service-user may receive a
C-FIND cancel indication.
c) If the C-FIND cancel indication is received before the processing of the C-FIND indication has
completed, then the C-FIND operation is aborted; otherwise the following procedure does not apply.
d) The performing DIMSE-service-user issues a C-FIND response with a status of Canceled to
the DIMSE-service-provider to indicate that the C-FIND has been canceled. The following procedures do not apply.
e) For each match, the performing DIMSE-service-user issues a C-FIND response with the
status set to Pending and a matching Identifier.
f) When the C-FIND operation completes (either in success or in failure), the performing DIMSE-
service-user issues a C-FIND response with the status set to either Refused, Failed, or Success to the DIMSE-service-provider.
The following C-FIND service procedures apply to the DIMSE-service-provider:
a) When the DIMSE-service-provider receives a C-FIND request primitive from the invoking
DIMSE-service-user, it issues a C-FIND indication primitive to the performing DIMSE-service­user.
b) When the DIMSE-service-provider receives a C-FIND cancel request primitive from the
invoking DIMSE-service-user, it issues a C-FIND cancel indication to the performing DIMSE­service-user.
c) When the DIMSE-service-provider receives a C-FIND response primitive from the performing
DIMSE-service-user, it issues a C-FIND confirmation primitive to the invoking DIMSE-service­user.
The performing DIMSE-service-user may return a C-FIND response primitive with the status of Failed or Refused before the entire C-FIND indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A C-FIND response primitive with the status of Success or Warning shall not be returned until the entire C-FIND indication has been received by the performing DIMSE-service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

9.1.3 C-GET SERVICE

The C-GET service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user, and retrieve all composite SOP Instances which match. It triggers one or more C-STORE sub-operations on the same Association. It is a confirmed service.
9.1.3.1 C-GET parameters
See Table 9.1-3.
Table 9.1-3
C-GET PARAMETERS
DIMSE-C Parameter Name Req/Ind Rsp/Conf CnclReq/CnclInd
Message ID M
Message ID Being Responded To
M M
Page 34
PS 3.7-2004 Page 24
Affected SOP Class UID M U(=)
Priority M
Identifier M U
Status
Number of Remaining Sub-operations
Number of Completed Sub-operations
Number of Failed Sub-operations
Number of Warning Sub-operations
M
C
C
C
C
9.1.3.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Noteσ: 1. Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but
this mode of use is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE-service-user should not attach any semantic significance to this parameter.
2. The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug procedures.
9.1.3.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the request/indication to which this response/confirmation applies.
9.1.3.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class of the Information Model for the retrieve. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
9.1.3.1.4 Priority
This parameter specifies the priority of the C-GET operation. It shall be one of LOW, MEDIUM or HIGH. This priority shall also be the priority used for all sub-operations.
9.1.3.1.5 Identifier
In the request/indication, this is a list of Attributes to be matched against the values of the Attributes of known composite SOP Instances of the performing DIMSE-service-user. The list of Attributes allowed and the rules for the construction are specified in PS 3.4.
Note: The Identifier is specified as U in the Response/Confirmation, but Services defined in PS 3.4 that use this
primitive may impose mandatory or conditional requirements on its presence.
In the response/confirmation, this is a list of Attributes which provide status information about the C-GET operation. The list of Attributes allowed and the rules which define the usage of the Identifier are specified in PS 3.4.
9.1.3.1.6 Status
Indicates the status of the response. It may have any of the following values:
Page 35
PS 3.7-2004
Page 25
a) SuccessThis indicates that processing of the matches and all sub-operations are complete.
b) PendingThis indicates that processing of the matches and sub-operations is initiated or
continuing.
c) Refused: Out of ResourcesIndicates that processing of the C-GET has been terminated
because it was out of resources. This may be the initial response to the C-GET or may be sent after a number of Pending statuses.
d) Refused: SOP Class Not SupportedIndicates that processing of the C-GET has been
terminated because the SOP Class was not supported.
e) CancelIndicates that processing of the C-GET has been terminated due to a C-GET Cancel
indication primitive.
f) FailedIndicates that the C-GET operation failed at the performing DIMSE-service-user.
9.1.3.1.7 Number of remaining sub-operations
This specifies the number of remaining C-STORE sub-operations to be invoked by this C-GET operation. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.3.1.8 Number of completed sub-operations
This specifies the number of C-STORE sub-operations invoked by this C-GET operation which have completed successfully. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.3.1.9 Number of failed sub-operations
This specifies the number of C-STORE sub-operations invoked by this C-GET operation which have failed. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.3.1.10 Number of warning sub-operations
This specifies the number of C-STORE sub-operation invoked by this C-GET operation which generated Warning responses. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.3.2 C-GET service procedures
The following C-GET service procedures apply to the invoking DIMSE-service user:
a) The invoking DIMSE-service-user requests a performing DIMSE-service-user to match an
Identifier against the Attributes of all SOP Instances known to the performing DIMSE-service­user and generate a C-STORE sub-operation for each match. This request is made by issuing a C-GET request primitive to the DIMSE-service-provider. If the request is rejected by the DIMSE-service-provider, the following procedures do not apply.
b) At any time before receiving a C-GET confirmation primitive with status unequal to Pending,
the invoking DIMSE-service-user may request the performing DIMSE-service-user to cancel the service by issuing a C-GET cancel request primitive to the DIMSE-service-provider.
c) The invoking DIMSE-service-user may receive C-GET confirmation primitives with status of
Pending during the processing of the C-GET operation.
d) The invoking DIMSE-service-user receives a final C-GET confirmation primitive.
Note: In the above procedures, (c) may precede (b).
The following C-GET service procedures apply to the performing DIMSE-service-user:
Page 36
PS 3.7-2004 Page 26
a) When the performing DIMSE-service-user receives a C-GET indication from the DIMSE-
service-provider it matches the Identifier against the Attributes of known composite SOP Instances and generates a C-STORE sub-operation for each match.
b) At any time following the C-GET indication, the performing DIMSE-service-user may receive a
C-GET cancel indication.
c) If the C-GET cancel indication is received before the processing of the C-GET indication has
completed, then the C-GET operation is terminated; otherwise the following procedure does not apply.
d) The performing DIMSE-service-user issues a C-GET response with a status of Canceled to
the DIMSE-service-provider to indicate that the C-GET has been canceled. The following procedures do not apply.
e) For each match, the performing DIMSE-service-user initiates a C-STORE sub-operation on
the same Association as the C-GET. In this sub-operation, the C-GET performing DIMSE­service-user becomes the C-STORE invoking DIMSE-service-user. The C-STORE performing DIMSE-service-user is the C-GET invoking DIMSE-service-user.
f) During the processing of the C-GET operation, the performing DIMSE-service-user may issue
C-GET response primitives with a status of Pending.
g) When the C-GET operation completes (either in success or in failure), the performing DIMSE-
service-user issues a C-GET response with the status set to either refused, failed or success to the DIMSE-service-provider.
The following C-GET service procedures apply to the DIMSE-service-provider:
a) When the DIMSE-service-provider receives a C-GET request primitive from the invoking
DIMSE-service-user, it issues a C-GET indication primitive to the performing DIMSE-service­user.
b) When the DIMSE-service-provider receives a C-GET cancel request primitive from the
invoking DIMSE-service-user, it issues a C-GET cancel indication to the performing DIMSE­service-user.
c) When the DIMSE-service-provider receives a C-GET response primitive from the performing
DIMSE-service-user, it issues a C-GET confirmation primitive to the invoking DIMSE-service­user.
The performing DIMSE-service-user may return a C-GET response primitive with the status of Failed or Refused before the entire C-GET indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A C-GET response primitive with the status of Success or Warning shall not be returned until the entire C-GET indication has been received by the performing DIMSE-service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

9.1.4 C-MOVE SERVICE

The C-MOVE service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user, and retrieve all composite SOP Instances which match. It triggers one or more C-STORE sub-operations on a separate Association. It is a confirmed service.
9.1.4.1 C-MOVE parameters
See Table 9.1-4.
Table 9.1-4
C-MOVE PARAMETERS
Page 37
PS 3.7-2004
Page 27
DIMSE-C Parameter Name Req/Ind Rsp/Conf CnclReq/CnclInd
Message ID M
Message ID Being Responded To
Affected SOP Class UID M U(=)
Priority M
Move Destination M
Identifier M U
Status
Number of Remaining Sub-operations
Number of Completed Sub-operations
Number of Failed Sub-operations
Number of Warning Sub-operations
M M
M
C
C
C
C
9.1.4.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Notes: 1. Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but
this mode of use is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE-service-user should not attach any semantic significance to this parameter.
2. The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug procedures.
9.1.4.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the request/indication to which this response/confirmation applies.
9.1.4.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class of the Information Model for the retrieve. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
9.1.4.1.4 Priority
This parameter specifies the priority of the C-MOVE operation. It shall be one of LOW, MEDIUM or HIGH . This priority shall also be the priority used for all sub-operations.
9.1.4.1.5 Move destination
This parameter specifies the DICOM AE Title of the destination DICOM AE from which the C-STORE sub-operations are being performed.
9.1.4.1.6 Identifier
In the request/indication, this is a list of Attributes to be matched against the values of the Attributes of known composite SOP Instances of the performing DIMSE-service-user. The list of Attributes allowed and the rules for the construction are in PS 3.4.
Page 38
PS 3.7-2004 Page 28
Note: The Identifier is specified as U in the Response/Confirmation, but Services defined in PS 3.4 that use this
primitive may impose mandatory or conditional requirements on its presence.
In the response/confirmation, this is a list of Attributes which provide status information about the C­MOVE operation. The list of Attributes allowed and the rules which define the usage of the Identifier are specified in PS 3.4.
9.1.4.1.7 Status
Indicates the status of the response. It may have any of the following values:
a) SuccessThis indicates that processing of the matches and all sub-operations are complete.
b) PendingThis indicates that procession of the matches and sub-operations is initiated or
continuing.
c) Refused: Out of ResourcesIndicates that processing of the C-MOVE has been terminated
because it was out of resources. This may be the initial response to the C-MOVE or may be sent after a number of Pending statuses.
d) Refused: SOP Class Not SupportedIndicates that processing of the C-MOVE has been
terminated because the SOP Class was not supported.
e) Refused: Move Destination UnknownIndicates that processing of the C-MOVE has been
terminated because the Move destination was unknown.
f) CancelIndicates that processing of the C-MOVE has been terminated due to a C-MOVE
Cancel indication primitive.
g) FailedIndicates that the C-MOVE operation failed at the performing DIMSE-service-user.
9.1.4.1.8 Number of remaining sub-operations
This specifies the number of remaining C-STORE sub-operations to be invoked by this C-MOVE operation. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.4.1.9 Number of completed sub-operations
This specifies the number of C-STORE sub-operations invoked by this C-MOVE operation which have completed successfully. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.4.1.10 Number of failed sub-operations
This specifies the number of C-STORE sub-operations invoked by this C-MOVE operation which have failed. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.4.1.11 Number of warning sub-operations
This specifies the number of C-STORE sub-operation invoked by this C-MOVE operation which generated Warning responses. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
9.1.4.2 C-MOVE service procedures
The following C-MOVE service procedures apply to the invoking DIMSE-service user:
a) The invoking DIMSE-service-user requests a performing DIMSE-service-user to match an
Identifier against the Attributes of all SOP Instances known to the performing DIMSE-service­user and generate a C-STORE sub-operation for each match. This request is made by issuing
Page 39
a C-MOVE request primitive to the DIMSE-service-provider. If the request is rejected by the DIMSE-service-provider, the following procedures do not apply.
b) At any time before receiving a C-MOVE confirmation primitive with status unequal to Pending,
the invoking DIMSE-service-user may request the performing DIMSE-service-user to cancel the service by issuing a C-MOVE cancel request primitive to the DIMSE-service-provider.
c) The invoking DIMSE-service-user may receive C-MOVE confirmation primitives with status of
Pending during the processing of the C-MOVE operation.
d) The invoking DIMSE-service-user receives a final C-MOVE confirmation primitive.
Note: in the above procedures, (c) may precede (b).
The following C-MOVE service procedures apply to the performing DIMSE-service-user:
a) When the performing DIMSE-service-user receives a C-MOVE indication from the DIMSE-
service-provider it matches the Identifier against the Attributes of known composite SOP Instances and generates a C-STORE sub-operation for each match.
b) At any time following the C-MOVE indication, the performing DIMSE-service-user may receive
a C-MOVE cancel indication.
c) If the C-MOVE cancel indication is received before the processing of the C-MOVE request has
completed, then the C-MOVE operation is terminated; otherwise the following procedure does not apply.
d) The performing DIMSE-service-user issues a C-MOVE response with a status of Canceled to
the DIMSE-service-provider to indicate that the C-MOVE has been canceled. The following procedures do not apply.
e) For each matching composite SOP Instance, the C-MOVE performing DIMSE-service-user
initiates a C-STORE sub-operation on a different Association than the C-MOVE. In this sub­operation, the C-MOVE performing DIMSE-service-user becomes the C-STORE invoking DIMSE-service-user. The C-STORE performing DIMSE-service-user may or may not be the C-MOVE invoking DIMSE-service-user.
f) During the processing of the C-MOVE operation, the performing DIMSE-service-user may
issue C-MOVE response primitives with a status of Pending.
g) When the C-MOVE operation completes (either in success or in failure), the performing
DIMSE-service-user issues a C-MOVE response with the status set to either Refused, Failed, or Success to the DIMSE-service-provider.
The following C-MOVE service procedures apply to the DIMSE-service-provider:
PS 3.7-2004
Page 29
a) When the DIMSE-service-provider receives a C-MOVE request primitive from the invoking
DIMSE-service-user, it issues a C-MOVE indication primitive to the performing DIMSE­service-user.
b) When the DIMSE-service-provider receives a C-MOVE cancel request primitive from the
invoking DIMSE-service-user, it issues a C-MOVE cancel indication to the performing DIMSE­service-user.
c) When the DIMSE-service-provider receives a C-MOVE response primitive from the performing
DIMSE-service-user, it issues a C-MOVE confirmation primitive to the invoking DIMSE­service-user.
The performing DIMSE-service-user may return a C-MOVE response primitive with the status of Failed or Refused before the entire C-MOVE indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A C-MOVE response primitive with the status of Success or Warning shall not be returned until the entire C-MOVE indication has been received by the performing DIMSE-service-user.
Page 40
PS 3.7-2004 Page 30
Notes: Such an occurrence of a "Failed" response is often called an early failed response.

9.1.5 C-ECHO SERVICE

The C-ECHO service is invoked by a DIMSE-service-user to verify end-to-end communications with a peer DIMSE-service-user. It is a confirmed service.
9.1.5.1 C-ECHO parameters
Table 9.1-5
C-ECHO PARAMETERS
DIMSE-C Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
M
Affected SOP Class UID M U(=)
Status
M
9.1.5.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Notes: 1. Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but
this mode of use is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE-service-user should not attach any semantic significance to this parameter.
2. The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug procedures.
9.1.5.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the request/indication to which this response/ confirmation applies.
9.1.5.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class of the SOP Instance for the verification. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
9.1.5.1.4 Status
Indicates the status of the response. It shall have a value of success.
9.1.5.2 C-ECHO service procedures
The following C-ECHO procedures apply:
a) The invoking DIMSE-service-user requests verification of communication to the performing
DIMSE-service-user by issuing a C-ECHO request primitive to the DIMSE-service-provider.
b) The DIMSE-service-provider issues a C-ECHO indication primitive to the performing DIMSE-
service-user.
c) The performing DIMSE-service-user verifies communication by issuing a C-ECHO response
primitive to the DIMSE-service-provider.
Page 41
PS 3.7-2004
Page 31
d) The DIMSE-service-provider issues a C-ECHO confirmation primitive to the invoking DIMSE-
service-user, completing the C-ECHO operation.

9.2 SEQUENCING

9.2.1 TYPES OF SERVICES

All operation and notifications shall be confirmed services.

9.2.2 USAGE RESTRICTIONS

These services may only be invoked within the context of an established Association.

9.2.3 DISRUPTED PROCEDURES

These services do not disrupt any other service procedure.

9.2.4 DISRUPTING PROCEDURES

These services are disrupted by the A-ABORT service procedure.

9.3 PROTOCOL

This section specifies the protocol necessary to perform the set of DIMSE-C operations. The Value Representations (VR) specified in the following tables shall be encoded as defined in PS 3.5.

9.3.1 C-STORE PROTOCOL

The information necessary for the C-STORE request and indication DIMSE-C primitives are conveyed in the C-STORE-RQ Message. The information necessary for the C-STORE response and confirmation DIMSE-C primitives are conveyed in the C-STORE-RSP Message.
9.3.1.1 C-STORE-RQ
The C-STORE-RQ Message contains fields as defined in Table 9.3-1. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C­STORE service definition unless otherwise noted in Table 9.3-1. Fields not specified in the C-STORE service definition but present in Table 9.3-1 are required by the DIMSE-C protocol.
Table 9.3-1
C-STORE-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class
(0000,0002) UI 1 SOP Class UID of the SOP Instance to be stored.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0001H for the C-STORE-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value. It distinguishes this
Message from other Messages.
Priority (0000,0700) US 1 The priority shall be set to one of the following
values:
LOW = 0002H
MEDIUM = 0000H
HIGH = 0001H
Page 42
PS 3.7-2004 Page 32
Data Set Type (0000,0800) US 1 This field indicates that a Data Set is present in
the Message. It shall be set to any value other than 0101H (Null).
Affected SOP Instance UID
Move Originator Application Entity Title
Move Originator Message ID
(0000,1000) UI 1 Contains the UID of the SOP Instance to be
stored.
(0000,1030) AE 1 Contains the DICOM AE Title of the DICOM AE
which invoked the C-MOVE operation from which this C-STORE sub-operation is being performed.
(0000,1031) US 1 Contains the Message ID (0000,0110) of the C-
MOVE-RQ Message from which this C-STORE sub-operations is being performed.
Data Set (no tag)
Application-specific Data Set.
Note: The contents of Composite Information Object Definitions, encoded as a series of Data Elements, are
defined in PS 3.3 and PS 3.4
9.3.1.2 C-STORE-RSP
The C-STORE-RSP Message contains fields as defined in Table 9.3-2 and in Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5 of the DICOM Standard. Fields are required as specified in the C-STORE service definition unless otherwise noted in Table 9.3-2. Fields not specified in the C-STORE service definition but present in Table 9.3-2 are required by the DIMSE-C protocol.
Table 9.3-2
C-STORE-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 Contains the SOP Class of the SOP Instance
stored.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 8001H for the C-STORE­RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C­STORE-RQ Message.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present
in the Message and shall be set to a value of 0101H (Null).
Status (0000,0900)
Affected SOP
(0000,1000) UI 1 Contains the UID of the SOP Instance stored.
US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
Instance UID
Page 43
PS 3.7-2004
Page 33
9.3.1.3 C-STORE protocol procedures
The C-STORE procedures are initiated by the invoking DIMSE-service-user issuing a C-STORE request primitive. On receipt of the C-STORE request primitive the DIMSE-C protocol machine shall:
construct a Message conveying the C-STORE-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-STORE-RQ the DIMSE-C protocol machine shall issue a C­STORE indication primitive to the performing DIMSE-service-user.
On receipt of the C-STORE response primitive, issued by the performing DIMSE-service-user, the DIMSE-C protocol machine shall:
construct a Message conveying the C-STORE-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-STORE-RSP the DIMSE-C protocol machine shall issue a C­STORE confirmation primitive to the invoking DIMSE-service-user, thus completing the C-STORE procedure.
The performing DIMSE-service-user may return a C-STORE-RSP with the status of Failed or Refused before the complete C-STORE-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused C­STORE-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before a C-STORE-RQ Message has been completely transmitted if it has not received a Failed or Refused C-STORE-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.

9.3.2 C-FIND PROTOCOL

The information necessary for the C-FIND request and indication DIMSE-C primitives are conveyed in the C-FIND-RQ Message. The information necessary for the C-FIND response and confirmation DIMSE-C primitives are conveyed in the C-FIND-RSP Message. The information necessary for the C-FIND Cancel Request and Cancel Indication primitives are conveyed in the C-CANCEL-FIND-RQ Message.
9.3.2.1 C-FIND-RQ
The C-FIND-RQ Message contains fields as defined in Table 9.3-3. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-FIND service definition unless otherwise noted in Table 9.3-3. Fields not specified in the C-FIND service definition but present in Table 9.3-3 are required by the DIMSE-C protocol.
Table 9.3-3
C-FIND-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Page 44
PS 3.7-2004 Page 34
Affected SOP Class
(0000,0002) UI 1 SOP Class UID associated with this operation.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0020H for the C-FIND-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Priority (0000,0700) US 1 The priority shall be set to one of the following
values:
LOW = 0002H
MEDIUM = 0000H
HIGH = 0001H
Data Set Type (0000,0800) US 1 This field indicates that a Data Set is present
in the Message. It shall be set to any value other than 0101H (Null).
Identifier (no tag)
A Data Set which encodes the Identifier to be matched. See Section 9.1.2.1.4.
Note: Implementations which require compatibility to previous versions of this Standard must set the Data Set
Type (0000,0800) Field to 0102H (Identifier).
9.3.2.2 C-FIND-RSP
The C-FIND-RSP Message contains fields as defined in Table 9.3-4 and in Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-FIND service definition unless otherwise noted in Table 9.3-4. Fields not specified in the C-FIND service definition but present in Table 9.3-4 are required by the DIMSE-C protocol.
Table 9.3-4
C-FIND-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class
(0000,0002) UI 1 SOP Class UID associated with the operation.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 8020H for the C-FIND-RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-FIND­RQ Message.
Data Set Type (0000,0800) US
1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H (Null) if no Data Set is present;
Page 45
PS 3.7-2004
Page 35
any other value indicates a Data Set is included in the Message.
Status (0000,0900)
Identifier (no tag)
US
1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
A Data Set which encodes the Identifier that was matched. See Section 9.1.2.1.4.
9.3.2.3 C-CANCEL-FIND-RQ
The C-CANCEL-FIND-RQ Message contains fields as defined in Table 9.3-5. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C­FIND service definition unless otherwise noted in Table 9.3-5. Fields not specified in the C-FIND service definition but present in Table 9.3-5 are required by the DIMSE-C protocol.
Table 9.3-5
C-CANCEL-FIND-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0FFFH for the C-CANCEL­FIND-RQ Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-FIND­RQ Message.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present
in the Message and shall be set to a value of 0101H.
9.3.2.4 C-FIND protocol procedures
The C-FIND procedures are initiated by the invoking DIMSE-service-user issuing a C-FIND request primitive. On receipt of the C-FIND request primitive the DIMSE-C protocol machine shall:
construct a Message conveying the C-FIND-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-FIND-RQ the DIMSE-C protocol machine shall issue a C-FIND indication primitive to the performing DIMSE-service-user.
The DIMSE-C protocol machine shall:
accept zero or more C-FIND response primitives containing the status of Pending, issued by
the performing DIMSE-service-user, followed by a single C-FIND response primitive containing the final status
for each C-FIND response primitive containing the Pending status the DIMSE-C protocol
machine shall:
Page 46
PS 3.7-2004 Page 36
a) construct a Message conveying the (Pending) C-FIND-RSP b) send the Message using the P-DATA request service (See 8.1)
for the C-FIND response primitive containing the final status the DIMSE-C protocol machine
shall:
a) construct a Message conveying the (final) C-FIND-RSP b) end the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-FIND-RSP the DIMSE-C protocol machine shall:
if the Message indicates the status of Pending, issue a C-FIND confirmation primitive to the
invoking DIMSE-service-user with a Pending status
if the Message indicates a final status, issue a C-FIND confirmation primitive to the invoking
DIMSE-service-user with a final status, thus completing the C-FIND procedure
Note: The C-FIND procedures can be canceled at any time by the invoking DIMSE-service-user. This is
accomplished by the invoking DIMSE-service-user issuing a C-CANCEL request primitive.
The performing DIMSE-service-user may return a C-FIND-RSP with the status of Failed or Refused before the complete C-FIND-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused C­FIND-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before a C-FIND-RQ Message has been completely transmitted if it has not received a Failed or Refused C-FIND-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.

9.3.3 C-GET PROTOCOL

The information necessary for the C-GET request and indication DIMSE-C primitives are conveyed in the C-GET-RQ Message. The information necessary for the C-GET response and confirmation DIMSE-C primitives are conveyed in the C-GET-RSP Message. The information necessary for the C-GET Cancel Request and Cancel Indication primitives are conveyed in the C-CANCEL-GET-RQ Message.
9.3.3.1 C-GET-RQ
The C-GET-RQ Message contains fields as defined in Table 9.3-6. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-GET service definition unless otherwise noted in Table 9.3-6. Fields not specified in the C-GET service definition but present in Table 9.3-6 are required by the DIMSE-C protocol.
Table 9.3-6
C-GET-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class (0000,0002) UI 1 SOP Class UID associated with this operation.
Page 47
PS 3.7-2004
Page 37
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0010H for the C-GET-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which distinguishes
this Message from other Messages.
Priority (0000,0700) US 1 The priority shall be set to one of the following
values:
LOW = 0002H
MEDIUM = 0000H
HIGH = 0001H
Data Set Type (0000,0800) US 1 This field indicates that a Data Set is present in
the Message. It shall be set to any value other than 0101H (Null).
Identifier (no tag)
A Data Set that encodes attributes providing status information about the C-GET operation. See Section 9.1.3.1.5.
Note: Implementations which require compatibility to previous versions of this Standard must set the Data Set
Type (0000,0800) Field to 0102H (Identifier).
9.3.3.2 C-GET-RSP
The C-GET-RSP Message contains fields as defined in Table 9.3-7 and in Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-GET service definition unless otherwise noted in Table 9.3-7. Fields not specified in the C-GET service definition but present in Table 9.3-7 are required by the DIMSE-C protocol.
Table 9.3-7
C-GET-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID (0000,0002) UI 1 SOP Class UID associated with the operation.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 8010H for the C-GET-RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-GET­RQ Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H (Null) if no Data Set is present; any other value indicates a Data Set is included in the Message.
Page 48
PS 3.7-2004 Page 38
Status (0000,0900)
Number of Remaining
(0000,1020) US 1 The number of remaining C-STORE sub-
Sub-operations
US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
operations to be invoked for this C-GET operation.
Number of Completed Sub-operations
(0000,1021) US 1 The number of C-STORE sub-operations
invoked by this C-GET operation which have completed successfully.
Number of Failed Sub­operations
(0000,1022) US 1 The number of C-STORE sub-operations
invoked by this C-GET operation which have failed.
Number of Warning Sub­operations
(0000,1023) US 1 The number of C-STORE sub-operations
invoked by this C-GET operation which generated warning responses.
Identifier (no tag)
A Data Set which encodes the Identifier that was matched. See Section 9.1.3.1.5.
Note: The list of Attributes allowed and the rules which define the usage of the Identifier are specified in PS 3.4.
9.3.3.3 C-CANCEL-GET-RQ
The C-CANCEL-GET-RQ Message contains fields as defined in Table 9.3-8. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C­GET service definition unless otherwise noted in Table 9.3-8. Fields not specified in the C-GET service definition but present in Table 9.3-8 are required by the DIMSE-C protocol.
Table 9.3-8
C-CANCEL-GET-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0FFFH for the C-CANCEL­GET-RQ Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-GET­RQ Message.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present
in the Message and shall be set to a value of 0101H.
9.3.3.4 C-GET protocol procedures
The C-GET procedures are initiated by the invoking DIMSE-service-user issuing a C-GET request primitive. On receipt of the C-GET request primitive the DIMSE-C protocol machine shall:
Page 49
PS 3.7-2004
Page 39
construct a Message conveying the C-GET-RQ
send the Message using the P-DATA request service (See 8.1).
On receipt of a Message conveying a C-GET-RQ the DIMSE-C protocol machine shall issue a C-GET indication primitive to the performing DIMSE-service-user.
The DIMSE-C protocol machine shall:
accept zero or more C-GET response primitives containing the status of Pending, issued by
the performing DIMSE-service-user, followed by a single C-GET response primitive containing the final status
for each C-GET response primitive containing the Pending status the DIMSE-C protocol
machine shall:
a) construct a Message conveying the (Pending) C-GET-RSP b) send the Message using the P-DATA request service (See 8.1)
for the C-GET response primitive containing the final status the DIMSE-C protocol machine
shall:
a) construct a Message conveying the (final) C-GET-RSP b) send the Message using the P-DATA request service (See 8.1)
Note: The C-GET indication primitive initiates a sub-operation identical to the C-STORE operation. However,
for the C-STORE sub-operation the DIMSE-service-users switch their invoking and performing roles (i.e. the invoking DIMSE-service-user becomes the performing DIMSE-service-user, etc.).
On receipt of a Message conveying a C-GET-RSP the DIMSE-C protocol machine shall:
if the Message indicates the status of Pending, issue a C-GET confirmation primitive to the
invoking DIMSE-service-user with a Pending status
if the Message indicates a final status, issue a C-GET confirmation primitive to the invoking
DIMSE-service-user with a final status, thus completing the C-GET procedure
Note: The C-GET procedures can be canceled at any time by the invoking DIMSE-service-user. This is
accomplished by the invoking DIMSE-service-user issuing a C-CANCEL request primitive.
The performing DIMSE-service-user may return a C-GET-RSP with the status of Failed or Refused before the complete C-GET-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused C­GET-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before a C-GET-RQ Message has been completely transmitted if it has not received a Failed or Refused C-GET-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.
Page 50
PS 3.7-2004 Page 40

9.3.4 C-MOVE PROTOCOL

The information necessary for the C-MOVE request and indication DIMSE-C primitives are conveyed in the C-MOVE-RQ Message. The information necessary for the C-MOVE response and confirmation DIMSE-C primitives are conveyed in the C-MOVE-RSP Message. The information necessary for the C­MOVE Cancel request and Cancel indication primitives are conveyed in the C-CANCEL-MOVE-RQ Message.
9.3.4.1 C-MOVE-RQ
The C-MOVE-RQ Message contains fields as defined in Table 9.3-9. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-MOVE service definition unless otherwise noted in Table 9.3-9. Fields not specified in the C-GET-MOVE service definition but present in Table 9.3-9 are required by the DIMSE-C protocol.
Table 9.3-9
C-MOVE-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class
(0000,0002) UI 1 SOP Class UID associated with this operation.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0021H for the C-MOVE-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Priority (0000,0700) US 1 The priority shall be set to one of the following
values:
LOW = 0002H
MEDIUM = 0000H
HIGH = 0001H
Data Set Type (0000,0800) US 1 This field indicates that a Data Set is present
in the Message. It shall be set to any value other than 0101H (Null).
Move Destination (0000,0600) AE 1 Shall be set to the DICOM AE Title of the
destination DICOM AE for which the C­STORE sub-operations are being performed.
Identifier (no tag)
A Data Set which encodes the Identifier to be matched. See Section 9.1.4.1.6.
Note: Implementations which require compatibility to previous versions of this Standard must set the Data Set
Type (0000,0800) Field to 0102H (Identifier).
9.3.4.2 C-MOVE-RSP
The C-MOVE-RSP Message contains fields as defined in Table 9.3-10 and in Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as
Page 51
PS 3.7-2004
Page 41
specified in the C-MOVE service definition unless otherwise noted in Table 9.3-10. Fields not specified in the C-MOVE service definition but present in Table 9.3-10 are required by the DIMSE-C protocol.
Table 9.3-10
C-MOVE-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class
(0000,0002) UI 1 SOP Class UID associated with the operation.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 8021H for the C-MOVE­RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-MOVE Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H (Null) if no Data Set is present; any other value indicates a Data Set is included in the Message.
Status (0000,0900)
Number of Remaining
(0000,1020) US 1 The number of remaining sub-operations to be
Sub-operations
Number of Complete
(0000,1021) US 1 The number of C-STORE sub-operations
Sub-operations
US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
invoked for this C-MOVE operation.
invoked by this C-MOVE operation which have completed successfully.
Number of Failed Sub­operations
(0000,1022) US 1 The number of C-STORE sub-operations
invoked by this C-MOVE operation which have failed.
Number of Warning Sub-operations
(0000,1023) US 1 The number of C-STORE sub-operations
invoked by this C-MOVE operation which generated warning responses.
Identifier (no tag)
A Data Set that encodes attributes providing status information about the C-MOVE operation. See Section 9.1.4.1.6.
9.3.4.3 C-CANCEL-MOVE-RQ
The C-CANCEL-MOVE-RQ Message contains fields as defined in Table 9.3-11. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-MOVE service definition unless otherwise noted in Table 9.3-11. Fields not specified in the C­MOVE service definition but present in Table 9.3-11 are required by the DIMSE-C protocol.
Page 52
PS 3.7-2004 Page 42
Table 9.3-11
C-CANCEL-MOVE-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0FFFH for the C-CANCEL­MOVE-RQ Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-MOVE­RQ Message.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present
in the Message and shall be set to a value of 0101H.
9.3.4.4 C-MOVE Protocol Procedures
The C-MOVE procedures are initiated by the invoking DIMSE-service-user issuing a C-MOVE request primitive. On receipt of the C-MOVE request primitive the DIMSE-C protocol machine shall:
construct a Message conveying the C-MOVE-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-MOVE-RQ the DIMSE-C protocol machine shall issue a C-MOVE indication primitive to the performing DIMSE-service-user.
The DIMSE-C protocol machine shall:
accept zero or more C-MOVE response primitives containing the status of Pending, issued by
the performing DIMSE-service-user, followed by a single C-MOVE response primitive containing the final status
for each C-MOVE response primitive containing the Pending status the DIMSE-C protocol
machine shall:
a) construct a Message conveying the (Pending ) C-MOVE-RSP b) send the Message using the P-DATA request service (See 8.1)
for the C-MOVE response primitive containing the final status the DIMSE-C protocol machine
shall:
a) construct a Message conveying the (final) C-MOVE-RSP b) send the Message using the P-DATA request service (See 8.1)
Note: The C-MOVE indication primitive initiates a sub-operation identical to the C-STORE operation.
On receipt of a Message conveying a C-MOVE-RSP the DIMSE-C protocol machine shall:
if the Message indicates the status of Pending, issue a C-MOVE confirmation primitive to the
invoking DIMSE-service-user with a Pending status;
Page 53
PS 3.7-2004
Page 43
if the Message indicates a final status, issue a C-MOVE confirmation primitive to the invoking
DIMSE-service-user with a final status, thus completing the C-MOVE procedure
Note: The C-MOVE procedures can be canceled at any time by the invoking DIMSE-service-user. This shall be
accomplished by the invoking DIMSE-service-user issuing a C-CANCEL request primitive.
The performing DIMSE-service-user may return a C-MOVE-RSP with the status of Failed or Refused before the complete C-MOVE-RQ request Message has been completely transmitted by the invoking DIMSE­service-user (this is called an early failed response). Upon receipt of this Failed or Refused C-MOVE-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before a C-MOVE-RQ Message has been completely transmitted if it has not received a Failed or Refused C-MOVE-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.

9.3.5 C-ECHO PROTOCOL

The information necessary for the C-ECHO request and indication DIMSE-C primitives are conveyed in the C­ECHO-RQ Message. The information necessary for the C-ECHO response and confirmation DIMSE-C primitives are conveyed in the C-ECHO-RSP Message.
9.3.5.1 C-ECHO-RQ
The C-ECHO-RQ Message contains fields as defined in Table 9.3-12 Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-ECHO service definition unless otherwise noted in Table 9.3-12. Fields not specified in the C-ECHO service definition but present in Table 9.3-13 are required by the DIMSE-C protocol.
Table 9.3-12
C-ECHO-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class
(0000,0002) UI 1 SOP Class UID associated with this operation.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 0030H for the C-ECHO-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which distinguishes
this Message from other Messages.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present in
the Message and shall be set to a value of 0101H.
Page 54
PS 3.7-2004 Page 44
9.3.5.2 C-ECHO-RSP
The C-ECHO-RSP Message contains fields as defined in Table 9.3-13 and in Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the C-ECHO service definition unless otherwise noted in Table 9.3-13. Fields not specified in the C-ECHO service definition but present in Table 9.3-13 are required by the DIMSE-C protocol.
Table 9.3-13
C-ECHO-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class
(0000,0002) UI 1 SOP Class UID associated with the operation.
UID
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-C operation
conveyed by this Message. The value of this field shall be set to 8030H for the C-ECHO-RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated C-ECHO­RQ Message.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present in
the Message and shall be set to a value of 0101H.
Status (0000,0900) US 1 Indicates the status of the response. It shall have
a value of Success.
9.3.5.3 C-ECHO protocol procedures
The C-ECHO procedures are initiated by the invoking DIMSE-service-user issuing a C-ECHO request primitive. On receipt of the C-ECHO request primitive the DIMSE-C protocol machine shall:
construct a Message conveying the C-ECHO-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-ECHO-RQ the DIMSE-C protocol machine shall issue a C-ECHO indication primitive to the performing DIMSE-service-user.
On receipt of a C-ECHO response primitive, issued by the performing DIMSE-service-user, the DIMSE-C protocol machine shall:
construct a Message conveying the C-ECHO-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying a C-ECHO-RSP the DIMSE protocol machine shall issue a C-ECHO confirmation primitive to the invoking DIMSE-service-user, thus completing the C-ECHO procedure.
Page 55
PS 3.7-2004
Page 45

10 DIMSE-N

10.1 SERVICES

10.1.1 N-EVENT-REPORT SERVICE

The N-EVENT-REPORT service is used by a DIMSE-service-user to report an event to a peer DIMSE­service-user. It is a confirmed service.
10.1.1.1 N-EVENT-REPORT parameters
Table 10.1-1 lists the parameters for this service.
Table 10.1-1
N-EVENT-REPORT PARAMETERS
DIMSE Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
Affected SOP Class UID M U(=)
Affected SOP Instance UID M U(=)
Event Type ID M C(=)
Event Information U
Event Reply
Status
M
C
M
10.1.1.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Note: Τhe Message ID (0000,0110) is recommended to be unique within the scope of an Association, to
support debug procedures.
10.1.1.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the notification request/indication to which this response/confirmation applies.
10.1.1.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class of the SOP Instance for the event. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
10.1.1.1.4 Affected SOP instance UID
For the request/indication, this parameter specifies the SOP Instance for the event. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
Page 56
PS 3.7-2004 Page 46
10.1.1.1.5 Event type ID
This parameter specifies the type of event being reported. It may be included in the success response/confirmation and shall be included if the Event Reply parameter is included.
Note: Service Class Specifications contained in PS 3.4 defines any application usage of the Event Type ID
parameter.
10.1.1.1.6 Event information
This application-specific parameter contains information that the invoking DIMSE-service-user is able to supply about the event.
Note: Service Class Specifications contained in PS 3.4 defines any application usage of the Event Information
parameter.
10.1.1.1.7 Event reply
This application-specific parameter contains the optional reply to the event report. It may only be included in the success response/confirmation.
Note: Service Class Specifications contained in PS 3.4 defines any application usage of the Event Reply
parameter.
10.1.1.1.8 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in any response/confirmation. The following types of status may occur:
class-instance conflict: the specified SOP Instance is not a member of the specified SOP
class.
duplicate invocation: the Message ID (0000,0110) specified is allocated to another notification
or operation.
invalid argument value: the event information value specified was out of range or otherwise
inappropriate.
invalid SOP Instance: the SOP Instance UID specified implied a violation of the UID
construction rules.
mistyped argument: one of the parameters supplied has not been agreed for use on the
Association between the DIMSE-service-users.
no such argument: the event information specified was not recognized.
no such event type: the event type specified was not recognized.
no such SOP class: the SOP Class was not recognized.
no such SOP Instance: the SOP Instance was not recognized.
processing failure: a general failure in processing the operation was encountered.
resource limitation: the operation was not performed due to resource limitation.
success: successful notification.
unrecognized operation: the operation is not one of those agreed between the DIMSE-service-
users.
10.1.1.2 N-EVENT-REPORT service procedures
The following N-EVENT-REPORT procedures apply:
Page 57
PS 3.7-2004
Page 47
a) The invoking DIMSE-service-user reports an event to the performing DIMSE-service-user by
issuing an N-EVENT-REPORT request primitive to the DIMSE-service-provider.
b) The DIMSE-service-provider issues an N-EVENT-REPORT indication primitive to the
performing DIMSE-service-user.
c) The performing DIMSE-service-user reports acceptance or rejection of the N-EVENT-REPORT
request primitive by issuing an N-EVENT-REPORT response primitive to the DIMSE-service­provider.
d) The DIMSE-service-provider issues an N-EVENT-REPORT confirmation primitive to the
invoking DIMSE-service-user, completing the N-EVENT-REPORT notification.
The performing DIMSE-service-user may return an N-EVENT-REPORT response primitive with the status of Failed or Refused before the entire N-EVENT-REPORT indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A N-EVENT-REPORT response primitive with the status of Success or Warning shall not be returned until the entire N-EVENT-REPORT indication has been received by the performing DIMSE-service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

10.1.2 N-GET Service

The N-GET service is used by a DIMSE-service-user to retrieve Attribute values from a peer DIMSE­service-user. It is a confirmed service.
10.1.2.1 N-GET Parameters
Table 10.1-2 lists the parameters for this service.
Table 10.1-2
N-GET PARAMETERS
DIMSE Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
Requested SOP Class UID M
Requested SOP Instance UID M
Attribute Identifier List U
Affected SOP Class UID
Affected SOP Instance UID
Attribute List
Status
M
U
U
C
M
10.1.2.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Note: The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to
support debug procedures.
Page 58
PS 3.7-2004 Page 48
10.1.2.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the operation request/indication to which this response/confirmation applies.
10.1.2.1.3 Requested SOP class UID
This parameter specifies the SOP Class for which Attribute Values are to be retrieved.
10.1.2.1.4 Requested SOP instance UID
This parameter specifies the SOP Instance for which Attribute Values are to be retrieved.
10.1.2.1.5 Attribute identifier list
This parameter contains a set of Attribute identifiers for which the Attribute Values are to be returned by the performing DIMSE-service-user. If this parameter is omitted, all Attribute identifiers are assumed. The definitions of the Attributes are found in the specification of the Information Object Definition in PS 3.3.
10.1.2.1.6 Affected SOP class UID
This parameter may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the Requested SOP Class UID parameter value used in the request/indication.
10.1.2.1.7 Affected SOP instance UID
This parameter specifies the SOP Instance for which Attribute Values are returned. It may be included in any response/confirmation and when included shall be equal to the Requested SOP Instance UID (0000,1001) parameter value used in the invocation.
10.1.2.1.8 Attribute list
This parameter contains the set of Attribute identifiers and values which are returned by the performing DIMSE-service-user. It shall be included in the success response/confirmation.
10.1.2.1.9 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in any response/confirmation. The following types of status may occur:
attribute list error: one or more Attribute Values were not read because the specified Attribute
was not recognized. The Attribute Values that could be read are returned.
class-instance conflict: the specified SOP Instance is not a member of the specified SOP
Class.
duplicate invocation: the Message ID (0000,0110) specified is allocated to another notification
or operation.
invalid SOP Instance: the SOP Instance UID specified implied a violation of the UID
construction rules.
mistyped argument: one of the parameters supplied has not been agreed for use on the
Association between the DIMSE-service-users.
no such SOP class: the SOP Class was not recognized.
no such SOP Instance: the SOP Instance was not recognized.
processing failure: a general failure in processing the operation was encountered.
resource limitation: the operation was not performed due to resource limitation.
success: successful operation.
Page 59
PS 3.7-2004
Page 49
unrecognized operation: the operation is not one of those agreed between the DIMSE-service-
users.
10.1.2.2 N-GET service procedures
The following N-GET procedures apply;
a) The invoking DIMSE-service-user requests the performing DIMSE-service-user to retrieve
Attribute Value(s) by issuing an N-GET request primitive to the DIMSE-service-provider.
b) The DIMSE-service-provider issues an N-GET indication primitive to the performing DIMSE-
service-user.
c) If the operation can be performed, then the performing DIMSE-service-user retrieves the
requested Attribute Value(s) and generates a response indicating acceptance of the N-GET request primitive by issuing an N-GET response primitive to the DIMSE-service-provider. In this case the following procedure does not apply.
d) If the operation cannot be performed, then the performing DIMSE-service-user rejects the N-
GET request by issuing an N-GET response primitive with the appropriate error code to the DIMSE-service-provider.
e) The DIMSE-service-provider issues an N-GET confirmation primitive to the invoking DIMSE-
service-user, completing the N-GET operation.

10.1.3 N-SET SERVICE

The N-SET service is used by a DIMSE-service-user to request the modification of Attribute Values from a peer DIMSE-service-user. It is a confirmed service.
10.1.3.1 N-SET parameters
Table 10.1-3 lists the parameters for this service.
Table 10.1-3
N-SET PARAMETERS
DIMSE Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
Requested SOP Class UID M
Requested SOP Instance UID M
Modification List M
Attribute List
Affected SOP Class UID
Affected SOP Instance UID
Status
M
U
U
U
M
10.1.3.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Page 60
PS 3.7-2004 Page 50
Note: The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to
support debug procedures.
10.1.3.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the operation request/indication to which this response/confirmation applies.
10.1.3.1.3 Requested SOP class UID
This parameter specifies the SOP Class for which Attribute Values are to be modified.
10.1.3.1.4 Requested SOP instance UID
This parameter specifies the SOP Instance for which Attribute Values are to be modified.
10.1.3.1.5 Modification list
This parameter contains the set of Attribute identifiers and values which are to be used by the performing DIMSE-service-user to replace the current values of the Attributes specified.
10.1.3.1.6 Attribute list
This parameter contains the set of Attribute identifiers and values which were used by the performing DIMSE-service-user to replace the values of the Attributes specified. It may be included in the success response/confirmation.
10.1.3.1.7 Affected SOP class UID
This parameter may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the Requested SOP Class UID parameter value used in the request/indication.
10.1.3.1.8 Affected SOP instance UID
This parameter specifies the SOP Instance for which Attribute Values were modified. It may be included in any response/confirmation and when included shall be equal to the Requested SOP Instance UID (0000,1001) parameter value used in the invocation.
10.1.3.1.9 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in any response/confirmation. The following types of status may occur:
class-instance conflict: the specified SOP Instance is not a member of the specified SOP
Class.
duplicate invocation: the Message ID (0000,0110) specified is allocated to another notification
or operation.
invalid Attribute Value: the Attribute Value specified was out of range or otherwise
inappropriate. The Attribute Values that could be modified were modified.
mistyped argument: one of the parameters supplied has not been agreed for use on the
Association between the DIMSE-service-users.
invalid SOP Instance: the SOP Instance UID specified implied a violation of the UID
construction rules.
missing Attribute Value: a required Attribute Value was not supplied.
no such Attribute: the Tag for the specified Attribute was not recognized. The Attribute Values
that could be modified were modified.
no such SOP class: the SOP Class was not recognized.
Page 61
PS 3.7-2004
Page 51
no such SOP Instance: the SOP Instance was not recognized.
processing failure: a general failure in processing the operation was encountered.
resource limitation: the operation was not performed due to resource limitation.
success: successful operation.
unrecognized operation: the operation is not one of those agreed between the DIMSE-service-
users.
10.1.3.2 N-SET service procedures
The following N-SET procedures apply:
a) The invoking DIMSE-service-user requests the performing DIMSE-service-user to modify
Attribute Value(s) by issuing an N-SET request primitive to the DIMSE-service-provider.
b) The DIMSE-service provider issues an N-SET indication primitive to the performing DIMSE-
service-user.
c) If the operation can be performed, then the performing DIMSE-service-user modifies the
requested Attribute Value(s) and generates a response indicating acceptance of the N-SET request primitive by issuing an N-SET response primitive to the DIMSE-service-provider. In this case the following procedure does not apply.
d) If the operation cannot be performed, then the performing DIMSE-service-user rejects the N-
SET request by issuing an N-SET response primitive with the appropriate error code to the DIMSE-service-provider.
e) The DIMSE-service-provider issues an N-SET confirmation primitive to the invoking DIMSE-
service-user, completing the N-SET operation.
The performing DIMSE-service-user may return an N-SET response primitive with the status of Failed or Refused before the entire N-SET indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A N-SET response primitive with the status of Success or Warning shall not be returned until the entire N-SET indication has been received by the performing DIMSE-service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

10.1.4 N-ACTION SERVICE

The N-ACTION service is used by a DIMSE-service-user to request an action by a peer DIMSE-service­user. It is a confirmed service.
10.1.4.1 N-ACTION parameters
Table 10.1-4 lists the parameters for this service.
Table 10.1-4
N-ACTION PARAMETERS
DIMSE Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
Requested SOP Class UID M
Requested SOP Instance UID M
M
Action Type ID M C(=)
Action Information U
Page 62
PS 3.7-2004 Page 52
Affected SOP Class UID
Affected SOP Instance UID
Action Reply
Status
U
U
C
M
10.1.4.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Note: The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to
support debug procedures.
10.1.4.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the operation request/indication to which this response/confirmation applies.
10.1.4.1.3 Requested SOP class UID
This parameter specifies the SOP Class for which the action is to be performed.
10.1.4.1.4 Requested SOP instance UID
This parameter specifies the SOP Instance on which the action is to be performed.
10.1.4.1.5 Action type ID
This parameter specifies a particular action which is to be performed. It may be included in the success response/confirmation and shall be included if the action reply parameter is included.
Note: Service Class Specifications contained in PS 3.4 defines any application usage of the Action Type ID
(0000,1008) parameter.
10.1.4.1.6 Action information
This parameter specifies extra application-specific information when necessary to further define the nature, variations, or operands of the action to be performed. The syntax and semantics of the parameter depend upon the action requested. It may only be included in the request/indication.
Note: Service Class Specifications contained in PS 3.4 defines any application usage of the Action Information
parameter.
10.1.4.1.7 Affected SOP class UID
This parameter may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the Requested SOP Class UID parameter value used in the request/indication.
10.1.4.1.8 Affected SOP instance UID
This parameter specifies the SOP Instance on which the action is to be performed. It may be included in any response/confirmation and when included shall be equal to the Requested SOP Instance UID (0000,1001) parameter value used in the invocation.
Page 63
PS 3.7-2004
Page 53
10.1.4.1.9 Action reply
This parameter contains the application-specific reply to the action. It may be included in the success response/confirmation.
Note: Service Class Specifications contained in PS 3.4 defines any application usage of the Action Reply
parameter.
10.1.4.1.10 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in any response/confirmation. The following type of status may occur:
class-instance conflict: the specified SOP Instance is not a member of the specified SOP
Class.
duplicate invocation: the Message ID (0000,0110) specified is allocated to another notification
or operation.
invalid argument value: the action information value specified was out of range or otherwise
inappropriate.
invalid SOP Instance: the SOP Instance UID specified implied a violation of the UID
construction rules.
mistyped argument: one of the parameters supplied has not been agreed for use on the
Association between the DIMSE-service-users.
no such action: the action type specified was not supported.
no such argument: the action information specified was not supported.
no such SOP class: the SOP Class was not recognized.
no such SOP Instance: the SOP Instance was not recognized.
processing failure: a general failure in processing the operation was encountered.
resource limitation: the operation was not performed due to resource limitation.
success: successful operation.
unrecognized operation: the operation is not one of those agreed between the DIMSE-service-
users.
10.1.4.2 N-ACTION service procedures
The following N-ACTION procedures apply:
a) The invoking DIMSE-service-user requests the performing DIMSE-service-user to perform an
action on a managed SOP Instance by issuing an N-ACTION request primitive to the DIMSE­service-provider.
b) The DIMSE-service provider issues an N-ACTION indication primitive to the performing
DIMSE-service-user.
c) If the operation can be performed, the performing DIMSE-service-user applies the action to
the specified SOP Instance and generates a response indicating acceptance of the N-ACTION request primitive by issuing an N-ACTION response primitive to the DIMSE-service-provider. In this case the following procedure does not apply. The Action Reply may be included in a successful response.
d) If the operation cannot be performed, then the performing DIMSE-service-user rejects the N-
ACTION request by issuing an N-ACTION response primitive with the appropriate error code to the DIMSE-service-provider.
Page 64
PS 3.7-2004 Page 54
e) The DIMSE-service-provider issues an N-ACTION confirmation primitive to the invoking
DIMSE-service-user, completing the N-ACTION operation.
The performing DIMSE-service-user may return an N-ACTION response primitive with the status of Failed or Refused before the entire N-ACTION indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A N-ACTION response primitive with the status of Success or Warning shall not be returned until the entire N-ACTION indication has been received by the performing DIMSE­service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

10.1.5 N-CREATE SERVICE

The N-CREATE service is used by a DIMSE-service-user to request a peer DIMSE-service-user to create a new managed SOP Instance, complete with its identification and the values of its associated Attributes, and simultaneously to register its identification. It is a confirmed service.
10.1.5.1 N-CREATE parameters
Table 10.1-5 lists the parameters for this service.
Table 10.1-5
N-CREATE PARAMETERS
DIMSE Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
M
Affected SOP Class UID M U(=)
Affected SOP Instance UID U C
Attribute List U U
Status
M
10.1.5.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Note: The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to
support debug procedures.
10.1.5.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the operation request/indication to which this response/confirmation applies.
10.1.5.1.3 Affected SOP class UID
For the request/indication, this parameter specifies the SOP Class of the new SOP Instance which is to be created by the performing DIMSE-service-user. The performing DIMSE-service-user assigns to the new SOP Instance, a set of Attribute Values as specified by the definition of its SOP Class. For the response/confirmation, this parameter specifies the SOP class of the SOP Instance which was created. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
Page 65
PS 3.7-2004
Page 55
10.1.5.1.4 Affected SOP instance UID
For the request/indication, this parameter specifies the SOP Instance which is used by the performing DIMSE-service-user. If the SOP Instance UID is not supplied by the invoking DIMSE-service-user, then the performing DIMSE-service-user assigns a value to this identification of instance. For the response/confirmation, this parameter may only be included in the success response/confirmation and shall be included if it is not supplied by the invoking DIMSE-service-user.
10.1.5.1.5 Attribute list
When this parameter is supplied by the invoking DIMSE-service-user, it contains a set of Attribute identifiers and values that the performing DIMSE-service-user is to assign to the new managed SOP Instance. When returned by the performing DIMSE-service-user, this parameter contains the complete list of all Attribute identifiers and values that were assigned to the new managed SOP Instance. It may be included in the success response/confirmation.
10.1.5.1.6 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in any response/confirmation. The following type of status may occur:
class-instance conflict: the specified SOP Instance is not a member of the specified SOP
Class.
duplicate invocation: the Message ID (0000,0110) specified is allocated to another notification
or operation.
duplicate SOP Instance: the new managed SOP Instance Value supplied by the invoking
DIMSE-service-user was already registered for a managed SOP Instance of the specified SOP Class.
invalid Attribute Value: the Attribute Value specified was out of range or otherwise
inappropriate.
invalid SOP Instance: the SOP Instance UID specified implied a violation of the UID
construction rules.
missing Attribute: a required Attribute was not supplied.
missing Attribute Value: a required Attribute Value was not supplied and a default value was
not available.
mistyped argument: one of the parameters supplied has not been agreed for use on the
Association between the DIMSE-service-users.
no such Attribute: the Tag for the specified Attribute was not recognized.
no such SOP class: the SOP Class was not recognized.
no such SOP Instance: the SOP Instance was not recognized.
processing failure: a general failure in processing the operation was encountered.
resource limitation: the operation was not performed due to resource limitation.
success: successful operation.
unrecognized operation: the operation is not one of those agreed between the DIMSE-service-
users.
10.1.5.2 N-CREATE service procedures
The following N-CREATE procedures apply:
a) The invoking DIMSE-service-user requests the creation and registration of a new managed
SOP Instance by issuing an N-CREATE request primitive to the DIMSE-service-provider.
Page 66
PS 3.7-2004 Page 56
b) The DIMSE-service provider issues an N-CREATE indication primitive to the performing
DIMSE-service-user.
c) If the operation can be performed, the performing DIMSE-service-user creates and registers
the new managed SOP Instance and generates a response indicating acceptance of the N­CREATE request primitive by issuing an N-CREATE response primitive to the DIMSE-service­provider. In this case the following procedure does not apply.
d) If the operation cannot be performed, then the performing DIMSE-service-user rejects the N-
CREATE request by issuing an N-CREATE response primitive with the appropriate error code to the DIMSE-service-provider.
e) The DIMSE-service-provider issues an N-CREATE confirmation primitive to the invoking
DIMSE-service-user, completing the N-CREATE operation.
The performing DIMSE-service-user may return an N-CREATE response primitive with the status of Failed or Refused before the entire N-CREATE indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A N-CREATE response primitive with the status of Success or Warning shall not be returned until the entire N-CREATE indication has been received by the performing DIMSE­service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.

10.1.6 N-DELETE SERVICE

The N-DELETE service is used by an invoking DIMSE-service-user to request a peer DIMSE-service­user to delete a managed SOP Instance and to de-register its identification. It is a confirmed service.
10.1.6.1 N-DELETE parameters
Table 10.1-6 lists the parameters for this service.
Table 10.1-6
N-DELETE PARAMETERS
DIMSE Parameter Name Req/Ind Rsp/Conf
Message ID M
Message ID Being Responded To
Requested SOP Class UID M
Requested SOP Instance UID M
Affected SOP Class UID
Affected SOP Instance UID
Status
M
U
U
M
10.1.6.1.1 Message ID
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Note: The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to
support debug procedures.
Page 67
PS 3.7-2004
Page 57
10.1.6.1.2 Message ID being responded to
This parameter specifies the Message ID (0000,0110) of the operation request/indication to which this response/confirmation applies.
10.1.6.1.3 Requested SOP class UID
This parameter specifies the SOP Class which is to be deleted.
10.1.6.1.4 Requested SOP instance UID
This parameter specifies the SOP Instance which is to be deleted.
10.1.6.1.5 Affected SOP class UID
This parameter may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the parameter value used in the request/indication.
10.1.6.1.6 Affected SOP instance UID
This parameter specifies the SOP Instance which was deleted. It may be included in any response/confirmation and when included shall be equal to the Requested SOP Instance UID (0000,1001) parameter value used in the invocation.
10.1.6.1.7 Status
This parameter contains the error or success notification for the operation. It shall be included by the performing DIMSE-service-user in any response/confirmation. The following types of status may occur
class-instance conflict: the specified SOP Instance is not a member of the specified SOP
Class
duplicate invocation: the Message ID (0000,0110) specified is allocated to another notification
or operation
invalid SOP Instance: the SOP Instance UID specified implied a violation of the UID
construction rules
mistyped argument: one of the parameters supplied has not been agreed for use on the
Association between the DIMSE-service-users
no such SOP class: the SOP Class was not recognized
no such SOP Instance: the SOP Instance was not recognized
processing failure: a general failure in processing the operation was encountered
resource limitation: the operation was not performed due to resource limitation
success: successful operation
unrecognized operation: the operation is not one of those agreed between the DIMSE-service-
users
10.1.6.2 N-DELETE service procedures
The following N-DELETE procedures apply:
a) The invoking DIMSE-service-user requests the performing DIMSE-service-user to delete a
managed SOP Instance by issuing an N-DELETE request primitive to the DIMSE-service­provider.
b) The DIMSE-service provider issues an N-DELETE indication primitive to the performing
DIMSE-service-user.
c) If the operation can be performed, the performing DIMSE-service-user deletes the specified
managed SOP Instance and generates a response indicating acceptance of the N-DELETE
Page 68
PS 3.7-2004 Page 58
request primitive by issuing an N-DELETE response primitive to the DIMSE-service-provider. In this case the following procedure does not apply.
d) If the operation cannot be performed, then the performing DIMSE-service-user rejects the N-
DELETE request by issuing an N-DELETE response primitive with the appropriate error code to the DIMSE-service-provider.
e) The DIMSE-service-provider issues an N-DELETE confirmation primitive to the invoking
DIMSE-service-user, completing the N-DELETE operation.

10.2 SEQUENCING

10.2.1 TYPES OF SERVICES

All operation and notifications shall be confirmed services.

10.2.2 USAGE RESTRICTIONS

These services may only be invoked within the context of an established Association.

10.2.3 DISRUPTED PROCEDURES

These services do not disrupt any other service procedure.

10.2.4 DISRUPTING PROCEDURES

These services are disrupted by the A-ABORT service procedure.

10.3 PROTOCOL

This section specifies the protocol necessary to perform the set of DIMSE-N operations and notifications. The Value Representations (VR) specified in the following tables shall be encoded as defined in PS 3.5.

10.3.1 N-EVENT-REPORT PROTOCOL

The information necessary for the N-EVENT-REPORT request and indication DIMSE-N primitives are conveyed in the N-EVENT-REPORT-RQ Message. The information necessary for the N-EVENT­REPORT response and confirmation DIMSE-N primitives are conveyed in the N-EVENT-REPORT-RSP Message.
10.3.1.1 N-EVENT-REPORT-RQ
The N-EVENT-REPORT-RQ Message contains fields as defined in Table 10.3-1. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-EVENT-REPORT service definition unless otherwise noted in Table 10.3-1. Fields not specified in the N-EVENT-REPORT service definition but present in Table 10.3-1 are required by the DIMSE-N protocol.
Table 10.3-1
N-EVENT-REPORT-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance for which
this event occurred.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N
notification conveyed by this Message. The value of this field shall be set to 0100H for the N-EVENT-REPORT-RQ Message.
Page 69
PS 3.7-2004
Page 59
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Affected SOP Instance UID
(0000,1000) UI 1 Contains the UID of the SOP Instance for
which this event occurred.
Event Type ID (0000,1002) US 1 Values for this field are application-specific.
Event Information (no tag)
Application-specific Data Set containing additional information related to the operation.
Notes: 1. Service Class Specifications contained in PS 3.4 defines the values needed for the Event Type ID
parameter.
2. Service Class Specifications contained in PS 3.4 defines the Data Set needed for the Event Information parameter.
10.3.1.2 N-EVENT-REPORT-RSP
The N-EVENT-REPORT-RSP Message contains fields as defined in Table 10.3-2 and Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-EVENT-REPORT service definition unless otherwise noted in Table 10.3-2. Fields not specified in the N-EVENT-REPORT service definition but present in Table 10.3-2 are required by the DIMSE-N protocol.
Table 10.3-2
N-EVENT-REPORT-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance for which
this event occurred.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 8100H for the N-EVENT­REPORT-RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated N­EVENT-REPORT-RQ Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Status (0000,0900) US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the
Page 70
PS 3.7-2004 Page 60
status types defined in the service definition.
Affected SOP Instance UID
(0000,1000) UI 1 Contains the UID of the SOP Instance for
which this event occurred.
Event Type ID (0000,1002) US 1 Values for this field are application-specific.
Event Reply (no tag)
Application-specific Data Set containing additional information related to the operation.
Notes: 1. Service Class Specifications contained in PS 3.4 defines the values needed for the Event Type ID
parameter.
2. Service Class Specifications contained in PS 3.4 defines the Data Set needed for the Event Reply parameter related to each defined Event Type ID.
10.3.1.3 N-EVENT-REPORT protocol procedures
The N-EVENT-REPORT reporting procedures are initiated by the invoking DIMSE-service-user issuing an N-EVENT-REPORT request primitive. On receipt of the N-EVENT-REPORT request primitive the DIMSE-N protocol machine shall:
construct a Message conveying the N-EVENT-REPORT-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-EVENT-REPORT-RQ the DIMSE-N protocol machine shall issue an N-EVENT-REPORT indication primitive to the performing DIMSE-service-user.
On receipt of the N-EVENT-REPORT response primitive issued by the performing DIMSE-service-user, the DIMSE-N protocol machine shall:
construct a Message conveying the N-EVENT-REPORT-RSP
send the Message using the P-DATA request service (See Section 8.1)
On receipt of a Message conveying an N-EVENT-REPORT-RSP the DIMSE-N protocol machine shall issue an N-EVENT-REPORT confirmation primitive to the invoking DIMSE-service-user, thus completing the notification procedure.
The performing DIMSE-service-user may return an N-EVENT-REPORT-RSP with the status of Failed or Refused before the complete N-EVENT-REPORT-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused N-EVENT-REPORT-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before an N-EVENT-REPORT-RQ Message has been completely transmitted if it has not received a Failed or Refused N-EVENT-REPORT-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.
Page 71
PS 3.7-2004
Page 61

10.3.2 N-GET PROTOCOL

The information necessary for the N-GET request and indication DIMSE-N primitives are conveyed in the N-GET-RQ Message. The information necessary for the N-GET response and confirmation DIMSE-N primitives are conveyed in the N-GET-RSP Message.
10.3.2.1 N-GET-RQ
The N-GET-RQ Message contains fields as defined in Table 10.3-3. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-GET service definition unless otherwise noted in Table 10.3-3. Fields not specified in the N-GET service definition but present in Table 10.3-3 are required by the DIMSE-N protocol.
Table 10.3-3
N-GET-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Requested SOP Class UID (0000,0003) UI 1 SOP Class UID of the SOP Instance for which
Attribute Values are to be retrieved.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 0110H for the N-GET-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set shall be
present in the Message. This field shall be set to the value of 0101H).
Requested SOP Instance UID
(0000,1001) UI 1 Contains the UID of the SOP Instance for
which Attribute Values are to be retrieved.
Attribute Identifier List (0000,1005) AT 1-n This field contains an Attribute Tag for each of
the n Attributes applicable to the N-GET operation.
10.3.2.2 N-GET-RSP
The N-GET-RSP Message contains fields as defined in Table 10.3-4 and Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-GET service definition unless otherwise noted in Table 10.3-4. Fields not specified in the N-GET service definition but present in Table 10.3-4 are required by the DIMSE-N protocol.
Table 10.3-4
N-GET-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the value
field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance for which Attribute
Values are returned.
Page 72
PS 3.7-2004 Page 62
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 8110H for the N-GET-RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID (0000,0110)
field used in associated N-GET-RQ Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in the
Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Status (0000,0900) US 1 The value of this field depends upon the status type.
Annex C defines the encoding of the status types defined in the service definition.
Affected SOP Instance UID
Attribute List (no tag)
(0000,1000) UI 1 Contains the UID of the SOP Instance for which
Attribute Values are returned.
T his field is encoded as a Data Set. One Data Element is encoded for each Attribute Value returned.
Note: The permitted contents of Attribute List, encoded as a series of Data Elements, are defined in the
Information Object Definition (PS 3.3) and Service Class Specifications (PS 3.4).
10.3.2.3 N-GET protocol procedures
The N-GET procedures are initiated by the invoking DIMSE-service-user issuing an N-GET request primitive. On receipt of the N-GET request primitive the DIMSE-N protocol machine shall:
construct a Message conveying the N-GET-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-GET-RQ the DIMSE-N protocol machine shall issue an N-GET indication primitive to the performing DIMSE-service-user.
On receipt of the N-GET response primitive, issued by the performing DIMSE-service-user, the DIMSE-N protocol machine shall:
construct a Message conveying the N-GET-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-GET-RSP the DIMSE-N protocol machine shall issue an N-GET confirmation primitive to the invoking DIMSE-service-user, thus completing the N-GET procedure.

10.3.3 N-SET PROTOCOL

The information necessary for the N-SET request and indication DIMSE-N primitives are conveyed in the N-SET-RQ Message. The information necessary for the N-SET response and confirmation DIMSE-N primitives are conveyed in the N-SET-RSP Message. Fields not specified in the N-SET service definition but present in Table 10.3-3 are required by the DIMSE-N protocol.
10.3.3.1 N-SET-RQ
The N-SET-RQ Message contains fields as defined in Table 10.3-5. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-SET
Page 73
PS 3.7-2004
Page 63
service definition unless otherwise noted in Table 10.3-5. Fields not specified in the N-SET service definition but present in Table 10.3-5 are required by the DIMSE-N protocol.
Table 10.3-5
N-SET-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Requested SOP Class UID
(0000,0003) UI 1 SOP Class UID of the SOP Instance for which
Attribute values are to be modified.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 0120H for the N-SET-RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Data Set Type (0000,0800) US 1 This field indicates that a Data Set is present in
the Message. It shall be set to any value other than 0101H (Null).
Requested SOP Instance UID
Modification List
(0000,1001) UI 1 Contains the UID of the SOP Instance for
which Attribute values are to be modified.
(no tag)
This field is encoded as a Data Set. One Data Element is encoded for each Attribute and Attribute Value applicable to the operation.
Note: Τhe permitted contents of Modification List, encoded as a series of Data Elements, are defined in the
Information Object Definition (PS 3.3) and Service Class Specifications (PS 3.4).
10.3.3.2 N-SET-RSP
The N-SET-RSP Message contains all fields as defined in Table 10.3-6 and in Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-SET service definition unless otherwise noted. Fields not specified in the N-SET service definition but present in Table 10.3-6 are required by the DIMSE-N protocol.
Table 10.3-6
N-SET-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance for which
Attribute Values were modified.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 8120H for the N-SET-RSP Message.
Page 74
PS 3.7-2004 Page 64
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated N-SET­RQ Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Status (0000,0900) US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
Affected SOP Instance UID
Attribute List (no tag)
(0000,1000) UI 1 Contains the UID of the SOP Instance for
which Attribute Values were modified.
This field is encoded as a Data Set. One Data Element is encoded for each Attribute and Attribute Value applicable to the operation.
Note: The permitted contents of Attribute List, encoded as a series of Data Elements, are defined in the
Information Object Definition (PS 3.3) and Service Class Specifications (PS 3.4).
10.3.3.3 N-SET protocol procedures
The N-SET procedures are initiated by the invoking DIMSE-service-user issuing an N-SET request primitive. On receipt of the N-SET request primitive the DIMSE-N protocol machine shall:
construct a Message conveying the N-SET-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-SET-RQ the DIMSE-N protocol machine shall issue an N-SET indication primitive to the performing DIMSE-service-user.
On receipt of the N-SET response primitive, issued by the performing DIMSE-service-user, the DIMSE-N protocol machine shall:
construct a Message conveying the N-SET-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-SET-RSP the DIMSE-N protocol machine shall issue an N-SET confirmation primitive to the invoking DIMSE-service-user, thus completing the N-SET procedure.
The performing DIMSE-service-user may return an N-SET-RSP with the status of Failed or Refused before the complete N-SET-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused N­SET-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before an N-SET-RQ Message has been completely transmitted if it has not received a Failed or Refused N-SET-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may
Page 75
PS 3.7-2004
Page 65
receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.

10.3.4 N-ACTION PROTOCOL

The information necessary for the N-ACTION request and indication DIMSE-N primitives are conveyed in the N-ACTION-RQ Message. The information necessary for the N-ACTION response and confirmation DIMSE-N primitives are conveyed in the N-ACTION-RSP Message.
10.3.4.1 N-ACTION-RQ
The N-ACTION-RQ Message contains fields as defined in Table 10.3-7. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-ACTION service definition unless otherwise noted in Table 10.3-7. Fields not specified in the N­ACTION service definition but present in Table 10.3-7 are required by the DIMSE-N protocol.
Table 10.3-7
N-ACTION-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Requested SOP Class UID
(0000,0003) UI 1 SOP Class UID of the SOP Instance for which
the action is to be performed.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 0130H for the N-ACTION­RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Requested SOP Instance UID
(0000,1001) UI 1 Contains the UID of the SOP Instance for
which the action is to be performed.
Action Type ID (0000,1008) US 1 Values for this field are application-specific.
Action Information (no tag)
Application-specific Data Set containing additional information related to the operation.
Notes: 1. Service Class Specifications contained in Part 4 of the DICOM Standard defines the values needed
for the Action Type ID (0000,1008) parameter.
2. Service Class Specifications contained in Part 4 of the DICOM Standard defines the Data Set needed for the Action Reply parameter related to each defined Action Type ID.
3. Service Class Specifications contained in Part 4 of the DICOM Standard defines the encoding of the Action Reply parameter.
Page 76
PS 3.7-2004 Page 66
10.3.4.2 N-ACTION-RSP
The N-ACTION-RSP Message contains fields as defined in Table 10.3-8 and Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-ACTION service definition unless otherwise noted in Table 10.3-8. Fields not specified in the N-ACTION service definition but present in Table 10.3-8 are required by the DIMSE-N protocol.
Table 10.3-8
N-ACTION-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance for which
the action was performed.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 8130H for the N-ACTION­RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated N­ACTION-RQ Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Status (0000,0900) US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
Affected SOP Instance UID
(0000,1000) UI 1 Contains the UID of the SOP Instance for
which the action was performed.
Action Type ID (0000,1008) US 1 Values for this field are application-specific.
Action Reply (no tag)
Application-specific Data Set containing additional information related to the operation.
Note: 1. Service Class Specifications contained in PS 3.4 defines the values needed for the Action Type ID
(0000,1008) parameter.
2. Service Class Specifications contained in PS 3.4 defines the Data Set needed for the Action Information parameter.
10.3.4.3 N-ACTION protocol procedures
The N-ACTION procedures are initiated by the invoking DIMSE-service-user issuing an N-ACTION request primitive. On receipt of the N-ACTION request primitive the DIMSE-N protocol machine shall:
construct a Message conveying the N-ACTION-RQ
send the Message using the P-DATA request service (See 8.1)
Page 77
PS 3.7-2004
Page 67
On receipt of a Message conveying an N-ACTION-RQ the DIMSE-N protocol machine shall issue an N­ACTION indication primitive to the performing DIMSE-service-user.
On receipt of the N-ACTION response primitive, issued by the performing DIMSE-service-user, the DIMSE-N protocol machine shall:
construct a Message conveying the N-ACTION-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-ACTION-RSP the DIMSE-N protocol machine shall issue an N­ACTION confirmation primitive to the invoking DIMSE-service-user, thus completing the N-ACTION procedure.
The performing DIMSE-service-user may return an N-ACTION-RSP with the status of Failed or Refused before the complete N-ACTION-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused N­ACTION-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before an N-ACTION-RQ Message has been completely transmitted if it has not received a Failed or Refused N-ACTION-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.

10.3.5 N-CREATE PROTOCOL

The information necessary for the N-CREATE request and indication DIMSE-N primitives are conveyed in the N-CREATE-RQ Message. The information necessary for the N-CREATE response and confirmation DIMSE-N primitives are conveyed in the N-CREATE-RSP Message.
10.3.5.1 N-CREATE-RQ
The N-CREATE-RQ Message contains fields as defined in Table 10.3-9. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-CREATE service definition unless otherwise noted in Table 10.3-9. Fields not specified in the N­CREATE service definition but present in Table 10.3-9 are required by the DIMSE-N protocol.
Table 10.3-9
N-CREATE-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance to be
created.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 0140H for the N-CREATE­RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other
Page 78
PS 3.7-2004 Page 68
Messages.
Data Set Type (0000,0800) US 1 This field indicates that if a Data Set is present
in the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Affected SOP Instance UID
Attribute List (no tag)
(0000,1000) UI 1 Contains the UID of the SOP Instance to be
created.
This field is encoded as a Data Set. One Data Element is encoded for each Attribute and Attribute Value applicable to the operation.
Note: The permitted contents of Attribute List, encoded as a series of Data Elements, are defined in the
Information Object Definition (PS 3.3) and Service Class Specifications (PS 3.4).
10.3.5.2 N-CREATE-RSP
The N-CREATE-RSP Message contains fields as defined in Table 10.3-10 and Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-CREATE service definition unless otherwise noted in Table10.3-10. Fields not specified in the N-CREATE service definition but present in Table 10.3-10 are required by the DIMSE-N protocol.
Table 10.3-10
N-CREATE-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance which
was created.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 8140H for the N-CREATE­RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated N­CREATE-RQ Message.
Data Set Type (0000,0800) US 1 This field indicates if a Data Set is present in
the Message. This field shall be set to the value of 0101H if no Data Set is present; any other value indicates a Data Set is included in the Message.
Status (0000,0900) US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
Affected SOP Instance UID
Attribute List (no tag)
(0000,1000) UI 1 Contains the UID of the SOP Instance which
was created.
This field is encoded as a Data Set. One Data
Page 79
PS 3.7-2004
Page 69
Element is encoded for each Attribute and Attribute Value applicable to the operation.
Note: The permitted contents of Attribute List, encoded as a series of Data Elements, are defined in the
Information Object Definition (PS 3.3) and Service Class Specifications (PS 3.4).
10.3.5.3 N-CREATE protocol procedures
The N-CREATE procedures are initiated by the invoking DIMSE-service-user issuing an N-CREATE request primitive. On receipt of the N-CREATE request primitive the DIMSE-N protocol machine shall:
construct a Message conveying the N-CREATE-RQ
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-CREATE-RQ the DIMSE-N protocol machine shall issue an N­CREATE indication primitive to the performing DIMSE-service-user.
On receipt of the N-CREATE response primitive, issued by the performing DIMSE-service-user, the DIMSE-N protocol machine shall:
construct a Message conveying the N-CREATE-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-CREATE-RSP the DIMSE-N protocol machine shall issue an N­CREATE confirmation primitive to the invoking DIMSE-service-user, thus completing the N-CREATE procedure.
The performing DIMSE-service-user may return an N-CREATE-RSP with the status of Failed or Refused before the complete N-CREATE-RQ request Message has been completely transmitted by the invoking DIMSE-service-user (this is called an early failed response). Upon receipt of this Failed or Refused N­CREATE-RSP the invoking DIMSE-service-user may terminate the Message before it is completely sent (i.e. set the Last Fragment bit to 1 in a Data PDV for this Message, see Annex F). Following this, it may invoke another operation or notification. It is a protocol violation for an invoking DIMSE-service-user to set the Last Fragment bit to 1 before an N-CREATE-RQ Message has been completely transmitted if it has not received a Failed or Refused N-CREATE-RSP to that request.
Note: When an Association is operating in asynchronous mode, it is possible for an invoking DIMSE-service-
user to transmit several Messages before a response. Therefore, while sending a Message it may receive a response to a previously transmitted Message. In this case this response is not an early failed response because the related Message has already been sent.

10.3.6 N-DELETE PROTOCOL

The information necessary for the N-DELETE request and indication DIMSE-N primitives are conveyed in the N-DELETE-RQ Message. The information necessary for the N-DELETE response and confirmation DIMSE-N primitives are conveyed in the N-DELETE-RSP Message.
10.3.6.1 N-DELETE-RQ
The N-DELETE-RQ Message contains fields as defined in Table 10.3-11. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the
Page 80
PS 3.7-2004 Page 70
N-DELETE service definition unless otherwise noted in Table 10.3-11. Fields not specified in the N­DELETE service definition but present in Table 10.3-11 are required by the DIMSE-N protocol.
Table 10.3-11
N-DELETE-RQ MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Requested SOP Class UID
(0000,0003) UI 1 SOP Class UID of the SOP Instance to be
deleted.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 0150H for the N-DELETE­RQ Message.
Message ID (0000,0110) US 1 Implementation-specific value which
distinguishes this Message from other Messages.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present
in the Message. It shall be set to the value of 0101H.
Requested SOP Instance UID
(0000,1001) UI 1 Contains the UID of the SOP Instance to be
deleted.
10.3.6.2 N-DELETE-RSP
The N-DELETE-RSP Message contains fields as defined in Table 10.3-12 and Annex C. Each field shall conform to DICOM encoding and Value Representation as defined in PS 3.5. Fields are required as specified in the N-DELETE service definition unless otherwise noted in Table 10.3-12. Fields not specified in the N-DELETE service definition but present in Table 10.3-12 are required by the DIMSE-N protocol.
Table10.3-12
N-DELETE-RSP MESSAGE FIELDS
Message Field Tag VR VM Description of Field
Group Length (0000,0000) UL 1 The even number of bytes from the end of the
value field to the beginning of the next group.
Affected SOP Class UID
(0000,0002) UI 1 SOP Class UID of the SOP Instance which
was deleted.
Command Field (0000,0100) US 1 This field distinguishes the DIMSE-N operation
conveyed by this Message. The value of this field shall be set to 8150H for the N-DELETE­RSP Message.
Message ID Being Responded To
(0000,0120) US 1 Shall be set to the value of the Message ID
(0000,0110) field used in associated N­DELETE-RQ Message.
Data Set Type (0000,0800) US 1 This field indicates that no Data Set is present
in the Message. This field shall be set to the
Page 81
PS 3.7-2004
Page 71
value of 0101H).
Status (0000,0900) US 1 The value of this field depends upon the status
type. Annex C defines the encoding of the status types defined in the service definition.
Affected SOP Instance UID
(0000,1000) UI 1 Contains the UID of the SOP Instance which
was deleted.
10.3.6.3 N-DELETE protocol procedures
The N-DELETE procedures are initiated by the invoking DIMSE-service-user issuing an N-DELETE request primitive. On receipt of the N-DELETE request primitive the DIMSE-N protocol machine shall:
construct a Message conveying the N-DELETE-RQ
end the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-DELETE-RQ the DIMSE-N protocol machine shall issue an N­DELETE indication primitive to the performing DIMSE-service-user.
On receipt of the N-DELETE response primitive, issued by the performing DIMSE-service-user, the DIMSE-N protocol machine shall:
construct a Message conveying the N-DELETE-RSP
send the Message using the P-DATA request service (See 8.1)
On receipt of a Message conveying an N-DELETE-RSP the DIMSE-N protocol machine shall issue an N­DELETE confirmation primitive to the invoking DIMSE-service-user, thus completing the N-DELETE procedure.
Page 82
PS 3.7-2004 Page 72
Annex A Application Context Usage
(Normative)

A.1 APPLICATION CONTEXT DEFINITION

An Application Context explicitly defines the set of application service elements, related options and any other information necessary for the inter working of Application Entities on an Association; in particular, it specifies the DIMSE Protocol used by the Application Layer.
Two Application Entities establish an Association by agreeing on an Application Context. The requester of an Association proposes an Application Context Name and the acceptor returns either the same or a different Application Context Name. The returned name specifies the Application Context to be used for this Association. The offer of an alternate Application Context by the acceptor provides a mechanism for limited negotiation. If the requester cannot operate in the acceptor's Application Context, it shall issue an A-Abort request primitive. Such a negotiation will facilitate the introduction of new versions of the DICOM Message Exchange Protocol in the future.

A.2 DICOM APPLICATION CONTEXT NAME ENCODING AND REGISTRATION

The Application Context Name structure is based on the OSI Object Identification (numeric form) as defined by ISO 8824. Specific rules are defined in PS 3.5. Application Context Names are registered values as defined by ISO 9834-3 to ensure global uniqueness. Application Context Names shall be encoded as defined in PS 3.8.

A.2.1 DICOM Registered Application Context Names

The organization responsible for the definition and registration of DICOM Application Context Names is ACR-NEMA. ACR-NEMA guarantees uniqueness for all DICOM Application Context Names. A choice of DICOM registered Application Context Names related to a specific version of DIMSE, as well as the associated negotiation rules, are defined in this annex.
A single DICOM Application Context Name is defined for this version of this Standard. This name is "1.2.840.10008.3.1.1.1"

A.2.2 Privately defined application context names

Privately defined Application Context Names may also be used, but they will not be registered by ACR­NEMA. Organizations which define private Application Context Names are responsible to obtain their proper registration as defined for OSI Object Identifiers. National Standards Organizations representing a number of countries (e.g. UK, France, Germany, Japan, USA, etc.) to the International Standards Organization act as a registration authority as defined by ISO 9834-3.
Note: For example, in the USA, ANSI assigns Organization Identifiers to any requesting organization. This
identifier is made of a series of four numeric elements; 1 (identifies ISO), 2 (identifies the ISO member bodies branch), 840 (identifies ANSI as the ISO member body representing the USA), and xxxxxx (identifies a specific organization and is issued by ANSI). Such an identifier may be used by the identified organization as a root to which it may add a suffix made of one or more numeric elements. The identified organization accepts the responsibility to properly register these suffixes to ensure uniqueness.
Privately defined Application Context Names shall be encoded as defined in PS 3.8. The Organization identifier "1.2.840.10008" is reserved for DICOM and shall not be used for privately defined Application Context Names.
Page 83
PS 3.7-2004
Page 73

A.3 ASSOCIATION INITIALIZATION FOR DICOM APPLICATION ENTITY

The establishment of an Association involves two DICOM AEs, one that is the Association-requester and one that is the Association-acceptor.
A DICOM AE shall initiate an Association establishment by using the A-ASSOCIATE request service defined in PS 3.8. It shall provide the Application Association Information as defined by Annex D.

A.4 OPERATION/NOTIFICATION FOR DICOM APPLICATION ENTITY

Operations and notifications are only used on an Association. They result in Messages exchanged by using the P-DATA request service defined in PS 3.8.
All operations and notifications invoked over an Association shall be confirmed. The performing DICOM AE shall report the response of each operation or notification over the same Association by means of which the operation or notification was invoked. No recovery shall be performed using multiple Associations.
Operations and notifications, on an Association, shall use one of the following two modes:
synchronous, where the invoking DICOM AE, on a established Association, requires a
response from the performing DICOM AE before invoking another operation or notification
asynchronous, where the invoking DICOM AE, on a established Association, may continue to
invoke further operations or notifications to the performing DICOM AE without awaiting a response
Note: The synchronous/asynchronous mode is defined within the scope of one Application Entity and not within
the scope of the association between two Application Entities. The communication mode on the association may be bi-directional if agreed upon during association negotiation (i.e. both operation and notifications are simultaneously supported, etc.). Following is an example of synchronous mode, DICOM AE A may send an operation request to DICOM AE B and DICOM AE B may send a notification request to DICOM AE A before responding to the operation request from AE A. This is considered as synchronous mode because each AE has only one outstanding operation or notification.
The mode selected (synchronous or asynchronous) is determined at Association establishment time. The synchronous mode serves as the default mode and shall be supported by all DICOM AEs. The asynchronous mode is optional and the maximum number of outstanding operations or notifications is negotiated during Association establishment. This negotiation is accomplished by the Asynchronous Operations Window sub-item structure as defined in Annex D.

A.5 ASSOCIATION RELEASE FOR DICOM AE

Only the DICOM AE Association-requester may initiate an orderly release of the Association. This shall be accomplished by using the A-RELEASE service defined in PS 3.8.
The DICOM AE Association-requester shall not release the Association until all operations invoked have been confirmed.

A.6 ASSOCIATION ABORT FOR DICOM AE

Either DICOM AE may initiate an abrupt termination of an Association. This shall be accomplished by using the A-ABORT service defined in PS 3.8.
Upon receiving or issuing the A-ABORT service primitive, the DICOM AE Association-requester and DICOM AE Association-acceptor shall fail any operation which is outstanding.
Page 84
PS 3.7-2004 Page 74
Note: The Association services and presentation services defined in the Upper Layer Service in PS 3.8 are a
fully conformant subset of the services offered by the ACSE and the OSI Presentation Layer.
Page 85
PS 3.7-2004
Annex B Index to Application Context Name UIDs
(Informative)
1.2.840.10008.3.1.1.1.....................................................................................................................81
Page 75
Page 86
PS 3.7-2004 Page 76
Annex C Status Type Encoding
(Normative)
The following sections define the encoding for the Status Types supported by the DIMSE services. The semantics for each Status Type (i.e. Attribute List Error, etc.) are defined in the DIMSE Services. Each Status Type is categorized in a Status Class.
Note: The Status (0000,0900) Command Element is required for all Status Types.

C.1 SUCCESS STATUS CLASS

Statuses in this Status Class convey that the operation/notification completed successfully.

C.1.1 Success

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0000H.

C.2 PENDING STATUS CLASS

Statuses in this Status Class convey that the operation/notification is continuing and additional Statuses are expected.

C.2.1 Pending

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field is Service Class specific and defined in PS 3.4.

C.3 CANCEL STATUS CLASS

Statuses in this Status Class convey that the operation/notification has been canceled.

C.3.1 Cancel

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to FE00H.
Page 87
PS 3.7-2004
Page 77

C.4 WARNING STATUS CLASS

Statuses in this Status Class convey that the operation/notification has completed but an error was detected. The semantics and behavior of these Statuses are defined in PS 3.4.

C.4.1 Warning

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value of
this required field is Service Class specific and defined in PS 3.4.
Offending Element (0000,0901) AT 1-n This optional field contains a list of the elements in
which the error was detected.
Error Comment (0000,0902) LO 1 This optional field contains an application-specific
text description of the error detected.

C.4.2 Attribute list error

Status Field Tag VR VM Description of Field
Affected SOP Class UID
(0000,0002) UI 1 This optional field contains the SOP Class UID for
which Attributes were not recognized.
Status (0000,0900) US 1 Confirmation status of the operation. The value of
this required field shall be set to 0107H.
Affected SOP Instance UID
(0000,1000) UI 1 This optional field contains the UID of the SOP
Instance for which Attributes were not recognized.
Attribute Identifier List (0000,1005) AT 1-n This optional field contains an Attribute Tag for
each Attribute which were not recognized.

C.4.3 Attribute Value Out of Range

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value of
this required field shall be set to 0116H.
Modification List/Attribute List
(no tag)
Optionally contains the application specific Data Set to only encode the invalid Attribute Values conveyed in the Modification List of the N-SET-RQ or the Attribute List of the N-CREATE-RQ.

C.5 FAILURE STATUS CLASS

Statuses in this Status Class convey that the operation/notification failed and was not performed.

C.5.1 Error: cannot understand

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field is Service Class specific
Page 88
PS 3.7-2004 Page 78
and defined in PS 3.4.
Offending Element (0000,0901) AT 1-n This optional field contains a list of the
elements in which the error was detected.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.

C.5.2 Error: Data Set does not match SOP class

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field is Service Class specific and defined in PS 3.4.
Offending Element (0000,0901) AT 1-n This optional field contains a list of the
elements in which the error was detected.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.

C.5.3 Failed

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field is Service Class specific and defined in PS 3.4.
Offending Element (0000,0901) AT 1-n This optional field contains a list of the
elements in which the error was detected.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.

C.5.4 Refused: move destination unknown

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field is Service Class specific and defined in PS 3.4.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.

C.5.5 Refused: out of resources

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field is Service Class specific and defined in PS 3.4.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.
Page 89
PS 3.7-2004
Page 79

C.5.6 Refused: SOP class not supported

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0122H.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.

C.5.7 Class-instance conflict

Status Field Tag VR VM Description of Field
Requested SOP Class UID
(0000,0003) UI 1 This optional field contains the SOP Class UID
for which the SOP Instance was not a member.
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0119H.
Requested SOP Instance UID
(0000,1001) UI 1 This optional field contains the SOP Instance
which was not a member of the specified SOP Class.

C.5.8 Duplicate SOP instance

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0111H.
Affected SOP Instance UID
(0000,1000) UI 1 This optional field contains the SOP Instance
UID which was already allocated to another SOP Instance.

C.5.9 Duplicate invocation

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0210H.

C.5.10 Invalid argument value

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0115H.
Affected SOP Class UID
Affected SOP Instance UID
(0000,0002) UI 1 This optional field contains the SOP Class UID
for which an argument value was in error.
(0000,1000) UI 1 This optional field contains the ID of the SOP
Instance for which an argument value was in error.
Event Type ID (0000,1002) US 1 This optional field contains the UID of the
Event Type which was not recognized.
Page 90
PS 3.7-2004 Page 80
Permitted only in the N-EVENT-RSP.
Event Information (no tag)
Optionally contains the application specific Data Set to only encode the invalid argument values conveyed in the Event Information of the request. Permitted only in the N-EVENT­REPORT-RSP.
Action Type ID (0000,1008) US 1 This optional field contains the ID of the Action
Type which was not recognized. Permitted only in the N-ACTION-RSP.
Action Information (no tag)
Optionally contains the application specific Data Set to only encode the invalid argument values conveyed in the N-ACTION-RQ. Permitted only in the N-ACTION-RSP.

C.5.11 Invalid attribute value

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0106H.
Modification List/Attribute List
(no tag)
Optionally contains the application specific Data Set to only encode the invalid Attribute Values conveyed in the Modification List of the N-SET -RQ or the Attribute List of the N­CREATE-RQ.

C.5.12 Invalid object instance

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0117H.
Affected SOP Instance UID
(0000,1000) UI 1 This optional field contains the SOP Instance
UID which violated the UID construction rules.

C.5.13 Missing attribute

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0120H.
Attribute Identifier List (0000,1005) AT 1-n This optional field contains an Attribute Tag for
each Attribute which was not recognized.

C.5.14 Missing attribute value

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0121H.
Modification (no tag)
Optionally contains the application specific
Page 91
PS 3.7-2004
Page 81
List/Attribute List Data Set to only encode missing Attribute
Values conveyed Modification List of the N­SET -RQ or the Attribute List of the N­CREATE-RQ..

C.5.15 Mistyped argument

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0212H.

C.5.16 No such argument

Status Field Tag VR VM Description of Field
Affected SOP Class UID
(0000,0002) UI 1 This optional field shall optionally contain the
SOP Class UID for which the argument does not exist.
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0114H.
Event Type ID (0000,1002) US 1 This optional field contains the ID of the Event
Type for which the argument does not exist. Permitted only in the N-EVENT-REPORT­RSP.
Action Type ID (0000,1008) US 1 This optional field contains the ID of the Action
Type for which the argument does not exist. Permitted only in the N-ACTION-RSP.

C.5.17 No such attribute

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0105H.
Attribute Identifier List (0000,1005) AT 1-n This optional field contains an Attribute Tag for
each Attribute which was not recognized.

C.5.18 No such event type

Status Field Tag VR VM Description of Field
Affected SOP Class UID
(0000,0002) UI 1 This optional field contains the SOP Class UID
for which the event type does not exist.
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0113H.
Event Type ID (0000,1002) US 1 This optional field contains the ID of the Event
Type which does not exist.
Page 92
PS 3.7-2004 Page 82

C.5.19 No Such object instance

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0112H.
Affected SOP Instance UID
(0000,1000) UI 1 This optional field contains the SOP Instance
UID which did not exist.

C.5.20 No Such SOP class

Status Field Tag VR VM Description of Field
Affected SOP Class UID
(0000,0002) UI 1 This optional field contains the SOP Class UID
which does not exist.
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0118H.

C.5.21 Processing failure

Status Field Tag VR VM Description of Field
Affected SOP Class UID
(0000,0002) UI 1 This optional field contains the SOP Class UID
on which the processing failure occurred.
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0110H.
Error Comment (0000,0902) LO 1 This optional field contains an application-
specific text description of the error detected.
Error ID (0000,0903) US 1 This optional field contains an application-
specific error code.
Affected SOP Instance UID
(0000,1000) UI 1 This optional field shall optionally contain the
UID of the SOP Instance on which the processing failure occurred.

C.5.22 Resource limitation

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0213H.

C.5.23 Unrecognized operation

Status Field Tag VR VM Description of Field
Status (0000,0900) US 1 Confirmation status of the operation. The value
of this required field shall be set to 0211H.

C.5.24 No such action type

Status Field Tag VR VM Description of Field
Page 93
PS 3.7-2004
Page 83
Affected SOP Class UID
Status (0000,0900) US 1 Confirmation status of the operation. The value
Action Type ID (0000,1008) US 1 This optional field contains the ID of the Action
(0000,0002) UI 1 This optional field contains the SOP Class UID
for which the action type does not exist.
of this required field shall be set to 0123H.
Type which does not exist.
Page 94
PS 3.7-2004 Page 84
Annex D Association Negotiation
(Normative)
Association establishment is the first phase of any instance of communication between peer DICOM AEs. The AEs use the Association establishment to negotiate how data will be encoded and the type of data to be exchanged. This Annex provides an overview of the negotiation mechanisms plus a discussion of each concept, its objectives, relationships, usage principles and specifications.

D.1 ABSTRACT SYNTAX

Abstract Syntaxes specify the Application Layer Data Elements and Application Layer protocol control information (with associated semantics) which are independent of the encoding technique used to represent them.
Each Abstract Syntax shall be identified by an Abstract Syntax Name in the form of a UID. DICOM AEs use the Abstract Syntax Name to identify and negotiate which SOP Classes and related options are supported on a specific Association. Abstract Syntax Names shall be defined in the Service Class Definitions specified in PS 3.4. Each Abstract Syntax Name defined shall have a value of either
a Service-Object Pair Class UID
a Meta Service-Object Pair Group UID

D.1.1 Service-object pair class UID

Each Service Class Definition defines one or more functionally-related Service-Object Pair (SOP) Class definitions which specify well-defined operations and/or notifications which may be performed between peer DICOM Application Entities to provide an application-level service. Each SOP Class, identified by a SOP Class UID, is defined by the union of one Information Object Definition (IOD) and a specific set of one or more DIMSE Services called the DIMSE Service Group (DSG) in that
The IOD defines the data structures
The DSG defines the operations and/or notifications that can be performed on this data
structure.
Two SOP Classes defined by a single Service Class Definition may differ by the IOD, the DSG or both. Two different IODs shall not, however, be part of the same SOP Class. Figure D.1.1-1 shows the relationships between Service Classes, IODs, DSGs and SOP Classes.
Page 95
PS 3.7-2004
Page 85
Ope ration "X"
SG "1"
Ope ration "Y"
D
IOD "A"
SOP CLASS "1"
(identified by SOP
Class UID "1")
Operation "Z"
+
Service Class "α" Service Class "β"
DSG "2 "
+
IOD "A"
SOP CLASS "2"
(identified by SOP
Class UID "2")
Operation "W"
Ope ration "X"
DSG "3"
IOD "A"
SOP CLASS "3"
(identified by SOP
Class UID "3")
+
Ope ration "V"
DSG "4 "
IOD "A"
SOP CLASS "4"
(identified by SOP
Class UID "4")
+
Operation "W"
Ope ration "X"
DSG "5"
+
IOD "B"
SOP CLASS "5"
(identified by SOP
Cla ss UI D "5 ")
Figure D.1-1
SERVICE CLASS, IOD, DSG AND SOP CLASS RELATIONSHIPS
Notes: 1. Two examples of Service Classes are the Storage and Study Management Service Classes. The
Storage Service Class relates to image Information Object Definitions such as CT, MR etc. and the Study Management Service Class relates to the Study Information Object Definition.
2. For readers familiar with OSI terminology, the concept of the Managed Object Class is the equivalent to the DICOM Service-Object Pair Class. The SOP Class specifies both the data (Attributes defined in the Information Object Definition) and the methods (Operations and Notifications (DSG) defined in the Service Class).
By setting the Abstract Syntax Name to a specific SOP Class UID value, DICOM Application Entities may negotiate Service Class operations and/or notifications for each defined SOP Class individually.

D.1.2 Meta service-object pair group UID

Each Service Class Definition may optionally define one or more Meta Service-Object Pair Classes each being identified by a Meta SOP Class UID. Each Meta SOP Class represents the union of a set of SOP Classes defined in the Service Class.
By setting the Abstract Syntax Name to a specific Meta SOP Class UID value, DICOM Application Entities may negotiate Service Class operations and/or notifications for a set of defined SOP Classes using a single Abstract Syntax. Figure D.1-2 depicts this.
Page 96
PS 3.7-2004 Page 86
Operation "X"
SG "1"
Operation "Y"
D
+
IOD "A"
SOP CLASS "1"
(identified by SOP
Class UID "1")
Service Class "α"
Abstract Syntax
Nam e "1"
Operation "Z"
DSG "2 "
SOP CLASS "2"
(identified by SOP
SOP Class UID "2"SOP Class UID "1"
Abstract Syntax
Name "2"
SOP CLASS UIDs AND META SOP CLASS UIDs AND ABSTRACT SYNTAX NAMES

D.2 TRANSFER SYNTAXES

+
IOD "A"
Class UID "2")
Operation "W"
Operation "X"
DSG "3"
+
IOD "A"
SOP CLASS "3"
(identified by SOP
Class UID " 3")
META SOP CLASS "φ"
(identified by Meta SOP Class UID "φ")
Meta SOP Class UID "φ"
Figure D.1-2
DSG "4 "
SOP CLASS "4"
Abstract Syntax
Name "φ"
Operation "V"
+
IOD "A"
(identified by SOP
Class UID "4")
Service Class "β"
Operation "W"
Operation "X"
DSG "5"
+
IOD "B"
SOP CLASS "5"
(identified by SOP
Clas s UID "5" )
SOP Class UID "5"
Abstract Syntax
Name "5"
Transfer Syntaxes define a set of encoding rules used to unambiguously represent one or more Abstract Syntaxes. It allows communicating DICOM AEs to negotiate the encoding techniques they are able to support (e.g. byte ordering, compression, etc.).

D.3 ASSOCIATION ESTABLISHMENT

Association establishment is used to negotiate the type of data to be exchanged and how the data will be encoded. DICOM AEs establish Associations by using the ACSE A-ASSOCIATE Service as defined by Part 8 of the DICOM Standard. Three key parameters conveyed in the A-ASSOCIATE Service are the Application Context, Presentation Context, and the User Information Items. The following section discusses these negotiation parameters.
Note: The A-ASSOCIATE Service is performed only once at Association established time. The examples
shown in this Section separate the negotiation parameters for clarification purposes only. Readers should remember that only one A-ASSOCIATE request is offered for each Association and it contains all of the negotiation parameters.

D.3.1 Application context

An Application Context explicitly defines the set of Application Service Elements, related options and any other information necessary for the inter-working of DICOM AEs on an Association.
The Application Context provides the highest level of negotiation, therefore, a very high level definition. Only one Application Context shall be offered per Association. DICOM specifies a single Application Context Name which defines the DICOM Application Context (applicable for this Standard and potentially later versions).
Note: For complete specification see Annex A of this Part.
Page 97
PS 3.7-2004
Page 87

D.3.2 Presentation contexts negotiation

A Presentation Context defines the presentation of the data on an Association. It provides a lower level of negotiation and one or more Presentation Contexts can be offered and accepted per Association.
A Presentation Context consists of three components, a Presentation Context ID, an Abstract Syntax Name, and a list of one or more Transfer Syntax Names.
Only one Abstract Syntax shall be offered per Presentation Context. However, multiple Transfer Syntaxes may be offered per Presentation Context, but only one shall be accepted.
For each SOP Class or Meta SOP Class a Presentation Context must be negotiated such that this Presentation Context supports the associated Abstract Syntax and a suitable Transfer Syntax. Presentation Contexts will be identified within the scope of a specific Association by a Presentation Context ID.
Figure D.3-1 provides an illustration of Presentation Context Negotiation with the key points as follows:
a. the Association-requester may offer multiple Presentation Contexts per Association. b. each Presentation Context supports one Abstract Syntax (related to a SOP Class or Meta SOP
Class) and one or more Transfer Syntaxes.
c. the Association-acceptor may accept or reject each Presentation Context individually. d. the Association-acceptor selects a suitable Transfer Syntax for each Presentation Context
accepted.
Page 98
PS 3.7-2004 Page 88
Pres.
Cont. ID
(1)
Pres.
Cont. ID
(3)
Pres.
Cont. ID
(5)
DICOM Application Entity "A"
Abs. Syn. Name for Storage-MR SOP
Abs. Syn. Name for Storage-CT SOP
Abs. Syn. Name for Basic Print Meta SOP
Trans. Syn. Name for Little End.
Trans. Syn. Name for Little End.
Trans. Syn. Name for Little End.
Trans. Syn. Name for Big End.
Trans. Syn. Name for Compress.
Pres.
Cont. ID
(7)
Pres.
Cont. ID
(9)
Abs. Syn. Name for Detached Study Mg. SOP
Abs. Syn. Name for Query SOP
A-ASSOCIATE
Response (A B)
Trans. Syn. Name for Little End.
Trans. Syn. Name for Little End.
Pres.
Pres.
Cont. ID
(1)
Pres.
Cont. ID
Cont. ID
(3)
Pres.
Pres.
Cont. ID
(5)
Pres.
Cont. ID
Cont. ID
(7)
Pres.
Cont. ID
(9)
A-ASSOCIATE
Request
(A B)
DICOM Application Entity "B"
Trans. Syn.
Accept
Accept
Reject
Reject
Accept
Name for Little End.
Trans. Syn. Name for Compress.
Trans. Syn. Name for Little End.
Figure D.3-1
PRESENTATION CONTEXTS NEGOTIATION

D.3.3 DICOM application association information

Peer DICOM AEs negotiate, at Association establishment, a number of features related to the DIMSE protocol by using the ACSE User Information Item of the A-ASSOCIATE request. This Section discusses these features.
When the Association is established between peer DIMSE-service-users the Kernel Functional Unit shall be assumed; therefore, the Kernel Functional Unit shall not be included in the A-ASSOCIATE User Information item.
Page 99
PS 3.7-2004
Page 89
D.3.3.1 MAXIMUM LENGTH APPLICATION PDU NOTIFICATION
The Maximum Length notification allows communicating AEs to limit the size of the data for each P-DATA indication. Each DICOM AE defines the maximum PDU size it can receive on this Association. Therefore, different maximum lengths can be specified for each direction of data flow on an Association. This notification is required. Figure D.3-2 illustrates the Maximum Length notification.
Note: For complete specification see PS 3.8.
DICOM Application Entity "A"
Max. Length
Sub-Item
(51H)
Max. PDU
Length Receive
(4096)
A-ASSOCIATE
Request
(A B)
A-ASSOCIATE
Response (A B)
DICOM Application Entity "B"
Max. Length
Sub-Item
(51H)
Max. PDU
Length Receive
(16384)
Figure D.3-2
MAXIMUM LENGTH PDU NEGOTIATION
D.3.3.2 IMPLEMENTATION IDENTIFICATION NOTIFICATION
The implementation identification notification allows implementations of communicating AEs to identify each other at Association establishment time. It is intended to provide respective (each network node knows the other's implementation identity) and non-ambiguous identification in the event of communication problems encountered between two nodes. This negotiation is required.
Implementation identification relies on two pieces of information:
Implementation Class UID (required)
Implementation Version Name (optional)
The Implementation Class UID identifies in a unique manner a specific class of implementation. Each node claiming conformance to this Standard shall be assigned an Implementation Class UID to distinguish its implementation environment from others. Such Implementation Class UIDs shall be registered by the implementing organization per the policies defined in PS 3.5. This Standard does not specify the policies associated with assigning such a UID.
Different equipment of the same type or product line (but having different serial numbers) shall use the same Implementation Class UID if they share the same implementation environment (i.e., software).
The notification by Association requestors and acceptors of their respective Implementation Class UID is required for all implementations conforming to this Standard. Figure D.3-3 illustrates the Implementation Class UID notification.
Page 100
PS 3.7-2004 Page 90
DICOM Application Entity "A"
Imp. UID
Sub-Item
(52H)
Imp. UID for
DICOM AE
"A"
A-ASSOCIATE
Request
(A B)
A-ASSOCIATE
Response (A B)
DICOM Application Entity "B"
Imp. UID
Sub-Item
(52H)
Imp. UID for
DICOM AE
"B"
Figure D.3-3
IMPLEMENTATION CLASS UID NOTIFICATION
In addition to the Implementation Class UID, an option is provided to convey an Implementation Version Name of up to 16 characters. Figure D.3-4 illustrates the Implementation Version Name notification. This Standard does not specify the structure and policies associated with such an Implementation Version Name. The absence of the Implementation Version Name requires that the use of the same Implementation Class UID by two nodes guarantees that these use the same version of implementation.
Note: As the UID shall not be parsed (their structure is not intended to convey any semantic significance
beyond uniqueness), this optional Implementation Version Name provides an adequate mechanism to distinguish two versions of the same implementation (same Implementation Class UID).
D.3.3.2.1 Implementation class UID sub-item structure (A-ASSOCIATE-RQ)
The Implementation Class UID Sub-Item shall be made of a sequence of mandatory fixed length fields followed by a variable field. Only one Implementation Class UID Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-1 shows the sequence of the mandatory fields.
Loading...
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use