Scheduled Workflow II - Detailed Proposal

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

The Scheduled Workflow Profile dictates that changes to a procedure must be made by cancelling the order and entering a new order. This workflow causes problems for healthcare systems that need continuity between the two orders and need authorization for some changes.

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 replacement profile for Scheduled Workflow is in order. The replacement is called Radiology Acquisition Workflow since it doesn't cover scheduling of the procedure.

The Problem

SWF does not allow modification of a requested procedure.

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. It is expected that this requirement will go into effect in December 2007.

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

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

• More Fields: There are likely useful things which can be done with fields added after v2.3.1
  • ORC has been extended to field 31 (in v2.5.1); SWF only uses up to field 19
  • OBR has been extended to field 50 (in v2.5.1); SWF only uses up to field 45

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.
• Advanced Beneficiary Notice: Some states require patient consent to pay for an imaging procedure before it is performed
  • Although available in v2.3.1, the advanced beneficiary code was not mentioned in SWF

• Additional issues are believed to exist between the order placer, the HIS and the filler that should be identified and addressed.

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 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 content profile; Radiology Image Content Profile. This technically forces all systems claiming SWF to support the implicit Radiology Image Content Profile, but some systems might not produce radiology images. Factoring out the Radiology Image Content Profile would make SWF II more "egalitarian for other imaging departments". This would require a new Radiology Image Profile to fill the gap.

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.
• Raw Data Handling - including retention and distribution of raw images and notes.

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

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

Note: IHE Japan would prefer that only the A08 Event be required.

DSS/Order Filler

Refer to as Order Filler only?

Change Optionality to Mandatory the following Options:

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

Remove the following option:

• Image Availability

Order Placer

No change.

Remove the following option:

• Departmental Appointment Notification

PPS Mgr

Remove the actor 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

Change Optionality to Mandatory the following Option:

• Creator Performed Procedure Step
• PPS Exception Management

Acquisition Modality

Change Optionality to Mandatory the following Option:

• Assisted Acquisition Protocol Setting
• PPS Exception Management
• Billing and Material 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 Mandatory the following Option:

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

Existing actors to be pulled in from other Profiles include:

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

New Actors

Enterprise System Scheduler

Add to be the destination for RAD-48 transaction, scheduled Item Updates. Previously, the order placer was the destination for this transaction.

This actor can be grouped with with Patient Demographics Consumer and grouped with Patient Encounter Consumer.

Note that this actor could be the source for RAD-48, transaction to the Order Filler, providing bi-directional scheduling interface.

Existing Transactions

The following changes are proposed for each tranaction:

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

No workflow trigger for initiating either query.

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:

• Order Performed Notification - An OMI or OMG message from the Order FIller to Order Placer to what was actually performed. Open issue of whether to send imaging data in OMI or to send billing data in OMG

• Order Initiated Notification - An OMI message from the Order FIller to Order Placer to indicate when the acquisition for the order started.

• Patient Arrived Notification - An A10 message from the Order Filler to Order Placer to indicate when the patient actually arrived.

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

DICOM and HL7 version 2.5.1 need to be evaluated for the ability to meet the needs for the new transactions listed.

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.

Breakdown of Tasks that need to be accomplished

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.

Rad TC 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.

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

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

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

2.3. Mandatory Usage of Protocol Codes in MWL & MPPS

The usage of protocol codes is necessary for robust interoperability. 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.

3. Enhanced Interoperability with HL-7 v2.5.1

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

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

3.3 Enhanced ability to specify timing for an order

HL-7 v2.5 introduces the TQ1 and TQ2 timing and quantity segments, enabling you to specify specific timing requirements also not possible in 2.3.1.

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

3.5 CTD Contact Data Segment

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

3.6 PID Segment The identification data of a patient specified in the PID segment with the HL7 v2.5 version is neccessary for support of the IHE Spain National requirements for Patient Identification. Included in this requiremnt is the need for specifying the ID number, Assigning Authority, Identifier Type Code, Expiration Date, and Assigning Authority Jurisiction.

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

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

6. PAM Transactions

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

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

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.

Risks

It has been suggested that PAM may not have considered all the requirements in the current v2.3.1 SWF (e.g. ...). If there are gaps/issues with PAM, will it be possible to make needed changes quickly? Who will do the work? IT or Radiology?

Rad TC should work to identify the gaps early to 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.

Initial analysis of PAM:

