Difference between revisions of "Scheduled Workflow II Phase 2 - Brief Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
==1. Proposed Workitem: ''<initial working name for profile/whitepaper/etc>''==
+
==Proposed Profile: Scheduled Workflow II ==
  
−
* Proposal Editor: ''<Name of author/editor/contact for the proposal>''
+
* Proposal Editor: Chris Lindop/Ruth Berge/Tony Palmer
−
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''
 
 
* Date:    N/A (Wiki keeps history)
 
* Date:    N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
−
* Domain: ''<Domain name (e.g. Radiology)>''
+
* Domain: Radiology
−
<nowiki> remove this tag
 
−
[[Category:DomainAbbreviation]]
 
−
</nowiki> remove this tag too
 
  
−
==2. The Problem==
+
===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. 
  
−
''<Summarize the integration problem. What doesn’t work, or what needs to work.>''
+
==The Problem==
  
 +
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'''.
  
−
==3. Key Use Case==
 
  
−
''<Describe a short use case scenario from the user perspective.  The use case should demonstrate the integration/workflow problem.>''
+
IHE National Committees have identified their deployment need to use HL7 v2.5.1.   
  
−
''<Feel free to add a second use case scenario demonstrating how it “should” work.  Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.>''
+
:'''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.
  
 +
:'''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.
  
−
==4. Standards & Systems==
+
:As part of the '''United States standards harmonization initiative''', HHS plans to require that all Government contracts use HL7 v2.5 or higher.
  
−
''<List existing systems that are/could be involved in the problem/solution.>''
+
SWF is a roadblock for regions to deploy version 2.5.1.  
  
−
''<If known, list standards which might be relevant to the solution>''
 
  
 +
Some '''new systems in development''' are utilizing '''HL-7 v2.5.1'''. 
 +
* 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.
 +
* 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.
  
−
==5. Discussion==
 
  
−
''<Include additional discussion or consider a few details which might be useful for the detailed proposal>''
+
Some specific features relevant to SWF that are '''lacking in 2.3.1''' include:
−
:''<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>''
+
* '''Order Granularity''': the ability to specify procedure details is limited
−
:''<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>''
+
** e.g. in an order for a 2-view chest, it is not possible to specify the view to include decubitus
−
:''<What are some of the risks or open issues to be addressed?>''
+
** ORC segment may include the JJ1017 Code (Japanese master code for Radiology)
 +
** 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.
 +
** Hospital policy may require the signing provider to approve it when Imaging department needs to change ordered procedure
 +
** V2.5 added a field to specify the entering users authorization mode in the ORC
  
−
''<This is the brief proposal.  Try to keep it to 1 or at most 2 pages>''
+
* '''Result Study UID''':  ORR can't 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 v2.5 formally defines it in the OMI
  
  
−
''<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>'' [[Category:Templates]]
+
SWF also has a number of '''interoperability gaps''' that need addressing, including:
 +
* '''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. 
 +
* '''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.
 +
 
 +
 
 +
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'''
 +
* '''Assisted Protocol Option'''
 +
 
 +
 
 +
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.
 +
 
 +
==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.
 +
* '''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==
 +
'''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 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 v2.6  (In Ballot)'''
 +
: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'''
 +
 
 +
==Technical Approach==
 +
 
 +
===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
 +
'''DSS'''
 +
'''ADT'''
 +
'''Image Archive'''
 +
'''MPPS Manager'''
 +
'''Image Display'''
 +
''Remove the following option:''
 +
 
 +
''Remove the following option:''
 +
* Departmental Appointment Notification
 +
 
 +
 
 +
'''Evidence Creator'''
 +
 
 +
''Change Optionality to Manadatory the following Option:''
 +
 
 +
* Creator Performed Procedure Step
 +
* PPS Exception Management
 +
 
 +
'''Acquisition Modality'''
 +
 
 +
''Change Optionality to Manadatory the following Option:''
 +
* Assisted Acquisition Protocol Setting
 +
* PPS Exception Management
 +
 
 +
''No Change to the following Options:''
 +
* Patient Based Worklist Query
 +
* Broad Worklist Query
 +
* Modality Group Case
 +
 
 +
