tranlation doesn’t use correct message definition

[Sergey Sevastyanov]

Hi all

I use a tcl proc to determine trxId. For my Lab results it returns trxId as ORU_R01_LB.

I created variant with message type ORU_R01_LB:

Code:

prologue
   who: username
   date: December 15, 2008 3:35:49 PM EST
   hl7vers: 2.4
   type: msg
   version: 4.0
end_prologue
MSH
PID
[
  PV1
  [ PV2 ]
]
ORC
OBR
[{ OBX } ]

I set up routing to translate ORU_R01_LB messages and configured translation to translate from my variant (here is xlate prologue):

Code:

prologue
   xlt_infile: hl7 2.4 Paragon_2.4 ORU_R01_LB
   who: username
   date: December 15, 2008 3:36:36 PM EST
   xlt_outfile: hl7 2.3.1 CDR_RAD_OP_DS_MDM ORU_R01_LAB
   type: xlt
   version: 5.0
end_prologue

But it looks like translation still uses ORU_R01 message definition from my variant (that one has just single OBX vs. multiple OBX’s that I need for Lab messages). Translated message has only 1st OBX – all other OBX’s get ignored. I get the following errors in my log:

Code:

[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 7 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 8 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 9 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 10 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 11 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 12 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 13 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 14 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 15 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 16 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 17 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 18 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 19 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 20 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 21 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 22 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 23 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 24 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 25 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 26 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
[msg :RecP:WARN/0:test_cdr_lab_xlate:12/15/2008 15:37:16] [0.0.57549] The # 27 segment encountered ‘OBX’ is out of order for message type ‘ORU_R01’.  Segment ignored.
Engine idle — 12/15/2008 15:37:26

When I created brand new variant for Lab messages and set up OBX as repeating in ORU_R01 the message gets translated just fine. If worst comes to worst I can use that separate variant but I don’t really want to have too many variants.

Any idea what I do wrong?

Thanks

Sergey

Topic

[Tom Rioux]

Please post your outbound variant.

Thanks…

Tom Rioux

[Sergey Sevastyanov]

Here is my outbound variant:

Code:

prologue
   who: svcquovadx
   date: December 15, 2008 5:05:29 PM EST
   hl7vers: 2.3.1
   type: msg
   version: 4.0
end_prologue
MSH
PID
PV1
ORC
OBR
[ NTE ]
ZLS
[
  {
     OBX
     [ NTE ]
  }
]
ZLT

Thanks

[Tom Rioux]

Here is my best guess on the subject.  It appears to me that the engine doesn’t like the message type definition you have defined  (ORU_R01_LB and ORU_R01_LAB).  I attempted to recreate your issue and got the same type of error you received.  I had the following message types defined in my variant:

ORU_R01

ORU_R01_LB

ORU_R01_LAB

When I started to experience the issue you have, I simply deleted the ORU_R01 message type out of my variant.  That didn’t do any good because it seemed to have picked up the ORU_R01 message definition out of the default HL7 2.3 variant.

Hope this helps…

Tom Rioux

[Sergey Sevastyanov]

Thomas,

Thank you for your help.

I was trying to avoid creation of additional variant, but it looks like I can’t do it.

So I created a new variant where by inbound message definition is  ORU_R01. Interesting that for outbound ORU_R01_LAB the translation seems working.

Also I still have trxId = ORU_R01_LB and it works with inbound definition ORU_R01. It’s probably a bug in Cloverleaf (or I’m doing something very wrong)

Anyway, thank you for your help!

[Russ Ross]

I was concerned by the problem you are observing.

I don’t have time to research but did wonder if a truncation issue might be confusing cloverleaf.

I think if you try to create a variant called ORU_RLB that should be enough to quickly get a clue if truncation of the message type defined in the xlate could be part of the problem for the inbound variant.

Russ Ross
RussRoss318@gmail.com

[John Mercogliano]

Sergey,

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Sergey Sevastyanov]

Russ,

no I didn’t try what you suggest, but I think John got it right.

MSH-9 still has ORU^R01 (and I want it to stay that way). I thought that trxId will determine which translation to take. But it looks like it only drives the route, not the translation.

I still think it’s wrong, because I explicitly configure inbound variant for translation.

Now that I think of it I have the same issue for my radiology results. The same trxId program determined them as ORU_R01_RAD and they go through a different route. But they actually use ORU_R01 variant in xlate. That was fine with me, I actually configured xlate to use it (that’s why I didn’t encounter the same issue).

I will go with a separate variant instead of changing MSH-9 to have ORU^R01_LB and then changing it back to ORU^R01 in translation.

Thank you guys for your help!

[John Mercogliano]

Sergey,

 In this case I think HV got it right in that they went for the lesser of two evils.  When you look at the hl7 standard and the ADT mapping which is the worst of them, if they determined the message layout from the translation instead of the message we would have to create a separate translation for each ADT type we wanted to process.

An A01 does not look like an A02 but with the way they did it I was able to create a variant and make all the ADT types we process map the same with the missing pieces as optional, so I have one translation based on an A01 but all ADT uses it.

I can control how my variants look but I can’t control how other systems format there messages.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Sergey Sevastyanov]

John

You almost convinced me. If you could explain how you create one translation for all ADT’s I will be convinced.

When I configure translation Cloverleaf makes me specify a particular message (like ADT_A03). I can’t get away with just specifying ADT (unless I created a variant called ADT that is good for all). Is it what you do?

Thanks

[John Mercogliano]

Sergey,

 Here is a link to another topic that you might find useful, that discusses this in more detail.

<a href="http://clovertech.infor.com/viewtopic.php?t=859&#8243; class=”bbcode_url”>http://clovertech.infor.com/viewtopic.php?t=859

 Let me know if this clears it up for you,

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Sergey Sevastyanov]

Thank you, John

I got the point

[Author]

Replies