PCD SDO HL7 Coordination
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 at 2021-10-19 to -21 San Diego Face-to-Face placeholder
Use the following table to capture issues to be discussed at the upcoming January 2021 HL7 meetings.
[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, Garguilo 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. Proposal: Request OID arc from HL7 Implementation / Conformance Technical Committee for IHE message profiles (if one doesn't already exist). Arc would be <HL7><conformance><IHE><...>. Assignment of the last component would be managed by IHE. Before the proposal is made, queries will be made to IHE Co-Chairs and NIST. Note: Lisa Carnahan (NIST) is a co-chair of the HL7 TC. Note: In the HL7 v2 Global Message Profile Library User's Guide reviews usage of the submission process. There is a "Manual Add" service for associating profile-related OIDs to the profile indicated; however, there is no relationship identified such as "same as".
Actions (jjg): 1) Find out more information regarding what the process is, or what it takes, to register a profile (obtain an OID) with IHE? (ping Eric Poiseau) 2) Same question for registering with HL7; and how does the identifier/registration (OID?) get mapped between HL7 and IHE?
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. A change proposal for HL7 2.x should be made ASAP. This must be associated with a specific section of the HL7 standard. Depending on timing (i.e., submission today 2008-05-07) this may be added to v2.7; otherwise, it will be considered for 2.8. Note that officially, the 2.7 ballot was closed during the 2008/01 HL7 WGM. 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. For trial implmentation using HL7 v2.5, Device ID will be provided in an OBX segment. Change request has been entered to change the standard to provide a place for Administration Device ID in RXR in v2.7 or 2.8.
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. The response structure needs to be changed so that 2 messages are sent. The actual response message (RRV) is intended to provide the application ACK (or error). In order to send back changed settings, the same transaction (RGV) should be used with a different order control code ("XX" in ORC-1). We may also evaluate ORC-5 Order Status for use in our profile. Note that even though the RRV response basically provides all of the same information (except for supporting the OBX segments containing height and weight) it is not intended for the purpose of communicating changed data.
6 tbd . . . . 7 tbd . . . . 8 tbd . . . . 9 tbd . . . . 10 tbd . . . .