Материал: part17

1. ‘List Procedures for Delivery’ on TDS console

2.Query UPS (C-FIND)

3.Receive 0-n UPS

Display list to User

4.‘Select Procedure’ on TDS console (optional, if only one procedure in list)

5.Get UPS details (C-GET)

Receive UPS details

Extract input UIDs from selected UPS

5a. Retrieve Archive Objects (C-MOVE)

RT Plan and any other required objects

(e.g., verification images, RT Beam Treatment Records)

6.Change UPS ‘IN PROCESS’ (N-ACTION with Transaction UID)

7.Retrieve TMS objects (C-MOVE)

RT Beams Delivery Instruction

RT Treatment Record Summary

RT Beams Treatment Rec (if not in 5)

7a. Communicate UPS and any required delivery data using a non-specified mechanism

8. ‘Start Treatment Session’ on TDS console

8a. ‘Deliver Beam 1’ on TDS console

8b. Create RT Conv. Machine Verification

(N-CREATE)

9. Set UPS 0% complete, Beam ‘1’ (N-SET)

9a. Set ‘Beam1’ RT Conv. Machine Verification (N-SET)

9b. Initiate verification (N-ACTION)

Verify

9c. Notify Verification Status (N-EVENT-REPORT,

Event-Type = ‘Done’, TVS = VERIFIED)

9d. Get RT-Conv. Machine Verification (N-GET)

- optional instruction

DELIVER RADIATION

9e. Store ‘Beam1’ RT Beams Treatment Record (C-STORE)

8a. ‘Deliver Beam 2’ on TDS console

9. Set UPS 50% complete, Beam ‘2’ (N-SET)

9a. Set ‘Beam2’ RT Conv. Machine Verification (N-SET)

9b. Initiate verification (N-ACTION)

Verify

9c. Notify Verification Status (N-EVENT-REPORT,

Event-Type = ‘Done’, TVS = VERIFIED)

9d. Get RT-Conv. Machine Verification (N-GET) - optional instruction

DELIVER RADIATION

9e. Store ‘Beam2’ RT Beams Treatment Record (C-STORE)

9f. Delete RT Conv. Machine Verification

(N-DELETE)

10.Set UPS 100% complete, (N-SET)

11.Store other result objects (C-STORE)

12.Set UPS to Final State (N-SET)

13.Change UPS ‘COMPLETED’ (N-ACTION)

14.Indicate ‘Treatment Session Completed on TDS Console’

Figure BBB.3.2.1-1. Treatment Delivery Normal Flow - External Verification Message Sequence​

AftertheTDShassignaledtheUPScurrentReferencedBeamNumberandcompletionpercentageforagivenbeam(9),thefollowing​ sequence of steps is performed:​

- Standard -​

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​ containedaTreatmentVerificationStatusofVERIFIED(thisusecase),thenthisstepisnotnecessaryunlesstheTDSwishestorecord​ additional parameters associated with the verification process.​

TheTDSthendeliversthetherapeuticradiation.Inthecurrentusecase,itisassumedthattheradiationcompletesnormally,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​

TheTDSstoresanRTBeamsTreatmentRecordtotheArchive(orpotentiallytheTMSasdescribedinSectionBBB.3.1.2Transactions​ 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​ MPVthatverificationisnolongerrequired.ThisisconveyedusingtheN-DELETEprimitiveoftheRTConventionalMachineVerification​ SOP Class.​

BBB.3.3 Treatment-delivery With External Verification - Override Or Additional Info Required​

BBB.3.3.1 Message Sequencing​

Figure BBB.3.3.1-1 illustrates a message sequence example for the external verification model in the case where the Machine​ Parameter Verifier (MPV) either detects that an override is required, or requires additional information (such as a bar code) before​ authorizing treatment.​

The steps in this use case replace Steps 8a to 9f in Use Case BBB.3.2, for the case where only a single beam is delivered.​

- Standard -​

FigureBBB.3.3.1-1.TreatmentDeliveryMessageSequence-OverrideorAdditionalInformationRequired​

BBB.3.3.2 Transactions and Message Flow​

This section describes in detail the interactions illustrated in Figure BBB.3.3.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 para-​ meters are out-of-tolerance, or that information such as a bar code is missing. 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. The MPV also shows the reason for the​ override/information request on its display (5a).​

6.​Supply Override Instruction or Bar Code​

The User observes on the MPV console that an override or missing information is required, and supplies the override approval​ or missing information to the MPV via its user interface, or equivalent proxy.​

- Standard -​

7.​Initiate Machine Verification​

The TDS performs another N-ACTION on the RT Conventional Machine Verification SOP Instance to indicate that the TDS is​ once again ready for treatment verification. See use case BBB.3.2. This may be initiated by the user (as shown in this example),​ or may be initiated automatically by the TDS using a polling approach.​

8.​Re-verify Machine Parameters​

The MPV verifies the treatment parameters, and determines that all parameters are now within tolerance and all required inform-​ ation is supplied. It sends an N-EVENT-REPORT signal to the TDS with an Event Type of Done and an RT Machine Verification​ Status of VERIFIED_OVR.​

Note​

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

9.​Get RT Conventional Machine Verification (optional step)​

See use case BBB.3.2. If an N-GET is requested, the parameters that were overridden are available in Overridden Parameters​ Sequence (0074,104A).​

The TDS then delivers the therapeutic radiation.​

10.​Store 'Beam x' RT Beams Treatment Record to Archive​

See use case BBB.3.2. Overridden parameters are ultimately captured in the treatment record.​

11.​Delete RT Conventional Machine Verification Instance​

See use case BBB.3.2.​

BBB.3.4 Treatment-delivery With External Verification - Machine Adjustment Required​

BBB.3.4.1 Message Sequencing​

Figure BBB.3.4.1-1 illustrates a message sequence example for the external verification model in the case where the Machine​ Parameter Verifier (MPV) detects that one or more machine adjustments are required before authorizing treatment, and the TDS has​ been configured to retrieve the failure information and make the required adjustments.​

The steps in this use case replace Steps 8a to 9f in Use Case BBB.3.2, for the case where only a single beam is delivered.​

- Standard -​

Figure BBB.3.4.1-1. Treatment Delivery Message Sequence - Machine Adjustment Required​

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 para-​ meters 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​

- Standard -​