[HL7 message processing] OBX segment is smaller than it should be when we use GetValueAt()

Question

Question

Yone Moreno · Oct 2, 2020

#Caché

Hello,

We would need your help:

We are processing a HL7 message.

Its OBX segment has 4318 characters

1) We get the OBX with the following line of code:

set textoCompleto = request.GetValueAt("5:3.2")

When we output its length with:

$$$LOGINFO("textoCompleto: "_textoCompleto)

It shows:

     $LENGTH(textoCompleto): 3497

- So as we see it is being shortened

2) We get the OBX with the following line of code:

set textoCompleto = $PIECE(request.OutputToString(), "OBX", 2)

When we output its length with:

$$$LOGINFO("textoCompleto: "_textoCompleto)

It shows:

     $LENGTH(textoCompleto):  4318

It displays the correct length

Why does this line of code

set textoCompleto = request.GetValueAt("5:3.2")

cut the string below the correct size?

We have read:

https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cl...

Discussion (1)1

Log in or sign up to continue

Julian Matthews · Oct 4, 2020

Hey Yone - there's a few things going on here, but I'll try to explain as best I can.

For starters, calling "request.GetValueAt("5:3.2")" is returning to you the value of segment "3.2" of whatever is row 5 of your inbound message. If in your case this is an OBX, then this is only returning the content of OBX:3.2 (Which is some variation of Observation Identifier Text).

When you are then outputting the entire HL7 message to a string and then running "$PIECE(request.OutputToString(), "OBX", 2)" you are getting every character in the string after the literal text "OBX"

So if we use this fake message as an example:

MSH|blahblahblah
PID|blahblahblah
OBR|blahblahblah
NTE|1|blahblahblah
OBX|1|ST|NA^SODIUM^L||139|mmol/L|136-145|N|||F

Calling "request.GetValueAt("5:3.2")" and then evaluating its length would give you 6, as OBX:3.2 is "SODIUM" in the above. If you then output the above into a string and then checked the length of the output from "$PIECE(request.OutputToString(), "OBX", 2)" you would be evaluating all that is highlighted above.

Now with that being said, it is not a good idea to make assumptions that a specific row within a message will be a set segment type. Certainly in my case, all it would take is for a few NTE segments to be present in a message, and "5:3.2" could easily be part of an OBR or NTE.

1 0