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

From IHE Wiki
Jump to: navigation, search
(5. Discussion)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
==1. Proposed Workitem: Reporting Workflow Update==
+
==1. Proposed Workitem: Reporting Workflow Revision==
  
 
* 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===
 +
Reporting workflow is difficult to integrate and often poorly managed due it's dependency on inputs from a (growing) number of contributing systems (modalities, 3D, CAD, Clinical Packages) and poor communication between those systems. 
 +
 +
GP-Worklist has been retired and we need a standard-based model and mechanisms for communicating relevant data lists and sending ready-to-read signals.
 +
 +
DICOM UPS:
 +
:* supports Reporting Worklists;
 +
:* supports push-notifications of the completion of pre-requisite tasks and lists of their outputs (which are reporting inputs);
 +
:* supports references to remote/alternate locations for inputs (e.g. for off-site reporting or access to priors);
 +
:* dovetails with PAWF Post Acquisition Workflow
 +
:* is simpler to implement than GP-Worklist/GP-PPS.
 +
 +
A revised IHE Reporting Workflow profile is the second half of the work started with IHE PAWF.
  
 
==2. The Problem==
 
==2. The Problem==
  
Reporting workflow is getting more distributed; data collection, processing & reporting are more commonly spread across multiple locations, even multiple organizations.
+
Reporting workflow is getting more complex;  
 +
* need to '''coordinate/collate more inputs''' such as clinical processing, 3D reconstruction, and more combinations and permutations.
  
Reporting workflow is getting more complex; need to coordinate/collate more inputs such as clinical processing, 3D reconstruction, and more combinations and permutations.
+
Reporting workflow is getting more distributed;  
 +
* data collection, processing & reporting are more commonly spread across '''multiple locations''', even multiple organizations.
  
The original Reporting Workflow Profile tried to address earlier versions of this problem, but did so using the cumbersome (soon to be retired) GP-Worklist.  
+
The original Reporting Workflow Profile tried to address earlier versions of this problem, but did so using the cumbersome (retired) GP-Worklist.  
  
 +
The "'''Ready-to-Read'''" problem is a long standing issue that needs a solution.
  
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.
+
Radiology process improvement initiatives like SWIM need better tools to '''capture timestamps''' for activities.
 +
 
 +
Costs from manual workflow include slower report turnaround time (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 traceability, etc.
  
 
Proprietary workflows sometimes address some of the above, but at a cost in flexibility and limiting choice/ability to use preferred systems.
 
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==
 
==3. Key Use Case==
 
<<Revise to discuss the "ready to read" challenges, etc.>>
 
  
 
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.
 
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
 
* 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 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
 
* the radiologist does not know when each is complete or when the data is available
 +
* the reporting worklist should be able to either identify or provide selection criteria for reporting templates and hanging protocols
 
* when there is a failure, there should be enough information for a management system to be alerted/intervene
 
* 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
 
* 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
 +
* those waiting on the report may not know whether it has been completed/approved
  
 
Among other things, we would like to be able to:
 
Among other things, we would like to be able to:
 
* request reading or consultation by another facility
 
* request reading or consultation by another facility
 
* provide references and access paths for images to read, images for priors
 
* provide references and access paths for images to read, images for priors
 +
* leverage input signals that contribute to "ready-to-read" decisions
 
* precisely describe the requested action
 
* precisely describe the requested action
 
* possibly indicate who you would like to do it
 
* possibly indicate who you would like to do it
Line 46: Line 62:
 
Systems include RIS, PACS, modalities, post-processing, reporting, HIS, EMR  
 
Systems include RIS, PACS, modalities, post-processing, reporting, HIS, EMR  
  
Standards include DICOM Unified Procedure Step
+
Standards include DICOM Unified Procedure Step, IHE PAWF
  
==5. Discussion==
+
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.
  
This is basically about updating the existing Reporting Profile to be easier to implement and use, in part through using UPS.
+
==5. Technical Approach==
 +
Update the existing Reporting Profile to use UPS and any other changes that might make it easier to implement and use; same as we did for PAWF.
  
 +
===Existing actors===
 +
Reporting Manager, DSS/OF, Report Creator, Image Archive/Manager, PPS Mgr
  
UPS Status
+
===New actors===
* Radiotherapy implemented Sup 74 based on Sup 96 and successfully tested at two Connectathons
+
* now Final Text
+
* was used for PAWF
+
  
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
 
  
SIIM TRIP
+
===Existing transactions===
* SIIM is working on mapping/modeling radiology workflow steps and patterns (first draft completed)
+
Modify/replace existing RWF workflow transactions for claiming/managing worklist items and status/notifications.
* good potential for collaboration on defining needs, designing solutions and promoting the result
+
  
IHE Reporting Whitepaper
+
Most of the new PAWF transactions could be re-used, so a good chunk of work has been done.
* 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.
+
* 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.
+
  
Questions:
+
===New transactions (standards used)===
* 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)
+
* Should/Could we describe how to consume the reporting input signals independent of actually using UPS for the Reporting Worklist itself?
+
  
Risks:
+
===Impact on existing integration profiles===
* we should confirm the need/business case does exist for these profiles.  They may not have failed due to technical issues.
+
This would replace the current Reporting Workflow (RWF) which would be deprecated.
 +
