IHERO UseCase 2011 QA Checker: Difference between revisions

Revision as of 08:36, 20 March 2011

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

Proposal Editor: Name: Mika Miettinen, mika.miettinen@varian.com, +1 650 799 7665
Editor: Colin Field for Mika
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiation Oncology

2. The Problem

Current patient QA solutions are not integrated well to the clinical workflow to enable efficient, fast and as automated daily patient QA as possible. The lack of integration causes a lot of manual work for clinicians, and thus does not encourage the adoption of these tools to be part of everyday operations and patient treatments in the clinic.

3. Key Use Case

Success Use Cases

Use Case 1

Treatment plan has been created and is sent to Treatment Management System (TMS)
Treatment is prepared by dosimetrist in TMS
Dosimetrist saves the final plan, and sends it to approval
TMS system request a “QA check” from “QA checker” (QA application)
“QA checker” performs the “QA Check”, and returns the results to TMS
If “QA Checker” result is “Ok to proceed”
- Plan in TMS is ready to be approved by physicist and physician
- Physicist and physician approve the plan for treatment
If “QA Checker” result is “Not Ok to proceed”
- TMS informs the dosimetrist about the failure of the check

Use Case 2

Therapist opens the worklist on the Treatment Delivery System (TDS) and selects the patient plan to be treated.
TDS retrieves the patient plan from TMS
TDS system request a “QA check” for the plan from “QA checker” (QA application)
“QA checker” performs the “QA Check”, and returns the results to TDS
If “QA Checker” result is “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 informs the therapist about the failure of the check and requires QA personnel to resolve the situation.

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

@@ Line 1: / Line 1: @@
 __NOTOC__
-''This template is for one or two page IHE workitem proposals for initial review.''
+==1. Proposed Workitem: Integrated Patient QA Checker (part of Patient Safety Use Case)==
-''<Delete everything in italics and angle brackets and replace with real text>
+* Proposal Editor: Name: Mika Miettinen, mika.miettinen@varian.com, +1 650 799 7665
+* Editor: Colin  Field for Mika
-==1. Proposed Workitem: ''<initial working name for profile/whitepaper/etc>''==
-* Proposal Editor: ''<Name of author/editor/contact for the proposal>''
-* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
 * Date:    N/A (Wiki keeps history)
 * Version: N/A (Wiki keeps history)
 * Domain: ''Radiation Oncology''
 [[Category:RO]]
 ==2. The Problem==
-''<Summarize the integration problem. What doesn’t work, or what needs to work.>''
+Current patient QA solutions are not integrated well to the clinical workflow to enable efficient, fast and as automated daily patient QA as possible. The lack of integration causes a lot of manual work for clinicians, and thus does not encourage the adoption of these tools to be part of everyday operations and patient treatments in the clinic.
+==3. Key Use Case==
-==3. Key Use Case==
+Success Use Cases
-''<Describe a short use case scenario from the user perspective.  The use case should demonstrate the integration/workflow problem.>''
+Use Case 1
+# Treatment plan has been created and is sent to Treatment Management System (TMS)
+# Treatment is prepared by dosimetrist in TMS
+# Dosimetrist saves the final plan, and sends it to approval
+# TMS system request a “QA check” from “QA checker” (QA application)
+# “QA checker” performs the “QA Check”, and returns the results to TMS
+# If “QA Checker” result is “Ok to proceed”
+#*Plan in TMS is ready to be approved by physicist and physician
+#*Physicist and physician approve the plan for treatment
+# If “QA Checker” result is “Not Ok to proceed”
+#*TMS informs the dosimetrist about the failure of the check
-''<Feel free to add a second use case scenario demonstrating how it “should” work.  Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>''
+Use Case 2
+# Therapist opens the worklist on the Treatment Delivery System (TDS) and selects the patient plan to be treated.
+# TDS retrieves the patient plan from TMS
+# TDS system request a “QA check” for the plan from “QA checker” (QA application)
+# “QA checker” performs the “QA Check”, and returns the results to TDS
+# If “QA Checker” result is “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 informs the therapist about the failure of the check and requires QA personnel to resolve the situation.
+<br>
+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==
-''<List existing systems that are/could be involved in the problem/solution.>''
+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.
+<br>
-''<If known, list standards which might be relevant to the solution>''
+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==
@@ Line 42: / Line 56: @@
 :''<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?>''
-''<This is the brief proposal.  Try to keep it to 1 or at most 2 pages>''