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

## 1:XX Shared Management of Radiation Therapy (SMRT) Volume 1

The Shared Managament of Radiation Therapy (SMRT) Profile defines the workflow and content necessary to connect any machine-integrated Treatment Planning and Management System (TPMS) with a departmental Radiation Oncology Information System (ROIS).

There is a need to be able to incorporate “island” treatment devices into a larger, departmental Radiation Oncology Information System (ROIS). Such "island" treatment devices often come with their local TPMS fully tailored to the capabilities of that treatment device. The Oncology department needs to be able to schedule, review and track treatment progress for these devices as they do for the other standard treatment devices of their treatment device fleet.

This profile provides the mechanisms to exchange the required treatment planning and treatment delivery artefcats to support beforementioned scenarios and to allow a holistioc view of the on-going treatments in the ROIS.

**TODO: Explicitly state whether this is a Workflow, Transport, or Content Module (or combination) profile. See the IHE Technical Frameworks General Introduction for definitions of these profile types. The IHE Technical Frameworks General Introduction. **

## 1:X.1 SMRT Actors, Transactions, and Content Modules

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.

Figure XX.1-2: SMRT Actor Diagram

Table XX.1-1: SMRT Profile - Actors and Transactions

Actors | Transactions | Initiator or Responder | Optionality | Reference
--- | --- | --- | --- | ---
ROIS | RO-SMRT-01 Query Treatment Strategy | Responder | R (Note 1) | ​Domain Acronym TF-2: 3.Y1
| RO-SMRT-02 Query Diagnosis | Responder | R | ​Domain Acronym TF-2: 3.Y2
TMS | RO-SMRT-01 Query Treatment Strategy | Initiator | R | ​Domain Acronym TF-2: 3.Y1
| RO-SMRT-02 Query Diagnosis | Initiator | R | ​Domain Acronym TF-2: 3.Y2

Note 1: For example, a note could specify that at least one of the transactions shall be supported by an actor or other variations. For example: Note: Either Transaction Y3 or Transaction Y4 shall be implemented for Actor E.

Note 2: For example, could specify that Transaction Y4 is required if Actor B supports XYZ Option, see Section XX.3.X.

### XX.1.1 Actors

The actors in this profile are described in more detail in the sections below.

#### XX.1.1.1 Radiation Oncology Information System (ROIS)

The Client queries for blah meeting certain criteria and may retrieve selected blah.

​FHIR Capability Statement for ROIS

#### XX.1.1.2 Treatment Management System (TMS)

The Sever processes query request from the Client actor.

​FHIR Capability Statement for TMS

#### XX.1.1.3 Radiation Oncology Resource Repository (REPO)

The Client queries for blah meeting certain criteria and may retrieve selected blah.

​FHIR Capability Statement for REPO

### XX.1.2 Transaction Descriptions

The transactions in this profile are summarized in the sections below.

#### XX.1.2.1 Query Treatment Strategy ToDo do transaction

This transaction is used to do things

For more details see the detailed transaction description

## XX.2 SMRT Actor Options

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

### XX.2.1 AB Option

**TODO: describe this option and the Volume 1 requirements for this option

## XX.3 SMRT Required Actor Groupings

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.

- If there are no required groupings for any actor in this profile, use alternative 1 as a template.
- If an actor in this profile (with no option), has a required grouping, use alternative 1.
- If any required grouping is associated with an actor/option combination in this profile, use alternative 2.

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

- Required Actor Groupings

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:

- If an actor has no required grouping, Column 2 should contain "–". See Actor A below.
- If an actor has a required grouping that is not associated with a profile option (i.e., it has no condition), column 2 should contain "Required". See Actor B below.
- Sometimes an option requires that an actor in this profile be grouped with an actor in another profile. That condition is specified in Column 2. See Actor C below.

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)

## XX.4 ToDo Overview

This section shows how the transactions/content modules of the profile are combined to address the use cases.

Use cases are informative, not normative, and "SHALL" language is not allowed in use cases.

### XX.4.1 Concepts

If needed, this section provides an overview of the concepts that provide necessary background for understanding the profile. If not needed, state "Not applicable." For an example of why/how this section may be needed, please see ITI Cross Enterprise Workflow (XDW).

It may be useful in this section but is not necessary, to provide a short list of the use cases described below and explain why they are different.

### XX.4.2 Use Cases

#### XX.4.2.1 Use Case #1: Regular Treatment

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.).

##### XX.4.2.1.1 simple name Use Case Description

Describe the key use cases addressed by the profile. Limit to a maximum of one page of text or consider an appendix.

##### XX.4.2.1.2 simple name Process Flow

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.

XX.4.2.2-1: Basic Process Flow in SMRT Profile

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.

## XX.5 ToDo Security Considerations

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:

- which attacks have been considered and addressed in the specification
- which attacks have been considered but not addressed in the specification

- 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.

## XX.6 ToDo Cross-Profile Considerations

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.