Difference between revisions of "Reporting Workflow Revision - Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 3: Line 3:
  
 
* Proposal Editor: Kevin O'Donnell
 
* Proposal Editor: Kevin O'Donnell
* Editor: Kevin O'Donnell?
+
* Editor: Kevin O'Donnell  
 
* Domain: Radiology (& Cardiology?)
 
* Domain: Radiology (& Cardiology?)
  
 
===Summary===
 
===Summary===
''<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">''
+
Post-processing and reporting workflow & dataflow in Radiology departments is increasingly complex.  However, implementation and deployment of the Reporting and Postprocessing Workflow Profiles has been minimal and they do not support some forms of workflow and task management.
  
''<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">''
+
DICOM UPS supports a wider variety of workflow patterns, provides subscription-based task monitoring, a simpler implementation model, better data referencing, and has been successfully implemented and tested in IHE-RO for radiotherapy workflow.
  
''<Summarize in a few lines how the problem could be solved.  E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">''
+
The Reporting Workflow and Post-processing Workflow Profiles can be revised/replaced to use DICOM UPS.
  
''<Summarize in a line or two market interest & available resources.  E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking.  Individuals from SFR are willing to participate in Profile development.">''
+
SIIM has recently revived interest in mapping the post-processing and reporting workflow in their TRIP initiative.  The RSNA RadLex work has produced an initial set of report templates which are the topic of another proposal.
 
 
''<Summarize in a line or two why IHE would be a good venue to solve the problemE.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">''
 
  
 
==2. The Problem==
 
==2. The Problem==
Line 60: Line 58:
  
 
UPS Status
 
UPS Status
 +
* currently in the process of moving from Frozen Draft to Final Text
 
* Radiotherapy implemented Sup 74 based on Sup 96 and successfully tested at two Connectathons
 
* Radiotherapy implemented Sup 74 based on Sup 96 and successfully tested at two Connectathons
* currently in the process of moving from Frozen Draft to Final Text
+
* due to changes/improvements during review will be re-balloted in November
* due to changes/improvements during review will be re-balloted in October
 
  
  
 
==5. Technical Approach==
 
==5. Technical Approach==
''<This section can be very short but include as much detail as you like.  The Technical Committee will flesh it out when doing the effort estimation.>''
 
  
''<Outline how the standards could be used/refined to solve the problems in the Use Cases.  The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>''
+
This basically involves updating the existing Reporting and PostProcessing Profiles to use UPS and any other changes that might make it easier to implement and use.
 
 
This is basically about updating the existing Reporting and PostProcessing Profiles (which seem to have had very limited traction), to be easier to implement and use, in part through using UPS.
 
  
 
UPS Benefits
 
UPS Benefits
Line 79: Line 74:
 
* improves referencing of input/output data, handling local network, media or XDS retrieval
 
* improves referencing of input/output data, handling local network, media or XDS retrieval
  
IHE Reporting Whitepaper
 
* Several years ago we did a whitepaper on reporting workflow which partly mapped it out and arrived at some conclusions.  That material should be useful to this activity as well.
 
 
''<If a phased approach would make sense indicate some logical phases.  This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''
 
  
 
===Existing actors===
 
===Existing actors===
''<Indicate what existing actors could be used or might be affected by the profile.>''
+
Post-Processing Manager, Reporting Manager, Evidence Creator, Report Creator, Acquisition Modality, Image Display, Image Archive/Manager, DSS/Order Filler
  
 
===New actors===
 
===New actors===
''<List possible new actors>''
+
 
  
 
===Existing transactions===
 
===Existing transactions===
''<Indicate how existing transactions might be used or might need to be extended.>''
+
Modify/replace existing RWF/PPWF workflow transactions.  
  
 
===New transactions (standards used)===
 
===New transactions (standards used)===
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''
+
Consider new transactions for additional workflow patterns
 +
 
  
 
===Impact on existing integration profiles===
 
===Impact on existing integration profiles===
''<Indicate how existing profiles might need to be modified.>''
+
Modify Post-Processing & Reporting Workflow Profiles
  
 
===New integration profiles needed===
 
===New integration profiles needed===
''<Indicate what new profile(s) might need to be created.>''
+
Alternatively, create a new combined Post-Processing & Reporting Workflow Profile
 +
 
  
 
