tranlation doesn’t use correct message definition

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf tranlation doesn’t use correct message definition

  • Creator
    Topic
  • #50514
    Sergey Sevastyanov
    Participant

    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

Viewing 10 reply threads
  • Author
    Replies
    • #66414
      Tom Rioux
      Participant

      Please post your outbound variant.

      Thanks…

      Tom Rioux

    • #66415
      Sergey Sevastyanov
      Participant

      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

    • #66416
      Tom Rioux
      Participant

      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

    • #66417
      Sergey Sevastyanov
      Participant

      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!

    • #66418
      Russ Ross
      Participant

      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

    • #66419
      John Mercogliano
      Participant

      Sergey,

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

    • #66420
      Sergey Sevastyanov
      Participant

      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!

    • #66421
      John Mercogliano
      Participant

      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

    • #66422
      Sergey Sevastyanov
      Participant

      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

    • #66423
      John Mercogliano
      Participant

      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

    • #66424
      Sergey Sevastyanov
      Participant

      Thank you, John

      I got the point

Viewing 10 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
5,042
Forums
28
Topics
9,200
Replies
34,023
Topic Tags
267