Suppressing HL7 Segments

[Anonymous]

I’m working with a vendor system that, unlike most systems I’ve worked with, cannon simply ignore a unwanted HL7 segments.  In the xlate that I’m building for this vendor, there are currently 10 “IF” statements with an additional 2 more that they have requested we add.  This is due to the fact that if there is a particular field that is empty within the segment, they don’t want the engine to send the segment.  

My question is this….is it more efficient to do this within the Xlate or should I have a huge Tcl script on the outbound side that performs these checks before sending the message?  Has anyone encountered this before?

Any advice would be welcome at this point.  You can email me here or directly at the address below…..

Thanks….

Thomas G. Rioux

The Methodist Hospital

trioux@tmh.tmc.edu

832-667-5466

Topic

[James Cobane]

Thomas,

My $.02 worth would be to handle it in the Xlate since the purpose of translation is to map or (NOT map) data to the outbound message.  In my opinion there is no benefit to waiting to do it in an outbound tps, and future maintenance is better handled within the Xlate.

Just my viewpoint.

Jim Cobane

Henry Ford Health

[Anonymous]

You don’t need a tclproc to accomplish this. Simply remove the segment from message list in the variant.

So for an instance this segment is ZV1. Assume you have this segment in ADT_A01.

launch the HL7 -> version -> variant and then select the message type.

right pane you would see the list of the segments.

Even if you have it as optional you will have to remove it.

Save it. Bounce the threads.

Test it out.

It should work though.

-Reggie-

[Jonathan Hamilton]

Depending on the complexity of the filtering I lean towards keeping it in the Xlate.  If you have multiple and/or compound requirements it usually comes out cleaner and easier to develop using Tcl, at least for me.  I usually resort to Tcl if the Xlate method will require more than 5-10 additional actions.  This is an attempt to reduce Xlate bloat which I find harder to support than reading Tcl code.

I have developed several interfaces like this and neither approach is easy to support as you get into more complex filtering.  I think the question you should answer is which are you more comfortable developing in Xlates or Tcl?  Also, from a support standpoint how comfortable is the rest of your team with the approach you choose.  Meaning, don’t pick Tcl if you know it, but nobody else does.

[Jim Kosloskey]

Tom,

If it were me, I would use the Xlate.

If you are concerned regarding operational performance, try timing an Xlate without the IFs and one with. Compare the difference and see if it is tolerable (remember there is a big performance hit when an Xlate is referenced within the engine for the FIRST time so take your timings from the second use or later).

My guess would be the difference is tolerable when compared to the maintenance benefit. After all anyone using Cloverleaf should at least be Level 1 and a Level 1 person should be able to maintain Xlates but maybe not Tcl.

Jim Kosloskey

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

[Author]

Replies