CC.1.1 Unified Procedure Step States

Figure CC.1.1-1, Table CC.1.1-1 and Table CC.1.1-2 specify how changes in the state of a Unified Procedure Step shall be managed.

[pic]

Figure CC.1.1-1 Unified Procedure Step State Diagram

The following interactions represent an example sequence of events and state transitions. Observe that the DIMSE Services described here operate on the same IOD. The multiple UPS SOP Classes thus act in a coordinated manner as specified in this Annex.

To create a UPS, an SCU uses an N-CREATE to push a UPS onto the SCP’s worklist. The SCP responds to such requests by creating a Unified Procedure Step (UPS) with an initial state of SCHEDULED.

Note: All UPS Instances are instances of the UPS Push SOP Class, although the other three SOP Classes (UPS Pull, UPS Watch and UPS Event) may also operate on the Instance.

To subscribe to receive N-EVENT-REPORTs for a UPS, or to unsubscribe to stop receiving N-EVENT-REPORTS, an SCU uses an N-ACTION request. The SCU may be the system that created the UPS as a Push SCU, or may be some other system with a reason to track the progress and results of a scheduled step.

To inform interested systems of the state of a UPS or the SCP itself, an SCP issues N-EVENT-REPORTs to SCUs that have subscribed.

To find a UPS of interest, an SCU uses a C-FIND to query the SCP for relevant UPS instances.

To “claim” and start work on a UPS, an SCU (which will be referred to here as the “Performing SCU”) uses an N-ACTION Change State request to set the UPS state to IN PROGRESS and provide a transaction UID (which will be referred to here as the Locking UID). For a SCHEDULED UPS, the SCP responds by changing the UPS state to IN PROGRESS and recording the transaction UID for future use. For a UPS with other status, the SCP rejects the request.

The SCP does not permit the status of a SCHEDULED UPS to be set to COMPLETED or CANCELED without first being set to IN PROGRESS.

To modify details of the performed procedure, the Performing SCU uses an N-SET request to the SCP (providing the Locking UID for the UPS). N-SET requests on an IN PROGRESS UPS where the Locking UID in the N-SET dataset does not match the Locking UID in the UPS are rejected by the SCP.

To modify the status of the procedure step, the Performing SCU uses an N-ACTION Change State request to the SCP (providing the Locking UID for the UPS). N-ACTION Change State requests where the Locking UID in the N-ACTION dataset does not match the Locking UID in the UPS are rejected by the SCP.

The Locking UID effectively limits control of the state of an IN PROGRESS UPS to only the SCP and the Performing SCU. The SCP does not check whether IP addresses, AE-Titles, or parameters other than the Locking UID match to determine if the SCU has permission.

When the Performing SCU completes work on the UPS, it N-SETs any values necessary to meet the Final State requirements in Table CC.2.5-3, then uses an N-ACTION request (providing the Locking UID for the UPS during both steps) for the SCP to change the UPS state to COMPLETED.

When the Performing SCU abandons work on an incomplete UPS, it N-SETs any values necessary to meet the Final State requirements in Table CC.2.5-3, then uses an N-ACTION request (providing the Locking UID for the UPS) for the SCP to change the UPS state to CANCELED.

To request cancellation of a UPS, non-performing SCUs use an N-ACTION Request Cancel (See PS 3.17 GGG.4 and GGG.5 for example cases).

Table CC.1.1-1 describes the valid UPS states

Table CC.1.1-1

UNIFIED PROCEDURE STEP (UPS) STATES

State Description
SCHEDULED The UPS is scheduled to be performed.
IN PROGRESS The UPS has been claimed and a Locking UID has been set. Performance of the UPS has likely started.
CANCELED The UPS has been permanently stopped before or during performance of the step. This may be due to voluntary or involuntary action by a human or machine. Any further UPS-driven work required to complete the scheduled task must be performed by scheduling another (different) UPS.
COMPLETED The UPS has been completed.

COMPLETED and CANCELED are “Final States” that involve specific requirements on the UPS as described in CC.2.5.1.1.

Table CC.1.1-2 describes the valid state transitions (a row in the table defines what should happen in response to a certain event for each initial state). Details on how the Operations listed in the table should be carried out are described in section CC.2.

Table CC.1.1-2

UNIFIED PROCEDURE STEP STATE TRANSITION TABLE

States
Events null SCHEDULED IN PROGRESS COMPLETED CANCELED
N-CREATE received for this SOP Instance UID Create SOP Instance with empty transaction UID, Change State to SCHEDULED error 0111 error 0111 error 0111 error 0111
N-ACTION to Change State to IN PROGRESS with correct transaction UID error C307 Report state change, Record transaction UID, Change State to IN PROGRESS error C302 error C300 error C300
N-ACTION to Change State to IN PROGRESS without correct transaction UID error C307 error C301 error C301 error C301 error C301
N-ACTION to Change State to SCHEDULED error C307 error C303 error C303 error C303 error C303
N-ACTION to Change State to COMPLETED, with correct transaction UID error C307 error C310 If Final State Requirements met, (Report state change, Change State to COMPLETED); Else C304 warning B306 error C300
N-ACTION to Change State to COMPLETED, without correct transaction UID error C307 error C301 error C301 error C301 error C301
N-ACTION to Request Cancel error C307 Report state change to IN-PROGRESS, Report state change to CANCELED, Change State to CANCELED Report that an Application Entity requested a cancel. error C311 warning B304
N-ACTION to Change State to CANCELED, with correct transaction UID error C307 error C310 If Final State Requirements met, (Report state change, Change State to CANCELED); Else C304. error C300 warning B304
N-ACTION to Change State to CANCELED, without correct transaction UID error C307 error C301 error C301 error C301 error C301