Is there a way to use both a TCL proc and Output Message Format on a route?

[Joe Baranski]

I’m trying to convert a lot of existing XLATEs to TCL but the previous guy was strict to use HL7 formats for their specific vendors.  Instead of going through all these with a fine tooth comb and have to compare every single field in TCL, is there a way to integrate the output formats with TCL?  Other than write the TCL and put it on PreProc with a specific bulkcopy XLATE that uses the output message format?

 

Thanks in advance!

-Joe

Topic

[Jason Russell]

I’m curious why you’re converting xlates to TCL? They both have their pros and cons. TCL can do some really fancy stuff as scripts and basic bulk actions. Xlates use HL7 formats to make sure data goes from a message to an outgoing message. They really have different functionalities. The entire point of the Xlate is to use the structures to make sure the messages are formatted properly, with the correct segments in the correct places.

There are HL7 libraries for TCL, but they are very basic processors, and don’t use formatted structures. There is a reason you want to use a structure for HL7, they can get messy quickly if you don’t.

[Joe Baranski]

Partly because I’m far more knowledgeable with TCL than Xlates; my last site was 100% TCL and this new one is 100% Xlate.  And partly because Infor had recommended it due to Xlates being a little more top-heavy with resources.  We’ve had issues where some of the heavy-traffic interfaces with Xlate filtering would spike to 100% CPU usage and choke out our entire prod server.  We’ve already taken steps to fix that.  Not everything can be converted due to the complexity.  And things get even more complex when field length limitations impact the data.  Like Pt Type comes out of our EMR is 6 characters but the output format has 2 characters allowed for that field.

[Jim Kosloskey]

I submit a lack of knowledge is not a valid reason to make such a major change. Xlate is not that difficult to learn.

Moreover, I did a performance evaluation of using Tcl vs Xlate vs Xlate Chaining for filtering. That study result was posted on this forum, and I have a white paper (and testing components) available for the asking – just email me.

The gist of the study is there is not a significant difference in the performance among the techniques. If you want to know the difference on your processor, you can just run my test suite and do your own evaluation.  I would be interested to see your results.

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

[Jason Russell]

Interestingly enough, we use a mix of TCL and xlate for our interfaces. TCL for filtering, XLates for actual HL7-HL7 translations and functionality.

As far as I am aware, the xlate is built on top of TCL and the only extra overhead is loading the structure and parsing the message out completely, which should be nearly instant. I would be curious as to your throughput (how many messages) and what kind of hardware you’re on (even if you’re in VMs).

How many threads and processes are in your sites? There are some things that we were doing (and still are to some extent) that could help reduce processing on messages that cloverleaf recommends.

As for field lengths, we disabled field length checks completely. Considering data changes and software updates, if we need to limit fields we do that manually on an as-needed basis.

[Jim Kosloskey]

Just so we understand how this works… The formats and tables are loaded into memory with the first of a given message, thereafter there is no overhead for loading these into memory, just the overhead of retrieving them for use.

Great efforts post 6.1 have been made by the developers to enhance the overall performance of the Xlate. There are techniques that can be coded in Xlates that get the job done but are inefficient, wherein the Xlate itself is performing well but is asked to perform more than it should. I have seen this most often with a misunderstanding of the ITERATE Action.

Interesting history, the product originally was not to have Tcl exposed as an extensibility language. As I understand it (from one of the founding fathers) there were some passionate discussions before Tcl was exposed. The original design intent was to use the toolset sans Tcl unless it was something that could not be done in the toolset, then use Tcl.

I suspect there are very few (maybe no) shops 100% Xlate. There is likely some Tcl outside the Xlate  and within the Xlates to handle things the toolset does not. Within the Xlate itself, with the advent of the STRING Action Functions, there should be less need for Tcl within the Xlate to do the job.

Even then, I advocate writing reusable Tcl instead of ‘snippets’ imbedded in the Xlate. There is a slight performance advantage and means fewer Tcl modules to maintain.

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

[Author]

Replies