Stream: V2
Topic: Structure of OBX-5
Vassil Peytchev (Dec 09 2020 at 20:53):
@Jessica Bush asked:
Can someone send me the breakdown of components within the OBX-5 segment in v2.5.1 ORU^R01 message?
OBX-5 varies based on the value of OBX-2. It can be one of the following datatypes, specified in OBX-2:
AD
CE
CF
CK
CN
CP
CX
DT
ED
FT
MO
NM
PN
RP
SN
ST
TM
TN
TS
TX
XAD
XCN
XON
XPN
XTN
Jessica Bush (Jan 06 2021 at 18:23):
@Vassil Peytchev what would the components be for OBX 5 if OBX-2 is ED? I'm unable to find the breakdown of the components for that field
Craig Newman (Jan 06 2021 at 18:30):
OBX-5 would follow the structure of the ED data type as defined in chapter 2A of the base standard.
2.A.24.1 Source Application (HD)
Definition: A unique name that identifies the system which was the source of the data. Identical format and restrictions as in reference pointer (see Section 2.A.66.2, "Application ID (HD)").
2.A.24.2 Type of Data (ID)
Definition: Identical to “type of data” component in the reference pointer (RP) data type. See Section 2.A.66.3, "Type of Data (ID)".
Refer to Imported Table 0834 – MIME Types for valid values.
2.A.24.3 Data Subtype (ID)
Definition: Identical to “subtype” component in the reference pointer (RP) data type. See Section 2.A.66.4, "Subtype (ID)".
Refer to External Table 0291 - Subtype of Referenced Data for valid values.
2.A.24.4 Encoding (ID)
Definition: The type of encoding used to represent successive octets of binary data as displayable ASCII characters. Refer to HL7 Table 0299 - Encoding for valid values.
2.A.24.5 Data (TX)
Definition: Displayable ASCII characters which constitute the data to be sent from source application to destination application. The characters are limited to the legal characters of the ST data type, as defined in Section 2.A.76, "ST - string data," and, if encoded binary, are encoded according to the method of Section 2.A.24.2, "Type of Data (ID)".
If the encoding component (see Section 2.A.24.4, "Encoding (ID)") = "A" (none), then the data component must be scanned before transmission for HL7 delimiter characters, and any found must be escaped by using the HL7 escape sequences defined in Section 2.7 – "Use of escape sequences in text fields." On the receiving application, the data field must be de-escaped after being parsed.
If the encoding component ED.4 does not equal "A", then, after encoding, the (encoded) data must be scanned for HL7 delimiter characters, and any found must be escaped by using the HL7 escape sequences. Only then can the component be added to the HL7 segment/message. On the receiving application, the data field must be de-escaped after being parsed out of the message before being decoded. This can be expressed as "encode", "escape", "parse", "de-escape" or "decode".
Last updated: Apr 12 2022 at 19:14 UTC
