BBB.3.4.2 Transactions and Message Flow
Prev | BBB.3.4 Treatment-delivery With External Verification - Machine Adjustment Required | Next

#### BBB.3.4.2 Transactions and Message Flow

This section describe in detail the interactions illustrated in Figure BBB.3.4.1-1.

1. 'Deliver Beam x' on TDS console (optional step)

   See use case BBB.3.2.

2. Create RT Conventional Machine Verification Instance

   See use case BBB.3.2.

3. Set 'Beam x' RT Conventional Machine Verification Instance

   See use case BBB.3.2.

4. Initiate Machine Verification

   See use case BBB.3.2.

5. Verify Machine Parameters

   The MPV then attempts to verify the treatment parameters for 'Beam x'. The MPV determines that one or more treatment parameters are out-of-tolerance. It sends an N-EVENT-REPORT signal to the TDS with an Event Type of Done and an RT Machine Verification Status of NOT_VERIFIED. It may also display the verification status and information to the user (5a).

6. Get RT Conventional Machine Verification

   The TDS then requests the failed verification parameters of the verification process. This is conveyed using the N-GET primitive of the RT Conventional Machine Verification SOP Class. The MPV replies with an N-GET-RESPONSE having a Treatment Verification Status of NOT_VERIFIED. The reason(s) for the failure is encoded in the Failed Parameters Sequence (0074,1048) attribute of the response.

7. Request machine adjustment

   As illustrated in this example, some implementations may require that the User observes the failed verification parameters on the MPV console and manually request the required machine adjustment. In this case the User makes the request to the TDS via its user interface. In other implementations the TDS makes the adjustments automatically and request verification without User intervention.

8. Adjust TDS and Set 'Beam x' RT Conventional Machine Verification Instance

   The TDS adjusts one or more of its parameters as requested, then sets the RT Conventional Machine Verification SOP Instance to indicate that the TDS is once again ready for treatment delivery. This is conveyed using the N-SET primitive of the RT Conventional Machine Verification SOP Class. The N-SET command provides values for all applicable parameters (not just those that have been modified) since if one or more parameters within a top-level sequence is supplied, then all the applicable parameters within that sequence must also be supplied (otherwise DICOM requires their values to be cleared).

9. Initiate Machine Verification

   The TDS performs another N-ACTION on the RT Conventional Machine Verification SOP Instance to request that the MPV re-perform treatment verification. See use case BBB.3.2.

   As an optional step, the MPV may notify the TDS that the verification is in process at any time, by sending an N-EVENT-REPORT signal to the TDS with an Event Type of Pending (9a).

10. Re-verify Machine Parameters

    The MPV verifies the treatment parameters, and determines that the required adjustments have been made, i.e., all parameters are now within tolerance. It sends an N-EVENT-REPORT signal to the TDS with an Event Type of Done and an RT Conventional Machine Verification Status of VERIFIED.

    ### Note

    If another verification failure occurs, the override cycle can be repeated as many times as necessary.

11. Get RT Conventional Machine Verification (optional step)

    See use case BBB.3.2.

    The TDS then delivers the therapeutic radiation.

12. Store 'Beam x' RT Beams Treatment Record to Archive

    See use case BBB.3.2.

13. Delete RT Conventional Machine Verification Instance

    See use case BBB.3.2.

Prev | Up | Next
BBB.3.4 Treatment-delivery With External Verification - Machine Adjustment Required | Home | CCC Ophthalmic Axial Measurements and Intraocular Lens Calculations Use Cases (Informative)