* Since GPWL has been retired, RWF should be deprecated anyway
 +
 
 +
===New integration profiles needed===
 +
Publish modified RWF(.b) Reporting Workflow Profile
 +
 
 +
===Breakdown of tasks that need to be accomplished===
 +
* add Report Manager/Creator to Role Table in PAWF transactions for query, claim and report performance of tasks
 +
* review SIIM TRIP timestamps and consider if new attributes/codes are needed to capture them
 +
* list up ready-to-read signals and decide if worklist manager needs any additional transactions
 +
* merge and tweak Profile Chapters from PAWF and existing RWF
 +
 
 +
==6. Support & Resources==
 +
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
 +
 
 +
==7. Risks==
 +
 
 +
* As with all these proposals, we should confirm the need/business case does exist for these profiles.
 
** 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 RWF inhibitors than the complexity of the GP implementation
** Did people implement GPWL and balk at using SR for the output?
+
 
 +
* Lack of Participation from reporting vendors (GE, Siemens, Nuance, Agfa, MModal, Intelerad) is a risk. 
 +
** RSNA Reporting, WG-8 and SIIM TRIP collaboration are venues to recruit and generate critical mass.
 +
 
 +
==8. Open Issues==
 +
 
 +
 
 +
 
 +
 
 +
==9. Tech Cmte Evaluation==
 +
 
 +
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 +
:* 35% (which includes informative analysis of how to collect/interpret useful ready-to-read signals)
  
* 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).
+
Responses to Issues:
** do we need a RESTful interface to the UPS Service?
+
:''See italics in Risk and Open Issue sections''
* Given that it is DICOM-based, how do we keep the EMR in the loop?
+
  
''<This is the brief proposal.  Try to keep it to 1 or at most 2 pages>''
+
Candidate Editor:
 +
: Kevin O'Donnell

Revision as of 17:59, 27 August 2013

1. Proposed Workitem: Reporting Workflow Revision

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

Summary

Reporting workflow is difficult to integrate and often poorly managed due it's dependency on inputs from a (growing) number of contributing systems (modalities, 3D, CAD, Clinical Packages) and poor communication between those systems.

GP-Worklist has been retired and we need a standard-based model and mechanisms for communicating relevant data lists and sending ready-to-read signals.

DICOM UPS:

  • supports Reporting Worklists;
  • supports push-notifications of the completion of pre-requisite tasks and lists of their outputs (which are reporting inputs);
  • supports references to remote/alternate locations for inputs (e.g. for off-site reporting or access to priors);
  • dovetails with PAWF Post Acquisition Workflow
  • is simpler to implement than GP-Worklist/GP-PPS.

A revised IHE Reporting Workflow profile is the second half of the work started with IHE PAWF.

2. The Problem

Reporting workflow is getting more complex;

  • need to coordinate/collate more inputs such as clinical processing, 3D reconstruction, and more combinations and permutations.

Reporting workflow is getting more distributed;

  • data collection, processing & reporting are more commonly spread across multiple locations, even multiple organizations.

The original Reporting Workflow Profile tried to address earlier versions of this problem, but did so using the cumbersome (retired) GP-Worklist.

The "Ready-to-Read" problem is a long standing issue that needs a solution.

Radiology process improvement initiatives like SWIM need better tools to capture timestamps for activities.

Costs from manual workflow include slower report turnaround time (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 traceability, 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
  • 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
  • the reporting worklist should be able to either identify or provide selection criteria for reporting templates and hanging protocols
  • 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
  • those waiting on the report may not know whether it has been completed/approved

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
  • leverage input signals that contribute to "ready-to-read" decisions
  • 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, IHE PAWF

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.

5. Technical Approach

Update the existing Reporting Profile to use UPS and any other changes that might make it easier to implement and use; same as we did for PAWF.

Existing actors

Reporting Manager, DSS/OF, Report Creator, Image Archive/Manager, PPS Mgr

New actors

Existing transactions

Modify/replace existing RWF workflow transactions for claiming/managing worklist items and status/notifications.

Most of the new PAWF transactions could be re-used, so a good chunk of work has been done.

New transactions (standards used)

Impact on existing integration profiles

This would replace the current Reporting Workflow (RWF) which would be deprecated.

  • Since GPWL has been retired, RWF should be deprecated anyway

New integration profiles needed

Publish modified RWF(.b) Reporting Workflow Profile

Breakdown of tasks that need to be accomplished

  • add Report Manager/Creator to Role Table in PAWF transactions for query, claim and report performance of tasks
  • review SIIM TRIP timestamps and consider if new attributes/codes are needed to capture them
  • list up ready-to-read signals and decide if worklist manager needs any additional transactions
  • merge and tweak Profile Chapters from PAWF and existing RWF

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

  • As with all these proposals, we should confirm the need/business case does exist for these profiles.
    • Feeling is that the business case is sound. There is a need.
    • Were there other RWF inhibitors than the complexity of the GP implementation
  • Lack of Participation from reporting vendors (GE, Siemens, Nuance, Agfa, MModal, Intelerad) is a risk.
    • RSNA Reporting, WG-8 and SIIM TRIP collaboration are venues to recruit and generate critical mass.

8. Open Issues

9. Tech Cmte Evaluation

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

  • 35% (which includes informative analysis of how to collect/interpret useful ready-to-read signals)

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Kevin O'Donnell