Getting an AI planning engine to talk to your treatment planning system sounds straightforward. Import a DICOM file, accept the plan, treat the patient. In practice, about one in sixteen imports exposes a mismatch that requires manual intervention before any beam can fire. We've worked through enough Eclipse handshakes and Monaco round-trips to know where the bodies are buried.
The Four DICOM-RT Objects You Need to Understand
DICOM-RT is not a single file format. It is a family of four distinct storage objects, each carrying a different slice of the clinical workflow.
| Object | Contains | Typical size |
|---|---|---|
| RTSTRUCT | Contour sets, structure names, ROI metadata | 2-40 MB |
| RTPLAN | Beam geometry, gantry angles, MU per control point, isocenter | 100 KB-5 MB |
| RTDOSE | 3D dose grid, DVH reference data | 20-200 MB |
| RTIMAGE | Port films, EPID frames for geometric verification | 10-80 MB per frame |
When AIVOT exports a plan for import into a clinical TPS, it sends RTSTRUCT plus RTPLAN. The dose grid (RTDOSE) is generated by the TPS's own dose engine after import, which is the correct clinical flow: the TPS vendor's dose calculation is what the physicist will sign off on, not ours. RTIMAGE stays entirely within the record-and-verify system and never touches AIVOT at all.
Vendor Reality: Eclipse, Monaco, Pinnacle, RayStation
The DICOM-RT standard is 25 years old. Every major TPS vendor has interpreted it slightly differently, usually for reasons that made sense at the time. Here is what we see in practice.
Varian Eclipse 18.0 is the most permissive importer in our test fleet. It accepts RTPLAN objects with up to 200 control points per beam without complaint, and its DICOM store service via C-STORE is stable at the default AE title configuration. The quirk: Eclipse applies a bolus attachment check on import. If AIVOT references a bolus ROI in the RTPLAN that was not exported with the RTSTRUCT, Eclipse will reject the import with a non-obvious error code. We trap this and strip bolus references before export now.
Elekta Monaco 5.x is strict about control point count. Monaco's internal arc representation uses a different sampling density from most AI planners. An IMRT plan with 51 control points per beam imports cleanly. A VMAT arc exported at 178 control points can trigger a Monaco parsing warning that forces the physicist to manually verify beam parameters before the plan is unlocked for calculation. Not a hard failure. But a friction point. Every time.
Philips Pinnacle presents a different challenge: it converts RTPLAN data into its internal p3 format on import. Isocenter coordinates survive that conversion accurately, but wedge direction encoding uses a non-standard DICOM private tag in Pinnacle's own RTPLAN exports, absent in an AI-generated plan. The import completes, but the physicist gets a notification about missing modifier data. Cosmetic for IMRT plans. Not cosmetic for 3D-CRT plans with physical wedges.
RaySearch RayStation 12B is the strictest of the four. RayStation validates referenced SOP Instance UIDs on import: the RTPLAN must reference the exact RTSTRUCT SOP UID it was created from. If the AI system regenerated the RTSTRUCT after an auto-contouring revision, the UID changes and RayStation refuses the import. This is a safety feature, not a bug. It requires that AI planning workflows keep structure sets and plans linked by UID through every revision cycle.
Coordinate Systems: The Quiet Failure Mode
DICOM uses the IEC 61217 patient coordinate system. So do most AI planners. So do most TPS systems. In our tracking, 6% of integration failures trace back to coordinate system inconsistencies rather than missing fields or UID errors.
The trap: scanner DICOM coordinate space versus TPS planning space. A CT scanner exports images with the patient coordinate origin at a particular physical location. When an AI planner defines an isocenter in world coordinates from the CT DICOM frame and the TPS re-establishes its origin slightly differently during import, isocenter can shift by 1-3 mm. For most scenarios, sub-clinical. For a stereotactic brain case, it is not.
The fix: express isocenter in patient coordinates relative to a named structure centroid (usually the gross tumor volume or a fiducial marker), not in absolute DICOM world coordinates. Both AIVOT and the receiving TPS then anchor to the same clinical landmark. This requires the structure set to be imported before the plan, which is the correct sequence in any case.
Structure Naming Conventions That Break Across Vendors
RTSTRUCT ROI names are free-text strings in the DICOM standard. Every institution and every AI planner chooses its own naming convention. The result is a long-standing interoperability problem.
Practical note: ``PTV_7000'' and ``PTV Boost 70Gy'' refer to the same structure at different institutions, but no TPS can automatically map between them. Dose-volume constraint rules are linked to structure names. Wrong name, wrong constraint lookup.
We maintain a structure name normalization table that maps common variants to TG-263 standard nomenclature before RTPLAN export. TG-263 defines ``PTV_7000cGy'' as the canonical form for a 70 Gy PTV. Eclipse, RayStation, and Monaco all have TG-263 mapping layers now, though coverage is not 100%. Pinnacle requires a manual mapping step in the site's template library, a one-time configuration per institution.
The failure mode is subtle: a plan imports, constraints run, the physicist approves. Then during chart review someone notices the DVH for ``PTV Boost'' shows a different structure than intended because the auto-mapping linked to the wrong ROI. We've seen this. It is why AIVOT exports a structure name report alongside every RTPLAN, listing how each AI-generated ROI maps to the receiving TPS. The physicist signs it before plan approval.
Plan Import Round-Trip Issues
Several RTPLAN attributes do not survive a round-trip through every TPS without transformation.
- Beam weights and monitor units: MU values in RTPLAN are stored as floating-point. Eclipse rounds to two decimal places on import. For most beams, the difference is under 0.1 MU. For a very short arc segment, it can be 0.5 MU. Our exports round to two decimal places before sending to avoid phantom discrepancies on the physicist's plan comparison screen.
- Isocenter offsets: If the plan isocenter does not coincide with the DICOM image origin and the TPS applies a coordinate transform on import, isocenter can shift. See coordinate systems section above. Explicit structure-anchored coordinates prevent this.
- Control point count limits: Monaco caps VMAT arcs at 180 control points per arc. AIVOT's default VMAT export uses 181 points for a full arc. Off by one. We fixed this in firmware 2.3.1 after seeing it on two sites. Simple. Embarrassing in retrospect.
- Collimator rotation conventions: The collimator angle convention in IEC 61217 is counterclockwise-positive looking from the source. Several linac models from one major vendor historically used clockwise-positive for one specific collimator type. DICOM does not encode which convention applies. This is 4% of the 6% of failures we see on import. The fix requires a site-specific collimator rotation flag in the AIVOT configuration, set during commissioning.
The Safety-Critical Rule: Plan QA After Every Import
This is not optional. Not for any plan. Not for any vendor. Not even if you've run a hundred identical imports before.
After importing an RTPLAN from an AI planning tool into a clinical TPS, the physics team must run the full plan QA sequence:
- Point dose verification (independent monitor unit calculation)
- 3D gamma analysis against the expected dose grid (typical pass criterion: 3%/3mm, 95% of points)
- DVH constraint review against approved plan objectives
In our pilot data across 847 AIVOT-to-TPS imports, 94% required zero manual adjustment after import. The physicist reviewed QA results, confirmed parameters matched, and approved. Fast. The 6% that needed intervention were caught during QA, before any fraction was delivered. That is the system working correctly. QA is not overhead. It is the safety margin that makes the workflow trustworthy.
Fact: the most common reason a plan passes visual inspection but fails point-dose verification is the MU rounding issue described above, combined with a specific beam geometry that amplifies the discrepancy. It looks fine. It is not fine. Run the numbers.
What Actually Breaks in That 6%
Two root causes account for the majority of the 6% failure cases in our data.
First: collimator rotation convention mismatches. Sites commissioned under an older IEC interpretation where the linac configuration was never updated. The site-specific collimator rotation flag in AIVOT commissioning mode catches this during the initial validation run.
Second: bolus structures. When a plan includes a bolus ROI, the bolus must appear in both the RTSTRUCT and the RTPLAN with matching SOP UIDs. If the bolus was added after the initial contouring session (common in certain head-and-neck protocols), the RTSTRUCT may have been re-exported with a new SOP UID. Eclipse handles this with a warning. RayStation refuses the import. Monaco imports the plan and silently ignores the bolus reference, which is arguably the most dangerous behavior of the three.
We've built a pre-export validation step in AIVOT that checks bolus SOP UID consistency before the plan leaves the AI system. It runs in under 200 milliseconds. It has prevented 23 import failures across the pilot cohort.
Getting Integration Right
DICOM-RT integration between AI planning tools and clinical TPS systems works reliably when the configuration is done carefully. The 94% zero-adjustment rate from our pilot data is achievable in production, but it requires commissioning time, site-specific configuration, and a physics team that runs QA on every plan. No exceptions.
Honestly, the institutions that do this well share one characteristic: they treat AI integration commissioning the same way they treat a new linac acceptance. Systematic. Documented. Not rushed.
