# ESAPI v18 – VMAT Verification Plan: Dose Rate Forced to 400 MU/min and ~2% MU Difference

[marioalexliuzzo-hash]

Hello everyone,

I am developing an ESAPI v18 application to automatically create QA verification plans from clinical VMAT plans.

The workflow is based on the standard ESAPI verification plan approach:

1. Import a phantom image/structure set.
2. Create a verification plan using:

course.AddExternalPlanSetupAsVerificationPlan(
    verificationStructures,
    verifiedPlan);

3. Recreate all treatment beams manually using:

verificationPlan.AddVMATBeam(...)

4. Copy beam geometry and MLC information through editable beam parameters:

var editable = qaBeam.GetEditableParameters();

For each control point I copy:

dstCP.JawPositions  = srcCP.JawPositions;
dstCP.LeafPositions = srcCP.LeafPositions;
dstCP.GantryAngle   = srcCP.GantryAngle;

Then I apply the parameters:

qaBeam.ApplyParameters(editable);

The meterset weights used to build the VMAT beam are taken directly from the source plan:

var meterset =
    beam.ControlPoints.Select(cp => cp.MetersetWeight);

For dose calculation I use:

verificationPlan.CalculateDose();

(and CalculateDoseWithPresetValues() for DoseDynamic plans).

The verification plan is successfully created and dose calculation completes without errors.

However, I am observing two unexpected behaviors:

1. Dose Rate is always 400 MU/min

The original treatment plan uses a different dose rate (for example 600 MU/min or 1400 MU/min depending on machine and energy).

Even though the beam is created using:

new ExternalBeamMachineParameters(
    beam.TreatmentUnit.Id,
    beam.EnergyModeDisplayName,
    beam.DoseRate,
    beam.Technique.Id,
    string.Empty);

the resulting QA beam always shows 400 MU/min.

2. Final MU differs by about 2%

The recreated QA plan generally produces approximately 2% lower MU than the original plan.

When comparing control points between the original beam and the QA beam:

Matching values

• Control Point Index
• Meterset Weight
• Gantry Angle
• Jaw Positions
• Leaf Positions

Non-matching values (only in some control points, around 10–15 CPs in my test plan)

• Dose Rate [MU/min]
• Gantry Speed [deg/s]
• MU/deg

These differences appear even though the geometric parameters and meterset weights are copied directly from the original beam.

My questions are:

1. Is ESAPI recalculating VMAT delivery parameters (Dose Rate, Gantry Speed, MU/deg) during AddVMATBeam() or CalculateDose()?
2. Is the 400 MU/min value expected behavior for verification plans?
3. Has anyone observed a systematic ~1–2% MU difference when recreating VMAT beams this way?
4. Is there any supported method in ESAPI v18 to preserve the original VMAT delivery parameters exactly?

Any feedback or similar experiences would be greatly appreciated.

Thank you.

[kwwall]

I don't think this is the ESAPI library that you're looking for. This ESAPI is a Java library of security control ls sponsored by OWASP, and the latest version is v2.7.1 0-RC1, so we have a way to go until version 18.

…

-- Blog: https://off-the-wall-security.blogspot.com/ | GitHub: @kwwall <https://github.com/kwwall>| OWASP ESAPI Project <https://owasp.org/www-project-enterprise-security-api/>co-lead | OWASP and ACM lifetime member NSA: All your crypto bit are belong to us.

On Mon, Aug 10, 2026, 12:08 PM Mario Alexander Liuzzo < ***@***.***> wrote: Hello everyone, I am developing an ESAPI v18 application to automatically create QA verification plans from clinical VMAT plans. The workflow is based on the standard ESAPI verification plan approach: 1. Import a phantom image/structure set. 2. Create a verification plan using: course.AddExternalPlanSetupAsVerificationPlan( verificationStructures, verifiedPlan); 3. Recreate all treatment beams manually using: verificationPlan.AddVMATBeam(...) 4. Copy beam geometry and MLC information through editable beam parameters: var editable = qaBeam.GetEditableParameters(); For each control point I copy: dstCP.JawPositions = srcCP.JawPositions;dstCP.LeafPositions = srcCP.LeafPositions;dstCP.GantryAngle = srcCP.GantryAngle; Then I apply the parameters: qaBeam.ApplyParameters(editable); The meterset weights used to build the VMAT beam are taken directly from the source plan: var meterset = beam.ControlPoints.Select(cp => cp.MetersetWeight); For dose calculation I use: verificationPlan.CalculateDose(); (and CalculateDoseWithPresetValues() for DoseDynamic plans). The verification plan is successfully created and dose calculation completes without errors. However, I am observing two unexpected behaviors: 1. Dose Rate is always 400 MU/min The original treatment plan uses a different dose rate (for example 600 MU/min or 1400 MU/min depending on machine and energy). Even though the beam is created using: new ExternalBeamMachineParameters( beam.TreatmentUnit.Id, beam.EnergyModeDisplayName, beam.DoseRate, beam.Technique.Id, string.Empty); the resulting QA beam always shows 400 MU/min. 2. Final MU differs by about 2% The recreated QA plan generally produces approximately 2% lower MU than the original plan. When comparing control points between the original beam and the QA beam: *Matching values* - Control Point Index - Meterset Weight - Gantry Angle - Jaw Positions - Leaf Positions *Non-matching values (only in some control points, around 10–15 CPs in my test plan)* - Dose Rate [MU/min] - Gantry Speed [deg/s] - MU/deg These differences appear even though the geometric parameters and meterset weights are copied directly from the original beam. My questions are: 1. Is ESAPI recalculating VMAT delivery parameters (Dose Rate, Gantry Speed, MU/deg) during AddVMATBeam() or CalculateDose()? 2. Is the 400 MU/min value expected behavior for verification plans? 3. Has anyone observed a systematic ~1–2% MU difference when recreating VMAT beams this way? 4. Is there any supported method in ESAPI v18 to preserve the original VMAT delivery parameters exactly? Any feedback or similar experiences would be greatly appreciated. Thank you. — Reply to this email directly, view it on GitHub <#917?email_source=notifications&email_token=AAO6PG3DU3XL3ROSREKQ5DL5JHXOTA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDKOBYHA3DPJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO6PG35D7WK7DVNCDBQGGD5JHXOTAVCNFSNUABHKJSXA33TNF2G64TZHMZDGOBVG42DMMZ3IRUXGY3VONZWS33OHMYTANJYHA4DMN5BOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAO6PG6TLYCCBDINKRHNNXT5JHXOTA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDKOBYHA3DPJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAO6PG6U7MXCQ626JEAT7X35JHXOTA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDKOBYHA3DPJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>