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
Note: Use of the Dialog command, supported in previous versions of this Standard, has been retired.
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.
DIMSE-C provides the following operation services which are all confirmed services and as such a response is expected:
a) The C-STORE service is invoked by a DIMSE-service-user to request the storage of Composite SOP Instance information by a peer DIMSE-service-user.
b) The C-FIND service is invoked by a DIMSE-service-user to match a series of Attribute strings against the Attributes of the set of SOP Instances managed by a peer DIMSE-service-user. The C-FIND service returns for each match a list of requested Attributes and their values.
c) The C-GET service is invoked by a DIMSE-service-user to fetch the information for one or more Composite SOP Instances from a peer DIMSE-service-user, based upon the Attributes supplied by the invoking DIMSE-service-user.
d) The C-MOVE service is invoked by a DIMSE-service-user to move the information for one or more Composite SOP Instances from a peer DIMSE-service-user, to a third party DIMSE-service-user, based upon the Attributes supplied by the invoking DIMSE-service-user
e) The C-ECHO service is invoked by a DIMSE-service-user to verify end-to-end communications with a peer DIMSE-service-user.
Notes: 1. The major differences between a C-GET and a C-MOVE operation are that the:
a. C-STORE sub-operations resulting from a C-GET are performed on the same Association as the C-GET. With a C-MOVE, the resulting C-STORE sub-operations are performed on a separate Association.
b. C-MOVE operation supports C-STORE sub-operations being performed with an Application Entity which is not the one that initiated the C-MOVE (third party move).
2. In the case where an Application Entity wishes to request that it receives one or more images for storage, it may use either a C-GET operation or a C-MOVE to itself. It is expected that in most environments the C-MOVE is a simpler solution despite the fact that two Associations are required. The use of the C-GET service may not be widely implemented. It may be implemented in special cases where a system does not support multiple Associations. It was left in this version of the Standard for backward compatibility with previous versions of the Standard.
The DIMSE-N services provide both notification and operation services applicable to Normalized SOP Instances.
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.
DIMSE-N provides the following operation services which are all confirmed services and as such a response is expected:
a) The N-GET service is invoked by a DIMSE-service-user to request the retrieval of information from a peer DIMSE-service-user.
b) The N-SET service is invoked by a DIMSE-service-user to request the modification of information by a peer DIMSE-service-user.
c) The N-ACTION service is invoked by a DIMSE-service-user to request a peer DIMSE-service-user to perform an action.
d) The N-CREATE service is invoked by a DIMSE-service-user to request a peer DIMSE-service-user to create an instance of a SOP Class.
e) The N-DELETE service is invoked by a DIMSE-service-user to request a peer DIMSE-service-user to delete an instance of a SOP Class.
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.
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.
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.
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