Notice and Disclaimer

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

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

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

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

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

Foreword

This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.

The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].

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 PS3.5).

This Part specifies:

a set of service primitives provided by the DIMSE Application Service Element
the parameters that 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:

PS3.3, Information Object Definitions, specifies the set of Information Object Definitions to which the services defined in this Part may be applied
PS3.5, Data Structure and Encoding, addresses the encoding rules necessary to construct a conditional Data Set that 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 PS3.4

2 Normative References

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

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

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

[ISO/TR 8509] ISO. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .

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

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

[ISO/IEC 9595] ISO. 1991. Information processing systems - Open Systems Interconnection - Common Management Information Service Definition.

[ISO/IEC 9834-1] ISO. 2012. Information processing systems - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree.

[RFC1510] IETF. September 1993. The Kerberos Network Authentication Service (V5). http://tools.ietf.org/html/rfc1510 .

[RFC2289] IETF. February 1998. A One-Time Password System. http://tools.ietf.org/html/rfc2289 .

[RFC6750] IETF. October 2012. The OAuth 2.0 Authorization Framework: Bearer Token Usage. http://tools.ietf.org/html/rfc6750 .

[RFC7519] IETF. May 2015. JSON Web Token (JWT). http://tools.ietf.org/html/rfc7519 .

[SAML] OASIS. 15 March 2005. SAML Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 OASIS Standard. https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf .

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:

ApplicationEntity: See [ISO 7498-1].
Application Process: See [ISO 7498-1].
Protocol: See [ISO 7498-1].
Protocol Data Unit: See [ISO 7498-1].
Service: See [ISO 7498-1].
Transfer Syntax: See [ISO 7498-1].

3.2 Service Conventions Definitions

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

Service Provider: See [ISO/TR 8509].
Service User: See [ISO/TR 8509].
Confirmed Service: See [ISO/TR 8509].
Non-confirmed Service: See [ISO/TR 8509].
Primitive: See [ISO/TR 8509].
Request (Primitive): See [ISO/TR 8509].
Indication (Primitive): See [ISO/TR 8509].
Response (Primitive): See [ISO/TR 8509].
Confirm (Primitive): See [ISO/TR 8509].

3.3 Presentation Service Definitions

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

Abstract Syntax: See [ISO 8822].
Abstract Syntax Name: See [ISO 8822].
Presentation Context: See [ISO 8822].
Presentation Data Value: See [ISO 8822].

3.4 ACSE Service Definitions

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

Association: See [ISO 8649].
Application Context: See [ISO 8649].
Association Control Service Element (ACSE): See [ISO 8649].
Association Initiator: See [ISO 8649].

3.5 CMIS Service Definitions

This Part of the Standard makes use of the following terms defined in [ISO/IEC 9595]:

Functional Unit: See [ISO/IEC 9595].
Kernel Functional Unit: See [ISO/IEC 9595].

3.6 DICOM Introduction and Overview Definitions

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

Attribute: See Attribute in PS3.1 .
Command: See Command in PS3.1 .
Command Stream: See Command Stream in PS3.1 .
Data Stream: See Data Stream in PS3.1 .
Message: See Message in PS3.1 .
Service-Object Pair Class (SOP Class): See Service-Object Pair Class in PS3.1 .

3.7 DICOM Upper Layer Service Definitions

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

DICOM Upper Layer Service: See DICOM Upper Layer Service in PS3.8 .

3.8 DICOM Service Class Definitions

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

Service Class: See Service Class in PS3.4 .
Service Class User (SCU): See Service Class User in PS3.4 .
Service Class Provider (SCP): See Service Class Provider in PS3.4 .
Service-Object Pair Instance (SOP Instance): See Service-Object Pair Instance in PS3.4 .
Related General SOP Class: See Related General SOP Class in PS3.4 .

3.9 DICOM Data Structures and Encoding Definitions

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

Data Element: See Data Element in PS3.5 .
Data Set: See Data Set in PS3.5 .
Default Character Repertoire: See Default Character Repertoire in PS3.5 .
Element Number: See Element Number in PS3.5 .
Group Number: See Group Number in PS3.5 .
Implicit VR: See Implicit VR in PS3.5 .
Little Endian: See Little Endian in PS3.5 .
Unique Identifier (UID): See Unique Identifier in PS3.8 .

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 that 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 that supports operations and notifications on Normalized SOP Instances related to Normalized Information Object Definitions with peer DIMSE Service Users.
DIMSE Service Group (DSG): A specific set of one or more DIMSE Services that define the operations and/or notifications that can be performed on a data structure.
DIMSE Service Provider: An abstraction of the totality of those entities that provide DIMSE services to peer DIMSE Service Users.
DIMSE Service User: That part of an Application Entity that makes use of the DICOM Message Service Element.
Extended Negotiation: Exchange of application information by peer DICOM AEs at Association establishment, defined by specific Service Class specifications.
Implementation Class UID: The unique identifier of a specific class of implementation.
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
JIRA: Japan Medical Imaging and Radiological Systems Industries Association
NEMA: National Electrical Manufacturers Association
OSI: Open Systems Interconnection
PDU: Protocol Data Unit
PDV: Presentation Data Value
SOP: Service-Object Pair
TCP/IP: Transmission Control Protocol/Internet Protocol
VM: Value Multiplicity
VR: Value Representation
UID: Unique Identifier
UL: Upper Layer

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. The parameter shall not be present.
C: The parameter is conditional. The condition(s) are defined by the text that 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 Communication Model for Message Exchange

