PS-2020a / 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 -​

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 Conven-​ tional 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.​

Asanoptionalstep,theMPVmaynotifytheTDSthattheverificationisinprocessatanytime,bysendinganN-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.​

- Standard -​

CCC Ophthalmic Axial Measurements and​ Intraocular Lens Calculations Use Cases​ (Informative)​

CCC.1 Axial Measurements​

An axial measurements device is used to take axial measurements of the eye, from the anterior surface of the cornea to either the​ surface of the retina (ultrasound) or the retinal photoreceptors (optical). The axial measurements are typically expressed in mm​ (Ophthalmic Axial Length (0022,1010). Currently these measurements are taken using ultrasound or laser light. The measurements​ are used in calculation of intraocular lens power for cataract surgery. Axial measurements devices and software on other systems​ perform intraocular lens power calculations using the axial measurements in addition to measurements from other sources (currently​ by manual data entry, although importation from other software systems is expected in the future).​

When the natural lens of the eye turns opaque it is called a cataract. The cataract is surgically removed, and a synthetic intraocular​ lens is placed where the natural lens was before. The power of the lens that is placed determines what the patient's refractive error​ will be, meaning what power his glasses will need to be to maximize vision after surgery.​

Axial measurements devices provide graphical displays that help clinicians to determine whether or not the probe used in taking the​ measurements is aligned properly. Annotations on the display provide information such as location of gates that assists the clinician​ in assessing measurement quality. High, fairly even waveform spikes suggest that the measurement producing a given graph is likely​ to be reliable. The quality of the graphical display is one of the factors that a clinician considers when choosing which axial length​ measurement to use in calculating the correct intraocular lens power for a given patient.​

CCC.2 Intraocular Lens Calculations Introduction​

Axial measurements devices and software on other systems perform intraocular lens power calculations for cataract surgery patients.​ The power selection of intraocular lens to place in a patient's eye determines the refractive correction (e.g., glasses, contact lenses,​ etc.) the patient will require after cataract surgery.​

The data input for these calculations consists of ophthalmic axial length measurements (one dimensional ultrasound scans that are​ called "A-scans" in the eye care domain) and keratometry (corneal curvature) measurements in addition to constants and sometimes​ others kinds of measurements. The data may come from measurements performed by the device, on which the intraocular lens cal-​ culationsoftwareresides,orfrommanualdataentry,orfromanexternalsource.Thereareanumberofdifferentformulasandconstants​ available for doing these calculations. The selection of formula to use is based on clinician preference and on patient factors such as​ the axial length of the eye. The most commonly used constants, encoded by Concept Name Code Sequence (0040,A043) using CID​ 4237 “Lens Constant Type”, are a function of the model of intraocular lens to be used.​

Themostcommonlyusedformulas,encodedbyIOLFormulaCodeSequence(0022,1029)usingCID4236“IOLCalculationFormula”,​ for intraocular lens calculation are inaccurate in a patient who has had refractive surgery, and numerous other formulas are available​ for these patients. Since most of them have not been validated to date, they were not included in this document.​

Intraocularlenscalculationsoftwaretypicallyprovidestabulardisplaysofintraocularlenspowerinassociationwitheachlens'spredicted​ refractive error (e.g., glasses, contact lenses, etc).​

- Standard -​

Pupil

Cornea

Conjunctiva

Iris

Lens

Retina

Sclera

Optic nerve

Figure CCC.2-1. Sagittal Diagram of Eye Anatomy (when the lens turns opaque it is called a cataract)​

Courtesy; National Eye Institute, National Institutes of Health; ftp://ftp.nei.nih.gov/eyean/eye_72.tif​

Figure CCC.2-2. Eye with a cataract​

Courtesy; National Eye Institute, National Institutes of Health; ftp://ftp.nei.nih.gov/eyedis/EDA13_72.tif​

- Standard -​

Figure CCC.2-3. Eye with Synthetic Intraocular Lens Placed After Removal of Cataract​

This file is licensed under the Creative Commons Attribution Share Alike 2.5 License, Author is Rakesh Ahuja, MD (http://​ en.wikipedia.org/wiki/Image:Posterior_capsular_opacification_on_retroillumination.jpg)​

CCC.3 Output of An Ultrasound A-scan Device​

FigureCCC.3-1demonstratesanA-scanwaveform-producedbyanultrasounddeviceusedforophthalmicaxiallengthmeasurement.​ This is referenced in the Ophthalmic Axial Measurements IOD in Referenced Ophthalmic Axial Length Measurement QC Image Se-​ quence (0022,1033).​

Figure CCC.3-1. Scan Waveform Example​

Time (translated into distance using an assumed velocity) is on the x-axis, and signal strength is on the y-axis. This waveform allows​ clinicians to judge the quality of an axial length measurement for use in calculating the power of intraocular lens to place in a patient's​ eye in cataract surgery. Figure CCC.3-1 above demonstrates a high quality scan, with tall, even spikes representing the ocular​ structuresofinterest.Thistellstheclinicianthattheprobewasproperlyalignedwiththeeye.Thefirst,doublespikeontheleftrepresents​ anterior cornea followed by posterior cornea. The second two, more widely spaced spikes represent anterior and posterior lens. The​ first tall spike on the right side of the display is the retinal spike, and the next tall spike to the right is the sclera. Smaller spikes to the​

- Standard -​

far right are produced by orbital tissues. Arrows at the bottom of the waveform indicate the location of gates, which may be manually​ adjusted to limit the range of accepted values. Note that in the lower right corner of the display two measurements are recorded. In​ the column labeled AXL is an axial length measurement, which on this device is the sum of the measurements for ACD (anterior​ chamberdepth),lens,andVCD(vitreouschamberdepth).Themeasuredtimevalueforeachofthesegmentsandapresumedvelocity​ ofsoundforthatsegmentareusedtocalculatetheaxiallengthforthatsegment.Anaveragevalueforeachcolumnisdisplayedbelow​ along with the standard deviation of measurements in that column. The average axial length is the axial length value selected by this​ machine, although often a clinician will make an alternative selection.​

CCC.4 Output of An Optical A-scan Device​

Figure CCC.4-1 demonstrates the waveform-output of a partial coherence interferometry (PCI) device used for optical ophthalmic​ axial length measurement. This is referenced in the Ophthalmic Axial Measurements IOD in Referenced Ophthalmic Axial Length​ Measurement QC Image Sequence (0022,1033).​

Figure CCC.4-1. Waveform Output of a Partial Coherence Interferometry (PCI) Device Example​

Physical distance is on the x axis, and signal strength is on the y axis. What is actually measured is phase shift, determined by looking​ atinterferencepatternsofcoherentlight.Physicaldistanceiscalculatedbydividing"opticalpathlength"bythe"refractivegroupindex"​ - using an assumed average refractive group index for the entire eye. The "optical path length" is derived from the phase shift that is​ actually observed. Similar to ultrasound, this waveform allows clinicians to judge the quality of an axial length measurement.​

Figure CCC.4-1 above demonstrates a high quality scan, with tall, straight spikes representing the ocular axial length. The corneal​ spike is suppressed (outside the frame on the left hand side) and represents the reference 0 mm. The single spike on this display​ represents the signal from the retinal pigment epithelium (RPE) and provides the axial length measurement value (position of the​ circlemarker).SometimessmallerspikescanbeobservedontheleftorrightsideoftheRPEpeak.Thosespikesrepresentreflections​ from the internal limiting membrane (ILM,150-350 µm before RPE) or from the choroid (150-250 µm behind RPE) respectively.​

Because all classical IOL power calculation formulas expect axial lengths measured to the internal limiting membrane (as provided​ by ultrasound devices), axial length measurements obtained with an optical device to the retinal pigment epithelium are converted to​ this convention by subtracting the retinal thickness.​

Figure CCC.4-1 above displays five axial length measurements obtained for each eye (one column for each eye) and the selected​ axial length value is shown below the line.​

CCC.5 IOL Calculation Results Example​

Figure CCC.5-1 demonstrates a typical display of IOL (intraocular lens) calculation results.​

- Standard -​