===Breakdown of tasks that need to be accomplished===
 
===Breakdown of tasks that need to be accomplished===
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''
+
* re-draft transactions for query, claim and report performance of tasks
 +
* review existing use cases in the profile and update based on SIIM TRIP analysis
 +
* add transactions to address new use cases
 +
 
  
 
==6. Support & Resources==
 
==6. Support & Resources==
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
+
 
 +
IHE Reporting Whitepaper
 +
* Several years ago we did a whitepaper on reporting workflow which partly mapped it out and arrived at some conclusions.  That material should be useful to this activity as well.
  
 
SIIM TRIP
 
SIIM TRIP
Line 112: Line 110:
 
* good potential for collaboration on defining needs, designing solutions and promoting the result
 
* good potential for collaboration on defining needs, designing solutions and promoting the result
  
 +
RSNA RadLex
 +
* work has been completed on an initial set of procedure codes and report templates.
  
* The whitepaper stalled due to lack of participation from reporting vendors.  That is a risk for this work as well.  SIIM TRIP collaboration may help generate critical mass.
 
  
 
==7. Risks==
 
==7. Risks==
''<List technical or political risks that will need to be considered to successfully field the profile.>''
+
 
Risks:
 
 
* we should confirm the need/business case does exist for these profiles.  They may not have failed due to technical issues.
 
* we should confirm the need/business case does exist for these profiles.  They may not have failed due to technical issues.
 
** Feeling is that the business case is sound.  There is a need.
 
** Feeling is that the business case is sound.  There is a need.
 
** Were there other inhibitors than the complexity of the GP implementation
 
** Were there other inhibitors than the complexity of the GP implementation
 
** Did people implement GPWL and balk at using SR for the output?
 
** Did people implement GPWL and balk at using SR for the output?
 +
* whitepaper work stalled due to lack of participation from reporting vendors.
 +
** Leverage SIIM TRIP and RadLex participants?
 +
  
 
==8. Open Issues==
 
==8. Open Issues==
''<Point out any key issues or design problems.  This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>''
 
  
 
* we should be careful not to stray into trying to design universal workflow management.  Even while limiting to Radiology, we should still be aware of general solutions (e.g. BPEL, etc).
 
* we should be careful not to stray into trying to design universal workflow management.  Even while limiting to Radiology, we should still be aware of general solutions (e.g. BPEL, etc).
Line 138: Line 138:
  
 
==9. Tech Cmte Evaluation==
 
==9. Tech Cmte Evaluation==
 
''<The technical committee will use this area to record details of the effort estimation, etc.>''
 
  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):

Revision as of 11:21, 20 October 2010

1. Proposed Workitem: Reporting & Processing Workflow Update

  • Proposal Editor: Kevin O'Donnell
  • Editor: Kevin O'Donnell
  • Domain: Radiology (& Cardiology?)

Summary

Post-processing and reporting workflow & dataflow in Radiology departments is increasingly complex. However, implementation and deployment of the Reporting and Postprocessing Workflow Profiles has been minimal and they do not support some forms of workflow and task management.

DICOM UPS supports a wider variety of workflow patterns, provides subscription-based task monitoring, a simpler implementation model, better data referencing, and has been successfully implemented and tested in IHE-RO for radiotherapy workflow.

The Reporting Workflow and Post-processing Workflow Profiles can be revised/replaced to use DICOM UPS.

SIIM has recently revived interest in mapping the post-processing and reporting workflow in their TRIP initiative. The RSNA RadLex work has produced an initial set of report templates which are the topic of another proposal.

2. The Problem

Radiology workflows are getting more distributed; data collection, processing & reporting are more commonly spread across multiple locations, even multiple organizations.

Radiology workflows are getting more complex; more steps such as clinical processing, 3D reconstruction, and more combinations and permutations.

Radiology workflow logic is getting more sophisticated; there are examples of push, pull, centralized, distributed, data-driven, event-driven, etc.

This makes it harder for people to know who is supposed to do what next or find out what has been done. Worklists and performed procedure steps would help, but GP Worklist has proven to be difficult to implement and does not address some of the logic patterns.


Costs from manual workflow likely include slower turnaround (a key metric for radiology), extra manpower for the manual tasks, lost/dropped actions, poor resource balancing, missing data, poor coordination, poor collection of performance metrics, poor tracability, etc.