Figure 5-1 in PS3.1 presents the general communication model of the DICOM Standard, which spans both network (on-line) and storage media interchange (off-line) communications. Application Entities may utilize any of the following transport mechanisms:

the DICOM Message Service and Upper Layer Service, which provides independence from specific physical networking communication support and protocols such as TCP/IP,
the DICOM Web Service API and HTTP Service, which allows use of common hypertext and associated protocols for transport of DICOM services,
the Basic DICOM File Service, which provides access to Storage Media independently from specific physical media storage formats and file structures, or
DICOM Real-Time Communication, which provides real-time transport of DICOM metadata based on SMPTE and RTP.

PS3.7 focuses on the DICOM Message Service and here the OSI Basic Reference Model is used to model the interconnection of medical imaging equipment. As shown in Figure 6.1-1 several 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 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 PS3.8.

Figure 6.1-1. DICOM Communication Model for Message Exchange

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:

PS3.3, Information Object Definitions, which provides data models and Attributes used as a basis for defining SOP Instances that 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.
PS3.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.
PS3.5, Data Structure and Encoding, which addresses the encoding of the Data Sets exchanged to accomplish the above services
PS3.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 PS3.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.

Figure 6.2-1. DICOM Application Layer Structure

The DIMSE-C and DIMSE-N services are supported by a single DIMSE protocol that 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 PS3.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 Section 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.

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 PS3.5. The requirements for the existence of a Command Element in a Command Set are defined in the DIMSE protocol.

Note

The use of Private Command Elements has been retired in this version of the DICOM Standard.
The encoding corresponds to the Implicit VR Data Element encoding defined in PS3.5.

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 the Element Number.

Note

All Command Element Tags have the Group Number 0000. See Annex E for the Registry of Command Elements, which provides a complete list of all Command Elements that can be used for the Command Set.
In particular, the Command Set is not permitted to contain any Data Elements, such as those listed in PS3.6.

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 can be found in PS3.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 PS3.5. The VM for a given Command Element can be determined using the Command Dictionary in Annex E.

Note

The Command Length to End (0000,0001) Command Element is retired. Implementations may choose to send it for backward compatibility reasons. DICOM V3.0 conformant implementations must not rely on its presence for their operation.
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 PS3.8). 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:

invoking DIMSE Service User
performing DIMSE Service User

DIMSE Service Users make use of service primitives that are provided by the DIMSE Service Provider. The DIMSE Service Provider is an abstraction of the totality of those entities that provide DIMSE services to peer DIMSE Service Users. A service primitive shall be one of the following types:

request primitive
indication primitive
response primitive
confirmation primitive

These primitives (which are shown in Figure 7-1) are used as follows to successfully complete a DIMSE service:

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 that are used by DICOM Application Entities:

a notification service
an operation service

Figure 7-1. 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 PS3.3 and PS3.4.

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.

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:

it performs operations (on SOP Instances for which it has responsibility) that 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.
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.

Note

Role a) (called the Agent role in ISO terminology) is used by an implementation that conforms to a DICOM Service Class as an SCP.
Role b) (called the Manager role in ISO terminology) is used by an implementation that conforms to a DICOM Service Class as an SCU.

Figure 7.2-1. Operation and Notification Flow

7.3 Service Modes

Operations and notifications, on an Association, are used in one of the following two modes:

synchronous
asynchronous

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. In the asynchronous mode, the performing DIMSE Service User may respond to the operations or notifications in a different order than they were received.

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 PS3.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) that include:

Application context
Presentation and session requirements
DIMSE-specific user information
Application Association Information

The A-RELEASE and A-ABORT Services defined in PS3.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.

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:

DIMSE Service Provider
DIMSE Service User

Reference PS3.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 that are all confirmed services and as such a response is expected:

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.
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.
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.
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
The C-ECHO service is invoked by a DIMSE Service User to verify end-to-end communications with a peer DIMSE Service User.

Note

The major differences between a C-GET and a C-MOVE operation are that the:
1. 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.
2. C-MOVE operation supports C-STORE sub-operations being performed with an Application Entity that is not the one that initiated the C-MOVE (third party move).
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 that are all confirmed services and as such a response is expected:

