This Annex defines the Service and SOP Classes associated with a Unified Worklist and Procedure Step.
The Unified Procedure Step Service Class provides for management of simple worklists, including creating new worklist items, querying the worklist, and communicating progress and results.
A worklist is a list of Unified Procedure Step (UPS) instances. Each UPS instance unifies the worklist details for a single requested procedure step together with the result details of the corresponding performed procedure step. There is a one to one relationship between the procedure step request and the procedure step performed.
Unified Procedure Step instances may be used to represent a variety of scheduled tasks such as: Image Processing, Quality Control, Computer Aided Detection, Interpretation, Transcription, Report Verification, or Printing.
The UPS instance can contain details of the requested task such as when it is scheduled to be performed or Workitem Codes describing the requested actions. The UPS may also contain details of the input information the performer needs to do the task and the output the performer produced, such as: Current Images, Prior Images, Reports, Films, Presentation States, or Audio recordings.
The Unified Worklist and Procedure Step Service Class includes five SOP Classes associated with UPS instances. The SOP Class UID for any UPS Instance always specifies the UPS Push SOP Class. The separate SOP Classes facilitate better negotiation and logical implementation groups of functionalities.
The UPS Push SOP Class allows an SCU to instruct the SCP to create a new UPS instance, effectively letting a system push a new work item onto the SCP's worklist. It is important to note that the SCP could be a Worklist Manager that maintains the worklist for other systems that will perform the work, or the SCP could be a performing system itself that manages an internal worklist.
The UPS Pull SOP Class allows an SCU to query a Worklist Manager (the SCP) for matching UPS instances, and instruct the SCP to update the status and contents of selected items (UPS instances). The SCU effectively pulls work instructions from the worklist. As work progresses, the SCU records details of the activities performed and the results created in the UPS instance.
The UPS Query SOP Class allows an SCU to query a Worklist Manager (the SCP), but does not otherwise interact with the UPS instances.
The UPS Watch SOP Class allows an SCU to subscribe for status update events and retrieve the details of work items (UPS instances) managed by the SCP.
The UPS Event SOP Class allows an SCP to provide the actual status update events for work items it manages to relevant (i.e., subscribed) SCUs.
Each of these services has an equivalent HTTP operation defined by the UPS-RS Worklist Service (see Section 11 “Worklist Service and Resources” in PS3.18).
While a Unified Worklist and Procedure Step Service Class SCP is not required to support UPS-RS, an SCP may choose to support one or more of the UPS-RS services as an origin server. In this scenario, an SCP/origin server shall follow the same internal behavior for all Workitems irrespective of whether they originated with a DIMSE request or an HTTP request. A DIMSE request and its equivalent HTTP request with the same parameters shall yield the same response.
-
A Workitem instance created via DIMSE N-CREATE can be retrieved via HTTP requests and vice-versa
-
A Workitem instance created via DIMSE N-CREATE can be updated, have its state changed or be canceled via HTTP requests and vice-versa
-
A C-FIND request and an HTTP SearchForUPS request with the same parameters shall return the same set of results
-
An N-EVENT-REPORT SCU that also supports HTTP subscriptions will record whether a given subscriber uses DIMSE or WebSockets and send the appropriate form of notification to that subscriber
-
A change made to a Workitem instance will result in the same event notifications regardless of whether the change was requested via DIMSE or HTTP
-
A Global Subscription request or a Filtered Global Subscription request will subscribe an SCU (or user agent) to instances created both via DIMSE and via HTTP requests
-
A DIMSE event subscriber will receive notifications for relevant changes made via HTTP requests
-
An HTTP event subscriber will receive notifications for relevant changes made via DIMSE requests
The mapping between UPS DIMSE operations and UPS-RS services is defined in Section 11 “Worklist Service and Resources” in PS3.18.
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.
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 another 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 Data Set 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 Data Set 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 Section GGG.2.4 “Third Party Cancel” in PS3.17 and Section GGG.2.5 “Radiation Therapy Dose Calculation Push Workflow” in PS3.17 for example cases).
-
If the UPS is still in the SCHEDULED state, the SCP first changes the UPS state to IN PROGRESS, and then to CANCELED, issuing the appropriate N-EVENT-REPORTS.
-
If the UPS is already IN PROGRESS and the SCP is itself performing the UPS, it may, at its own discretion, choose to cancel the UPS as described in the previous paragraph.
-
If the UPS is already IN PROGRESS and the SCP is not the performer, it does not change the UPS state to CANCELED, but rather responds by issuing an N-EVENT-REPORT of the cancellation request to all subscribed SCUs. If the Performing SCU is listening to N-EVENT-REPORTs it may, at its own discretion, choose to cancel the UPS as described above.
Table CC.1.1-1 describes the valid UPS states
Table CC.1.1-1. Unified Procedure Step (UPS) States
COMPLETED and CANCELED are "Final States" that involve specific requirements on the UPS as described in Section 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