Figure BBB.3.2.1-1 illustrates a message sequence example in the case where a treatment procedure delivery is requested and performed by a conventional delivery device requiring an external verification capability.
In the case where external verification is requested (i.e. where the UPS Requested Procedure Code Sequence item has a value of “RT Treatment With External Verification”), the information contained in the UPS and potentially other required delivery data must be communicated to the Machine Parameter Verifier (MPV). In many real-world situations the Oncology Information System fulfils both the role of the TMS and the MPV, hence this communication is internal to the device and not standardized. If separate physical devices perform the two roles, the communication may also be non-standard, since these two devices must be very closely coupled.
Elements in bold indicate the additional messages required when the Machine Parameter Verifier is charged with validating the beam parameters for each beam, prior to radiation being administered. These checks can be initiated by the User on a beam-by-beam basis (‘manual sequencing’, shown with the optional ‘Deliver Beam x’ messages), or can be performed by the Machine Parameter Verifier without intervention (‘automatic sequencing’). The TDS would typically store an RT Treatment Record SOP Instance after each beam.
This example illustrates the case where photon or electron beams are being delivered. If ion beams are to be delivered, instances of the RT Conventional Machine Verification IOD will be replaced with instances of the RT Ion Machine Verification IOD.
Delivery of individual beams can be explicitly requested by the User (as shown in this example), or sequenced automatically by the TDS.
This section describes in detail the additional interactions illustrated in Figure BBB.3.2.1-1.
After the TDS has retrieved the necessary treatment SOP Instances (Step 7), the following step is performed:
7a. Communicate UPS and Required Delivery Data to MPV
The MPV must receive information about the procedure to be performed, and any other data required in order to carry out its role. This communication typically occurs outside the DICOM standard, since the TMS and MPV are tightly coupled (and may be the same physical device). In cases where standardized network communication of these parameters is required, this could be achieved using DICOM storage of RT Plan and RT Delivery Instruction SOP Instances, or alternatively by use of the UPS Push SOP Class.
After the User has initiated the treatment session on the TDS console (Step 8), the following steps are then performed:
8a. ‘Deliver Beam x’ on TDS console
In some implementations, parameter verification for each beam may be initiated manually by the User (as shown in this example). In other approaches, the TDS may initiate these verifications automatically.
8b. Create RT Conventional Machine Verification Instance
The TDS creates a new RT Conventional Machine Verification instance on the MPV prior to beam parameter verification of the first beam to be delivered. This is conveyed using the N-CREATE primitive of the RT Conventional Machine Verification SOP Class.
Figure BBB.3.2.1-1 Treatment Delivery Normal Flow – External Verification Message Sequence
After the TDS has signaled the UPS current Referenced Beam Number and completion percentage for a given beam (9), the following sequence of steps is performed:
9a. Set ‘Beam x’ RT Conventional Machine Verification Instance
The TDS sets the RT Conventional Machine Verification SOP Instance to transfer the necessary verification parameters. This is conveyed using the N-SET primitive of the RT Conventional Machine Verification SOP Class. The Referenced Beam Number (300C,0006) attribute is used to specify the beam to be delivered. It is the responsibility of the SCU to keep track of the verification parameters such that the complete list of required attributes can be specified within the top-level sequence items.
9b. Initiate Verification
The TDS sets the RT Conventional Machine Verification SOP Instance to indicate that the TDS is ready for external verification to occur. This is conveyed using the N-ACTION primitive of the RT Conventional Machine Verification SOP Class.
9c. Verify Machine Parameters
The MPV then attempts to verify the treatment parameters for ‘Beam x’. The MPV sends one or more N-EVENT-REPORT signals to the TDS during the verification process. The permissible event types for these signals in this context are ‘Pending’ (zero or more times, not shown in this use case), and ‘Done’ when the verification is complete (successful or otherwise).
9d. Get RT Conventional Machine Verification (optional step)
The TDS may then request attributes of the RT Conventional Machine Verification instance. This is conveyed using the N-GET primitive of the RT Conventional Machine Verification SOP Class. If verification has occurred normally and the N-EVENT-REPORT contained a Treatment Verification Status of VERIFIED (this use case), then this step is not necessary unless the TDS wishes to record additional parameters associated with the verification process.
The TDS then delivers the therapeutic radiation. 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 or MPV, are not described here. If the delivery requires an override of additional information, a different message flow occurs. This is illustrated in the use case described in the next section.
9e. Store ‘Beam x’ RT Beams Treatment Record to Archive
The TDS stores an RT Beams Treatment Record to the Archive (or potentially the TMS as described in Section BBB.3.1.2 Transactions and Message Flow). The RT Beams Treatment Record is therefore not stored in Step 11 for the external verification case (since it has already been stored in the step on a per-beam basis).
For each subsequent beam in the sequence of beams being delivered, steps 8a (optional), 9, 9a, 9b, 9c, 9d (optional), and 9e are then repeated, i.e. N-SET, N-ACTION, and N-GET operations are performed on the same instance of the RT Conventional Machine Verification SOP Class, which persists throughout the beam session.
9f. Delete RT Conventional Machine Verification Instance
When all beams have been processed, the TDS deletes the RT Conventional Machine Verification SOP Instance to indicate to the MPV that verification is no longer required. This is conveyed using the N-DELETE primitive of the RT Conventional Machine Verification SOP Class.