HL7 icon indicating copy to clipboard operation
HL7 copied to clipboard

Not a valid message: invalid control segment

Open Antoniojesusv opened this issue 4 years ago • 8 comments

ACK response received contain hexadecimal characters that are not deleted prior to the construction of the message, causing this error.

Screenshot from 2020-06-30 08-52-52

This ACK response has been generated by Nextgen connect 3.9 with the MLLPV2 protocol.

Screenshot from 2020-06-30 08-58-38

one possible solution has been to replace the hexadecimal characters right after the reading of the buffer.

Screenshot from 2020-06-30 09-01-58

  • line 136

Antoniojesusv avatar Jun 30 '20 07:06 Antoniojesusv

Thanks for raising this issue with the solution. I'll make this change in a day or two. If you need it before that you can create a PR.

senaranya avatar Jun 30 '20 08:06 senaranya

Thanks for raising this issue with the solution. I'll make this change in a day or two. If you need it before that you can create a PR.

I'll be creating a pull request these days, thanks to you.

Antoniojesusv avatar Jun 30 '20 11:06 Antoniojesusv

I went through the code and it looks like the standard prefix and suffix characters are already being removed:

$data = preg_replace('/^' . $this->MESSAGE_PREFIX . '/', '', $data);
$data = preg_replace('/' . $this->MESSAGE_SUFFIX . '$/', '', $data);

Where: MESSAGE_PREFIX = "\013" (or 0x0B) MESSAGE_SUFFIX = "\034\015" (or 0x1C0x0D)

Can you give me the specific hex code(s) that's causing this issue for you?

senaranya avatar Jul 02 '20 12:07 senaranya

I get this error too with the following example of an incoming message (output from tcpdump):

^KMSH|^~&|redacted|P|2.3^MORC|redacted^M^\

saywebsolutions avatar Oct 29 '21 19:10 saywebsolutions

Seems like newline characters? What are these characters in hex? We remove only standard MLLP characters (0B from prefix and 1C0D from suffix). Nothing else is removed.

senaranya avatar Oct 30 '21 02:10 senaranya

I'll try with a different flag to see what these characters are in hex with tcpdump. I think these are the expected control characters in ASCII; ^K looks to be 0B in hex and ^M^\ is 0D1C according to https://cs.stanford.edu/people/miles/iso8859.html

saywebsolutions avatar Nov 01 '21 23:11 saywebsolutions

Guess the suffix could be the reason it's not working - code expects 1C0D, but your message has 0D1C. I'm not too sure if either or both are part of MLLP protocol standards. If you can find out that 0D1C also conforms to the standard, I can add its support in the code.

senaranya avatar Nov 02 '21 05:11 senaranya

Yeah I noticed too that the characters are switched; I will look into it. Thank you

saywebsolutions avatar Nov 02 '21 15:11 saywebsolutions

Closing due to inactivity

senaranya avatar Apr 07 '23 06:04 senaranya