The N-GET service is invoked by a DIMSE Service User to request the retrieval of information from a peer DIMSE Service User.
The N-SET service is invoked by a DIMSE Service User to request the modification of information by a peer DIMSE Service User.
The N-ACTION service is invoked by a DIMSE Service User to request a peer DIMSE Service User to perform an action.
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.
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.

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	Multiple Responses	Cancel
C-STORE	-	-	-
C-GET	M	C	M
C-MOVE	M	C	M
C-FIND	-	C	M
C-ECHO	-	-	-
N-EVENT-REPORT	-	-	-
N-GET	-	-	-
N-SET	-	-	-
N-ACTION	-	-	-
N-CREATE	-	-	-
N-DELETE	-	-	-

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 that is the Association-requestor and one that is the Association-acceptor. A DIMSE Service User may initiate an Association establishment by using the A-ASSOCIATE service described in PS3.8.

Included in the parameters of the A-ASSOCIATE service is the Application Context that 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

Implementers conform to the DIMSE protocol only by conformance to a SOP class as defined in PS3.2 and PS3.4. Implementers 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 PS3.4.

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	U
Message ID Being Responded To	-	M
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

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.

Note

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

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 that 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 (see also Annex C):

Refused: Out of resources (Status value is Service Class specific) - This indicates that the peer DIMSE Service User was unable to store the composite SOP Instance because it was out of resources.
Refused: SOP Class not supported (0122H) - This indicates that the peer DIMSE Service User was unable to store the composite SOP Instance because the SOP Class is not supported,
Error: Cannot understand (Status value is Service Class specific) - This indicates that the peer DIMSE Service User was unable to store the composite SOP Instance because it Cannot understand certain Data Elements.
Error: Data Set does not match SOP Class (Status value is Service Class specific) - This 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.
Warning (Status value is Service Class specific) - This indicates that the peer DIMSE Service User was able to store the composite SOP Instance, but detected a probable error.
Success (0000H) - This indicates that the composite SOP Instance was successfully stored.
Duplicate invocation (0210H) - Indicates that the Message ID (0000,0110) specified is allocated to another notification or operation.
Invalid SOP Instance (0117H) - Indicates that the SOP Instance UID specified implied a violation of the UID construction rules.
Mistyped argument (0212H) - Indicates that one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
Unrecognized operation (0211H) - Indicates that the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - Indicates that the peer DIMSE Service User was not authorized to store the composite SOP Instance.

9.1.1.2 C-STORE Service Procedures

The following C-STORE procedures apply:

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.
The DIMSE Service Provider issues a C-STORE indication primitive to the performing DIMSE Service User.
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,
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	U	-
Message ID Being Responded To	-	M	M
Affected SOP Class UID	M	U(=)	-
Priority	M	-	-
Identifier	M	C	-
Status	-	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.

Note

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

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 that 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 PS3.4.

9.1.2.1.6 Status

Indicates the status of the response. It may have any of the following values (see also Annex C):

Success (0000H) - This indicates that processing of the matches is complete. It shall not contain a matching Identifier.
Pending (Status value is Service Class specific) - This indicates that processing of the matches is initiated or continuing. It shall contain a matching Identifier.
Refused: Out of resources (Status value is Service Class specific) - Indicates 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.
Refused: SOP Class not supported (0122H) - 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.
Cancel (FE00H) - Indicates 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.
Failed (Status value is Service Class specific) - Indicates that the C-FIND operation failed at the performing DIMSE Service User.
Warning (Status value is Service Class specific) - Indicates that the performing DIMSE Service User has terminated the C-FIND operation, and the set of returned matching Identifiers may not be complete.

9.1.2.2 C-FIND Service Procedures

The following C-FIND service procedures apply to the invoking DIMSE-service user:

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

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.
At any time following the C-FIND indication, the performing DIMSE Service User may receive a C-FIND cancel indication.
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.
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.
For each match, the performing DIMSE Service User issues a C-FIND response with the status set to Pending and a matching Identifier.
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, Warning, or Success to the DIMSE Service Provider.

The following C-FIND service procedures apply to the DIMSE Service Provider:

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.
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.
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 that 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	U	-
Message ID Being Responded To	-	M	M
Affected SOP Class UID	M	U(=)	-
Priority	M	-	-
Identifier	M	U	-
Status	-	M	-
Number of Remaining Sub-operations	-	C	-
Number of Completed Sub-operations	-	C	-
Number of Failed Sub-operations	-	C	-
Number of Warning Sub-operations	-	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

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.
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 PS3.4.

Note

The Identifier is specified as U in the Response/Confirmation, but Services defined in PS3.4 that use this primitive may impose mandatory or conditional requirements on its presence.

