Scheduled Workflow II - Detailed Proposal

From IHE Wiki
Jump to navigation Jump to search

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 Profile (SWF) is over 5 years old and is not current with some existing standards (e.g. HL7 2.5).

There are interoperability gaps that should be addressed by SWF but are not.

Other profiles that have been developed since SWF provide reasons to consider re-factoring SWF to fold some profiles in (PIR?) and break some profiles out (PAM?).

A new "SWF II" profile should be developed to address these issues.


The Problem

SWF is based on HL7 2.3.1. The current balloted version is HL7 2.5.1. Some new systems in development are supporting 2.5.1 and not supporting the version profiled in SWF. This impedes adoption of this profile by some new systems. Conversely, other systems that support SWF are impeded from abandoning 2.3.1 in favour of 2.5.1.

This is felt most strongly in countries relatively new to HL7. The new features of 2.5.1 are appealing and with no install base of 2.3.1 systems, they have little reason or desire to use 2.3.1. Japan and Spain have made specific requests for 2.5 support in SWF (see following list)


Specific features relevant to SWF that are lacking in 2.3.1 include:

  • Order Granularity: the ability to specify procedure details is limited, e.g. in an order for a 2-view chest, it is not possible to specify the view to include decubitus
  • Signature Mode: there is no way to indicate how an order change/cancellation was approved.
    • Hospital policy may require the signing provider to approve it when Imaging department needs to change ordered procedure
  • Result Study UID: ORR can't provide the Study UID to reference. v2.5 has it in the OMI
  • EVN Segment: Is required and should be optional because ... (IHE-J)
  • TQ1 Segment: Is optional and should be required for ... (IHE-J)


  • IHE Japan requests replacement of ORM with OMG/ORG
  • Order Details in Order Place Management hangling multiple codes and alternate codes for protocols (IHE-J)
  • IHE Japan requests Procedure Scheduled and Procedure update ORM to be replaced with HL7 v2.5 OMI
  • IHE Spain requests Pateint Identifier List definition from HL7 v2.5
  • IHE Spain requests XCN Structure types from HL7 v2.5
  • IHE Spain requests Address Data based on the HL7 v2.5 definition
  • Seperate role for write the order and authorizing or co-signature to order(examples: Medical Student orders procedure- authorized provider must sign, Provider orders procedure but asks for co-signature from another provider)
  • Procedure requires pre certification from insurance before it can be scheduled.
  • Patient with no insurance must sign off on being responsible for paying for the procedure before scheduling
  • Imaging department needs to change ordered procedure and hospital requires the ordering/signing provider to be notified of the change


SWF also has a number of interoperability gaps that need addressing, including:

  • Workflow Triggers: No explicit workflow triggers for ready to view (ER), ready to be read, sufficiently done to bill, etc.
  • Wetread Request: Ordering provider can't request wet reads and set a trigger for when a wet read result is available
  • Change Authority: SWF does not address who authorized cancelling or modifying an order (either at the HL7 level or the DICOM level)
  • MPPS Semantics: MPPS is identified by SWF as meaning end of exam. MPPS only indicates that a procedure step is complete, not the exam.
  • feedback from the order filler is not sufficiently designed to profile the expectations of the clinical environment when placing orders. (lack of procedure granualrity and universal service identifiers)
  • specific clinical data and human intervention to confirm that exam is complet is missing.


The number of options in SWF makes it unnecessarily complex for users trying to order it in products or review Integration Statements.

The options include useful SWF features, but because they were added later it was necessary to document them as options. It would simplify things if an updated profile folded in existing options. Likely examples include:

  • Exception Management Option
  • Patient Information Reconciliation Profile (as was done in Cardiology)
    • Note: IHE-Japan requests PIR to be optional


Patient Administration Management provides a common approach for all domains for patient management. SWF had to include patient management because it wasn't' profiled at the time. The PAM specification differs and improves on the SWF specification. SWF II could reduce variation by factoring out patient management and referencing PAM instead.


SWF is not strictly a Workflow Profile. It includes an implicit Radiology Image content profile. This technically forces all systems claiming SWF to support image transactions, but some systems might not produce images. Factoring out the Image Profile would make SWF II more "egalitarian". This would require a new Image Profile to fill the gap.


Gap Analysis

DICOM needs to be evaluated for the ability to meet the needs for the new transactions listed.

Other DOMAINS need to be notified of the changes we are considering for their feedback. Currently 4 domains are using SWF.

The International Committees need to be invited to review the proposal and provide feedback and support.

