IHERO UseCase 2011 QA Checker

1. Proposed Workitem: Integrated Patient QA Checker (part of Patient Safety Use Case)

• Proposal Editor: Name: Sha Chang and Kevin Riddell
• Editor: Sha Chang and Kevin Riddell
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiation Oncology

2. The Problem

Today many effective patient QA solutions rely on stand alone systems. Lack of integration of these important QA systems with TPS and TMS systems greatly hinders the reliability and efficiency of the patient specific QA checks and their verification. The lack of integration causes not only a lot of manual work for clinicians but also an increased risk that patient is treated before the required QA checks on the treatment have been successfully completed. Manpower and the lack of reliability of manual entering QA check results to multiple systems also discourage the adoption of these patient QA systems into everyday operations.

3. Key Use Case

Use Case 1: Pre-treatment Patient QA Checks (including data transfer integrity check)

1. Treatment plan created in TPS and approved by physician is transferred from TPS to Treatment Management System (TMS)
2. Treatment preparation in TMS is performed by dosimetrist/therapist
3. Dosimetrist saves the final plan in TMS, and sends request in TMS for treatment approval by physicians
4. TMS sends relevant data to 3rd party QA devices for pre-treatment QA tests. Samples of the tests are
   • independent MU calculation (performed and within tolerance)
   • data transfer (from TPS to TMS) integrity
   • IMRT QA, etc.
   • patient consent form
   • concurrent chemotherapy treatment schedule
   • Prescription (total dose and dose/fraction) in TMS consistent with the treatment plan in TPS
   • Treatment site (incl left right) in TMS is consistent with the treatment plan in TPS
   • Patient setup/localization parameters and instruction in TMS are consistent with the treatment plan in TPS
5. After a given time period TMS system initiates a pre-treatment QA check verification process “pre-treatment patient QA checker” in TMS.
6. The “QA checker” verifies a list of the required QA Checks, and returns the results to TMS based on preset QA criteria or a tolerance table.
7. If all “QA Checker” results are “Ok to proceed”
   • The plan in TMS is ready to be used for patient treatment
8. If one “QA Checker” result is “Not Ok to proceed”
   • TMS prohibits the delivery of the QA-failed treatment plan
   • TMS notifies users the failure of the QA check and the cause(s)

Samples of the interconnectivity needed for this use case:

1. TMS download treatment machine parameters to 3rd party QA system (IMSURE, MUcal, etc) for MU calculation
2. TPS download dosimetry parameters to 3rd party QA system
3. 3rd party QA system compute dose/MU from the TMS data and compare it with the TPS data and download QA results back to TMS “patient QA check”
4. Manual entry QA check result into TMS if interconnectivity between the QA device and TMS doesn’t exist.
5. TMS download treatment machine parameters to 3rd party IMRT QA system (MapCheck, Matrix, etc)
6. TPS download dosimetry parameters to 3rd party IMRT QA system
7. 3rd party IMRT QA system produces QA results and download them to TMS (within the criteria or outside criteria) – for instance, “met criteria" or "passed QA", or "not met criteria" or "failed QA".
8. TMS performs internal check in the patient's dataset to detect if there are entries to STOP patient treatment. Such entries can be
   • Physician's note/order to Cancel treatment
   • Treatment prescription (fractionation and fractional dose) is changed after the plan approval.

1. Based on the outcome from the pre-treatment patient QA checker TMS will either allow or prohibit the delivery of the treatment

Successful scenario:

1. A treatment plan has been created in TPS, approved by the physician in TPS, and downloaded to TMS.
2. TMS “Patient QA Checker”
   • send treatment plan data to a 3rd party software for independent MU calculation
   • send treatment plan data to a 3rd party system for IMRT QA
   • check if patient’s consent form is signed (Do everyone do this? we do)
   • Review any critical note in TMS relevant to the patient treatment and treatment schedule (concurrent chemotherapy)