In the response/confirmation, this is a list of Attributes that provide status information about the C-GET operation. The list of Attributes allowed and the rules that define the usage of the Identifier are specified in PS3.4.

9.1.3.1.6 Status

Indicates the status of the response. It may have any of the following values (see also Annex C):

Success (0000H) - This indicates that processing of the matches and all sub-operations are complete.
Pending (Status value is Service Class specific) - This indicates that processing of the matches and sub-operations is initiated or continuing.
Refused: Out of resources (Status value is Service Class specific) - Indicates 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.
Refused: SOP Class not supported (0122H) - Indicates that processing of the C-GET has been terminated because the SOP Class was not supported.
Cancel (FE00H) - Indicates that processing of the C-GET has been terminated due to a C-GET Cancel indication primitive.
Failed (Status value is Service Class specific) - Indicates that the C-GET operation failed at the performing DIMSE Service User.
Duplicate invocation (0210H) - Indicates that the Message ID (0000,0110) specified is allocated to another notification or operation.
Mistyped argument (0212H) - Indicates that one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
Unrecognized operation (0211H) - Indicates that the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - Indicates that the peer DIMSE Service User was not authorized to invoke the C-FIND operation.
Warning (Status value is Service Class specific) - This indicates that the peer DIMSE Service User was able to perform sub-operations but detected a probable error with one or more of them.

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

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.
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.
The invoking DIMSE Service User may receive C-GET confirmation primitives with status of Pending during the processing of the C-GET operation.
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:

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.
At any time following the C-GET indication, the performing DIMSE Service User may receive a C-GET cancel indication.
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.
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.
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.
During the processing of the C-GET operation, the performing DIMSE Service User may issue C-GET response primitives with a status of Pending.
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:

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

DIMSE-C Parameter Name	Req/Ind	Rsp/Conf	CnclReq/CnclInd
Message ID	M	U	-
Message ID Being Responded To	-	M	M
Affected SOP Class UID	M	U(=)	-
Priority	M	-	-
Move Destination	M	-	-
Identifier	M	U	-
Status	-	M	-
Number of Remaining Sub-operations	-	C	-
Number of Completed Sub-operations	-	C	-
Number of Failed Sub-operations	-	C	-
Number of Warning Sub-operations	-	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.

Note

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.
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 to 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 PS3.4.

Note

The Identifier is specified as U in the Response/Confirmation, but Services defined in PS3.4 that use this primitive may impose mandatory or conditional requirements on its presence.

In the response/confirmation, this is a list of Attributes that provide status information about the C-MOVE operation. The list of Attributes allowed and the rules that define the usage of the Identifier are specified in PS3.4.

9.1.4.1.7 Status

Indicates the status of the response. It may have any of the following values (see also Annex C):

Success (0000H) - This indicates that processing of the matches and all sub-operations are complete.
Pending (Status value is Service Class specific) - This indicates that procession of the matches and sub-operations is initiated or continuing.
Refused: Out of resources (Status value is Service Class specific) - Indicates 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.
Refused: SOP Class not supported (0122H) - Indicates that processing of the C-MOVE has been terminated because the SOP Class was not supported.
Refused: Move Destination unknown (Status value is Service Class specific) - Indicates that processing of the C-MOVE has been terminated because the Move destination was unknown.
Cancel (FE00H) - Indicates that processing of the C-MOVE has been terminated due to a C-MOVE Cancel indication primitive.
Failed (Status value is Service Class specific) - Indicates that the C-MOVE operation failed at the performing DIMSE Service User.
Duplicate invocation (0210H) - Indicates that the Message ID (0000,0110) specified is allocated to another notification or operation.
Mistyped argument (0212H) - Indicates that one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
Unrecognized operation (0211H) - Indicates that the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - Indicates that the peer DIMSE Service User was not authorized to invoke the C-MOVE operation.
Warning (Status value is Service Class specific) - This indicates that the peer DIMSE Service User was able to perform sub-operations but detected a probable error with one or more of them.

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

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-MOVE request primitive to the DIMSE Service Provider. If the request is rejected by the DIMSE Service Provider, the following procedures do not apply.
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.
The invoking DIMSE Service User may receive C-MOVE confirmation primitives with status of Pending during the processing of the C-MOVE operation.
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:

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.
At any time following the C-MOVE indication, the performing DIMSE Service User may receive a C-MOVE cancel indication.
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.
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.
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.
During the processing of the C-MOVE operation, the performing DIMSE Service User may issue C-MOVE response primitives with a status of Pending.
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:

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

Note

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

Note

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.
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 may have any of the following values (see also Annex C):

