DICOM PS3.4 2021d - Service Class Specifications

CC.2 DIMSE Service Groups (Current)
Prev | CC Unified Procedure Step Service and SOP Classes (Normative) | Next

## CC.2 DIMSE Service Groups

The DIMSE Services shown in Table CC.2-1, Table CC.2-2, Table CC.2-3, Table CC.2-4 and Table CC.2-5 are applicable to the Unified Procedure Step (UPS) IOD under the UPS Push, UPS Pull, UPS Watch, UPS Event and UPS Query SOP Classes respectively.

Table CC.2-1. DIMSE Service Group Applicable to UPS Push

DICOM Message Service Element | Usage SCU/SCP
--- | ---
N-CREATE | M/M
N-ACTION - Request UPS Cancel | U/M
N-GET | U/M

Table CC.2-2. DIMSE Service Group Applicable to UPS Pull

DICOM Message Service Element | Usage SCU/SCP
--- | ---
C-FIND | M/M
N-GET | M/M
N-SET | M/M
N-ACTION - Change UPS State | M/M

Table CC.2-3. DIMSE Service Group Applicable to UPS Watch

DICOM Message Service Element | SCU/SCP
--- | ---
N-ACTION - Un/Subscribe | M/M
N-GET | M/M
C-FIND | U/M
N-ACTION - Request UPS Cancel | U/M

Table CC.2-4. DIMSE Service Group Applicable to UPS Event

DICOM Message Service Element | Usage SCU/SCP
--- | ---
N-EVENT-REPORT | M/M

Table CC.2-5. DIMSE Service Group Applicable to UPS Query

DICOM Message Service Element | Usage SCU/SCP
--- | ---
C-FIND | M/M

### CC.2.1 Change UPS State (N-ACTION)

This operation allows an SCU to ask the SCP to change the state of a Unified Procedure Step (UPS) instance. This operation shall be invoked by the SCU through the DIMSE N-ACTION Service.

#### CC.2.1.1 Action Information

DICOM AEs that claim conformance to the UPS Pull SOP Class as an SCU and/or an SCP shall support the Action Types and Action Information as specified in Table CC.2.1-1.

Table CC.2.1-1. Change UPS State - Action Information

Action Type Name | Action Type ID | Attribute Name | Tag | Requirement Type SCU/SCP
--- | --- | --- | --- | ---
Change UPS State | 1 | Procedure Step State | (0074,1000) | 1/1
Transaction UID | (0008,1195) | 1/1

#### CC.2.1.2 Service Class User Behavior

An SCU uses N-ACTION to ask the SCP to change the state of a UPS Instance as shown in Figure CC.1.1-1. Since all UPSs are created as instances of the UPS Push SOP Class, the Requested SOP Class UID (0000,0003) in the N-ACTION request shall be the UID of the UPS Push SOP Class. See Section CC.3.1 for further details.

To take control of a SCHEDULED UPS, an SCU shall generate a Transaction UID and submit a state change to IN PROGRESS including the Transaction UID in the submission. The SCU shall record and use the Transaction UID in future N-ACTION and N-SET requests for that UPS instance.

### Note

1. The performing SCU may wish to record the Transaction UID in non-volatile storage. This would allow the SCU to retain control over the UPS after recovering from a crash.

2. If two SCUs try to take control of a UPS, the second SCU will get an error since the first SCU established the correct Transaction UID, so the Transaction UID provided by the second SCU is incorrect.

Upon completion of an IN PROGRESS UPS it controls, an SCU shall submit a state change to COMPLETED and include the Transaction UID for the UPS instance.

To cancel an IN PROGRESS UPS for which it has the Transaction UID, an SCU shall submit a state change to CANCELED and include the Transaction UID for the UPS instance.

### Note

1. Prior to submitting the state change to CANCELED, the performing SCU can N-SET the values of Reason For Cancellation, Procedure Step Discontinuation Reason Code Sequence, Contact Display Name or Contact URI to provide information to observing SCUs about the context of the cancellation.

2. To request cancellation of an IN PROGRESS UPS for which it does not have the Transaction UID, an SCU uses the Request UPS Cancel action as described in Section CC.2.2, rather than a Change UPS State action.

Prior to submitting a state change to COMPLETED or CANCELED for a UPS instance it controls, the SCU shall perform any N-SETs necessary for the UPS to meet Final State requirements as described in section Section CC.2.5.1.1.

At any time after receipt of the N-ACTION-Response, the SCU may release the association on which it sent the N-ACTION-Request.

#### CC.2.1.3 Service Class Provider Behavior

The SCP shall perform the submitted state change for the identified UPS instance by setting the Procedure Step State (0074,1000) to the requested value, or shall report the appropriate failure response code.

Upon successfully changing the state of a UPS instance to IN PROGRESS, the SCP shall record the Transaction UID provided by the SCU in the Transaction UID (0008,1195) of the UPS instance.

Upon completion of the N-ACTION request, the SCP shall return, via the N-ACTION response primitive, the N-ACTION Status Code applicable to the associated request as shown in Table CC.2.1-2.

The SCP shall only perform legal state changes as described in Table CC.1.1-2.

The SCP shall refuse requests to change the state of an IN PROGRESS UPS unless the Transaction UID of the UPS instance is provided in the request.

The SCP shall refuse requests to change the state of an IN PROGRESS UPS to COMPLETED or CANCELED if the Final State requirements described in Table CC.2.5-3 have not been met.

After the state of the UPS instance has been changed to COMPLETED or CANCELED, the SCP shall not delete the instance until all deletion locks have been removed.

### Note

See Section CC.2.3.2 for a description of how SCUs place and remove deletion locks and see Section GGG.1 “Introduction” in PS3.17 Reliable Watchers and Deletion Locks for further discussion.

The SCP may also modify the Procedure Step State (0074,1000) of a UPS instance independently of an N-ACTION request, e.g., if the SCP is performing the procedure step itself, or if it has been determined that the performing SCU has been disabled.

### Note

If the SCP is not performing the procedure step, this should be done with caution.

Upon successfully changing the state of a UPS instance, the SCP shall carry out the appropriate N-EVENT-REPORT behavior as described in Section CC.2.4.3 if it supports the UPS Event SOP Class as an SCP.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS3.7 and PS3.15). PS3.7 provides a "Refused: Refused: Not authorized" error code. Further requiring or documenting authentication and/or authorization features from the SCU or SCP is beyond the scope of this SOP Class.

#### CC.2.1.4 Status Codes

Table CC.2.1-2 defines the status code values that might be returned in a N-ACTION response. General status code values and fields related to status code values are defined for N-ACTION DIMSE Service in PS3.7 .

Table CC.2.1-2. N-ACTION Response Status Values [for Change UPS State]

Service Status | Further Meaning | Status Code
--- | --- | ---
Success | The requested state change was performed | 0000
Warning | The UPS is already in the requested state of CANCELED | B304
The UPS is already in the requested state of COMPLETED | B306
Failure | Failed: The UPS may no longer be updated | C300
Failed: The correct Transaction UID was not provided | C301
Failed: The UPS is already IN PROGRESS | C302
Failed: The UPS may only become SCHEDULED via N-CREATE, not N-SET or N-ACTION | C303
Failed: The UPS has not met final state requirements for the requested state change | C304
Failed: Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP | C307
Failed: The UPS is not yet in the "IN PROGRESS" state | C310

Prev | Up | Next
CC Unified Procedure Step Service and SOP Classes (Normative) | Home | CC.2.2 Request UPS Cancel (N-ACTION)

DICOM PS3.4 2021d - Service Class Specifications