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.
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.
Change UPS State – ACTION INFORMATION
|Action Type Name||Action Type ID||Attribute||Tag||Requirement Type SCU/SCP|
|Change UPS State||1||Procedure Step State||(0074,1000)||1/1|
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 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.
Notes: 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.
Notes: 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 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 CC.188.8.131.52.
At any time after receipt of the N-ACTION-Response, the SCU may release the association on which it sent the N-ACTION-Request.
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 N-ACTION 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 CC.2.3.2 for a description of how SCUs place and remove deletion locks and see PS 3.17 GGG.1 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 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 PS 3.7 and PS 3.15). PS 3.7 provides a “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.
The status values which are specific for this DIMSE operation are defined in Table CC.2.1-2.
|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||Refused: The UPS may no longer be updated||C300|
|Refused: The correct Transaction UID was not provided||C301|
|Refused: The UPS is already IN PROGRESS||C302|
|Refused: The UPS may only become SCHEDULED via N-CREATE, not N-SET or N-ACTION||C303|
|Refused: The UPS has not met final state requirements for the requested state change||C304|
|Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP||C307|
|Refused: The UPS is not yet in the “IN PROGRESS” state||C310|