3. TMS “Patient QA Checker” discovered that the patient’s physician has put a note in TMS to abort the approved treatment plan because the new pathology just came back changed the diagnosis. The treatment was no longer needed.
4. The “Patient QA Checker” resulted “Not OK to proceed” in TMS
5. TMS prohibits the delivery of the treatment plan that is no longer beneficial to the patient.
6. TMS inform physicist/dosimetrist/therapist the reason why the treatment is aborted.

Unsuccessful scenario:

1. Dosimetrist downloaded a treatment plan that has been verbally and informally approved by the patient’s physician from TPS to TMS
2. The physician went away that day for 2 days.
3. Dosimetrist has prepared in TMS to start patient treatment the next day
4. While the physician was away he received a phone call about the change of diagnosis for his patient. It was at the end of the day before the 1st treatment the next morning.
5. The physician could not find the therapist on the machine to notify that the patient no longer needed the treatment. He left phone messages on the treatment console phone and the chief therapist's cell phone asking not to treat his patient.
6. The next morning therapist at the machine and the chief therapist had a very hectic morning because of the machine problems and didn’t have time to check the phone message and to learn that the patient should not be treated.
7. Patient was treated with the approved plan in TMS although the patient no longer needed the treatment.

Use Case 2 – TMS to TDS Integrated QA Checker

Problems/challenges:

1. edits to fields or plan may occur (intentionally or not) between initial plan readiness check and treatment delivery appointment;
2. this QA check is integrated and not experienced as an additional step by users except in case of a failure where details of failure will be displayed;
3. some edits may be acceptable - eg. table positions, set up notes (tolerance tables can be useful in some cases);
4. the timeliness of the check is important- failures should be found as early as possible to allow correction time where appropriate but also readiness check prior to each actual delivery is crucial- a potential solution is to allow a morning QA check of all patient readiness;
5. override for exceptions may be useful to ensure entire concept/application is not disregarded (eg. QA checker not compatible with rarely used mMLC).

Workflow:

1. Therapist opens the worklist (on either TMS or Treatment Delivery System) and selects the patient plan to be treated.
2. During after receipt of patient plan from TMS to TDS the plan is automatically sent through QA checker;
3. “QA checker” performs the “QA Check”, and returns the results to TDS
4. If all “QA Checker” results are “Ok to proceed”

TDS allows therapist to start treatment (after other verification steps are completed) If “QA Checker” result is “Not Ok to proceed” TDS prohibits the delivery of the treatment plan and displays to user a list of 'errors' TDS informs the therapist about the failure of the check and physicists to resolve the situation.

Examples of unsuccessful QA check include: -unacceptable variations from originally planned (as checked by Use case #1) field settings (including asymmetric jaws, MLC, segments, fractional dose, correct treatment machine)- tolerance tables may be useful when there may be a range of acceptable variation; -change of Machine settings in TMS that influence plan delivery (eg. output rate, wedge settings); -field specific check of expected SRS cone, electron applicator, hard wedges, shows incorrect jaw settings for given device; -comparison to exported and stored DICOM RT plan (with plan version number) may be more achievable than comparison to plan within TPS; -Prescription unapproved for treatment.

These are just example use cases, and any actor in the radiotherapy or radiosurgery process shall be able to call a “QA check” at any point of time of the process, and this way the clinic is able to define “QA check timeouts” in their process.

4. Standards & Systems

As IHE-RO addresses interoperability, not functionality, the integration profile must be defined along these lines even if there is a temptation to define what kind of QA checks the “QA checkers” should perform. However it is clear that the community needs the “QA checkers” to perform e.g. data integrity checks, data sanity checks, clinical sanity checks, independent MU calculations, data verification, etc. As part of this integration profile, the technical committee must create a list of “checks” that the “QA checkers” can perform (define what, not how), and what are the expected inputs and outputs in the process.
DICOM RT standard (data objects and worklist) should be considered in implementation of the integration profile. One of the main objectives is to get the QA vendors to join the IHE-RO efforts, and get these QA tools to be part of clinical workflow.

5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>

<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>

<What are some of the risks or open issues to be addressed?>