OO CR175-833 - Example error in CQ datatype

Return to OO Change Requests page.

Submitted by: Riki Merrick	Revision date: <<Revision Date>>
Submitted date: 18-Nov-2014	Change request ID: OO CR173
Standard/IG: Standard	Artifact ID, Name: <<Artifact ID, Name>>

Issue

See [1] for problem definition and proposal.

Discussion

From e-mail exchange with InM:

The errata proposed is: Definition: This field defines the data type of OBX-5, Observation Value. This field is required if OBX-11-Observation result status is not valued with an "X" if OBX-5 is valued. See HL7 Table 0125 – Value Types for valid values, except for CQ, ID, and IS data types.

For V2.9 I would go with: Definition: This field defines the data type of OBX-5, Observation Value. If OBX-5, Observation Value, is valued then OBX-2, Value Type, SHALL be valued. When OBX-5, Observation Value, is not valued, OBX-2 Value Type MAY be valued to represent a data type used to value the observation expressed in OBX-3, Observation Identifier. See HL7 Table 0125 – Value Types for valid values, except for CQ, ID, and IS data types. Condition: This field is required if OBX-5, Observation Value, is valued.

Is there a reason why the CQ, ID, and IS data types are called out as exceptions? In the previous V2.9 ballot Table 0125 Value Types didn’t contain CQ or ID, but it did contain IS. So there seems to be some kind of inconsistency. (the following is from the standard): CQ is invalid because units for OBX-5-observation value are always specified explicitly in an OBX segment with OBX-6 units. SI IS is invalid because it only applies to HL7 message segments; ID is also invalid because it requires a constant field definition.

Suggest to remove CQ, IS, and ID from Table 0125 as it is not used elsewhere. This requires a harmonization proposal.

Recommended Action Items

May 13, 2015

OO WGM Wed Q1

Reviewed the proposal to fix the example. Recommend approval to InM