PCD SDO HL7 Coordination

From IHE Wiki
Revision as of 13:51, 2 May 2008 by Mpattillo (Talk | contribs) (Issues for Discussion @ [http://www.hl7.org/events/phoenix052008/ 2008.05.05 HL7/IEEE/ISO Meetings in Phoenix])

Jump to: navigation, search

HL7 Technical Coordination

The IHE PCD Technical Framework and profile supplements leverage HL7 standards, but during the development phase, questions often arise regarding which HL7 components should be used, how they should be used, or resolution of gaps that are surfaced. This page provides PCD membership with a place to log and discuss issues.

Note: In the future, this type of activity may be managed by another tool such as Flyspray. An IHE application of this tool is also available for tracking domain coordination issues.

Additionally, IHE is forming an HL7 technical support group that may be able to address many of these issues in the future.


New Issues

Use the following table to log new issues that need to be addressed.


Item Submitters Profiles Topic Description Status/Disposition
1 . . . . .


Issues for Discussion @ 2008.05.05 HL7/IEEE/ISO Meetings in Phoenix

Use the following table to capture issues to be discussed at the upcoming HL7 meetings in Phoenix.

[TCooper] Should a Date column be added to this table ... for submission or updating ... or is that when we need to use a different tool?!


Item Submitters Profiles Topic Description Status/Disposition
1 TCooper DEC, PIV, SPD v2.x Message Registration There was discussion during development of the [DEC] profile that the resulting message should be "registered" in order to support conformance validation. This question has come up again for the PIV and SPD development, espeically with respect to the value for MSH-21 Message Profile Identifier. See HL7 v2.6 chapter 2.14.9.21. .
2 PSchluter ACM v2.x OBX's w/ simiple wave data The ACM profile needs a simple method for communicating wave snippet data that is associated with an alarm condition. The desire is to have wave sample information communicated vs. an image representation of the wave. Since the output devices upon which the wave data will be displayed can vary widely w.r.t. their capabilities, the data format should be very simple, such that it can be easily transformed to a presentation format appropriate to the display / reviewer device. Notes:
  • This should also apply to the DEC profile
  • Extensibility to annotation data should also be supported
  • Could a URL be passed linking to the wave data?
3 MPatillo ACM v2.x assignment of a non-"Z" trigger event IHE PCD currently makes use of Znn events. Could we get assigned event codes for the PCD Z events. .
4 JRinda PIV Use of ORC-18 Entering Device to contain the infusion pump ID Using the RGV transaction to transmit infusion pump settings from a barcode point of care (BPOC) nursing application to a pump. This transaction requires the identification of the pump. After considerable discussion, it appears that although ORC-18 is not exactly intended for this purpose, there was no reasonable alternative way to provide it. .
5 JRinda PIV Response reporting of actual settings Using the RGV transaction to transmit infusion pump settings from a barcode point of care (BPOC) nursing application to a pump. Two of the parameters, patient height and weight, are represented as observations in OBX segments. We are using the RRV acknowledgment transaction to respond back to the BPOC. Most infusion pumps have a limit to the precision they can support; for example, the BPOC might send 13.333 mL/hr to the pump but the pump can only handle 13.3 mL/hr. We populate the segments in RRV with the actual settings that will be used by the pump with regard to rate and volume. Height and weight values are also subject to precision limitations; however, since RRV does not include OBX there does not seem to be any way to provide this information back to the BPOC in the response. .
6 tbd . . . .
7 tbd . . . .
8 tbd . . . .
9 tbd . . . .
10 tbd . . . .