Proprietary workflows sometimes address some of the above, but at a cost in flexibility and limiting choice/ability to use preferred systems.

3. Key Use Case

An imaging procedure is ordered which should be followed by running a clinical analysis package on the images, performing a CAD analysis and generating a 3D visualization. All four datasets should be considered in the interpretation and report.

  • the three post-processing steps are performed by different people on different workstations
  • there is more than one protocol that could be run in each step and they need to know which
  • the techs need to know when the input data is available for them to start their work
  • they should not have to go manually retrieve their inputs
  • the output data should be identified and made available to the next step
  • the radiologist may not know whether to expect all 4 of the datasets or only some of them
  • the radiologist does not know when each is complete or when the data is available
  • when there is a failure, there should be enough information for a management system to be alerted/intervene
  • there should be information in the audit trails to give some idea of how the department is performing and where the bottlenecks, if any, are

Among other things, we would like to be able to:

  • request reading or consultation by another facility
  • provide references and access paths for images to read, images for priors
  • precisely describe the requested action
  • possibly indicate who you would like to do it
  • provide avenue for requester to monitor progress and get pointers to results

4. Standards & Systems

Systems include RIS, PACS, modalities, post-processing, reporting, HIS, EMR

Standards include DICOM Unified Procedure Step (Sup 96)

UPS Status

  • currently in the process of moving from Frozen Draft to Final Text
  • Radiotherapy implemented Sup 74 based on Sup 96 and successfully tested at two Connectathons
  • due to changes/improvements during review will be re-balloted in November


5. Technical Approach

This basically involves updating the existing Reporting and PostProcessing Profiles to use UPS and any other changes that might make it easier to implement and use.

UPS Benefits

  • retains many of the attributes used in GP-WL for easier transition
  • much simpler object management logic
  • supports push workflow, pull workflow, self-scheduling, etc.
  • provides a subscription model for monitoring procedure steps
  • improves referencing of input/output data, handling local network, media or XDS retrieval


Existing actors

Post-Processing Manager, Reporting Manager, Evidence Creator, Report Creator, Acquisition Modality, Image Display, Image Archive/Manager, DSS/Order Filler

New actors

Existing transactions

Modify/replace existing RWF/PPWF workflow transactions.

New transactions (standards used)

Consider new transactions for additional workflow patterns


Impact on existing integration profiles

Modify Post-Processing & Reporting Workflow Profiles

New integration profiles needed

Alternatively, create a new combined Post-Processing & Reporting Workflow Profile


Breakdown of tasks that need to be accomplished

  • re-draft transactions for query, claim and report performance of tasks
  • review existing use cases in the profile and update based on SIIM TRIP analysis
  • add transactions to address new use cases


6. Support & Resources

IHE Reporting Whitepaper

  • Several years ago we did a whitepaper on reporting workflow which partly mapped it out and arrived at some conclusions. That material should be useful to this activity as well.

SIIM TRIP

  • SIIM is working on mapping/modeling radiology workflow steps and patterns (first draft completed)
  • good potential for collaboration on defining needs, designing solutions and promoting the result

RSNA RadLex

  • work has been completed on an initial set of procedure codes and report templates.


7. Risks

  • we should confirm the need/business case does exist for these profiles. They may not have failed due to technical issues.
    • Feeling is that the business case is sound. There is a need.
    • Were there other inhibitors than the complexity of the GP implementation
    • Did people implement GPWL and balk at using SR for the output?
  • whitepaper work stalled due to lack of participation from reporting vendors.
    • Leverage SIIM TRIP and RadLex participants?


8. Open Issues

  • we should be careful not to stray into trying to design universal workflow management. Even while limiting to Radiology, we should still be aware of general solutions (e.g. BPEL, etc).
    • do we need a RESTful interface to the UPS Service?
  • Given that it is DICOM-based, how do we keep the EMR in the loop?

Questions:

  • Should loosen the linkage to SINR as the output.
  • Is this a clean compliment to the Reporting Templates?
    • Dovetail fairly easily. Don't have to be joined at the hip.
  • Should we address MWL?
    • (While UPS would work, shouldn't mandate replacing MWL, but a useful compliment - perhaps add as an option to SWF)

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA