xlate question

[Daniel Bantaa]

I have an xlate that I use for ORUs to fix the result flags in certain cases.  It work fine to fix the flags, but know I’m have problems with the OBX(7) field in some cases.  I think it because of the bulkcopy, because I don’t do anything else with this field.

ex.

before xlate ->  1.005-1.030

after xlate -> 1.005-1.03

The last zero is getting stripped off, but not in every case.  It seems like it only what a max of 10 chars?

Thanks in advance.

Topic

[Ryan Spires]

Daniel,

Check your field length within your outbound variant… it may be truncating it to length of 10…

if so, just mod the field length in the variant and you are off an running.

Ryan

[Daniel Bantaa]

I’m not using a variant, the xlate is HL7 2.3 to HL7 2.3.  I’m only using the xlate to modify the result flag in certain cases.

[Russ Ross]

As you can see by the attached screen shot the standard definition for OBX-7 does have a maximum length of 10 like Ryan suspected.

So his suggestion is valid but he just didn’t know that you also need to create a variant before you modify the field length.

I would not ever change the standard definiton because it will disappear with any future cloverleaf upgrades you might do.

Russ Ross
RussRoss318@gmail.com

[Daniel Bantaa]

That makes sense, but how does the incoming message, which is HL7 2.3, have more than 10 chars in that field?

[Russ Ross]

I have observed like you that the xlate only turncates what goes out and not what comes in.

It is my understanding it is designed to behave this way.

In fact there are other interesting aspects about how the xlate treats what comes in.

Like you can access extra subfields that are not even defined in the variant.

I think the idea is to have the xlate manipulate what goes out and not what comes in.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies