GGG.2 Implementation Examples

The following sections describe ways UPS workflows could be used to address some typical scenarios.

GGG.2.1 Typical SOP Class Implementations

The decision of which SOP Classes to implement in which systems will revolve partly around where it makes the most sense for the business logic to reside, what information each system would have access to, and what kind of workflow is most effective for the users.

Table GGG.1-1 shows a number of hypothetical systems and the combination of SOP Classes they might implement. For example, a typical worklist manager would support all four SOP Classes as an SCP. A typical scheduling system might want to be a UPS Push SCU to submit work items to the worklist manager, a UPS Watch SCU to subscribe for notifications and get details of the results, and a UPS Event SCU to receive the progress notifications. A simple "pull performer" might only be a UPS Pull SCU, similar to modalities today.

Other examples are listed for:

  • "Minimal Scheduler", a requesting system that is not interested in monitoring progress or results.

  • "Watcher", a system interested in tracking the progress and/or results of Unified Procedure Steps.

  • "General Contractor", a system that accepts work items pushed to it, then uses internal business logic to subdivide/create work items that it pushes or makes available to systems that will actually perform the work.

  • "Push Performer", a system, for example a CAD system, that has work pushed to it, and provides status and results information to interested observers.

  • "Self-Scheduled Performer", which internally schedules it's own work, but supports notifications and N-GET so the details of the work can be made available to other departmental systems.

  • "Self-Scheduled Pull Performer", which pushes a workitem onto a worklist manager and then pulls it off to perform it. This allows it to work on "unscheduled" procedures without taking on the responsibility of being an SCP for notifications and events.

Table GGG.1-1. SOP Classes for Typical Implementation Examples

SOP Classes

SCU

SCP

UPS Push

UPS Watch

UPS Event

UPS Pull

UPS Push

UPS Watch

UPS Event

UPS Pull

Non-Performing SCUs

Minimal Scheduler

X

Typical Scheduler

X

X

X

Watcher

X

X

Worklist SCPs

Worklist Manager

X

X

X

X

General Contractor

X

X

X

X

X

X

X

Performing SCPs

Push Performer

X

X

X

Self-Scheduled Performer

X

X

Performing SCUs

Pull Performer

X

Self-Scheduled Pull Performer

X

X


A system that implements UPS Watch as an SCP will also need to implement UPS Event as an SCP to be able to send Event Reports to the systems from whom it accepts subscriptions.

GGG.2.2 Typical Pull Workflow

This example shows how a typical pull workflow could be used to manage the work of a 3D Lab. A group of 3D Workstations query a 3D Worklist Manager for work items that they perform and report their progress. In this example, the RIS would be a "Typical Scheduler", the 3D Workstation is a "Pull Performer" as seen in Table GGG.1-1 and the PACS and Modality do not implement any UPS SOP Classes.

We will assume the RIS decides which studies require 3D views and puts them on the worklist once the acquiring modality has reported it's MPPS complete. The RIS identifies the required 3D views and lists the necessary input objects in the UPS based on the image references recorded in the MPPS.

Assume the RIS has subscribed globally for all UPS instances managed by the 3D Worklist Manager.

Diagram of Typical Pull Workflow

Figure GGG.2-1. Diagram of Typical Pull Workflow


GGG.2.3 Reporting Workflow With "hand-off"

This example shows a reporting workflow with a "hand-off". Reporting Workstations query a RIS for work items to interpret/report. In this example, the RIS is a "Worklist Manager", the Reporting Workstation is both a "Pull Performer" and a "Minimal Scheduler" as shown in Table GGG.1-1 and the PACS and Modality do not implement any UPS SOP Classes. A reporting workstation claims Task X but can't complete it and "puts it back on the worklist" by canceling Task X and creating Task Y as a replacement, recording Task X as the Replaced Procedure Step.