Key Use Case

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

  • Simple Case - A patient is registered, an imaging order is placed, a procedure is scheduled, and images are acquired.
  • UnScheduled Case - Images are acquired for an unscheduled procedure.
  • Patient Update Case - Any update to patient information.
  • Appointment Update Case - Any update to the patient's appointment.
  • Order Change Case - Any update to the order where the order is changed except for status change.
  • Abandon Case - Where an order is started, but discontinued. Valid images may have been acquired and work may be billable.
  • Append Case - Additional acquisition procedures steps are performed that were not part of the original order.
  • Group Case - A single procedure performed at the modality for multiple procedures scheduled for the patient.
  • Implicit Post Processing - Post processing on an imaging set implied by the acquisition worklist. Images may be transferred to a separate workstation for post-processing task completion.
  • Relevant Clinical Information Distribution - Critical relevant patient information provided from other EMR systems distributed to every system, including the acquisition modality through Modality Worklist.
  • Results Distribution - Information provided by the Order Placer to the Order Filler for Results Distribution.
  • Multimodality Acquisition - Where an order contains procedure steps for multi-modalities.
  • Intermittently Connected Devices - Where a modality may not be continuously connected to the department information system.
  • Raw Data Management - Image Management, including retention and distribution of raw images.

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

Standards & Systems

HL-7 v2.5.1 (Released)

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.

HL-7 v2.6 (In Ballot)

When will v2.6 be released? What features does it provide? Are they relevant enough to SWF that SWF II should consider them?


HL-7 v2.7 (In Development)


HL-7 v3.x (In Development)

Why HL7 v3.x should or should not be considered so that this can be reviewed.

Regional HL-7 Version Requirements

How will the requirements from other Regions (e.g. Spain and Japan) be taken into consideration?


DICOM

What about Modality Worklist (MWL) and Unified Procedure Step (UPS)?

MWL is well accepted and broadly implemented by the Modalities/DSS/OF. Unless a compelling advantage is found, there is no reason to change to UPS. It might be worth considering if any problems would be created by some niche systems using UPS in addition to MWL.

Technical Approach

Existing Actors

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

ADT - Remove from SWF II The transactions are currently up to HL-7 v 2.5 in PAM. Will include PAM Actors to replace.

DSS/Order Filler - no change or combine to be referred as DSS or Imaging Department Scheduler only

Order Placer - no change

PPS Mgr - Remove with direct from the modality or Leave but require that it must be grouped with either Image Mgr/Image Archive of DSS/Order Filler

Image Display - no change

Evidence Creator - no change

Acquisition Modality - no change

Image Manager/Image Archive - Combine to be referred to as Image Manager only


New Actors

Enterprise System Scheduler - Add to assume the scheduled Item Updates, grouped with Patient Demographics Consumer and grouped with Patient Encounter Consumer.

Patient Demographics Consumer - Add as requirement to be grouped with Order Placer and Department System Scheduler

Patient Encounter Consumer - Add as requirement to be grouped with Order Placer and Department System Scheduler

Existing Transactions

Transactions with HL-7 messaging will need to be re-written. Regional requirements/differences will need to be considered.


RAD-1 Patient Registration - Remove, replace with Patient Identity Feed[ITI-030] and Patient Encounter Feed[ITI-031]

RAD-2 Orders Management - Remove, replace with new RAD-62 Orders Management V2.5 using the specific OMI message.

RAD-3 Order Filler Management - Remove, replace with new RAD-63 Order Filler Management using the specific V2.5 OMI message.

RAD-4 Procedure Scheduled - Remove, replace with new RAD-64. Procedure Schedule using the specific V2.5 OMI message.

RAD-5 Query Modality Worklist - Remove and replace with RAD 65. Need to make the Scheduled and Requested Procedure code sequence required. Relevant Clinical Information needs to be required.

RAD-6 Modality Performed Procedure Step in-Progress and RAD-7 Modality Performed Procedure Step Complete/Discontinued Remove and replace with RAD-66 and RAD-67 to include the assisted protocol option. Technologist performer/provider name and person identifier/s needs to be provided for RAD-67. Discontinuation reason codes must be required for RAD-67.

RAD-8 no change

RAD-9 no change

RAD-10 no change

RAD-11 remove. It is permanently replaced with RAD-49

RAD-12 remove and replace with the the RAD-68 using HL7 v2.5.

RAD-13 procedure update, remove and replace with the RAD-69 using HL-7 V2.5 OMI

RAD-14, RAD 15, RAD 16 and RAD 17 have no workflow trigger for initiating either query. These could be removed and addressed in Reporting workflow. A realisitc option is to provide a study complete message, indicating that images are available. A new transaction is proposed; RAD-X1 Work Item Complete.

RAD-20 and RAD 21 change to required for evidence creator.

RAD-18, RAD-20. RAD-21 and RAD-10 from evidence Creator have no workflow trigger for creating the evidence documents. Currently the workitem is considered implied. This has not been an effective or realistic model. These could be removed and addressed in Post-Processing workflow. A realistic option is to provide a study complete message, indicating that images are available. A new transaction is proposed; RAD-X2 Assign Work Item.

RAD-48 change optionality to required. Change destination actor to Enterprise System Scheduler.

RAD-49 change optionality to required.

New Transactions

New transaction/s identified:

  • Work Item Complete - from the Acquisition Modality to the Order filler. Indicates all work by Technologist with patient is complete. The expectation is that the Technologist has completed all tasks associated with this patient. This will provide the workflow trigger for RAD-14, RAD 15, RAD 16 and RAD 17.
  • Assign Work Item - Work Item pushed to Evidence creator for completion. Workitem is an implicit workitem to be performed as part of the modality procedure step. This will provide for the workflow trigger for the evidence creator to initiate RAD-18, RAD-20. RAD-21 and RAD-10.

