hl7 variant and xlate question

[Kevin Crist]

We are sending transcriptions to a new system, they want all transcription types we have, i am wanting to use one xlate to do the same work for all of these, we have 4 different types of transcriptions systems sending this each with different hl7 versions. can i use a variant for version 2.3.1 for version 2.4 or 2.2? Wasnt sure if i had to create many variants for the same one xlate.

thanks for your time.

Topic

[Jim Kosloskey]

Kevin,

An Xlate can only reference one inbound and one outbound variant.

It is possible that particular Message/Event structure being used for the transcription systems has sufficient commonality among the versions used that one variant of one of the versions could be used for all versions (that does happen). If that is the case (that will take some analysis) then you can do the one Xlate.

If not you could always try to ‘normalize’ each of the inbound messages to a common variant but then I don’t think you would achieve the single Xlate goal and ‘normalization’ of disparate vendor systems can be problematic over time.

If it were me, what I would do is to have a variant and an Xlate for each inbound system.

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

[Kevin Crist]

Thanks Jim,

That was the route i was thinking, but you never until you ask.

[Russ Ross]

I have found it easier when dealing with different versions of HL7 to use the field number notation for example:

0(0).PID(0).#2.[0]

This is because HL7 item numbers are different for some versions of HL7 not to mention everyone uses the field numbers when talking about the message.

I have used a common variant to discribe multiple versions of HL7 back when I thought normalizing my data made common sense.

After I made that journey I no longer think normalized data is the way to go because we have many departmental silos that want data tailored made for them their way.

This unchanging aspect of human nature is problably one of the big reasons our services stay in high demand.

Over time I’ve tended to create integrations that have more granualarity of control independent of the other because this better matches the envirnmoent at my enterprise.

Russ Ross
RussRoss318@gmail.com

[Kevin Crist]

Thanks. This leads me to another though provoking question, if you dont mind. We have a setup that is using many tps stacks. One tpsproc for the msh, one for obr,obx,etc…basically whatever needs to be changed. The good thing is there isnt a lot of changes happening in the tclprocs but are you really saving time by running a message through 4 or 5 tclprocs vs one xlate. I know their is differeing opinion on this and was just curious.

thanks.

[Tom Rioux]

Strictly from a troubleshooting standpoint, I prefer to do things in the xlate.   If something goes wrong, it is easier to find it in a single xlate than having to wade through multiple tcl procs in an outbound tcl stack.  

I have had situations before where the message will go through the outbound tps stack without obvious errors but the message format may be off in one place or another.   Then I would have to go through each tcl procs to find out which procs is the offending proc.  You can see where that would get cumbersome if you had 4 or 5 procs in the outbound TPS.

Just my humble opinion…..

Tom Rioux

[Jim Kosloskey]

I rarely do anything in a Tcl proc I can do in an Xlate.

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

[Bob Richardson]

Folks,

Just another guideline to follow in using HL7 variants:  NEVER implement a 2.1 HL7 variant.  Back in pre-historical times, some smart analyst decided to renumber all of the fields when documenting the HL7 2.2 variant and that created havoc between version 2.1 and 2.2 and subsequent variants.

In the HL7 2.N world, I like to create variants with the highest level that the engine supports (here 2.5 for CIS5.6) and then set the MSH version id to whatever the vendor specifies.  Some vendors like Epic Systems implement HL7 message formats that are “blended” rather than standard.

Also: if you can do the work in the Xlate that centralizes your processing and makes it easier for maintenance down the road.  There are times when the TCL procedure will override that consideration especially if you must work with the post mapped record and spin through and reformat a message based on the new output record.

Think of ease of maintenace down the road.

[Author]

Replies