Assume the RIS is picking up where example GGG.2.2 left off and was waiting for the 3D view generation task to be complete before putting the study on the reading worklist. The RIS identifies the necessary input objects in the UPS based on the image references recorded in the acquisition MPPS and the 3D UPS.

Diagram of Reporting Workflow

Figure GGG.3-1. Diagram of Reporting Workflow


You could also imagine the 3D workstation is a Mammo CAD workstation. If the first radiologist completed the report, the RIS could easily schedule Task Y as the over-read by another radiologist.

For further discussion, refer to the Section GGG.2.7 material on Hand-offs, Fail-overs and Putting Tasks Back on the Worklist.

GGG.2.4 Third Party Cancel

Cancel requests are always directed to the system managing the UPS instance since it is the SCP. When the UPS is being managed by one system (for example a Treatment Management System) and performed by a second system (for example a Treatment Delivery System), a third party would send the cancel request to the TMS and cancellation would take place as shown below.

Performing SCUs are not required to react to cancel requests, or even to listen for them, and in some situations would be unable to abort the task represented by the UPS even if they were listening. In the diagram below we assume the performing SCU is listening, willing, and able to cancel the task.

If the User had sent the cancel request while the UPS was still in the SCHEDULED state, the SCP (i.e., the TMS) could simply have canceled the UPS internally. Since the UPS state was IN PROGRESS, it was necessary to send the messages as shown. Note that since the TDS has no need for the UPS instance to persist, it subscribed without setting a Deletion Lock, and so it didn't need to bother unsubscribing later.

Diagram of Third Party Cancel

Figure GGG.4-1. Diagram of Third Party Cancel


GGG.2.5 Radiation Therapy Dose Calculation Push Workflow

In this example, users schedule tasks to a shared dose calculation system and need to track progress. This example is intended as a demonstration of UPS and should not be taken as prescriptive of RT Therapy procedures.

Pushing the tasks avoids problems with a pull workflow such as the server having to continually poll worklists on (a large number of) possible clients; needing to configure the server to know about all the clients; reporting results to a user who might be at several locations; and associating the results with clients automatically. Also, when performing machines each have unique capabilities, the scheduling must target individual machines, and there can be advantages for integrating the scheduling and performing activities like this.

Although not shown in the diagram, the User could have gone to a User Terminal ("Watcher") and monitored the progress from there by doing a C-FIND and selecting/subscribing to Task X.

Diagram of Radiation Therapy Planning Push Workflow

Figure GGG.5-1. Diagram of Radiation Therapy Planning Push Workflow


In a second example, the User monitors progress from another User Terminal ("Watcher") and decides to request cancellation after 3 beams.

Diagram of Remote Monitoring and Cancel

Figure GGG.5-2. Diagram of Remote Monitoring and Cancel


GGG.2.6 X-Ray Clinic Push Workflow

In this example, arriving patients are admitted at the RIS and sent to a specific X-Ray room for their exam.

The RIS is shown here subscribing globally for events from each Room. Alternatively the RIS could subscribe individually to each Task right after the N-CREATE is requested.

It is left open whether the patient demographics have been previously registered and the patients scheduled on the RIS or whether they are registered on the RIS when they arrive.

Diagram of X-Ray Clinic Push Workflow

Figure GGG.6-1. Diagram of X-Ray Clinic Push Workflow


GGG.2.7 Other Examples

A wide variety of workflow methods are possible using the UPS SOP Classes. In addition to those diagrammed in the previous sections, a few more are briefly described here. These include examples of ways to handle unscheduled tasks, grouped tasks, append cases, "event forwarding", etc.

Self-Scheduling Push & Pull: Unscheduled and Append Cases

In radiation therapy a previously unscheduled ("emergency") procedure may be performed on a Treatment Delivery System. Normally a TDS performs scheduled procedures as a Performing SCU in a Typical Pull Workflow like that shown in GGG.2.2. A TDS that might need to perform unscheduled procedures could additionally implement UPS Push (as an SCU) and push the "unscheduled" procedure to the departmental worklist server then immediately set it IN PROGRESS as a UPS Pull SCU. The initial Push to the departmental server allows the rest of the departmental workflow to "sync up" normally to the new task on the schedule.

