View source for Reporting Workflow Revision - Brief Proposal

__NOTOC__
==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