PS-2020a / part07

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​ ServiceProvidermayhaveinprogress.NotwoidenticalvaluesfortheMessageID(0000,0110)shallbeusedforoutstandingoperations​ or notifications.​

Note​

1.​Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but this mode of use​ is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE Service User​ should not attach any semantic significance to this parameter.​

2.​The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug pro-​ cedures.​

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​

ThisparameterspecifiestheDICOMAETitleofthedestinationDICOMAEtowhichtheC-STOREsub-operationsarebeingperformed.​

9.1.4.1.6 Identifier​

Intherequest/indication,thisisalistofAttributestobematchedagainstthevaluesoftheAttributesofknowncompositeSOPInstances​ of the performing DIMSE Service User. The list of Attributes allowed and the rules for the construction are in PS3.4.​

Note​

TheIdentifierisspecifiedasUintheResponse/Confirmation,butServicesdefinedinPS3.4thatusethisprimitivemayimpose​ mandatory or conditional requirements on its presence.​

Intheresponse/confirmation,thisisalistofAttributesthatprovidestatusinformationabouttheC-MOVEoperation.ThelistofAttributes​ 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):​

a.​Success (0000H) - This indicates that processing of the matches and all sub-operations are complete.​

b.​Pending (Status value is Service Class specific) - This indicates that procession of the matches and sub-operations is initiated​ or continuing.​

c.​Refused:Outofresources(StatusvalueisServiceClassspecific)-IndicatesthatprocessingoftheC-MOVEhasbeenterminated​ because it was out of resources. This may be the initial response to the C-MOVE or may be sent after a number of Pending​ statuses.​

d.​Refused: SOP Class not supported (0122H) - Indicates that processing of the C-MOVE has been terminated because the SOP​ Class was not supported.​

- Standard -​

e.​Refused:MoveDestinationunknown(StatusvalueisServiceClassspecific)-IndicatesthatprocessingoftheC-MOVEhasbeen​ terminated because the Move destination was unknown.​

f.​ Cancel (FE00H) - Indicates that processing of the C-MOVE has been terminated due to a C-MOVE Cancel indication primitive.​

g.​Failed (Status value is Service Class specific) - Indicates that the C-MOVE operation failed at the performing DIMSE Service​ User.​

h.​Duplicateinvocation(0210H)-IndicatesthattheMessageID(0000,0110)specifiedisallocatedtoanothernotificationoroperation.​

i.​ Mistyped argument (0212H) - Indicates that one of the parameters supplied has not been agreed for use on the Association​ between the DIMSE Service Users.​

j.​ Unrecognized operation (0211H) - Indicates that the operation is not one of those agreed between the DIMSE Service Users.​

k.​Refused: Not authorized (0124H) - Indicates that the peer DIMSE Service User was not authorized to invoke the C-MOVE oper-​ ation.​

l.​ Warning (Status value is Service Class specific) - This indicates that the peer DIMSE Service User was able to perform sub-op-​ erations 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:​

a.​The invoking DIMSE Service User requests a performing DIMSE Service User to match an Identifier against the Attributes of all​ SOPInstancesknowntotheperformingDIMSEServiceUserandgenerateaC-STOREsub-operationforeachmatch.Thisrequest​ 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.​

b.​At any time before receiving a C-MOVE confirmation primitive with status unequal to Pending, the invoking DIMSE Service User​ may request the performing DIMSE Service User to cancel the service by issuing a C-MOVE cancel request primitive to the​ DIMSE Service Provider.​

c.​The invoking DIMSE Service User may receive C-MOVE confirmation primitives with status of Pending during the processing of​ the C-MOVE operation.​

d.​The invoking DIMSE Service User receives a final C-MOVE confirmation primitive.​

Note​

in the above procedures, (c) may precede (b).​

- Standard -​

The following C-MOVE service procedures apply to the performing DIMSE Service User:​

a.​When the performing DIMSE Service User receives a C-MOVE indication from the DIMSE Service Provider it matches the​ Identifier against the Attributes of known composite SOP Instances and generates a C-STORE sub-operation for each match.​

b.​At any time following the C-MOVE indication, the performing DIMSE Service User may receive a C-MOVE cancel indication.​

c.​If the C-MOVE cancel indication is received before the processing of the C-MOVE request has completed, then the C-MOVE​ operation is terminated; otherwise the following procedure does not apply.​

d.​The performing DIMSE Service User issues a C-MOVE response with a status of Canceled to the DIMSE Service Provider to​ indicate that the C-MOVE has been canceled. The following procedures do not apply.​

e.​For each matching composite SOP Instance, the C-MOVE performing DIMSE Service User initiates a C-STORE sub-operation​ on a different Association than the C-MOVE. In this sub-operation, the C-MOVE performing DIMSE Service User becomes the​ C-STOREinvokingDIMSEServiceUser.TheC-STOREperformingDIMSEServiceUsermayormaynotbetheC-MOVEinvoking​ DIMSE Service User.​

