Problematic XLTP

[Mike Strout]

We have a complex process that takes a textual finding from a radiology result from an OBX and applies formatting to it. In the xlate when we find “Findings:” at the beginning of an OBX, we flip OBX-3 from &GDT to &IMP so it files in the correct item in Epic. The problem is that the simple xltp that does the searching isn’t always working. It works consistently in a Tcl test, but when I resend the message to the beginning of the route, the resulting message still has the &GDTs, a clear sign that the XLTP didn’t work

Here are a few examples of the contents of the OBX5 that fail…

Findings:   Blood Pressure Response to Stress: The patient

Findings:.  Exam Quality/Artifacts/Incidental  The overall quality of

Findings:   Perfusion LV: The perfusion images are normal without Findings:

The xlate grabs this string and throws it into a variable that is passed into the following code…

Code:

lassign $xlateInVals obx
set xlateOutVals [string match -nocase “Findings:*” $obx]

Out of about 50 messages yesterday, this code returned 1 to the xlate exactly 0 times. Grrr. Thinking that the xlate may be tripping up on the string match, I decided to try the more resource intensive regexp as follows…

Code:

lassign $xlateInVals obx
set xlateOutVals [regexp — “^Findings:” $obx]

Still no dice. what am I missing?

Topic

[Jim Kosloskey]

Mike,

Have you echoed out xlateInVals to see what is in it?

If not try that to make sure what your source is.

If in your Xlate your Source is at the field level and it is a componentized field (code^text) you might only be seeing the code in your xltp proc. You might only need to add component notation to the Source to get the correct component.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Mike Strout]

Jim,

Long time no talk. Hope all is well for you with that chilly Michigan winter right around the corner.

Yes, I did echo out exactly as you said, plus a little…

echo “$xlateInVals=$xlateOutVals”

Most of the time, when I tested this in the testing tool I would get…

Findings:=1

I haven’t been able to find a common thread as to why it works sometimes and doesn’t others. I chalked it up to the testing tool not always giving accurate results, as we have discussed on previous occasions.

Today I just built another target thread that is a duplicate of the real one except it is a raw route (no xlate). I have it write to dev/null, but log the message in SMAT. It is a little cumbersome, but it at least gives me accurate results or all the pre-procs and I can see exactly what the xlate sees.

It is quite a mystery. Maybe someone else has bumped into a similar issue and will comment.

Thanks,

[Jim Kosloskey]

Mike,

Forgive me for asking but did you recycle the process to pick up the latest Xlate?

Sometimes it is the little things that trip me up.

I cannot see any reason why what you are attempting should not work.

Email me your proc (with the string match) and a test message and I will see what I observe.

What release of Cloverleaf?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Oh and things are good here in the great white north.

I am heading down to Houston in a couple of weeks. Then by the time I return we should be seeing the beginning snow and consistently colder temperatures – not looking forward to that.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Max Drown (Infor)]

You should always treat xlateInVals and xlateOutVals as list variables.

Correct: lassign $xlateInVals obx

Incorrect: set xlateOutVals [string match -nocase “Findings:*” $obx]

Instead: set xlateOutVals

]

-- Max Drown (Infor)

[Mike Strout]

Max,

I appreciate needing to send the xlateOutVals to a list if there is more than one item in the list, but in this case the list will only ever be a 0 or a 1.

I assume that the following happens behind the scenes from the Pre Proc to the destination value

[ lassign $xlateOutVals $destinationsList ]

Because $xlateOutVals only has one item in the list and there is only one item in the $destinationsList…

set xlateOutVals [ string match -nocase “Findings:*” $theOBX ]

is functionally equivalent to

set xlateOutVals [ list [ string match -nocase “Findings:*” $theOBX ] ]

Where I would run into a problem is when there is more than one item in $xlateOutVals or $destinationsList, or both.

[Mike Strout]

Well, way too many hours were just spent only to find out that there was a complicated inbound pre-proc that wasn’t consistently putting “Findings:” at the beginning of a sentence.

At least the process of solving this problem has allowed me to wholly understand and document how this rad workflow works.

Thanks Jim and Max for your thoughts,

[Author]

Replies