Scheduled Workflow 2.0 - Detailed Proposal

From IHE Wiki
Jump to navigation Jump to search

Proposed Profile: Scheduled Workflow II

  • Proposal Editor: Chris Lindop
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

Summary

The Scheduled Workflow Integration Profile for the Radiology Domain was first introduced in the IHE Technical Framework Version 1 over 8 years ago. Since the introduction, HL7 has obsoleted and developed new message types which are more appropriate to imaging. In the past years, IHE Radiology has added several options to the original profile to fill in interoperability gaps. These options are best folded into the core profile to improve interoperability overall. Some gaps still exist for some of the actors. As a result, the level of uptake is not consistent with all actors.

The Problem

Completing the Study (on the Order Filler)

  • MPPS is not 100% relied on for completing the study on the modality. A major factor is the "append" use case. When a procedure step is appended, the RIS and PACS would need to re-open the study. This can be an issue if the RIS workflow has already started the next procedure step.
  • Today most sites have a RIS terminal in the suite where the operator manually "completes" the study.
  • It would be better if the tech manually completed it on the modality and remove the need for the "rolling chair" and extra terminal.

Obsolete Messaging for Change Order

  • SWF requires support of Cancel/New Order in order to perform the Modify Order. This two step process is obsolete with the HL7 method which provides the capability to modify an order in a single transaction.
  • The current HL7 method retains the original linking IDs and ordering information supporting better workflow and interoperability with the Order placer and Order Filler.

Obsolete Messaging for Order Placement

  • SWF requires support of ORM in order to perform the Order Placer transactions. This message is obsolete and replaced with the OMG message. The OMG message is much more robust and is capable of supporting coded terminolgy for Order detail. Currently Order Detail partially handled using overloaded fields.

Obsolete Messaging for Order Scheduled

  • SWF requires support of ORM in order to perform the Order Placer transactions. This message is obsolete and replaced with the OMI message. The OMI message is much more robust, designed specifically for Imaging, is capable of supporting coded terminolgy for Order detail and many of the DICOM terminology.


Operator Name at the Order Filler

  • The Order Filler needs the operator name to close the study because it would avoid manual entry for billing and management of staff resources/workflow
  • MPPS does not identify the operator

Cleanup

Overloaded HL7 Fields

  • SWF on 2.3.1 works, but it uses overloads existing fields and uses Z segments
    • Views: SWF overloads the OBR field for specimen with views.
    • Support for Master Codes: New ORC segment may now include the JJ1017 Code (Japanese master code for Radiology)
    • Result Study UID: Current ORR does not normally provide the Study UID to reference. SWF added a custom ZDS Segment to handle Study Instance UID in Transactions RAD-4 and RAD-13. HL7 v2.5 formally defines it in the OMI
  • It would be better if it continued to work but did the same thing using the new fields and segments in 2.6

Patient Information Reconciliation

  • It was not included in SWF for historical reasons.
  • It would be better if PIR was part of SWF (like Card had the opportunity to do)
    • PIR transactions and use cases should be part of SWF II

National Focus on HL7 Version Numbers

  • Some countries are requiring national purchases to use particular versions for Radiology transactions(e.g. 2.5.1)
  • Vendors supporting the current HL7 versions in their deployments and SWF would be limited by deploying the obsolete messaging defined in SWF.

Patient Administration Management Adoption

  • SWF includes patient management because it wasn't' profiled at the time of SWF development.
  • PAM from ITI domain provides a common approach for all domains for patient management.
    • PAM effectively replaces SWF transactions RAD-1 and RAD-12.
  • It would be better if IHE Rad factored out patient management and just referenced PAM instead.

Instance Availability

  • Instance Availability Notification transaction supercedes Instance Availability Query

SWF Options

  • Several should simply be made requirements for all participating actors.
    • PPS Exception Management
    • Availability of PPS Referenced Instances

Key Use Case

The SWF II whitepaper has identified use cases that are not addressed by SWF but could be useful to address.

This SWF II proposal would not address any new use cases beyond SWF.

Only Use Cases which address Radiology Acquisition will be part of the workscope.

It is proposed that the committee spend time on a limited analysis of distributed workflow use cases but not write technical text to address them.

Standards & Systems

