planning:instructions_for_use:instructions_for_use
Differences
This shows you the differences between two versions of the page.
planning:instructions_for_use:instructions_for_use [2017/08/17 19:50] – [Release Version Compatibility] kerhart | planning:instructions_for_use:instructions_for_use [2021/07/29 18:23] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== Overview and Indications for Use ===== | ===== Overview and Indications for Use ===== | ||
- | The Astroid Planning App is an interactive end user application | + | The Astroid Planning App is an interactive end user application |
Furthermore, | Furthermore, | ||
Line 11: | Line 11: | ||
It is the user's responsibility to commission and test the dose accuracy prior to patient treatment. This general liability on the end users should be understood and communicated to all users and a representative with signatory authority from each facility using Astroid must sign a //User Agreement// stating their understanding and acceptance of this responsibility. | It is the user's responsibility to commission and test the dose accuracy prior to patient treatment. This general liability on the end users should be understood and communicated to all users and a representative with signatory authority from each facility using Astroid must sign a //User Agreement// stating their understanding and acceptance of this responsibility. | ||
- | Additionally, | + | Additionally, |
===== Clinical Safety ===== | ===== Clinical Safety ===== | ||
Line 51: | Line 51: | ||
==== System Availability and Data Integrity ==== | ==== System Availability and Data Integrity ==== | ||
- | As with any cloud based application there is always concern with system availability and uptime. Astroid makes use of caching at various system levels to improve performance and mitigate some of these concerns, however, this can never provide 100% assurance and reliability. Since customer has unique needs, specific business agreements will be entered into with each customer as appropriate to detail the reliability guarantees and assurances. Data integrity is generally a less variable concern, as Astroid' | + | As with any cloud based application there is always concern with system availability and uptime. Astroid makes use of caching at various system levels to improve performance and mitigate some of these concerns, however, this can never provide 100% assurance and reliability. Since customer has unique needs, specific business agreements will be entered into with each customer as appropriate to detail the reliability guarantees and assurances. Data integrity is generally a less variable concern, as Astroid' |
Since data integrity is such a critical feature for application such as this, the Astroid Planning App automatically saves both the state of the application and the working record data on a timer (triggering every minute or less) as well as on exit of any create or edit event in the application. Additionally, | Since data integrity is such a critical feature for application such as this, the Astroid Planning App automatically saves both the state of the application and the working record data on a timer (triggering every minute or less) as well as on exit of any create or edit event in the application. Additionally, | ||
Line 59: | Line 59: | ||
The following is a list of several important items that users should understand in regards to the information displays in the Astroid Planning Application: | The following is a list of several important items that users should understand in regards to the information displays in the Astroid Planning Application: | ||
- | * The Astroid Planning exclusively uses IEC 61217 coordinate systems for display information (machine based coordinates are NOT available) | + | * The Astroid Planning exclusively uses DICOM coordinate systems for display information (machine based coordinates are NOT available) |
* All linear dimensions are shown in millimeters (mm) | * All linear dimensions are shown in millimeters (mm) | ||
* All angular dimensions are shown in degrees (deg) | * All angular dimensions are shown in degrees (deg) | ||
Line 66: | Line 66: | ||
* All date and time notifications in Astroid should match current Windows OS date and time, including proper use of daylight savings time where appropriate (note: Astroid will display in 24 hour format, while Windows may display in am/pm depending on local settings) | * All date and time notifications in Astroid should match current Windows OS date and time, including proper use of daylight savings time where appropriate (note: Astroid will display in 24 hour format, while Windows may display in am/pm depending on local settings) | ||
+ | ==== Data Validation and Limits ==== | ||
+ | |||
+ | Users are responsible for inputting a lot of data into the Astroid Planning App to develop clinical treatment plans. In the course of entering such data, there are opportunities for users to enter incorrect information. Although users are responsible for checking for such errors before clinical treatment, Astroid does provide some assistance in ensuring data limitations are met by a plan. Machine energy (range) limits, gantry angles, patient support (couch) angles, snout extensions, as well as shifter and aperture sizes and availability are all explicitly limited to user configured levels within the Astroid Planning App controls. Additionally, | ||
==== Data Displays and Interpretation ==== | ==== Data Displays and Interpretation ==== | ||
Line 101: | Line 104: | ||
By using the astroid Launcher, users can log in to multiple realms with each realm using a different app version. This allows for scenarios of using non-clinical or research application versions from the same user account or workstation without the overhead of managing multiple installations. By logging into a realm, the user is required to use the installed client version for that realm. | By using the astroid Launcher, users can log in to multiple realms with each realm using a different app version. This allows for scenarios of using non-clinical or research application versions from the same user account or workstation without the overhead of managing multiple installations. By logging into a realm, the user is required to use the installed client version for that realm. | ||
+ | |||
+ | Details regarding the specific requirements for computers on which the Launcher and Planning App client applications will be installed can be found on the [[planning: | ||
=== Releasing a new App Version === | === Releasing a new App Version === | ||
Line 121: | Line 126: | ||
For the release notes for each version of the Planning Application, | For the release notes for each version of the Planning Application, | ||
+ | |||
+ | === DICOM Receiver === | ||
+ | |||
+ | Your site may have been provided with a DICOM receiver accessory package along with the astroid Planning App. This package may also require updating when installing new versions of the Planning App. The Planning App release notes will describe the necessity for such changes between versions and will also provide download links for obtaining the latest DICOM package software files. The DICOM receiver application includes a configuration file (receiver_config.json) that controls several important parameters for the DICOM receiver: | ||
+ | * local_ae_title: | ||
+ | * local_port: <local network communication port for this ae title> | ||
+ | * timeout: <max time allowed between files to consider them as a batch> | ||
+ | * storage_root_path: | ||
+ | * thinknode: | ||
+ | * user_token: <user access token from the DICOM upload account for your site> | ||
+ | * api_url: <full thinknode url for your site account> | ||
+ | * apps: <list of apps to get contexts for, must include: dosimetry, planning, and dicom> | ||
+ | * realm_name: <realm to which the DICOM data should be uploaded> | ||
+ | * account_name: | ||
==== Release Version Compatibility ==== | ==== Release Version Compatibility ==== | ||
Line 135: | Line 154: | ||
- Install the release candidate app version into a test realm that is using the copied bucket. | - Install the release candidate app version into a test realm that is using the copied bucket. | ||
- Review the release notes for the new version and ensure you understand the changes. | - Review the release notes for the new version and ensure you understand the changes. | ||
- | - Check the release notes to determine if accessory applications may be impacted by the changes (e.g. DICOM receivers, report scripts) | + | - Check the release notes to determine if accessory applications may be impacted by the changes (e.g. DICOM receivers, report scripts) |
- Login to the launcher and select the new test realm. Ensure the new app version is able to be installed and launched. | - Login to the launcher and select the new test realm. Ensure the new app version is able to be installed and launched. | ||
- Open existing patients in the test realm. You should ensure each of the following for the existing patients and plans in the test realm: | - Open existing patients in the test realm. You should ensure each of the following for the existing patients and plans in the test realm: | ||
Line 150: | Line 169: | ||
==== Realm Data Duplication or Backup ==== | ==== Realm Data Duplication or Backup ==== | ||
- | Data from within in a realm can be duplicated or backed up by manually copying the realm' | + | Data from within in a realm can be duplicated or backed up by manually copying the realm' |
If your user has the required thinknode permissions to read and manage buckets then you can backup data by running the[[https:// | If your user has the required thinknode permissions to read and manage buckets then you can backup data by running the[[https:// | ||
Line 158: | Line 177: | ||
The following page describes the hierarchy of data used to manage patient data records within the Astroid planning environment. | The following page describes the hierarchy of data used to manage patient data records within the Astroid planning environment. | ||
- | ===== Hierarchy | + | ==== Hierarchy ==== |
* __**Patient**__ | * __**Patient**__ | ||
Line 187: | Line 206: | ||
* Constraints | * Constraints | ||
* Objectives | * Objectives | ||
+ | * Optional Fluence Override | ||
* Dose Results | * Dose Results | ||
Line 194: | Line 214: | ||
*/ | */ | ||
- | ===== Descriptions | + | ==== Descriptions ==== |
* **__Patient__**: | * **__Patient__**: | ||
Line 210: | Line 230: | ||
* A specific model of a target, OAR, or other structure. A physician may provide an initial target contour and a treatment plan generated using this information. The physician may later (using the same CT image set) provide a revised target contour. Rather than import this revision as a new structure or override the original, you may specify this new contour as a variant of the original. Each contour may have only a single " | * A specific model of a target, OAR, or other structure. A physician may provide an initial target contour and a treatment plan generated using this information. The physician may later (using the same CT image set) provide a revised target contour. Rather than import this revision as a new structure or override the original, you may specify this new contour as a variant of the original. Each contour may have only a single " | ||
* **__Plan__**: | * **__Plan__**: | ||
- | * A detailed model of a proton therapy treatment. Most aspects of the patient planning information are stored here (e.g. Beams, Fraction Groups, Optimization Information, | + | * A detailed model of a proton therapy treatment. Most aspects of the patient planning information are stored here (e.g. Beams, Fraction Groups, Optimization Information, |
+ | ==== Structures in the Data Model ==== | ||
- | ---- | + | There are multiple levels that various structures can live at. Each level and structure type will effect how the structure will relate to the plan. Refer to the [[planning: |
- | <WRAP center 10%>// | + | |
- | <WRAP center | + | |
+ | ---- | ||
+ | <WRAP center | ||
planning/instructions_for_use/instructions_for_use.1502999448.txt.gz · Last modified: 2021/07/29 18:22 (external edit)