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 [2016/05/25 02:47] – [Descriptions] kerhart | planning:instructions_for_use:instructions_for_use [2021/07/29 18:23] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Astroid Patient Data Model ====== | + | ====== Planning App Instructions for Use ====== |
+ | |||
+ | ===== Overview and Indications for Use ===== | ||
+ | |||
+ | The Astroid Planning App is an interactive end user application for proton treatment planning for the intended use and primary purpose of enabling radiotherapy professionals to efficiently design and analyze proton radiotherapy treatment plans. This Astroid Planning App leverages the existing .decimal Astroid Dosimetry App [FDA 510(k) K150547], which is a library of treatment planning functions accessed through the Thinknode® cloud services framework, for device creation, dose calculation, | ||
+ | |||
+ | Furthermore, | ||
+ | |||
+ | ===== User Responsibilities ===== | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ===== Clinical Safety ===== | ||
+ | |||
+ | It is the responsibility that the user performs end-to-end testing prior to the clinical implementation of Astroid. The user should follow accepted industry guideline (such as AAPM TG244) for the end-to-end testing. This testing should be performed by qualified personnel. | ||
+ | |||
+ | It is the responsibility of the facility to ensure that all users of the Astroid treatment planning system have had training on the Astroid product and possess the appropriate clinical education, experience, and (where applicable) licensure to develop clinical treatment plans. This includes, but is not limited to, the application training provided by Astroid staff. | ||
+ | |||
+ | It is recommended that users follow acceptable global standards during the commissioning of the Astroid product. During the clinical set up, the following should be tested to ensure clinical safety prior to treatment: | ||
+ | - Geometric relationships of the hardware machine models | ||
+ | - The dose algorithm | ||
+ | - Data access and storage | ||
+ | - Accuracy of the planning dose systems. | ||
+ | |||
+ | ==== Warning ==== | ||
+ | |||
+ | It is critical that all users read these Instructions for Use and the User Guide material carefully and completely and consult the provided User Guides and other training materials to ensure proper use of the application and proper interpretation of results. | ||
+ | |||
+ | <WRAP center round important 60%> | ||
+ | Prior to the delivery of any plan on a patient, users are responsible for performing patient specific QA to ensure clinical acceptability of the delivered dose distribution. Since users are responsible for testing the acceptability of the delivered dose before treatment, Astroid, its staff, and representatives shall not be liable for any mis-treatments that may result from use of the system. | ||
+ | </ | ||
+ | |||
+ | <wrap em> | ||
+ | |||
+ | ===== Intended Use ===== | ||
+ | |||
+ | The Astroid Planning App is an interactive end user application that leverages the existing .decimal Astroid Dosimetry App library [FDA 510(k) K150547] of functions (accessed through the Thinknode® cloud services framework) for device creation, dose calculation, | ||
+ | |||
+ | ===== User Profile ===== | ||
+ | |||
+ | The Astroid Planning App is a tool to develop radiotherapy treatment plans for delivery using a proton therapy system. Such plans are generally developed to meet the directives of a physician through a formal documented prescription. As such, the users of this application are expected to be supervised by an attending physician and should themselves be experienced in the physics and dosimetric characteristics of proton radiotherapy. Additionally, | ||
+ | |||
+ | ===== Product Features ===== | ||
+ | |||
+ | In the most common, primary use case of the software, users will import patient data from existing imaging and contouring software programs, manage physician prescription and intent information, | ||
+ | The Astroid Planning App software communicates with other treatment planning systems generally by sending & receiving files in various DICOM RT formats, although the extensive Application Programming Interface (API) of Thinknode® allows users to easily build their own export and import conversion applications. Since the accuracy of information computed and displayed by an application such as this is very important to the proper treatment of patients, it is critical that users have the appropriate educational and clinical experience backgrounds to adequately understand and use the product. Additionally, | ||
+ | |||
+ | |||
+ | ==== 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' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ==== Coordinates and Units of Measure ==== | ||
+ | |||
+ | 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 DICOM coordinate systems for display information (machine based coordinates are NOT available) | ||
+ | * All linear dimensions are shown in millimeters (mm) | ||
+ | * All angular dimensions are shown in degrees (deg) | ||
+ | * All radiation dose quantities will be shown with their corresponding units within the application (e.g. Gy(RBE) or %) | ||
+ | * All date/time values are provided in a // dd/mm/yyyy h:m:s // format using local time on a 24 hour clock | ||
+ | * 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 ==== | ||
+ | |||
+ | Astroid contains many displays throughout the plan creation process. Please refer to [[http:// | ||
+ | |||
+ | ==== Unauthorized Use ==== | ||
+ | |||
+ | The Astroid Planning Application will contain sensitive patient information that is protected under various governmental regulations, | ||
+ | |||
+ | ==== Access Control ==== | ||
+ | |||
+ | Astroid (Thinknode) administrators have the ability to manage user access, passwords, and " | ||
+ | |||
+ | As Astroid is a cloud based application the site administrator will be responsible for the installation of Astroid on to the appropriate workstations. Each user should have an individual log in and password to access the planning app that prevents unauthorized access. Best practices should be followed. | ||
+ | |||
+ | For further information on access management and permission settings please refer to [[https:// | ||
+ | |||
+ | ==== Known Limitations ==== | ||
+ | |||
+ | For a list of known system issues and limitations please refer to the following articles for the Planning App and Dosimetry App, respectively. | ||
+ | |||
+ | [[planning: | ||
+ | |||
+ | [[dosimetry: | ||
+ | |||
+ | |||
+ | ==== Release Management (Launcher) ==== | ||
+ | |||
+ | The astroid Planning App is installed and launched from the astroid Launcher. The Launcher program provides the following functionality in regards to the Planning App: | ||
+ | - Ensures that all users at a site are using the same version of the application | ||
+ | - Ensures that the local Planning App client stays in sync with the latest release version (as set via Thinknode) | ||
+ | - Provides user authentication and password management | ||
+ | |||
+ | When an application update is available via the astroid Launcher, the users will be required to install the App in the Launcher. This is accomplished by selecting the //Install// button for the specific app. Within a few minutes, the app should be downloaded and installed locally for the current user account. The user will then be able to launch the released app version from the astroid Launcher. | ||
+ | |||
+ | 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 === | ||
+ | |||
+ | In order to " | ||
+ | * **< | ||
+ | * **< | ||
+ | * References Immutable: < | ||
+ | " | ||
+ | " | ||
+ | } </ | ||
+ | * **< | ||
+ | * **< | ||
+ | * **< | ||
+ | |||
+ | For the launcher to register that an application should be installed for a realm, the //client// app with the // | ||
+ | |||
+ | For Example: from the above RKS hierarchy example, the application client named // | ||
+ | |||
+ | === Release Notes === | ||
+ | |||
+ | 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 ==== | ||
+ | |||
+ | The astroid Planning App is tested for version compatibility by .decimal prior to release to customers. However, it is still important for each site to independently test and verify the data integrity of each version prior to release at the site. Specifically, | ||
+ | * Adding manual and automatic data upgrades, as appropriate, | ||
+ | * Performing a Thinknode [[https:// | ||
+ | * Test the final dose calculations of matching patients between the two app versions to ensure the final doses exactly match (unless the dosimetry app has been otherwise indicated as changed). | ||
+ | |||
+ | Prior to releasing a new app version into a realm, it is imperative to ensure that the data is compatible between the existing version installed in the realm and the new version that is intended to be installed. | ||
+ | |||
+ | The following procedure shall be followed in order to safely release new versions of an application: | ||
+ | - For the realm being upgraded [[planning: | ||
+ | - 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. | ||
+ | - Check the release notes to determine if accessory applications may be impacted by the changes (e.g. DICOM receivers, report scripts) and complete any necessary steps to update or configure these items to work with the new test realm. | ||
+ | - 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: | ||
+ | - The patients and plans all open without errors. | ||
+ | - The final optimized dose result is the same as the previous version. Note: because a new version is released, the optimizer may rerun. But the result should be the same (Thinknode Immutable IDs may be used to confirm the exact matching of results). | ||
+ | - Perform any testing deemed appropriate in regards to the changes outlined in the release notes and required by regulatory guidelines for treatment planning system upgrades. | ||
+ | - Once the release candidate has been thoroughly tested and is ready for release, notify all users at your site of the pending release and set an appropriate date and time for the release (it is generally good practice to stop all active clinical use during the upgrade so choose a time outside of normal clinical operating hours). At the designated date/ | ||
+ | - Using the Thinknode Client: | ||
+ | - Navigate to the Admin -> Realms page. | ||
+ | - Uninstall the existing astroid app versions and install the new app versions. | ||
+ | - Login to the launcher and select the clinical realm. Ensure the new app version is able to be installed and launched. | ||
+ | - Open a patient plan and ensure it loads without error. | ||
+ | - Perform any other transfer testing necessary to ensure safe clinical release. | ||
+ | ==== Realm Data Duplication or Backup ==== | ||
+ | |||
+ | 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:// | ||
+ | |||
+ | ===== Astroid Patient Data Model ===== | ||
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 | + | |
- | * Course [0, | + | * __**Course**__ |
- | | + | * Prescriptions & Clinical Goals |
- | | + | * Directive Structure List |
- | | + | * __**Patient Model**__ |
- | * Directive [0, | + | * Imaging Data |
- | | + | * Structure Data |
- | * Clinical Goals data stuff here FIXME | + | * Active Variant |
- | * Phase | + | * Variant List |
- | | + | * __**Plans**__ |
- | | + | * RSP Data |
- | | + | * Structures |
- | | + | * Calculation Grid |
- | * Snapshot [0, | + | * Treatment Room |
- | | + | * Beams |
- | * Structure Data [0,1,...,N] | + | * Snout |
- | * Active Variant | + | * Devices & Spot Options |
- | * The user has the ability to modify a DICOM structure in the contouring software, keeping the same original name, and bring it into ASTROID. This new structure will be a variant of the original structure. It will be given a label a, b, c, etc depending on the number of modifications.The user may also choose to give it a new color to distinguish from a previous variable. | + | * DRRs |
- | * The user has the ability to choose which variation they want to calculate to or they may choose a variant to visualize; such as in the case of a tumor shrinkage- i.e. the original tumor and tumor (variant a) is the tumor after " | + | * Fraction Groups |
- | | + | * Target |
- | | + | * Constraint |
- | | + | * Targets (1 or more) |
- | | + | * Constraint |
- | | + | * Beamset |
- | * Points [0,1,...,N] | + | * Beams (1 or more) |
- | * Structures | + | * Constraints |
- | * Calculation Grid | + | * Objectives |
- | * Treatment Room | + | * Optional Fluence Override |
- | * Beams [1,...,N] | + | * Dose Results |
- | * Snout | + | |
- | * Devices & Spot Options | + | /* |
- | * DRRs | + | |
- | * Fraction Groups | + | Variant: 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 “active” variant and the plan will automatically update based on the selection of the active variant. However, in some cases it is not desirable to update the plan, so the user may also choose to lock the plan and simply recompute DVH and other volume based statistics based on the new active variant geometry. In either case, variants can be used to streamline workflows and prevent accidental misuse of out-dated contours. |
- | * Target | + | |
- | * Constraint | + | */ |
- | * Target Dose Constraints [1,...,N] | + | ==== Descriptions ==== |
- | * Target | + | |
- | | + | |
- | * Beamset | + | |
- | * Constraint [0,1,...,N] | + | |
- | * Beam [1,...,N] | + | |
- | * Constraints [0,1,...,N] | + | |
- | * Objectives [0,1,...,N] | + | |
- | * Dose Results | + | |
- | ===== Descriptions | + | |
* **__Patient__**: | * **__Patient__**: | ||
* A person receiving medical treatment. A Patient record contains basic personal information and demographics, | * A person receiving medical treatment. A Patient record contains basic personal information and demographics, | ||
+ | * This is where the patient name (prefix, given name, middle name, family name, suffix), medical record number (MRN#), sex (male, female, other, any) and date of birth (month, day, year) are stored. | ||
* **__Course__**: | * **__Course__**: | ||
- | * A prescribed regimen to be followed to treat a specific disease occurrence for a specific period of time. A Course will contain the physician' | + | * A prescribed regimen to be followed to treat a specific disease occurrence for a specific period of time. A Course will contain the physician' |
- | * **__Intent__**: | + | * The user will label the Course of treatment and specify the physician of record. The user has the option of adding a description of the course of treatment. |
- | * The physician' | + | * The intent captures the physician' |
- | * **__Directive__**: | + | * The directive is the physician' |
- | * The physician' | + | * A Course |
- | * **__Snapshot__**: | + | * **__Patient Model__**: |
- | * A description of the patient' | + | * A description of the patient' |
- | * **__Request__**: | + | * **__Variant__**: |
- | * A message giving an alert that a Plan needs to be created. As DICOM Gen2 is finalized and implemented, a request can be implemented from many locations, including the TPS itself, a contouring program, or other workflow management software tools. The request will include | + | * 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 |
* **__Plan__**: | * **__Plan__**: | ||
- | * A detailed model of a proton therapy treatment. Most aspects of the patient planning | + | * A detailed model of a proton therapy treatment. Most aspects of the patient planning |
+ | |||
+ | ==== 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 60%> | ||
planning/instructions_for_use/instructions_for_use.1464144425.txt.gz · Last modified: 2021/07/29 18:22 (external edit)