Success (0000H)
Refused: SOP Class not supported (0122H) - Indicates that a different SOP Class than the Verification SOP Class was specified, which was not supported.
Duplicate invocation (0210H) - Indicates that the Message ID (0000,0110) specified is allocated to another notification or operation.
Mistyped argument (0212H) - Indicates that one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
Unrecognized operation (0211H) - Indicates that a different SOP Class than the Verification SOP Class was specified, which does not recognize a C-ECHO operation.

9.1.5.2 C-ECHO Service Procedures

The following C-ECHO procedures apply:

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.
The DIMSE Service Provider issues a C-ECHO indication primitive to the performing DIMSE Service User.
The performing DIMSE Service User verifies communication by issuing a C-ECHO response primitive to the DIMSE Service Provider.
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 PS3.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 PS3.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
Command 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 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 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
Command 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	(0000,1000)	UI	1	Contains the UID of the SOP Instance to be stored.
Move Originator Application Entity Title	(0000,1030)	AE	1	Contains the DICOM AE Title of the DICOM AE that invoked the C-MOVE operation from which this C-STORE sub-operation is being performed.
Move Originator Message ID	(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 PS3.3 and PS3.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 PS3.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
Command 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.
Command 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)	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 stored.

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 PS3.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
Command 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 this 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 0020H for the C-FIND-RQ Message.
Message ID	(0000,0110)	US	1	Implementation-specific value that 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
Command 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 the Identifier to be matched. See Section 9.1.2.1.5.

Note

Implementations that require compatibility to previous versions of this Standard must set the Command 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 PS3.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
Command 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 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.
Command 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)	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.
Identifier	(no tag)	-	-	A Data Set that encodes the Identifier that was matched. See Section 9.1.2.1.5.

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 PS3.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
Command 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.
Command 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:
1. construct a Message conveying the (Pending) C-FIND-RSP
2. 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:
1. construct a Message conveying the (final) C-FIND-RSP
2. send 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 PS3.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
Command 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 this 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 0010H for the C-GET-RQ Message.
Message ID	(0000,0110)	US	1	Implementation-specific value that 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
Command 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 that require compatibility to previous versions of this Standard must set the Command 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 PS3.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
Command 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.
Command 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)	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.
Number of Remaining Sub-operations	(0000,1020)	US	1	The number of remaining C-STORE sub-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 that 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 that have failed.
Number of Warning Sub-operations	(0000,1023)	US	1	The number of C-STORE sub-operations invoked by this C-GET operation that generated warning responses.
Identifier	(no tag)	-	-	A Data Set that encodes the Identifier that was matched. See Section 9.1.3.1.5.

Note

The list of Attributes allowed and the rules that define the usage of the Identifier are specified in PS3.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 PS3.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
Command 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.
Command 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:

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:
1. construct a Message conveying the (Pending) C-GET-RSP
2. 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:
1. construct a Message conveying the (final) C-GET-RSP
2. 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.

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 PS3.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
Command 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 this 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 0021H for the C-MOVE-RQ Message.
Message ID	(0000,0110)	US	1	Implementation-specific value that 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
Command 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 to which the C-STORE sub-operations are being performed.
Identifier	(no tag)	-	-	A Data Set that encodes the Identifier to be matched. See Section 9.1.4.1.6.

Note

Implementations that require compatibility to previous versions of this Standard must set the Command 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 PS3.5. Fields are required as 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
Command 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 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.
Command 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)	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.
Number of Remaining Sub-operations	(0000,1020)	US	1	The number of remaining sub-operations to be invoked for this C-MOVE operation.
Number of Completed Sub-operations	(0000,1021)	US	1	The number of C-STORE sub-operations invoked by this C-MOVE operation that 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 that have failed.
Number of Warning Sub-operations	(0000,1023)	US	1	The number of C-STORE sub-operations invoked by this C-MOVE operation that 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 PS3.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.

Table 9.3-11. C-CANCEL-MOVE-RQ Message Fields

Message Field	Tag	VR	VM	Description of Field
Command 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.
Command 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:
1. construct a Message conveying the (Pending) C-MOVE-RSP
2. 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:
1. construct a Message conveying the (final) C-MOVE-RSP
2. 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;
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 PS3.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-12 are required by the DIMSE-C protocol.

Table 9.3-12. C-ECHO-RQ Message Fields

Message Field	Tag	VR	VM	Description of Field
Command 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 this 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 0030H for the C-ECHO-RQ Message.
Message ID	(0000,0110)	US	1	Implementation-specific value that distinguishes this Message from other Messages.
Command 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.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 PS3.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
Command 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 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.
Command 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.

10 DIMSE-N

10.1 Services

The following sections describe the DIMSE-N Services. The behavior of these services is also described in PS3.4. The Affected SOP Class UID in the DIMSE-N command need not match the SOP Class UID in the Presentation Context negotiated for the association over which the DIMSE-N command has been sent. PS3.4 specifies which combinations are valid.

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	-	M
Affected SOP Class UID	M	U(=)
Affected SOP Instance UID	M	U(=)
Event Type ID	M	C(=)
Event Information	U	-
Event Reply	-	C
Status	-	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

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

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 PS3.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 PS3.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 PS3.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 (see also Annex C):

