Scheduled Workflow 2.0 - Detailed Proposal: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Lindop (talk | contribs)
Bureaucrats, editor
854 edits
New page: ==Proposed Profile: Scheduled Workflow II == * Proposal Editor: Chris Lindop/Ruth Berge/Tony Palmer * Date: N/A (Wiki keeps history) * Version: N/A (Wiki keeps history) * Domain: Radi...
 
Lindop (talk | contribs)
Bureaucrats, editor
854 edits
 
(128 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Proposed Profile: Scheduled Workflow II ==
==Proposed Profile: Scheduled Workflow II ==


* Proposal Editor: Chris Lindop/Ruth Berge/Tony Palmer
* Proposal Editor: Chris Lindop
* Date:    N/A (Wiki keeps history)
* Date:    N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
Line 7: Line 7:


===Summary===
===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, IHE Radiology has added several options to make it more operable.  Additionally, some of the early technology did not address all of the interoperability needs due to limitations of the technology.  As such, the level of uptake is not consistent with all actors.   
Scheduled Workflow was introduced over 9 years ago.   


==The Problem==
SWF is based on HL7 v2.3.1.  This version did not support the unique requirements of imaging. IHE overloaded messages and leveraged z-segments to work around the issues with this version.  Since then, HL7 has obsoleted and developed new message types which are more appropriate to imaging.  Implementation of the obsoleted versions is difficult.  The new messages address the limitations that IHE identified in SWF.  A new revision of Scheduled Workflow could address these problems by specifying HL7 V2.5 transactions using the new messages.
 
Current deployment requirements by institutions and governments include the necessity of using the current balloted versions of HL-7.  As SWF is developed with obsolete and overloaded messages, systems compliant with SWF transactions would not be extensible to the newer HL-7 versions.
 
IHE Radiology and Cardiology have added several workflow profile options that make it more difficult to analyze interoperability compatibility between systems.  The need for many of the options is for backward compatibility.  By creating a new profile and folding the needed options in, we address the need to simplify the compatibility and increase overall reliability.
 
Uptake of some of the actors are better than others.  Some of the rationale is product architecture.  An example of product architecture limitations is managing workflow to the procedure step level.  Many system architectures 9 years ago could not support this granularity.  This has changed over time.  But with this change, implementors have begun to encounter gaps.  Three specific gaps are addressed here. 


SWF is based on HL7 v2.3.1. The current balloted version is HL7 v2.5.1.  SWF is the most widely deployed IHE Integration Profile. For health care providers who have already deployed systems based on IHE SWF, '''SWF is a roadblock for deployment of the current HL7 version'''.  
The first is accountability of who is the person who is actually acquiring the images. This is required for patient information privacy and billing.


The second issue is, while PPS can handle the imaging and evidence information acquisition quite well, what about the acquisition resource itself?  If, for example, a technologist is reviewing the images for Quality assurance while the patient is still on the table, how will the department system scheduler know?  It may have received the MPPS a while ago. 


IHE National Committees have identified their deployment need to use HL7 v2.5.1.
Third issue is clarification on the usage of the append workflow.  While MPPS does tell when a procedure step is complete, SWF does allow for an exception to the completion state.  This is through the use of the append use case. There is no "reasons why" included in the status message of the MPPS. Was it because of "image quality?"  Was it because of "incorrect completion of procedure step?"  There needs to be a reason code for why a procedure step is being appended.


:'''IHE-Spain''' has submitted a National Extension which makes use of the PID definition provided in the HL7 v2.5 definition.  This version of HL7 v2.5 better meets the requirements for dealing with Names (multiple surnames) and Identifiers associated with Patients, Physicians, etc.
==The Problem==
===HL-7 Technology Upgrade===
====Obsolete Transactions====
'''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.


:'''IHE-Japan''' has submitted a National Extension which makes extensive use of the new Order Segments (including: OMG, ORG and TQ1).  Japan would prefer to make use of the latest HL7 v2.5 as it provides better organization for the information they require.
'''Obsolete Messaging for Placer Order Management'''
* SWF requires support of the obsolete ORM in order to perform the Order Placer transaction RAD-2. This message is obsolete and replaced with the OMG message.  The OMG message is much more robust and is capable of supporting coded terminology for Order detail.  Currently Order Detail partially handled using overloaded fields.  IHE specifies Laterality to overload the Specimen Field.


:As part of the '''United States standards harmonization initiative''', HHS plans to require that all Government contracts use HL7 v2.5 or higher.
'''Obsolete Messaging for Filler Order Management'''
* SWF requires support of the obsolete ORM in order to perform the Order Filler transaction RAD-3. This message is obsolete and replaced with the OMG message.  The OMG message is much more robust and is capable of supporting coded terminology for Order detail.  Currently Order Detail partially handled using overloaded fields. IHE specifies Laterality to overload the Specimen Field.


SWF is a roadblock for regions to deploy version 2.5.1.  
'''Overloaded Message for Procedure Scheduled and Procedure Update'''
* SWF requires support of ORM in order to perform the Order Filler transactions RAD-4 and RAD-13 to notify the PACS of the procedure steps scheduled. The PACS would receive multiple RAD-4 messages for a requested procedure to communicate each procedure step scheduled. This is certainly complex and not the intended use for this message.  HL7 v 2.5.1 added the OMI message for this purpose.  The legacy ORM message includes overloaded fields, User-specified fields, one-to-one mapping from order to procedures step, and Z-segments.  All of these fields are properly supported in the HL7 OMI standard without modification.  


====HL-7 Enhanced Support====
'''Patient Administration Management'''
* 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 regarding patient management. 
** PAM effectively replaces SWF transaction RAD-1 and PIR transaction RAD-12.


Some '''new systems in development''' are utilizing '''HL-7 v2.5.1'''. 
'''Japan Support needed for Master Codes'''
* Some may choose to still support SWF.  This provides compatibility with the installed base and gives them a profile to claim, but requires implementing v2.3.1 messaging and if they want to support equivalent capability in the HL7 2.3.1 version it requires extensive remapping of the unprofiled v2.5.1 features.
* Support for Master Codes: New ORC segment may now include the JJ1017 Code (Japanese master code for Radiology.) Currently, IHE uses overloaded fields in HL-7 for this information.
* For others, compatibility with the installed base may be less of an issue and the dual development costs are significant, but without SWF II they have no profile to serve as a basis for claiming compatibility.


'''Enhanced Workflow'''
* Support for the enhanced workflow described in the SWF Wite Paper is enabled by HL7 v2.5 capabilities.  SWF will need to adopt the HL7 v2.5.1 in order to be extensible to the workflows described there.


Some specific features relevant to SWF that are '''lacking in 2.3.1''' include:
===MPPS Enhancements===
* '''Order Granularity''': the ability to specify procedure details is limited
====Enhanced Workflow for Order Filler====
** e.g. in an order for a 2-view chest, it is not possible to specify the view to include decubitus
'''Appending Procedure Steps, Exception Management'''  
** ORC segment may include the JJ1017 Code (Japanese master code for Radiology)
* MPPS is effective for managing procedure steps most of the time. The Image Manager and RIS both know what has been scheduled and the modality will complete them. One exception is the an append case.  Currently, there is nothing in MPPS to notify why a procedure step is being appended. Is it because of an error in the previous completion reporting or is it because of a re-take due to bad images?  This information is not known.
** V2.5.1 provides increased Order Granularity in the fields added to the OBR in v2.4


* '''Authorization Mode''': there is no way to indicate how an order change/cancellation was approved.
'''Completing the Procedure Step (between the modality and the Order Filler)'''  
** Hospital policy may require the signing provider to approve it when Imaging department needs to change ordered procedure
* SWF does not require the modality to identify who actually is performing the procedure step at the modality.  This information is required for accountability and access to patient information.  It is also needed for billing.  Today many sites will have a RIS terminal in the suite where the operator manually "completes" the procedure step with the operator identified .  It would be better if the tech automatically completed it on the modality without the extra manual step on the RIS.
** V2.5 added a field to specify the entering users authorization mode in the ORC
* Additional need for completing the procedure step include:
:# Narrative text providing stronger text on the usage of MPPS procedure step Status in-progress/complete with regard to using the append use case.


* '''Result Study UID''': ORR can't normally provide the Study UID to reference.
'''Resource Ready for next Patient'''
** SWF added a custom ZDS Segment to handle Study Instance UID in Transactions RAD-4 and RAD-13 v2.5 formally defines it in the OMI
* MPPS is effective for managing information acquired during a procedure step.  The Image Manager and RIS both know what has been scheduled and the modality will identify what the clinically relevant information acquired with each procedure step.  However, it does not notify the scheduler when the resource is actually available for the next patient. For example, if the technologist is reviewing the images for quality while the patient is on the table, there is no notification method to inform the scheduler when the patient is off the table and release.  
:# Usage of a PPS event, Discharge Patient from Department, as documented in CP932, could be used for asset utilization management.


===SWF Options Rationalization===


SWF also has a number of '''interoperability gaps''' that need addressing, including:
'''Intermittently Connected Devices'''
* '''Implicit post processing Workflow''': No explicit workflow trigger is identified for an evidence creator to initiate their post-processing of an image set that is implicitly required in the worklist item selected on the modality.  
* Intermittently Connected Devices, part of Cardiology's Echo Workflow, is equally important to Radiology. Should be part of SWF for mobile devices support.
* '''Wetread Workflow''': 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 the authority of the person cancelling or modifying an order (either at the HL7 level or the DICOM level)
* '''Study Complete''': MPPS is identified by SWF as meaning end of exam or study complete.  MPPS only indicates that a procedure step is complete, not the exam or study. There is a need for knowing when the complete is study and available for viewing or reading. 
* '''Intermittently Connected Devices''': IHE Cardiology supplemented Scheduled Workflow to address ultrasound systems that disconnect from the network while moving around the hospital but need to remain "integrated".  Radiology needs to address the same issue.


'''Multi-modality Study'''
*  Multi-modality study, part of Cardiology's Cath Workflow, is equally important to Radiology.  Should be part of SWF for multi-modality support.


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:
'''Image Deletion for Quality reasons'''
* '''Exception Management Option'''
* The Image Deletion for quality reasons, developed in MAWF, should also be included in PIR, allowing for image removal for Quality reasons.
* '''Assisted Protocol Option'''


'''SWF Options Review with SWF 2.0'''
* Several SWF Options, developed after the original SWF could now be made requirements for all participating actors.
** PPS Exception Management
** Availability of PPS Referenced Instances
** Instance Availability Notification
** Assisted Protocol Selection
** Evidence Creator - MPPS


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.
===Enabling Enhanced Image Distribution with CP 800===
*SWF assumes a tightly coupled environment between the actors.  Each actor has only one instance.  Leveraging CP800 will enhance interoperability of distributing of images between patient domains workflow by utilizing CP 800 to transform locally unique Identifiers to globally unique.  This is very important when images are distributed between facilities.


==Key Use Case==
==Key Use Case==


This Integration profile leverages the same use cases as scheduled workflow.
The SWF II white paper has identified several use cases that are not addressed by SWF but could be useful to address.  The core of this profile proposal is not to add additional use cases that are already captured in SWF and Cardiology, but to enhance the current SWF technology to be extensible to the uses cases describe in the white paper.  If time permits, address the new use cases.


* '''Simple Case''' - A patient is registered, an imaging order is placed, a procedure is scheduled, and images are acquired.
* '''Un-Scheduled 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.


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


==Standards & Systems==
==Standards & Systems==
'''HL-7 v2.3.1 (Released)'''
:This is the version currently profiled in Scheduled Workflow and implemented by compliant systems.
'''HL-7 v2.5.1 (Released)'''
'''HL-7 v2.5.1 (Released)'''
:HL-7 v 2.5.1 is the most currently balloted and 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 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  (In Ballot)'''
'''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.
:The initial assessment by the Rad TC is that v2.6 has no additional features useful or relevant to SWF II.


Line 97: Line 108:


'''Regional HL-7 Version Requirements'''
'''Regional HL-7 Version Requirements'''
:''see strawman process described in open issues section
:''see straw man process described in open issues section




'''DICOM'''
'''DICOM'''


==Technical Approach==
==5. Technical Approach==
 
Create a new profile that incorporates the changes described.
 
Keep the old profile on the books for legacy systems.


===Existing Actors===
===Existing Actors===
All existing actors in the Current Scheduled Workflow Integration Profile will be included in this effort with the exception of:


:Remove from SWF II
'''ADT'''
'''DSS'''
'''ADT'''
'''Image Archive'''
'''MPPS Manager'''
'''Image Display'''
''Remove the following option:''


''Remove the following option:''
'''Order Placer'''  
* Departmental Appointment Notification


'''Order Filler'''


'''Evidence Creator'''  
'''Evidence Creator'''  


''Change Optionality to Manadatory the following Option:''
'''Acquisition Modality'''  


* Creator Performed Procedure Step
'''Image Manager'''
* PPS Exception Management
 
===New Actors===


'''Acquisition Modality'''
None proposed.


''Change Optionality to Manadatory the following Option:''
===Existing Transactions===
* Assisted Acquisition Protocol Setting
* PPS Exception Management


''No Change to the following Options:''
The following changes are proposed for each transaction:
* Patient Based Worklist Query
* Broad Worklist Query
* Modality Group Case


'''Image Manager/Image Archive'''
*'''RAD-1 Patient Registration''' - Replace, 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 OMG message.
*'''RAD-4 Procedure Scheduled''' - Replace with Enhanced Procedure Scheduled using the specific V2.5 OMI message.
*'''RAD-5 Query Modality Work list''' - 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''' - Retire, it's covered by Instance Availability Notification
*'''RAD-12 Patient Update''' - Replace, 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 Work list''' - Do not include.  reporting workflow not included
*'''RAD-48 Appointment Notification''' - no change
*'''RAD-50 Instance Availability Notification''' - no change.


Permantly combine Image Manager and Image Archive, propose to be referred to as Image Manager only
===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 OMG 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 Acquisition Complete''' - New Transaction to identify when the operator releases the equipment and is ready for new patient.


''Change Optionality to Manadatory the following Option:''
===Impact on existing integration profiles===
* Availability of PPS-Referenced Instances
Scheduled Workflow and Patient Information Reconciliation Profiles are not impacted.  They will become obsolete in the future by this and other profiles.
* PPS Exception Management
* Performed Work Status Update - Receive


===New Actors===
===Breakdown of tasks that need to be accomplished===
:# Create new profile referencing as much of the existing SWF and PIR profiles as necessary.
:# Port the transactions,  RAD-2, RAD-3, RAD-4 and RAD-13 from HL7 v2.3.1 to current HL7 v2.5.1/2.6 with new transactions RAD-x2, RAD-x3, RAD-x4 and RAD-x13.
:# Fold-in existing Cardiology multi-modality and intermittently connected devices options and the MAWF Deletion Request.
:# Include text in Volume 1 to factor out transactions RAD-1 and Rad-12 and add PAM as a dependency or required grouping.
:# Develop new "Resource Ready for Next Patient" Message mechanisms with the corresponding DICOM CP
:# Develop MPPS Enhancements
:# Rationalize existing SWF and PIR Options, decide which to fold-in/make mandatory.
:# Develop capability for enabling distributed image management with CP800.


===Existing Transactions===


The following changes are proposed for each tranaction:
Extra Credit
*Included profile text to address the additional uses cases documented in the 2007-2008 SWF II White Paper.


'''RAD-1 Patient Registration''' - Remove
Note:
'''RAD-2 Orders Management''' - Remove, replace with new RAD-x+1 Orders Management V2.5 using the specific OMG message.   Note that this message complies with the IHE-Japan request to include the ORC segment to include the JJ1017 Code (Japanese master code for Radiology)
*Essential work elements of this profile are items 2 and 6.
*Key new development tasks are 5, 6 and 8.


'''RAD-3 Order Filler Management''' - Remove, replace with new RAD-X+2 Order Filler Management using the specific V2.5 OMI message.
==Support & Resources==


'''RAD-4 Procedure Scheduled''' - Remove, replace with new RAD-x+3.  Procedure Schedule using the specific V2.5 OMI message.
* GE Healthcare
** Ruth Berge
* 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.


===New Transactions===
==Risks==
''New transaction/s identified:''


===New Integration Profiles Needed===
There may not be enough added value for vendors to implement/users to upgrade.
: ''SWF uses obsolete messages. Many institutions and governments now require HL7 v2.5 or greater, making conformance to SWF not possible.  SWF 2.0 gives the vendors a path for upgrade without obsoleting their current capabilities.''
: ''SWF is not compliant with many institutions and government organizations today with the obsolete 2.3.1 messaging.  Hence, SWF will become obsolete if this trend continues.


Create '''Scheduled Workflow II'''.
Conveying operator identity may provide minimal benefit if the values/codes are not synchronized across the organization.
: ''This is a deployment issue.  An implementer might call a dependency on PWP or other IT technique''


Partition Scheduled Workflow (SWF) to remove the ADT transactions and add:
There may be confusion/knock-on effect to other domains which further profiled SWF. 
:* Patient Account Management (PAM) - Use existing ITI profile
: ''SWF will not be obsoleted without consultation with dependent domains.''


Domains outside of Radiology will need to consider which version/s of SWF to use.
Feature creep.


==Open Issues==


Issue: Should the TF text use HL7 V2.6 or 2.5.1
: ''2.6 is the newest balloted and we are required by HL-7 MOU to use the most current balloted version.  In the context of SWF, 2.5.1 adds required capabilities over 2.3.1, where 2.6 doesn't add anything useful over 2.5.1 in context of SWF.  If we choose to use the most current balloted version that adds something useful, we can identify the lowest interoperable standard, and allow deployment sites, who may have version restrictions to analyze compatibility more easily.''


==Support & Resources==
Issue: Should we eliminate the PPS Mgr and just assign it to the Order Filler?
The resource needs for this profile are high.  It is important to obtain commitment of resources from the National Committees, the Radiology Subcomittees and other Domain Committees who would benefit from a new SWF.
: ''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.''
: ''Propose to elliminate MPPS manager for SWF II, but neccessary for mixed environments.''


The Japan and Spain National Committees both have expressed interest in seeing SWF updated to HL7 v2.5.
Issue: Should we extract image display behaviors from Retrieve 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.).  ''


The Mammography Subcommittee 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.
Issue: Should we add a new Actor, "Enterprise Scheduler" to more appropriately manage the Appointment Notification transaction?
: ''Enterprise scheduling is a gap.  Order Placer is not intended to be the Enterprise Scheduler.  We could clean it up.  Or we could decide to leave it a gap and maintain it's optionality 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.
: ''SWF needs to be maintained as is for Legacy and cross-domain usage for now.''


Issue:  Mixed environments.  Will SWF II be capmpatible in mixed environments with SWF?
:  ''This analysis can be performed as part of the workitem.  Ideally, they should be comaptible with some limitations


==Tech Cmte Evaluation==
==Tech Cmte Evaluation==
Candidate Editor:
 
: Chris Lindop(Lead Editor)/Ruth Berge/Tony Palmer
Effort Evaluation (as a % of Tech Cmte Bandwidth):
: 40%
Responses to Issues:
:''See italics in Risk and Open Issue sections''
 
Candidate Editors:
: Chris Lindop
: Ruth Berge
: Ellie Avraham
 
[[Radiology_Proposals_2009-2010]]

Latest revision as of 12:15, 15 October 2009

Proposed Profile: Scheduled Workflow II

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

Summary

Scheduled Workflow was introduced over 9 years ago.

SWF is based on HL7 v2.3.1. This version did not support the unique requirements of imaging. IHE overloaded messages and leveraged z-segments to work around the issues with this version. Since then, HL7 has obsoleted and developed new message types which are more appropriate to imaging. Implementation of the obsoleted versions is difficult. The new messages address the limitations that IHE identified in SWF. A new revision of Scheduled Workflow could address these problems by specifying HL7 V2.5 transactions using the new messages.

Current deployment requirements by institutions and governments include the necessity of using the current balloted versions of HL-7. As SWF is developed with obsolete and overloaded messages, systems compliant with SWF transactions would not be extensible to the newer HL-7 versions.

IHE Radiology and Cardiology have added several workflow profile options that make it more difficult to analyze interoperability compatibility between systems. The need for many of the options is for backward compatibility. By creating a new profile and folding the needed options in, we address the need to simplify the compatibility and increase overall reliability.

Uptake of some of the actors are better than others. Some of the rationale is product architecture. An example of product architecture limitations is managing workflow to the procedure step level. Many system architectures 9 years ago could not support this granularity. This has changed over time. But with this change, implementors have begun to encounter gaps. Three specific gaps are addressed here.

The first is accountability of who is the person who is actually acquiring the images. This is required for patient information privacy and billing.

The second issue is, while PPS can handle the imaging and evidence information acquisition quite well, what about the acquisition resource itself? If, for example, a technologist is reviewing the images for Quality assurance while the patient is still on the table, how will the department system scheduler know? It may have received the MPPS a while ago.

Third issue is clarification on the usage of the append workflow. While MPPS does tell when a procedure step is complete, SWF does allow for an exception to the completion state. This is through the use of the append use case. There is no "reasons why" included in the status message of the MPPS. Was it because of "image quality?" Was it because of "incorrect completion of procedure step?" There needs to be a reason code for why a procedure step is being appended.

The Problem

HL-7 Technology Upgrade

Obsolete Transactions

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 Placer Order Management

  • SWF requires support of the obsolete ORM in order to perform the Order Placer transaction RAD-2. This message is obsolete and replaced with the OMG message. The OMG message is much more robust and is capable of supporting coded terminology for Order detail. Currently Order Detail partially handled using overloaded fields. IHE specifies Laterality to overload the Specimen Field.

Obsolete Messaging for Filler Order Management

  • SWF requires support of the obsolete ORM in order to perform the Order Filler transaction RAD-3. This message is obsolete and replaced with the OMG message. The OMG message is much more robust and is capable of supporting coded terminology for Order detail. Currently Order Detail partially handled using overloaded fields. IHE specifies Laterality to overload the Specimen Field.

Overloaded Message for Procedure Scheduled and Procedure Update

  • SWF requires support of ORM in order to perform the Order Filler transactions RAD-4 and RAD-13 to notify the PACS of the procedure steps scheduled. The PACS would receive multiple RAD-4 messages for a requested procedure to communicate each procedure step scheduled. This is certainly complex and not the intended use for this message. HL7 v 2.5.1 added the OMI message for this purpose. The legacy ORM message includes overloaded fields, User-specified fields, one-to-one mapping from order to procedures step, and Z-segments. All of these fields are properly supported in the HL7 OMI standard without modification.

HL-7 Enhanced Support

Patient Administration Management

  • 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 regarding patient management.
    • PAM effectively replaces SWF transaction RAD-1 and PIR transaction RAD-12.

Japan Support needed for Master Codes

  • Support for Master Codes: New ORC segment may now include the JJ1017 Code (Japanese master code for Radiology.) Currently, IHE uses overloaded fields in HL-7 for this information.

Enhanced Workflow

  • Support for the enhanced workflow described in the SWF Wite Paper is enabled by HL7 v2.5 capabilities. SWF will need to adopt the HL7 v2.5.1 in order to be extensible to the workflows described there.

MPPS Enhancements

Enhanced Workflow for Order Filler

Appending Procedure Steps, Exception Management

  • MPPS is effective for managing procedure steps most of the time. The Image Manager and RIS both know what has been scheduled and the modality will complete them. One exception is the an append case. Currently, there is nothing in MPPS to notify why a procedure step is being appended. Is it because of an error in the previous completion reporting or is it because of a re-take due to bad images? This information is not known.

Completing the Procedure Step (between the modality and the Order Filler)

  • SWF does not require the modality to identify who actually is performing the procedure step at the modality. This information is required for accountability and access to patient information. It is also needed for billing. Today many sites will have a RIS terminal in the suite where the operator manually "completes" the procedure step with the operator identified . It would be better if the tech automatically completed it on the modality without the extra manual step on the RIS.
  • Additional need for completing the procedure step include:
  1. Narrative text providing stronger text on the usage of MPPS procedure step Status in-progress/complete with regard to using the append use case.

Resource Ready for next Patient

  • MPPS is effective for managing information acquired during a procedure step. The Image Manager and RIS both know what has been scheduled and the modality will identify what the clinically relevant information acquired with each procedure step. However, it does not notify the scheduler when the resource is actually available for the next patient. For example, if the technologist is reviewing the images for quality while the patient is on the table, there is no notification method to inform the scheduler when the patient is off the table and release.
  1. Usage of a PPS event, Discharge Patient from Department, as documented in CP932, could be used for asset utilization management.

SWF Options Rationalization

Intermittently Connected Devices

  • Intermittently Connected Devices, part of Cardiology's Echo Workflow, is equally important to Radiology. Should be part of SWF for mobile devices support.

Multi-modality Study

  • Multi-modality study, part of Cardiology's Cath Workflow, is equally important to Radiology. Should be part of SWF for multi-modality support.

Image Deletion for Quality reasons

  • The Image Deletion for quality reasons, developed in MAWF, should also be included in PIR, allowing for image removal for Quality reasons.

SWF Options Review with SWF 2.0

  • Several SWF Options, developed after the original SWF could now be made requirements for all participating actors.
    • PPS Exception Management
    • Availability of PPS Referenced Instances
    • Instance Availability Notification
    • Assisted Protocol Selection
    • Evidence Creator - MPPS

Enabling Enhanced Image Distribution with CP 800

  • SWF assumes a tightly coupled environment between the actors. Each actor has only one instance. Leveraging CP800 will enhance interoperability of distributing of images between patient domains workflow by utilizing CP 800 to transform locally unique Identifiers to globally unique. This is very important when images are distributed between facilities.

Key Use Case

The SWF II white paper has identified several use cases that are not addressed by SWF but could be useful to address. The core of this profile proposal is not to add additional use cases that are already captured in SWF and Cardiology, but to enhance the current SWF technology to be extensible to the uses cases describe in the white paper. If time permits, address the new use cases.


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 straw man process described in open issues section


DICOM

5. Technical Approach

Create a new profile that incorporates the changes described.

Keep the old profile on the books for legacy systems.

Existing Actors

ADT

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 - Replace, 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 OMG message.
  • RAD-4 Procedure Scheduled - Replace with Enhanced Procedure Scheduled using the specific V2.5 OMI message.
  • RAD-5 Query Modality Work list - 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 - Retire, it's covered by Instance Availability Notification
  • RAD-12 Patient Update - Replace, 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 Work list - Do not include. reporting workflow not included
  • RAD-48 Appointment Notification - no change
  • 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 OMG 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 Acquisition Complete - New Transaction to identify when the operator releases the equipment and is ready for new patient.

Impact on existing integration profiles

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

Breakdown of tasks that need to be accomplished

  1. Create new profile referencing as much of the existing SWF and PIR profiles as necessary.
  2. Port the transactions, RAD-2, RAD-3, RAD-4 and RAD-13 from HL7 v2.3.1 to current HL7 v2.5.1/2.6 with new transactions RAD-x2, RAD-x3, RAD-x4 and RAD-x13.
  3. Fold-in existing Cardiology multi-modality and intermittently connected devices options and the MAWF Deletion Request.
  4. Include text in Volume 1 to factor out transactions RAD-1 and Rad-12 and add PAM as a dependency or required grouping.
  5. Develop new "Resource Ready for Next Patient" Message mechanisms with the corresponding DICOM CP
  6. Develop MPPS Enhancements
  7. Rationalize existing SWF and PIR Options, decide which to fold-in/make mandatory.
  8. Develop capability for enabling distributed image management with CP800.


Extra Credit

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

Note:

  • Essential work elements of this profile are items 2 and 6.
  • Key new development tasks are 5, 6 and 8.

Support & Resources

  • GE Healthcare
    • Ruth Berge
  • 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.

SWF uses obsolete messages. Many institutions and governments now require HL7 v2.5 or greater, making conformance to SWF not possible. SWF 2.0 gives the vendors a path for upgrade without obsoleting their current capabilities.
SWF is not compliant with many institutions and government organizations today with the obsolete 2.3.1 messaging. Hence, SWF will become obsolete if this trend continues.

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

This is a deployment issue. An implementer 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 dependent domains.

Feature creep.

Open Issues

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

2.6 is the newest balloted and we are required by HL-7 MOU to use the most current balloted version. In the context of SWF, 2.5.1 adds required capabilities over 2.3.1, where 2.6 doesn't add anything useful over 2.5.1 in context of SWF. If we choose to use the most current balloted version that adds something useful, we can identify the lowest interoperable standard, and allow deployment sites, who may have version restrictions to analyze compatibility more easily.

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.
Propose to elliminate MPPS manager for SWF II, but neccessary for mixed environments.

Issue: Should we extract image display behaviors from Retrieve 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 we add a new Actor, "Enterprise Scheduler" to more appropriately manage the Appointment Notification transaction?

Enterprise scheduling is a gap. Order Placer is not intended to be the Enterprise Scheduler. We could clean it up. Or we could decide to leave it a gap and maintain it's optionality 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.

SWF needs to be maintained as is for Legacy and cross-domain usage for now.

Issue: Mixed environments. Will SWF II be capmpatible in mixed environments with SWF?

This analysis can be performed as part of the workitem. Ideally, they should be comaptible with some limitations

Tech Cmte Evaluation

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

40%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editors:

Chris Lindop
Ruth Berge
Ellie Avraham

Radiology_Proposals_2009-2010

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