FRL to HL7 xlate/tcl issue with encoding characters

[Andy Devitt]

I am converting a FRL to HL7, the FRL can contain |^~& characters, so I was mapping them via a string map on a copy of the field.

set xlateOutVals [string map {& \T\ \ \E\ | \F\ ^ \S\ ~ \R\} $xlateInVals]

This seems to work 90% of the time, but I ran into an issue with a couple of values that don’t have spaces around the character I am mapping. “B&C” vs “B & C”

When I was troubleshooting via the testing tool, the value seems to get mapped appropriately as I am echoing the xlateOutVals, so I will see “BTC” on the echo, but in the message is “BTC”. In the case of the value with spaces around the character, the echo has “B T C” and the message also has “B T C”.

I am pretty much stumped and not sure what to do next. Any ideas?

Topic

[Russ Ross]

As you are finding out the testing tool is nice for percise and quick testing but isn’t 100% dependable to expect to match the same outcome as running messages thru the actual interface.

This especially applies when dealing with some of the special characters.

Since this sounded a bit familiar I located some comments in our tps_regsub_all.tcl proc that look like this:

Code:

#
# ——
# Notes:
# ——
#
# UPoC type = TPS
#
# When using hcitester enclose args in curly braces
# or use double escapes !!!
#
# When using hcinetconfig do not enclose args with curly barces
# or either enclose args in double quotes !!!
#
#
# Examples of Normal Usage via hcinetconfig:
# ——————————————
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word left smart quote to ASCII double quote}}
#            {EXPRESSION_1 x093}
#            {EXPRESSION_2 x022}
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word right smart quote to ASCII double quote}}
#            {EXPRESSION_1 x094}
#            {EXPRESSION_2 x022}
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word long dash to ASCII dash}}
#            {EXPRESSION_1 x096}
#            {EXPRESSION_2 x02d}
#
#
# Examples of Normal Usage via hcitester:
# —————————————
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word left smart quote to ASCII double quote}}
#            {EXPRESSION_1 {x093}}
#            {EXPRESSION_2 {x022}}
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word right smart quote to ASCII double quote}}
#            {EXPRESSION_1 {x094}}
#            {EXPRESSION_2 {x022}}
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word long dash to ASCII dash}}
#            {EXPRESSION_1 {x096}}
#            {EXPRESSION_2 {x02d}}
#
# More Examples of Normal Usage via hcitester:
# ——————————————–
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word left smart quote to ASCII double quote}}
#            {EXPRESSION_1 \x093}
#            {EXPRESSION_2 \x022}
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word right smart quote to ASCII double quote}}
#            {EXPRESSION_1 \x094}
#            {EXPRESSION_2 \x022}
#
#    Proc :  tps_regsub_all
#    Args :  {COMMENT {change MS Word long dash to ASCII dash}}
#            {EXPRESSION_1 \x096}
#            {EXPRESSION_2 \x02d}
#

Perhaps some of these examples can help you make some trial and error guesses to get the messages correct for the actual interface instead of for the tester.

Probably will take playing around with these or {} or “”.

Also be warned that when we went from Cloverleaf 5.6 to Cloverleaff 6.0 we observerd that the MSH & is handled differently at the individual field level, so if you aren’t on Cloverleaf 6.0 right now then your fix might need a reworking when you upgrade to Cloverleaf 6.0.

Russ Ross
RussRoss318@gmail.com

[Andy Devitt]

Thanks Russ for the information, we are actually in the process of upgrading our 5.7 environment to 6.0, so I will definitely be sure to pay attention when i start testing this piece in 6.0.

I figured out the problem I was having, the issue was that when xlateOutVals was setting the value in the message, sometimes the T was being interpreted correctly and other times I needed to send \T\ for it to go in the outbound message correctly. I will post later the actual fix that I came up with as I still need to test some more to be certain I have it fixed.

[Jim Kosloskey]

Andy,

I note you are not treating either xlateInVals nor xlateOutVals as lists.

Perhaps changing that might improve your results. Weird inconsistent things can happen when the xlate In and Out lists are not treated as such.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Andy Devitt]

Thanks Jim, yes that is exactly the issue.

I am not sure the best way to do it, but I seem to have it working now where I concatenate all the list values into a single value and then set xlateOutVals index 0 to that value.

Is there a better option? I am still really new to tcl, and lists are my biggest downfall at the moment.

[Jim Kosloskey]

Andy,

Try this:

set xlateOutVals

]]

or to spread that out:

set in_data [lindex $xlateInVals 0]  <– This gets the first (and probaky only) element in the Source (xlateInVals list) of your Xlate Action and places that in a variable called in-data.

set mapped_data [string map {& \T\ \ \E\ | \F\ ^ \S\ ~ \R\} $in_data]  <– does the string map

set xlateOutVals

 <– makes sure xlateOutVals is a list

I have not actually executed any of the above so there may be some mis-matched braces/brackets, etc. but the concept should be correct.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Russ Ross]

A simple example of making xlateOutVals a list when passing field1 that might contain spaces in it might look like this

Code:

set xlateOutVals [list $field1]

Russ Ross
RussRoss318@gmail.com

[Author]

Replies