f.​ During the processing of the C-MOVE operation, the performing DIMSE Service User may issue C-MOVE response primitives​ with a status of Pending.​

g.​When the C-MOVE operation completes (either in success or in failure), the performing DIMSE Service User issues a C-MOVE​ response with the status set to either Refused, Failed, or Success to the DIMSE Service Provider.​

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

a.​When the DIMSE Service Provider receives a C-MOVE request primitive from the invoking DIMSE Service User, it issues a C-​ MOVE indication primitive to the performing DIMSE Service User.​

b.​When the DIMSE Service Provider receives a C-MOVE cancel request primitive from the invoking DIMSE Service User, it issues​ a C-MOVE cancel indication to the performing DIMSE Service User.​

c.​When the DIMSE Service Provider receives a C-MOVE response primitive from the performing DIMSE Service User, it issues a​ C-MOVE confirmation primitive to the invoking DIMSE Service User.​

The performing DIMSE Service User may return a C-MOVE response primitive with the status of Failed or Refused before the entire​ C-MOVE indication (Data Set) has been completely transmitted by the invoking DIMSE Service User. A C-MOVE response primitive​ with the status of Success or Warning shall not be returned until the entire C-MOVE indication has been received by the performing​ DIMSE Service User.​

Note​

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

- Standard -​

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​ ServiceProvidermayhaveinprogress.NotwoidenticalvaluesfortheMessageID(0000,0110)shallbeusedforoutstandingoperations​ or notifications.​

Note​

1.​Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but this mode of use​ is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE Service User​ should not attach any semantic significance to this parameter.​

2.​The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug pro-​ cedures.​

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):​

a.​Success (0000H)​

b.​Refused: SOP Class not supported (0122H) - Indicates that a different SOP Class than the Verification SOP Class was specified,​ which was not supported.​

c.​Duplicateinvocation(0210H)-IndicatesthattheMessageID(0000,0110)specifiedisallocatedtoanothernotificationoroperation.​

d.​Mistyped argument (0212H) - Indicates that one of the parameters supplied has not been agreed for use on the Association​ between the DIMSE Service Users.​

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

a.​The invoking DIMSE Service User requests verification of communication to the performing DIMSE Service User by issuing a​ C-ECHO request primitive to the DIMSE Service Provider.​

b.​The DIMSE Service Provider issues a C-ECHO indication primitive to the performing DIMSE Service User.​

c.​The performing DIMSE Service User verifies communication by issuing a C-ECHO response primitive to the DIMSE Service​ Provider.​

d.​The DIMSE Service Provider issues a C-ECHO confirmation primitive to the invoking DIMSE Service User, completing the C-​ ECHO operation.​

9.2 Sequencing​

9.2.1 Types of Services​

All operation and notifications shall be confirmed services.​

- Standard -​

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​

TheinformationnecessaryfortheC-STORErequestandindicationDIMSE-CprimitivesareconveyedintheC-STORE-RQMessage.​ 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 Rep-​ resentationasdefinedinPS3.5.FieldsarerequiredasspecifiedintheC-STOREservicedefinitionunlessotherwisenotedinTable9.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​

- Standard -​

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​

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

- Standard -​

TheperformingDIMSEServiceUsermayreturnaC-STORE-RSPwiththestatusofFailedorRefusedbeforethecompleteC-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 an-​ other 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 trans-​ mitted 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 Repres-​ entation 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​

Note​

Implementations that require compatibility to previous versions of this Standard must set the Command Data Set Type​ (0000,0800) Field to 0102H (Identifier).​

- Standard -​

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​

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​

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)​

- Standard -​

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

a.​construct a Message conveying the (Pending) C-FIND-RSP​

b.​send the Message using the P-DATA request service (see 8.1)​

•​for the C-FIND response primitive containing the final status the DIMSE-C protocol machine shall:​

a.​construct a Message conveying the (final) C-FIND-RSP​

b.​end the Message using the P-DATA request service (see 8.1)​

On receipt of a Message conveying a C-FIND-RSP the DIMSE-C protocol machine shall:​

•​if the Message indicates the status of Pending, issue a C-FIND confirmation primitive to the invoking DIMSE Service User with a​ Pending status​

•​if the Message indicates a final status, issue a C-FIND confirmation primitive to the invoking DIMSE Service User with a final status,​ thus completing the C-FIND procedure​

Note​

The C-FIND procedures can be canceled at any time by the invoking DIMSE Service User. This is accomplished by the in-​ voking 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 trans-​ mitted 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 Repres-​ entation 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.​

- Standard -​

Page 60​ DICOM PS3.7 2020a - Message Exchange​

Table 9.3-6. C-GET-RQ Message Fields​

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​

- Standard -​