Multiple Copies of Message Type in 1 Variant Wont XLATE

[Brian Hochenedel]

I would like to have a single HL7 variant per system/vendor that Cloverleaf (6.1.1) connects to. In this instance I am creating one for Epic using 2.3 as the base. My issue is that I have 3 different interfaces that process ORU messages (incoming lab results, outgoing results, incoming/outgoing radiology results). I defined 3 different copies of ORU (ORU_LAB, ORU_RAD, and ORU) to set up my translations since each interface has a different format. Unfortunately, Cloverleaf will not use the variant spec that was defined in the XLATE for processing the translation. Instead it is using the default ORU and is truncating various segments.

It seems like it should work, but for some reason Cloverleaf is refusing to use the defined translation. I thought that the whole purpose of setting up a route/TRXID was to determine the XLATE that I want to process the message. Instead, Cloverleaf is overriding my wishes. I really dont want to have 3 different HL7 v2.3 variants just to process my Epic messages. Is there a better solution to this? I also have the same issue with ORM and ADT messages.

I’ve checked the forums for answers and the only thread I came across was: Multiple Variants. I do not agree with the “solutions” in the thread as they do not solve the underlying issue. Currently I have every ADT message type definition set to the same definition which also seems cumbersome…instead of just defining a default ADT message type once and routing all TRXIDs through that one XLATE regardless of MSH-9 (again, that value was already used to determine the correct XLATE to use).

Topic

[Jim Kosloskey]

TrxID will take what is in MSH-9 (unless you have a TrxID proc).

So it does not matter what you call the message type in the Variant when Cloverleaf extracts the MSH-9 from the message it uses that (probably ORU) to find the layout in your variant. I suspect you do not have an ORU

so Cloverleaf uses the default

The ORU type structuree is flexible enough so you should not need different structures for Lab/Radiology/etc. – especially later 2.1 vversions (like 2.5.1 and beyond).

What I typically do is to understand the differences between the standard and the vendor for a given Message Type (like ORU) and modify the ORU layout to accomodate all of the differences in one ORU definition.

The only time this does not work is if the vendor has multiple variances from the standard which cannot be defined in one message structure – then an additional variant would be needed. I have found that to be rare – bbut then again I have not yet dealt with the EPIC loonies (thankfully).

It is important to thoroughly understand the message structure potentials as well as the variances from the standad the vendor will be using.

If you still have questions feel free to email me.

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

[Terry Kellum]

As you can translate using TCL procs, that would be one solution.  It is quite a bit more labor intensive, and requires more maintenance and testing than a standard translate.

One other note is that TrxId is not the determiner of message parts, the TrxId only determines the Path that the message will follow.  If you are trying to change from an existing message flow, make sure that you check your translate configuration.  That is the point where variants will succeed or fail.

If you have a large base of messages, do a big test on your variant.  Picking out a small number for your development testing is good, but you need 1000+ messages (ideally) to give all of your parts a good test.

The command line testing tools are greatly valuable in the subject of mass testing.  The GUI works well for development, but if you are running a thousand messages, you have to be good at the command line.  Capture both the message outputs and the standard and error channels.

You may know all of these things, but I consider this board to be a great training tool.  I did a level I class, and that got my feet wet, but Clovertech is where I have been able to study the techniques used by the folks who can really utilize the engine to its fullest.  Charlie and Jim have taught me so much just by observing their posts on this board, so I try to expand just beyond the scope of the question to offer ideas that can help not only the questioner, but the lurker as well.

[Brian Hochenedel]

Thanks Terry. I am Level 2 and 3 certified and had Charlie as our implementation consultant, so I have some of his custom TCL scripts still running in Production (with some of my own modifications thrown in

[Author]

Replies