Difference between revisions of "IHE Domain Coordination Committee 2008-03-28 HL7 Versioning Work Group Teleconference Minutes"
Jump to navigation
Jump to search
Chrisdcarr (talk | contribs) |
Chrisdcarr (talk | contribs) |
||
| Line 15: | Line 15: | ||
==Minutes== | ==Minutes== | ||
===Conflicts between PAM and SWF=== | ===Conflicts between PAM and SWF=== | ||
| − | Radiology defined scheduled workflow (SWF) in 1999 based on HL7 2.3.1--then most widely implemented version | + | '''Radiology defined scheduled workflow (SWF) in 1999 based on HL7 2.3.1--then most widely implemented version''' |
* Patient Management and Order Management are the primary HL7 components used | * Patient Management and Order Management are the primary HL7 components used | ||
| + | * Radiology SWF used some fields inappropriately because it was using the best solutions available; Need to determine whether overloading causes interoperability problems (internal issue for Radiology) | ||
* Pieces reused by RO, Eye Care, Lab, and Cardio | * Pieces reused by RO, Eye Care, Lab, and Cardio | ||
* Radiology polled vendors last year about moving to 2.5 and found that there was no support for moving there with current product base in Radiology | * Radiology polled vendors last year about moving to 2.5 and found that there was no support for moving there with current product base in Radiology | ||
| − | ITI defined PAM in 2002 to address ADT feeds for registration messages based on HL7 2.5 | + | |
| + | '''ITI defined PAM in 2002 to address ADT feeds for registration messages based on HL7 2.5''' | ||
* 2.5 explicitly disallows some PID segments defined in 2.3.1 | * 2.5 explicitly disallows some PID segments defined in 2.3.1 | ||
* Non-radiology vendors do not usually claim conformance to a specific version of HL7; mix and match segments as needed | * Non-radiology vendors do not usually claim conformance to a specific version of HL7; mix and match segments as needed | ||
* HL7 2.4 introduced the concept of message profiles; includes messaging workbench toolkit | * HL7 2.4 introduced the concept of message profiles; includes messaging workbench toolkit | ||
| − | Should all domains reissue their order and patient management issues using HL7 message profiles and workbench? | + | |
| + | '''Should all domains reissue their order and patient management issues using HL7 message profiles and workbench?''' | ||
* Would this invalidate currently compliant systems? No change in implementation semantics would be needed. | * Would this invalidate currently compliant systems? No change in implementation semantics would be needed. | ||
* Make upgrade paths based on profiles and specific elements rather than HL7 versions | * Make upgrade paths based on profiles and specific elements rather than HL7 versions | ||
| − | Is it possible to publish a simple CP to "unlock" the version number segment? | + | |
| + | '''Is it possible to publish a simple CP to "unlock" the version number segment?''' | ||
* If a radiology system receives a v. 2.5 message it should be able to parse the elements it needs and ignore any superfluous elements | * If a radiology system receives a v. 2.5 message it should be able to parse the elements it needs and ignore any superfluous elements | ||
* CP to unlock version number in patient mgt and order mgt messages in Radiology and derivative domains | * CP to unlock version number in patient mgt and order mgt messages in Radiology and derivative domains | ||
| Line 35: | Line 39: | ||
* Should radiology go back and revise existing profiles? | * Should radiology go back and revise existing profiles? | ||
| − | Conflicting requirements and prohibitions between domains | + | |
| + | '''Conflicting requirements and prohibitions between domains''' | ||
* Conflicting segments should be in different messages, but can still cause failures | * Conflicting segments should be in different messages, but can still cause failures | ||
* An example of the problem: PID fields defined in 2.3.1 are replaced in PAM by a repeating PID segment in v. 2.5 | * An example of the problem: PID fields defined in 2.3.1 are replaced in PAM by a repeating PID segment in v. 2.5 | ||
* 2.3.1 is no longer an ANSI standard; it was not resubmitted to ANSI for reapproval | * 2.3.1 is no longer an ANSI standard; it was not resubmitted to ANSI for reapproval | ||
* In profile writers guideline: avoid prohibiting fields; instead? | * In profile writers guideline: avoid prohibiting fields; instead? | ||
| − | + | ||
| − | Establish standards-based review cmtes: eg, HL7 Review | + | |
| + | '''Establish standards-based review cmtes: eg, HL7 Review''' | ||
* Make issue of resolving conflicts between PAM and SWF the initial issue of HL7 cross-domain coordination | * Make issue of resolving conflicts between PAM and SWF the initial issue of HL7 cross-domain coordination | ||
* '''Action:''' Propose to Domain Coord Cmte the formation of an HL7 Review Committee (or task force) | * '''Action:''' Propose to Domain Coord Cmte the formation of an HL7 Review Committee (or task force) | ||
| − | Begin Developing Advice Page ("Cookbook") for using HL7 in profiles | + | |
| + | '''Begin Developing Advice Page ("Cookbook") for using HL7 in profiles''' | ||
* Include discussion of versioning; whether to use HL7 profiling mechanisms, messaging workbench | * Include discussion of versioning; whether to use HL7 profiling mechanisms, messaging workbench | ||
* '''Action:''' Start Wiki stub linking off of Process page; drop in key items from today's discussion | * '''Action:''' Start Wiki stub linking off of Process page; drop in key items from today's discussion | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 11:07, 31 March 2008
Participants
Yongjian Bao John Donnelly Floyd Eisenberg Lynn Felhofer Cynthia Levy Steve Moore Kevin O'Donnell Vassil Peytchev Paul Seifert Karen Witting
Minutes
Conflicts between PAM and SWF
Radiology defined scheduled workflow (SWF) in 1999 based on HL7 2.3.1--then most widely implemented version
- Patient Management and Order Management are the primary HL7 components used
- Radiology SWF used some fields inappropriately because it was using the best solutions available; Need to determine whether overloading causes interoperability problems (internal issue for Radiology)
- Pieces reused by RO, Eye Care, Lab, and Cardio
- Radiology polled vendors last year about moving to 2.5 and found that there was no support for moving there with current product base in Radiology
ITI defined PAM in 2002 to address ADT feeds for registration messages based on HL7 2.5
- 2.5 explicitly disallows some PID segments defined in 2.3.1
- Non-radiology vendors do not usually claim conformance to a specific version of HL7; mix and match segments as needed
- HL7 2.4 introduced the concept of message profiles; includes messaging workbench toolkit
Should all domains reissue their order and patient management issues using HL7 message profiles and workbench?
- Would this invalidate currently compliant systems? No change in implementation semantics would be needed.
- Make upgrade paths based on profiles and specific elements rather than HL7 versions
Is it possible to publish a simple CP to "unlock" the version number segment?
- If a radiology system receives a v. 2.5 message it should be able to parse the elements it needs and ignore any superfluous elements
- CP to unlock version number in patient mgt and order mgt messages in Radiology and derivative domains
- Start a page of HL7 versioning procedures across domains--ITI and Radiology have appendixes that will provide some useful source material
- Should radiology go back and revise existing profiles?
Conflicting requirements and prohibitions between domains
- Conflicting segments should be in different messages, but can still cause failures
- An example of the problem: PID fields defined in 2.3.1 are replaced in PAM by a repeating PID segment in v. 2.5
- 2.3.1 is no longer an ANSI standard; it was not resubmitted to ANSI for reapproval
- In profile writers guideline: avoid prohibiting fields; instead?
Establish standards-based review cmtes: eg, HL7 Review
- Make issue of resolving conflicts between PAM and SWF the initial issue of HL7 cross-domain coordination
- Action: Propose to Domain Coord Cmte the formation of an HL7 Review Committee (or task force)
Begin Developing Advice Page ("Cookbook") for using HL7 in profiles
- Include discussion of versioning; whether to use HL7 profiling mechanisms, messaging workbench
- Action: Start Wiki stub linking off of Process page; drop in key items from today's discussion