Announcement

Collapse

Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

< character in a 2.x OBX.5 (value) field

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • < character in a 2.x OBX.5 (value) field

    I've searched the faq and the entire site but was unable to find any hint about the following situation:

    I'm trying to parse ORU R01 HL7 2.x messages with mirth 1.7

    These are laboratory results in free text, and of course some OBX have OBX.5 (value) string elements like
    " * CEFTAZIDIME <=8 S <=8 S"
    It seems (after much fiddling!) that the mirth inbound message template parser will reject any message containing the "<" character no matter what I put for OBX.2 (value type) - I've tried TX and ST that I thought might allow those characters.

    The ">" character is permitted, so I'm guessing it's not some confusion about XML delimiters.

    I may be able to convince the people generating the message to do something about this, but I'm wondering if there's some value type I didn't yet try that will convince the parser to ignore any < characters inside an OBX.5?

    Post edited by: fubar, at: 03/15/2008 13:32

    Post edited by: fubar, at: 03/15/2008 13:33

    Post edited by: fubar, at: 03/15/2008 13:33

    Post edited by: fubar, at: 03/16/2008 10:47

  • #2
    Re:&lt character in a 2.x OBX.5 (value) field

    Turn on Encode Entities. The option is in your source and destination transformers, under the inbound and outbound template protocol properties.
    Jacob Brauer
    Director, Software Development
    NextGen Healthcare

    sigpic

    Comment


    • #3
      Re:aracter in a 2.x OBX.5 (value) field

      jacobb wrote:
      Turn on Encode Entities. The option is in your source and destination transformers, under the inbound and outbound template protocol properties.
      Thank you very much Jacob - absolutely beautiful solution. Works fine now.

      Sorry I didn't notice that check box - I found the line end conversion but didn't stop to think that encode might do the trick. We always get lots of stupid characters like < in lab results and I would be surprised if it wasn't a common "gotcha"?

      I wonder if it should always be on by default for 2.x messages - or is this usually not needed?

      Post edited by: fubar, at: 03/15/2008 22:15

      Comment


      • #4
        Re:&lt character in a 2.x OBX.5 (value) field

        jacobb:
        What does the Encode Entities do?


        Does the Encode Entities need to be applied to every channel for this to work.

        I have a LLP listener that feeds numerous channels and I am having this same problem. Can I select the Encode Entities in the main channel and that would take care of the other channels?


        Also, there is an issue open in the Jira about this problem:
        http://www.mirthproject.org/communit...owse/MIRTH-804

        Post edited by: afterdark23, at: 03/17/2008 07:36
        Reid Hospital and Healthcare

        Comment


        • #5
          Re:&lt character in a 2.x OBX.5 (value) field

          Encode entities is on by default EXCEPT in version 1.7.0. This has been changed for 1.7.1, where there isn't even an option to turn it off.
          Jacob Brauer
          Director, Software Development
          NextGen Healthcare

          sigpic

          Comment

          Working...
          X