Class-Instance conflict (0119H) - the specified SOP Instance is not a member of the specified SOP class.
Duplicate invocation (0210H) - the Message ID (0000,0110) specified is allocated to another notification or operation.
Invalid argument value (0115H) - the event information value specified was out of range or otherwise inappropriate.
Invalid SOP Instance (0117H) - the SOP Instance UID specified implied a violation of the UID construction rules.
Mistyped argument (0212H) - one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
No such argument (0114H) - the event information specified was not recognized.
No such Event Type (0113H) - the event type specified was not recognized.
No such SOP Class (0118H) - the SOP Class was not recognized.
No such SOP Instance (0112H) - the SOP Instance was not recognized.
Processing Failure (0110H) - a general failure in processing the operation was encountered.
Resource limitation (0213H) - the operation was not performed due to resource limitation.
Success (0000H) - successful notification.
Unrecognized operation (0211H) - 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:

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.
The DIMSE Service Provider issues an N-EVENT-REPORT indication primitive to the performing DIMSE Service User.
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.
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	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Attribute Identifier List	U	-
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Attribute List	-	C
Status	-	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.

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 PS3.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 that 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 (see also Annex C):

Attribute List warning (0107H) - 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 (0119H) - the specified SOP Instance is not a member of the specified SOP Class.
Duplicate invocation (0210H) - the Message ID (0000,0110) specified is allocated to another notification or operation.
Invalid SOP Instance (0117H) - the SOP Instance UID specified implied a violation of the UID construction rules.
Mistyped argument (0212H) - one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
No such SOP Class (0118H) - the SOP Class was not recognized.
No such SOP Instance (0112H) - the SOP Instance was not recognized.
Processing Failure (0110H) - a general failure in processing the operation was encountered.
Resource limitation (0213H) - the operation was not performed due to resource limitation.
Success (0000H) - successful operation.
Unrecognized operation (0211H) - the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - the DIMSE Service User was not authorized to invoke the operation
Warning (Status value is Service Class specific): not all optional attributes were returned by DIMSE Service User
Failed (Status value is Service Class specific): DIMSE Service User failed to complete the operation

10.1.2.2 N-GET Service Procedures

The following N-GET procedures apply;

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.
The DIMSE Service Provider issues an N-GET indication primitive to the performing DIMSE Service User.
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.
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.
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	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Modification List	M	-
Attribute List	-	U
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Status	-	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.

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 that 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 that 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 (see also Annex C):

Class-Instance conflict (0119H) - the specified SOP Instance is not a member of the specified SOP Class.
Duplicate invocation (0210H) - the Message ID (0000,0110) specified is allocated to another notification or operation.
Invalid Attribute Value (0106H) - the Attribute Value specified was out of range or otherwise inappropriate.
Attribute Value out of range (0116H) - the Attribute Value specified was out of range or otherwise inappropriate. The Attribute Values that could be modified were modified.
Mistyped argument (0212H) - one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
Invalid SOP Instance (0117H) - the SOP Instance UID specified implied a violation of the UID construction rules.
Missing Attribute Value (0121H) - a required Attribute Value was not supplied.
No such Attribute (0105H) - the Tag for the specified Attribute was not recognized.
Attribute List warning (0107H) - one or more Attribute Values were not modified because the specified Attributes were not recognized. The Attribute Values that could be modified were modified.
No such SOP Class (0118H) - the SOP Class was not recognized.
No such SOP Instance (0112H) - the SOP Instance was not recognized.
Processing Failure (0110H) - a general failure in processing the operation was encountered.
Resource limitation (0213H) - the operation was not performed due to resource limitation.
Success (0000H) - successful operation.
Unrecognized operation (0211H) - the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - the DIMSE Service User was not authorized to invoke the operation.
Failed (Status value is Service Class specific): the operation was not performed as certain conditions for operation were not met
Warning (Status value is Service Class specific): the operation was performed partially or with modified conditions

10.1.3.2 N-SET Service Procedures

The following N-SET procedures apply:

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.
The DIMSE-service provider issues an N-SET indication primitive to the performing DIMSE Service User.
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.
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.
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	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Action Type ID	M	C(=)
Action Information	U	-
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Action Reply	-	C
Status	-	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 that 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 PS3.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 PS3.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.

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 PS3.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 (see also Annex C):

