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

From IHE Wiki
Jump to: navigation, search
(New page: __NOTOC__ ''This template is for one or two page IHE workitem proposals for initial review.'' ''<Delete everything in italics and angle brackets and replace with real text. This means ...)
 
(Impact on existing integration profiles)
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 +
==1. Proposed Workitem: Reporting Workflow Revision==
  
''This template is for one or two page IHE workitem proposals for initial review.''
+
* 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. 
  
''<Delete everything in italics and angle brackets and replace with real text.  This means delete the angle bracket character and the two quote marks too.>''
+
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.
  
==1. Proposed Workitem: ''<initial working name for profile/whitepaper/etc>''==
+
A revised IHE Reporting Workflow profile is the second half of the work started with IHE PAWF.
  
* Proposal Editor: ''<Name of author/editor/contact for the proposal>''
+
==2. The Problem==
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
+
* Domain: ''<Domain name (e.g. Radiology)>''
+
  
 +
Reporting workflow is getting more complex;
 +
* need to '''coordinate/collate more inputs''' such as clinical processing, 3D reconstruction, and more combinations and permutations.
  
==2. The Problem==
+
Reporting workflow is getting more distributed;
 +
* data collection, processing & reporting are more commonly spread across '''multiple locations''', even multiple organizations.
  
''<Summarize the integration problem. What doesn’t work, or what needs to work.>''
+
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.
  
''<Now describe the Value Statement: what is the underlying cost incurred by the problem, what is to be gained by solving it>''
+
Radiology process improvement initiatives like SWIM need better tools to '''capture timestamps''' for activities.
  
==3. Key Use Case==
+
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.
  
''<Describe a short use case scenario from the user perspective.  The use case should demonstrate the integration/workflow problem.>''
+
Proprietary workflows sometimes address some of the above, but at a cost in flexibility and limiting choice/ability to use preferred systems.
  
''<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.>''
+
==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==
 
==4. Standards & Systems==
  
''<List existing systems that are/could be involved in the problem/solution.>''
+
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
 +
 
 +
===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==
 +
 
  
''<If known, list standards which might be relevant to the solution>''
 
  
  
==5. Discussion==
+
==9. Tech Cmte Evaluation==
  
''<Include additional discussion or consider a few details which might be useful for the detailed proposal>''
+
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:''<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>''
+
:* 35% (which includes informative analysis of how to collect/interpret useful ready-to-read signals)
:''<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?>''
+
  
 +
Responses to Issues:
 +
:''See italics in Risk and Open Issue sections''
  
''<This is the brief proposal.  Try to keep it to 1 or at most 2 pages>''
+
Candidate Editor:
 +
: Kevin O'Donnell

Latest revision as of 18:00, 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

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