Announcement

Collapse

Mirth Connect 4.0.1 Released!

Mirth Connect 4.0.1 is now available as an appliance update and on our GitHub page. Mirth Connect 4.0.1 is a patch release containing a bug fix which includes fixing a Jetty keystore regression that caused Connect servers using a PKCS12 keystore containing a wildcard certificate and/or a certificate with a SAN to throw an exception on startup. 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

  • jacobb
    replied
    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.

    Leave a comment:


  • afterdark23
    replied
    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

    Leave a comment:


  • fubar
    replied
    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

    Leave a comment:


  • jacobb
    replied
    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.

    Leave a comment:


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

    < 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
Working...
X