Figure BBB.3.1.1-1 illustrates a message sequence example in the case where a treatment procedure delivery is requested and performed by a delivery device that has internal verification capability. In the example, no 'setup verification' is performed, i.e., the patient is assumed to be in the treatment position. Unified Procedure Step (UPS) is used to request delivery of a session of radiation therapy (commonly known as a "fraction") from a specialized Application Entity (a "Treatment Delivery System"). That entity performs the requested delivery, completing normally. Further examples could be constructed for discontinued, emergency (unscheduled) and interrupted treatment delivery use cases, but are not considered in this informative section (see DICOM Part 17 for generic examples).
In this example the Treatment Delivery System conforms to the UPS Pull SOP Class as an SCU, and the Treatment Management System conforms to the UPS Pull SOP Class as an SCP. In alternative implementations requiring on-the-fly scheduling and notification, other UPS SOP classes could be implemented.
Italic text in Figure BBB.3.1.1-1 denotes messages that will typically be conveyed by means other than DICOM services.
This section describes in detail the interactions illustrated in Figure BBB.3.1.1-1.
-
'List Procedures for Delivery' on TDS console.
The User uses a control on the user interface of the TDS to indicate that he or she wishes to see the list of patients available for treatment.
-
The TDS queries the TMS for Unified Procedure Steps (UPSs) matching its search criteria. For example, all worklist items with a Unified Procedure Step Status of "SCHEDULED", and Input Readiness State (0040,4041) of "READY". This is conveyed using the C-FIND request primitive of the UPS Pull SOP Class.
-
The TDS receives the set of Unified Procedure Steps (UPSs) resulting from the Query UPS message. The Receive UPS is conveyed via one or more C-FIND response primitives of the UPS Pull SOP Class. Each response (with status pending) contains the requested Attributes of a single Unified Procedure Step (UPS).
The TMS returns a list of one or more UPSs based on its own knowledge of the planned tasks for the querying device. Two real-world scenarios are common in this step:
-
There is no TMS Console located in the treatment area, and selection of the delivery to be performed has not been made. In this case, the TMS returns a list of potentially many UPSs (for different patients), and the User picks from the list the UPS that they wish to deliver.
-
The User has direct access to the TMS in the treatment area, and has already selected the delivery to be performed on the console of the TMS, located in the treatment room area. In this case, a single UPS is returned. The TDS may either display the single item for confirmation, or proceed directly to loading the patient details.
A returned set of UPSs may have more than one UPS addressing a given treatment delivery. For example, in the case where a patient position verification is required prior to delivery, there might be a UPS with Requested Procedure Code Sequence item having a Code Value of 121708 ("RT Patient Position Acquisition, CT MV"), another UPS with a Code Value of 121714 ("RT Patient Position Registration, 3D CT general"), another UPS with a Code Value of 121722 ("RT Patient Position Adjustment"),and a fourth UPS whose Requested Procedure Code Sequence item would have a Code Value of 121726 ("RT Treatment With Internal Verification").
-
-
'Select Procedure' on TDS console
The User selects one of the scheduled procedures specified on the TDS console. If exactly one UPS was returned from the UPS query described above, then this step can be omitted.
-
Get UPS Details and Retrieve Archive Objects
The TDS may request the details of one or more procedure steps. This is conveyed using the N-GET primitive of the UPS Pull SOP Class, and is required when not all necessary information can be obtained from the query response alone.
The TDS then retrieves the required SOP Classes from the Input Information Sequence of the returned UPS query response. In response to a C-MOVE Request on those objects (5a), the Archive then transmits to the TDS the SOP Instances to be used as input information during the task. These SOP Instances might include an RT Plan SOP Instance, and verification images (CT Image or RT Image). They might also include RT Beams Treatment Record SOP Instances if the Archive is used to store these SOP Instances rather than the TMS. The TDS knows of the existence and whereabouts of these SOP Instances by virtue of the fully-specified locations in the N-GET response.
Although the TDS could set the UPS to 'IN PROGRESS' prior to retrieving the archive instances, this example shows the archive instances being retrieved prior to the UPS being 'locked' with the N-ACTION step. This avoids the UPS being set 'IN PROGRESS' if the required instances are not available, and therefore avoids the need to schedule another (different) procedure step in this case, as required by the Unified Procedure Step State Diagram State Diagram (PS3.4). However, some object instances dynamically created to service performing of the UPS step should be supplied after setting the UPS 'IN PROGRESS' (see Step 7).
-
Change UPS State to IN PROGRESS
The TDS sets the UPS (which is managed by the TMS) to have the Unified Procedure Step Status of 'IN PROGRESS' upon starting work on the item. The SOP Instance UID of the UPS will normally have been obtained in the worklist item. This is conveyed using the N-ACTION primitive of the UPS Pull SOP Class with an action type "UPS Status Change". This message allows the TMS to update its worklist and permits other Performing Devices to detect that the UPS is already being worked on.
The UPS is updated in this step before the required dynamic SOP Instances are obtained from the TMS (see Step 7). In radiation therapy, it is desirable to signal as early as possible that a patient is about to undergo treatment, to allow the TMS to begin other activities related to the patient delivery. If the TMS implements the UPS Watch SOP Class, other systems will be able to subscribe for notifications regarding the progress of the procedure step.
-
In response to a C-MOVE Request, the TMS transmits to the TDS the RT Beams Delivery Instruction and possibly RT Treatment Summary Record SOP Instances to be used as input information during the task. These SOP Instances may be created "on-the-fly" by the TMS (since it was the TMS itself that transmitted the UIDs in the UPS). The RT Treatment Summary SOP Instance may be required by the TDS to determine the delivery context, although the UPS does specify a completion delivery (following a previous delivery interruption). RT Beams Treatment Record instances might also be retrieved from the TMS in this step if the TMS is used to manage these SOP Instances rather than the Archive.
-
'Start Treatment Session' on TDS console
The User uses a control on the user interface of the TDS to indicate that he or she wishes to commence the treatment delivery session. A Treatment Session may involve fulfillment of more than one UPS, in which case Steps 4-13 may be repeated.
-
Set UPS Progress and Beam Number, Verify, and Deliver Radiation
For each beam, the TDS updates the UPS on the TMS just prior to starting the radiation delivery sequencing. This is conveyed using the N-SET primitive of the UPS Pull SOP Class.
The completion percentage of the entire UPS is indicated in the Unified Procedure Step Progress Attribute. The algorithm used to calculate this completion percentage is not specified here, but should be appropriate for user interface display.
The Referenced Beam Number of the beam about to be delivered is specified by encoding it as a string value in the Procedure Step Progress Description (0074,1006).
The TDS then performs internal verifications to determine that the machine is ready to deliver the radiation, and then delivers the therapeutic radiation for the specified beam. In the current use case, it is assumed that the radiation completes normally, delivering the entire scheduled fraction. Other use cases, such as voluntary interruption by the User, or interruption by the TDS, will be described elsewhere.
If there is more than one beam to be delivered, the verification, UPS update, and radiation delivery is repeated once per beam.
This example does not specify whether or not treatment should be interrupted or terminated if a UPS update operation fails. The successful transmittal of updates is not intended as a gating requirement for continuation of the delivery, but could be used as such if the TDS considers that interrupting treatment is clinically appropriate at that moment of occurrence.
-
Set UPS to Indicate Radiation Complete
The TDS may then update the UPS Progress Information Sequence upon completion of the final beam (although this is not required), and set any other Attributes of interest to the SCP. This is conveyed using the N-SET primitive of the UPS Pull SOP Class.
-
The TDS stores any generated results to the Archive. This would typically be achieved using the Storage and/or Storage Commitment Service Classes and may contain one or more RT Beams Treatment Records or RT Treatment Summary Records, RT Images (portal verification images), CT Images (3D verification images), RT Dose (reconstructed or measured data), or other relevant Composite SOP Instances. References to the results and their storage locations are associated with the UPS in the Set UPS to Final State message (below). The RT Beams Treatment Record instances might be stored to the TMS instead, if the TMS is used to manage these SOP Instances rather than the Archive.
The required SOP Instances are stored to the Archive in this step before the UPS is status is set to COMPLETED. In radiation therapy, it is desirable to ensure that the entire procedure is complete, including storage of important patient data, before indicating that the step completed successfully. For some systems, such as those using Storage Commitment, this may not be possible, in which case another service such as Instance Availability Notification (not shown here) would have to be used to notify the TMS of SOP Instance availability. For the purpose of this example, it is assumed that the storage commitment response occurs in a short time frame.
-
Set UPS Attributes to Meet Final State Requirements
The TDS then updates the UPS with any further Attributes required to conform to the UPS final state requirements. Also, references to the results SOP Instances stored in Step 11 are supplied in the Output Information Sequence. This is conveyed using the N-SET primitive of the UPS Pull SOP Class.
-
The TDS changes the Unified Procedure Step Status of the UPS to COMPLETED upon completion of the scheduled step and storage or results. This is conveyed using the N-ACTION primitive of the UPS Pull SOP Class with an action type "UPS Status Change". This message informs the TMS that the UPS is now complete.
-
Indicate 'Treatment Session Completed' on TDS Console
The TDS then signals to the User via the TDS user interface that the requested procedure has completed successfully, and all generated SOP Instances have been stored.