Class-Instance conflict (0119H) - the specified SOP Instance is not a member of the specified SOP Class.
Duplicate invocation (0210H) - the Message ID (0000,0110) specified is allocated to another notification or operation.
Invalid argument value (0115H) - the action information value specified was out of range or otherwise inappropriate.
Invalid SOP Instance (0117H) - the SOP Instance UID specified implied a violation of the UID construction rules.
Mistyped argument (0212H) - one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
No such Action (0123H) - the action type specified was not supported.
No such argument (0114H) - the action information specified was not supported.
No such SOP Class (0118H) - the SOP Class was not recognized.
No such SOP Instance (0112H) - the SOP Instance was not recognized.
Processing Failure (0110H) - a general failure in processing the operation was encountered.
Resource limitation (0213H) - the operation was not performed due to resource limitation.
Success (0000H) - successful operation.
Unrecognized operation (0211H) - the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - the DIMSE Service User was not authorized to invoke the operation.
Failed (Status value is Service Class specific): the operation was not performed as certain conditions for operation were not met
Warning (Status value is Service Class specific): the operation was performed partially or with modified conditions

10.1.4.2 N-ACTION Service Procedures

The following N-ACTION procedures apply:

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.
The DIMSE-service provider issues an N-ACTION indication primitive to the performing DIMSE Service User.
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.
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.
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 that 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 that 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.

10.1.5.1.4 Affected SOP Instance UID

For the request/indication, this parameter specifies the SOP Instance that 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 in the success response/confirmation, this parameter contains the complete list of all Attribute identifiers and values that were assigned to the new managed SOP Instance.

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 (see also Annex C):

Duplicate invocation (0210H) - the Message ID (0000,0110) specified is allocated to another notification or operation.
Duplicate SOP Instance (0111H) - 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 (0106H) - the Attribute Value specified was out of range or otherwise inappropriate.
Attribute Value out of range (0116H) - the Attribute Value specified was out of range or otherwise inappropriate. The SCP will apply a default value or will not include the attribute in the created instance.
Invalid SOP Instance (0117H) - the SOP Instance UID specified implied a violation of the UID construction rules.
Missing Attribute (0120H) - a required Attribute was not supplied.
Missing Attribute Value (0121H) - a required Attribute Value was not supplied and a default value was not available.
Mistyped argument (0212H) - one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users.
No such Attribute (0105H) - the Tag for the specified Attribute was not recognized.
Attribute List warning (0107H) - one or more specified Attributes were not recognized and not included in the created instance.
No such SOP Class (0118H) - the SOP Class was not recognized.
Processing Failure (0110H) - a general failure in processing the operation was encountered.
Resource limitation (0213H) - the operation was not performed due to resource limitation.
Success (0000H) - successful operation.
Unrecognized operation (0211H) - the operation is not one of those agreed between the DIMSE Service Users.
Refused: Not authorized (0124H) - the DIMSE Service User was not authorized to invoke the operation.
Failed (Status value is Service Class specific): no instance was created by the DIMSE Service User
Warning (Status value is Service Class specific): the DIMSE Service User created an Instance but did not perform all specified operations

10.1.5.2 N-CREATE Service Procedures

The following N-CREATE procedures apply:

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.
The DIMSE-service provider issues an N-CREATE indication primitive to the performing DIMSE Service User.
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.
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.
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	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Status	-	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.

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 that is to be deleted.

10.1.6.1.4 Requested SOP Instance UID

This parameter specifies the SOP Instance that 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 that 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 (see also Annex C):

Class-Instance conflict (0119H) - the specified SOP Instance is not a member of the specified SOP Class
Duplicate invocation (0210H) - the Message ID (0000,0110) specified is allocated to another notification or operation
Invalid SOP Instance (0117H) - the SOP Instance UID specified implied a violation of the UID construction rules
Mistyped argument (0212H) - one of the parameters supplied has not been agreed for use on the Association between the DIMSE Service Users
No such SOP Class (0118H) - the SOP Class was not recognized
No such SOP Instance (0112H) - the SOP Instance was not recognized
Processing Failure (0110H) - a general failure in processing the operation was encountered
Resource limitation (0213H) - the operation was not performed due to resource limitation
Success (0000H) - successful operation
Unrecognized operation (0211H) - the operation is not one of those agreed between the DIMSE Service Users
Refused: Not authorized (0124H) - the DIMSE Service User was not authorized to invoke the operation.

10.1.6.2 N-DELETE Service Procedures

The following N-DELETE procedures apply:

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.
The DIMSE-service provider issues an N-DELETE indication primitive to the performing DIMSE Service User.
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 request primitive by issuing an N-DELETE response primitive to the DIMSE Service Provider. In this case the following procedure does not apply.
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.
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 PS3.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 PS3.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
Command 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.
Message ID	(0000,0110)	US	1	Implementation-specific value that distinguishes this Message from other Messages.
Command 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.

Note

