DICOM RT is the common language of radiation therapy data exchange. Every treatment planning system in clinical use today supports it; every linac control system reads from it; every record-and-verify system stores its data structures. For any software that wants to participate in a radiation therapy workflow — including AI planning systems, adaptive RT tools, and dosimetric QA platforms — DICOM RT compliance is not a feature. It is the admission requirement.
Understanding what DICOM RT actually specifies — and where it leaves room for implementation variation that creates real integration headaches — is essential background for clinical departments evaluating new software.
The DICOM RT Object Classes
DICOM RT defines a set of storage classes that map to the clinical workflow stages of radiation therapy:
- RT Structure Set (RTSTRUCT): contour data for targets and OARs, linked to a reference CT image series via frame of reference UID.
- RT Plan (RTPLAN): beam parameters — gantry angles, collimator settings, MLC leaf positions, monitor units per beam, isocenter coordinates.
- RT Dose (RTDOSE): 3D dose distribution array, stored as a voxelized dose grid with spatial registration to the CT geometry.
- RT Image (RTIMAGE): portal images, DRRs (digitally reconstructed radiographs), used for field verification.
- RT Ion Plan / RT Ion Beam Treatment Record: extensions for proton and heavy-ion therapy.
A complete treatment plan for a single patient consists of an RTSTRUCT linked to a CT series, an RTPLAN referencing that RTSTRUCT, and one or more RTDOSE objects representing the computed dose distribution. The chain of UID references — CT series UID → RTSTRUCT's referenced frame of reference UID → RTPLAN's referenced structure set UID → RTDOSE's referenced plan UID — is how the TPS and downstream systems verify data integrity and maintain the patient's treatment record.
Where Round-Trip Integration Breaks Down
In theory, DICOM RT's standardized object hierarchy should make vendor interoperability straightforward. In practice, clinical departments running mixed-vendor environments regularly encounter integration problems that trace to DICOM RT implementation variability.
The most common failure mode involves RTSTRUCT ROI naming conventions. DICOM RT does not mandate structure names — it only defines the data fields for storing them. Each TPS vendor has evolved its own naming conventions for standard structures: one system exports the prostate CTV as "PTV_prostate", another as "CTV_Prostate_70Gy", another as "PTV1". When an AI planning system or external dosimetric analysis tool reads an RTSTRUCT file and needs to identify which structure is the planning target volume, it must either rely on the ROI name string (fragile) or the ROI interpreted type field (more reliable, but inconsistently populated by TPS exporters).
At a regional cancer center in the Tohoku region, an AI planning integration pilot encountered this issue when processing RTSTRUCT files exported from the department's clinical TPS: approximately 30% of imported cases had ROI interpreted type fields unpopulated, requiring manual structure identification mapping before the AI planning engine could process the case. Solving this required a pre-processing step that standardized structure identification based on a combination of ROI name parsing rules and anatomy-based classification — adding a configuration burden that the department had not anticipated in the integration scoping phase.
RTPLAN Data Fidelity for AI Workflow Integration
When an AI planning system generates a treatment plan and exports it as RTPLAN for import into the clinical TPS, the fidelity of the RTPLAN export determines whether the plan can be accepted by the TPS without manual re-entry of beam parameters. This is the critical round-trip requirement: the plan generated by the AI system should be importable into the clinical TPS, computable (dose calculation), and evaluable — without the physicist needing to reconstruct beam parameters from the AI output.
For IMRT plans with static MLC segments, RTPLAN export fidelity is achievable at a high level — beam angles, collimator positions, MLC leaf positions, and monitor units can be encoded in RTPLAN and imported by any DICOM RT-compliant TPS. The practical limitation is that the AI system's dose calculation model may differ from the TPS's dose calculation model (different beam data, different algorithm), which means the dose computed in the TPS after import will differ from the dose the AI system predicted. The physicist must recognize that the imported plan's TPS-calculated dose is the clinically relevant one, and must evaluate it against constraints rather than trusting the AI system's dose prediction.
This is not a DICOM RT problem; it is a dose calculation model problem. But it surfaces in the integration workflow as a source of confusion if it is not addressed in integration documentation and physicist training.
Structure Set Versioning and Plan Modification Tracking
A less-discussed integration challenge involves plan modification tracking. When a physicist imports an AI-generated RTPLAN into the TPS and then modifies beam weights or constraints to improve DVH metrics, the TPS creates a new plan version. The DICOM RT data model does not natively support version history in a structured way — tracking which version of a plan was approved, and which modifications were made by the physicist versus generated by the AI system, depends on the TPS's own version control implementation rather than DICOM RT semantics.
For clinical audit purposes — and increasingly for regulatory software validation purposes — the distinction between AI-generated plan components and physicist modifications is important. An AI planning system that logs its output as a distinct RTPLAN with a specific UID, which the TPS then imports and potentially modifies, provides a clean audit boundary: the AI's RTPLAN is the input; the TPS's approved plan is the output; the diff between them represents physicist judgment applied to the AI's proposal.
Practical Integration Checklist for New Software
For clinical departments evaluating AI planning software or other DICOM RT-based tools, the integration assessment should cover:
- RTSTRUCT import handling: How does the software handle unnamed or mis-typed ROI interpreted type fields? Does it require a mapping table? Is the mapping configurable per-TPS?
- RTPLAN export completeness: Does the exported RTPLAN include all beam parameters needed for direct TPS import, or does it require manual re-entry of any fields?
- Dose model transparency: Is the AI system's internal dose model documented, and are physicians and physicists informed that TPS-calculated dose after import may differ from AI-predicted dose?
- UID chain integrity: Does the software maintain correct DICOM UID references between RTSTRUCT, RTPLAN, and RTDOSE objects throughout the workflow?
- IHE RO conformance: Has the software been tested against the IHE Radiation Oncology technical framework profiles, which define interoperability tests for DICOM RT implementation?
We are not suggesting that DICOM RT compliance is difficult to achieve — every vendor in this space achieves baseline compliance. The question for clinical evaluation is not whether a system exports valid DICOM RT but whether its specific implementation assumptions are compatible with the department's existing TPS, R&V system, and physicist workflow. That compatibility testing belongs in the integration assessment, not as an assumption.
The Long-Term Integration Architecture
The practical reality for most Japanese radiation oncology departments is that DICOM RT integration between an AI planning layer and the clinical TPS will require a defined validation protocol before clinical use — not because the integration is inherently complex, but because clinical use of AI-generated plans requires documentation that the data exchange is reliable and that dose values are correctly represented throughout the workflow. This validation protocol, typically involving phantom measurements and side-by-side comparison of AI-predicted and TPS-calculated DVHs on a reference case set, is the integration work that precedes routine clinical use.
Departments that approach this validation systematically, with documented test cases and acceptance criteria, complete the integration phase with a clear operational protocol and a physicist team that understands the system's behavior at edge cases. Departments that skip the validation phase and move directly to clinical use on complex cases encounter the edge cases without that documentation — which is a suboptimal outcome for everyone involved.