Unrecognized TRXID in HL7 2.5.1

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Unrecognized TRXID in HL7 2.5.1

  • Creator
    Topic
  • #49986
    Jim Rawls
    Participant

      Hello,

      I’m running Cloverleaf 5.5 rev1 on Red Hat Linux.

      We’re bringing up a new vendor who is our first using HL7 2.5.1.  They are using the new convention for coding message type in MSH-9, which now has 3 components: message type, event, and message structure.  Here is a sample:   ORU^R01^ORU_R01

      Cloverleaf is not accepting this message and sends it to the database with state 101.  Per the standard the vendor is correct.  To verify that this is the problem, I replayed the message without the 3rd component and it worked.

      I have HL7 selected as my TRXID determination, but in this version you may not select a variant.  Is there a way for Cloverleaf to recognize this message type (short of stripping off the 3rd component)?

      Thanks,

      Jim  

    Viewing 6 reply threads
    • Author
      Replies
      • #64395
        Jim Kosloskey
        Participant

          Jim,

          That is interesting.

          I have not yet had any mesages doing that.

          You might need to write a TrxId proc to accomodate at this point.

          We are going to 5.6.

          When I get a test site I can play with in 5.6, I will try what you describe.

          However, I won’t get to that before you need that answer and it might indicate the same issue.

          Let us know how you handle this.

          Jim Kosloskey

          email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

        • #64396
          Bob Richardson
          Participant

            Greetings,

            You could also try wildcard routing, specifying something like ORU.*

            as your trxid.

            Good luck.

          • #64397
            Jim Rawls
            Participant

              Okay, this was a little clearer to me this morning than late Friday afternoon… once we coded the route as ORU_R01_ORU_R01, it worked fine.  Thanks for the suggestion to use a wildcard, as it got the juices flowing!   🙂

            • #64398
              Brian Goad
              Participant

                I am see these now, and have written a script to remove the “Structure type”. However after reviewing the standard I do understand where this could be beneficial.

                Looking at this thread has helped, but I think this will need to be evaluated further by Cloverleaf.

                So we could not do something like this: ADT_A(01-09) for example as these may come from the source as ADT^A08^ADT_A01. I would welcome ideas on this.

                We are using CL 6.1 on windows by the way.

                TIA

              • #64399
                Jim Kosloskey
                Participant

                  Brian,

                  You could set your TrxID to ‘by field ID’ and only select the components you want. This was new to us in 6.0.0 and should be there in 6.1.

                  No tcl needed and the structure component is not removed prior to Xlate, etc.

                  Moreover if you needed to route by a combination of fields no need for TrxID proc. Such as in the case of the Lab systeem we are working on where the combination of MSH-9.1, MSH-9.2, and OBR-24.1 allows us to select and route types of results we want.

                  This multiple field does not work in 6.0.0 (multiple componets single field does so the MSH-9 issue is resolved) but hopefully it is fixed in 6.1.

                  As I said above in 6.1 the specification of MSH#9.[0-1] will get you the anticpated ORU_R01 to route on.

                  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

                • #64400
                  Steve Williams
                  Participant

                    Jim,

                       I ran into this issue (multiple field routing addresses) today and found your notes on the subject. The Cloverleaf Docs are not much help, but they do hint at the behavior you’ve documented. Any idea if Infor has address the issue since last year?

                    Thanks!

                  • #64401
                    Jim Kosloskey
                    Participant

                      Unfortunately keeping up to date has never been a priority here so I do not have 6.1.2 to try.

                      I do not know if this has been addressed in any subsequent release perhaps a query to support could provide the scoop.

                      email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

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