Service Class Specifications contained in PS3.4 defines the values needed for the Event Type ID parameter.
Service Class Specifications contained in PS3.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 PS3.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
Command 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.
Command 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 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.

Note

Service Class Specifications contained in PS3.4 defines the values needed for the Event Type ID parameter.
Service Class Specifications contained in PS3.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.

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 PS3.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
Command 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 that distinguishes this Message from other Messages.
Command 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 PS3.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
Command 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.
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.
Command 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 Attribute Values are returned.
Attribute List	(no tag)	-	-	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 (PS3.3) and Service Class Specifications (PS3.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 PS3.5. Fields are required as specified in the N-SET 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
Command 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 that distinguishes this Message from other Messages.
Command 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	(0000,1001)	UI	1	Contains the UID of the SOP Instance for which Attribute Values are to be modified.
Modification List	(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

The permitted contents of Modification List, encoded as a series of Data Elements, are defined in the Information Object Definition (PS3.3) and Service Class Specifications (PS3.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 PS3.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
Command 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.
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.
Command 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 Attribute Values were modified.
Attribute List	(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

The permitted contents of Attribute List, encoded as a series of Data Elements, are defined in the Information Object Definition (PS3.3) and Service Class Specifications (PS3.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 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 PS3.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
Command 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 that distinguishes this Message from other Messages.
Command 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.

Note

Service Class Specifications contained in PS3.4 define the values needed for the Action Type ID (0000,1008) parameter.
Service Class Specifications contained in PS3.4 define the Data Set needed for the Action Information parameter.

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 PS3.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
Command 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.
Command 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

Service Class Specifications contained in PS3.4 define the values needed for the Action Type ID (0000,1008) parameter.
Service Class Specifications contained in PS3.4 define the Data Set needed for the Action Reply parameter related to each defined Action Type ID.
Service Class Specifications contained in PS3.4 define the encoding of the Action Reply 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)

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 PS3.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
Command 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 that distinguishes this Message from other Messages.
Command 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	(0000,1000)	UI	1	Contains the UID of the SOP Instance to be created.
Attribute List	(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

The permitted contents of Attribute List, encoded as a series of Data Elements, are defined in the Information Object Definition (PS3.3) and Service Class Specifications (PS3.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 PS3.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
Command 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 that 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.
Command 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 that was created.

PS3.7

DICOM PS3.7 2024d - Message Exchange

DICOM Standards Committee

Notice and Disclaimer

Foreword

1 Scope and Field of Application

2 Normative References

3 Definitions

3.1 Reference Model Definitions

3.2 Service Conventions Definitions

3.3 Presentation Service Definitions

3.4 ACSE Service Definitions

3.5 CMIS Service Definitions

3.6 DICOM Introduction and Overview Definitions

3.7 DICOM Upper Layer Service Definitions

3.8 DICOM Service Class Definitions

3.9 DICOM Data Structures and Encoding Definitions

3.10 DICOM Message Exchange Definitions

4 Symbols and Abbreviations

5 Conventions

6 Service Context

6.1 DICOM Communication Model for Message Exchange

6.2 The DICOM Application Layer Structure

Note

6.3 DICOM Message Structure and Command Set

6.3.1 Command Set Structure

Note

Note

Note

7 Service Overview

7.1 Service Types

7.2 DIMSE Service User Interaction

Note

7.3 Service Modes

7.4 Association Services

Note

7.4.1 Association Establishment

7.4.2 Association Release

7.5 DIMSE Services

Note

7.5.1 DIMSE-C Services

7.5.1.1 Operation Services

Note

7.5.2 DIMSE-N Services

7.5.2.1 Notification Service

7.5.2.2 Operation Services

7.5.3 DIMSE Procedures

7.5.3.1 Sub-Operations

7.5.3.2 Multiple Responses

7.5.3.3 Cancellation

8 Protocol Overview

8.1 DIMSE Protocol

Note

8.2 Association Protocol

8.3 Conformance

9 DIMSE-C

9.1 Services

9.1.1 C-STORE Service

9.1.1.1 C-STORE Parameters

9.1.1.1.1 Message ID

Note

9.1.1.1.2 Message ID Being Responded To

9.1.1.1.3 Affected SOP Class UID

9.1.1.1.4 Affected SOP Instance UID

9.1.1.1.5 Priority

9.1.1.1.6 Move Originator Application Entity Title

9.1.1.1.7 Move Originator Message ID

9.1.1.1.8 Data Set

9.1.1.1.9 Status

9.1.1.2 C-STORE Service Procedures

Note

9.1.2 C-FIND Service

9.1.2.1 C-FIND Parameters

9.1.2.1.1 Message ID

Note

9.1.2.1.2 Message ID Being Responded To

9.1.2.1.3 Affected SOP Class UID

9.1.2.1.4 Priority

9.1.2.1.5 Identifier

9.1.2.1.6 Status