Two treatment planning systems. One shared goal: faster, more consistent dose plans. Achieving that goal with AI turns out to look very different depending on which system is in your linac room.
We've spent the last two years integrating AIVOT with both Varian Eclipse and RaySearch RayStation across community hospitals and university centers in Japan. The technical architectures diverge in ways that matter for clinical workflow, budget planning, and long-term scalability. This article lays out the honest comparison.
Two Architectures, Two Philosophies
Eclipse's AI planning ecosystem is built around RapidPlan, Varian's knowledge-based planning (KBP) engine introduced in version 13.6. RapidPlan learns from your department's historical plans. You feed it a training library of approved IMRT cases, it builds dose-volume histogram (DVH) prediction models, and subsequent plans are initialized against those predictions. The scripting interface is ESAPI (Eclipse Scripting Application Programming Interface) — a C#/.NET API that exposes plan objects, structure sets, and calculation workflows.
RayStation took a different path. Deep Learning Planning (DLP), released in RayStation 11, uses convolutional neural networks to predict 3D dose distributions directly from anatomical contours. The scripting layer is IronPython — a .NET implementation of Python 2.7 that lets you manipulate the full RayStation object model interactively or via scripted automation. More flexible for custom tooling. Also more fragile when RayStation version-bumps its API surface.
Both approaches require an institutional investment in training data. Neither works on day one.
Model Training: KBP vs DL Dose Prediction
RapidPlan's KBP models require a training library of 20 to 30 approved plans minimum for meaningful DVH prediction. The models are geometry-based: they learn the relationship between patient anatomy (PTV overlap with OARs, body shape) and achievable dose distributions. Training runs inside Eclipse on your local server. Clinical physicists review the model statistics before deployment. Plan DVH estimates reflect your institution's planning style and constraints.
RayStation DLP works differently. The deep learning models are either pre-trained by RaySearch using multi-institutional data, or retrained locally. Critically, DLP outputs a predicted 3D dose cube rather than DVH objectives. The planning system then derives optimization parameters from that prediction. In our experience, this produces more spatially granular guidance, but the black-box nature of the 3D prediction can be harder to audit when a plan deviates.
One practical difference: RapidPlan model retraining is a routine physics workflow. Retraining RayStation DLP requires RaySearch involvement or significant local expertise. Most Japanese community hospitals running RayStation rely on vendor-provided pre-trained models for this reason.
Japan Market Reality: Who Uses What
This matters for integration decisions. Bluntly stated.
Eclipse dominates community hospital radiation oncology in Japan. Varian has held strong market share among smaller centers since the early 2010s TrueBeam rollout cycle. Our data shows roughly 65% of community hospitals with IMRT capability in the Tohoku region run Eclipse as their primary TPS. RapidPlan adoption at those sites is moderate — many have the license but haven't fully established their training libraries.
RayStation is more common in university medical centers and large cancer hospitals. Tohoku University, Hokkaido University, and several NCI-designated centers run RayStation, often in parallel with Eclipse for specific disease sites. The IronPython scripting environment is appreciated by medical physicists with programming backgrounds, and the cross-vendor beam model support matters for sites that mix accelerator hardware.
H&N IMRT Workflow: Same Input, Two Paths
Let's be concrete. Head-and-neck IMRT is the archetype case for AI-assisted planning — complex anatomy, multiple OARs, strong evidence for dose-volume benefits. Here's how the workflow diverges after the same DICOM-RT input.
| Step | Eclipse + RapidPlan | RayStation + DLP |
|---|---|---|
| AI trigger | Physicist runs RapidPlan model on plan; DVH estimates populate | DLP generates predicted 3D dose; system derives optimization objectives |
| Objective setting | DVH objectives drawn from KBP prediction bands | Auto-objectives from dose prediction; manual override possible |
| Optimization engine | Progressive Resolution Optimizer (PRO3) | Multi-criteria optimization (MCO) or standard IMRT optimizer |
| Plan review | Compare against RapidPlan expected DVH ranges | Compare against predicted 3D dose distribution |
| QA export | ESAPI export to measurement system (MapCHECK, ArcCHECK) | IronPython script or manual DICOM-RT export |
QA implications differ. Eclipse ESAPI scripting is mature and well-documented; automated gamma analysis pipelines have been in clinical use at Japanese centers since 2017. RayStation's IronPython automation is powerful but requires local scripting expertise. Centers without that expertise often run QA semi-manually.
Licensing and Cost Reality
Honest numbers, because decision-makers need them.
RapidPlan is licensed as a module add-on to Eclipse. Typical Japanese community hospital pricing runs approximately 8 million yen per year for a RapidPlan module including support and updates, on top of base Eclipse TPS maintenance. The exact figure varies with your Varian contract structure, but that's the range we see.
RayStation DLP is similarly structured as a licensed module. University center pricing in Japan typically falls in the 10 to 12 million yen per year range for DLP including RaySearch's standard support tier. The IronPython scripting environment itself is included in base RayStation licensing; the DLP module costs extra.
Total cost of ownership includes physicist time for model training and maintenance. Fact: a well-maintained RapidPlan library at a community hospital requires approximately 20 to 30 physicist-hours per year for retraining and model QA. Under-resourced departments often let models drift.
Where Vendor-Agnostic Tools Make Sense
Here's the thing — both RapidPlan and RayStation DLP are native tools optimized for their own TPS ecosystems. They don't communicate with each other. A department running both systems cannot share a unified AI planning model or compare AI plan quality across systems without external tooling.
AIVOT sits outside the TPS. It connects via DICOM-RT to both Eclipse and RayStation, ingests structure sets and prescription data, and applies its dose prediction and plan-scoring models at the DICOM level. This has practical implications:
- Sites transitioning from Eclipse to RayStation (or running both) can maintain consistent AI planning standards through the migration.
- Plan quality benchmarking becomes TPS-agnostic — you compare H&N IMRT plans from both systems on the same metrics.
- New community hospitals without established RapidPlan libraries can access AI-driven plan initialization without the 30-case bootstrap requirement.
- Physicists working across multiple facilities with different TPS installations use one interface.
This is not an argument that native AI tools are inadequate. For a single-system department with an established training library, RapidPlan or RayStation DLP may meet all planning needs. The vendor-agnostic case is strongest for multi-system environments and smaller centers with limited physics staffing.
Honest Limits of Each Approach
RapidPlan limitations: the KBP model reflects your historical planning style, including its suboptimalities. If your training library contains plans with suboptimal parotid sparing, the model will predict those suboptimal DVH ranges and treat them as acceptable. Model quality degrades if training cases aren't curated. It also doesn't generalize across institutions without retraining.
RayStation DLP limitations: the pre-trained models from RaySearch are built on multi-institutional Western datasets. In our tracking of pilot deployments in Tohoku and Kanto, we've found the parotid and submandibular gland sparing predictions from pre-trained DLP models occasionally underperform against locally-trained RapidPlan models for Japanese anatomical distributions. The difference is modest, but it's real. Local retraining matters more than the vendor documentation suggests.
Both systems require physicists to understand what the AI is doing. Black-box AI planning is a clinical risk, not an efficiency gain. The staff training investment is non-negotiable regardless of which system you're evaluating.
Practical Takeaway
Choose Eclipse RapidPlan if you're a community hospital already on Eclipse with the physics staff to build and maintain a training library. The ESAPI ecosystem is deep, the support network in Japan is strong, and the operational cost is predictable.
Choose RayStation DLP if you're a university center that prioritizes scripting flexibility, runs multiple accelerator vendors, and has the physics expertise to operate IronPython automation. The higher licensing cost reflects broader functionality.
Consider a vendor-agnostic layer — whether AIVOT or another tool — if you run multiple TPS platforms, are growing across facilities, or need consistent AI planning benchmarks that survive hardware and software transitions.
The AI planning ecosystem in Japan is still early. Most community hospitals haven't exhausted what their current native tools can do. Start there. Know what you're paying for.