'''Image Manager/Image Archive'''
 +
 
 +
Permantly combine Image Manager and Image Archive, propose to be referred to as Image Manager only
 +
 
 +
''Change Optionality to Manadatory the following Option:''
 +
* Availability of PPS-Referenced Instances
 +
* PPS Exception Management
 +
* Performed Work Status Update - Receive
 +
 
 +
===New Actors===
 +
 
 +
===Existing Transactions===
 +
 
 +
The following changes are proposed for each tranaction:
 +
 
 +
'''RAD-1 Patient Registration''' - Remove
 +
'''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)
 +
 
 +
'''RAD-3 Order Filler Management''' - Remove, replace with new RAD-X+2 Order Filler Management using the specific V2.5 OMI message.
 +
 
 +
'''RAD-4 Procedure Scheduled''' - Remove, replace with new RAD-x+3.  Procedure Schedule using the specific V2.5 OMI message.
 +
 
 +
===New Transactions===
 +
''New transaction/s identified:''
 +
 
 +
===New Integration Profiles Needed===
 +
 
 +
Create '''Scheduled Workflow II'''.
 +
 
 +
Partition Scheduled Workflow (SWF) to remove the ADT transactions and add:
 +
:* Patient Account Management (PAM) - Use existing ITI profile
 +
 
 +
Domains outside of Radiology will need to consider which version/s of SWF to use.
 +
 
 +
 
 +
 
 +
==Support & Resources==
 +
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.
 +
 
 +
The Japan and Spain National Committees both have expressed interest in seeing SWF updated to HL7 v2.5.
 +
 
 +
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.
 +
 
 +
 
 +
 
 +
==Tech Cmte Evaluation==
 +
Candidate Editor:
 +
: Chris Lindop(Lead Editor)/Ruth Berge/Tony Palmer

Latest revision as of 17:52, 15 September 2008

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

The Problem

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.


IHE National Committees have identified their deployment need to use HL7 v2.5.1.

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.
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.
As part of the United States standards harmonization initiative, HHS plans to require that all Government contracts use HL7 v2.5 or higher.

SWF is a roadblock for regions to deploy version 2.5.1.


Some new systems in development are utilizing HL-7 v2.5.1.

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


Some 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
    • ORC segment may include the JJ1017 Code (Japanese master code for Radiology)
    • 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.
    • Hospital policy may require the signing provider to approve it when Imaging department needs to change ordered procedure
    • V2.5 added a field to specify the entering users authorization mode in the ORC
  • Result Study UID: ORR can't 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 v2.5 formally defines it in the OMI


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

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


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
  • Assisted Protocol Option


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.

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

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 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 v2.6 (In Ballot)

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

Technical Approach

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

DSS ADT Image Archive MPPS Manager Image Display Remove the following option:

Remove the following option:

  • Departmental Appointment Notification


Evidence Creator

Change Optionality to Manadatory the following Option:

  • Creator Performed Procedure Step
  • PPS Exception Management

Acquisition Modality

Change Optionality to Manadatory the following Option:

  • Assisted Acquisition Protocol Setting
  • PPS Exception Management

No Change to the following Options:

  • Patient Based Worklist Query
  • Broad Worklist Query
  • Modality Group Case

Image Manager/Image Archive

Permantly combine Image Manager and Image Archive, propose to be referred to as Image Manager only

Change Optionality to Manadatory the following Option:

  • Availability of PPS-Referenced Instances
  • PPS Exception Management
  • Performed Work Status Update - Receive

New Actors

Existing Transactions

The following changes are proposed for each tranaction:

RAD-1 Patient Registration - Remove 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)

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

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

New Transactions

New transaction/s identified:

New Integration Profiles Needed

Create Scheduled Workflow II.

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

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

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


Support & Resources

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.

The Japan and Spain National Committees both have expressed interest in seeing SWF updated to HL7 v2.5.

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.


Tech Cmte Evaluation

Candidate Editor:

Chris Lindop(Lead Editor)/Ruth Berge/Tony Palmer
Retrieved from "http://wiki.ihe.net/index.php?title=Scheduled_Workflow_II_Phase_2_-_Brief_Proposal&oldid=23578"