Shared Managament of Radiation Treatments
0.0.1-current - ci-build
Shared Managament of Radiation Treatments
0.0.1-current - ci-build
Shared Managament of Radiation Treatments, published by IHE Radiation Oncology Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/RO.SMRT/ and changes regularly. See the Directory of published versions
In contemporary radiation oncology clinics, a single Radiation Oncology Information System (ROIS) is deployed to manage the electronic medical records (EMR) for all patients. This centralized system is used by radiation oncologists and departmental staff to prescribe, schedule, and track the complete course of treatment for each patient.
For an optimal workflow, all treatment devices should be interfaced with the ROIS to enable scheduling, prescription management, and treatment progress monitoring to be performed directly within that single, centralized system.
While some treatment devices interact with a Treatment Management System (TMS) integrated with the ROIS via the IHE-RO TDW-II profile or any proprietary interface, many others connect exclusively with a device-specific TMS or have an integrated TMS. This is increasingly common with the emergence of treatment devices for novel techniques like Online Adaptive Radiation Therapy (OART), which utilizes imaging such as CBCT, CT, or MRI, and PET-based Dose-Guided Radiation Therapy (DGRT), which often bundle the TMS, Treatment Planning System (TPS), and TDD actors.
These standalone TDDs are frequently disconnected from the departmental ROIS, creating isolated "islands" where treatments must be scheduled and tracked separately. This forces staff to rely on inefficient and error-prone workarounds, such as manual data entry or ad-hoc software bridges. Integrating these devices into the main ROIS is therefore essential to provide the same unified scheduling, review, and tracking capabilities available for the standard treatment device fleet.
The SMRT profile provides the necessary mechanisms for exchanging scheduling, planning, and treatment delivery artifacts to support these scenarios, thereby enabling a holistic and unified view of all ongoing treatments within the ROIS.
This profile is a Workflow and Content Profile.
This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/.
Figure below shows the actors directly involved in the SMRT Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines.
Table XX.1-1: SMRT Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| ROIS | Patient Identity Management [ITI-30] | Initiator | R | ITI TF-2: 3.30 |
| Patient Encounter Management [ITI-31] | Initiator | R | ITI TF-2: 3.31 | |
| Send Patient Photo [RO-SMRT-01] | Initiator | R | RO TF-2: 3.SMRT-01 | |
| Appointment Notification [RAD-48] | Initiator | R | RAD TF-2: 4.48 | |
| Report Planning Artifacts Ready [RO-SMRT-02] | Responder | R | RO TF-2: 3.SMRT-02 | |
| Retrieve Planning Artifacts [RO-SMRT-03] | Initiator | R | RO TF-2: 3.SMRT-03 | |
| Report Deliverable Plan Artifact Ready [RO-SMRT-04] | Responder | R | RO TF-2: 3.SMRT-04 | |
| Retrieve Deliverable Plan Artifact [RO-SMRT-05] | Initiator | R | RO TF-2: 3.SMRT-05 | |
| Report Delivery Artifacts Ready [RO-SMRT-06] | Responder | R | RO TF-2: 3.SMRT-06 | |
| Retrieve Delivery Artifacts [RO-SMRT-07] | Initiator | R | RO TF-2: 3.SMRT-07 | |
| TMS | Patient Identity Management [ITI-30] | Responder | R | ITI TF-2: 3.30 |
| Patient Encounter Management [ITI-31] | Responder | R | ITI TF-2: 3.31 | |
| Send Patient Photo [RO-SMRT-01] | Responder | R | RO TF-2: 3.SMRT-01 | |
| Appointment Notification [RAD-48] | Responder | R | RAD TF-2: 4.48 | |
| Report Planning Artifacts Ready [RO-SMRT-02] | Initiator | R | RO TF-2: 3.SMRT-02 | |
| Report Deliverable Plan Artifact Ready [RO-SMRT-04] | Initiator | R | RO TF-2: 3.SMRT-04 | |
| Report Delivery Artifacts Ready [RO-SMRT-06] | Initiator | R | RO TF-2: 3.SMRT-06 | |
| OST | Retrieve Planning Artifacts [RO-SMRT-03] | Responder | R | RO TF-2: 3.SMRT-03 |
| Retrieve Deliverable Plan Artifact [RO-SMRT-05] | Responder | R | RO TF-2: 3.SMRT-05 | |
| Retrieve Delivery Artifacts [RO-SMRT-07] | Responder | R | RO TF-2: 3.SMRT-07 |
The actors in this profile are described in more detail in the sections below.
Within the context of the SMRT profile, the ROIS serves as the system of record for the radiation therapy treatment workflow. It provides the clinical, scheduling, and administrative information required to coordinate planning and treatment delivery activities, regardless of whether portions of that information originate within the ROIS itself or are received from external systems. Its core responsibilities in this profile include:
Encounter Management: The ROIS maintains clinical and administrative encounter information. An encounter provides the administrative context within a patient's treatment course. It represents an episode of care under which radiation therapy activities are grouped. Within this profile, the encounter conveys key information such as whether the patient is an inpatient or outpatient, the attending physician, and the relevant procedure code. This ensures treatments are properly associated with the correct episode of care for departmental tracking and billing. Encounter information may be created within the ROIS or received from the Hospital Information System (HIS).
Appointment Scheduling: The ROIS creates and manages the appointment schedule for planned treatment fractions.
Clinical Approvals: The ROIS records clinical authorizations to proceed with treatment delivery.
FHIR Capability Statement for ROIS
Within the context of the SMRT profile, the TMS coordinates treatment delivery execution and maintains the information required to prepare, manage, and document the delivery of treatment fractions. Its core responsibilities in this profile include:
Treatment Fraction Management: The TMS maintains the treatment fractions and prepares the corresponding treatment sessions for delivery, including management of interrupted, canceled, and partially delivered fractions.
Treatment Plan Management: The TMS imports, enriches, and maintains the treatment plans required for treatment delivery.
Treatment Delivery Management: The TMS coordinates and monitors treatment delivery activities associated with treatment sessions.
Treatment Delivery Documentation: The TMS maintains treatment delivery records and other treatment delivery artifacts.
FHIR Capability Statement for TMS
No specific descriptions or requirements.
The transactions in this profile are summarized in the sections below.
This profile leverages existing IHE transactions based on HL7 V2 and defines additional transactions using HL7 V2, HL7 FHIR, and DICOM standards.
Standard: HL7 V2
This profile reuses the Patient Identity Management [ITI-30] transaction defined in the Patient Administration Management (PAM) Profile.
For more details see ITI-30
Standard: HL7 V2
This profile reuses the Patient Encounter Management [ITI-31] transaction defined in the Patient Administration Management (PAM) Profile.
For more details see ITI-31
Standard: HL7 V2
This profile reuses the Appointment Notification [RAD-48] transaction defined in the Radiology Scheduled Workflow (SWF) Profile.
For more details see RAD TF-2: 4.48.
Standard: FHIR
This transaction is used by the ROIS to provide the patient's photo to the TMS. The photo supports patient identification and verification activities during treatment delivery. The photo may be conveyed directly within the transaction or by reference for subsequent retrieval.
For more details see the detailed transaction description.
Standard: FHIR
This transaction is used by the TMS to notify the ROIS that treatment planning artifacts are available for retrieval from the OST. Treatment planning artifacts represent information produced during treatment planning and include at least the treatment plan, structure sets, reference images, and dose information. The notification enables the ROIS to retrieve the artifacts required to maintain the treatment workflow record and support treatment progress tracking.
For more details see the detailed transaction description.
Standard: DICOM
This transaction is used by the ROIS to retrieve treatment planning artifacts from the OST.
For more details see the detailed transaction description.
Standard: FHIR
This transaction is used by the TMS to notify the ROIS that the deliverable plan artifact is available for retrieval from the OST. The deliverable plan artifact is the treatment plan enriched with treatment delivery parameters, such as patient setup information and tolerance tables. The notification enables the ROIS to retrieve the artifact required to maintain the treatment workflow record and support treatment progress tracking.
For more details see the detailed transaction description.
Standard: DICOM
This transaction is used by the ROIS to retrieve the deliverable plan artifact from the OST.
For more details see the detailed transaction description.
Standard: FHIR
This transaction is used by the TMS to notify the ROIS that treatment delivery artifacts are available for retrieval from the OST. Treatment delivery artifacts represent information produced during the treatment session and include at least the treatment record and procedure information. The notification enables the ROIS to retrieve the artifacts required to maintain the treatment workflow record and support treatment progress tracking.
For more details see the detailed RO-SMRT-06.html.
Standard: DICOM
This transaction is used by the ROIS to retrieve treatment delivery artifacts from the OST.
For more details see the detailed RO-SMRT-07.html.
Options that may be selected for each actor in this implementation guide, are listed in Table XX.2-1 below. Dependencies between options when applicable are specified in notes.
Table XX.2-1: Actor Options
| Actor | Option Name |
|---|---|
| Actor A | Option AB |
| Actor B | none |
**TODO: describe this option and the Volume 1 requirements for this option
Describe any requirements for actors in this profile to be grouped with other actors.
This section specifies all REQUIRED Actor Groupings (although "required" sometimes allows for a selection of one of several). To SUGGEST other profile groupings or helpful references for other profiles to consider, use Section XX.6 Cross Profile Considerations. Use Section X.5 for security profile recommendations.
An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2) (Column 3 in alternative 2).
If this is a content profile, and actors from this profile are grouped with actors from a workflow or transport profile, the Reference column references any specifications for mapping data from the content module into data elements from the workflow or transport transactions.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; this is designated by merging column one into a single cell spanning multiple potential grouped actors. Notes are used to highlight this situation.
Section XX.5 describes some optional groupings that may be of interest for security considerations and Section XX.6 describes some optional groupings in other related profiles.
Two alternatives for Table XX.3-1 are presented below.
alternative 1 Table XX.3-1: Profile Name - Required Actor Groupings
All actors from this profile should be listed in Column 1, even if none of the actors has a required groupings. If no required grouping exists, "None" should be indicated in Column 2. If an actor in a content profile is required to be grouped with an actor in a transport or workflow profile, it will be listed with at least one required grouping. Do not use "XD*" as an actor name.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; to designate this, create a row for each potential actor grouping and merge column one to form a single cell containing the profile actor which should be grouped with at least one of the actors in the spanned rows. In addition, a note should be included to explain the enumerated set. See example below showing Document Consumer needing to be grouped with at least one of XDS.b Document Consumer, XDR Document Recipient or XDM Portable Media Importer
The author should pay special consideration to security profiles in this grouping section. Consideration should be given to Consistent Time (CT) Client, ATNA Secure Node or Secure Application, as well as other profiles. For the sake of clarity and completeness, even if this table begins to become long, a line should be added for each actor for each of the required grouping for security. Also see the ITI document titled 'Cookbook: Preparing the IHE Profile Security Section' at http://ihe.net/Technical_Frameworks/#IT for a list of suggested IT and security groupings.
Table XX.3-1: Actor Groupings
| this Profile Acronym Actor | Actor(s) to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Actor A | external Domain Acronym or blank profile acronym/Actor e.g., ITI CT / Time Client |
TF Reference; typically from Vol 1 e.g., ITI-TF-1: 7.1 |
-- |
| Actor B | None | -- | -- |
Actor C In this example, Actor C shall be grouped with all three actors listed in column 2 |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 |
| external Domain Acronym or blank profile acronym/Actor | -- | See Note 1 | |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 | |
Actor D (See note 1) In this example, the note is used to indicate that the Actor D shall be grouped with one or more of the two actors of the two actors in column 2. |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 | |
Actor E In rare cases, the actor to be grouped with must implement an option. An example is in column 2.) |
external Domain Acronym or blank profile acronym Actor e.g., ITI RFD Form Filler with the Archive Form Option |
TF Reference to the Option definition; typically from Vol 1 (e.g., ITI TF-1: 17.3.11) |
|
| e.g., Content Consumer (See Note 1) | ITI XDS.b / Document Consumer | ITI TF-1: 10.1 | PCC TF-2:4.1 (See Note 2) |
| ITI XDR / Document Recipient | ITI TF-1: 15.1 | PCC TF-2:4.1 (See Note 2) | |
| ITI XDM / Portable Media Importer | ITI TF-1: 16.1 | PCC TF-2:4.1 (See Note 2) | |
| e.g., Content Consumer | ITI CT / Time Client | ITI TF-1: 7.1 | -- |
Note 1: This is a short note. It may be used to describe situations where an actor from this profile may be grouped with one of several other profiles/actors.
Note 2: A note could also be used to explain why the grouping is required, if that is still not clear from the text above.
alternative 2 Table XX.3-1: this Profile Acronym Profile
All actors from this profile should be listed in Column 1. If no required grouping exists, "None" should be indicated in Column 3.
Guidance on using the "Grouping Condition" column:
Table XX.3-1: Actor Groupings
| this Profile Acronym Actor | Grouping Condition | Actor(s) to be grouped with | Reference |
| Actor A | -- | None | -- |
| Actor B | Required | external Domain Acronym or blank profile acronym/Actor e.g., ITI CT / Time Client |
TF Reference; typically from Vol 1 (e.g., ITI TF-1: 7.1) |
| Actor C | With the Option name in this profile Option | external Domain Acronym or blank profile acronym/Actor | Where the Option is defined in this profile Section XX.3 z |
Actor D if an actor has both required and conditional groupings, list the Required grouping first |
Required | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 |
| If the Option name in this profile Option is supported. | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 | |
| If the other Option name in this profile Option is supported. | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 | |
Actor E (In rare cases, the actor to be grouped with must implement an option, an example is in column 3) |
Required | external Domain Acronym or blank profile acronym/Actor with the option name e.g. ITI RFD Form Filler with the Archive Form Option |
TF Reference to the Option definition; typically from Vol 1 (eg ITI TF-1:17.3.11) |
The Shared Managament of Radiation Treatments (SMRT) Profile [pronounced 'smart'] defines the transactions and content specifications necessary to connect any device-specific Treatment Management System (TMS) with a single departmental Radiation Oncology Information System (ROIS).
The SMRT profile operates within the broader context of a radiation oncology treatment center. It is expected that the Radiation Oncology Information System (ROIS) functions as the central management platform for oncology workflows, but it may rely on other systems such as a Hospital Information System (HIS) or a Radiology Information System (RIS) when the department is integrated within a hospital.
This use case describes how clinical staff can use a single departmental Radiation Oncology Information System (ROIS) to schedule, review, and track the treatment progress of a therapy session conducted on a standalone treatment device.
to establish a clinically acceptable integration workflow between a standalone treatment device and a departmental ROIS. This baseline workflow focuses on the exchange of patient demographics, scheduling, and treatment-related artifacts. More advanced interactions, such as the direct exchange of prescription information, are considered optional extensions.
The formal behavioral requirements and core responsibilities for the ROIS and TMS actors are detailed in Section XX.1.1.1 and Section XX.1.1.2 respectively. In this use case, the departmental ROIS manages the overall patient clinical journey, while the specialized TMS manages treatment planning and delivery, feeding status updates and treatment-related artifacts back to the ROIS to maintain a centralized patient record.
The process flow for this use case is initiated by the departmental ROIS, which is the central point of management for the patient's entire treatment journey. Patient Registration:
Treatment Planning:
Treatment Approval:
Treatment Delivery:
One or two sentence simple description of this particular use case.
Note that Section XX.4.2.1 repeats in its entirety for additional use cases (replicate as Section XX.4.2.2, XX.4.2.3, etc.).
Describe the key use cases addressed by the profile. Limit to a maximum of one page of text or consider an appendix.
Diagram and describe the process flow(s) covered by this profile in order to satisfy the use cases. Demonstrate how the profile transactions are combined/sequenced. To provide context and demonstrate how the profile interacts with other profiles, feel free to include transactions and events that are "external" to this profile (using appropriate notation.)
The set of process flows will typically be exemplary, not exhaustive (i.e., it will address all the use cases, but will not show all possible combinations of actors, or all possible sequencing of transactions).
If there are detailed behavioral rules that apply to a specific process flow or multiple process flows, an appendix may be added as needed.
The roles at the top of the swimlane diagram should correspond to actor names, include the profile acronym:actor name if referencing an actor from a different profile.
Modify the following "Swimlane Diagram". You can use plantuml or mermaid. see details on using mermaid in the IG publisher. Mermaid user guide online. Plantuml seems more stable, and does support clickable links on artifacts. Goto plantuml.com for an online tool to draft plantuml files.
If process flow "swimlane" diagrams require additional explanation to clarify conditional flows, or flow variations need to be described where alternate systems may be playing different actor roles, document those conditional flows here.
Delete the material below if this is a workflow or transport profile. Delete the material above if this profile is a content module only profile.
Pre-conditions:
Very briefly (typically one sentence) describe the conditions or timing when this content module would be used.
Main Flow:
Typically in an enumerated list, describe the clinical workflow when, where, and how this content module would be used.
Post-conditions:
Very briefly (typically one sentence) describe the state of the clinical scenario after this content module has been created including examples of potential next steps.
See ITI TF-2x: Appendix Z.8 "Mobile Security Considerations"
The following is instructions to the editor and this text is not to be included in a publication. The material initially from RFC 3552 "Security Considerations Guidelines" July 2003.
This section should address downstream design considerations, specifically for: Privacy, Security, and Safety. These might need to be individual header sections if they are significant or need to be referenced.
The editor needs to understand Security and Privacy fundamentals. General Security and Privacy guidance is provided in the FHIR Specification. The FHIR core specification should be leveraged where possible to inform the reader of your specification.
IHE FHIR based profiles should reference the ITI Appendix Z section 8 Mobile Security and Privacy Considerations base when appropriate.
IHE Document Content profiles can reference the security and privacy provided by the Document Sharing infrastructure as directly grouped or possibly to be grouped.
While it is not a requirement that any given specification or system be immune to all forms of attack, it is still necessary for authors of specifications to consider as many forms as possible. Part of the purpose of the Security and Privacy Considerations section is to explain what attacks have been considered and what countermeasures can be applied to defend against them.
There should be a clear description of the kinds of threats on the described specification. This should be approached as an effort to perform "due diligence" in describing all known or foreseeable risks and threats to potential implementers and users.
Authors MUST describe:
what could be done in system design, system deployment, or user training
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the specification incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled.
If the specification involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified. That is, authors MUST document the assumptions that the security of this authentication method is predicated upon.
The threat environment addressed by the Security and Privacy Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat environment. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document.
There should be a clear description of the residual risk to the user or operator of that specification after threat mitigation has been deployed. Such risks might arise from compromise in a related specification (e.g., IPsec is useless if key management has been compromised), from incorrect implementation, compromise of the security technology used for risk reduction (e.g., a cipher with a 40-bit key), or there might be risks that are not addressed by the specification (e.g., denial of service attacks on an underlying link protocol). Particular care should be taken in situations where the compromise of a single system would compromise an entire protocol. For instance, in general specification designers assume that end-systems are inviolate and don't worry about physical attack. However, in cases (such as a certificate authority) where compromise of a single system could lead to widespread compromises, it is appropriate to consider systems and physical security as well.
There should also be some discussion of potential security risks arising from potential misapplications of the specification or technology described in the specification.
This section also include specific considerations regarding Digital Signatures, Provenance, Audit Logging, and De-Identification.
Where audit logging is specified, a StructureDefinition profile(s) should be included, and Examples of those logs might be included.
This section is informative, not normative. It is intended to put this profile in context with other profiles. Any required groupings should have already been described above. Brief descriptions can go directly into this section; lengthy descriptions should go into an appendix. Examples of this material include ITI Cross Community Access (XCA) Grouping Rules (Section 18.2.3), the Radiology associated profiles listed at wiki.ihe.net, or ITI Volume 1 Appendix E "Cross Profile Considerations", and the "See Also" sections Radiology Profile descriptions on the wiki such as http://wiki.ihe.net/index.php/Scheduled_Workflow#See_Also. If this section is left blank, add "Not applicable."
Consider using a format such as the following:
other profile acronym - other profile name
A other profile actor name in other profile name might be grouped with a this profile actor name to describe benefit/what is accomplished by grouping.
IG © 2025+ IHE Radiation Oncology Technical Committee. Package ihe.ro.smrt#0.0.1-current based on FHIR 4.0.1. Generated 2026-08-27
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change