Unified Post-Processing Workflow with Application Hosting - Detailed Proposal

1. Proposed Workitem: Unified Post-Processing Workflow with Application Hosting

Proposal Editor: Lawrence Tarbox, Ph.D.
Editor: Kevin O'Donnell / Lawrence Tarbox
Domain: Radiology

Summary

PPWF needs to be upgraded to take advantage of UPS and Application hosting. Post-processing continues to get more complex (more kinds of applications, used in more exams, spread over multiple devices) and managing the workflow and dataflow is challenging.

DICOM has made UPS final text and it has been used successfully in radiotherapy products. DICOM has made Application Hosting final text and it has been used successfully by caBIG in XIP. DICOM is retiring GPWL on which PPWF is currently based.

The PPWF Profile can be re-drafted around UPS with additional text for incorporating application hosting, XDS data references, "ready-for-reading" notifications, etc.

The authors of the UPS and Application Hosting supplements are available and interested in working on the revision.

This sort of combining and profiling standards-based mechanisms to address multi-system workflow is exactly what IHE is most successful at.

2. The Problem

The existing Post-processing Workflow Profile (PPWF) needs to be upgraded to take advantage of new developments in the DICOM Standard, specifically the Unified Worklist and Procedure Step, and Application Hosting.

The Unified Worklist and Procedure Step (UPS) is intended to be simpler to implement, and addresses certain integration problems encountered with the older General Purpose Procedure Step (GPPS) currently specified by the Post-Processing Workflow Profile. In addition, the UPS opens up options unavailable in the older GPPS. DICOM is retiring GPWL in favor of UPS.

Coupling UPS with DICOM Application Hosting in a revamped post-processing workflow opens up a world of possibilities for the potential automation of post-processing, including chaining of sequential operations, collecting input data and posting results via XDS, etc.

While DICOM defines the basic mechanisms for both Unified Worklists, Procedure Steps, and Application Hosting, DICOM does not specify how these mechanisms can be orchestrated to accomplish tasks within a departmental workflow. IHE would seem to be the preferred venue for profiling how these mechanisms work in concert to accomplish procedure steps needed to fulfill an imaging service request or order.

3. Key Use Case

After imaging data has been acquired, one or more analysis or post-processing steps are often performed, providing new or modified data which would be made available to the physician to refer to in making a final report.

These tasks may be automatically triggered by the completion of a pre-requisite step or the availability of pre-requisite data.

These tasks might be performed automatically (e.g. create CAD reports, drug/agent or biological function specific post-processing), or may be semi-automated or manual analysis of that data done by a human operator (e.g. registration of datasets, fusion of datasets, segmentation, image enhancements), so both humans and machines may make use of the worklists.

The outcome of one step may dictate the choice of the next step, so it is useful to be able to create new workitems.

In addition to local data, references to remote data (e.g. priors, or prior volume measurements) should be considered. Workitems should allow identification of the task, application (hosted or standalone) needed to accomplish the task. Workitems should allow passing processing parameters such as thresholds, operating points, and algorithm choices.

Use cases should consider situations where some time may pass until the full set of input data is available, so the profile can document mechanisms for starting tasks once input data is available.

It will also be useful to consider prioritization of certain studies, and tracking when a study has stalled at some point.

The use cases found in Annex XX of Part 17 of the 2011 DICOM Standard describes several analysis categories that could benefit from this proposed automation of post processing workflow. The original use cases for the PPWF Profile should also be considered.

An example sequence of events might be as follows:

1. A workflow manager is informed that data has been acquired (e.g. by completion of a Modality Performed Procedure Step).

2. The workflow manager determines that additional post-processing steps are desired prior to completing the final report

3. The workflow manager creates new worklist items (procedure steps) to accomplish the desired post-processing, and queues them up for appropriate post-processing servers or workstations.

4. The workflow manager tracks the availability of input data and flags workitems as ready for processing once data is available.

5. The post-processing servers or workstations pick up worklist items queued for them, and launch appropriate Hosted Applications to accomplish the tasks. The pickup could either be done automatically, for Hosted Applications that do not require human interventions, or could be done interactively under control of a human operator.

6. When the Hosted Application has completed its analysis or post-processing, it updates the contents of the workitem, stores the result data to an image and/or report manager, and changes the workitem status to complete.

6. Upon receiving notification of completion, the workflow manager may create and queue additional worklist items, building upon the previous output.

4. Standards and Systems

Systems:

Workflow manager (which could be implemented by a PACS, a RIS or a standalone actor)
Evidence creators (which could be embedded in a PACS, a post-processing server or a standalone workstation)
Image manager/archive (which holds input/output data)

DICOM Standard:

Unified Worklist and Procedure Step (Incorporated into the Standard in 2011, originally published as Supplement 96)
Application Hosting (Incorporated into the Standard in 2011, originally published as Supplement 118)

SIIM TRIP has identified a number of departmental timestamps/benchmarks that can be considered. This profile could facilitate tracking progress through the workflow and other departmental performance metrics.

5. Technical Approach

We propose replacing the General Purpose Procedure Step used in the current IHE profile with the new Unified Worklist and Procedure Step mechanisms.

UPS Features/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 (managing), Reporting Manager (listening), Evidence Creator, Acquisition Modality, Image Display, Image Archive/Manager, DSS/Order Filler (triggering)

New actors

Push Performer?
- would accept pushed workitems. Having a separate actor would make it easier for any existing PPWF Evidence Creators to support new mechanics without adopting new workflow patterns.

Existing transactions

Modify/replace existing PPWF workflow transactions.

New transactions (standards used)

Push Workitem?
- based on DICOM UPS N-CREATE
Subscribe for Task Status?
- based on DICOM UPS N-ACTION to get on subscription list for N-EVENTs

Impact on existing integration profiles

Re-draft Post-processing Workflow Profile with new mechanisms.

Update Query to use DICOM UPS C-FIND
Update Claim to use DICOM UPS N-ACTION
Update GPPS to use DICOM UPS N-SET and N-EVENT

New integration profiles needed

No.

Breakdown of tasks that need to be accomplished

re-draft transactions for query, claim and notify performance of tasks
- consider if guidance would be helpful for folks converting Old Profile to New
consider if new attributes are needed to drive/monitor hosted applications (e.g. parameter passing, sub-AETITLEs?)
review existing use cases in the profile and update based on SIIM TRIP analysis (more timestamps?)
consider if new attributes/timestamps are needed to capture all the TRIP benchmarks
add transactions to address new use cases
- Push Workitem (to Push Performer Actor?)
- Subscribe for Workitem Status (to leverage UPS notifications)

6. Support & Resources

The editors of Application Hosting and UPS are available to participate
SIIM TRIP workflow models may provide useful use cases/patterns
caBIG projects may provide additional examples
Clinical workstation "showdown" scenarios should be considered

7. Risks

Be careful not to stray into trying to design universal hospital workflow management.
- Stick to describing radiology tasks.
- Be aware of general solutions (e.g. BPEL, XDW, etc) for layers above the "leaf nodes"
Given that it is DICOM-based, how do we keep the EMR in the loop?
- Consider a RESTful interface to the UPS Service?

Questions:

Should we address SWF/MWL?
- Out of scope for this profile (While UPS would work, shouldn't mandate replacing MWL, but a useful compliment - perhaps propose adding as an option to SWF in the future)

8. Open Issues

See "?" items in Breakdown of Tasks (above) for some potential topics of discussion.

9. Tech Cmte Evaluation

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

30%
no major concerns

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Kevin O'Donnell / Lawrence Tarbox