A modality choosing to append some additional images after the original UPS was completed could use a similar method. Since the original UPS can no longer be modified, the modality could push a new UPS instance to the Worklist Manager and then immediately set it IN PROGRESS. Many of the attribute values in the new UPS would be the same as the original UPS.

Note that for a Pull Performer that wants to handle unscheduled cases, this Push & Pull approach is pretty simple to implement. Becoming a UPS Push SCU just requires N-CREATE and N-ACTION (Request Cancel) that are quite similar to the N-SET and N-ACTION it already supports as a UPS Pull SCU.

The alternative would be implementing both UPS Watch and UPS Event as an SCP, which would be more work. Further, potential listeners would have to be aware of and monitor the performing system to track the unscheduled steps, instead of just monitoring the departmental Pull SCP.

Self-Scheduling Performer

An example of an alternative method for handling unscheduled procedures is a CAD workstation that decides for itself to perform processing on a study. By implementing UPS Watch as an SCP and UPS Event as an SCP, the workstation can create UPS instances internally and departmental systems such as the RIS can subscribe globally to the workstation to monitor its activities.

The workstation might create the UPS tasks in response to having data pushed to it, or potentially the workstation could itself also be a Watch and Event SCU and subscribe globally to relevant modality or PACS systems and watch for appropriate studies.

Push Daisy Chain

Sometimes the performer of the current task is in the best position to decide what the next task should be.

An alternative to centralized task management is daisy-chaining where each system pushes the next task to the next performer upon completion of the current task. Using a workflow similar to the X-Ray Clinic example in GGG.6, a modality could push a task to a CAD workstation to process the images created by the modality. The task would specify the necessary images and perhaps parameters relevant to the acquisition technique. The RIS could subscribe globally with the CAD workstation to track events. Another example of push daisy chain would be for the task completed at each step in a reporting process to be followed by scheduling the next logical task.

Hand-offs, Fail-overs and Putting Tasks Back on the Worklist

Sometimes the performer of the current task, after setting it to IN PROGRESS, may determine it cannot complete the task and would like the task performed by another system. It is not permitted to move the task backwards to the SCHEDULED state.

One approach is for the performer to cancel the old UPS and schedule a new UPS to be pulled off the worklist by another system or by itself at some point in the future. The new UPS would be populated with details from the original. The details of the new UPS, such as the Input Information Sequence (0040,4021), the Scheduled Workitem Code Sequence (0040,4018), and the Scheduled Processing Parameters Sequence (0074,1210), might be revised to reflect any work already completed in the old UPS. By including the "Discontinued Procedure Step rescheduled" code in the Procedure Step Discontinuation Reason Code Sequence (0074,100e) of the old UPS, the performer can allow watchers and other systems monitoring the task to know that there is a replacement for the old canceled UPS. By referencing the UID of the old UPS in the Replaced Procedure Step Sequence (0074,1224) of the new UPS, the performer can allow watchers and other systems to find the new UPS that replaced the old. A proactive SCP might even subscribe watchers of the old UPS to the new UPS that replaces it.

Alternatively, if the performer does not have the capability to create a new UPS, it could include the "Discontinued Procedure Step rescheduling recommended" code in the Procedure Step Discontinuation Reason Code Sequence (0074,100e). A very smart scheduling system could observe the cancellation reason and create the new replacement UPS as described above on behalf of the performer.

Another approach is for the performer to "sub-contract" to another system by pushing a new UPS onto that system and marking the original UPS complete after the sub-contractor finishes.

Yet another approach would be for the performer to deliver the Locking UID (by some unspecified mechanism) to another system allowing the new system to continue the work on the existing UPS. Coordination and reconciliation would be very important since the new system would need to review the current contents of the UPS, understand the current state, update the performing system information, etc.