0

An HL7 message comes into Mirth and throws a "processing" error. At the very bottom of the message in Raw format is a partial line that has been separated from the line above it. I have to manually correct this every time. I am hoping to use a Mirth-Javascript as a message filter that can fix this so that everything flows without human intervention.

Below message snippet triggers the error. In this example it is the very last line of the HL7 message.

OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||

||||||F|||202254836969552|||

Currently my only fix is to open the HL7 message and manually go to the line break and bring it up to the line above it that is part of the segment.

The HL7 message should look like this:

OBX|68|FT|PT1103&IMP^PET/CT Imaging Whole Body||||||||F|||20190327101958|||
Amit Joshi
  • 15,448
  • 21
  • 77
  • 141
IndyMirthman
  • 21
  • 1
  • 5
  • 4
    [The segment separator is not negotiable. It is always a carriage return](http://healthstandards.com/blog/2007/09/24/hl7-separator-characters/) – Alon Eitan Mar 27 '19 at 18:04
  • What happens if you turn off "Convert Line Breaks" in your inbound data type properties? If the extra line breaks are `\n` characters instead of `\r` it might let them pass through. – agermano Mar 29 '19 at 04:36
  • I turned off convert line breaks and it just processes the message without error but does not fix the problem... it just ignores it. I did see that you can right click in the message and "show line endings" and all the segments end in \r and it appears that "somehow" the last line at OBX.5 a \n is somehow inserted breaking the segment... A colleague is thinking that maybe a the sender has an old interface (like an old modality like an old xray machine) and its output has that in it... – IndyMirthman Apr 01 '19 at 19:44
  • If it's processing the message, what is the problem? Is something downstream also having an issue with it? If you need to you can use mirth to remove or replace any `\n` characters in OBX-5. – agermano Apr 10 '19 at 19:03
  • It's not processing the message as is. It throws an error as shown in the above original post. I'm trying to find a way to negate the error so manual intervention is not needed. When you say remove \n Are you saying i can add a javascript filter that would replace all \n's with \r's ... would a javascript see that since the \n's and \r's are hidden? – IndyMirthman Apr 17 '19 at 19:50

7 Answers7

1

This worked. Put the following into the preprocessor.

message = message.replace(/[\r\n]+(?![A-Z][A-Z][A-Z0-9]\|)/g, "");

return message;
Andrew Fan
  • 1,313
  • 5
  • 17
  • 29
IndyMirthman
  • 21
  • 1
  • 5
0

Remove all line brakes in the channel's pre-processor or attachment script, and then insert them back based on the segment names. The best way would be to stop the message generating system insert line brakes into OBX.5 field.

Shamil
  • 910
  • 4
  • 17
  • I'm new to Mirth so I'm not sure yet on how to go about that. I can test it on a test channel easy enough, but the steps you are giving could you elaborate a little please? – IndyMirthman Apr 01 '19 at 19:51
0

From your question, the HL7 field that contains line breaks is OBX(5,1) which should hold Observation Value.

Observation value may contain line breaks as a part of data. Line break (<CR> or ASCII 13) is segment separator by default. If this is received as a part of data, there will be issues while parsing message. This is the root cause of the problem you mentioned in the question.

The segment separator is not negotiable. It is always a carriage return. I have explained this in more details in this answer.

Ideally, those line breaks should be replaced with its escape sequence while building HL7 message. More details about it are already given in one of my earlier answers here.

So, your inbound message

OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||

||||||F|||202254836969552|||

should be actually

OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||\X0D\\X0D\||||||F|||202254836969552|||

About your actual question that how to do this with Mirth/Javascript, there should not be need in your particular use case. This conversion should be done before sending message to Mirth. So, the one who is sending this message to you should build it like this.

While actually displaying observation value on UI, you again need to do the reverse process.

Edit:

If line break is different than <CR> (ASCII 13), then respective HEX should be replaced in \X0D\. Details are mentioned in my linked answer; I am not repeating those here.

Amit Joshi
  • 15,448
  • 21
  • 77
  • 141
0

Removing all line breaks would be an approach, but it could be a problem later on, you could set up a replace script, that instead of '/n', searches for '|/n|' or a similar string, that way, it would fix that particular problem as well as any other undesired line breaks in between vertical separators, tho it wouldnt help if it broke anywhere else, so keep that in mind.

Skye
  • 21
  • 6
0

Put this code snippet in your preprocessor script. It worked for me

var newmessage = message.replace(/[\n\r]$/,"");

while (newmessage.match(/(\r\n|\r|\n)([^A-Z]|[A-Z][^A-Z]|[A-Z]{2}[^A-Z\d]|[A-Z]{2}[\d][^|]|[A-Z]{3}[^|])/i)) {
    var extrabit = newmessage.match(/(\r\n|\r|\n)([^A-Z]|[A-Z][^A-Z]|[A-Z]{2}[^A-Z\d]|[A-Z]{2}[\d][^|]|[A-Z]{3}[^|])/i)[0].substring(1);
    var newmessage = newmessage.replace(/(\r\n|\r|\n)([^A-Z]|[A-Z][^A-Z]|[A-Z]{2}[^A-Z\d]|[A-Z]{2}[\d][^|]|[A-Z]{3}[^|])/i,'\\.br\\' + extrabit);
}

return newmessage;
DeC
  • 2,226
  • 22
  • 42
franklwambo19
  • 169
  • 6
0

Mirth processor expects every line the first 3 characters should contain valid HL7 segments otherwise the mirth throws an error.

To remove the invalid line breaks in the HL7 message you should follow the below steps.

1.Channel -->Scripts -->Preprocessor.

  1. Paste the bellow code top of the "return message;" statement message = message.replace(/[\r\n]+(?![A-Z][A-Z][A-Z0-9]\|)/g, ""); //This Line is for invalid line breaks in incoming message APPEND to PREVIOUS SEGMENT .
  2. Save the changes and deploy the channel for new changes affected.
Suresh Gopineni
  • 139
  • 2
  • 6
0

I had the similar issue of having blank lines between the segments and i solved it liked this :

content = content.replace(/^\s*\n/gm, '');

Note: This will just remove blank lines. You need to still figure out how to get the next line on current line

You can try regex to eliminate all '\n' not followed by any segment.

Sanket Patel
  • 227
  • 1
  • 14