Potential bug: xlateInVals list improperly formed from HL/7 component field

[Jim Kosloskey]

All,

Cloverleaf 2209.

I have an xltp Tcl proc that uses values in the xlateInVals matched up with XlateInList.

When I specify one of the Source elements to be a componentized field (in this case PID-5) I would expect to see either just the first component (in this case ‘Patient’) or both components as a list {Patient Sample} associated with the xlateInList element. Instead, I see Patient and Sample as additional xlateInVals elements thus throwing off the association with xlateInList. There should be 5 xlateInVals elements instead there are 6 – see below.

You will note the elements are in synch until the PID-5 definition, then there is an additional element (Sample).

Has anyone else experienced this? Does this look like a bug? I can, of course, correct this by using component notation on PID-5 but I think the correct way this should be presented is either as just Patient or {Patient Sample}

xlateInVals >Y MYKEY Patient Sample y Y<
TEST XLTECHO v1.1: *** START *********************************************************************************************
TEST XLTECHO v1.1: xlateInList >@xlt_put_userdata_debug @xlt_put_userdata_key 0(0).PID(0).#5(0) @xlt_put_userdata_key_override @xltecho_debug<

 

Thanks,

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

Topic

[Jason Russell]

I’m fairly certain that when inserting a node into the inbound, it splits the node into separate elements in the xlatInList. So if your name was LAST^FIRST^MIDDLE, your xlate in vals would look like this:

{@xlt_put_userdata_debug} {@xlt_put_userdata_key} {LAST} {FIRST} {MIDDLE} {@xlt_put_userdata_key_override} {@xltecho_debug}

and you are expecting:

{@xlt_put_userdata_debug} {@xlt_put_userdata_key} {LAST^FIRST^MIDDLE} {@xlt_put_userdata_key_override} {@xltecho_debug}

If that’s the case, you will have to define a variable (@name or whatever) and copy pid-5 into that variable, then pass the variable into the translation line you’re attempting to do.

[Jim Kosloskey]

I agree that is what is happening, but I don’t believe that is what should be happening. The implication in all of the documentation is that the xlateInList and XlateInVals lists are in synch with each other and that is to be expected. The reality is there are cases where that is not true and I do not think those cases should exist. The relationship between xlatexxLixt and xlatexxVals (in and out) should be maintained in my opinion and based on what I can gather from the documentation available and my past experience.

I have coded xltp type procs this way since release 3.1 and although I cannot prove it, I do not recall this particular issue in the intervening releases I have used (I have not used all the intervening releases).

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

[Author]

Replies