Difference between revisions of "HL7 Review Task Force 2008-05-30"

Latest revision as of 15:45, 11 June 2008

Attendees

Yongjian Bao - GE, ITI Tech
Dick Donker - Philips, Rad Tech
Ana Estelrich - GMP-DIP, QRPH Plan
Rob Horn - Agfa, ITI Tech
Cindy Levy - Cedara, Rad Tech
Chris Lindop - GE, Rad Tech
Charles Parisot - GE, ITI Plan
Vassil Peytchev - Epic, ITI Tech
Charles Rica - QRPH Tech
Paul Seifert - Agfa, Rad Tech
LaVerne Palmer - HIMSS
Lisa Spellman - HIMSS
Chris Carr - RSNA
Nichole Drye-Mayo - RSNA

Minutes

PAM and SWF

Review of previous task force action item: Clean up the PAM vs. SWF spreadsheet comparing PAM 2.5 to SWF 2.3.1
- Identified fields whose use/optionality in PAM is different from Radiology and noted which differences are critical
  - PAM has three sets of messages: assigning identities (create, update patient), registration and encounter (combined in certain transactions)
- Radiology does not make the same distinction consistently

- Radiology does not include the concept of encounter (though a radiology order may be associated with an encounter)

- Other than patient location radiology may not need to provide encounter-related patient tracking and workflow information

- Currently the use case for encounter management in radiology doesn't seem compelling

- Development of SWF II can take into account the potential conflicts with PAM transactions and make them irrelevant

- Issue of interoperability between SWF I and SWF II (PAM) is the critical consideration

- PAM's concept of encounter includes patient location information; Radiology may suggest separating these elements out; a radiology order is not considered an encounter

- In PAM encounter management is optional

- PAM (section 14.5.2.4) specifically addresses the use case of tracking patient in temporary transfer going into radiology department for imaging exam

- Important for radiology to understand PAM and communicate with implementers about differences, etc.

- PIX query is being updated with PAM feed

- Functions related to charge posting and administrative/financial transactions are being built on top of PAM: 2.5 provides benefits in defining these transactions; not covered in comparison from Radiology perspective

Action item: Add functional comparison of trigger events and workflow capabilities in PAM vs. SWF

HL7 Versioning Requirements

Should IHE allow different versions of HL7 in a single transaction?
- Probably too complex: make separate transactions where one is optional
- Might put the requirement on flexibility on the receiver of messages: required to support both
- Indicate the data that becomes available only in later versions of HL7
Should IHE allow different versions in a single profile?
- Already done in PIX for different transactions
Main problems are with application behavior
- Applications will sometimes reject messages solely based on the HL7 version number in the header
- HL7 specifies that they should accept messages from version number they support or earlier
- Applications will sometimes ignore information in fields from newer versions of HL7 that they are not confident are complete or accurate
- Solutions might be to develop profiles for each of the HL7 messages used
- The breadth and specificity of the use case need to be balanced
- Section in Rad TF (vol. 2, section 2.3) that describes version compatibility; Yongjian
Action Item: Review Rad TF vol. 2, section 2.3 for accuracy prior to next meeting.

Next Meeting

June 20, 10:00am - 11:30 am CDT - next call

HL7 Review Task Force

Domain Coordination Committee

