NEMA DICOM User manual

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 -
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.
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
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
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
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
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
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
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
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.
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
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
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:
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
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
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
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.
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
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.
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:
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.
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
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.
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:
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.
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.
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
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.
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.
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,
Loading...
+ 88 hidden pages