hl7 variant and xlate question

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.

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.

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

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

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.