This topic contains 2 replies, has 2 voices, and was last updated by  jbaker 2 weeks, 2 days ago.

hl7.parse – Some delimiters in the message were repeated.

  • Building a translator script to handle inbound HL7 v2.2+ ORUs which contain ASCII encoded RTF data in OBX5; due to the ASCII characters used for the RTF formatting there is no escape character in MSH2: Beginning of the MSH segment looks like MSH|^~&| instead of typically MSH|^~\&|

    This is leading to a <b>Some delimiters in the message were repeated.</b> when using hl7.parse. Interestingly if I edit a sample message before the translator processes it to include the escape character, it clears and everything works fine except for the ASCII RTF formatting getting messed up; if I add an extra character to MSH2 in Lua using gsub before performing hl7.parse I still get the error on the hl7.parse even though I see the raw string modified correctly: RawMsgIn:gsub('~&','~\\&',1)

    Has anyone else experienced this or have any thoughts?

    If they’re including bare HL7 delimiters in the message payload without escaping them, they’re technically violating the HL7 standard.

    Does the target system need to receive it as RTF embedded in OBX segments as well, or are you performing some other processing on it (extracting to a file for staging/upload, for example)?

    Is there any way you can convince the vendor of the source application to supply the RTF as base64-encoded? You can then convert and process it in its native form, then write some lua code to build the OBX segment(s) as a string with the “native” RTF inserted and append it/them to the destination message. Of course, if the target system can handle it as base64 as well, you really won’t have to jump through any hoops at all.

    Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊

    The target system doesn’t have a problem receiving an ASCII formatted RTF in OBX: the RTF ASCII that is received in OBX5 and it doesn’t appear to utilize any of the delimiter characters, only the “\” which is typically an escape character specified in MSH2.

    My initial thought when I got the error was that hl7.parse was hard coded to expect 4 characters in MSH2 and when it encountered the second pipe it thought the message was trying to use it again as a secondary delimiter/field separator; explains why I can add any other character to the test message between the ‘~’ and ‘&’ and that clears the error; weird thing is the problem doesn’t clear if I use Lua to add the extra character to the message before it gets to hl7.parse.

    I’m working with the vendor to send the results in a BASE64 encoded format, I’m still curious about this error and what exactly hl7.parse is choking on.

    EDIT: wouldn’t allow me to attach the file

You must be logged in to reply to this topic.