HL-7 v2.5.1 (Released)

HL-7 v 2.5.1 is the most relevant version of HL-7 to SWF II. HL-7 v 2.5.1 is identified as a critical need by the Japan National Committee and the Spain National Committee.

HL-7 v2.6 (Released)

The initial assessment by the Rad TC is that v2.6 has no additional features useful or relevant to SWF II.

HL-7 v2.7 (In Development)

The initial assessment by the Rad TC is that v2.7 has no additional features useful or relevant to SWF II.
The initial assessment by the Rad TC is that SWF II will not define any additional requirements relevant to v2.7 development.

HL-7 v3.x (In Development)

The initial assessment by the Rad TC is that the impact of HL-7 v3.x is so significant that it warrants a separate profile.

Regional HL-7 Version Requirements

see strawman process described in open issues section


DICOM

5. Technical Approach

Create a new profile that incorporates all the changes and new material.

Keep the old profile on the books for systems that don't want to make the leap.

Alternative: Add a V2.6 Option which includes the Operator Name, Study Ready and V2.6. Systems must maintain 2.3.1.


Existing Actors

Order Placer

Order Filler

Evidence Creator

Acquisition Modality

Image Manager

New Actors

None proposed.

Existing Transactions

The following changes are proposed for each transaction:

  • RAD-1 Patient Registration - Remove, PAM transactions supersede
  • RAD-2 Orders Management - Replace with Enhanced Orders Management V2.5 based on the OMG message.
  • RAD-3 Order Filler Management Replace with Enhanced Order Filler Management using the specific V2.5 OMI message.
  • RAD-4 Procedure Scheduled - Replace with Enhanced Procedure Scheduled using the specific V2.5 OMI message.
  • RAD-5 Query Modality Worklist - Update the mapping tables
  • RAD-6 Modality Procedure Step In Progress - Add operator ID
  • RAD-7 Modality Procedure Step Complete - Add operator ID
  • RAD-8 Modality Images Stored - no change
  • RAD-10 Storage Commitment - no change
  • RAD-11 Image Availability Query - Remove, it's covered by Instance Availability Notification
  • RAD-12 Patient Update - Remove, PAM transactions supersede
  • RAD-13 Procedure update - Replace with Enhanced Procedure Update using the specific V2.5 OMI message.
  • RAD-14 Query Images - no change
  • RAD-16 Retrieve Images - no change
  • RAD-18 Creator Images Stored - no change
  • RAD-19 Creator Procedure Step In Progress - Add operator ID
  • RAD-20 Creator Procedure Step Complete - Add operator ID
  • RAD-26 Query Reports - Do not include, reporting workflow not included
  • RAD-27 Retrieve Reports - Do not include, reporting workflow not included
  • RAD-42 Performed Work Status Update - Do not include?. Post-processing workflow not included
  • RAD-46 Query Reporting Worklist - Do not include. reporting workflow not included
  • RAD-48 Appointment Notification - Open Issue.
  • RAD-50 Instance Availability Notification - no change.

New Transactions

  • RAD-x2 Manage Order from Placer - Replaces RAD-2 with Enhanced Orders Management V2.5 based on the OMG message.
  • RAD-x3 Manage Order from Filler Replaces RAD-3 with Enhanced Order Filler Management using the specific V2.5 OMI message.
  • RAD-x4 Notify of Scheduled Procedure - Replaces RAD-4 with Enhanced Procedure Scheduled using the specific V2.5 OMI message.
  • RAD-x13 Update Procedure - Replaces RAD-13 with Enhanced Procedure Update using the specific V2.5 OMI message.
  • RAD-xx1 Release? Study - New Transaction to identify when the operator thinks they are done with the study and it is ready for the next step in the departmental workflow

Impact on existing integration profiles

Scheduled Workflow and Patient Information Reconciliation Profiles are not impacted. They may become obsolete in the future by this and other profiles.

New Integration Profiles Needed

None

