Scheduled Workflow II - Detailed Proposal

1. Proposed Profile: Scheduled Workflow II

• Proposal Editor: Chris Lindop/Ruth Berge/Tony Palmer/Doug Castle
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

Summary

The Scheduled Workflow Integration Profile pioneered the use cases for interoperability of Healthcare systems for Radiology Imaging. It is not current with the existing standards. It has gaps that do not cover the interoperability workflow of today's system needs. This integration profile addresses the usage of current standards and the interoperability gaps.

The Problem

It is based on HL-7 v3.2.1. The current balloted version is HL-7 V 2.5.1. New systems in development are using the current version and not the version profiled in Scheduled workflow. This impedes new adoption of this profile.

The original scheduled workflow has interoperability gaps since it was originally published. Many of those gaps were published as options. New integration profiles were published, including Patient Administration Management, Post-Processing Workflow and Review Workflow designed to address many of the gaps associated with Scheduled Workflow. This new integration profile needs to review the options and integration profiles

The original scheduled workflow has interoperability gaps with the order placer. The order granularity and feedback from the order filler is not sufficiently designed to profile the expectations of the clinical environment when placing orders.

The original scheduled workflow does not address specific interoperability requirements of the order filler. Many of the options do address the order filler interoperability. However specific clinical data and human intervention to confirm that an imaging tack is claimed as well is completed is missing.

Key Use Case

This Integration profile leverages the same use cases as scheduled workflow.

• Normal Scheduled Case
• UnScheduled Case
• Patient Update Case
• Schedule Update
• Order Change Case
• Abandon Case
• Apend Case
• Group Case
• Implicit Post Processing
• Relevant Clinical Information Distribution
• Results Distribution

All of these use cases are documented to some level throughout the Current Integration Profile.  

Standards & Systems

Relevant standards:

HL-7 v2.5.1

IHE SWF needs to use the most currently balloted version of HL-7. Moving to the current balloted version is an essential component of this proposal. HL-7 v 2.5 was identified as a critical need by the Japan National Committee and the Spain National Committee. Version 3 has not currently passed ballot. The current balloted version is HL7 v2.5.1.

DICOM

Technical Approach

Existing Actors

All existing actors in the Current Scheduled Workflow Integration Profile will be included in this effort.

New Actors

None.

New Transactions

Two new transactions are identified:

• Claim Workitem - from the Acquisition Modality to the Order filler.
• Work Item Complete - from the Acquisition Modality to the Order filler.

New Integration Profiles Needed

This profile should consider normalizing SWF to cover Acquisition Workflow (AWF) and Radiology Order Management (ROM) as separate profiles. The purpose of this partitioning would provide for a clearer delineation between acquisition, post-processing and reporting. Consideration will also be needed to structure Orders Management such that it can be reused by other domains for their orders management.

Breakdown of Tasks that need to be acomplished

1. Use Case Review

The Use Case Descriptions need to be restructured and reviewed for completeness. In their current state, they are not explicitly described in any single section.

2. Profile Options Review

There are a total of 16 options specified in Scheduled Workflow. Each of the options specified must be reviewed against the Use Cases. If the options are necessary to meet the use cases, then the optional usage must be changed to required. If not, they need to be removed.

3. Transaction Data Elements Options Review.

Each Transaction within Scheduled Workflow has optional data elements specified. Each optional data element needs to be reviewed against the Use Cases. They are to be removed if not necessary or changed to required if they do contribute to the use case. Elements marked as required but are not clearly mapped to a use case or are not clearly testable against a use case need to be evaluated as well.

3.1. MWL Clinical Information Option

MWL has inclusion of clinically relevant data in the worklist as an option today. This is in conflict with the Order Filler requirement to provide this information to the modality.

3.2. Mandatory Usage of Exception Codes in MPPS

The usage of exception codes needs to be mandatory for Order Fillers to accept and modalities to provide.

3.3. Mandatory Usage of Protocol Codes in MPPS

The usage of protocol codes is necessary for true interoperability with RIS systems. Clearly defining what was ordered versus what was performed. This is essential for re-takes appends, and other, well documented, use cases which impede the effective interoperability of SWF.

4. Enhanced Interoperabiilty with HL-7 v2.5.1

4.1. Enhanced OBR Segment

The transaction RAD-2 created by the order placer contains the OBR segment. The OBR segment is enhanced in version 2.5.1. The additional information in the OBR segments enables finer grain order definition with the placer and filler supplemental service information.

The segment is bi directional. The supplemental service information fields provide supplemental service information for procedure information when the order from the master file is not sufficient. A placed order needs to provide additional specificity beyond the master file. Conversely, the feedback with supplemental service information fields is necessary when the order is not sufficient for proper billing and reporting.

OBR includes additional fields for results distribution. Additional information includes “who” to send the report to and how.

OBR segment introduces the parent universal service identifier for identifying the parent order. This would be very useful in appends and duplicate procedure uses cases. There is also the duplicate procedures field to provide additional rationale for procedure duplication.

4.2. Imaging Procedure Control Inclusion of the OMI Message

Version 2.5 introduces the OMI message, specific to imaging orders.

It includes the IPC segment, designed to provide a direct mapping with DICOM Imaging Procedure Control attributes. The IPC includes modality, protocol, procedure step and other acquisition information that is not available in version 2.3.1.

It also introduces the TQ1 and TQ2 timing and quantity segments, enabling you to specify specific timing requirements also not possible in 2.3.1.

4.3 ORC Segment

The ORC Segment includes the inter-authorization mode needed to identify the filler’s-authorization for use case events such as append or unscheduled events.

The ORC includes an Order Confidentiality field to provide confidentiality handling of the order being placed.

4.4. CTD Contact Data Segment

CTD Contact data segment provides additional types of contact information for report distribution.

5. SWF Order Modify

Clean up the Order Modification workflow (as it is an inefficient process today). For an order modification, the order is cancelled and then a new order is placed. HL-7 allows for the order to be modified without cancelling first. This practice was adopted in the original version of SWF. It is not a constraint of HL-7 v2.3.1. Reason or usage for cancel/new order workflow is not captured. This workflow would be inconsistent with other workflows such as a modality changing an order with the DICOM MPPS changing what was requested with what was performed using procedure codes.

6. Add, Claim Work Item Transaction

Add a “Claim work Item Transaction” from the Modality to the Order Filler with additional fields necessary for Workflow Management by the Order Filler to signify the Start of an Exam. This would help with modalities which have the capability to setup protocols for the next patient while the previous patient is still being scanned.

7. Add, Work Item Complete Transaction

Add a “Work Item Complete Transaction” from the Modality to the Order Filler with additional fields necessary for Workflow Management by the Order Filler to properly close the completion of an exam procedure. The additional attributes need to include the clinical elements of the image acquisition.

Note that the current MPPS is not sufficient to support closing an exam. Without the additional clinical information, MPPS can not be used to close an exam by an Order Filler.

8. PAM Transactions

Replace the ADT transactions currently specified with the IHE ITI Patient Demographics Management (PAM) transaction.

9. Precautions and Allergies

Precautions and Allergies and other comment fields need to be reviewed and potentially remapped to alternate segments in v.2.5 that are currently relevant.

Tech Cmte Evaluation

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

Responses to Issues:

Candidate Editor:

Chris Lindop/Ruth Berge/Tony Palmer

Other Contributors?