Announcement

Collapse
No announcement yet.

Escape characters generating error in OBX

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

  • #31
    Yep. The OBX has returns in it. Your preprocessor should be....


    // Modify the message variable below to pre process data
    while(message.indexOf('\n') > -1)
    {
    message = message.replace('\n', '');
    }
    return message;


    Nothing needs to be in your destination transformer.

    Comment


    • #32
      Originally posted by cory_cole View Post
      Yep. The OBX has returns in it. Your preprocessor should be....


      // Modify the message variable below to pre process data
      while(message.indexOf('\n') > -1)
      {
      message = message.replace('\n', '');
      }
      return message;


      Nothing needs to be in your destination transformer.
      I almost don't want to say it, but that still gives me the "TypeError: The content of elements must consist of well-formed character data or markup" error

      what does that mean exactly?

      Comment


      • #33
        I ran your message through successfully with that code. It means that the message is not in XML format. Mirth converts HL7 into XML for easier processing. In this message there were carriage returns that put the message in bad format. It could meant that there is a <tag> that doesn't have a </tag>. Not likely here as the message itself is not in XML.

        Unless there is an issue in the PHI

        Do you have any other code running on the message?
        Last edited by cory_cole; 12-12-2019, 09:34 AM.

        Comment


        • #34
          Originally posted by cory_cole View Post
          I ran your message through successfully with that code. It means that the message is not in XML format. Mirth converts HL7 into XML for easier processing. In this message there were carriage returns that put the message in bad format. It could meant that there is a <tag> that doesn't have a </tag>. Not likely here as the message itself is not in XML.

          Unless there is an issue in the PHI

          Do you have any other code running on the message?
          Not at this time. We have one destination transformer to change a field value, but I have that off while working on this. Would you be able to attach your channel to a post here so I could load it & compare?

          Comment


          • #35
            This goes back to what I originally said that the \E\ probably wasn't the problem. The best solution would be for the software that is creating the hl7 message to base64 encode the rtf document you're trying to embed and the receiving end would decode it.

            If that isn't possible and it's always the case that the rtf document is the last field of the message, it should be fairly easy to strip that out with the attachment handler, like Jack suggested, and reattach at the end. Technically any carriage returns in the message should be escaped, as that is the segment delimiter, and you don't have valid segments following the delimiter.

            Comment


            • #36
              Originally posted by agermano View Post
              This goes back to what I originally said that the \E\ probably wasn't the problem. The best solution would be for the software that is creating the hl7 message to base64 encode the rtf document you're trying to embed and the receiving end would decode it.

              If that isn't possible and it's always the case that the rtf document is the last field of the message, it should be fairly easy to strip that out with the attachment handler, like Jack suggested, and reattach at the end. Technically any carriage returns in the message should be escaped, as that is the segment delimiter, and you don't have valid segments following the delimiter.
              I believe this method is the vendor's limitation, if they are to send RTF.

              I would be happy to try the attachment process, if I could be guided on it.In the Summary tab, we have "Store Attachments' checked but the drop-down menu next to it has "None" selected. I don't think it's actually doing anything with this configuration, am I right?

              Comment


              • #37
                Switch it to regex and click the properties button.

                For the expression, use
                Code:
                (?:OBX\|(?:[^|]*\|){4})([\s\S]*)$
                Use "application/rtf" for the mime type.

                This will take EVERYTHING including and after OBX-5 of the first OBX segment and replace it with a token. The token will be replaced with what was removed when your destination connector attempts a send. If that doesn't work you may need a different regex or to write a javascript attachment handler.

                This should let you process the message without changing the content by replacing values (and likely breaking your rtf.)

                Comment


                • #38
                  Originally posted by Ozz View Post
                  I almost don't want to say it, but that still gives me the "TypeError: The content of elements must consist of well-formed character data or markup" error

                  what does that mean exactly?
                  Originally posted by cory_cole View Post
                  Yep. The OBX has returns in it. Your preprocessor should be....


                  // Modify the message variable below to pre process data
                  while(message.indexOf('\n') > -1)
                  {
                  message = message.replace('\n', '');
                  }
                  return message;


                  Nothing needs to be in your destination transformer.


                  Got it working this morning with the above in place. Not sure why it wasn't working the other day, but here we are. Things are moving along - thank you so much! If I have to revisit and look at the attachment idea, it's nice to have that outlined here as well to go by.

                  Comment

                  Working...
                  X