@@ Line 1: / Line 1: @@
-===Attendees===
+==Attendees==
-* Dick Donker - Philips
+* Yongjian Bao - GE, ITI Tech
-* Yongjian Bao - GE
+* Dick Donker - Philips, Rad Tech
-* Paul Seifert - Agfa
+* Ana Estelrich - GMP-DIP, QRPH Plan
-* Cindy Levy - Radiology
+* Rob Horn - Agfa, ITI Tech
-LaVerne Palmer - HIMSS
+* Cindy Levy - Cedara, Rad Tech
-Lisa Spellman - HIMSS
+* Chris Lindop - GE, Rad Tech
-Chris Carr - RSNA
+* Charles Parisot - GE, ITI Plan
-Nichole Drye-Mayo - RSNA
+* Vassil Peytchev - Epic, ITI Tech
+* Charles Rica - QRPH Tech
+* Paul Seifert - Agfa, Rad Tech
+* LaVerne Palmer - HIMSS
+* Lisa Spellman - HIMSS
+* Chris Carr - RSNA
+* Nichole Drye-Mayo - RSNA
-Rob Horn - Agfa
+==Minutes==
-Ana Estelrich - Quality - dropped in and had a meeting conflict.
+===PAM and SWF===
-Chris Lindop - Radiology
+* Review of previous task force action item: Clean up the PAM vs. SWF spreadsheet comparing PAM 2.5 to SWF 2.3.1
-Charles Parisot - GE
+** Identified fields whose use/optionality in PAM is different from Radiology and noted which differences are critical
-Charles RICA - QRPH
+*** PAM has three sets of messages: assigning identities (create, update patient), registration and encounter (combined in certain transactions)
+** Radiology does not make the same distinction consistently
+::::- Radiology does not include the concept of encounter (though a radiology order may be associated with an encounter)
+::::- Other than patient location radiology may not need to provide encounter-related patient tracking and workflow information
+::::- Currently the use case for encounter management in radiology doesn't seem compelling
+::::- Development of SWF II can take into account the potential conflicts with PAM transactions and make them irrelevant
+::::- Issue of interoperability between SWF I and SWF II (PAM) is the critical consideration
+** PAM's concept of encounter includes patient location information; Radiology may suggest separating these elements out; a radiology order is not considered an encounter
+:::- In PAM encounter management is optional
+:::- PAM (section 14.5.2.4) specifically addresses the use case of tracking patient in temporary transfer going into radiology department for imaging exam
+:::- Important for radiology to understand PAM and communicate with implementers about differences, etc.
+:::- PIX query is being updated with PAM feed
+:::- Functions related to charge posting and administrative/financial transactions are being built on top of PAM: 2.5 provides benefits in defining these transactions; not covered in comparison from Radiology perspective
+* '''Action item:''' Add functional comparison of trigger events and workflow capabilities in PAM vs. SWF
-Taskforce formed within the IHE Domain Committee to look at a series of HL7 related issues to make sure the requirements of HL7 are being defined and consistent in the way HL7 requirements are defined in different profiles.  Rash of emails sparked this issue and there was a change proposal presented, cp211 in ITI, that was relevant to the topic.
+===HL7 Versioning Requirements===
-Define issues and group.
+* Should IHE allow different versions of HL7 in a single transaction?
-Radiology Planning Activities and SWII - PAM vs. SW - click on and it will take you right there.
+** Probably too complex: make separate transactions where one is optional
-Table displayed is important. Analysis of table comparisons - Yongjian
+** Might put the requirement on flexibility on the receiver of messages: required to support both
-Volume II Section 2.3
+** Indicate the data that becomes available only in later versions of HL7
+* Should IHE allow different versions in a single profile?
+** Already done in PIX for different transactions
+* Main problems are with application behavior
+** Applications will sometimes reject messages solely based on the HL7 version number in the header
+** HL7 specifies that they should accept messages from version number they support or earlier
+** Applications will sometimes ignore information in fields from newer versions of HL7 that they are not confident are complete or accurate
+** Solutions might be to develop profiles for each of the HL7 messages used
+** The breadth and specificity of the use case need to be balanced
+** Section in Rad TF (vol. 2, section 2.3) that describes version compatibility; Yongjian
+* '''Action Item:''' Review Rad TF vol. 2, section 2.3 for accuracy prior to next meeting.
+==Next Meeting==
 June 20, 10:00am - 11:30 am CDT - next call
+[[HL7 Review Task Force]]
+[[Domain Coordination Committee]]
+[[Category: Minutes]]