New Integration Profiles Needed

Partition Scheduled Workflow (SWF) to remove the ADT transactions and add:

  • Patient Account Management (PAM) - Use existing ITI profile

Other Domains will need to consider which version/s to use.

Breakdown of Tasks that need to be accomplished

<<Technical Committee discussed the possibility of using the Mammography as the test case for the first year implementation of SWFII. This would give an opportunity to see if the implementation will work on a speciality area which has high Clinical Input and determine where to go from there.>>


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

7. PAM Transactions

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

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


Support & Resources

<<It would be really really good if there was some support and/or resources. See Dose Reporting for example.>>


Risks

List any potential risks

Preferably with some ideas or plan on how the risk can be managed


If there are gaps/issues with PAM, will it be possible to make needed changes quickly? Who will do the work? IT or Radiology?

If this is done as a two year project, identifying the gaps in the first year would give IT the most time to react. Rad TC should also approach IT TC as soon as work begins to outline the potential issues. That way IT TC can help/guide and won't be caught off guard by unexpected requests later.

If there are gaps/issues with MPPS, will it be possible to make needed changes quickly?


If we do a multi-year development, will participants lose interest due to "lack of progress/results"? (See Technical Estimates below)


Will SWF II meet the global needs of other IHE Regional groups?

Rad TC will directly solicit input from all regions at the beginning of the development process and inform them how to monitor/participate in the development. Public Comment feedback will also be directly solicited from the regions and they will be encouraged to participate in the public comment resolution meeting.

Currently 4 other IHE Domains use SWF as their base. How do (if we do) make sure that other Domains are aware of the work and have the approriate input.


A risk that there may be items which PAM may have open issue the existing HL& v2.3.1 requirements.


It may be desirable to fold PIR into SWF II rather than having a separate profile. What does that mean to Enterprises using a combination of SWF and SWF II Systems. Will there be a conflict with the Japanese National Extension requirements.

Open Issues

List any open issues

Preferably with answers or opinions from the TC, otherwise they are unknowns.


Should any of the existing SWF Actors be removed (e.g. PPS Manager), Permanently Grouped (e.g. Image Manager/Image Archived), renamed, or added (e.g. from the PAM Profile)?


What is the SWF migration/compatibility strategy for HL7 v2.3.1, v2.5.1, v2.6, v2.7 and V3.x?


Should PIR be folded into SWF 2 or should we create a PIR 2? (PIR 1 would not be compatible with SWF 2)


Does PAM support all the use cases of SWF (e.g. John Doe cases with the order filler and Image Manager)?


Does PAM cover all of the Patient Demographics which need to be covered in SWF II?


Does HL7 v2.5 support all of the elements required to fully support a wet read?


Is there value in having a mechanism to change an order rather than cancel & re-order? If so, when/where would that be allowed?


Which SWF Options should get folded into SWF II, which should be SWF II Options and which go away?


An inconsistency may exist between systems which currently support unscheduled procedures in SWF and the proposed PAM in SWF II. How will these be reconciled? (e.g. use of ADT rather than MRG)


The definition of "Complete" is different at different levels - images from procedure complete (current MPPS), Ready to Read, "Study Complete" - PACCS, "Exam Complete" - RIS. This needs to be clarified and additional triggers may be necessary to provide these statuses (some of the status may require User input).


Should we create a generic Image Profile and factor the image handling requirements out of SWF II?


Do we need a retention flag for RAW DATA. Right now this is handled as a manual process.


What additional triggers are needed for implicit post-processing? (e.g. ordering provide ready to bill.)


HL7 currently includes a signature mode to indicate that an order has been canceled by phone, electronically or by paper, and by whom. Is this a sufficient amount of information? This is a critical feature to include in SWF II.


Still need improved text on what is an order, a study and an exam, and when is each "complete".

Tech Cmte Evaluation

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

Technical Committee review resulted in estimates for three different approaches:

  • 150% Full implementation of SWF II. It is believed that this is a multi-year effort. A major risk with this implementation is that User's have to wait at least 2 years for an implementation (note that as an interim it is recommended that a Whitepaper (or User's Guide) be developed for Mammography Acquisition).
  • 85%/85% Division of SWF II into Order and Acquisition and work through the implementation of each half of SWF II separately. If the Technical Committee works through the Acquisition first, then potentially Mammography would be able to develop the Mammography Acquisition Profile earlier. Note that the risk in this scenario is that dependencies between the Order and the Acquisition pieces will not be realized until too late.
  • 40%/120% Development of the Use Cases for the first year. This would concentrate the User effort in the development of the Profile. (Note from the Mammography Committee perspective this would be most desirable). Additional work could be done to review the HL7 and DICOM standards to determine if any HL7 Standards or DICOM Standards work needs to be done.

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Chris Lindop/Ruth Berge/Tony Palmer
Retrieved from "http://wiki.ihe.net/index.php?title=Scheduled_Workflow_II_-_Detailed_Proposal&oldid=10438"