Breakdown of tasks that need to be accomplished

  1. Modify and review new volume one Profile for Radiology Acquisition Workflow (supersedes SWF II). Use cases to include usage of Operator ID and Study Complete Transaction.
  2. Review existing SWF and PIR Options, decide which to fold-in/make mandatory.
  3. Include text in Volume 1 to factor out tranactions RAD-1 and Rad-12 and add PAM as a dependency or required grouping.
  4. Coordinate "Study Ready" Message mechanisms with the corresponding DICOM CP
  5. Create new Release Study Transaction
  6. Port transactions RAD-2, RAD-3, RAD-4 and RAD-13 from HL7 v2.3.1 to current HL7 v2.5 with new transactions RAD-x2, RAD-x3, RAD-x4 and RAD-x13.


Extra Credit 1

  • Included profile text to address all the additional uses cases documented in the 2007-2008 SWF II Whitepaper.

Extra Credit 2

  • Include profile text to address Distributed Workflow

Support & Resources

Ruth Berge, GE Healthcare.

  • Canada Health Infoway
    • Alvaro Mestre (CHI)
  • IHE Eyecare
    • Mike Schmidt
  • IHE Europe
    • Peter Mildenberger
    • Nick Brown
  • HL7
    • Mike Henderson


  • IHE Japan and Spain
    • both have expressed interest in seeing SWF updated to HL7 v2.5.
    • There is hope that they might contribute some resources.
  • IHE Mammography
    • has expressed their need for some of the departmental workflow enhancements identified and their willingness to work with the re-factoring to support their needs.

Risks

There may not be enough added value for vendors to implement/users to upgrade.

This is a not a major concern. SWF currently uses obsolete messages. Many national requirements include HL7 v2.5 or greater today, making conformance to SWF not possible. SWF 2.0 gives the vendors a path for upgrade without obsoleting their current capabilities.

The mechanisms might be too extensive for vendors to take on:

Some implementers might decide not to support PAM requirements for outpatient imaging centers.

Conveying operator identity may provide minimal benefit if the values/codes are not synchronized across the organization scope of this profile.

This is a deployment issue. An implimentor might call a dependency on PWP or other IT technique

There may be confusion/knock-on effect to other domains which further profiled SWF. SWF will not be obsoleted without consultation with dependednt domains.

Risk: Difficulties coordination the technical approach and schedule with DICOM WG-6 for handling "Study Ready"

Though nice-to-have, "Study Ready" is not essential to the overlying need to update SWF.

Open Issues

Issue: Should the TF text use HL7 V2.6 or 2.5.1

2.6 is the newest balloted. In the context of SWF, 2.5.1 adds useful capabilities over 2.3.1, 2.6 doesn't add much over 2.5.1. Since they are backwards compatible we might as well target 2.6. On the other hand, vendors may not have committed to that change.

Issue: Address Distributed Workflow?

IHE-Canada is very interested in getting this done. It would increase the complexity of the work.

Issue: Should there be an Order Management Profile to go with the Patient Administration Management Profile?

Domain ordering practices are probably different enough that the same transactions/behaviors could not be used.

Issue: Should we eliminate the PPS Mgr and just assign it to the Order Filler?

Would be cleaner text and implementation to remove it. However, more "mixed/legacy" sites could be handled if the Image Manager also has the capability. So should the Profile document that as a requirement or make it a suggestion.

Issue: Should we extract image display behaviors from Retreive Images and put them in a separate Display Image transaction?

Architecturally the separate Display Image would be helpful. Not all retrieves involve display, not all displays involve retrieve (e.g. import, etc.).

Issue: Should the Creator Image/MPPS still be separate transactions?

Issue: Should Appointment Notification be included or not?

It might need to be re-written given the other changes. Enterprise scheduling is a gap. We could do our piece, or we could decide to leave it a gap until there is a master plan.

Issue: What is our policy for maintenance of SWF and SWF II if both are left on the books.

An immediate question is whether we add options to SWF for Intermittent Connection and Multi-modality Aquisition.

Tech Cmte Evaluation

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

  • 50% for only Study Ready, Operator Name, V2.6 and fold-in of PIR & PPS Exception Option & Instance Availability & Assisted Protocol Setting
  • 80% to also include Extra Credit 1
  • 110% to also include Extra Credit 1 & 2

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Chris Lindop


Radiology_Proposals_2008-2009

Retrieved from "http://wiki.ihe.net/index.php?title=Scheduled_Workflow_2.0_-_Detailed_Proposal&oldid=36054"