Clovertech

tranlation doesn’t use correct message definition

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

  • Creator
    Topic
  • December 15, 2008 at 8:22 pm #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

    • Creator
      Topic
    Viewing 10 reply threads
    • Author
      Replies
      • December 15, 2008 at 9:03 pm #66414
        Tom Rioux
        Participant

          Please post your outbound variant.

          Thanks…

          Tom Rioux

        • December 15, 2008 at 9:05 pm #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

          • December 15, 2008 at 10:21 pm #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

            • December 15, 2008 at 10:26 pm #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!

              • December 17, 2008 at 12:58 pm #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

                • December 17, 2008 at 1:24 pm #66419
                  John Mercogliano
                  Participant

                    Sergey,

                    John Mercogliano
                    Sentara Healthcare
                    Hampton Roads, VA

                  • December 17, 2008 at 2:52 pm #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!

                    • December 17, 2008 at 5:51 pm #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

                      • December 17, 2008 at 5:59 pm #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

                        • December 17, 2008 at 8:39 pm #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="https://usspvlclovertch2.infor.com/viewtopic.php?t=859&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=859

                             Let me know if this clears it up for you,

                            John Mercogliano
                            Sentara Healthcare
                            Hampton Roads, VA

                          • December 20, 2008 at 1:38 am #66424
                            Sergey Sevastyanov
                            Participant

                              Thank you, John

                              I got the point

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