Reporting Workflow Revision - Detailed Proposal - 2012-2013

1. Proposed Workitem: Reporting Workflow Update

• 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 and poor communication between those systems.

DICOM UPS supports Reporting Worklists; push-notifications of the completion of pre-requisite tasks and lists of their outputs (which are reporting inputs); the ability to reference remote/alternate locations for inputs (e.g. for off-site reporting or access to priors); and dovetails with the PAWF post-processing workflow. UPS is simpler to implement than the prior GP-Worklist/GP-PPS.

An updated Reporting Workflow Profile would provide a standard-based model and mechanisms for communicating relevant data lists and sending ready-to-read related signals.

IHE could support integration/testing of RIS-driven, PACS-driven, and third-party driven workflows.

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 (soon to be retired) GP-Worklist.

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

• Radiotherapy implemented Sup 74 based on Sup 96 and successfully tested at two Connectathons
• now Final Text
• was used for PAWF

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

<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

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

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

Impact on existing integration profiles

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

New integration profiles needed

RWF would be re-written.

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

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

<List technical or political risks that will need to be considered to successfully field the profile.>

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

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

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

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)
• Should/Could we describe how to consume the reporting input signals independent of actually using UPS for the Reporting Worklist itself?

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):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA

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

• 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

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.
• 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.