• Some fields are optional in SWF, but prohibited in PAM. Systems could fail for sending them. ITI prohibited anything kept in 2.5 for backwards compatibility only. Open Issue: CP to ITI-PAM to allow them, or warning in SWF II not to use them.
• Patient Account Number, Visit Number and Visit Indicator are optional in PAM. SWF requires these three fields to determine if the Patient is being tracked on a visit or patient level. A CP is needed to ITI-PAM allowing Radiology to require them.
• Ambulatory Status is Optional in PAM. It is needed in SWF to indicate a Woman’s Pregnancy Status. A CP is needed to ITI-PAM.

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

Analysis needs to be completed early with any proposed changes to the standards. Minor gaps can be addressed quickly. Larger, gaps would take longer time. Working with the standards bodies, SWF 2 could continue with profiling the proposed changes in trial implementation while the changes are being processed by the standard committees.

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

As a multi-year project, Radiology can deploy as a multi-year trial implementation to flush out the gaps. There are many components which are at low risk technically and where progress can be achieved early.

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.

SWF provided the basis for the workflow profiles of four Domains (Cardiology, ..., ...). How do we make sure that other Domains are aware of the work and have the appropriate input.

Rad TC will directly solicit input from all IHE domains 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 domains and they will be encouraged to participate in the public comment resolution meeting.

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.

PIR needs to be assessed with the Rad TC and the Japan National Committee. The Japanese National Extension Requirements to have PIR as an option will impact the ability to require PAM as part of the Integration Profile. Rad TC will need to work with the Japan National Committee to understand how to approach this need.

PIR needs to be assessed by the Rad TC to ensure there are not interoperability gaps when deploying in a mixed environment.

Scheduled Workflow is a major undertaking. It may take up to 3 years from initial Kickoff to final text. A major risk we face is obsolesence of the existing SWF without a replacement.

Radiology Subcommittees (Mammography and Nuclear Medicine) need to be invited to participate in the development.

Open Issues

How should we handle the central issue of multiple versions of the standards that underlie IHE?

The policy loosely followed by IHE Radiology to date has been:

• New profiles use the most recently released version (Currency)
• Existing profiles are not re-opened/revised simply to update the version of a standard (Stability)
• Version mixing is tractable due to the compartmentalization of transactions.

The following alternative policies have been proposed for HL7 in SWF II

• The profile uses "the most current relevant Released" version
• The profile uses "the most current relevant In-Ballot" version. Trial Implementation does not close until the relevant "In-Ballot" version is "Released"
• The profile uses "the most current In-Development" version if it has features necessary to complete SWF II. Trial Implementation does not close until the relevant content is "Released"

The following alternative policy has been proposed for HL7 in Final Text Profiles

• "In-Development" versions will be assessed for their backward compatibility. If a version is considered no longer "backward Compatible" to a profile, consideration will be needed to create a new integration profile.

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

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)

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)?

Some proposals are included in Section 5.1 Technical Approach, Existing Actors

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

See Section 7 Risks Fold PIR into PIR

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?

Some feel that users think of "changing" and order and the underlying protocol mechanisms should reflect the users view.

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

Some proposals are included in Section 5.1 Technical Approach, Existing Actors

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.

Are additional triggers needed for implicit post-processing and if so, what are they? (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 necessary and is this a sufficient amount of information?

Some flagged this as a critical feature to include in SWF II. Others have questioned the need.

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

IHE-Japan requests usage of the OMG and the ORG application acknowlegements. Is this suggesting that IHE support the enhanced application mode? If not, can IHE-Japan describe how the application acknowlegements should work?

IHE-Japan requests use of OMG/ORG meassages for the transmission of the new order messages from the Order Placer to the Order Filler. The Rad TC suggests that the OMG/ORI aslo include order updates prior to patient arrived from the order filler to order placer. For example, Order Placer discontinues an order before it has been scheduled.

IHE Japan suggests definition of a ZE1 Segment for billing. Rad TC suggests using the OMG message because it already includes the FT1 and the BLG segments.

IHE Japan suggest the ZE2 segment is defined to describe exposure information. The Rad TC suggest that the OBX segment is used for radiation dose.

IHE Japan suggests changing the EVN Segment to an optional requirement.

IHE Japan suggests placing all relevent AL1 information in the OBX segment.

Tech Cmte Evaluation

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

Note: Post the initial discussion it has been recommended that the estimate be bumped because of the extent of the unknown issues that may arise during the development. These increase are reflected in all of the estimates.

Technical Committee review resulted in estimates for three different approaches:

• 200% 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).

• 105%/105% 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.

• 50%/160% 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(Lead Editor)/Ruth Berge/Tony Palmer