TCL or XLATE Complex situation?

That seems very doable, but I would do it in a tcl proc probably where you have more flexibility.

Femina,

I believe this is accomplishable in an Xlate.

You would need to use your own counters. Probably one for the outbound ORC/OBR group and one for the outbound OBX group/

There might be some Tcl involved inside the Xlate using an Xlate solution but I don’t see that based on your description.

Are you familiar enough with tcl to translate from plain text?

Use a variable set to 0 as a counter, then run a foreach on the segments.  Split the segment into fields, find the field you want, set a variable with the data from that field, then run a search in an if statement to see if it contains that sequence of characters.  If true, increase your variable.  You can do this independently for each string, if needed.

It looks like you’ll also need to grab the patient name from in the message, as well as a couple of other pieces of data.  That shouldn’t be too tricky.

I don’t quite see where you are looking to put those values in the OBR segment, but you would simply free write out the entire segment to a variable, using your variables in the string of text.  A basic example:

set topOBR “OBR|RE|13-433|DPP-$aleft|$procedure|||$date||||” (and so on)

Then you just need to add that topOBR variable to your list of segments at position 0.  It could take some time but Google is your friend.  Just start your search with “tcl”

“tcl get value of list item”

“tcl insert variable into list”

“tcl counter variable”

I hope this helps.  The testing tool and the echo command are your best friends in something like this.

Femina,

In an Xlate I would think you would ITERATE through the OBX Group then with an IF once you detect OBX-5 with the value ‘SPECIMENS SUBMITTED’ set a switch (use a temp variable) also set something to the value of the repetition counter of which OBX repetition this was located.

That switch indicates that this set of OBX repetitions has the value. The counter value saved off tells you after which you need to start building OBR group, etc.

After that ITERATE add an IF to check to see if the switch from the first ITERATE was thrown. Inside the IF add another OBX Group ITERATE. This one will be used to build the OBR, etc.

Inside the second ITERATE you will check its Iteration counter value against the value stored off in the first ITERATE which indicates where the ‘SPECIMENS SUBMITTED’ was found. IF the current counter is greater than the saved off value then check OBX-5 for eq @null. If it is not eq @null build your OBR then ITERATE again over the OBX group adding all of those OBX etc. to the new outbound.

Of course you will need some of your own counters for the outbound OBR and OBX groups.

Rememember in tha Xlate you can ITERATE over anything as many times as you need. Just try to use different Iteration Counters for each ITERATE – I would not recommend re-using counters.

That should give you an outline of how to do this but there is still some detail to be worked out.

For example if you can also have OBX sets which do NOT have this requirement then you will need to add logic to determine which set you are working with.

In the past when I have had Result messages with mixed content and the sending system is essentially sending reports I usually create an Xlate for each set (let’s say there are 2). Then either using a TrxID proc or filtering, I separate the messages at routing into the 2 camps and associate the appropriate Xlate with the message.

Although that means maintaining 2 Xlates it does mean neither is as complicated as trying to do both sets of logic in one Xlate.

I have done it in the combined Xlate as well.

Femina,

I think Jim has an interesting idea.     Try to find out if it would be ok to send a complete separate message for each of those OBRs you would build.

If yes, build a separate route for each possibility (A., B., C., D….), and have the translate in that route just make the needed adjustments specific to that route to the original OBR.

Jim,

I am trying to use the technique to add an OBX segment (as the first OBX) when certain conditions are met. But I’m having issues with the variables I think. I’ve always used a percent sign for iteration variables (i.e. %group1 ) and an @ symbol for regular variables (i.e. @obxcntr). I appear to be getting errors when trying to use the @ var in a path.

I also tried to make my variables using the percent instead but that didn’t work either.

I’ve included an image with a screenshot from the Xlate.

Steve,

You cannot use anything but a % variable or a number in the address path.

when you use a temp variable (@whatever) it is converteed to zero (0).

But you can have your own % variable (like %g99) which you have to manage (increment/decrement, etc.).

Feel free to email me if you need more assistance.

I both emailed and spoke to Jim on the phone and he gave some additional tips that I though I’d share, just in case someone else finds this thread interesting.

I didn’t read the documentation close enough on ITERATE.

Excerpt: “All variables must start with % and be either f (field), g (group), l (list), or s (segment). If there is more than one variable, use, for example %f1, %f2, and so on.” I wasn’t using one of those four single letters and a number. That was one issues (of several).

Another tip, unless the % variable is used in an actual address path (such as “1(0).1(%g1).1(%g99).OBX(0).#5(0)” ) you likely need to preface it with a dollar sign ($) so that TCL will interpret it correctly as a variable. This got me in an IF statement, MATH statement, and COPY statement.