Extra x0d at end of message

[Kathy Zwilling]

I have a situation where I am translating patient race in a tclproc (xlate isn’t appropriate for this circumstance) and the resulting ADT HL7 message ends up with an extra x0d at the end of the message after the tclproc processes the ADT message.   Tclproc is attached.

When the ADT comes into the engine it has one x0d at the end of the message (found through turning up engine debug log).  

I have put echo statements in my tclproc to find out more and discovered that when I split the inbound ADT message on /r, I get an extra element in my list at the end that is {}.   This “segment” at the very end and completely empty (null maybe?).   There is no actual segment beyond the ZAD at the end.   Generally, the tclproc split creates this:

{MSH|||||||} {EVN||||} {PID||||} …. {IN1|||} {IN2|||} {ZAD|||} {}

and after it rebulids the message the split shows us this generally:

{MSH|||||||} {EVN||||} {PID||||} …. {IN1|||} {IN2|||} {ZAD|||} {} {}

How can I keep this from happening in my tclproc?  Is there a null character doing this?

Thank you!

Topic

[Tom Rioux]

It appears to me that the problem may be with the statement:

append newmsg $segr

That is inside the foreach loop and will append a “r” to each “seg” variable, INCLUDING the last seg.  I don’t think you would want to do this on the very last segment.

Try just getting the PID segment, grabbing the index, do your race code logic, then do an lreplace to place the new seg back into the “segments” list.   Then join your message back together then pass it on.   I’d take out the append altogether.  You could probably also do without the foreach by doing an lsearch in the “segments” list for ^PID.  Something like this would do the trick:

set pid_idx [lsearch -regexp $segments ^PID]

Hope this helps…

Tom Rioux

[Kathy Zwilling]

Thank you!  Tried that and it looks like it is working.

[Kathy Zwilling]

Does anyone know why the split command would generate an empty element at the end of the message?

[Rob Abbott]

Because there’s a delimiter at the end of the message:

segsegseg

when split on CR this will result in

seg seg seg {}

Rob Abbott
Cloverleaf Emeritus

[Kathy Zwilling]

Is it normal to have a CR at the end of the last segment of an HL7 message?

[Mark Brown]

For tcl procs that make changes to a segment, I’ve started adding this piece of code just before the msgset to get rid of the extra line feed at the end.

 # Get rid of double line feed at the end of the message.

 regsub -all {x0dx0d} $outBuff x0d outBuff

outBuff being whatever variable you use to save your message to before sending it on it’s way with msgset.

I’m sure I’m getting the extra line feed with “append outBuff ${segment}r” but if I take the r off, the proc always fails.  So I just started adding the regsub.

[David Barr]

Kathy Zwilling wrote:

Is it normal to have a CR at the end of the last segment of an HL7 message?

Yes.  The HL7 standard refers to it as a “segment terminator”, not a “segment separator”.

[Kathy Zwilling]

Thank you that explanation.  

It must be that I don’t understand how the split command is working then.  I really anticipated that it would create the list be making an element from each “segement prior to the segment terminator.   It looks like it is also creating an element at the end of the list (empty) for a set of data after the last segment terminator but there is no segment there.   What am I not seeing?

[Rob Abbott]

That’s the way split works.

Rob Abbott
Cloverleaf Emeritus

[Mike Grieger]

HL7 segments are terminated by a 13 (CR).  So, a simple illustration would be MSH(CR)PID(CR)PV1(CR)

When you split the message by the CR, you get a list containing MSH PID PV1 {} – that final null element is the result of the character you are splitting on being the last character of the data.  

If that null element did not exist, when you would join the segments back together, you would get MSH(CR)PID(CR)PV1, which would no longer be a properly formatted message.  Because the null element is the final list element, when joining the segments back together, the final CR is put back where it belongs.

If you were to have a improper message (just for illustration) of MSH(CR)PID(CR)PV1(CR)(CR) and split by CR, the resulting list would be MSH PID PV1 {} {}

[Kathy Zwilling]

Ok, thanks alot for both explanations!  That helps alot!

[Author]

Replies